Protocol

This page contains the exact rules the agents follow. For a shorter explanation, start with workflow steps or starting a cycle.

What you do and what the agent does

You give a role a request, make decisions when the agent asks, and invoke the next role named in a handoff unless your request already invoked it. Tester and Reviewer need separate chats for their independent checks. You approve Developer’s plan before implementation and decide whether to sign off at the end.

The agent handles the workflow files: it chooses or checks the cycle mode, generates an ID, saves the request and current step, writes its role’s documents, and records handoffs and corrections. You do not need to edit .standards/STATE.md yourself.

Full protocol

The rules below come from PROTOCOL.md and, after them, its chapters in protocol/, during docs setup and builds. Agents read a chapter only when the reading guide names it. Commands such as “read” and “save” address the agent unless a rule asks you to make a decision. The exact field names help agents keep workflow records consistent. Contributors change the source file, then rebuild the docs. Download the original Markdown.

This file is the canonical contract for shared workflow vocabulary, state, transitions, recovery, and the installed runtime in S.T.A.N.D.A.R.D.S.

README.md explains the framework at a high level. Individual skills define role-specific behavior. This protocol defines the rules those skills must share.

Read all of this file before workflow work, then each chapter that the reading guide below names for the current state or request. This file is longer than a single read in some tools. If a read shows only part of it, such as its beginning, or its beginning and end with lines left out between them, read the missing lines in consecutive parts before acting.

How to read this document

The sections run from foundations (roles, modes, states, the persisted state record, and the runtime tools) through handoffs, gates, failure and recovery, user decisions, record formats, and user styles. The order is for orientation only: a role applies every applicable rule wherever it appears. Canonical Terms, the last section, defines terms this protocol uses in a specific sense; consult it whenever a term is load-bearing.

Three chapters in .standards/protocol/ hold rules that apply only in some situations. Read a chapter before acting whenever its condition holds. If a chapter is missing, stop and report an incomplete runtime.

Chapter	Sections	Read when
user-decisions.md	Choose the next cycle’s mode, Standalone Documenter entry, Start a cycle, Change completion policy, Switch verification cadence, Promote an expedited cycle, Sign off, Cancel an active cycle, Greenfield Bootstrap Cancellation, Cycle IDs	No cycle is active (Active Work.Id is UNSET, or WorkflowState is SIGNED_OFF or CANCELLED), or the user invokes Documenter for a standalone documentation request, asks to choose the next cycle’s mode, select or withdraw a completion policy, switch verification cadence, or start, promote, sign off, or cancel a cycle, or Handoff.Kind is COMPLETION_CHANGE, or Active Work.PendingVerificationCadence is not NONE, or Active Work.BlockedOn holds a pending approval to reset the workflow for a greenfield bootstrap cancellation
expedited.md	Expedited Cycle Contract, Expedited Promotion, Outstanding Obligations	CycleMode or PendingCycleMode is EXPEDITED, EXPEDITED is requested or being considered, Active Work.PromotionReason is not NONE, or Outstanding Obligations is active
installation.md	Installed Runtime Contract, Running the CLI, Project Reset, Project Uninstallation	Before running the standards CLI, including for a greenfield bootstrap cancellation, or when the user asks about installing, upgrading, resetting, or uninstalling

Roles

Role
- SCOPER
- TESTER
- ARCHITECT
- NAVIGATOR
- DEVELOPER
- AUDITOR
- REVIEWER
- DOCUMENTER
- SYNCHRONIZER

A role owns decisions or artifacts; it is not necessarily a workflow state. Workflow role skills are invoked explicitly by the user. WorkflowState determines whether an invoked role may perform role-owned workflow work; it does not dispatch a skill automatically. Where supported, client installation must prevent implicit model invocation of workflow role skills. Read-only discovery of a role’s invocation options does not invoke that role, authorize role-owned work, or change workflow state.

NAVIGATOR is explicitly invoked, strictly non-mutating, and outside the workflow state machine. Its Navigator Boundary below applies instead of workflow entry, persistence, completion, and handoff requirements.

State ownership governs role-owned work, not protocol coordination. User Decisions and Intervention defines the control-plane transitions that an explicit user instruction authorizes regardless of which role owns the current state. An active workflow role may also PROMOTE without separate user authorization when an expedited cycle can no longer safely remain expedited.

Project Modes

ProjectMode
- GREENFIELD
- BROWNFIELD

• GREENFIELD: no meaningful pre-existing project implementation must be treated as established baseline.
• BROWNFIELD: meaningful implementation already exists and workflow work must understand, preserve, extend, repair, or otherwise depend on it.

Choose the initial mode from project state at installation. GREENFIELD is temporary: during the initial greenfield cycle, Developer must permanently change .standards/MODE.md to BROWNFIELD as soon as Developer observes and verifies that the active cycle has successfully created or materially modified a project implementation artifact. The trigger is implementation existence, not authorship: it applies equally to code written by Developer and code applied by the user during Developer collaboration. Workflow metadata and role-owned planning, context, test, review, or documentation artifacts do not count as project implementation. The mode never reverts, including during recovery; only Project Reset (in .standards/protocol/installation.md) chooses it again, from --mode or the project’s contents at that time.

For a STANDARD cycle:

• GREENFIELD starts in SCOPING.
• BROWNFIELD starts in AUDITING.

Before the first greenfield audit, missing Auditor-produced project context is intentional. Treat it as a PROJECT_CONTEXT failure only when the active role actually requires context that cannot be established from completed upstream artifacts and known project constraints.

Cancellation while still GREENFIELD follows Greenfield Bootstrap Cancellation in .standards/protocol/user-decisions.md, which resets the workflow. Cancellation after the permanent transition to BROWNFIELD enters terminal CANCELLED.

Cycle Modes

CycleMode
- UNSET
- STANDARD
- EXPEDITED
- DOCUMENTATION

ProjectMode describes the persistent implementation baseline. CycleMode records the assurance topology of the active cycle only. PendingCycleMode records an explicit user preference for the next cycle before that cycle exists. PendingCycleRequest and PendingCycleBlockedOn durably hold a next-cycle request only when a pre-cycle decision prevents that request from becoming an active cycle. All are persisted in .standards/STATE.md.

• CycleMode: UNSET: no cycle is active yet. It is a coordination value, not an execution topology.
• CycleMode: STANDARD: the active cycle uses the standard workflow for the current ProjectMode, with its completion boundary selected by Active Work.CompletionPolicy under Completion Policies.
• CycleMode: EXPEDITED: the active cycle uses the bounded brownfield path that intentionally omits Scoping, Architecture, Auditing, Testing, Documentation, Final Review, and Synchronization unless promoted.
• CycleMode: DOCUMENTATION: the active cycle uses the brownfield documentation path under Documentation Cycle Contract, retaining Auditing, Scoping, Architecture, Documentation, Final Review, and Synchronization while omitting Development, Testing, and Implementation Review.
• PendingCycleMode: UNSET: no explicit next-cycle preference is persisted.
• PendingCycleMode: STANDARD | EXPEDITED | DOCUMENTATION: explicit user preference for the next cycle. It is not an active topology and must be validated when consumed.
• PendingCycleRequest: UNSET | <request>: normally UNSET; stores the actual next-cycle request only while a pre-cycle decision blocks cycle creation.
• PendingCycleBlockedOn: NONE | <question>: unresolved pre-cycle user decision for PendingCycleRequest, otherwise NONE. PendingCycleRequest and PendingCycleBlockedOn are paired: the request is UNSET exactly when the blocker is NONE.

Cycle-mode rules:

1. Installation initializes CycleMode: UNSET, PendingCycleMode: UNSET, PendingCycleRequest: UNSET, and PendingCycleBlockedOn: NONE. Terminal SIGNED_OFF and retained CANCELLED states reset CycleMode to UNSET after the completed or cancelled cycle’s mode-specific transition rules have been applied; all pending-cycle fields must be clear at that point.
2. No role-owned workflow work may proceed with CycleMode: UNSET. A cycle’s mode is chosen, validated, and persisted when it starts, under Start a cycle in .standards/protocol/user-decisions.md; the user sets a pending preference under Choose the next cycle’s mode in .standards/protocol/user-decisions.md.
3. GREENFIELD supports only STANDARD. Pending EXPEDITED and DOCUMENTATION preferences are invalid in GREENFIELD and must not be persisted. Documentation existence does not determine project mode.
4. BROWNFIELD supports all three execution modes. A standalone Documenter request asks for DOCUMENTATION before eligibility and preference checks, under Standalone Documenter entry in .standards/protocol/user-decisions.md. Ineligible or conflicting entry requires a pre-cycle decision, including in GREENFIELD; it never defaults to STANDARD. Otherwise, without an explicit or pending mode choice, STANDARD is the default, except that an explicit Developer invocation for a sufficiently bounded brownfield implementation change may select EXPEDITED.
5. The rules for keeping, promoting, and completing an expedited cycle are in Expedited Cycle Contract and Expedited Promotion, both in .standards/protocol/expedited.md.
6. A documentation cycle has one fixed completion contract and no promotion or in-place mode conversion. Work requiring an omitted role follows Documentation Cycle Contract; selecting a mode for the next cycle never changes an active cycle.

Completion Policies

CompletionPolicy
- NONE
- FULL_DELIVERABLE
- IMPLEMENTATION_REVIEWED

Active Work.CompletionPolicy is required in .standards/STATE.md. A missing, invalid, or repeated value is an inconsistency. It selects a standard cycle’s completion boundary independently of project mode, role mode, and verification cadence; it does not change CycleMode or the ownership of any work.

Policy	Meaning
NONE	No standard completion policy applies: no cycle has started, or the cycle is expedited or documentation-only. It is invalid for an active standard cycle.
FULL_DELIVERABLE	Complete the standard workflow through documentation, final review, and synchronization before user sign-off.
IMPLEMENTATION_REVIEWED	Complete all standard upstream work and the implementation review, then satisfy the early-closure gate under Standard Cycle Completion before user sign-off.

Both standard policies support cycles that start in GREENFIELD or BROWNFIELD. The permanent project-mode transition remains unchanged. Absence of project documentation never selects a policy or proves eligibility for early closure. Scope, architecture, verification, and review records remain required workflow evidence even when project-facing documentation is not required.

Policy lifecycle:

• Installation and project reset initialize CompletionPolicy: NONE.
• Each new standard cycle initializes FULL_DELIVERABLE unless the user explicitly selects IMPLEMENTATION_REVIEWED for that cycle. A prior cycle’s policy is never inherited.
• Each expedited cycle uses NONE and retains its existing completion contract. Promotion to standard initializes FULL_DELIVERABLE; promotion itself never authorizes the shorter completion boundary.
• Each documentation cycle uses NONE and must satisfy Documentation Cycle Contract through Synchronizer. Standard completion policies cannot shorten or extend this route; NONE does not waive its required gates.
• Only an explicit user choice authorizes selecting or withdrawing IMPLEMENTATION_REVIEWED. A policy choice does not revise acceptance conditions, resolve findings, clear blockers, or discharge recovery and outstanding obligations.
• Sign-off and retained cancellation preserve the cycle’s policy in Active Work, even though CycleMode becomes UNSET. It is historical context until the next cycle replaces it; a terminal cycle cannot be reopened by changing its policy.

The shorter policy omits the normal Documenter, final Reviewer, and Synchronizer phases and their completion guarantees. It does not transfer their work to Reviewer, permit fabricated completion records, or remove those owners from standard failure and recovery routing. Required corrective work still returns to its owner. Recovery routing takes precedence over the normal completion boundary.

Selection, withdrawal, and permitted policy-change routes follow Change completion policy in .standards/protocol/user-decisions.md. A policy choice alone is not user sign-off or an invocation of a workflow role.

Documentation Cycle Contract

DOCUMENTATION is valid only with ProjectMode: BROWNFIELD for a request to document existing implementation. It may update existing documentation or create missing documentation. No existing guide or prior cycle record is required for entry. A greenfield request cannot enter this mode merely because documentation files exist; do not change project mode to make it eligible.

The fixed forward route is Documentation Brownfield under Forward Transitions. Auditor establishes relevant existing behavior and project constraints; Scoper defines audiences, documentation targets, editing boundaries, and acceptance conditions; Architect records the existing technical contracts and constraints needed to document them accurately. Architect accounts for each acceptance condition with relevant technical coverage or an explicit no-architectural-impact disposition, without inventing implementation work. Documenter produces documentation and checked evidence. Final Reviewer assesses its accuracy and acceptance coverage independently. Synchronizer reconciles the current deliverable and the applicability of those assessments before sign-off readiness. Existing state ownership, explicit role invocation, handoff, artifact provenance, and independent Reviewer session rules still apply.

Permitted project edits are Documenter-owned prose, guides, project agent guidance outside managed framework blocks, and ordinary comments and docstrings. Examples must describe evidenced existing behavior. Comments interpreted as tooling directives, runtime metadata, or executable logic are outside this boundary. Respect established documentation generation workflows and verify their outputs; a documentation request does not authorize changing behavior, tests, fixtures, configuration, or tooling to make documentation or checks pass. Other roles retain their existing artifact ownership and protocol coordination permissions.

Development, Testing, and Implementation Review are intentionally omitted, not pending work. Their plans, reports, and completion claims are not prerequisites for documentation-cycle gates. Existing source, tests, and prior assessments may be inspected as supporting evidence, but do not fabricate current-cycle records or claim formal implementation verification. Documentation checks provide Documenter-owned evidence; final review and synchronization assess and reconcile it without manufacturing another role’s evidence.

Before entering AWAITING_USER_SIGNOFF, all six included roles must have passed their applicable full gates for the current work. The scope and architecture references, current Auditor context, documentation record, FINAL_DELIVERABLE review report, and synchronization record must be present and applicable. Every current AC-NNN and relevant technical criterion must have sufficient current evidence. No unresolved material finding, documentation gap, dependency, or blocking user question may remain. CompletionPolicy, Development, PromotionReason, PendingVerificationCadence, and BaselineReconciliation must all be NONE; recovery must be inactive with an empty stack and outstanding obligations inactive. An assessed no-change documentation result is valid; it does not skip final review or synchronization. Readiness still requires user acceptance, with evidence freshness rechecked at sign-off.

Failure and rework within this boundary use Recovery Mechanics among the included states only; REVIEW targets REVIEWING_FINAL. Corrections must re-establish affected downstream evidence before readiness. A defect or changed request requiring implementation, formal testing, or implementation review does not authorize entry into an omitted state or automatic promotion. Persist the evidence and required user decision in Active Work.BlockedOn when it prevents the documentation contract from being met. The user may keep an achievable documentation-only scope, or explicitly cancel this cycle and start a separate implementation cycle. Preserve the active cycle, request, and recovery while that decision is unresolved; unrelated observations do not alone block documentation completion. Cancellation retains changed project documentation for later Auditor baseline reconciliation under Start a cycle in .standards/protocol/user-decisions.md.

Workflow States

