Glossary

These definitions explain the terms used throughout the documentation. The protocol and role instructions provide the full rules.

Acceptance identifier

Scoper’s stable AC-NNN label for a checkable outcome, reused in the design, implementation plan, and evidence. It identifies the condition, not its priority or execution order. See acceptance traceability.

Active work

The Active Work section in STATE.md: the cycle’s ID, request, document paths, promotion reason, audit target, unresolved cancelled changes, pending verification cadence, completion policy, and blocking question. After retained cancellation or sign-off, it describes the last cycle until a new one replaces it.

Artifact provenance

A marker in a workflow document that identifies its type and owning cycle. Review reports also name the review kind. Moving or renaming the file does not change its ownership. See file ownership.

Assessment purpose

The scope of Tester’s current assignment: FULL for the whole implementation, INCREMENT for a selected testable outcome, or CORRECTION for a specific recovery task. It is separate from Tester’s VERIFY and REVERIFY modes. See Tester.

Baseline

Established facts about the existing project that later work must understand and respect. Auditor records them in project context. A planned design or tentative implementation does not become established merely because it is mentioned there.

Baseline reconciliation

Auditor’s check of changes left by cancelled cycles: which are accepted parts of the project, which were reverted, and which still need a decision. Active Work.BaselineReconciliation keeps each source cycle’s ID and request until all sources are resolved.

Checkpoint handoff

A normal Developer-to-Tester assignment of a ready increment or Tester’s verified return to Developer. It keeps the cycle’s implementation or verification in progress and creates no recovery frame. See incremental verification.

Completed scope

A saved scope that has passed Scoper’s completion checks. Separate user approval is needed only if the project requires it.

Completion gate

The checks a role must pass before full completion. An incremental checkpoint uses an assignment gate, and a scoped correction can return before unrelated work is finished. See the corrective return rules.

Completion policy

A standard cycle’s choice of checks before sign-off. FULL_DELIVERABLE includes all standard phases. IMPLEMENTATION_REVIEWED keeps all steps through implementation review and requires a separate check that no required work remains. The choice applies to one cycle and is saved in Active Work.CompletionPolicy. See Finishing After Implementation Review.

Cycle

One piece of work, from its saved request to sign-off or cancellation. Rework, recovery, and promotion stay within that cycle. Work after a cycle ends needs a new ID and cycle.

Cycle ID

A cycle’s unique name, such as add-user-search-20260927T190146Z-7bef0f04, built from the request, the UTC time, and random hex digits. The agent gets it from node .standards/bin/cycle.mjs new when the cycle starts and saves it in Active Work.Id. No one writes an ID by hand or reuses one. See cycle identity.

Cycle mode

The workflow chosen for one cycle: STANDARD, EXPEDITED, or DOCUMENTATION. UNSET means no cycle is active, so workflow work cannot begin. Navigator can still explain available project evidence.

Development plan

Developer’s saved implementation steps, approval status, collaboration mode, verification cadence, increments, and progress. The initial plan and material revisions need approval before implementation. See Developer.

Development step

One implementation outcome in the plan, identified by DEV-NNN, with dependencies, progress, and a way to check the result. Step IDs are distinct from Scoper’s AC-NNN requirement IDs.

Documentation cycle

A Brownfield workflow for documentation of existing behavior: Auditor, Scoper, Architect, Documenter, final Reviewer, and Synchronizer before user sign-off. It omits implementation and formal testing, and cannot convert in place. See Updating Documentation on Its Own.

Documentation record

Documenter’s account of documentation inspected or changed, checks performed, limitations, remaining work, and collaboration choices. The record belongs to one cycle; the guides and docstrings it describes remain reusable project files. See the template.

Expedited cycle

A bounded brownfield change handled by Developer and implementation Reviewer before user sign-off. It provides fewer checks than standard work and must be promoted if a skipped role becomes necessary.

Failure handoff

Sending a defect to the role responsible for the affected decision or file. Discovering the problem does not give a role ownership of the fix.

Forward handoff

Moving to the next normal workflow step after the current role passes its completion checks.

Handoff

A recorded move to another workflow step, with the reason for that move. When another role needs to take over, the agent tells you how to invoke it. Saving the handoff does not start that role automatically. See workflow states and handoffs.

