Jaw Dev Pabcd

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

C0/C1 work: 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:

cli-jaw orchestrate I

Do NOT ask clarifying questions in IDLE instead of entering Interview, skip Interview for unclear requests, or merely narrate — actually execute the command in Bash. /interview is the user-facing shortcut; the Boss agent always runs the command directly.

• 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 (jaw-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 jaw-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:

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). Applies in HITL and goal mode alike; an archetype discovered mid-loop, after candidates were burned, is an Interview 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 jaw-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

IDLE ──→ P ──→ A ──→ B ──→ C ──→ D ──→ IDLE
         │      │      │      │      │
        STOP   STOP   STOP   auto   auto
        wait   wait   wait
         └──────┴──── I (Interview) — reachable from any phase, context preserved

Transitions (each phase accepts only its predecessor):
cli-jaw orchestrate I|P|A|B|C|D   → I from any state (context preserved); P from IDLE/I;
                                    A←P, B←A, C←B, D←C (D returns to IDLE)
cli-jaw orchestrate reset         → IDLE from any state (context cleared); re-enter with P

§2.1 Evidence gate (forward transitions)

The four forward transitions (P→A, A→B, B→C, C→D) require an evidence attestation — a real cli-jaw orchestrate command with an --attest JSON, not narration. The server gates the agent (identified by its boss token); a human's /orchestrate X keeps the free pass. P, A, and B also require user approval; C and D proceed automatically once their work is done. In goal mode, §4 rule 4 replaces user approval with evidence-backed checkpoints.

cli-jaw orchestrate A --attest '{"from":"P","to":"A","did":"<the concrete plan you wrote: files/surfaces + devlog path>"}'
cli-jaw orchestrate B --attest '{"from":"A","to":"B","did":"<who audited the plan + the verdict>"}'
cli-jaw orchestrate C --attest '{"from":"B","to":"C","did":"<what you built + who verified it>"}'
cli-jaw 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: well-formed block, real did narrative (booleans/placeholders rejected); C→D additionally requires non-empty checkOutput and, if present, exitCode:0. It does NOT cross-check the narrative against runtime state — it forces a deliberate, specific claim, not malice-proofing.

Evidence pointers (DEFAULT, ATTEST-EVIDENCE-01): even though the gate checks form only, write did with artifact pointers: plan/devlog path, changed-file list, verifier command, exit code, and relevant cli-jaw goal update checkpoint when goal mode is active, so a later reader can re-check the claim. Narration without running the command does nothing: the state moves only on the command.

Threat model = laziness, not malice. Accepted residuals (NOT bugs): fabricated did, the hidden --force hatch, a prior-turn pendingAttestation, and boss-token stripping (closing it would break the legitimate human-via-CLI free pass).

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.
2. Arm the mode explicitly — enter at orchestrate I or orchestrate P.
3. Advance every forward edge with an evidence-bearing attestation, carrying that phase's real artifact (ORCH-ARTIFACT-01 below).
4. 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 names its plan unit — a real devlog/_plan/YYMMDD_slug/ holding numbered docs (UNIT-RESIDENCE-01) — inside did, not as a separate key.

That placement is not a style choice. cli-jaw's attest parser accepts exactly from, to, did, checkOutput, and exitCode; every other key is silently dropped, with no error and no warning. A planUnit, workPhaseId, auditOutput, auditVerdict, or testReceiptPath field written into the JSON simply vanishes, so a rule demanding them would document a gate that does not exist. Carry them in the did narrative, where they survive and stay readable, and treat the shape as what makes the log re-readable rather than what makes the gate pass.

SESSION-IDENTITY-01 (STRICT) — do not attest for a state you do not own. cli-jaw keeps one FSM per server rather than one per session, and jaw orchestrate takes no --session flag, so there is no id to get wrong here. What remains is the failure the rule exists to prevent: advancing a phase that another conversation is mid-cycle on. Read the current phase before claiming one, and when several conversations share the server, confirm the in-flight cycle is yours before advancing it.

Two cycles writing one record is not a mistake that reports itself: the other conversation's phase moves without it acting, and neither side can tell from inside. That is why this is STRICT rather than hygiene.

§3. Phases

P — Plan