WorkflowState
- SCOPING
- ARCHITECTING
- AUDITING
- DEVELOPING
- TESTING
- REVIEWING_IMPLEMENTATION
- DOCUMENTING
- REVIEWING_FINAL
- SYNCHRONIZING
- AWAITING_USER_SIGNOFF
- SIGNED_OFF
- CANCELLED

.standards/STATE.md records exactly one WorkflowState, one CycleMode, and one set of pending-cycle coordination fields: PendingCycleMode, PendingCycleRequest, and PendingCycleBlockedOn. SIGNED_OFF and CANCELLED are terminal and mean there is no active cycle. In a terminal state, CycleMode is UNSET; persisted Active Work data describe the most recent cycle for traceability until NEW_CYCLE replaces them, while the pending-cycle fields may independently describe an explicit next-cycle preference or a blocked next-cycle request.

The owning role for each state is:

Workflow state	Owning role
SCOPING	SCOPER
ARCHITECTING	ARCHITECT
AUDITING	AUDITOR
DEVELOPING	DEVELOPER
TESTING	TESTER
REVIEWING_IMPLEMENTATION	REVIEWER
DOCUMENTING	DOCUMENTER
REVIEWING_FINAL	REVIEWER
SYNCHRONIZING	SYNCHRONIZER
AWAITING_USER_SIGNOFF	User
SIGNED_OFF	User (terminal)
CANCELLED	User (terminal)

Persisted Workflow State

.standards/STATE.md is the authoritative, branch-persisted, version-controlled record needed to resume workflow work across sessions or agents. Before workflow work, read .standards/PROTOCOL.md, .standards/MODE.md, and .standards/STATE.md. Resume from persisted state, active work, handoff, recovery context, and outstanding corrective obligations; do not infer a different state from chat history or artifact presence.

STATE.md uses this shape:

# S.T.A.N.D.A.R.D.S. Workflow State

`WorkflowState`: `ARCHITECTING` `CycleMode`: `STANDARD` `PendingCycleMode`:
`UNSET` `PendingCycleRequest`: `UNSET` `PendingCycleBlockedOn`: `NONE`

## Active Work

`Id`: `add-user-search-by-name-and-email-20260923T150000Z-a7f3c2e9` `Request`:
`Add user search by name and email.` `Scope`: `docs/scope/add-user-search.md`
`CompletionPolicy`: `FULL_DELIVERABLE` `Architecture`:
`docs/specs/add-user-search.md` `Development`:
`.standards/docs/development/add-user-search-by-name-and-email-20260923T150000Z-a7f3c2e9.md`
`PromotionReason`: `NONE` `AuditTarget`: `NONE` `BlockedOn`: `NONE`
`PendingVerificationCadence`: `NONE`

`BaselineReconciliation`: `NONE`

## Handoff

`Kind`: `FAILURE` `From`: `TESTING` `FailureType`: `ARCHITECTURE` `Reason`:
`Retry behavior is not defined by the current technical design.`

## Recovery

`Active`: `true`

### Frame 1

`From`: `TESTING` `Owner`: `ARCHITECTING` `FailureType`: `ARCHITECTURE`
`Reason`: `Retry behavior is not defined by the current technical design.`
`ResumeAt`: `TESTING` `RerunThrough`: `NONE`

## Outstanding Obligations

`Active`: `false`

Branches and merges

Commit .standards/ like any other project files. STATE.md belongs to the branch it is committed on, and each branch carries at most one active cycle, which anyone who checks out the branch continues where it was left.

• To start over on a branch, including one created from a branch with an active cycle, the user cancels the cycle or runs Project Reset in .standards/protocol/installation.md.
• If the main branch has STANDARDS installed, once a branch’s cycle is signed off or cancelled, the user runs Project Reset (in .standards/protocol/installation.md) before merging. The main branch then keeps a fresh installation with an accurate MODE.md instead of one branch’s workflow state, Auditor context, and cycle records, and every branch created from it starts with no cycle.
• If the main branch has no STANDARDS installation, the user may instead run Project Uninstallation (in .standards/protocol/installation.md) on the feature branch before merging. Uninstallation removes the branch’s runtime and cycle records while leaving project work outside the installation.

Merging two branches that both changed .standards/ without a reset usually conflicts in STATE.md. The user resolves it by keeping exactly one cycle; the other cycle stops being tracked, and its records stay under .standards/docs/ for the user to decide about. While .standards/ has unmerged files or conflict markers, a workflow role stops, tells the user which cycles are involved, and waits; it never resolves the conflict by choosing a side.

Manual edits

STANDARDS changes its runtime files and cycle records only through legal protocol transitions and the runtime tools. Editing them by hand is unsupported, except to resolve a merge conflict as described above; a user who edits them otherwise is responsible for the result. check reports many, but not all, of the problems such edits cause.

Navigator Boundary

Navigator helps the user understand existing work, investigate questions, and check comprehension. It may run in any workflow state, including user-owned and terminal states, with any cycle mode or no active cycle. It owns no workflow state or persisted artifact and has no workflow completion gate.

• Navigator persists nothing. It creates no quiz scores, preferences, or summaries, and conversation context stays in the conversation.
• The control-plane permissions elsewhere in this protocol do not apply while Navigator runs. It never initializes cycles, generates IDs, records blockers, selects or promotes cycle modes, signs off, cancels, or creates failure, recovery, or other state-changing handoffs. It may explain these actions and their owners, but performing them requires leaving Navigator.

The Navigator skill defines the full operating boundary, including its non-mutation rules, diagnostic safety requirements, explanation standards, and interaction modes.

Instruction Layering and Conflicts

Role-specific precedence may order compatible guidance, such as applying a repository formatter before generic style preferences. Precedence must never be used to silently resolve a material conflict among the protocol or installed integration contract, explicit user constraints, completed role-owned workflow artifacts, project-specific instructions, or repository-enforced/toolchain constraints.

When authorities materially conflict:

1. If the conflict is a defect or changed requirement owned by a workflow role, route it through the protocol’s normal failure, recovery, or USER_REWORK mechanics to that owner.
2. If no workflow owner can resolve the contradiction without overriding another authority, or project instructions conflict with the protocol/integration contract, stop workflow work and require user resolution.
3. Do not weaken an authority, invent an exception, or choose a winner merely because one source appears earlier in a role-specific precedence list.

Role skills should reference these rules rather than redefine conflict-resolution semantics locally.

Runtime Tools and Hooks

Installation places these tools in .standards/bin/. They run with Node.js. Agents call them internally; users do not need an extra post-install command or setup step. Roles use them instead of doing these steps by hand:

Command	Purpose
node .standards/bin/cycle.mjs new --request "<request>"	Generate a new cycle ID (see Cycle IDs in .standards/protocol/user-decisions.md).
node .standards/bin/artifact.mjs init <TYPE>	Create one of the active cycle’s records with its provenance block and header (see Workflow Artifact Provenance).
node .standards/bin/id.mjs next <AC|DEV|F|D|DOC> <file>	Print the next free identifier for a record.
node .standards/bin/check.mjs	Check the runtime files and the active cycle’s records. It only reads files.
node .standards/bin/invocation.mjs <role> --client <client> --json	Discover a role’s invocation options without changing files (see Next-Role Invocation Options).

A workflow role runs check before its first substantive work and again before every state-changing handoff. For each problem it reports:

1. If the problem is in work the current role owns, fix it before continuing.
2. If another role owns it, route it through Failure Handoffs.
3. If no role can fix it, for example a merge conflict or a hand-edited file, stop and report it to the user.

A forward handoff requires that check reports no problem in files the current role owns. check finds mechanical errors such as malformed cycle IDs, broken provenance, or missing acceptance coverage; it does not replace a role’s completion gate. If a tool is missing or fails, stop and report it; do not do its step by hand. Invocation discovery is the presentation-only exception: follow Next-Role Invocation Options for unavailable or incomplete results.

A user instruction not to run commands covers tests, builds, scripts, package managers, git (including read-only git commands) and any other command, with these exceptions. A workflow role still runs the runtime tools above as this protocol requires; if the user explicitly forbids them too, apply Instruction Layering and Conflicts. Viewing, listing and searching files without changing them is not running a command, whatever tool the client uses, and neither is editing files with the client’s file tools. Say which commands were not run and what they would have established, in the role’s record when it keeps one.

Installation can also add a stop hook for Claude Code and Codex (see Installed Runtime Contract in .standards/protocol/installation.md). When an agent finishes a turn and workflow files have uncommitted changes, the stop hook runs check. If it finds problems, it sends the agent back once with the list, and the agent handles them as described above. Because the turn may have ended with a handoff, the hook does not hold the current state’s own COMPLETE records to full acceptance coverage; the role that owns the state reconciles them when it starts, and its own check before handing off still includes them. During recovery, when check otherwise holds only the current state’s COMPLETE records, the hook instead holds those of the state named in Handoff.From after a FORWARD, CHECKPOINT, RESUME, or FAILURE handoff. Apply the gate for the persisted assignment: a checkpoint or scoped corrective return does not assert full phase completion. It holds none while in SCOPING, because Scoper may have changed the acceptance conditions since that handoff. The checker must allow legitimate partial records during an increment assessment or scoped correction while preserving full completion checks at Reviewer entry.

Navigator may run check and invocation, because they change nothing. Discovery needs no active cycle. When a tool or hook reports problems during Navigator work, Navigator reports the relevant limits and changes nothing.

Verification Cadence

Verification cadence controls when Developer hands implemented outcomes to Tester in a STANDARD cycle. It is independent of Developer’s AUTONOMOUS, STEPWISE, or CODE_WITH_ME collaboration mode and does not add a workflow state or change CycleMode.

Developer persists exactly one effective Verification Cadence in its plan:

• AFTER_IMPLEMENTATION: the default. Finish all approved implementation, then hand off to Tester for full verification.
• INCREMENTAL: alternate implementation and independent verification of testable increments, then establish full completion before Reviewer.

Verification Cadence and Current Increment are required. Initialize new plans with AFTER_IMPLEMENTATION and NONE, respectively. Missing, invalid, repeated, or contradictory values are defects. EXPEDITED supports only AFTER_IMPLEMENTATION. Initial selection and later switches follow Switch verification cadence in .standards/protocol/user-decisions.md, including promotion when required.

Testable Increments

An increment is an observable implementation outcome ready for independent assessment, usually one AC or a small group of dependent ACs. It may require several DEV-NNN steps. Increment references do not redefine acceptance or imply that every referenced AC is fully satisfied by that increment.

The existing development plan holds ordered ### Increment N entries, starting at 1, with their Development Steps, Acceptance, and concrete Ready Outcome. Their numbers are plan-local scheduling references, not new requirement IDs. Preserve existing numbers; append new entries rather than renumbering assessed increments. An AC or development step may be referenced by more than one increment when their testable outcomes genuinely require it. Respect approved dependencies; do not manufacture a checkpoint for an outcome that cannot yet be assessed independently.

Developer alone selects and advances Current Increment, a defined positive increment number or NONE, in its plan. Tester records assessments in the existing cycle verification report and never edits the plan. Before advancing, Developer independently reconciles the matching Tester result and current inputs. A report’s existence or an earlier pass alone does not authorize progression. NONE is valid before scheduling, after switching to AFTER_IMPLEMENTATION, or at full completion. Every checkpoint requires a defined increment. Historical handoffs follow Handoff; partial acceptance coverage follows Acceptance Traceability.

Checkpoint Handoffs

With effective cadence INCREMENTAL and no active recovery, CHECKPOINT permits only DEVELOPING -> TESTING and TESTING -> DEVELOPING. Set FailureType: NONE. It records a completed assignment gate, not full phase completion, and creates no recovery frame. Persist claims and actual evidence in the owning records before changing state; independent-session and explicit-role-invocation rules still apply. A pending cadence request does not change the active assignment.

Before Developer hands off an increment:

• the plan has explicit approval under the normal approval rules;
• Current Increment names a defined, testable outcome; all implementation steps and dependencies needed for that outcome are DONE;
• relevant self-checks are satisfactory and the assessed implementation content and readiness claim are saved;
• no unresolved defect, Developer-owned outstanding obligation, unapproved material deviation, or user question blocks the assignment;
• check reports no problem in Developer-owned files.

Tester independently reconstructs that assignment, selects VERIFY or REVERIFY using the existing input-change rules, records Assessment Purpose: INCREMENT and Assessment Target: Increment N, and assesses the outcome plus affected earlier behavior. Both checkpoint directions identify the increment concisely in Handoff.Reason; the owned artifacts hold readiness and assessment evidence. Tests may be updated, replaced, or removed when appropriate to the current contract; preserve required coverage, evidence history, and cycle-wide scenario allocations. Source, test, fixture, dependency, configuration, or contract changes can invalidate earlier results.

Before Tester returns a checkpoint to Developer:

• the selected outcome and affected completed behavior have sufficient current evidence and the report identifies assessed content, actual results, and any justified evidence reuse;
• no required assignment check is unrun, failed, flaky, blocked, or uncovered, and no unresolved defect, Tester-owned obligation, or user question blocks it;
• the increment assessment and remaining acceptance work are saved, with the report still IN_PROGRESS while full verification remains unfinished;
• check reports no problem in Tester-owned files.

A failed checkpoint follows normal failure routing. During recovery, use the saved FAILURE, FORWARD, and RESUME route rather than ordinary checkpoint exchanges; see Implementation and Verification Recovery Gates. Developer resumes under its collaboration mode’s permissions and pauses.

Full Verification Boundary

For normal completion, when all current approved steps are DONE and every other Developer completion-gate condition passes, mark the plan COMPLETE, set Current Increment: NONE, and hand off to full Tester verification. Recovery follows Recovery Mechanics. Tester reconciles every current AC and relevant technical criterion against the final implementation, reusing only still-valid evidence and choosing regression breadth from affected dependencies and risk.

Only the full Tester gate permits a COMPLETE verification report and normal handoff to Reviewer, with Assessment Purpose: FULL and Assessment Target: NONE. Before either a FORWARD or recovery RESUME enters a Reviewer state, the full applicable Developer and Tester gates must hold for the current implementation, even if another recovery frame remains active. Existing implementation-stage dependencies on later roles remain permitted under those gates. Checkpoint passes, targeted corrections, and report labels cannot replace full completion.

Forward Transitions

The following normal forward routes use the gates defined in Handoff Rules.

Standard Greenfield

With CompletionPolicy: FULL_DELIVERABLE:

SCOPING
-> ARCHITECTING
-> AUDITING
-> DEVELOPING
-> TESTING
-> REVIEWING_IMPLEMENTATION
-> DOCUMENTING
-> REVIEWING_FINAL
-> SYNCHRONIZING
-> AWAITING_USER_SIGNOFF

Standard Brownfield

With CompletionPolicy: FULL_DELIVERABLE:

AUDITING
-> SCOPING
-> ARCHITECTING
-> DEVELOPING
-> TESTING
-> REVIEWING_IMPLEMENTATION
-> DOCUMENTING
-> REVIEWING_FINAL
-> SYNCHRONIZING
-> AWAITING_USER_SIGNOFF

