Implement Spec Execution Policy Glossary
Canonical language for dynamic implementation scheduling, task release, verification, pull-request visibility, and bounded code review
Implement Spec Execution Policy Glossary
This glossary defines the accepted language for implementing an agent-ready specification with high throughput and risk-triggered assurance.
Terms
Execution Frontier
Tasks whose dependencies have passed their Task Gates, whose required Active Write Scopes are available, and whose declared read, write, and shared-runtime conflicts permit release now.
Task Gate
The smallest validation and parent check that makes one completed task safe for its dependents to consume.
Active Write Scope
Paths exclusively owned by one currently running worker in the shared current branch.
Context Pointer
A stable reference to authoritative specification, plan, code, test, architecture, or skill content that avoids copying that content into a task record or worker brief.
Architecture Checkpoint
A declared cumulative barrier for ownership, dependency, public-seam, responsibility, and migration conformance.
Meaningful Pushed Commit
A pushed commit on the recorded branch that contains in-scope specification or implementation changes. An empty commit or a commit containing only unrelated work is not meaningful.
Verification
Exercise observable product behavior through a real user path and retain evidence of the action, resulting state, and applicable side effects.
Project Verifier
Project-owned app-specific executable knowledge consumed through the single verify-behavior entrypoint.
Full Code Review Pass
One complete review-phase run over a frozen implemented change with explicit coverage of all five mandatory Code Review axes, one comprehensive primary reviewer, and one mandatory independent risk-focused challenger for a bounded independent risk area. Additional challengers may be assigned when larger changes require separate independent risk areas. It does not run the product or perform Verification. Avoid the ambiguous phrase "full review."
Focused Repair Validation
Checks tied to accepted Code Review findings and the surfaces changed by their repairs.
Read Dependency
A declared input that a task must inspect or consume and whose change can invalidate the task's evidence.
Shared Runtime Resource
A service, database, port, build output, or other execution resource whose concurrent use can interfere with a task's work or evidence.
Relevant Input Set
The declared read dependencies and shared runtime resources whose stability bounds a task's valid evidence.
Derived Context Excerpt
A bounded source-attributed summary or rationale included to avoid a predictable lookup. It carries a resolvable Context Pointer and freshness information and remains subordinate to its authority source.
Diagnostic Evidence
New observation gathered by authorized inspection or tracing that distinguishes plausible causes and justifies a repair or request for user direction.
Relationships
implement-specrecomputes the Execution Frontier after each Task Gate result.- A task enters the Execution Frontier only when its dependencies have passed, its Active Write Scope is available, and its declared read, write, and shared-runtime conflicts permit release.
- An Architecture Checkpoint or declared relevant-input conflict may block otherwise eligible tasks.
implement-specperforms Verification throughverify-behaviorand the Project Verifier, completes implementation, and returns control todelivery-phase.- The subsequent
delivery-phasereview step invokesreview-phasefor one Full Code Review Pass over the frozen implemented change. review-phasemay inspect retained Verification evidence but does not create or refresh it.- Focused Repair Validation follows accepted review repairs. Affected Verification returns to
implement-specownership when repair changes invalidate its evidence. - The
swarm-plannerprimitive of thecreate-planstep ofdelivery-phaserecords Read Dependencies and Shared Runtime Resources with each Active Write Scope. - A Task Gate is valid only against a stable Relevant Input Set; changes invalidate affected evidence before dependent release or finalization.
- A Derived Context Excerpt may shorten a brief but never becomes a competing authority.
- Authorized diagnosis may produce Diagnostic Evidence before another repair; retries require useful evidence or remaining diagnostic options, otherwise report the blocker and request user direction.
- An interrupted or invalidated Full Code Review Pass is incomplete and does not consume the completed-pass allowance.
Axioms
- Unrelated slow work does not delay an otherwise safe dependent task.
- Concurrent workers write in one current branch and never share an Active Write Scope.
- A passed Task Gate can release dependents before shared-artifact reconciliation finishes.
- Shared-artifact reconciliation finishes before an applicable Architecture Checkpoint or finalization.
- Architecture, runtime, UI, provider, and acceptance proof remain when applicable.
- Verification and Code Review remain separate gates with separate evidence.
- An eager draft pull request starts after the first Meaningful Pushed Commit and preserves accepted branch, base, and stack intent.
- Normal delivery runs one Full Code Review Pass with one comprehensive primary reviewer and one mandatory independent risk-focused challenger; additional challengers may be assigned when larger changes require separate independent risk areas. A second pass is reserved for accepted high-risk repair triggers.
- Review topology details belong to the Delivery Phase Flow Optimization specification.
- During-pass semantic invalidation requires a fresh pass over the new frozen target; after-pass ordinary repairs use Focused Repair Validation and affected Verification reruns.