Dr Change Orchestrator

DeepReason change orchestrator

The operator has suggested a change. Your job is to implement exactly that change — not the change you would have designed, not the neighboring improvement, not a partial version you forgot to finish. This workflow differs from deepreason-orchestrator (defects): there is no diagnosis; the authority is the OPERATOR'S WORDS, and every phase traces back to them.

The ledger rule (the anti-forgetting mechanism)

REQUEST.md is the single source of authority. It holds the operator's suggestion VERBATIM, split into numbered requirements (R1, R2, ...). Every later artifact cites requirement numbers.

• Before starting ANY phase, re-read REQUEST.md and CHECKLIST.md in full. Context windows lose earlier turns; the ledger does not.
• If the operator sends a new message mid-workflow: APPEND it to REQUEST.md verbatim as new numbered requirements (or amendments "R2a supersedes R2") BEFORE acting on it, then route to dr-spec-change to reconcile. Never absorb new instructions silently into the current step.
• A requirement is never deleted, only marked superseded-by:<n> or deferred (operator approved <where>).

Scope contract

1. Implement what REQUEST.md says. Where it is silent, choose the smallest reasonable interpretation and RECORD the assumption in SPEC.md; where two readings differ materially in effort or behavior, stop and ask — one batched question, not a dribble. Before asking, load dr-ask-the-right-question: derive the answer from the record and the operator's recorded values first; a fork the dominance test kills is decided and noted, not asked.
2. Anything you notice that is broken but not requested: into PARKED.md (a defect goes to the deepreason-orchestrator workflow later). Never fix it now. Write the entry for its future runner, at park time: one line of WHAT, then a ready-to-send prompt (route, one-goal statement, evidence pointers, end state) — the follow-up should cost the operator a paste, not an authoring session.
3. Stop conditions: a step fails twice the same way; the spec turns out to require touching frozen-record semantics (state digests, event application, replay formats, qualification subjects); the estimated diff exceeds SPEC.md's budget; or a requirement contradicts the record/codebase (report the contradiction, do not pick a side silently). Every stop follows the standard format — decision in ONE sentence, options priced, a recommendation with its reason — canonical in dr-drive-harness §6's calibration note.

Map preflight (do this before routing, every time)

Full procedure, canonical: dr-drive-harness §4 — docs/map/INDEX.md → INV-frozen-surfaces.md → seam document (before either subsystem) → record the resolved ids in the tranche's first artifact.

The map is maintained by the phases that change code, in the same commit — see dr-execute-step and dr-implement-fix. Nothing else may advance a Verified-at: stamp.