For brownfield standard work, ARCHITECTING -> DEVELOPING requires valid project context for the active cycle. Missing, materially incomplete, incorrect, or unexpectedly invalidated context routes to AUDITING. Planned active-cycle implementation changes do not alone make context stale.

Standard Implementation-Reviewed Completion

With CompletionPolicy: IMPLEMENTATION_REVIEWED, either standard route keeps its entire prefix through REVIEWING_IMPLEMENTATION and replaces only the remaining forward tail with:

REVIEWING_IMPLEMENTATION
-> AWAITING_USER_SIGNOFF

This handoff requires the early-closure gate under Standard Cycle Completion, not just a passing implementation review. Unmet closure requirements block this handoff and follow normal ownership and failure rules. User acceptance is still required to reach SIGNED_OFF.

Documentation Brownfield

AUDITING
-> SCOPING
-> ARCHITECTING
-> DOCUMENTING
-> REVIEWING_FINAL
-> SYNCHRONIZING
-> AWAITING_USER_SIGNOFF

This topology is valid only for ProjectMode: BROWNFIELD with CycleMode: DOCUMENTATION and CompletionPolicy: NONE, under Documentation Cycle Contract. Architecture requires valid current-cycle project context before handing off to Documenter. User acceptance is still required to reach SIGNED_OFF.

Expedited Brownfield

DEVELOPING
-> REVIEWING_IMPLEMENTATION
-> AWAITING_USER_SIGNOFF

This topology is valid only for ProjectMode: BROWNFIELD with CycleMode: EXPEDITED, under Expedited Cycle Contract in .standards/protocol/expedited.md.

Handoff Rules

1. Forward handoff requires the current completion gate to pass. Scoped recovery reruns use the explicitly permitted applicable gate under Implementation and Verification Recovery Gates. A CHECKPOINT uses its assignment gate under Checkpoint Handoffs and does not assert the full completion gate passed.
2. A role does not repair work it does not own; failures route under Failure Handoffs.
3. A handoff identifies its target role or workflow state. A failure handoff also identifies FailureType; REVIEW targets the Reviewer state matching the affected ReviewKind.
4. No role silently changes another role’s artifact or decision.
5. Corrective routing and reruns follow Recovery Mechanics, which skills must not redefine; user decisions follow User Decisions and Intervention; and promotion follows Expedited Promotion in .standards/protocol/expedited.md and is not encoded as FAILURE.
6. Every state-changing transition persists all applicable WorkflowState, CycleMode, pending-cycle, Active Work, Handoff, Recovery, and Outstanding Obligations changes before further role work and before presenting any next-role invocation.
7. After a legal transition to a different workflow role, provide a concise copy/paste invocation for that role with Next-Role Invocation Options, unless the same user instruction already explicitly invoked it and it will continue immediately. Do not emit one when the workflow remains with the same role, a blocking question is unresolved, the result is AWAITING_USER_SIGNOFF, SIGNED_OFF, or CANCELLED, or Navigator is used.
8. The invocation is convenience only; STATE.md and role-owned artifacts remain authoritative. Use the active client’s syntax and avoid duplicating authoritative workflow content unless needed for disambiguation:

Next role: <Role>

Codex:       $<skill> Continue the active workflow from `.standards/STATE.md`. Read the persisted Active Work, relevant project context and owned artifacts, and recovery context before proceeding.
Claude Code: /<skill> Continue the active workflow from `.standards/STATE.md`. Read the persisted Active Work, relevant project context and owned artifacts, and recovery context before proceeding.

Emit only the active-client line. When recovery is active, replace “active workflow” with “active recovery” and explicitly direct the role to read the active recovery frame.

At AWAITING_USER_SIGNOFF, present the applicable user actions rather than a next-role invocation.

Next-Role Invocation Options

When a next-role invocation is required under Handoff Rules, the current role runs the read-only discovery helper after persisting the transition and before presenting the message:

node .standards/bin/invocation.mjs <role> --client <client> --json

Use the destination skill identifier for <role> and the active client, codex or claude, for <client>. This is an internal agent operation, not a user setup step or a command to include in the copy/paste invocation. Installation includes the helper and its schema. It discovers the installed role/mode metadata and current user-style filenames on each call. Do not keep a second mode/style catalog, infer styles from identity, or load unselected style contents.

Read the JSON dispositions, including catalogStatus, group selections, option selectability, saved values/arguments, style inventory and lock, and diagnostics. Exit status 0 does not establish that every option is selectable or that a workflow gate passed. Read a referenced selectionRules section only when needed to explain an option’s restrictions; this does not invoke the next role or authorize performing its assessment or procedure. The detailed output contract is in .standards/bin/schemas/invocation-metadata.md.

Keep the base invocation from Handoff Rules unchanged, including its persisted-input directions, recovery wording, and any independent-session prefix and review kind. Put a compact summary beside it, separating:

• You can choose: options whose selectability is user, with a short description and optional text the user can append to the invocation. Name the group when needed to distinguish collaboration from a target, and supply a placeholder for any required file, directory, capability, or area argument. An assessment-required user option is a request subject to the receiving role’s assessment, not a promise that the requested boundary is eligible.
• What happens next: known current selections, applicable saved target details, and any assessment the receiving role still needs to make. Never present state or assessment modes as user switches, or an assessed candidate as a decided outcome. A saved value cannot override a state-selected value or a current condition. A saved assessed mode is resume context only.

Use the discovered identifiers and descriptions. For example, a discovered STEPWISE collaboration choice may be expressed as an optional addition Use STEPWISE collaboration.; do not append it to the base invocation on the user’s behalf. A bare continuation preserves applicable choices, including intent retained in the active request/scope. Mention a defaultForNew only as a fallback for genuinely new work with no applicable choice; missing records do not establish new work. If a saved choice is unresolved or invalid, describe that uncertainty instead of replacing it with the default.

Include a few discovered user-style identifiers when the inventory is complete and the selection is unlocked; label samples as examples if more exist. Use the helper’s non-null selector for copy/paste examples such as Use user style <selector>., or clear an unlocked selection with Use user style NONE.. An entry with a null selector is inventory information only, not a confirmed selectable choice; use selectorReason to distinguish ambiguous names, record-syntax restrictions, and an unverified inventory. Style files are role-specific; never carry a style from the current role into the next role automatically. For conversation bindings, use only an explicit choice for that role still present in the conversation; a different conversation needs the user to name it again.

If a style is locked, report the retained identifier, including NONE, and omit change/clear suggestions. Developer’s style stays locked after first plan approval even during recovery or a revised plan; collaboration modes remain separately selectable. If a lock is unknown, report that change eligibility is unresolved. Discovered filenames may be named as inventory information, but not as confirmed selectable styles. Only the receiving role can establish that a missing record belongs to genuinely new work. A missing locked style requires restoration under User Styles, not substitution or clearing.

Omit empty categories and irrelevant alternatives. Keep small groups of selectable choices complete; for a long inventory, label the displayed choices as examples and point to the discovered role/style location for the rest. Do not dump metadata, diagnostics, all mode procedures, or a configuration questionnaire. Optional choices do not add an approval gate, revise scope, waive remaining required work, or invoke a role on their own. Do not pause an already-authorized immediate continuation to solicit choices; Independent Assessment Sessions still takes precedence.

If the helper cannot run or its catalog is unavailable, provide the normal invocation with a brief note that optional choices could not be verified. Do not invent an option list or ask the user to run the helper. With a complete catalog but unresolved context, present only independently verified choices and qualify the affected values; complete: false need not hide usable parts of the result. Genuine workflow blockers still follow their existing rules. Discovery neither repairs framework files nor changes a selection.

Independent Assessment Sessions

Tester and Reviewer reconstruct assessments from persisted artifacts and repository evidence. Before a handoff to either role, persist the applicable state, owned artifacts, claims, assessed content identities, actual commands and results, limitations, unresolved findings and dependencies, and resume context. Record detail in the owning artifact, not in Handoff.Reason. The receiving role must be able to work without the authoring conversation.

Every handoff entering TESTING, REVIEWING_IMPLEMENTATION, or REVIEWING_FINAL, including recovery and corrections, keeps the normal invocation with its persisted-input and recovery-frame directions, adds the independent-session prefix below, and names the review kind when entering Reviewer. Even when the user invoked both roles together, the immediate-continuation exception never runs an assessment in a conversation that contains the prohibited authoring history.

A skill cannot erase chat history or certify session freshness without client support. Known prohibited history requires persisting missing context within existing ownership, then stopping before the formal assessment to request a fresh session. When history or client metadata is unavailable, state that limitation and proceed from persisted evidence, without inventing an attestation, blocking automatically, or asking for routine confirmation. The assessing role may resume its own interrupted assessment in a conversation separate from the prohibited authoring work. Both roles reload persisted state and current inputs on every resumption; two open chats do not authorize simultaneous role-owned workflow work. Developer and Tester must operate on the same active cycle and checkout.

Independent Tester Session

Apply Independent Assessment Sessions. Prefix a Tester invocation with “Use the existing independent Tester chat, or open a fresh chat separate from Developer’s implementation conversation, then run:”. Developer implementation history is prohibited for formal Tester work, including later increments and targeted corrections. Reusing the Tester chat preserves independence only while it contains no prohibited authoring history.

Independent Reviewer Session

Apply Independent Assessment Sessions. Prefix a Reviewer invocation with “Open a fresh chat separate from the conversations that produced the artifacts under review, then run:”. The separation covers requirements, design, context, implementation, tests and evidence, and documentation authoring, not just Developer. Reviewer’s own review history, including resuming its assessment and correcting its own findings, is not prohibited history.

Also recommend that the user select a different model of equal or higher capability than the one that produced the work, where known. This is advisory: do not switch models automatically, guess model identities or capability rankings, or add a routine author-model confirmation gate. Unknown model metadata is a stated limitation, not a blocker, and session separation is required even when no different model is available.

Commit Message Guidance

After role work, if the role produced a meaningful atomic set of repository changes, provide a suggested Git commit message. Do not create the commit unless the user explicitly requests it. Coordination-only changes such as advancing STATE.md do not justify a suggestion by themselves.

Use Conventional Commits, <type>(<optional-scope>): <description>, for example feat(search): implement user search or docs(scope): define user search requirements. Choose type and scope from the actual changes, not the role or workflow state. Common types include feat, fix, docs, test, refactor, perf, build, ci, and chore. Keep the description concise, imperative, and specific. Use breaking-change syntax or footers only for genuinely breaking changes.

NAVIGATOR never suggests a commit. Other roles omit the suggestion when they produced no meaningful committable changes. When both a commit suggestion and a next-role invocation are emitted, present the commit suggestion first.

Acceptance Traceability

These obligations apply to STANDARD and DOCUMENTATION cycles and do not create a shared traceability artifact or add acceptance data to STATE.md. EXPEDITED cycles do not fabricate Scoper-owned acceptance conditions or substitute identifiers. If an expedited cycle is promoted, Scoper establishes them when the standard topology reaches SCOPING.

In DOCUMENTATION, apply the ownership and identity rules below to the included roles under Documentation Cycle Contract. Tester-specific scheduling and evidence obligations do not apply; Documenter supplies documentation evidence, final Reviewer assesses it, and Synchronizer reconciles it under the same ACs.

1. Scoper represents every verifiable in-scope completion obligation as one or more acceptance conditions with stable, unique AC-NNN identifiers for the active cycle. Do not combine separable obligations under one identifier when their satisfaction or verification evidence is established in different workflow phases. The identifier is a reference, not an ordering guarantee. Get each new identifier with node .standards/bin/id.mjs next AC <scope>. Define each condition as a Markdown list item, bulleted or numbered, that starts with its identifier followed by a colon or dash, for example - `AC-001`: Users can search by name. A table row, heading, or prose mention does not define a condition, and check reports an identifier the scope mentions without defining. This applies to a reused project scope document too: write its current conditions in this form.
2. During REPLAN, preserve an identifier when meaning is unchanged. New or materially replaced conditions receive previously unused identifiers. Removed or replaced identifiers remain in the scope’s retired-identifier record: list items in the same form under a ## Retired Acceptance Identifiers heading. Never renumber surviving identifiers or reuse retired ones within the cycle.
3. When a cycle reuses a canonical scope document that already holds another cycle’s acceptance conditions, numbering continues from the highest identifier ever used in that document. Move the earlier cycle’s conditions, including its retired identifiers, under a ## Previous Cycles heading that stays the document’s last section; the moved content may keep its own headings. Everything under that heading is history, not current obligations, and its identifiers are never used again in that document.
4. Scoper owns acceptance wording and meaning. Downstream roles reference IDs but do not redefine intent; material defects route to Scoper.
5. Architect accounts for every current ID with technical design coverage or an explicit no-architectural-impact disposition when satisfaction depends entirely on established nontechnical behavior or work owned by another workflow phase. Group IDs only when the same disposition applies; do not invent architecture or claim ownership of satisfaction that belongs to another workflow phase. When a cycle reuses a canonical design document that already holds another cycle’s acceptance coverage or technical acceptance criteria, move them under a ## Previous Cycles heading that stays the document’s last section, as in rule 3, before adding the current coverage. Everything under that heading is history, not current coverage or criteria.
6. All downstream coverage, work, and evidence references the same current IDs; downstream roles do not invent substitute requirement IDs.
7. Tester accounts for every current ID with verification evidence, a blocker, or—when satisfaction explicitly depends on a later role—a pending dependency. During partial development, AWAITING_IMPLEMENTATION identifies approved future steps or increments, regardless of effective cadence. It is neither a defect nor a later-role dependency, and cannot pass full verification or Reviewer entry. For partially satisfied ACs, distinguish evidenced outcomes from the remaining work; an increment pass alone does not verify an entire AC. Known regressions or defective completed outcomes follow failure routing. Pending and awaiting implementation are not verification evidence and must be resolved under the same ID.
8. AWAITING_USER_SIGNOFF is forbidden while any current ID lacks sufficient evidence or has an unresolved blocker. Route defects to their owning roles through normal failure and recovery rules; never treat an unevidenced condition as satisfied by assumption.
9. Acceptance changes during recovery or rework invalidate any completed downstream artifact whose completion contract requires accounting for every current ID. Include those states when computing downstream invalidation even if underlying behavior or technical decisions remain otherwise valid.

Review Kinds

ReviewKind
- IMPLEMENTATION
- FINAL_DELIVERABLE

IMPLEMENTATION corresponds to REVIEWING_IMPLEMENTATION. FINAL_DELIVERABLE corresponds to REVIEWING_FINAL. A review handoff must identify the requested kind.

Review Gates

Reviewer’s skill defines the gate for each review kind. FINAL_DELIVERABLE is available in STANDARD and DOCUMENTATION; in EXPEDITED, implementation review assesses the bounded Active Work.Request and Developer evidence under Expedited Cycle Contract in .standards/protocol/expedited.md.

In DOCUMENTATION, final review assesses Documentation Cycle Contract without requiring current-cycle Development, Testing, or Implementation Review artifacts. It still requires independent assessment and a full applicable gate.

