GENERATED VIEW · PRIVATE ARCHIVE · DO NOT SERVE
RobCo Industries · Archive Museum

dispatch-autonomy-preference.md



MEMORY

memory/localmode-1060dea9-0dc3-42b4-958d-2a6f7a6c0c58/dispatch-autonomy-preference.md

sha256 d620a8e022022365 · 3443 bytes · original held in the private archive

--- name: dispatch-autonomy-preference description: "⭐ STANDING OWNER PREFERENCE (2026-07-14, emphatic): DO NOT gate the routine plan→build→audit→next-unit progression on an explicit 'go' each time. Once a unit/direction is agreed, DRIVE it through the whole chain automatically. Only stop for a REAL decision, a destructive/irreversible action, spec ambiguity, or an empty queue." metadata: node_type: feedback type: feedback originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- **Owner, verbatim (2026-07-14, frustrated — and right):** *"why are you making me individually tell you go everytime when you know to automatically go."* **The correction:** Dispatch was asking *"go for the build?" / "go for the audit?"* at every step of the standard plan→build→audit chain. The owner had already said "go" dozens of times the same day. **He wants the routine progression to RUN ON ITS OWN.** **Why:** the rules already put the efficiency burden on Dispatch, not the owner — and this is the same principle. Gating every mechanical step on a human round-trip is exactly the avoidable friction that rule exists to remove. **Once the unit is agreed, the plan→build→audit→(fix loop)→next-queued-unit chain is THE MACHINE. It should not stop to ask permission to keep turning.** ## ⇒ DEFAULT: AUTO-ADVANCE THROUGH THE CHAIN For an agreed unit, without asking: - plan (if non-trivial) → build → independent audit → if audit bounces, loop to fix → when it passes, **move to the next queued item and start it.** - Report at each landing as the rules require, but **a report is not a request for permission** — keep going. ## ⇒ STILL STOP FOR (these are real, not ceremony): - A **genuine design decision with no obvious right answer** (e.g. red-vs-dashed, the +1-tap tradeoff, "is the left casing in or out", which of 3 Fable variants). These are the owner's calls. - A **destructive / irreversible / prohibited action** (delete data, force-push, anything in the safety "explicit permission" list). - **Spec ambiguity** — genuinely unsure what he wants. - **A new direction not yet agreed** (a new feature, a new experiment, reordering the roadmap). - **The queue is EMPTY** — nothing left to auto-advance to. - A **failure/blocker** that needs his input. ## ⇒ DO NOT STOP FOR: - "Go for the build?" after a plan he already approved the *unit* for. - "Go for the audit?" — audits are a mandatory stage of the chain, not optional; just run them. - "Want me to start the next one?" — if it's the next queued item and nothing's ambiguous, start it and say so. **The tell that I've got the balance right:** the owner should only have to weigh in on *decisions*, never on *permission to continue*. If I'm asking him to rubber-stamp the machine turning, I've regressed — re-read this. **One named exception:** an explicitly GATED batch — work the owner said to hold and *remind* him about — is not part of the queue this auto-advances through. Starting it is a new direction, and new directions still need his go. See [[robco-phase6-backlog]]. *Correction 2026-07-20: protocol numbers removed (they are looked up in `CLAUDE.md` + `rules/`, not remembered). The preference itself is unchanged.* Related: [[opus-plan-sonnet-implement-workflow.md]] (the chain this auto-advances), [[session-management-rule]], [[engineering-metrics-log]] (the efficiency-is-Dispatch's-burden principle).
STAMP · generated for RELEASE v2.8.5 commit 06e5180 (06e51801b38a) · archive input-tree hash c07fbfbdd2e1ddeb · 754 files · no wall-clock timestamp (regenerates identically when nothing changed).