If the request has unclear scope or unspecified technology, return to Interview (cli-jaw orchestrate I): present 2–3 options as <TechName> — <plain explanation>, 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, naming, tests)
• Whether existing SoT logs (structure/, devlog/, docs/, plans/) were read and will be reused, and whether new ones are proposed
• The SoT sync target (SOT-SYNC-01): which general source-of-truth doc 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.

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, and every phase closes with something independently verifiable (build, tests, or a demonstrable surface). Effort-based bucketing is FORBIDDEN (no "quick win vs heavy" buckets, impact/effort matrices, or time-boxed slices): phase boundaries encode build order, not the schedule. Larger work splits into multiple PABCD passes (§5).

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 of 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.

For every planned conditional path, the accept criteria name its activation scenario (C-ACTIVATION-GROUNDING-01 — owner: C phase below).

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 and what it measures, not only pass/fail) · Stop condition · Memory artifact (worklog/devlog/checkpoint path) · Expected terminal states (§11.2) · Escalation condition. Goal mode also states the §11.5 resource scope.

Instrumentation before candidates: when the archetype is open-ended optimization, the loop-spec MUST include a divergence plan: descriptor axes, cell/archetype assignments, candidate count, deterministic selection rule, and telemetry schema. With a score-only verifier, B's first work item is the telemetry, not a candidate — a scalar-only verifier plus discarded candidates is the §10 plateau signature by design.

If anything is unclear, return to Interview (cli-jaw 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 — each a copy-paste-executable PRD, not an outline or empty scaffold. Each later cycle's P re-verifies its pre-written doc against the current codebase (stale check), amends it, then executes. LOOP-CONTINUITY-01 (§10) applies.

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, unnumbered folders) are an A-phase FAIL, not a style nit. Research/spec material (00-range) and implementation phase designs (decade ranges) are SEPARATE documents; mixing both in one doc 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 — stating what changed, why the fast path applied, and the verification evidence; no owning unit → create a minimal unit folder for it. 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.

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; optional for C0-C2 and low-persistence C3 (the work still leaves its numbered record in a unit, UNIT-RESIDENCE-01).
• Sequential within decade; overflow (>10 docs) uses sub-index (000_0_name.md).
• NEVER use bare filenames like PLAN.md, DIFF_PLAN.md, PHASES.md, RCA.md.

Three digits rather than two because the range carries the 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.

This rule was previously written as two-digit while current practice is three. Measured in devlog/_plan/: 492 three-digit documents against 107 two-digit ones, and the two-digit files are concentrated in units from 2026-06 (260610_*, 260618_*, 260621_*) while every unit from 2026-08 onward is three-digit. So the repository migrated and the rule text did not follow.

Historical units keep their prefixes. Renaming them would break every inbound reference for no gain, so this 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.
2. Executing surface — which script, job, hook, or human actually runs it.
3. Known bypass path — the concrete way around it.
4. Residual risk — what stays reachable once the layer is in place.
5. 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). Mirror the plan's work items into the worklog ## Plan section at P and keep their statuses current through B. That section is the visibility channel between turns, and it is not the plan: the diff-level document in the unit stays the single source of truth, and ticking an item is never a substitute for the phase's artifact (ORCH-ARTIFACT-01).

cli-jaw has no separate plan/todo tool surface -- the worklog IS it -- so there is nothing to mirror into beyond that section. Do not report having updated a tracker this runtime does not have.

Present to the user: the Part 1 summary (≤5 sentences) + diagram + devlog file path, plus "Is there any business logic I must not decide alone?" and "Is this direction correct?"