Passing a review gate does not complete the cycle. Apply Recovery Mechanics when active; otherwise follow Forward Transitions. Before entering AWAITING_USER_SIGNOFF, all applicable cycle completion requirements, including an empty recovery stack and inactive outstanding obligations, must hold.

In STANDARD, an implementation review may pass with permitted later-role dependencies. Its COMPLETE status alone therefore does not establish eligibility for IMPLEMENTATION_REVIEWED closure. Reviewer separately assesses and records that eligibility under Standard Cycle Completion; this remains implementation review, not a third review kind or a substitute final review.

Synchronization Gate

Synchronizer reconciles completed assessments, the current deliverable, and workflow records in SYNCHRONIZING during STANDARD or DOCUMENTATION. Reviewer owns the assessment of soundness; Synchronizer establishes whether that assessment and its supporting evidence still apply to the work being offered for sign-off. Synchronizer’s skill defines the gate; passing it is not cycle completion or user acceptance. In STANDARD, its normal phase belongs to FULL_DELIVERABLE. Under IMPLEMENTATION_REVIEWED, required reconciliation corrections use Recovery Mechanics and, when applicable, Corrective Returns; they do not replace Reviewer’s closure assessment or restore the omitted normal tail.

In DOCUMENTATION, normal synchronization is mandatory with CompletionPolicy: NONE; reconcile the included roles’ assessments and evidence under Documentation Cycle Contract. Intentionally omitted implementation phases are not missing prerequisites or incomplete synchronization guarantees for that contract.

Project-facing documentation and agent guidance are Documenter-owned, including project instructions outside managed framework blocks. Their completion evidence must identify the relevant documents and assessed content, checks performed and results or limits, and any current AC or technical criterion they satisfy. Documenter persists this evidence and resumable progress in its documentation record under Workflow Artifact Provenance, referencing supporting evidence where it already exists rather than copying it. The record also preserves collaboration mode, target and editing boundary, explicitly selected user style (or NONE), remaining work, discrepancies, dependencies, and the completion conclusion. It is not an authoritative acceptance ledger and does not certify another role’s work. Reviewer and Synchronizer consume it independently; neither manufactures its evidence or rewrites documentation. Managed framework blocks, installed protocol, and installation metadata retain installer/protocol ownership. Preserve user-authored instructions and apply Instruction Layering and Conflicts when necessary.

Standard Cycle Completion

Before a STANDARD cycle enters AWAITING_USER_SIGNOFF, it must satisfy the common requirements below and the completion gate selected by Active Work.CompletionPolicy.

For both policies, Scoper, Architect, Auditor, Developer, Tester, and implementation Reviewer must have passed their applicable full gates for the current work. The Full Verification Boundary applies regardless of verification cadence; an increment pass or scoped corrective return does not establish full completion. Every current AC and relevant technical criterion must have sufficient current evidence, with no unresolved material findings, discrepancies, dependencies, or blocking user question. Required project context must be valid, Active Work.BaselineReconciliation must be NONE, and Active Work.PendingVerificationCadence must be NONE. Recovery must be complete (empty stack) and outstanding obligations inactive. Apply recovery routing first; neither a report label nor correction of one owned obligation bypasses these requirements.

Completion policy	Additional gate before sign-off readiness
FULL_DELIVERABLE	Documenter, final Reviewer, and Synchronizer have passed their full gates for the current work.
IMPLEMENTATION_REVIEWED	Implementation Reviewer has assessed and recorded eligibility under Implementation-Reviewed Closure below.

Implementation-Reviewed Closure

Reviewer assesses early-closure eligibility separately from the ordinary implementation-review conclusion. In the cycle’s implementation review report, record the selected policy, the explicit user choice and its stated reason (if any), assessed input identities, evidence references, eligibility conclusion, and the omitted documentation, final-review, and synchronization guarantees. This evidence must survive replacement of Handoff.Reason and remain in the cycle-owned report after a later cycle replaces Active Work.

Use the implementation report’s Implementation-Reviewed Closure section and structured fields in the Reviewer template. Its Eligibility is NOT_ASSESSED, INELIGIBLE, or ELIGIBLE, independently of ordinary review Status. Only current ELIGIBLE closure and a COMPLETE implementation review permit shorter-policy sign-off readiness. The checker requires that explicit assessment and its recorded prerequisites; Reviewer still determines evidence sufficiency and freshness. Full-deliverable and expedited completion do not require this assessment.

Eligibility requires all common standard completion requirements and:

• every current acceptance condition and relevant technical criterion is satisfied by sufficient current evidence, with no pending later-role work or evidence dependency;
• any required project documentation or agent guidance has owner-produced evidence sufficient for the current contract. Selecting this policy neither waives required documentation nor authorizes Reviewer to create Documenter’s evidence. A contract change uses normal owner-directed rework;
• assessed inputs still match the current contract, implementation, verification, relevant documentation, dependencies, and configuration. Reviewer reconciles changes under its existing assessment obligations without claiming the omitted final-review or independent synchronization guarantees;
• any artifacts and corrections already produced remain accounted for. The policy cannot hide an unresolved finding or discrepancy merely because its owner is outside the shorter normal forward route.

If the ordinary implementation gate passes but closure eligibility does not, keep those conclusions distinct and record the unmet requirement and its owner. Do not enter AWAITING_USER_SIGNOFF, claim skipped phases passed, or silently change the policy. Required owner work follows standard failure, rework, and recovery rules; a user may instead choose full-deliverable completion.

Sign-off Readiness and Freshness

AWAITING_USER_SIGNOFF means ready for the user’s decision, not accepted or SIGNED_OFF. User acceptance follows User Decisions and Intervention; revalidate the selected policy’s requirements at sign-off against current inputs, including after a recovery return to this state. Changes that invalidate supporting evidence or a closure conclusion require reassessment by the affected owners before sign-off; a previously passing report cannot authorize acceptance of changed work. Legal coordination updates alone do not invalidate assessed deliverable content. EXPEDITED uses Expedited Cycle Contract in .standards/protocol/expedited.md instead and never fabricates synchronization.

Failure Types

FailureType
- SCOPING
- ARCHITECTURE
- PROJECT_CONTEXT
- IMPLEMENTATION
- VERIFICATION
- DOCUMENTATION
- REVIEW
- SYNCHRONIZATION

Failure type	Owning role
SCOPING	SCOPER
ARCHITECTURE	ARCHITECT
PROJECT_CONTEXT	AUDITOR
IMPLEMENTATION	DEVELOPER
VERIFICATION	TESTER
DOCUMENTATION	DOCUMENTER
REVIEW	REVIEWER
SYNCHRONIZATION	SYNCHRONIZER

The discoverer of a failure does not automatically own the fix. Route it to the owner of the defective artifact or decision. A material decision that an owner’s completed artifact should have settled but left open is such a defect. When another role owns the correction, do not ask the user to settle it in that role’s place, offer to route it only if the user wants, continue on an assumed answer, or make a forward handoff with the defect noted only in the reply; the owner asks the user when its correction needs a decision. In EXPEDITED, a defect or guarantee owned by a skipped role requires Expedited Promotion in .standards/protocol/expedited.md. Navigator only explains the route; see Navigator Boundary.

Failure Handoffs

A failure handoff routes a defect to its owning state:

SCOPING failure         -> SCOPING
ARCHITECTURE failure    -> ARCHITECTING
PROJECT_CONTEXT failure -> AUDITING
IMPLEMENTATION failure  -> DEVELOPING
VERIFICATION failure    -> TESTING
DOCUMENTATION failure   -> DOCUMENTING
REVIEW failure          -> REVIEWING_IMPLEMENTATION or REVIEWING_FINAL, matching the affected review
SYNCHRONIZATION failure -> SYNCHRONIZING

In STANDARD, use this routing directly. In EXPEDITED, only IMPLEMENTATION -> DEVELOPING and implementation REVIEW -> REVIEWING_IMPLEMENTATION are valid failure routes because only those states exist in the expedited topology. A defect or guarantee owned by a skipped role requires Expedited Promotion in .standards/protocol/expedited.md, not a failure transition into a skipped state.

In DOCUMENTATION, only owners included in Documentation Cycle Contract are valid failure targets, with REVIEW targeting REVIEWING_FINAL. A required omitted role follows that contract’s blocking user-decision rule instead of a failure handoff into a skipped state.

If routing changes state, apply Recovery Mechanics. A same-state failure records the handoff but does not create a recovery frame.

Recovery Mechanics

This is the canonical recovery algorithm. Skills define only how their role corrects its owned work, evaluates its completion gate, and identifies which downstream work its correction invalidates.

Recovery follows the active CycleMode topology. Expedited recovery reruns only expedited states; a newly required skipped role or guarantee triggers Expedited Promotion in .standards/protocol/expedited.md, which preserves unresolved corrective obligations as Outstanding Obligations and clears only the now-obsolete expedited recovery routing.

Documentation recovery uses only its included states under Documentation Cycle Contract, including qualifying Corrective Returns to an interrupted role whose unfinished work prevents the correcting role’s full gate. Standard implementation/checkpoint and shorter-policy corrective exceptions do not add skipped states or guarantees to that topology.

Every documentation frame’s From and ResumeAt must be included states; Owner is an included role, with REVIEW owned by REVIEWING_FINAL. RerunThrough is NONE or a downstream included role, never AWAITING_USER_SIGNOFF. Use RESUME for a recovery-directed jump that skips an unaffected phase; a normal FORWARD still follows the fixed route and requires the full gate, even with frames active. A qualifying Documenter or Synchronizer return retains its valid current-cycle record and verified correction evidence while leaving unfinished full-gate work explicit. The saved return does not establish full completion or waive readiness requirements. Do not create expedited-promotion obligations or current-cycle artifacts for omitted owners; preserve the existing cycle and recovery and use the contract’s blocking user decision instead.

In STANDARD, both completion policies retain all failure owners and the same recovery algorithm. IMPLEMENTATION_REVIEWED omits only the normal forward tail; corrective routing may still enter DOCUMENTING, REVIEWING_FINAL, or SYNCHRONIZING. Those states require active recovery under the shorter policy. Their absence from the normal route is not itself a missing-artifact defect. Preserve the selected policy, frames, and obligations; a correction does not select full completion or authorize running the omitted normal phases.

Compute reruns from affected existing work and evidence required by the active contract, not every phase in the full-deliverable tail. Include already-produced artifacts from omitted phases when their evidence or conclusions are affected. Also treat Reviewer’s early-closure assessment as produced work: a correction that invalidates its assessed inputs or eligibility requires REVIEWING_IMPLEMENTATION reassessment before shorter-policy sign-off readiness. If that is the interrupted state, Reviewer reassesses on resume; otherwise include it in the required reruns. Changes that preserve applicability need a recorded justification, not an automatic full-workflow restart.

1. Push only when corrective routing changes state. For FAILURE or USER_REWORK moving to a different state, push a frame with From = interrupted state, Owner = corrective target, applicable FailureType and Reason, ResumeAt = interrupted state, and RerunThrough: NONE. Same-state correction creates no frame.
2. Preserve nesting. New failure or rework during recovery pushes another frame. Never overwrite older frames. The last frame is active.
3. Only the active frame owner plans resumption. After correcting the defect and passing its applicable gate, that owner decides which already-produced downstream work must be re-established before ResumeAt. Include affected implementation and checkpoint evidence in unfinished phases; a phase need not be COMPLETE to require a rerun. Unimplemented future work alone does not require a rerun. Route through the states owning the affected work using the active topology. Corrective Returns, Synchronizer Corrective Reruns, and Implementation and Verification Recovery Gates define the only exceptions to full completion; the routing algorithm below remains unchanged.
4. No rerun: pop the frame and transition directly to ResumeAt with Handoff.Kind: RESUME.
5. Rerun required: set RerunThrough to the last required state and transition to the earliest required rerun state. Keep the frame on the stack.
6. Rerun states use the applicable gates and legal recovery handoffs while preserving the stack. Normal full gates apply unless Implementation and Verification Recovery Gates or Synchronizer Corrective Reruns explicitly permits a scoped rerun. They do not own the frame unless a nested defect creates a new one.
7. At the rerun boundary, after RerunThrough passes its applicable gate, pop the frame and transition to ResumeAt with Handoff.Kind: RESUME instead of taking the normal forward handoff. This explicit return is valid even when ResumeAt lies outside the project’s normal forward topology.
8. Recovery ends only when the stack is empty.

A return to AWAITING_USER_SIGNOFF must re-establish the selected completion contract after the final frame is closed. For IMPLEMENTATION_REVIEWED, the ordinary implementation review must be COMPLETE and its closure assessment currently ELIGIBLE; a correction or a passing downstream gate alone is not enough. A role returning directly without a Reviewer rerun must establish that the existing closure assessment remains applicable, without rewriting Reviewer-owned conclusions. Otherwise route reassessment before returning.

Examples:

Architecture defect discovered during testing:
TESTING -> ARCHITECTING                 # push frame, ResumeAt TESTING
ARCHITECTING -> DEVELOPING              # set RerunThrough DEVELOPING
DEVELOPING -> TESTING                   # boundary completes, pop, resume TESTING

Scoping defect discovered during implementation review:
REVIEWING_IMPLEMENTATION -> SCOPING     # push frame
SCOPING -> ARCHITECTING                 # set RerunThrough TESTING
ARCHITECTING -> DEVELOPING -> TESTING
TESTING -> REVIEWING_IMPLEMENTATION     # pop, explicit resume

Invalid project context discovered during architecture:
ARCHITECTING -> AUDITING                # push frame
AUDITING -> ARCHITECTING                # no rerun; pop and resume

Nested recovery:
TESTING -> AUDITING                     # outer frame, ResumeAt TESTING
AUDITING -> SCOPING                     # nested rework frame, ResumeAt AUDITING
SCOPING -> ARCHITECTING                 # set nested RerunThrough DEVELOPING
ARCHITECTING -> DEVELOPING
DEVELOPING -> AUDITING                  # pop nested frame, explicit resume

Implementation and Verification Recovery Gates

Developer and Tester may finish a scoped corrective assignment or affected downstream rerun in STANDARD without completing unrelated future implementation or verification. This exception is selected by the interrupted assignment and required return, not by effective cadence, a pending switch, or the latest handoff kind. It also applies when Developer needs a Tester-owned test corrected after switching to AFTER_IMPLEMENTATION.

Before replacing a Developer or Tester assignment during corrective routing, persist its purpose, target, assessed input identities, and next action in that role’s existing artifact. Associate the saved assignment with the recovery frame and its specific reason; a frame number alone may be reused after it is popped. In Developer’s Plan Notes or Tester’s Resume or Handoff, use a ### Suspended Assignment N entry with these required fields:

`Recovery Frame`: `1` `Recovery Reason`: `<exact frame Reason>` `Purpose`:
`DEVELOPMENT | FULL | INCREMENT | CORRECTION` `Target`:
`NONE | Increment N | specific correction` `Assessed Inputs`:
`<relevant content identities>` `Next Action`: `<concrete action to resume>`

