dev-pabcd

Structured 5-phase development. Advance only with user approval.

> Runtime adapter (agent-neutral): orchestrate <phase> below means your runtime's

> FSM transition command (any host that persists PABCD state and gates transitions).

> If your runtime has NO FSM command, keep the state machine in your working notes:

> announce each transition in your reply and append the attestation JSON to the

> worklog/devlog — the discipline is identical, only the persistence differs.

> "Worker dispatch" means spawning a subagent through whatever delegation surface

> your runtime provides.

> C0/C1 work (e.g. small in-place patches): See dev §0.0 Work Classifier and §0.1 Patch

> Fast-Path first — full PABCD is mandatory for C4 and conditional for C3, not the baseline for every task.

> dev is canonical: dev §0.2 Rule Classes, §3 Verification Gate, and §5 Safety Rules apply to all work governed by this skill.

§1. Interview Trigger (MUST)

When the user asks for an interview in any form — "인터뷰하자", "인터뷰 모드", "interview",

"요구사항 정리", "스펙 정리해줘", "뭘 만들어야 하는지 정리", or any variation — you MUST

immediately run:

orchestrate I

Do NOT:

• Ask clarifying questions in IDLE mode instead of entering Interview
• Use the /interview slash command instead of orchestrate I
• Skip Interview and go straight to P for unclear requests
• Forget to run the command — actually execute it (via the host's orchestrate surface)

The /interview slash command is a user-facing shortcut that triggers the same transition.

As the orchestrating agent, always perform the orchestrate I transition directly.

Interview MUST settle three things before P (DEFAULT, INTERVIEW-CLASSIFY-01):

the work class (dev §0.0), the loop archetype (§11.4) — ask "does a verifier

define *done* for this work, or only *better*?" — and the unit residence

(UNIT-RESIDENCE-01, §3.1): which implementation unit (devlog/_plan/YYMMDD_slug/)

this work belongs to, an existing unit or a new one. This applies in HITL and goal

mode alike. An archetype discovered mid-loop — after candidates have already been

burned — is an Interview failure, not a Build failure.

Interview may widen, not only narrow (DEFAULT, INTERVIEW-DIVERGE-01): sometimes the

truest transfer of intent is "we don't know yet — test both." When a load-bearing

choice is genuinely uncertain and a spike is cheap, present options as

A · B · BOTH (parallel spike, select by evidence) instead of forcing one pick.

Generate the option list against typicality bias: the 2-3 options a model volunteers

are usually one attractor family — deliberately include at least one atypical

(low-probability) approach. A BOTH answer becomes an explore-and-select work-phase

(§11.4) with the comparison verifier declared in the loop-spec. Divergence seeded at

Interview is far cheaper than divergence discovered at a plateau.

Interview sub-modes (DEFAULT, INTERVIEW-CATALOG-01): pick by the user's knowledge level.

*Clarification* (existing) — the user already knows roughly what they want; questions structure

goals, constraints, success criteria. *Catalog Discovery* — the user names a vague domain but no

features ("사주 앱 만들고 싶어", "뭘 만들지 모르겠어"); see below. *Configurator* — compile the

selections into a spec. Heuristic: concrete feature/goal → Clarification; vague domain, no tech

specifics → Catalog Discovery; explicit user request → honor it.

Catalog Discovery — design/UX LEADS (DEFAULT, CATALOG-DESIGN-FIRST-01): the user cannot choose

from options they have never seen (the strong form of INTERVIEW-TEACH-01). Present the option

ontology in references/catalog-discovery.yaml. *Hard barrier:* iterate axis_order by ascending

stage; do NOT present a stage until every required entry of all earlier stages is answered.

Stage 1 is design, so all six design dials (mood, lightness, density, shape, typography, motion),

each required: true, MUST be answered before any Stage 2 (domain) or Stage 3 (feature/data/

security/ops/cost) question appears. This is the load-bearing invariant — backend is asked on top

of design, never before it.

• *Design methodology — Product-Personality Selection first* (design_methodology.primary, from

dev-uiux-design §1): for each design dial show its question_options (labels + trade-offs)

anchored on familiar products, then ask (present-then-ask, not confirm-what-they-said); refine

via the declared followups — Korean Request Translation (§3), Reference Discovery (§1 Step 6),

Design Read (§2).

• *Deriving backend questions* — two paths populate Stage 3 from earlier answers, never a flat

list: structural — a chosen Stage-2 domain entry's implies[] plus each Stage-3 entry's

derived_from (resolve implies[] transitively); keyword — scan the user's INITIAL

free-text request against Stage-3 auto_activate_rules (e.g. "사주"/"생년월일" pre-activates

security.pii_protection). Confirm high-impact activations.

• The catalog is a DATA STRUCTURE — do not invent entries not in it. The YAML encodes derivation

INPUTS + dependency metadata; this prose is the agent procedure that reads it. Automated runtime

filtering is out of scope (it would escalate to code).

Configurator: once selections are complete, compile them (with resolved implies[] chains)

into a spec — PRD sections, an MVP cut ordered by cost_class, a risk register of every

risk_class: high entry, and a PABCD plan seed carrying the work class + loop archetype from

INTERVIEW-CLASSIFY-01.

§2. How It Works

PABCD is a forward progression with Interview return.

IDLE ──→ P ──→ A ──→ B ──→ C ──→ D ──→ IDLE
         │      │      │      │      │
        STOP   STOP   STOP   auto   auto
        wait   wait   wait
         └──────┴──────┴──────┴──────┘
                      ↓
                 I (Interview)
              context preserved

You can return to Interview (I) from any phase to clarify requirements. Context (plan, audit status) is preserved.

To restart from scratch:

orchestrate reset   → returns to IDLE (context cleared)

Then re-enter with orchestrate P.

Transition commands:

orchestrate I       → enter Interview (from any state, context preserved)
orchestrate P       → enter Planning (from IDLE or I)
orchestrate A       → enter Plan Audit (from P only)
orchestrate B       → enter Build (from A only)
orchestrate C       → enter Check (from B only)
orchestrate D       → enter Done (from C only, returns to IDLE)
orchestrate reset   → return to IDLE (from any state)

§2.1 Evidence gate (forward transitions)

The four forward transitions (P→A, A→B, B→C, C→D) require an evidence attestation — a

real orchestrate command with an --attest JSON, not narration. The host runtime gates the

agent path (attest-required); a human's chat-submitted orchestrate X keeps the free pass.

P, A, and B also require user approval before advancing; C and D proceed automatically once

their work is done. In goal mode, §4 rule 4 replaces user approval with evidence-backed

checkpoints.

orchestrate A --attest '{"from":"P","to":"A","did":"<the concrete plan you wrote: files/surfaces + devlog path>"}'
orchestrate B --attest '{"from":"A","to":"B","did":"<who audited the plan + the verdict>"}'
orchestrate C --attest '{"from":"B","to":"C","did":"<what you built + who verified it>"}'
orchestrate D --attest '{"from":"C","to":"D","did":"<what you checked>","checkOutput":"<paste the real tsc/test tail>","exitCode":0}'

The gate is form-only: it checks that the block is well-formed and that did is a real

narrative (booleans/placeholders are rejected); C→D additionally requires a non-empty

checkOutput and, if present, exitCode:0. It does NOT cross-check the narrative against

runtime state — the goal is to force a deliberate, specific claim, not to defeat a malicious

agent.

Evidence pointers (DEFAULT, ATTEST-EVIDENCE-01): even though the gate checks form

only, write did with artifact pointers — the plan/devlog path, the changed-file list,

the verify command with its exit code — so a later reader (or a stronger future gate)

can re-check the claim against the repo instead of trusting the narrative. Saying "현재는 B입니다" without running the command does nothing: the state machine only

moves on the command.

Threat model = laziness, not malice. Accepted residuals (NOT bugs): a fabricated did, the

hidden --force emergency hatch, a pendingAttestation emitted in a prior turn, and an agent

that deliberately strips its own boss token to pose as a human. Closing the last one would risk

the legitimate human-via-CLI free pass, so it is out of scope unless the threat model expands.

2.2 Orchestration invariants

Four rules govern what a transition means. The gate above enforces none of them —

they are what makes the recorded cycle worth reading.

ORCH-MANDATE-01 (STRICT) — a narrated phase did not happen. A phase claim without

a persisted transition is invalid. Narrating phases — "now I'm in B", "the audit

passed" — without issuing them is the failure this rule exists to stop: nothing gated

anything, the log is empty, and the cycle is one ordinary turn wearing a PABCD

costume. §2.1 already says it for one edge; this generalizes it to entry and re-entry.

1. Read the real state before claiming one. Query the current phase, or read the

last recorded transition. Do not resume from memory.

1. Arm the mode explicitly — enter at orchestrate I or orchestrate P.
2. Advance every forward edge with an evidence-bearing attestation, carrying that

phase's real artifact (ORCH-ARTIFACT-01 below).

1. After D closes, read durable state — the plan record and the transition log —

to confirm what remains, then re-enter P for the next work-phase (LOOP-UNIT-CHAIN-01).

Work performed outside the state machine does not count as progress: re-enter and

attest it before building on it. Per the Runtime adapter note at the top of this file,

"persisted" scales with the host — a runtime with an FSM persists the transition

itself; a runtime without one persists it as the announced transition plus the

attestation JSON appended to the worklog. What is never acceptable is a transition

that exists only in the reply text.

ORCH-ARTIFACT-01 (DEFAULT) — advancing a phase is not doing it. Each forward edge

must carry its real artifact, not just an attestation string:

A phase whose artifact is absent is not done, regardless of adjacency. The gate is

form-only and cannot tell a real artifact from a plausible sentence; this rule is the

discipline the gate cannot enforce.

ATTEST-SHAPE-01 (STRICT) — name the edge. Every attestation carries from and

to naming the edge it advances, on every edge including ungated entry edges, and it

matters before did does: an attestation that does not say which transition it

belongs to is not an attestation, it is a sentence. A later reader reconstructing the

cycle from the log has only those two keys to order it by.

P→A additionally carries a plan-unit pointer — a real devlog/_plan/YYMMDD_slug/

holding numbered docs (UNIT-RESIDENCE-01). Where the runtime persists a work-phase

map, every gated edge also names the active work-phase.

Enforcement is runtime-dependent; the discipline is not. A host that parses the

attestation can refuse a malformed one, and a host keeping the state machine in

worklog notes can refuse nothing. Write the shape correctly either way — it is what

makes the log re-readable, not what makes a gate pass.

SESSION-IDENTITY-01 (STRICT) — use your own binding. When the runtime keys PABCD

state by a session or conversation id, use only the id your current session was bound

to at start. Never one read out of transcript history, never one inherited from a

parent, never one copied from a document.

A forked or resumed session replaying its parent's id does not share that state, it

corrupts it: two live cycles write the same record, and the parent's phase moves

without the parent doing anything. That is unrecoverable from inside either session,

which is why this is STRICT and not hygiene. The same binding governs every

state-writing surface — plan records, work-phase maps, evidence paths. If you cannot

determine your own binding, stop and ask.

§3. Phases

P — Plan

If the request has unclear scope or unspecified technology, return to Interview (orchestrate I). Within Interview:

• Present 2–3 options as <Name> — <plain explanation>, including one atypical

option; offer BOTH (parallel spike) when the choice is uncertain and a spike is

cheap (INTERVIEW-DIVERGE-01, §1)

• Teach the decision space, don't only narrow it (DEFAULT, INTERVIEW-TEACH-01):

intent transfer is bidirectional — a user cannot choose among options they have

never seen. Questions that merely confirm details the user already stated are the

weak form; the strong form maps the option landscape (research it first when

needed) with a trade-off explanation per option, at every load-bearing altitude:

stack, architecture, algorithm/strategy, data structure, evaluation method.

• Recommend one with project-specific reasoning
• Confirm once, then proceed

For broad changes or unfamiliar repositories, P phase MUST include:

• Compact tree of the current repository shape
• Detected repo conventions: docs, plans, architecture notes, source-of-truth logs, naming, tests
• Whether existing structure/, devlog/, docs/, plans/, or equivalent logs were read and will be reused
• Whether structure/ or devlog/ is proposed
• The SoT sync target (SOT-SYNC-01): which general source-of-truth doc

(structure/, architecture/INDEX docs) this unit will patch in C — or, if the

repo has none, the plan recommends creating one (dev-scaffolding §2.1)

Do not create new project-level source-of-truth folders during B unless approved in P or explicitly requested by the user.

For every planned conditional path (error handler, fallback, retry, cache, guard,

feature-gated branch, threshold behavior), the plan's accept criteria name its

activation scenario: how C will trigger the condition and what observable effect

proves the path ran (C-ACTIVATION-GROUNDING-01, §3 C).

Design phases before mapping them to PABCD. **Slice and order phases by

dependency/architecture structure (STRICT, PHASE-SPLIT-01)** — the orthodox

unlimited-time build order: foundations (schema, contracts, core data flow) → core

capabilities → integration → hardening/polish — so each phase consumes the verified

output of the previous one. DB/API/UI/test work inside a phase are subtasks, not

top-level phases by default, and every phase must still close with something

independently verifiable (build, tests, or a demonstrable surface). Effort-based

bucketing is FORBIDDEN: never split or order phases by estimated effort or payoff

speed — no "quick win vs heavy" buckets, no impact/effort matrices, no time-boxed

slices. Phase boundaries encode the system's build order, not the schedule. A simple

task can finish in one PABCD with several small phases; larger work splits into

multiple PABCD passes — one full P→A→B→C→D per work-phase, closed by D and

re-entered at P for the next work-phase (see Terminology / Rule 4).

Read project docs and dev skills first. Write the complete plan internally, then report it simply — like a developer reporting to the CEO.

Write a plan with two parts:

• Part 1: Easy explanation — what will be built, in non-developer terms.
• Part 2: Diff-level precision — exact file paths (NEW/MODIFY/DELETE), before/after diffs for MODIFY, complete content for NEW.

Loop-spec header (DEFAULT, C2+): open the plan with a compact loop-spec —

Loop archetype (§11.4, carried from Interview) · Trigger · Goal (user-visible

outcome) · Non-goals · Verifier (the command/gate that proves it, and **what it

measures**, not only pass/fail) · Stop condition · Memory artifact (devlog/worklog

path) · Expected terminal states (§11.2) · Escalation condition. Goal mode additionally

states the §11.5 resource scope. This makes the loop contract first-class instead of

scattered across the plan.

When the archetype is open-ended optimization, the loop-spec MUST additionally

include a divergence plan (descriptor axes · cell/archetype assignments · candidate

count · deterministic selection rule · telemetry schema), and **instrumentation

precedes candidates**: if the verifier only reports win/lose, B's first work item is

the telemetry, not a candidate. A scalar-only verifier plus discarded candidates is

the §10 plateau signature reproduced by design.

If anything is unclear, return to Interview (orchestrate I) — do NOT ask questions in P.

§3.1 Implementation-Unit Documents

Full documentation routine (P concretizes the docs, A audits them as a hard gate, D

archives to _fin/, plus the mainstream design-doc/RFC translation table):

dev-scaffolding/references/implementation-log.md.

Difflevel roadmap plan (STRICT, DIFFLEVEL-ROADMAP-01): for any multi-phase unit

(2+ work-phases), the FIRST P — or the dedicated design-only Phase-0 pass (§5) —

must deliver the entire roadmap concretized: 000_plan.md (objective, constraints,

dependency-ordered work-phase map) PLUS every phase's decade doc written to full

diff-level precision (exact paths, NEW/MODIFY/DELETE, before/after diffs) — each one

a copy-paste-executable PRD, not an outline. Scaffolding empty decade files to "fill

per cycle" does NOT satisfy this rule. Each later cycle's P starts from its

pre-written doc: re-verify it against the current codebase (stale check — earlier

phases may have moved lines, signatures, or files), amend the doc, then execute.

LOOP-CONTINUITY-01 (§10) applies on top.

Lexicographic separation (STRICT, LEXICO-SPLIT-01): every document in a unit

carries a numeric lexicographic prefix — bare semantic filenames (PLAN.md,

DIFF_PLAN.md, PHASES.md, RCA.md, an unnumbered mvpplan/-style folder) are an

A-phase FAIL, not a style nit. Research/spec material (00-range) and implementation

phase designs (decade ranges) are SEPARATE documents: no diffs inside a research

doc, no survey prose padding a phase doc — a document that mixes both fails the

audit.

Unit residence (STRICT, UNIT-RESIDENCE-01): every piece of development work

belongs to an implementation unit (devlog/_plan/YYMMDD_slug/). Ceremony scales

with class (§9); residence does not. C0-C1 fast-path work skips the PABCD ceremony

but MUST leave a numbered record doc in its owning unit — next free index in the

matching decade, e.g. 040_hotfix_dropdown_crash.md — stating what changed, why the

fast path applied (class call), and the verification evidence. No owning unit →

create a minimal unit folder holding only that record. Interview settles residence

before P (§1).

Devlog plan artifacts use decade-range numbering to separate concerns. **Prefixes are

three digits** (000_, 010_, 020_); do not mix two-digit and three-digit prefixes

inside one repository.

Rules:

• 000-range durable research is mandatory for C4, and for C3 only when state must persist

across turns/agents, public contract or architecture decisions need durable audit, or the

user/repo already uses devlog planning for that task; optional for C0-C2 and

low-persistence C3 (a response-level plan is enough — but the work still leaves its

numbered record in a unit, UNIT-RESIDENCE-01).

• Default: sequential within decade (000, 001, 002...).
• Overflow (>10 docs in a range): use sub-index (000_0_name.md, 000_1_name.md).
• NEVER use bare filenames like PLAN.md, DIFF_PLAN.md, PHASES.md, RCA.md.

Three digits rather than two because the range is what carries meaning, and two

digits make the tens column do double duty: 10 reads as both "decade 1" and "tenth

document". With three, 010 is unambiguously phase 1's first doc and 001 is

research's first. Units already written with two-digit prefixes stay as they are —

renaming historical documents breaks every inbound reference for no gain. The rule

governs new units.

§3.2 Plan-quality rules

Three authoring rules for P. Each is also an A blocker (§3 A, "Plan-rule checks"),

so failing one at P costs an audit round.

PLAN-VERIFIER-REAL-01 (DEFAULT). Before writing a verifier command into the

plan, run it. A command that does not exist — missing script, missing config —

or that does not read the change target is not a verifier. Record one line next to

each: its exit code, and whether it actually reads this unit's change target.

Prove the "reads the target" half with one of:

• the target path appears as a direct argument;
• a script or glob definition that includes it — quote the glob;
• a config include / files entry — quote it;
• a call chain into a sub-script that reads it — cite file:line.

If none holds, write "this command does not observe this change" and classify that

acceptance row as human review. Do not claim a gate protects it. Two traps

recur: a command that silently checks nothing when its config file is absent, and

naming a gate as the verifier for prose it never reads.

PLAN-FIELD-CHAIN-01 (DEFAULT). A plan that adds a field to a type, or a value to

an enum, must enumerate that value's whole chain in the file-change map:

creation (input type, builder, CLI arg) → serialization → deserialization (reviver,

unknown-value handling) → every consumer

When adding an enum value, search three things rather than one: the type name, the

field name, and every existing enum value. Then check non-comparison

consumption — destructuring and aliases, default branches, generic predicates, and

every function taking that type.

Give each of the four stages a path or an explicit N/A + reason; a blank is

indistinguishable from "did not check". The two failure shapes differ and both are

silent: a missed consumer makes the new value a ghost state that nothing counts,

while a missed creation path means the value can never be produced at all — so

any condition depending on it never arms. That second one is

C-ACTIVATION-GROUNDING-01's failure reached through the type system instead of

through control flow.

PLAN-BYPASS-NAMED-01 (DEFAULT). A plan that adds enforcement must also record

how to bypass it, in five fields:

1. Enforcement strength — on whatever tier vocabulary the repository uses. With

none, name the mechanism kind plainly: runtime gate, CI check, pre-commit hook, or

agent-followed prose.

1. Executing surface — which script, job, hook, or human actually runs it.
2. Known bypass path — the concrete way around it.
3. Residual risk — what stays reachable once the layer is in place.
4. Wording downgrade — whether the claim had to be weakened once (3) was known.

A bypassable layer is called an early warning, never enforcement.

final layer: none is an allowed answer: the point is to stop claiming enforcement

that does not exist, not to manufacture an unbypassable layer. If you claim no

bypass exists, give the evidence — that claim is usually wrong.

PLAN-TRACK-01 (DEFAULT). When the runtime offers a live plan or todo surface,

mirror the plan's work items into it at P and keep the statuses current through B.

That surface is the visibility channel, and often the only view the user gets

between turns. It is not the plan: the diff-level document stays the single source of

truth, and ticking an item is never a substitute for the phase's artifact

(ORCH-ARTIFACT-01). A runtime with no such surface loses nothing here.

Present to the user:

1. Part 1 summary (≤5 sentences) + diagram + devlog file path
2. "Is there any business logic I must not decide alone?" and "Is this direction correct?"

⛔ Present the plan. Revise on feedback.

When user approves, advance with the canonical P→A attestation form in §2.1.

A — Plan Audit

Spawn a worker to audit the plan (not code). The worker verifies:

• All file paths and imports in the plan actually exist
• Function signatures match real code
• No integration risks
• Existing source-of-truth docs/logs were read when present
• No new structure/, devlog/, docs, or AGENTS files are introduced without user approval
• New JS/TS files follow TypeScript preference rules unless the plan states why JS is required
• New TypeScript is strict-compatible or limitations are stated
• New devlog phase documents use the numbered lexicographic filename convention;

bare-named or research/implementation-mixed docs are a FAIL (LEXICO-SPLIT-01).

• Multi-phase units satisfy DIFFLEVEL-ROADMAP-01: every roadmap phase has a

diff-level decade doc (no outline-only or missing phases), and the phase map is

dependency-ordered, not effort-bucketed (PHASE-SPLIT-01).

• For each conditional path the plan adds: the trigger is reachable at all from

states the system actually visits (callers exist, preconditions can co-occur,

upstream code does not consume the trigger first), and the plan names its

activation scenario (C-ACTIVATION-GROUNDING-01). An unreachable-by-construction

branch is a plan blocker, not a C-phase discovery.

Plan-rule checks. The reviewer additionally verifies each of these, and any one

failing is a blocker: (a) every verifier command the plan names actually exists AND

reads the change target — the reviewer RUNS it rather than trusting the plan

(PLAN-VERIFIER-REAL-01); (b) each new field or enum value has its full

creation → serialization → deserialization → consumer chain enumerated, with

N/A + reason where a stage does not apply (PLAN-FIELD-CHAIN-01); (c) when several

documents reference a shared type, the field NAMES match, not just the concept;

(d) each document's header dependency declaration matches the types its body

actually uses; (e) any plan adding enforcement records the five bypass fields and

either names the final enforcement layer or states none

(PLAN-BYPASS-NAMED-01). All three plan rules are defined in §3.2.

Instruct the reviewer to end with a normalized final line —

VERDICT: PASS | GO-WITH-FIXES (blockers=N) | FAIL — followed by numbered

blockers. No code changes.

Audit loop (STRICT, AUDIT-LOOP-01). A is a loop — audit → synthesize →

amend plan → re-audit — not a single round. Exit A→B only when the main agent

judges the round:

• pass — the reviewer approved; or
• near-pass — every High/Critical blocker was folded into the plan as a

concrete amendment or explicitly rebutted with recorded rationale, and only

non-blocking residuals remain. GO-WITH-FIXES; 2 blockers folded back qualifies.

A FAIL round never exits. Apply REVIEW-SYNTHESIS-01 (§11.3), amend the plan,

and re-audit with the same reviewer so it keeps the context it already built

(DISPATCH-ACTOR-01, §7.2). LOOP-REPAIR-01 bounds the loop: after 3 failed rounds

return to P with a changed plan, or to Interview when human clarification is what

is actually missing.

Three details in that rule are load-bearing and easy to lose:

• The main agent is the judge, not a string parser. near-pass is a judgment

about whether the blockers were really addressed. A reviewer's closing line is

evidence for that judgment, not a substitute for it — and a pasted verdict whose

final line says FAIL does not become a pass because the summary claims one.

• Same reviewer on re-audit, fresh reviewer for the final adversarial pass. Reuse

preserves context across rounds; independence matters when the reviewer has

already shaped the fix. Those pull in opposite directions, which is why the rule

names both rather than one.

• The loop is bounded because an unbounded audit loop is a stall, not rigor.

Three failed rounds means the plan is wrong in a way re-auditing cannot find.

Verification is not pinned to A (LEAN-REVIEW-01, DEFAULT). Dispatch review lanes

wherever they help — plan audit at A, implementation review at B, check

verification at C — instead of treating A as the one phase that owns review. A

review lane costs one dispatch and returns evidence you can paste into the next

attestation.

Where a runtime records reviewer verdicts, a recorded verdict is binding: it

cannot be contradicted by your own attestation, spent across a re-plan, or spent on

a plan whose files changed after approval. Where the runtime records nothing, the

same discipline is yours to keep.

What must not be built is a review gate whose failure mode traps the cycle. Recorded

2026-08-18 in the codexclaw lineage: A→B once required a verdict only an automatic

observer could write, so every reason that observer failed to fire — a matcher that

missed the runtime's role vocabulary, a reviewer whose closing lines did not parse,

a reinstall that moved the plugin root under a live session — left the cycle in a

phase it could never leave, and the only escape was hand-feeding the gate its own

payload. A gate whose normal recovery is forging its own input is not a gate.

Apply that when designing any gate here: if the recovery path is "fabricate the

evidence the gate wanted", the gate is worse than none.

Output worker JSON for the audit. Review results when they come back.

• If FAIL → synthesize (§11.3) → amend the plan → re-audit with the same reviewer
• If PASS or near-pass → report results, with the residual disposition, to the user

⛔ Wait for user approval. When approved, advance with the canonical A→B attestation form in §2.1.

B — Build

Implement the plan. You write code by default and own every verdict; a worker may

write when its slice passes DISPATCH-ECONOMY-01 (§7.1) and the dispatch is

explicitly write-capable with a bounded scope (see Pitfalls). Workers without that

grant are read-only verifiers.

Do not create structure/ or devlog/ unless approved in P or explicitly requested by the user.

After implementing, output worker JSON for verification. The worker checks your code exists and integrates cleanly.

• If NEEDS_FIX → you fix the issues → re-verify (repair discipline and failure

thresholds: §11.3)

• If DONE → report results to the user

⛔ Wait for user approval. When approved, advance with the canonical B→C attestation form in §2.1.

C — Check

Final sanity check:

1. Verify all files saved and consistent
2. Run npx tsc --noEmit (if TypeScript project)
3. SoT sync (DEFAULT, SOT-SYNC-01): locate the repo's general source-of-truth

docs (structure/, architecture/INDEX docs) — found in P, patched HERE so SoT

and code never diverge silently; if the repo has none, recommend creating one

(dev-scaffolding §2.1) in the D summary

1. Report completion summary

DEFAULT (C-RENDER-GROUNDING-01): when the work-phase produces an artifact whose

correctness only shows when run or rendered (HTML page, SVG, game, UI, chart,

animation, script with observable visual/interactive output), C MUST include a

render-grounding loop before C→D: (1) RUN it in its natural execution

environment — headless-browser screenshot for web, SVG→PNG render, execute scripts,

drive games/wizards until the first interactive state change; (2) OBSERVE the

output — actually read the screenshot/console back; a produced-but-unread screenshot

is not observation; (3) FIX what the observation reveals, then re-run and

re-observe. Trigger on artifact type + change ("could this look or behave wrong in a

way that only shows when it runs?"), never on task depth alone. Stop after ONE clean

observation; re-render only after a change. Well-formed (tsc/lint/parse passing) is

not correct — static gates do not satisfy this rule. Defaults (HEURISTIC — deviate

with a stated reason): 1280x720 viewport; stateful artifacts driven until the first

interactive state change. Evidence scales with class: C2-C3 record the observation

in the attestation narrative; C4 (STRICT) additionally persists the screenshot to

the devlog. The render observation is valid checkOutput evidence for C→D and the

did must reference it. Excluded: pure logic/config/prose covered by its own test

suite. (Adopted 2026-07-05 from fablize verification-grounding; devlog

260705_pabcd_render_grounding.)

DEFAULT (C-ACTIVATION-GROUNDING-01): the conditional-path sibling of render

grounding. When the work-phase adds or changes a code path that only runs under a

trigger condition absent from the default/happy path — error handlers, fallbacks,

retries, caches, guards, feature-gated branches, mode switches, migration handlers,

threshold behaviors — C MUST include activation evidence before C→D: (1) TRIGGER

the condition for real (a test or scenario that drives it, a fixture crossing the

threshold, fault injection); (2) OBSERVE the new path execute with its intended

effect (hit assertion, log/debug line, counter, or trace — read back, not just

produced); (3) FIX and re-trigger if the observation contradicts intent. "All

tests green" does not satisfy this rule when no test drives the trigger; a branch

nobody can show firing is unverified regardless of suite status. Two loud signals

mandate this check retroactively: a change whose observable output is byte-identical

to baseline everywhere (presume the path is dead; instrument before concluding "no

effect"), and a close-out claim of "handled/defended/falls back" with no fired-path

artifact behind it. The activation observation is valid checkOutput evidence for

C→D and the did must reference it. Excluded: unconditional straight-line changes

fully exercised by existing coverage. P names the activation scenario for each such

path in the accept criteria; the A reviewer checks trigger reachability (callers

exist, preconditions can co-occur, upstream code does not consume the trigger

first) — an unreachable-by-construction branch is a plan blocker, not a C-phase

discovery. For score-optimization loops, LOOP-MECHANISM-PROOF-01 /

LOOP-RESIDUAL-TRACE-01 (§10) apply on top. (Adopted 2026-07-06 from a contest-bot

incident: an endgame branch shipped inside a passing combo while structurally

unreachable — its solo ablation was baseline-exact and no gate asked "did it

fire?"; codexclaw devlog 260706_loop_mechanism_research.)

Long external gates (CI runs, deploys): do not block the turn polling — register a

runtime-owned background task/watcher and end the turn (the runtime re-invokes you on

completion and PABCD state persists across turns); if your runtime has no background

tasks, poll at a sensible interval. Local tsc/tests stay blocking.

When done, advance with the canonical C→D attestation form in §2.1; C→D uniquely requires a pasted check tail.

D — Done

Summarize the entire flow:

• What was planned (P), audited (A), built (B), checked (C)
• List of files changed
• Any follow-up items

Pessimistic close-out (DEFAULT, LOOP-PESSIMIST-01): for loop/multi-pass work, D

also records the negative delta: what did NOT improve, which hypothesis died this

cycle, and one sentence answering "what evidence would show the current direction is

wrong?" — the next P quotes this (§10 LOOP-CONTINUITY-01). Treat D→IDLE→P as a

context boundary / bias flush: the next cycle resumes from disk artifacts

(worklog, devlog, archive, death log), not from the transcript's accumulated

assumptions.

State returns to IDLE automatically.

Project root configuration is persistent. D completion resets the PABCD state, but it

does not clear the configured project root; unset it only when the

user explicitly asks to unset the project root.

§4. Rules

1. One phase per response (the gate-and-wait turn boundary; canonical approval rule in §2.1).

Goal-mode exception: when a goal is active this does not permit ending a turn before D

when more PABCD-phases remain in the current cycle — keep going P→A→B→C→D, then close D

and re-enter P for the next work-phase.

1. Sequence: P → A → B → C → D. Use orchestrate reset to restart.
2. Workers verify (read-only) by default; write-capable dispatch follows §7.1

DISPATCH-ECONOMY-01. Verdicts stay with you in B.

1. Goal-mode precedence: when a jaw goal is active (dev §0.4), use §2.1 with

evidence-backed checkpoints (your runtime's goal-checkpoint command, or a worklog checkpoint entry) instead of user approval. Phase order,

audit conditions, and verification intensity are unchanged.

Gate quick-reference (strict vs goal mode):

§5. Terminology: work-phase vs PABCD-phase

• work-phase: one outcome slice of a larger goal (e.g. "Phase 3: Management API"). A

multi-phase goal has several work-phases done in sequence.

• PABCD-phase: one of the letters P/A/B/C/D inside a single orchestration cycle.

Work-phases need not be slices of one feature: successive cycles in the SAME session

may target completely different features or plans under the same goal

(LOOP-UNIT-CHAIN-01). "This needs its own PABCD" is a plan statement — append the unit

to the slice map/goalplan (P-phase amendment) and run it as the next cycle, never a

reason to end the goal or defer to a new session.

Invariant: one work-phase = one full PABCD cycle. Run P→A→B→C→D for a work-phase, close

D (state → IDLE), then run orchestrate P to start the next work-phase. Do NOT run

B for several work-phases back-to-back, and do NOT commit a work-phase out of B without

passing C and D. Depth scales per work-phase class (see "PABCD Depth by Work Class"), but

the P→D sequence is never skipped for a work-phase.

Loop / multi-pass tasks: a "loop"/"루프" request (or work too large for one cycle) runs

as MULTIPLE PABCD passes — one per work-phase. Pre-plan the full slice map and WRITE

all per-phase decade docs (10_phase1, 20_phase2, ...) to diff-level up front

(DIFFLEVEL-ROADMAP-01, §3.1) — scaffolding empty files is not pre-planning. Each

later cycle's P re-verifies its pre-written doc against the current codebase and

amends it before building.

Docs-first multi-cycle entry (LOOP-DOCS-FIRST-01, DEFAULT). The first pass is a

design-only PABCD pass (Phase 0) — a code-free whole-system design and documentation

cycle that produces exactly this diff-level roadmap before the first implementation

work-phase. This used to read "MAY"; it is the default for any loop of 2+ work-phases,

and mandatory when the loop runs unattended.

A loop is a chain of PABCD cycles, and a chain is only as disciplined as the documents

each cycle re-reads at P. Memory lives on disk, not in the transcript — so a loop

spanning 2+ work-phases buys its memory first.

1. Register and document in one motion. Arm the work-phase map (a skeleton is

fine) AND run the first work-phase as a docs-only cycle. Its deliverable is the

devlog unit: 000-009 research plus EVERY implementation phase's decade doc

(010, 020, 030, … with sub-docs like 021 where a phase needs finer grain)

at full diff-level precision (DIFFLEVEL-ROADMAP-01).

1. The roadmap cycle's D is the roadmap lock. Closing it finalizes the map: phases

are refined to map 1:1 onto the decade docs. The initial registration is a

skeleton; the lock is the docs-only D, and the map stays APPEND-friendly afterwards.

1. Implementation starts at the NEXT cycle. Each later work-phase consumes exactly

one decade doc as one full cycle: its P re-verifies the pre-written doc against the

current tree, amends it, then executes. Never implement two decade docs in one B.

1. Docs-only means docs-only. Allowed: research notes, inventories, design docs,

repro and state snapshots, the decade docs themselves. Not allowed: production code

patches, deploy actions, or completion claims for implementation criteria.

Exemptions: a loop that genuinely fits one work-phase skips the docs-only cycle, and

C0/C1 fast-path work is untouched. If multi-cycle scope is discovered mid-loop the

docs-first debt comes due — the next P is the roadmap amendment that writes the missing

decade docs before any further implementation cycle.

The slice map is APPEND-friendly (LOOP-UNIT-CHAIN-01): an independent unit discovered

mid-loop — including a feature unrelated to the current slice — becomes a NEW

work-phase appended to the map via a P-phase amendment, then runs as the next cycle in

the same session.

Faithful execution (anti-skip): do the real work of each PABCD-phase — P writes the

real diff-level plan, A really dispatches the audit, B really implements AND verifies, C

really runs tsc/tests/scrutiny, D really summarizes with evidence. Advancing the state is

NOT the same as doing the phase; never rubber-stamp a phase to move on.

§6. Repository Root Contract

Before writing a PABCD plan or dispatching a subagent, determine the actual

working repository root with pwd -P from the target repo.

If the host runtime injects the project root (e.g. Codex cwd, or a Project root

header), use that value directly. Otherwise resolve via pwd -P from the target repo.

Setting the project root prevents confusion between the agent's state directory and the

actual codebase.

Every A/B phase worker-dispatch task body MUST begin with:

Project root: /absolute/path/to/current/repo

Rules:

• Project root must be the current working repository, not the agent home directory.
• Never let workers infer the repo root from the agent home directory, process.cwd(), or a worker temp directory.
• Resolve all relative repo paths (src/..., tests/..., structure/..., skills_ref/...) against Project root.
• If Project root is unknown, STOP and ask before dispatching.

§6.1 Structure map before deep search (repo-map capability)

When entering unfamiliar C2+ territory, prefer a ranked structure map over blind

grep-walking: run the runtime's map command (cxc map / cli-jaw map / jwc map,

or the runtime's equivalent) on the target dir to see which files own which symbols,

then narrow with grep/ast-grep. On-demand only — never a whole-repo preload. Full

contract + per-harness port sites: references/repo-map-capability.md.

§7. Shared Plan (auto-injected)

When P completes, the plan is saved to the worklog ## Plan section (single source of truth) and kept in ctx.plan. No project-root file is created.

• In A and B, inject the full plan body at the top of every worker-dispatch task under ## Approved Plan (FSM runtimes may auto-inject).
• Workers never read a plan file. Your task body should contain only the actual audit/verify instruction — the plan is prepended for you.
• Example dispatch task: "Project root: /absolute/path/to/current/repo

Audit: verify the imports in ..."` — no "read the plan" line needed.

§7.1 Parallel dispatch: isolation, specialists, decorrelated review

• DEFAULT (DISPATCH-ISOLATION-01): Parallel workers in the same work-phase are

context-isolated by default: each dispatch names an explicit access list — which

prior outputs (paths or pasted excerpts) this worker may read — and nothing else

from peer lanes is visible. Never expose one lane's in-progress trajectory or

draft output to another outside the access list: the first finished trajectory

otherwise steers every later lane into redundant agreement (orchestration

collapse) and the parallelism buys nothing. Durable cross-cycle artifacts

(worklog plan, devlog, D summaries) stay shared. Widening an access list is a

stated decision in the dispatch task, not a default.

• HEURISTIC (SPECIALIST-CRUX-01): When P or A identifies a narrow crux outside

the main line's domain — a derivation, a protocol subtlety, a domain constant, a

security property — dispatch a specialist lane to re-derive that crux from first

principles before merging the work that depends on it. The specialist's return

names its assumptions, the derivation or trace, and the exact decision its

verdict changes.

• HEURISTIC (REVIEW-DECORRELATE-01): When the runtime offers more than one

model family, run the A reviewer — and any §11.3 clean-slate re-examination after

repeated failed repairs — on a different model family than the one that produced

the plan or build. Same-family reviewers share blind spots; decorrelating the

reviewer is the cheapest independence upgrade available.

• DEFAULT (DISPATCH-ECONOMY-01): Decide delegation on three axes —

specifiability (can the task packet state its inputs, outputs, and decision

boundary completely?), verifiability (can the return be checked mechanically:

anchors, figures, reproduction commands?), and judgment ownership

(collapse/crux VERDICTS stay with the orchestrating session; re-derivation,

standardized implementation, research, and audits are dispatchable). A slice

that fails any axis stays with the orchestrator. Complexity or importance is

NOT an axis: a hard derivation that passes all three axes is dispatchable

(SPECIALIST-CRUX-01 above), and a trivial slice whose packet cannot state its

decision boundary is not. Output side: every return receives an

accept/reject/merge disposition with a one-line rationale BEFORE the next

wave is dispatched (wave-granular allowed). Returns must carry verbatim

anchors — file:line quotes, exact figures, URLs — a paraphrase-only summary

creates correlated blind spots between orchestrator and reviewer. Prefer

batch-waves with a single synthesis over drip-feed spawning. Speculative

dispatch of a later phase's work is default-OFF; the one exception is

phase-invariant EXTERNAL research (reads no repo state), quarantined as

candidate — unverified and discarded by default on plan amendment.

(Adopted 2026-07-07 from the Sakana Fugu learned-orchestrator report,

arXiv:2606.21228 — its trained orchestrators converged on intra-workflow isolation

with explicit access lists, crux-matched aggregation, cross-model builder/verifier

alternation, and specialist first-principles re-derivation; devlog

260707_fugu_orchestration_adoption. DISPATCH-ECONOMY-01 adopted 2026-07-11 from

an adversarial fork-debate + Tier-2 arXiv claim ledger — 10 papers, evidence

grades recorded; codexclaw devlog 260711_dispatch_economy_docs_site. jawcode /

cli-jaw ports pending.)

§7.2 Dispatch packet, lane, and lifecycle

§7.1 decides whether to dispatch. These decide how, and each one names a

failure that looks like something else when you hit it.

DISPATCH-TASK-01 (DEFAULT) — the packet. Every dispatch carries a structured

packet with these sections, in this order:

TASK · SCOPE · MUST DO · MUST NOT · PROOF · RETURN FORMAT · decision boundary

• Write scopes must be disjoint across concurrent lanes, with explicit read

bounds. Two lanes that can touch one file are one lane.

• The plan travels with the dispatch. Pass the concrete plan and scope; never

let a worker reconstruct the plan from a thin task description (§8 Context Drift).

• Name every required skill explicitly — nothing infers an omitted one.
• **Workers return evidence and unresolved judgments; the dispatching session

decides and integrates.** Judgment ownership never delegates

(DISPATCH-ECONOMY-01).

DISPATCH-AGENT-TYPE-01 (DEFAULT) — the lane. The read-only/write-capable split

is a dispatch-time classification, not a description of what the worker happens

to do:

• read-only lane — plan audit, research, review, verification. The default, and

what the A gate, the B review lane, and the C verification lane all use.

• write-capable lane — a deliberate implementation slice only, with a bounded

write scope named in the packet (§8).

Mismatching the lane to the packet is a real failure with a misleading symptom. A

read-only packet sent down a write-capable lane produces a worker held to

obligations it has no permission to satisfy, and what you observe is a worker

repeating the same answer against the same directive. When you see that, check the

lane before rewriting the prompt — it is almost always the lane.

LEAF-TOPOLOGY-01 (DEFAULT) — the topology. A dispatched worker is a leaf: it

does its scoped task and returns, without standing up its own orchestration layer.

Recursion is a deliberate per-dispatch grant, never a default. A runtime whose

workers may fan out internally should say so explicitly rather than leaving it

ambiguous, because an unplanned second layer makes write scopes unprovable.

DISPATCH-ACTOR-01 (DEFAULT) — reuse across rounds. Follow-up rounds in the same

role and work context reuse the existing worker rather than spawning fresh. The

point is context preservation: the reviewer or builder keeps what it already read,

so round two argues about the change instead of re-deriving the baseline.

If the runtime distinguishes "send more work" from "deliver context only", know

which is which — using the context-only channel to request work produces a worker

that never runs and a caller that waits forever.

Do not justify reuse with "same provider, so the prompt cache is warm". That

was tested and rejected in the lineage this rule comes from. Reuse is about

context, not cost.

Carve-out. The final adversarial pass at C — and any reviewer that has already

shaped the fix through synthesis rounds — gets a fresh reviewer, or a direct

independent file:line audit. Anchoring must never grade its own influence. Same

independence argument as REVIEW-DECORRELATE-01 (§7.1), applied across rounds instead

of across model families.

DISPATCH-RETIRE-01 (DEFAULT) — the exception to reuse. A worker that failed —

error, timeout, unresponsive, nonsense output — is retired, not nursed.

• At most ONE retry against the same worker, then abandon it and spawn fresh

with the failure folded into the new packet.

• A worker that has produced nothing after roughly three wait cycles is a failed

dispatch, and that retirement consumes the one retry. Silence does not earn a

second chance on top of the silence.

• Packet-failure reclaim. When a second, distinct worker also fails the SAME

packet, stop blaming workers: two independent failures on one packet are evidence

the packet failed DISPATCH-ECONOMY-01's specifiability bar. The dispatching

session reclaims that slice and does the work directly rather than dispatching a

third copy.

Both lifecycle rules are agent-followed doctrine, not runtime gates — nothing

watches worker lifecycles for you.

§8. Pitfalls

Delegation Trap

• B phase: Boss writes by default. Workers are READ-ONLY verifiers unless granted otherwise.
• 💡 To let a worker write, the slice must pass DISPATCH-ECONOMY-01 (§7.1: specifiable, verifiable, no verdict ownership) AND the dispatch must be explicitly write-capable with a bounded scope (e.g. a --mutable-style flag or write-capable subagent type).
• ⛔ Without --mutable: "implement the feature", "write the code", "create the file" are forbidden.
• ✅ Always allowed: "verify src/x.ts compiles", "check integration of Y", "report DONE or NEEDS_FIX".

Context Drift

• If a worker says *"I'll proceed based on my assumption of the plan"* → STOP. Verify the dispatch went through the orchestration path that injects the plan (or re-send with the plan prepended).
• Never let workers reconstruct the plan from a short task description.

Phase Skip

• A (audit) is mandatory for C4, and for C3 when public contract, architecture,

persistence, cross-agent, or cross-session risk exists; use a micro-audit for C2 and

optional audit for C0-C1 (see dev §0.0 for classes).

• B verification is never "skippable". Untested code is not "done" — but verification

intensity scales with the work class (PABCD-AUTO-01).

• The orchestrator does not enforce these gates today — YOU do.

§9. PABCD Depth by Work Class

Render-artifact work-phases add C-RENDER-GROUNDING-01 (§3 C) to the Check column at

C2+; C4 escalates its evidence to STRICT (persisted screenshot).

§10. Optimization-Loop Meta-Rules (plateau discipline)

These rules apply to score/objective-maximization loops and repeated PABCD passes where

candidates are being discarded by evidence gates. Gate validity itself is owned by

dev-testing §9.5 Limited-Oracle / Score-Objective Evaluation.

• DEFAULT (LOOP-PHASE-DEATH-01): Track each discarded candidate's killing PABCD-phase

(P/A/B/C/D) and change class: parameter-tweak, branch-toggle, state-space redesign, or

evaluator change. After N consecutive same-phase, same-class deaths (starting value

N=3 — HEURISTIC, tune per domain), the next work-phase MUST target the killing

mechanism itself, usually the evaluation gate, not another candidate of that class.

Repeated D-evidence collapses mean the gate, not the candidates, is probably the

bottleneck.

• STRICT (LOOP-CONTINUITY-01): P must begin by quoting the previous cycle's D

conclusions and next-direction. A new candidate that contradicts the recorded

next-direction requires an explicit stated reason.

• DEFAULT (LOOP-CANDIDATE-ANCHOR-01): For score/objective-maximization work, source

divergence candidates from domain-state evidence such as logs, trajectories, and

opponent/instance analysis, not only from existing code parameters. If every candidate

is a threshold, guard, or suppression tweak on existing levers, treat that as

parameter-space anchoring and regenerate from the state space.

• HEURISTIC (LOOP-INSTANCE-CHECK-01): Check whether evaluation instances are fixed and

enumerable: fixed opponents, fixed test maps, fixed graders. If yes, per-instance

specialization such as fingerprint plus playbook is a legitimate, evaluable widening

move; consider it before generic-strategy tweaks.

• DEFAULT (LOOP-MECHANISM-PROOF-01): A candidate whose value is a new

branch/mechanism must carry activation evidence from the instances it targets — a

counter, debug line, or trace showing the branch actually FIRED — before adoption.

Aggregate score movement is not activation proof: in a multi-feature combo, a dead

mechanism hides behind the other features' gains. The loud special case is a

zero-delta ablation: if the single-feature candidate scores exactly baseline on the

instances it was built to flip, presume the mechanism never ran and instrument

before combining or discarding.

• DEFAULT (LOOP-RESIDUAL-TRACE-01): A residual failure carried through D needs a

mechanism-level explanation (which branches fired, which did not, and why the

outcome followed) or the explicit label unexplained. A plausible story about the

opponent/environment is not an explanation unless the trace confirms our own

relevant mechanism armed and acted. The pessimistic D record quotes this trace,

not the story.

• HEURISTIC (LOOP-PEER-CONTRAST-01): When an external artifact — a peer's bot, a

reference solution, a competitor run — achieves the objective on the same fixed

instance we fail, the next generation's first analysis deliverable is a behavioral

diff of the two traces (what they did that we did not), before any new candidate.

This is the cheapest capability-gap detector available and outranks another round

of parameter candidates (LOOP-CANDIDATE-ANCHOR-01).

• HEURISTIC (LOOP-FANOUT-TIMING-01): Spend parallel fan-out late, not early.

While coarse levers still move the metric, stay single-track (N=1); once coarse

levers stabilize or plateau and the search shifts to fine-grained candidates,

parallel candidate lanes and specialist re-derivation start paying for their

cost. Fan-out also buys outcome consistency (cross-run variance reduction), not

only peak score — weigh both when deciding. (Adopted 2026-07-07 from Sakana

Fugu, arXiv:2606.21228: orchestration gains on a 123-experiment autonomous

training loop concentrated after mid-run, once coarse configuration search gave

way to fine optimizer/schedule tuning.)

Grounding: observed in a 14-discard optimization plateau where a prefix-only replay gate

and a hard draw-protection invariant locked a 3.5/8 score; the mechanism-proof trio was

grounded 2026-07-06 by a second incident in the same domain (a dead endgame branch

adopted inside a passing combo; codexclaw devlog 260706_loop_mechanism_research).

Two-incident induction now — keep the per-domain death log and revise when a new

domain's evidence contradicts these rules.

§11. Loop-Engineering Alignment

PABCD is the macro loop; loop engineering supplies the micro-loop rules inside each

phase. Full rule text: references/loop-engineering.md — read it before running

any loop/multi-pass or optimization work-phase. Summary index (IDs are canonical):

• §11.1 Loop values (DEFAULT) — feedback must change the next action; the verifier

outranks the prompt; memory lives on disk; budget exhaustion ≠ done; context pressure

≠ budget exhaustion (checkpoint durable state and continue — never close a goal over

"context is getting large"); Interview yields a testable loop-spec, not solved intent.

• §11.2 Terminal states (DEFAULT) — D names the real report state: DONE · NOOP ·

BLOCKED · UNSAFE · NEEDS_HUMAN · BUDGET_EXHAUSTED (adopt best-so-far and say

so). Report states, not FSM states.

• §11.3 Repair-loop discipline (LOOP-REPAIR-01 / LOOP-DOOM-01) — repair only the

failing delta; 2 same-failure repairs → root-cause mode; 3 → replan or Interview;

3 same-phase attestation failures → forced Interview return.

• §11.4 Loop archetype (LOOP-ARCHETYPE-01) — spec-satisfaction → repair loop;

open-ended optimization → explore-and-select (diverse candidates, same-instance

evaluation, best-so-far ledger, plateau/budget stop → BUDGET_EXHAUSTED). Workflow

proposal: backlog/260702_explore_select_research.md (LOOP-EXPLORE-SELECT-01).

• §11.4a Analysis before regeneration (LOOP-REANALYZE-01) — every generation opens

with an analysis deliverable: updated opponent/problem model + capability-gap

hypotheses (a gap may expand the allowed surface via P amendment). Regenerating

straight from scores is a repair loop in an explore costume.

• §11.5 Unattended-loop resource policy (DEFAULT) — goal-mode loop-specs state

tool/credential scope, token/cost budget, and a wall-clock bound; unstated scope on

C4 surfaces is an ESCALATE-class omission.

• §11.6 Continuation doctrine (DEFAULT, LOOP-CONTINUE-01): the loop keeps the

turn alive; the agent decides what "remaining work" means. Rules: (a) do not

redefine the objective downward — success criteria from P/goalplan are the bar;

(b) audit completion against current repo state, not memory — a remembered "it

passed" is not evidence; (c) read durable state first (worklog, goalplan,

ledger.jsonl) before planning the next pass; (d) IDLE is not the end while work

remains — if unmet criteria remain under an active goal, start the next work-phase

at P; (e) work-phases chain HETEROGENEOUS units in one session

(LOOP-UNIT-CHAIN-01) — an independent feature discovered mid-loop is appended to

the plan and started at P, not deferred to a new session or used to justify

closing the goal.

• §11.7 Divergence/collapse (DEFAULT): PABCD is convergence-first by default.

Divergence is a mode for the open-ended-optimization archetype, not a standing

habit. Entry: deliberate in HITL (I/P when intent is open, approach uncertain, or

user asks to compare), or automatically prompted in goal mode when a maximize

objective records non-improving metrics (plateau detection). When ON: record at

least two candidates with search provenance; collapse early at P for spec work

(pass/fail), late at D for metric work (local metric can deceive). After the

plateau breaks or a candidate is kept/discarded, turn it off and return to N=1.

Divergence never bypasses human confirmation in HITL; in goal mode the hook can

only keep the turn alive and tell the agent to re-plan.

• §11.8 Divergence cost tiers (DEFAULT, DIVERGE-TIER-01): divergence defaults to

conceptual candidates. Tier 0 inline brainstorm (no dispatch); Tier 1 conceptual

candidate docs — 2-3 parallel candidate lanes, one-page docs each (research

read-only, doc write scoped to the plan archive), mandatory front-matter

(assumptions/risks/kill-criteria/evidence-needed) plus per-candidate provenance

(§11.7 search provenance, or a repo-evidence path for codebase-grounded

candidates — an explicit §11.8 amendment); the collapse owner critiques directly,

cross-critique is not a gate; Tier 2 implementation spike only when the choice is

load-bearing AND candidates genuinely conflict AND judgment needs running code

(0-1 per unit, recorded P-level decision). Tier inflation and tier deflation are

both violations.

• §11.9 Crux-matched collapse (DEFAULT, COLLAPSE-AGGREGATOR-01): collapse and

synthesis ownership follows the disputed crux. When parallel candidates disagree,

the synthesis verdict comes from whoever is strongest on the domain of the

disagreement — dispatch a crux-matched aggregator lane when the collapse owner is

not. A fixed aggregator caps the exercise at that aggregator's own ceiling for

the domain. The collapse record names each candidate's partial correctness, each

candidate's failure mode, and why the winner's evidence resolves the crux.

Full rules: references/loop-engineering.md.