Delivery Phase Flow Optimization Glossary

This glossary defines accepted language for a faster prompt-level delivery flow. The user-selected native harness remains the executor. The model adds no Delivery runtime, scheduler, journal, watcher, lock, or cache.

Terms

Execution Frontier

Worker-worthy Tasks whose dependencies passed Task Gates and whose required Active Write Scopes are available now.

Task Gate

The smallest parent-owned validation that proves one completed Task is safe for dependents to consume.

Active Write Scope

Paths exclusively owned by one currently running implementation worker on the shared current branch.

Read Dependency

An authority, path, generated output, or runtime input a Task must observe to implement or validate its outcome.

Shared Runtime Resource

A service, database, port, process, or other mutable runtime input whose concurrent use can affect execution or evidence.

Relevant Input Set

The read dependencies and shared runtime resources whose identity and state must remain stable for a Task or evidence record to remain valid.

Derived Context Excerpt

A bounded source-attributed excerpt or rationale carried in disposable context to avoid a predictable lookup. It includes source identity and freshness, and remains non-authoritative.

Diagnostic Evidence

New actionable evidence produced by bounded authorized diagnosis that discriminates between hypotheses and can justify a subsequent repair or request for user direction.

Context Pointer

A reference containing authority kind, stable locator, optional selector, content or state identity, and the freshness rule its consumer must check.

Delivery Context Packet

A disposable current-task projection containing identities, Context Pointers, freshness, current action, blocker, and stop condition needed to route Full Delivery. It may carry bounded source-attributed derived excerpts with source identity and freshness solely to avoid predictable lookups; those excerpts remain non-authoritative.

Phase Result

A compact phase-exit result with one common outcome, changed authority or evidence, invalidations, next routing, blocker, stop reason, and only the next Context Pointers.

Task Result

A compact evidence-bearing return from one scoped implementation worker for parent Task Gate evaluation.

Worker-worthy Task

An atomic, cohesive implementation outcome with exclusive paths, an acceptance boundary, and Task Gate checks.

Architecture Checkpoint

A declared cumulative barrier for ownership, dependency, public-seam, responsibility, and migration conformance.

Review Packet

Prepared factual frozen target, rules, evidence, and relevant dependencies for one Full Code Review Pass; it contains no persuasion narrative and avoids target rediscovery.

Review Lens Result

A compact result from the comprehensive primary reviewer or independent risk-focused challenger containing assigned coverage identity, Review Packet identity, and one outcome: clean, findings, or incomplete. clean means assigned coverage completed with no candidates; findings means assigned coverage completed with candidates; incomplete records missing coverage, cause, and follow-up and may retain candidates already found. An incomplete result cannot complete a pass.

Full Code Review Pass

One complete review-phase run over one frozen implemented change using every mandatory Code Review lens.

Focused Repair Validation

Checks tied to accepted Code Review findings and the surfaces changed by their repairs.

Delivery Handoff

A compact cross-task record of goal, bounds, Git identity, next action, Context Pointers, relevant provider identities, blocker, and explicit unknowns.

Relationships

• A Delivery Context Packet is updated from each Phase Result and never replaces pointed authorities.
• implement-spec recomputes the Execution Frontier after the parent records a Task Gate result.
• The parent delegates every implementation edit, validates each Task Result, dispatches newly eligible Worker-worthy Tasks, and alone updates shared summaries.
• implement-spec owns Verification through verify-behavior and the Project Verifier.
• One prepared Review Packet supplies frozen authority to autoreview as the comprehensive primary reviewer and to an independent risk-focused challenger; the primary covers all five retained obligations and the challenger sees no primary conclusions.
• After implement-spec completes, delivery-phase invokes review-phase for one Full Code Review Pass.
• Focused Repair Validation follows accepted review repairs. Verification reruns only when a repair invalidates its evidence.
• Delivery Handoff crosses tasks. The receiving task cold-routes and creates a new Delivery Context Packet only when Full Delivery continues.

Axioms

• Durable source artifacts remain authoritative. Packets and results carry identities, pointers, deltas, and bounded source-attributed excerpts where contracts permit; excerpts never supersede sources.
• The native harness executes. The parent orchestrates and owns shared projections and gates. Scoped workers perform every implementation edit.
• A passed Task Gate can release dependents before unrelated workers finish and before shared-summary reconciliation finishes.
• Shared-summary reconciliation finishes before an applicable Architecture Checkpoint or finalization.
• Verification and Code Review remain separate gates with separate evidence.
• Normal delivery runs one Full Code Review Pass. Ordinary repairs receive Focused Repair Validation; only accepted high-risk repairs can trigger a second pass.
• A failed Task blocks only its dependent chain. Independent disjoint Tasks continue.
• A repair retry requires new actionable evidence. Stagnation, redesign, or a weaker-gate request returns human_steering_required.
• Authorized hypothesis-discriminating diagnosis may continue before repair while it can produce new actionable evidence.
• Read dependencies, shared runtime resources, and evidence-stability inputs are planned by the swarm-planner primitive within create-plan, the planning step of delivery-phase; no runtime lock or execution service is introduced.
• Warm and cold describe routing cost, not durable lifecycle states.
• Faster delivery cannot weaken an applicable assurance gate.

Source Decisions

• Delivery Optimization Grill Status
• Delivery Optimization Grill Log
• Project Verification Capability Glossary
• Implement Spec Execution Policy Glossary