DEVELOPMENT represents Developer’s overall implementation assignment, and FULL represents Tester’s overall assessment; both use target NONE. INCREMENT names the assigned increment and CORRECTION names the specific correction. Select one concrete value for each field. Append entries with unique numbers within the artifact; the latest entry for a frame is its saved assignment. Retain the frame association through nested recovery. The checker uses these records to distinguish scoped work from full assignments; the owning roles still determine evidence validity and required reruns.

Preserve older suspended assignments through nested recovery. When the role receives its corresponding RESUME, restore the assignment and reconcile changed inputs. Corrected upstream intent may require revising the assignment under normal ownership and approval rules; record that reconciliation before relying on it.

A scoped gate may replace a Developer or Tester full gate only when:

• the active recovery frame and owned artifacts identify the specific correction or affected rerun and the unfinished assignment to resume;
• all owned work necessary to correct that defect or re-establish the affected outcome is done and verified with appropriate role-owned evidence;
• affected dependencies and previously completed behavior have been reconciled, and any newly discovered independent defect follows normal failure routing;
• remaining full-gate gaps consist only of explicitly recorded future approved implementation or assessment that depends on unfinished work in the preserved route; no assignment defect, owned outstanding obligation, required check, or blocking user question is being deferred;
• check reports no problem in the correcting or rerunning role’s owned files, and the applicable claims, limitations, and resume context are current.

Use the canonical stack algorithm. For a scoped return, Developer keeps its plan IN_PROGRESS; Tester keeps its report IN_PROGRESS or BLOCKED. Only full completion permits COMPLETE. A same-state correction can resume the partial assignment without a new frame. Scoper, Architect, and Auditor retain their full gates; Documenter and Synchronizer retain their separate Corrective Returns.

For example, an architecture correction discovered in an increment assessment can rerun Developer’s affected implementation and resume that assessment while future steps remain unfinished. A nested test correction may return to unfinished Developer work before the outer frame resumes Tester. A return to Reviewer or a later phase must satisfy Full Verification Boundary.

Corrective Returns

An interrupted role may need a documentation or reconciliation defect corrected before it can finish its own work, and requiring the correcting role to finish its full gate first would stop both. Documenter and Synchronizer may therefore plan resumption without passing their full gate. This is a narrow recovery outcome in STANDARD or DOCUMENTATION, not a passing completion conclusion. Every corrective, rerun, and resume state must be legal for the active cycle’s topology. It applies only when:

• the correcting role owns the active recovery frame, whose RerunThrough is NONE, and ResumeAt is another workflow role’s state, or is AWAITING_USER_SIGNOFF under IMPLEMENTATION_REVIEWED with the mandatory Reviewer rerun described below;
• its record has valid current-cycle provenance, and the frame’s specific correction has been verified as that role’s skill requires under Documenter Corrective Return or Synchronizer Corrective Return;
• every remaining full-gate gap exists only because work or assessment already assigned to the interrupted role or the preserved recovery route is unfinished, or, in STANDARD, because a normal phase is intentionally omitted by IMPLEMENTATION_REVIEWED and its guarantee is not required by the active contract. Record each unfinished item, its owner, and the evidence still required; distinguish intentionally omitted guarantees from pending work. Omission cannot excuse evidence needed for the correction, an acceptance condition, or an unresolved material defect;
• any newly discovered independent defect or gap is handled through normal failure and blocking rules instead of being deferred by this exception.

Persist the correction evidence and remaining work, leaving the record IN_PROGRESS or BLOCKED while its full gate is unmet. Then use Recovery Mechanics to determine reruns and the return, preserving older frames and outstanding obligations. Do not mark the record COMPLETE, claim the gate passed, close another role’s findings, or take a normal forward handoff on the strength of the correction. A same-state correction, a downstream rerun that does not own the active frame, or a direct return to AWAITING_USER_SIGNOFF cannot use this exception. Synchronizer Corrective Reruns separately defines the narrow non-owner rerun case. The full gate still applies before a normal forward handoff. Standard Cycle Completion or Documentation Cycle Contract, as applicable, still requires every full gate applicable to the mode and completion policy before sign-off readiness. A corrective return does not itself establish early-closure eligibility or waive remaining owner work.

In DOCUMENTATION, this exception may return a verified Documenter or Synchronizer correction to another included role while the correction record stays incomplete solely because that interrupted role or preserved route has unfinished work. For example, final Reviewer may find an error in an existing current-cycle synchronization record during re-review. Synchronizer verifies the correction with available evidence, persists the unfinished final-review dependency, and uses the active frame to return to Reviewer without claiming full synchronization. After the review gate passes, the preserved route must re-establish any affected synchronization before readiness. This exception does not waive evidence needed to verify the correction, permit entry into an omitted phase, allow an incomplete normal forward handoff, or return directly to AWAITING_USER_SIGNOFF on an incomplete gate. Reaching sign-off readiness still requires all full documentation-cycle gates, an empty recovery stack, and no outstanding obligations.

If ResumeAt is AWAITING_USER_SIGNOFF under IMPLEMENTATION_REVIEWED, a verified corrective return must keep the frame and rerun implementation Reviewer before resuming sign-off readiness. Set RerunThrough to REVIEWING_IMPLEMENTATION, including any earlier required reruns. Reviewer reassesses ordinary review and closure eligibility after the correction; only their passing conclusions and closure of the final frame permit resumption. This prevents an omitted full-phase guarantee from deadlocking required correction while retaining the complete early-closure gate. It does not permit unfinished contract work at sign-off or relax FULL_DELIVERABLE completion.

For example, an error in an existing synchronization record discovered while awaiting shorter-policy sign-off routes to Synchronizer with a recovery frame whose ResumeAt is AWAITING_USER_SIGNOFF. If the correction is verified but the full synchronization gate lacks intentionally omitted final review, Synchronizer keeps its record incomplete, sets RerunThrough to REVIEWING_IMPLEMENTATION, and hands off to Reviewer with the frame retained. Reviewer rechecks the correction’s effect on ordinary review and early closure, then pops the frame and resumes sign-off readiness only when both gates pass.

Synchronizer Corrective Reruns

Under STANDARD with IMPLEMENTATION_REVIEWED, an upstream correction may invalidate a synchronization record left incomplete by an earlier verified Corrective Returns outcome. Synchronizer may re-establish that existing corrective evidence as a downstream rerun without claiming its full gate passed, only when:

• the active frame belongs to another role, has a non-NONE RerunThrough, and its saved rerun plan includes this affected synchronization work;
• the current-cycle record preserves the earlier verified correction, assessed inputs, and intentionally omitted full-phase guarantees. This exception does not initiate normal synchronization or downgrade a previously completed full gate merely to avoid reassessment;
• all affected corrective evidence is rechecked against current inputs, and every required reconciliation check and owned correction is complete. No unresolved material defect, required evidence gap, owned outstanding obligation, or blocking user question is deferred;
• remaining full-gate gaps are limited to intentionally omitted normal-phase guarantees not required by the active contract, or implementation Reviewer reassessment awaiting this rerun on the preserved route. Unfinished required implementation, verification, or documentation cannot use this exception.

Persist the frame association and reason, earlier corrective evidence, changed inputs, revalidation results, remaining full-gate limitations, and next action in the synchronization record. Keep it IN_PROGRESS or BLOCKED; this is a passing scoped assignment, not COMPLETE synchronization or closure eligibility. Do not invent missing final-review evidence or change the selected policy.

The active frame owner plans the route; Synchronizer follows its existing boundary without taking ownership, rewriting RerunThrough, or discarding older frames. At its saved boundary it may pop that frame and resume a workflow role; otherwise it keeps the frame and continues the required reruns. In either case, implementation Reviewer must reassess affected review and closure conclusions before shorter-policy sign-off readiness. When ResumeAt is AWAITING_USER_SIGNOFF, the owner must set RerunThrough to REVIEWING_IMPLEMENTATION, with Synchronizer’s revalidation and other affected work before that final assessment. Synchronizer cannot pop directly to sign-off using this scoped gate. An incompatible saved route does not authorize a shortcut or a self-directed boundary change.

This exception does not apply to FULL_DELIVERABLE, final Reviewer, Documenter, same-state corrections, or an unmet ordinary Synchronizer assignment. Their existing gates and ownership rules remain in force.

User Decisions and Intervention

These are user-authorized control-plane transitions, subject to Navigator Boundary. An explicit, unambiguous user instruction may authorize the receiving agent to persist the coordination change regardless of current state ownership. That authorizes only the coordination changes the applicable rule requires, not the target role’s work: resulting role-owned work may proceed only when that role was explicitly invoked and owns the resulting state. Otherwise stop after persisting the transition and provide the next-role invocation when the handoff rules require one.

At AWAITING_USER_SIGNOFF, available actions are sign off, rework, or cancel; for expedited work, explicit promotion is also available. A standard cycle with IMPLEMENTATION_REVIEWED may instead withdraw that choice under Change completion policy in .standards/protocol/user-decisions.md to resume the full workflow. Bounded expedited rework follows normal recovery back to sign-off. Rework requiring a skipped standard guarantee promotes and restarts the standard brownfield topology at AUDITING.

The rules for choosing the next cycle’s mode, changing completion policy, switching verification cadence, and starting, promoting, signing off, and cancelling a cycle are in .standards/protocol/user-decisions.md. Reworking an active cycle follows below.

Rework an active cycle

From any nonterminal state, update Active Work.Request when the request changed, identify the earliest owned artifact or decision invalidated, record Handoff.Kind: USER_REWORK with its FailureType, and route to that owner. If state changes, push the recovery frame defined by Recovery Mechanics with ResumeAt equal to the interrupted state; preserve older frames. User-requested changes are not agent-discovered failures.

In EXPEDITED, bounded implementation rework routes to DEVELOPING. If the new contract requires a skipped standard role or guarantee, the rework request itself authorizes promotion: update Active Work.Request to the changed contract, then apply Expedited Promotion in .standards/protocol/expedited.md instead of routing to DEVELOPING. Record Handoff.Kind: PROMOTE, not USER_REWORK, and push no rework frame.

In DOCUMENTATION, apply rework only within Documentation Cycle Contract. If the proposed request needs an omitted role, resolve its blocking user decision before replacing the active request or routing; it does not authorize mode conversion or implementation work.

Workflow State Reference

This section defines the fields of .standards/STATE.md and the rules for updating them. The subsections follow the order of the shape example in Persisted Workflow State: Active Work, Handoff, and Recovery. Outstanding Obligations is normally Active: false; only Expedited Promotion adds entries. When it is active, read Outstanding Obligations in .standards/protocol/expedited.md before role work.

Active Work

• Id: stable, user-readable identifier generated by cycle.mjs new (see Cycle IDs in .standards/protocol/user-decisions.md). It is never reused by another cycle. Never overwrite or repurpose an artifact belonging to another cycle.
• Request: persisted user request at enough fidelity for the entry role to understand the work.
• CompletionPolicy: required NONE, FULL_DELIVERABLE, or IMPLEMENTATION_REVIEWED under Completion Policies. Preserve the selected value at sign-off or retained cancellation and initialize it afresh for each new cycle. It is a completion boundary, not acceptance evidence or user sign-off.
• Scope, Architecture, and Development: repository-relative paths to the owning artifacts, or NONE until created. Scoper, Architect, and Developer must persist their artifact path before their normal completion gate passes. In expedited work Scope and Architecture normally remain NONE unless the cycle is promoted; Development is still Developer-owned and is created before implementation begins. In documentation work, Scoper and Architect still persist their paths; Development remains NONE throughout the cycle.
• PromotionReason: durable reason an expedited cycle was promoted, otherwise NONE. Preserve it for the remainder of the cycle; it is workflow context, not a user requirement, scope decision, architecture decision, or baseline fact.
• BaselineReconciliation: durable provenance for unresolved project changes retained from cancelled cycles, otherwise NONE. It must be resolved before the current cycle may rely on the affected repository state as established baseline. Use the Baseline Reconciliation Format below, with one entry per unique SourceCycle and its Request summary. Carry the list across handoffs, failures, rework, recovery, and cancellation until Auditor resolves every source and clears it. Handoff.Reason is not a substitute.
• AuditTarget: transient repository-relative path or area label for an in-progress targeted audit when that focus cannot otherwise be recovered from persisted active work, owned artifacts, or recovery context; otherwise NONE. Auditor must persist an ad-hoc user-directed target before relying on it and clear it when that targeted audit completes, is abandoned, or no longer needs separate persistence.
• BlockedOn: unresolved user question preventing completion, otherwise NONE. Do not use it for a defect another role owns; route that as Failure Types describes, except for the omitted-role user decision required by Documentation Cycle Contract.
• PendingVerificationCadence: NONE, INCREMENTAL, or AFTER_IMPLEMENTATION; a user-requested cadence change awaiting application by Developer under Switch verification cadence in .standards/protocol/user-decisions.md. It is coordination, not the effective cadence or an acceptance ledger. This field is required; a missing, invalid, or repeated value is an inconsistency. Initialize and clear it under the cycle lifecycle rules; never carry it into a new cycle. Documentation cycles keep it NONE because they schedule no implementation or Tester assessments.

Installation initializes Id and Request as UNSET; Start a cycle (in .standards/protocol/user-decisions.md) sets them for every cycle.

Baseline Reconciliation Format

Within Active Work, store BaselineReconciliation on its own line. When no obligation exists, use exactly:

`BaselineReconciliation`: `NONE`

Otherwise use a nonempty Markdown list with both required fields in each entry:

`BaselineReconciliation`:

- `SourceCycle`: `change-invoice-cache-invalidation-20260923T141500Z-5d2e8b17`
  `Request`: `Change invoice-cache invalidation behavior.`
- `SourceCycle`: `add-internal-notes-to-admin-records-20260924T093000Z-c81f4a06`
  `Request`: `Add internal notes to admin records.`

SourceCycle is the cancelled source’s exact cycle Id, not the new cycle’s ID. It is the unique key; Request is that source’s brief persisted request summary. Preserve entry order and existing entries when carrying the list into another cycle. Append a newly obligated source only if its ID is absent; never replace older sources with the latest cancellation or duplicate an existing ID. Confirmation that the latest cycle left no changes does not clear older entries. Keep the complete list while any source remains unresolved; only Auditor clears it to NONE after reconciling every listed source. An empty list is represented as NONE, not an empty string or [].

A value that does not match this format is invalid workflow state. Report the inconsistency and block work that depends on it until corrected; do not infer entries or discard obligations.

Handoff

Handoff.Kind is one of INITIAL, FORWARD, CHECKPOINT, FAILURE, RESUME, PROMOTE, USER_REWORK, NEW_CYCLE, SIGNOFF, CANCEL, or COMPLETION_CHANGE. Use NONE for inapplicable fields. Reason describes only the latest transition and must remain concise; it is not durable storage for outstanding recovery or baseline obligations.