⛔ Present the plan; revise on feedback. On approval, 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
• No new structure/, devlog/, docs, or AGENTS files are introduced without user approval
• New JS/TS files follow TypeScript preference rules (strict-compatible, or limitations stated) unless the plan states why JS is required
• 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).
• Each planned conditional path: trigger reachable from states the system actually visits, not consumed upstream first, activation scenario named (C-ACTIVATION-GROUNDING-01). Unreachable-by-construction = 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 below.

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. On FAIL, synthesize (§11.3), amend the plan, and re-audit with the SAME reviewer. On 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. After implementing, output worker JSON for verification (code exists, integrates cleanly): NEEDS_FIX → fix and re-verify (repair thresholds §11.3); DONE → report 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 (TypeScript projects); (3) SoT sync (DEFAULT, SOT-SYNC-01) — patch the repo's general source-of-truth docs (found in P) HERE so SoT and code never diverge silently, or recommend creating one (dev-scaffolding §2.1) in the D summary; (4) report the 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, never task depth; stop after ONE clean observation. Static gates (tsc/lint/parse) do not satisfy this rule. Defaults (HEURISTIC): 1280x720 viewport. Evidence scales: C2-C3 record the observation in the attestation narrative; C4 (STRICT) persists the screenshot to the devlog. The render observation is valid checkOutput for C→D and the did references it. Excluded: pure logic/config/prose covered by its own test suite. (Adopted 2026-07-05; devlog 260705_pabcd_render_grounding.)

DEFAULT (C-ACTIVATION-GROUNDING-01): the conditional-path sibling of render grounding. When the work-phase adds/changes a code path that only runs under a trigger absent from the happy path (error handlers, fallbacks, retries, caches, guards, gated branches, mode switches, migration handlers, threshold behaviors), C MUST include activation evidence before C->D: (1) TRIGGER the condition for real (test, scenario, threshold fixture, fault injection); (2) OBSERVE the path execute with its intended effect via an assertion, log line, counter, or trace read back; (3) FIX and re-trigger if observation contradicts intent. "All tests green" does not satisfy this when no test drives the trigger. Retroactive-check signals: byte-identical output to baseline (presume dead, instrument first) and a D claim of "handled/falls back" with no fired-path artifact. The activation observation is valid checkOutput for C->D; the did references it. Excluded: unconditional straight-line changes under existing coverage. P names the activation scenario; A checks trigger reachability.

Long external gates (CI runs, deploys): do not block the turn — register cli-jaw bgtask add --cmd '[...]' --prompt "..." and end the turn; the server re-invokes the boss on completion and PABCD state persists. 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); the 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). D→IDLE→P is a context/bias-flush boundary: the next cycle resumes from disk artifacts, not the transcript's accumulated assumptions.

State returns to IDLE automatically. Project root configuration is persistent: D resets PABCD state but not projectDirs; cli-jaw project clear only on explicit user request.

§4. Rules

1. One phase per response (the gate-and-wait turn boundary; canonical approval rule in §2.1). Goal-mode exception: with an active goal, do not end the turn before D while PABCD-phases remain — keep going P→D, close D, re-enter P for the next work-phase.
2. Sequence: P → A → B → C → D. Use cli-jaw orchestrate reset to restart.
3. Workers verify (read-only) by default; write-capable dispatch follows §7.1 DISPATCH-ECONOMY-01. Verdicts stay with the boss in B.
4. Goal-mode precedence: when a jaw goal is active (dev §0.4), use §2.1 with evidence-backed checkpoints (cli-jaw goal update) 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"); PABCD-phase = one letter 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 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, close D (→ IDLE), then cli-jaw orchestrate P for the next work-phase. Never run B for several work-phases back-to-back or commit out of B without passing C and D. Depth scales per class (§9); the P→D sequence is never skipped.

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; re-verify/amend per cycle). The first pass MAY be a design-only Phase-0 cycle producing exactly this difflevel roadmap. 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).
2. 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.
3. 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.
4. 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 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 plan, A really dispatches the audit, B really implements AND verifies, C really runs tsc/tests, D really summarizes with evidence. Never rubber-stamp a phase.

§6. Repository Root Contract

Before writing a PABCD plan or dispatching an employee, determine the actual working repository root with pwd -P from the target repo. If Project root is injected at the top of the system prompt, use it directly; if not, recommend the user configure it (Manager UI → Project settings, or cli-jaw project add /path/to/repo) to avoid JAW_HOME/codebase confusion. Every A/B phase cli-jaw dispatch task body MUST begin with Project root: /absolute/path/to/current/repo.

Rules: Project root is the current working repository, never JAW_HOME; workers never infer the root from ~/.cli-jaw*, process.cwd(), or a temp dir; all relative repo paths resolve against Project root; if it is unknown, STOP and ask before dispatching.

§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 the orchestrator

…(truncated)