Coldstart is in final cutover and has not been released. The queue shown here is live in the development repository, while some of its drain behaviour remains a design contract rather than a promise that every item is automatically completed.
Useful work often appears at the wrong time. A session fixing an export path discovers that old records need stable customer IDs. The migration is real, but adding it to the current unit would mix a data change into a bounded endpoint session. Leaving it in chat would make it disappear when the conversation ends.
The open-work queue is the middle position. It preserves the action without pretending that the current session owns it.
[Visual 6.2 — The middle band of the section frame, enlarged. At centre is one horizontal queue card with five fields: "W42", "medium", "migrate historical customer IDs", "evidence: the read-model decision" and "owning location: @feature:exports". The card sits outside a box labelled "active export session", whose boundary remains unbroken. From the right, two return paths curve back to the card: "the next planned visit to exports" and "section close". The first reaches a small decision diamond labelled "done, stale, or still open?" The second reaches "drain or explicitly defer". A completed card leaves the frame into a small git-history symbol rather than a done column. A caption reads "the queue owns open action; location makes it reachable, and close prevents a silent carry".]
What belongs in the queue
A queue item is valid work that meets two conditions:
- resolving it needs no new human judgment
- it sits outside the active section's scope
If a product decision is still open, the item is a checkpoint and should say what depends on the answer. If a fact needs to remain true after the action is complete, it belongs in a durable decision or reference home. If the work is required for the current outcome, it belongs in the plan rather than beside it.
That leaves a useful, narrow category: open action which should survive this session without expanding it.
The item has an owner
The development repository keeps one shared open queue. Its grammar is deliberately compact: an identifier, severity, short action, optional evidence and a location key. The location can name a section, file or feature. A larger area can own its own queue when the shared file reaches its budget, using the same grammar.
The location key matters more than a generic priority label. It ties the item to a visit the project will make for another reason. A note about historical export IDs belongs to the export feature; a broken reference checker belongs to that checker; an unresolved documentation contract belongs to the relevant section. The work can return when that location is active and the evidence is already warm.
Location is not identity. The product's own history contains queue labels that were later reused for unrelated defects, so a short identifier alone cannot safely carry meaning forever. The action, location and evidence have to travel together. Nor does location prove importance: it answers "where does this work live?", not "should this work still be done?"
Open-only means completed work leaves
The queue is a view of work still open. When an item ships, its line is deleted. There is no done section and no growing archive at the bottom of the file; version control already records the line, its changes and its removal.
This matters because a queue that contains its whole history stops answering the question a fresh session asks. It becomes a changelog with open work hidden inside it. Keeping only live actions makes the file small enough to scan and makes absence meaningful: the action is no longer being carried.
Deletion from the queue must still be honest. The current cleanup instruction asks before deleting an item the session did not ship. A line can also be re-dated, escalated or proposed for removal if it has gone stale. "I do not remember why this is here" is evidence that the item needs review, not evidence that the work is complete.
Drain on touch
The primary return path is a relevant visit. When planned work next enters a file, feature or section, the queue items owned by that location are read with it. Work that is now required can move into the plan. Work that has already shipped can leave. Work made obsolete by a later decision can be proposed for removal. Work still valid and still separate stays open.
This is cheaper than a scheduled cleanup pass because the context needed to judge the item is already present. The project is touching exports anyway; that is the right moment to decide whether the historical-ID migration still belongs, not an arbitrary date several sessions later.
The development cleanup entry makes this behaviour available as an on-demand pass. It runs the strict checks, reads the queue, and reports findings grouped by class with a proposed repair. It does not silently apply structural fixes. Its current contract is report and propose, with only formatting-level fixes inside already-owned files treated as routine.
Close is the backstop
Drain on touch can miss an item if its location is never revisited. The cleanup design therefore gives section close a second job: every open item owned by the closing section needs a disposition. It is drained, or it is explicitly re-keyed forward with a reason. The design also names a staleness floor for items carried across repeated closes, so "later" cannot remain the only answer forever.
This is resurfacing, not automatic execution. Close does not make a migration safe to run or decide that an old action is still valuable. It forces the project to look at the item while the section's state is being handed off. A valid deferral remains possible, but it is visible and owned.
The distinction protects both sides. Without the close backstop, the queue becomes a place work goes to be forgotten. Without the human disposition, close becomes a machine for dragging stale work forward merely because a line exists.
The queue preserves scope, not certainty
In the export example, the current session can finish the endpoint for records that already have stable IDs. The historical migration becomes one queue item owned by the export feature, with the read-model decision as evidence. Nothing in that act proves the migration should be run, how it should be cut over, or whether all records need it. Those questions belong to the later unit.
What the queue establishes is smaller and useful: the work was recognised, it did not expand this session, and a future visit has a place to find it.
What this page does not claim
A location key does not guarantee retrieval, and a close rule does not guarantee good triage. The queue can still carry a vague action, stale evidence or the wrong owner. The source revision shows a real open-only queue and an on-demand cleanup instruction, while the full drain-on-touch and staleness behaviour is part of the design contract. Do not read the page as a claim that an installed service completes every queued item automatically.
The queue also does not establish stable item identity or provenance. For that reason, it cannot by itself authorize deletion of the code or content a pivot left behind.
Next
Move from preserving valid work to removing invalid residue: safe subtraction.
How current this page is
Checked on 10 August 2026 against the pinned product revision's live queue, cleanup instruction, iteration design and cleanup design. To ask whether a claim here still holds, or to report one that does not, write to [email protected].