COMPLETION_CHANGE is reserved for the two state-changing routes under Change completion policy in .standards/protocol/user-decisions.md. It requires FailureType: NONE, records the source state in From, and creates no recovery frame. A same-state policy choice preserves the existing handoff; it does not use this kind or replace an incremental checkpoint.

Use RESUME whenever a recovery frame returns to ResumeAt, and for any other recovery-directed transition that is not the normal forward handoff. CHECKPOINT is reserved for the two normal incremental exchange routes under Checkpoint Handoffs, never for a defect, cadence change, or recovery return. Validate a saved checkpoint against its assigned increment and evidence. After the return, Developer may change cadence or select the next increment without rewriting the handoff or Tester’s historical assessment target. These records do not assert that the new selection is verified.

Recovery

Recovery is a stack ordered oldest to newest, and Recovery Mechanics defines how frames are pushed, rerun, and popped. A frame preserves one corrective defect together with the routing needed to return to interrupted work. A role owns the active frame only when the current WorkflowState equals its Owner; merely running during recovery does not make a role responsible for the frame.

State-update rules

1. Installation initializes from the selected mode template: SCOPING for GREENFIELD, AUDITING for BROWNFIELD, CycleMode: UNSET, PendingCycleMode: UNSET, PendingCycleRequest: UNSET, PendingCycleBlockedOn: NONE, Handoff.Kind: INITIAL, unset active work, Active Work.CompletionPolicy: NONE, Active Work.PendingVerificationCadence: NONE, and inactive recovery.
2. Every legal state-changing transition updates all applicable fields as Handoff Rules requires; failure and recovery, promotion, and user-control transitions follow their canonical sections.
3. Blocking questions during an active cycle do not change workflow state. Set Active Work.BlockedOn before asking and clear it after incorporating the answer. Pre-cycle control-plane questions must not modify Active Work.BlockedOn; persist the blocked request and question in PendingCycleRequest and PendingCycleBlockedOn instead.
4. A user-requested cadence switch is a protocol coordination update, not a failure or USER_REWORK. Preserve the current handoff, recovery stack, and unrelated blockers while recording or applying it. Follow Switch verification cadence in .standards/protocol/user-decisions.md for safe application, replacement, and cleanup of pending requests.
5. A completion-policy choice changes only authorized coordination fields. Follow Change completion policy in .standards/protocol/user-decisions.md for permitted boundaries, preservation of assignments and obligations, and state-changing handoffs. Role-owned closure assessment and user sign-off remain separate actions.

STATE.md coordinates the workflow; it does not replace role-owned artifacts. Role-owned artifacts remain authoritative for their own content.

Workflow Artifact Provenance

Cycle ownership must be recoverable from the artifact itself whenever STANDARDS creates one of the records below. Create each with node .standards/bin/artifact.mjs init <TYPE>, adding --kind <ReviewKind> for a review; it writes the provenance block and record header and never overwrites an existing file. Every newly created record begins with this block, using exactly one concrete artifact type and the exact current cycle ID. A review report adds ReviewKind: IMPLEMENTATION | FINAL_DELIVERABLE before -->, with exactly one concrete kind matching its path and the current review state.

<!-- STANDARDS
Artifact: SCOPE | ARCHITECTURE | DEVELOPMENT | VERIFICATION | REVIEW | DOCUMENTATION | SYNCHRONIZATION
Cycle: <Active Work.Id>
-->

Record	Owner	Artifact type	Location	Entries
Scope	Scoper	SCOPE	.standards/docs/scope/<Active Work.Id>.md, or an existing unmarked project document	AC-NNN list items (Acceptance Traceability)
Technical design	Architect	ARCHITECTURE	.standards/docs/specs/<Active Work.Id>.md, or an existing unmarked project document	—
Development plan	Developer	DEVELOPMENT	.standards/docs/development/<Active Work.Id>.md	### DEV-NNN
Verification report	Tester	VERIFICATION	.standards/docs/verification/<Active Work.Id>.md	—
Implementation review	Reviewer	REVIEW, kind IMPLEMENTATION	.standards/docs/reviews/<Active Work.Id>/implementation.md	### F-NNN
Final-deliverable review	Reviewer	REVIEW, kind FINAL_DELIVERABLE	.standards/docs/reviews/<Active Work.Id>/final-deliverable.md	### F-NNN
Documentation record	Documenter	DOCUMENTATION	.standards/docs/documentation/<Active Work.Id>.md	### DOC-NNN
Synchronization record	Synchronizer	SYNCHRONIZATION	.standards/docs/synchronization/<Active Work.Id>.md	### D-NNN

An existing unmarked project document remains project-owned when Scoper or Architect selects it as the active scope or design location. The role may update an appropriate unmarked canonical project document and must not add STANDARDS provenance solely because Active Work.Scope or Active Work.Architecture references it; a new scope or design record is created with artifact init at its path in the table.

Every other record is always cycle-owned at its fixed path. Its provenance block must match Active Work.Id and the path, and its visible Cycle field, plus the visible ReviewKind field in a review report, must match the block. Active Work.Development names the plan; the other fixed paths derive from the cycle ID, so STATE.md gets no path field for them. Because every path that artifact init creates includes the cycle ID, a new record’s path never belongs to another cycle.

A valid provenance block makes the file a STANDARDS cycle-owned artifact even if it is later renamed or moved. A different cycle may read it as prior evidence when a role contract permits, but must never overwrite, repurpose, or adopt it. Preserve other cycles’ records and the other review kind’s report, including moved artifacts whose provenance still names their original cycle.

Before creating or editing a record, or an artifact referenced by Active Work.Scope, Active Work.Architecture, or Active Work.Development, inspect its path and any provenance block:

• A file that starts with a malformed STANDARDS block (for example an unknown artifact type, an invalid cycle ID, a missing or extra ReviewKind, or an unclosed block) is a collision for every artifact type. Do not edit, adopt, or repair it.
• An unrelated, unmarked, incorrectly marked, or different-cycle or different-kind file at a fixed path is a collision, and so is a non-directory or unsafe path that prevents the required location.
• An Active Work reference to another cycle’s artifact is inconsistent with the active cycle. Do not overwrite or silently repair that artifact; correct the reference without mutating it.

Report a collision and block dependent work until the user resolves it, preserving the existing content, without overwriting, relabeling, or adopting it or silently choosing another path.

Test suites, fixtures, ordinary project documentation, comments, and docstrings remain reusable project assets and do not acquire cycle provenance because a role creates or updates them.

The development plan, review reports, documentation record, and synchronization record number their entries as headings with the prefixes in the table. Get each new number, and each new AC-NNN, with node .standards/bin/id.mjs next <prefix> <file>. When a record refers to an entry in another record, it names that record’s path with the identifier, for example .standards/docs/reviews/<Active Work.Id>/implementation.md#F-003; a path relative to the referring file, as in a Markdown link, also works. Acceptance identifiers (AC-NNN) and development steps (DEV-NNN) of the active cycle are referred to without a path.

Project context lifecycle

.standards/CONTEXT.md is the canonical Auditor-owned project-context artifact. Installation does not fabricate it; Auditor creates or refreshes it when AUDITING runs. In a STANDARD or DOCUMENTATION cycle, refreshed context is the project baseline for downstream roles, subject to ownership and freshness rules. In an EXPEDITED cycle, existing context is prior evidence only and is not presumed refreshed.

Any Active-Cycle Non-Baseline Work entry is scoped to the Active Work.Id that produced it and applies only while that same cycle is nonterminal; it is stale in SIGNED_OFF, CANCELLED, and later cycles. A later audit reconciles each prior-cycle exclusion against current repository and version-control evidence, removing or reclassifying it rather than copying it forward, and blocks for user clarification when baseline status cannot be established safely.

Greenfield status does not require context to be absent. Before the first scheduled greenfield audit, Scoping and Architecture may run or rerun without CONTEXT.md when the facts their owned work needs are otherwise established; absence of context alone is not a defect, and a role that needs project facts that cannot safely be established without Auditor-owned context routes a PROJECT_CONTEXT failure. Once CONTEXT.md exists, later Scoping or Architecture work uses it when relevant, even while ProjectMode remains GREENFIELD.

.standards/MODE.md and .standards/STATE.md are protocol-owned coordination artifacts. A role or user may change them only through Project Reset (in .standards/protocol/installation.md), a legal protocol transition, or a protocol-required coordination update, including initializing Active Work, recording artifact paths, selecting or promoting CycleMode, and setting or clearing PromotionReason, BaselineReconciliation, AuditTarget, or BlockedOn. .standards/PROTOCOL.md, its chapters in .standards/protocol/, .standards/bin/, .standards/VERSION.json, and .standards/INSTALLATION.json are framework-owned and may be changed only by framework installation or upgrade.

User Styles

A user style is a Markdown file of personal preferences for one role, kept at .standards/user-styles/<role>/<identifier>.md, where <role> is the role’s skill name, such as developer or tester. Users add and maintain these files; STANDARDS ships none. Installation and Project Reset keep them, and Project Uninstallation deletes them with .standards/ (both in .standards/protocol/installation.md).

A role uses a user style only when the user explicitly selects one:

• The identifier is the filename stem: tony and tony.md both select .standards/user-styles/<role>/tony.md. Only a direct child Markdown file of that role’s folder can be selected; reject paths, separators, traversal, and symlinks that leave the folder. NONE is reserved and means no user style. When a filename overlaps another style’s identifier, use an unambiguous accepted name in invocations and saved User Style fields; do not shorten it into an ambiguous name. If neither the stem nor the full filename resolves uniquely, the user must disambiguate the filenames before selecting that file.
• For roles that persist styles in records, the selector must also be a concrete header value: it must be nonblank and must neither contain | nor be entirely enclosed in <...>. Prefer the stem only when it is unique and usable; otherwise use a unique, usable full filename. For example, <formal>.md persists as <formal>.md, never <formal>. Neither name for team | compact.md can be saved in a record. Report this syntax limitation separately from filename ambiguity. Retain a working saved selector on resume; do not rename user files or rewrite locked selections to work around a limitation. Conversation-only styles do not have record-field syntax restrictions.
• Never infer a style from the user’s identity, repository ownership, prior usage, another role’s selection, or the mere presence of a file.
• If a selection does not resolve to exactly one available file, stop and ask the user to choose an available style or clear the selection; never substitute another.

A user style governs discretionary choices only. Within a role’s style guidance, apply the role’s styles/universal.md first when it has one, then the selected user style, then the role’s other applicable style files. A user style never overrides the protocol, role ownership, the active contract, the required shape of a role’s artifacts, repository-enforced constraints, project instructions, or correctness. A precedence list never settles a material conflict; use Instruction Layering and Conflicts.

Roles that keep a cycle record persist the selection as User Style in that record and reload it on resume: Developer’s development plan, Tester’s verification report, Reviewer’s review reports, Documenter’s documentation record, and Synchronizer’s synchronization record. Scoper, Architect, Auditor, and Navigator have no record for it, so their selection lasts only for the current conversation and the user names it again when resuming. The user may change or clear a selection at any time, except that Developer locks its selection when the user first approves the development plan. If a persisted selection’s file is missing on resume, stop and ask the user to restore it or, when the selection is not locked, to choose another or clear it.

Canonical Terms

Use these terms consistently across all skills, and likewise the names defined in other sections, such as the handoff kinds (failure, forward, resume, and promotion handoffs), expedited cycle, recovery frame, outstanding obligation, active work, cycle mode, user style, runtime tools, and project reset:

• completed scope: scope artifact that passed Scoper’s completion gate; it does not imply separate user approval unless the project adds such a gate.
• scope-level acceptance conditions: observable outcomes owned by Scoper, each identified by a stable AC-NNN acceptance identifier for the active cycle that downstream artifacts reuse.
• retired acceptance identifier: an ID whose condition was removed or materially replaced; retained so it cannot be reused and no longer a current coverage or verification obligation.
• technical acceptance criteria: Architect-derived technical conditions linked to scope-level acceptance identifiers.
• development plan: Developer’s persisted plan for the active cycle. It decomposes the active contract into stable DEV-NNN steps, records collaboration mode and resumable progress, and never replaces scope, architecture, Tester verification, review, or documentation.
• verification cadence: the plan’s effective AFTER_IMPLEMENTATION or INCREMENTAL scheduling choice, independent of collaboration mode.
• increment: a plan-local testable implementation outcome linked to existing development steps and acceptance conditions; it may revisit earlier ACs.
• checkpoint handoff: a normal incremental exchange after an assignment gate passes, without asserting full Developer or Tester completion.
• verification report: records acceptance coverage, scenario allocations, actual execution evidence, gaps, and later-phase dependencies; it does not replace scope, design, or workflow coordination state.
• review report: records inspected inputs, checks, findings, limitations, dependencies, and resumable progress under Reviewer’s Review Gates.
• documentation record: holds the evidence and progress that Synchronization Gate describes; it is distinct from reusable project documentation and does not replace another role’s evidence or an acceptance authority.
• synchronization record: records assessed identities, references to completion and evidence artifacts, discrepancies and their owners, limitations, and a resumable conclusion under Synchronizer’s Synchronization Gate; it is not an acceptance ledger or user sign-off.
• project context: the Auditor-owned baseline in .standards/CONTEXT.md. It may persist as evidence across cycles under Project context lifecycle. A PROJECT_CONTEXT failure means it is materially incomplete, incorrect, or unexpectedly invalidated; planned implementation does not by itself make it stale.
• completion gate: conditions required before a role may make a forward handoff.
• STANDARDS hook: a Claude Code or Codex hook handler whose command runs .standards/bin/hook.mjs.

The paths of the records are in Workflow Artifact Provenance. Do not introduce alternate names for these concepts inside individual skills unless this protocol is updated first.

S.T.A.N.D.A.R.D.S. Protocol: Expedited Cycles

This chapter is part of .standards/PROTOCOL.md. Read that file first; its reading guide says when this chapter applies.

Expedited Cycle Contract

An EXPEDITED cycle provides a deliberately narrower completion contract:

1. It is valid only in BROWNFIELD, and only while the request is a sufficiently bounded implementation contract and no omitted role or guarantee is required.
2. Active Work.Request is the change contract. Scope and Architecture remain NONE unless promotion later causes their owners to create them. Active Work.CompletionPolicy is NONE; standard completion policies do not change the expedited path or its guarantees.
3. Existing project context may be consulted as prior evidence but is not refreshed by default. Prior-cycle non-baseline entries are stale for the current cycle.
4. Active-cycle implementation remains tentative and does not become established baseline, even after promotion.
5. Developer owns implementation and normal implementation-level self-checks; these are not Tester-owned formal verification.
6. Reviewer still owns REVIEWING_IMPLEMENTATION and may route implementation defects through normal recovery.
7. Scoper, Architect, Auditor, Tester, Documenter, REVIEWING_FINAL, and Synchronizer are absent from the expedited forward topology. Their missing artifacts or gates are not failures. Skipping them transfers none of their ownership, artifacts, or completion guarantees to Developer or Reviewer, and neither synthesizes the skipped work.
8. The cycle may reach AWAITING_USER_SIGNOFF after Developer and implementation Reviewer pass their gates, recovery is empty, and no blocking user question remains. Scope-level acceptance traceability does not apply.
9. If safe completion requires an omitted role or guarantee, including baseline status that needs Auditor-owned context, use Expedited Promotion instead of assigning that work to Developer, weakening ownership, or fabricating skipped work.

