Coldstart is in final cutover and has not been released. The commands on this page run in the development build; there is no release you can install today.
The four verbs so far move a session from start to close. Two more sit outside that loop entirely.
/cleanup sweeps for the problems that are too expensive or too judgment-heavy to check at every
close. /maintenance re-derives the surfaces the machine generates and re-measures the harness
against its own recorded envelopes. Neither advances your work; both act on the thing your work
runs inside.
[Visual 1.5 — Two off-ring arrows. The session ring from 1.1 is drawn small and entirely in grey outline, pushed to the left of the frame with no arc lit, labelled "the session loop, unchanged". To the right sits a separate box labelled "the harness itself", drawn as a stack of four layers: checks, generated maps, the open-work queue, the recorded envelopes. Two thick arrows leave the ring's outside edge and land on that box, deliberately not touching any arc. The upper arrow is labelled "/cleanup — sweep, then propose" and ends in an open hand icon rather than an arrowhead, with the note "reports; applies only what you approve". The lower arrow is labelled "/maintenance — regenerate and re-measure" and ends in a circular refresh arrow over the generated-maps layer. A caption under both reads: "neither arrow points back into the ring".]
Why these are separate verbs
Some checks are cheap enough to run at every close and some are not. Some findings have an obvious fix and some are structural decisions that a program should not make on your behalf.
Folding the expensive, judgment-heavy checks into the close would make closing slow enough that people stop doing it, and would put an automated restructuring proposal in front of you at the moment you are least inclined to evaluate it. Splitting them out means the close stays quick and the sweep stays honest about being advisory.
The sweep
The sweep runs the project's own strict self-check. Strict mode is the difference that matters: it promotes the warning-class findings, the ones about things that smell wrong rather than things that are broken, into errors. Registry entries that describe capability nobody has built, surfaces that are present but never used: these pass an ordinary check and fail a strict one.
Findings are triaged by class rather than listed flat, because the class is what tells you what kind of decision each one is.
Near-duplicates. Two things that do the same job, which is usually the symptom of a find-before-create step that was skipped.
Over-budget files. Files past their size budget. In this product a file that has outgrown its budget is usually a candidate to be split into its own section rather than trimmed.
Stale projections. Generated files that no longer match what they were generated from.
Leftovers from a deletion. What remained behind when something was removed.
It also drains the open-work queue. Anything already shipped is deleted outright, because version control is the archive and a list of finished items is not worth carrying. Anything stale is re-dated, escalated, or proposed for removal. It asks before deleting an item that this session did not ship, which is the specific case where deleting on your behalf would destroy information.
The output is findings grouped by class, each with a one-line proposed fix. Structural changes are proposed and not applied. The one exception is formatting-level fixes inside files that are already in scope for the current work, which are applied and named in a line.
The regeneration pass
Some files in the project are derived rather than written: the maps of what exists and where, and the index that routes a request to the right capability. They are generated from the source they describe, which means they can only be wrong by being out of date.
The regeneration pass re-derives them. A projection that changes when regenerated is drift that has just been caught, and the pass names which file moved and why rather than quietly rewriting it. Because everything it touches is machine-owned and idempotent, running it twice does nothing the second time, and it never edits a file you are the author of.
It then runs the same strict self-check as the sweep, and re-measures the harness against its own recorded envelopes: the newest evaluation report against the trend of previous ones, so a drop in how reliably the right guidance is found becomes visible as a number rather than a feeling. It reports drift. It does not re-band the envelope to make the drift disappear; changing what counts as acceptable is a decision recorded deliberately at a close.
Finally it reviews staleness: how old the open items are, and whether the reference sets used for measurement have gone untouched past their review age. Reported and proposed, never pruned unasked.
When to use them
Run the sweep when the project has been moving fast and you want to know what it has accumulated, before a release, or when something feels duplicated but you cannot name where. Run the regeneration pass after a change that moved or renamed a lot of files, when a generated map looks wrong, or on a schedule loose enough that drift is caught within a few sessions.
Neither belongs inside a working session. They interrupt the session's scope with a different kind of question, and answering it well requires attention the session is already spending.
Limits
The sweep reports; you decide. That is the design, and it means the sweep cannot keep a project tidy on its own. A list of findings that nobody acts on is a longer list next time.
Strict mode raises warnings to errors. It does not detect problems that no check represents. A clean strict run means every represented check passed, which is a narrower statement than "the project is healthy".
The measurement compares this harness against its own recorded history. It is an internal consistency signal and not an external benchmark, and a stable number over time is evidence that nothing regressed rather than evidence that the current level is good.
Neither verb touches your application code, your tests, or your data. They act on the harness. A project can pass both and still be broken in every way that matters to its users.
Next
That completes the six verbs. The next section explains the thing they operate on: one unit of work, from intent to handoff. Continue with the work loop.
How current this page is
Checked on 10 August 2026 against the product's current sweep and regeneration behavior and its recorded release state. To ask whether a claim here still holds, or to report one that does not, write to [email protected].