The no-op early return skips staleness, so a no-op `update` reports a stale document as fresh

Class: misleading · Severity: cosmetic Flow: arch-3e305bc76ff0 · Step: archive/unarchive on a document already in that state Question: None · Frequency: archiving an already-archived document

Finding¶

The no-op early return builds the view without computing staleness, so a stale document reports stale: false.

What happens today¶

document_service.py:166 and :180 call from_document(document) with no stale= argument; the dataclass default is False (dto.py:50).

Impact¶

One field is wrong on one rarely-hit path.

Proposed default¶

Pass stale=self._is_stale(document) on both early returns.

Resolution¶

FIXED 2026-07-29. Both no-op early returns now pass stale=self._is_stale(document). RE-CLASSIFIED on the way: filed cosmetic ("one field is wrong on one rarely-hit path"), but it put a wrong value in the machine contract — get reported stale: true for a document unarchive reported as fresh, and stale exists to be trusted. Cheap to fix and not cosmetic; the label was fair when filed and stopped being fair once the product leaned on machine-readable output. NOTE, found while writing the test: archive/unarchive stamp updated, so archiving a stale document makes it fresh. That is defensible — archiving is a human decision about the document, like a status change, not a mechanical rewrite — but it means the first attempt at this test proved nothing. Recorded so the next reader does not repeat it.

Actors affected¶

• AI coding agent

Evidence¶

• src/docir/modules/documents/application/services/document_service.py:166
• 180
• src/docir/modules/documents/application/dto.py:50

---

Migrated from the discovery gap register (GAP-015); the register itself now lives in this store.