Expedited Promotion

Promotion changes a nonterminal EXPEDITED brownfield cycle to STANDARD when safe completion requires formal Scoping, consequential Architecture, authoritative Auditor-owned context, Tester-owned verification, Documentation, Final Review, Synchronization, or another intentionally omitted guarantee. It is a topology change, not a failure handoff, and it is one-way for the active cycle.

1. An active workflow role may promote when required. At AWAITING_USER_SIGNOFF, user authorization is required. An explicit promote request qualifies; so does an explicit rework request whose changed contract necessarily requires an omitted standard role or guarantee.
2. Set CycleMode: STANDARD, WorkflowState: AUDITING, and Active Work.CompletionPolicy: FULL_DELIVERABLE. Set Handoff.Kind: PROMOTE; set From to the interrupted state, FailureType: NONE, and record a concise reason identifying which omitted standard guarantee is now required. Persist the same reason in Active Work.PromotionReason.
3. Preserve cycle Id, the current Request (including a change made by the rework that authorized promotion), and role-owned artifacts. Do not fabricate Scope or Architecture.
4. Auditor establishes or refreshes context without laundering tentative expedited work into pre-existing baseline. It distinguishes pre-cycle baseline from active-cycle changes using authoritative evidence, and material ambiguity requires a user question rather than a guess.
5. Before clearing recovery, persist the frame-to-obligation conversion defined in Outstanding Obligations below, preserving each converted frame’s Owner, FailureType, and Reason. Then clear the expedited recovery stack; the standard brownfield topology restarts at AUDITING.
6. All standard forward, failure, recovery, outstanding-obligation, traceability, and sign-off rules apply afterward. Promotion never selects IMPLEMENTATION_REVIEWED. A separate explicit user choice follows Change completion policy in .standards/protocol/user-decisions.md and cannot bypass the obligations preserved by promotion.

Outstanding Obligations

Outstanding Obligations preserves unresolved corrective work when the recovery routing that carried it is no longer valid. It is ordered oldest to newest. Each obligation records Owner, FailureType, and Reason; it deliberately has no From, ResumeAt, or RerunThrough.

Normally the recovery frame itself is the durable corrective obligation and no duplicate outstanding obligation is created. RerunThrough: NONE means the frame’s owner has not yet completed its correction; a non-NONE RerunThrough means the owner already passed its corrective gate and the frame remains only to finish downstream rerun/resume routing. During Expedited Promotion, convert each recovery frame whose RerunThrough is NONE into one outstanding obligation before clearing the expedited recovery stack. Do not convert frames whose RerunThrough is non-NONE. Preserve converted obligations in recovery-stack order, keep each distinct defect separate, and do not collapse defects merely because they share an owner or failure type.

When one or more obligations exist, set Active: true and record each as a numbered ### Obligation N entry containing Owner, FailureType, and Reason. When an obligation is removed, renumber the remaining entries 1, 2, 3, … in their existing order. When the last obligation is removed, set Active: false and remove the numbered entries.

An outstanding obligation remains until its owning state is reached and the owner corrects and verifies the specific defect recorded by the obligation. Remove a corrected obligation as soon as that corrective outcome is verified; removing it records only that the obligation itself is satisfied, not that the owning role is otherwise complete. The owner must still pass its normal completion gate, including having no unresolved obligation owned by its current state, before any normal forward handoff. User sign-off is unavailable while any outstanding obligation remains.

S.T.A.N.D.A.R.D.S. Protocol: Installation, Reset, and Uninstall

This chapter is part of .standards/PROTOCOL.md. Read that file first; its reading guide says when this chapter applies.

Installed Runtime Contract

The user installs, upgrades, resets, and uninstalls STANDARDS with the standards CLI. The CLI’s full contract is maintained in the STANDARDS repository (INSTALLER.md) and is not installed. An installed project should provide:

• AGENTS.md: project-facing entrypoint to the protocol and role skills;
• CLAUDE.md: Claude Code compatibility entrypoint importing AGENTS.md;
• .standards/PROTOCOL.md: installed canonical protocol;
• .standards/protocol/: the protocol chapters that the reading guide in .standards/PROTOCOL.md names for specific situations, replaced as a whole on every install and upgrade;
• .standards/VERSION.json: installed framework version used to check upgrade eligibility;
• .standards/INSTALLATION.json: installer metadata, not workflow state, recording only the client settings, client paths, and hook files the installer created, so a reinstall or uninstall never claims or undoes the user’s own settings;
• .standards/MODE.md: current ProjectMode;
• .standards/STATE.md: current workflow/cycle state and resumable coordination context;
• .standards/bin/: the runtime tools and hook script described in Runtime Tools and Hooks, replaced as a whole on every install and upgrade;
• .standards/docs/: the role-owned cycle records defined in Workflow Artifact Provenance, created only by the roles through artifact init;
• .standards/user-styles/: optional user-owned styles defined in User Styles;
• the S.T.A.N.D.A.R.D.S. workflow skills installed in the location required by the selected coding agent;
• unless the user declines it, the STANDARDS stop hook in .claude/settings.json for Claude Code and in .codex/hooks.json for Codex;
• explicit-invocation controls: Codex adapters use allow_implicit_invocation: false; Claude Code project settings use skillOverrides.<skill>: "user-invocable-only" for installed role skills, including Navigator despite its position outside the workflow state machine.

.standards/MODE.md contains exactly one canonical ProjectMode; its greenfield-to-brownfield transition follows Project Modes. .standards/STATE.md contains exactly one canonical WorkflowState and CycleMode and follows Persisted Workflow State. A reinstall of the same version, or an upgrade to a newer minor or patch release of the same major version, keeps workflow state, Auditor context, cycle records, user styles, and project-owned instructions and settings, and replaces the protocol, tools, skill files, and managed blocks. STANDARDS provides no migration between major versions: moving an existing project to a new major version means standards uninstall, which deletes .standards/, followed by a fresh installation.

Running the CLI

Agents run the standards CLI only when the user explicitly asks, except that they run reset for Greenfield Bootstrap Cancellation in .standards/protocol/user-decisions.md, which adds its own steps to these. standards reset and standards uninstall delete workflow data, so for either command:

1. Pass --project with the project’s absolute path and run the command with --dry-run first. Show the user the target, the planned changes, any warnings, and the exact command with --yes.
2. Run that command only after the user explicitly approves it. Outside a terminal the CLI does not ask for confirmation, so the approval must come from the user in the conversation.
3. If the preview changes before the command runs, show it again and get fresh approval. If the command refuses or fails, stop and report it with any backups it lists; do not delete or rewrite the files yourself.

Project Reset

An explicit standards reset returns an installed project’s workflow to the state of a fresh installation without reinstalling anything, ending any active cycle without a terminal state. Agents run it only as Running the CLI allows.

• Default to the current directory; accept --project <path> and --mode. Offer --dry-run to report every planned change without writing files, and confirm interactively unless --yes is given.
• Require the runtime ownership marker and a valid .standards/VERSION.json that matches the CLI’s version, because the fresh files come from the CLI’s templates. Missing or invalid workflow files do not prevent a reset.
• Delete .standards/CONTEXT.md and .standards/docs/, warning with the count of cycle records, and write fresh .standards/STATE.md and .standards/MODE.md. Take the mode from --mode, otherwise choose it from the project’s contents as a first installation would.
• Keep everything else: PROTOCOL.md, protocol/, VERSION.json, INSTALLATION.json, bin/, .standards/user-styles/, the skills, hooks, client settings, and managed blocks.
• Refuse symlinks in the paths it deletes. Keep backups during the operation and restore them on an ordinary failure. If recovery fails, keep the backups and report their location. An interrupted operation blocks install, reset, and uninstall until the user resolves it.

Project Uninstallation

An explicit standards uninstall removes all verified STANDARDS skill packages for Codex and Claude Code, the managed blocks in AGENTS.md and CLAUDE.md, the STANDARDS hooks, installer-added settings whose values are unchanged, client files and folders the installer created once nothing else is in them, and the entire .standards/ directory: saved workflow state, Auditor context, cycle records, user styles, and any other content in it. It keeps project work outside those paths, including reused scope or design documents, settings the user changed, and a globally installed CLI. It is allowed in either project mode, with or without an active cycle, and does not complete, sign off, cancel, or revert project work. There is no force removal or client-only uninstall.

S.T.A.N.D.A.R.D.S. Protocol: User Decisions

This chapter is part of .standards/PROTOCOL.md. Read that file first; its reading guide says when this chapter applies.

Choose the next cycle’s mode

While no cycle is active, or before the initialized first cycle has received its request, an explicit user instruction may set PendingCycleMode to a mode supported by the current ProjectMode, replace an earlier pending preference, or clear it to UNSET. Leave CycleMode: UNSET and Active Work unchanged; the selection does not activate a cycle. The latest selection survives across sessions until a cycle consumes it or the user replaces or clears it. While a blocked PendingCycleRequest exists, a mode change or clear revalidates that request under Start a cycle without asking the user to repeat it.

DOCUMENTATION is a supported preference only in BROWNFIELD. Validate the request against Documentation Cycle Contract when consuming it; a pending preference does not authorize implementation work or overwrite an active cycle. Reject unsupported Greenfield preferences without persisting them. A request already blocked before cycle creation remains governed by Start a cycle.

Standalone Documenter entry

An explicit Documenter invocation with a new documentation-only assignment requests DOCUMENTATION while no cycle is active. Classify that intent before applying project-mode eligibility, pending preferences, completion-policy choices, or default mode selection. Use Start a cycle, including cancelled-cycle baseline reconciliation and ID generation. In GREENFIELD, or with an incompatible mode preference or standard completion-policy choice, use its pre-cycle blocking decision; never substitute STANDARD automatically.

Persist the standalone Documenter entry instruction alongside the concrete documentation request and any explicit target, editing boundary, collaboration choice, or user style in PendingCycleRequest when blocked, or Active Work.Request when starting. Recover that intent from the saved request on resumption even when the user invokes another role or only says to continue. Only an explicit user decision to revise or withdraw standalone entry permits a different mode; preserve the documentation goal and other unchanged choices. A conflicting completion-policy choice alone does not withdraw that intent. Do not create a premature documentation record or invent missing choices. A bare invocation or request to continue without an available assignment does not invent a new cycle request.

The resulting state is AUDITING, not DOCUMENTING. Initializing coordination does not authorize Documenter to audit, scope, design, or edit documentation early. Persist the transition and provide the Auditor invocation under the protocol’s Handoff Rules. Auditor may continue immediately only when the same user instruction explicitly invoked Auditor too. Subsequent roles likewise require explicit invocation and ownership; never auto-dispatch the full route.

When a cycle is active, its saved mode and state remain authoritative. An invocation to continue the active documentation assignment follows the current owner and existing recovery. Documenter may perform its owned work only in DOCUMENTING; otherwise identify the owner and apply only an authorized coordination action. A materially changed active request uses the protocol’s Rework an active cycle, including documentation-boundary limits. A separate standalone request must wait until the active cycle is finished or explicitly cancelled. Do not overwrite its ID, request, artifacts, blockers, recovery, or pending fields to start another cycle, and do not infer cancellation from a Documenter invocation.

Start a cycle

A cycle starts from the installed state, where Active Work.Id, Active Work.Request, and CycleMode are UNSET, or from SIGNED_OFF or retained CANCELLED; a finished cycle is never reopened. The request is the user’s new request or, when one exists, the persisted PendingCycleRequest: use it without asking the user to restate it, and let a revised request replace it.

1. Determine the reconciliation obligation the new cycle would carry, without writing it yet. For the first cycle and from SIGNED_OFF, it is NONE. From retained CANCELLED, it preserves any existing BaselineReconciliation and, unless the user explicitly confirms that the just-cancelled cycle left no project changes because none were produced or they were reverted, adds a SourceCycle/Request entry for that cycle under Baseline Reconciliation Format if its exact cycle ID is not already listed.
2. Choose the mode before changing any state. First identify standalone Documenter intent from the current invocation or the saved request under Standalone Documenter entry, incorporating any explicit user resolution. While that intent remains, the requested mode is DOCUMENTATION, including in GREENFIELD or with a standard completion-policy choice. Conflicting explicit or pending mode choices and incompatible policies use step 3 before cycle creation; none changes this request into inferred STANDARD work. A pending preference must also be valid for the request, the current ProjectMode, and the reconciliation obligation. Honor explicit and pending choices; never silently replace a conflicting preference. Without standalone intent or an explicit or pending mode choice, STANDARD is the default, except that in BROWNFIELD an explicit Developer invocation with a sufficiently bounded implementation request may select EXPEDITED. A pending STANDARD preference prevents inferred expedited entry. GREENFIELD supports only STANDARD. Unresolved reconciliation requires an Auditor-first STANDARD or DOCUMENTATION cycle, never EXPEDITED. Documentation entry must satisfy Documentation Cycle Contract, including preserving reconciliation for Auditor; a request requiring implementation or another omitted role is ineligible. A pending EXPEDITED preference does not bypass the Expedited Cycle Contract in .standards/protocol/expedited.md: validate eligibility before consuming it. An explicit FULL_DELIVERABLE or IMPLEMENTATION_REVIEWED selection requires STANDARD and prevents inferred expedited entry. It conflicts with standalone documentation intent and does not override an explicit or pending EXPEDITED or DOCUMENTATION mode choice; resolve conflicts in step 3. Documentation cycles use CompletionPolicy: NONE.
3. Block instead of starting when the mode is not legal, whether because of an invalid pending preference or an explicitly requested mode the current ProjectMode does not support. Never silently reinterpret the mode as STANDARD or persist an unsupported mode. Leave WorkflowState, Active Work, CycleMode, and PendingCycleMode unchanged; persist the request in PendingCycleRequest and the specific decision required in PendingCycleBlockedOn, not in Active Work.BlockedOn; and ask the user to choose a supported mode, replace or clear the preference, revise the request, or abandon it. Abandoning clears PendingCycleRequest and PendingCycleBlockedOn without modifying Active Work or starting a cycle. Apply the same rule to an incompatible completion-policy choice. Keep the standalone entry instruction, explicit mode and policy choices, and stated reasons in the saved request text so resumption does not lose them; there is no separate pending completion-policy field. When the user explicitly revises or withdraws standalone entry to use another mode, update that instruction in the saved request before revalidating it. Merely resuming or clearing a conflicting preference does not withdraw standalone intent.
4. Generate the ID as Cycle IDs describes. If the tool refuses, leave the state unchanged and do not start the cycle.
5. Persist the cycle in one state update:
   • Active Work: the new ID and request; Scope, Architecture, Development, PromotionReason, AuditTarget, and BlockedOn set to NONE; PendingVerificationCadence: NONE; and BaselineReconciliation from step 1.
   • Active Work.CompletionPolicy: NONE for EXPEDITED or DOCUMENTATION; FULL_DELIVERABLE for STANDARD unless the user explicitly selected IMPLEMENTATION_REVIEWED for this request. Preserve any explicit choice and stated reason in Active Work.Request as a workflow instruction, distinct from implementation requirements. Do not inherit the prior cycle’s policy or invent a reason.
   • CycleMode: the chosen mode. PendingCycleMode and PendingCycleRequest become UNSET, and PendingCycleBlockedOn becomes NONE.
   • Handoff: for the first cycle, keep Kind: INITIAL with From: NONE and FailureType: NONE; from a terminal state, record Kind: NEW_CYCLE, From set to that state, FailureType: NONE, and a concise reason. An expedited or documentation first cycle records a concise mode-entry reason. Mention an unresolved reconciliation obligation concisely, without copying its source-cycle provenance.
   • Recovery and outstanding obligations inactive.
   • WorkflowState: AUDITING when reconciliation is unresolved or cancelled-cycle changes are being retained or adopted, or the chosen mode is DOCUMENTATION, so Auditor establishes baseline status first. Otherwise DEVELOPING for an allowed EXPEDITED cycle, or the standard entry state for the current ProjectMode: SCOPING for GREENFIELD or AUDITING for BROWNFIELD.