Outstanding obligation

An unfinished correction saved separately when promotion replaces its recovery route. The responsible role removes it after verifying the fix; its other completion checks still apply. See recovery obligations.

Pending cycle fields

A saved preference or blocked request for the next cycle, kept separately from active work. The agent reuses the saved request when its blocking decision is resolved. See Starting a Cycle.

Project context

Auditor’s record of relevant existing behavior, tools, commands, constraints, and evidence in .standards/CONTEXT.md. Earlier context must be checked before it is relied on as current. See Auditor.

Project mode

Whether the project has meaningful implementation to account for (BROWNFIELD) or not yet (GREENFIELD). Developer permanently changes greenfield to brownfield when it verifies that implementation has been created or materially changed. See project modes.

Project reset

standards reset, which returns an installed project’s workflow to the state of a fresh installation. It deletes the saved workflow state, Auditor context, and cycle records, chooses the project mode again, and keeps everything else installed. See Reset the workflow.

Promotion

The one-way change from expedited to standard work. It keeps the cycle and starts the standard brownfield sequence with Auditor. Also called a promotion handoff. See promotion.

Recovery frame

A saved correction and its return instructions: who fixes it, why, where interrupted work resumes, and which affected work needs repeating. Nested corrections are handled newest first. See Recovery.

Resume handoff

Returning to ResumeAt after a recovery frame is complete, or taking another recovery-directed transition outside the normal forward sequence.

Retired acceptance identifier

An ID for a removed or replaced acceptance condition. It stays in the history but cannot be reused within that cycle or counted as a current requirement.

Review report

Reviewer’s independent assessment for one cycle and review kind, including the evidence checked, findings, limitations, and conclusion. Passing review does not complete the cycle or provide user sign-off. See the template.

Role mode

A choice of how one role works, such as Developer’s STEPWISE or Navigator’s EXPLAIN. It does not change project mode, cycle mode, or workflow state.

Runtime tools

The Node.js tools in .standards/bin/: cycle.mjs generates cycle IDs, artifact.mjs creates cycle records, id.mjs numbers their entries, and check.mjs checks the workflow files. See runtime tools.

Scope-level acceptance condition

An observable outcome used to decide whether a requirement is met. Scoper defines it and gives it an AC-NNN ID. Separate outcomes checked by different roles need separate conditions.

Sign-off

Your acceptance of the finished work from AWAITING_USER_SIGNOFF, after the applicable completion requirements have been checked against current files. It ends the cycle in SIGNED_OFF. Readiness for sign-off is not acceptance.

Standard cycle

The workflow that keeps requirements, design, audit, implementation, full verification, and implementation review. Its completion policy determines whether normal documentation, final review, and synchronization follow. The default includes all three. The starting role depends on project mode. See workflow paths.

STANDARDS hook

A Claude Code or Codex stop hook, added by the installer, that runs .standards/bin/hook.mjs to check the workflow files when the agent finishes a turn. See Hooks.

Synchronization record

Synchronizer’s record of whether completed assessments and their evidence still apply to the current files. It records disagreements, limitations, and what must happen next. It does not replace another role’s evidence or your sign-off. See the template.

Technical acceptance criterion

A technical condition Architect derives from a scope acceptance condition. It references the existing acceptance ID rather than creating a new requirement identity.

Testable increment

An observable implementation outcome ready for independent testing, usually one acceptance condition or a small dependent group. It can span multiple development steps and revisit previously tested work. See Working with Developer.

User style

A Markdown file of your personal preferences for one role, kept at .standards/user-styles/<role>/<name>.md. A role applies it only when you select it by name, and only to discretionary choices. See user styles.

Verification cadence

When Developer hands work to Tester in a standard cycle: AFTER_IMPLEMENTATION (the default) or INCREMENTAL. It is independent of Developer’s collaboration mode. See choosing and switching cadence.

Verification report

Tester’s record of its current assessment assignment, increment history, acceptance coverage, test-scenario allocations, actual results, gaps, and permitted dependencies. It belongs to a cycle and is separate from reusable test files. See the template.

Workflow state

The current step or ended cycle’s state, saved as WorkflowState in STATE.md. It determines which workflow role may act; it does not invoke that role. Navigator operates outside the workflow state machine.