CycleMode never remains UNSET once a cycle has started.

Change completion policy

An explicit user instruction may select FULL_DELIVERABLE or IMPLEMENTATION_REVIEWED for the active STANDARD cycle under Completion Policies. A request to finish after implementation review selects the shorter policy; it does not itself assert that review passed or accept the deliverable. A request to withdraw that choice selects FULL_DELIVERABLE. The Navigator Boundary and User Decisions and Intervention permissions still apply.

With no active cycle, select the policy only as part of Start a cycle; there is no standalone next-cycle policy preference. With an active EXPEDITED cycle, keep CompletionPolicy: NONE and explain its existing path through implementation review to sign-off. A standard policy requires authorization for Promote an expedited cycle; selecting a policy alone does not promote it. Promotion first initializes FULL_DELIVERABLE, after which a separately authorized policy selection must satisfy the rules below. Both instructions may be given together, but selection must not bypass promotion obligations.

With an active DOCUMENTATION cycle, preserve CompletionPolicy: NONE and its fixed route through final review and synchronization. Explain that standard policy selection does not convert this cycle or omit its required phases.

1. Check whether this changes the policy. An instruction matching the saved policy is a no-op: preserve state, handoff, and records. It does not reassert evidence validity, sign off, or restart work. For an unset or terminal cycle, do not edit the retained cycle or reopen it.

2. Check the boundary before applying a change. Recovery must be inactive with an empty stack, and outstanding obligations inactive with no entries. No normal documentation, final-review, or synchronization work may have begun in this cycle. Determine this from the saved role progress and repository evidence, not merely the current state or absence of a record. Earlier corrective work by those owners is not normal downstream phase entry and remains subject to its existing evidence and obligations.

3. Select the permitted route from the table below. These are the only policy-change routes; other states or failed preconditions do not authorize a change. Leave the policy and routing unchanged, explain the unmet condition, and do not queue a deferred policy change. Established defects still use normal owner-directed failure routing. A materially changed request uses normal rework, not this policy-only action.

   Current state	Policy change	Resulting state	Additional precondition
   SCOPING, ARCHITECTING, AUDITING, DEVELOPING, TESTING, or REVIEWING_IMPLEMENTATION	Either standard policy to the other	Same state	Preserve the current role assignment and handoff, including an incremental checkpoint.
   DOCUMENTING	FULL_DELIVERABLE to IMPLEMENTATION_REVIEWED	REVIEWING_IMPLEMENTATION	Untouched normal Documenter handoff under the conditions below.
   AWAITING_USER_SIGNOFF	IMPLEMENTATION_REVIEWED to FULL_DELIVERABLE	DOCUMENTING	Current implementation-review evidence under the conditions below.

   For the DOCUMENTING route, the saved handoff must be either FORWARD from REVIEWING_IMPLEMENTATION, or COMPLETION_CHANGE from AWAITING_USER_SIGNOFF after a withdrawal. Documenter must not have begun its normal phase. The implementation review must have passed and remain applicable to current inputs; permitted later-role dependencies may still be unresolved. Entering Reviewer also requires Full Verification Boundary. Reviewer then assesses early-closure eligibility; selecting the policy never supplies that assessment or permits jumping directly to sign-off.

   For the AWAITING_USER_SIGNOFF withdrawal route, the completed implementation review and its supporting full verification must remain applicable to current inputs. If changes have invalidated them, route the affected work to its owners before applying the withdrawal. Withdrawal removes readiness for sign-off and resumes the full forward tail at Documenter; it does not require Auditor or other upstream owners to repeat still-valid work.

   Both state-changing routes require Active Work.BlockedOn: NONE. An unrelated blocker does not prevent a same-state policy choice, but that choice never clears it or authorizes blocked role work.

4. Persist the authorized choice. Set Active Work.CompletionPolicy and retain the explicit choice and any stated reason in Active Work.Request as a workflow instruction, preserving the implementation request. Replace an earlier policy instruction so the saved request and policy agree; do not treat this as a scope change or an acceptance waiver. Preserve cycle ID, mode, artifact references, evidence, blockers, pending verification cadence, baseline reconciliation, recovery, and outstanding obligations.

5. Record routing only when the state changes. For the two state-changing routes, set WorkflowState to the target and Handoff.Kind to COMPLETION_CHANGE, From to the source state, FailureType: NONE, and a concise reason identifying the old and new policies. Do not push a recovery frame or overwrite report conclusions. For a same-state change, preserve the entire handoff and any checkpoint assignment. Cycle initialization retains INITIAL or NEW_CYCLE instead.

6. Hand off within existing role permissions. Persist the coordination update before presenting the next action. Stop after the policy change unless the user also explicitly invoked the role that owns the resulting state. State-changing routes follow Handoff Rules, including the implementation review kind and independent-session requirements when returning to Reviewer. A policy change authorizes no other role’s work.

Existing review reports retain their historical assessments. Their closure conclusions apply only to the policy and inputs they assessed; a later return to the shorter policy requires Reviewer to reconcile eligibility again. Sign-off and retained cancellation preserve the last effective policy; starting a new cycle replaces it under Start a cycle.

Switch verification cadence

An explicit user instruction may select INCREMENTAL or AFTER_IMPLEMENTATION for the active cycle under Verification Cadence. Record and apply it as follows, preserving collaboration-mode permissions and pauses. The coordination rules in State-update rules apply throughout.

DOCUMENTATION has no implementation or Tester scheduling. Keep PendingVerificationCadence: NONE; a cadence request does not add those phases or convert the cycle. Explain that it requires a separate implementation cycle.

1. Promote when needed. EXPEDITED supports only AFTER_IMPLEMENTATION. An explicit INCREMENTAL request authorizes Expedited Promotion in .standards/protocol/expedited.md. Preserve the request as pending during promotion and follow the Auditor handoff. Evaluate remaining scheduling after the standard contract is established.
2. Check whether there is work to schedule. Accept the request during an active cycle while implementation or its increment scheduling remains unfinished, including before a development plan exists or during recovery. Once the current contract and recovery route establish that no implementation or increment scheduling remains, clear pending intent and explain why the switch has no remaining effect. Do not rely on completion claims invalidated by rework or promotion, or reopen work solely to change cadence. No request is retained for an unset, signed-off, or cancelled cycle.
3. Persist the latest request. Any current role may record the explicit request in Active Work.PendingVerificationCadence. Replace an earlier pending choice with the latest one. A request matching the effective cadence cancels an opposite pending choice; if no plan exists, retain the explicit selection for Developer to apply when creating it.
4. Apply only at a safe Developer boundary. Developer applies the pending choice during normal DEVELOPING, before its next implementation action or checkpoint assignment. Finish any already assigned Tester assessment and its required return first. During recovery, defer application until the preserved route returns to normal development. Until then, the saved effective setting governs the assignment.
5. Reconcile scheduling under existing approval rules. When enabling INCREMENTAL, group planned work into testable outcomes and select the next increment, including implemented work still needing assessment. When enabling AFTER_IMPLEMENTATION at the safe boundary, clear Current Increment, including an increment selected but not yet handed to Tester, and schedule remaining implementation before full verification. Retain previous increment definitions and evidence; reconcile changed inputs under normal ownership. Pure cadence selection and grouping of unchanged approved steps do not require duplicate approval. Material changes to steps, dependencies, behavior, or technical approach still require plan approval.
6. Save effective selection before clearing pending intent. Persist the plan’s cadence and reconciled scheduling first, then clear Active Work.PendingVerificationCadence to NONE. If interrupted between those writes, Developer reconciles the matching request and clears it idempotently. Report whether the switch was applied or remains pending.

Cycle lifecycle rules clear pending intent on cancellation, sign-off, reset, or new-cycle initialization; it never becomes a preference for a later cycle.

Promote an expedited cycle

An explicit user instruction may authorize Expedited Promotion in .standards/protocol/expedited.md from any nonterminal expedited brownfield state, including AWAITING_USER_SIGNOFF. After persisting promotion, stop and hand off to Auditor unless Auditor was also explicitly invoked.

Sign off

From AWAITING_USER_SIGNOFF, sign-off is legal only when the Outstanding Obligations section is inactive. Revalidate the current mode’s completion contract: Standard Cycle Completion, including every standard gate applicable to Active Work.CompletionPolicy and the acceptance-traceability obligations, or, for EXPEDITED, only the narrower Expedited Cycle Contract in .standards/protocol/expedited.md; skipped standard phases must not be represented as completed. For DOCUMENTATION, revalidate Documentation Cycle Contract, including current final review and synchronization evidence, without demanding omitted implementation artifacts. For IMPLEMENTATION_REVIEWED, inspect the implementation report’s separate closure assessment, its recorded user choice, evidence references, and assessed input identities. Require a COMPLETE ordinary review and current ELIGIBLE closure, with the omitted guarantees made clear. Check current inputs instead of trusting the saved label alone. If evidence or eligibility is invalidated, use owner-directed recovery and Reviewer reassessment under Recovery Mechanics; the agent recording sign-off does not author a replacement review conclusion. An unchanged, applicable assessment does not require another review merely because the user is now accepting it. Then transition to SIGNED_OFF, set CycleMode: UNSET, leave all pending-cycle fields clear, record Handoff.Kind: SIGNOFF, From: AWAITING_USER_SIGNOFF, and FailureType: NONE, clear Active Work.PendingVerificationCadence to NONE, preserve Active Work.CompletionPolicy, and clear recovery. The cycle is complete. A policy-selection instruction alone is not user sign-off.

Cancel an active cycle

• If ProjectMode: GREENFIELD, follow Greenfield Bootstrap Cancellation, including explicit approval of the reset before it runs.
• If ProjectMode: BROWNFIELD, transition to CANCELLED, set CycleMode: UNSET, leave all pending-cycle fields clear, record Handoff.Kind: CANCEL, set From to the interrupted state, FailureType: NONE, preserve Active Work except for clearing PendingVerificationCadence to NONE, and clear recovery plus outstanding obligations. Preserve Active Work.CompletionPolicy as historical context. Residual project-change provenance is handled through BaselineReconciliation when a later cycle starts.

Cancellation never reverts project artifacts and does not by itself establish cancelled-cycle project changes as baseline.

Greenfield Bootstrap Cancellation

If cancellation occurs while ProjectMode is still GREENFIELD, first verify that the active cycle has not successfully created or materially modified a project implementation artifact, regardless of authorship. If it has, persist the permanent BROWNFIELD transition and use retained brownfield CANCELLED semantics instead, even if recovery has moved to an earlier workflow state. Only when no such implementation exists is cancellation a reset of the workflow rather than a reusable terminal cycle.

The agent performs the reset with Project Reset, following Running the CLI, both in .standards/protocol/installation.md:

1. Use standards reset --mode greenfield if a globally installed STANDARDS CLI has the version recorded in .standards/VERSION.json; otherwise use npx @idinsight/standards@<that version> reset --mode greenfield. The cycle produced no implementation, so the project stays GREENFIELD; do not let the reset choose the mode from the project’s files.
2. Preview it with --dry-run, which may run before approval. Also warn that the reset deletes the saved workflow state, the Auditor’s project context, and every cycle record under .standards/docs/, and that the skills, hooks, client settings, and user styles stay installed.
3. Ask for explicit approval to run the exact command with --yes. A generic cancellation request does not grant it. Record the target, command, and pending approval in Active Work.BlockedOn, preserving any other unresolved questions, and keep the workflow state, cycle mode, recovery, and outstanding obligations intact while waiting. Do not record CANCELLED or continue role work while approval is pending. A resumed chat must resolve the saved question; silence or a request to continue is not approval.
4. After approval, recheck bootstrap eligibility and the preview. If implementation now exists, persist BROWNFIELD and use retained cancellation instead. If the target, command, planned changes, or warnings changed, obtain fresh approval for the updated preview. Otherwise run the approved command with --yes; the flag avoids a second CLI prompt and never substitutes for user approval.
5. Confirm that the reset succeeded before reporting the cancellation complete. Do not edit STATE.md afterwards to record it; the fresh state is the result. Reset approval authorizes only the reset, not starting a new cycle or resuming role work. After reporting success, stop and wait for a new request.

If approval is declined, clear only the approval question, keep the active cycle, and report that cancellation was not completed; further role work requires a user instruction to continue. If a matching CLI is unavailable, the preview fails, or the reset refuses or fails, stop and report that cancellation did not complete, including any backups the CLI reports, and do not work around a refusal by switching commands or by deleting or rewriting the files yourself. A retry requires a valid preview and approval covering it.

The reset leaves no CANCELLED state or cycle record behind, so the next request starts a first greenfield cycle from the fresh state. S.T.A.N.D.A.R.D.S. does not revert the project working tree; reverting project changes is the user’s responsibility.

Cycle IDs

Every cycle has a unique ID. Get it only from node .standards/bin/cycle.mjs new --request "<request>". The tool:

1. builds an ID from the request, the UTC time, and eight random hex digits, for example add-user-search-20260927T190146Z-7bef0f04;
2. checks that no cycle-owned artifact path or STANDARDS provenance block uses it; and
3. prints it without changing any file.

It refuses while a cycle is active (Active Work.Id is set and the state is not terminal), when STATE.md has a merge conflict, and when STATE.md is invalid. Only after the tool succeeds may the printed ID be written to Active Work.Id and cycle initialization continue. If initialization fails afterwards, run the tool again for the next attempt; an unused ID needs no cleanup.

Never write a cycle ID yourself or reuse one. check reports an Active Work.Id that does not have the generated form, and a cycle that is active under the ID of a cycle that the last commit ended in SIGNED_OFF or CANCELLED: a new cycle always gets a new ID, and a finished cycle is never reopened.