Spec: Dynamic Implement Spec Execution Policy

Context

Harness implements an agent-ready plan through scoped workers, applicable assurance gates, final acceptance, and a subsequent delivery review. The current execution model groups ready tasks into worker waves and waits for a complete wave review before it releases newly eligible dependents. Task records and worker briefs also repeat source content, while delivery can repeat complete Code Review passes after repairs.

Implementation orchestrators need a lower-latency execution policy that starts safe dependent work promptly, keeps workers on the current branch, reduces copied context, provides early pull-request visibility, and limits repeated Code Review. The stronger architecture, Verification, runtime, UI, provider, and acceptance boundaries remain authoritative.

Non-Goals

• Create worker worktrees, worker branches, or merger agents.
• Remove applicable TDD, runtime, UI, provider-readback, architecture, Verification, or final acceptance gates.
• Move Verification, Project Verifier execution, or Verification evidence freshness into review-phase.
• Replace Code Review with Verification or Verification with Code Review.
• Create one pull request per plan task or turn plan dependencies into pull-request stack dependencies.
• Integrate an external GitHub or Codex pull-request reviewer.
• Define provider Epic, Story, or Task identities.
• Define implementation files, commands, task estimates, or worker assignments.

Requirements and Outcomes

OUT-001: Continuous safe task release

An implementation orchestrator can release a dependent task as soon as each of its own prerequisites passes its Task Gate, without waiting for unrelated running work.

OUT-002: Shared-current-branch worker isolation

Scoped implementation workers can write directly in the recorded current branch while exclusive Active Write Scopes prevent concurrent ownership collisions.

OUT-003: Compact authoritative task context

Plans and worker briefs keep a small inline execution kernel and use Context Pointers to progressively disclose authoritative detail without copying it.

OUT-004: Risk-triggered assurance

Faster scheduling does not weaken applicable task checks, Architecture Checkpoints, Verification, runtime, UI, provider, or final acceptance proof.

OUT-005: Early durable pull-request visibility

Implementation creates or reuses a draft pull request after meaningful pushed branch state exists, while preserving accepted branch, base, and stack intent.

OUT-006: Bounded post-implementation Code Review

After implement-spec completes, the subsequent delivery-phase review step performs one Full Code Review Pass by default and escalates only after accepted high-risk repairs.

OUT-007: Accurate asynchronous execution records

Dependents can start before shared execution records are fully reconciled, while those records remain authoritative and complete before architecture or final completion gates.

OUT-008: Conflict-aware frontier release

The swarm-planner primitive of the create-plan step of delivery-phase records relevant read dependencies and shared runtime resources alongside each task's Active Write Scope so the Execution Frontier releases work only when its relevant inputs and resources are stable.

OUT-009: Efficient derived context

Plans and worker briefs can include bounded, source-attributed derived context excerpts or rationale with a Context Pointer and freshness marker when that avoids a predictable lookup, without creating competing authority.

OUT-010: Productive diagnosis and bounded recovery

Authorized diagnosis can continue long enough to produce discriminating evidence before another repair is attempted; execution hands back when progress requires an out-of-bounds decision, unavailable access, changed requirements, or useful diagnosis is exhausted.

OUT-011: Explicit review attempt state

Delivery distinguishes an incomplete or invalidated Full Code Review Pass from a completed pass and applies the accepted two-pass policy without counting interrupted attempts as completed passes or allowing stagnant repair loops.

Acceptance Criteria

• AC-001: When a task passes its Task Gate, every dependent whose other prerequisites have passed, whose Active Write Scope is available, and whose declared read, write, and shared-runtime conflicts permit release becomes eligible immediately.
  • Covers: OUT-001
• AC-002: A running unrelated task with no declared read, write, or shared-runtime conflict does not delay an otherwise eligible dependent.
  • Covers: OUT-001
• AC-003: A failed or incomplete Task Gate keeps that task's dependents ineligible while independent eligible work may continue.
  • Covers: OUT-001
• AC-004: Each Task Gate requires the task's RED/GREEN target, relevant typecheck, relevant lint, parent task-local acceptance, and Active Write Scope check to pass.
  • Covers: OUT-001, OUT-004
• AC-005: Every implementation worker writes in the recorded current branch without creating a worker worktree or worker branch.
  • Covers: OUT-002
• AC-006: Two workers with overlapping Active Write Scopes are never active concurrently.
  • Covers: OUT-002
• AC-007: Every task keeps inline its identity, dependencies, owned paths, intended outcome and acceptance references, validation and required RED/GREEN commands, applicable risk gates and Architecture Checkpoint identifiers, execution status, and provider identity when applicable.
  • Covers: OUT-003
• AC-008: Specification detail, code symbols, architecture views, and exact skill guidance are supplied through resolvable Context Pointers, with only bounded source-attributed derived context excerpts or rationale retained inline when they avoid a predictable lookup.
  • Covers: OUT-003
• AC-009: Applicable TDD, runtime, UI, provider-readback, Verification, and final acceptance gates retain their existing completion authority.
  • Covers: OUT-004
• AC-010: An Architecture Checkpoint blocks affected dependent work until cumulative ownership, dependency, public-seam, responsibility, and migration conformance passes.
  • Covers: OUT-004
• AC-011: Architecture-bearing completion still requires final zero drift and an empty migration ledger.
  • Covers: OUT-004
• AC-012: Verification normally blocks final acceptance rather than ordinary task release.
  • Covers: OUT-004
• AC-013: Verification becomes part of a Task Gate only when that task owns a complete visible journey or runtime side effect consumed by a dependent.
  • Covers: OUT-001, OUT-004
• AC-014: When selected behavior is absent from the Feature Map, implement-spec completes the accepted Uncovered Behavior update path before it classifies the affected Verification result.
  • Covers: OUT-004
• AC-015: After the branch and base gate passes, the first pushed commit containing in-scope specification or implementation changes creates or updates one draft pull request for the recorded branch.
  • Covers: OUT-005
• AC-016: If the recorded branch already has a meaningful pushed commit, implementation creates or reuses its draft pull request before further implementation work.
  • Covers: OUT-005
• AC-017: Implementation never creates an empty commit only to open the draft pull request.
  • Covers: OUT-005
• AC-018: implement-spec completes implementation, task checks, Verification, and final acceptance evidence before it returns control to delivery-phase for Code Review.
  • Covers: OUT-004, OUT-006
• AC-019: The subsequent delivery-phase review step invokes one Full Code Review Pass by default over the frozen implemented change.
  • Covers: OUT-006
• AC-020: After accepted review repairs, delivery runs Focused Repair Validation and reruns only Verification scenarios whose evidence the repair invalidated.
  • Covers: OUT-004, OUT-006
• AC-021: An ordinary review repair does not automatically cause a second Full Code Review Pass.
  • Covers: OUT-006
• AC-022: One second Full Code Review Pass runs only when an accepted repair changes architecture, security or authorization, a public contract, runtime or deployment topology, or accepted scope.
  • Covers: OUT-006
• AC-023: Delivery does not run more than two Full Code Review Passes in one delivery goal without explicit human direction.
  • Covers: OUT-006
• AC-024: PLAN.md and IMPLEMENTATION-NOTES.md reconciliation may finish after dependent dispatch but always finishes before an applicable Architecture Checkpoint or finalization.
  • Covers: OUT-007
• AC-025: Execution state distinguishes a passed Task Gate, completed shared-artifact reconciliation, final acceptance, and post-implementation Code Review.
  • Covers: OUT-007
• AC-026: The swarm-planner primitive of the create-plan step of delivery-phase records each task's relevant read dependencies and shared runtime resources in addition to its Active Write Scope.
  • Covers: OUT-008
• AC-027: The Execution Frontier does not release a task while a declared read/write or shared-runtime conflict can change its relevant inputs; unrelated disjoint work remains eligible.
  • Covers: OUT-008
• AC-028: A Task Gate's checks are valid only against stable relevant inputs, and a change to those inputs invalidates the affected evidence and schedules the affected checks again before dependent release or finalization.
  • Covers: OUT-008
• AC-029: A plan or worker brief may contain a bounded derived context excerpt or rationale only when it identifies its authoritative source, retains a resolvable Context Pointer, and records freshness sufficient to detect staleness.
  • Covers: OUT-009
• AC-030: Derived context remains subordinate to its source and cannot replace or silently diverge from the authoritative specification, plan, code, architecture, or skill guidance.
  • Covers: OUT-009
• AC-031: Authorized diagnosis may inspect, trace, or otherwise gather new evidence that distinguishes plausible causes before proposing or applying another repair.
  • Covers: OUT-010
• AC-032: Execution hands back when progress requires changed requirements, a weaker gate, an out-of-bounds decision or access, or useful authorized diagnosis is exhausted; it does not repeat a repair without new actionable evidence.
  • Covers: OUT-010
• AC-033: A Full Code Review Pass that is interrupted, incomplete, or invalidated is recorded as not clean and not completed, and does not consume the completed-pass allowance.
  • Covers: OUT-011
• AC-034: A semantic target change during an active review invalidates that pass and requires a fresh pass over the new frozen target; an accepted ordinary repair after a completed pass uses Focused Repair Validation and affected Verification reruns.
  • Covers: OUT-011
• AC-035: Delivery does not silently treat a stagnant repair loop as progress or retry without useful evidence or remaining diagnostic options, and preserves the two completed Full Code Review Pass ceiling without explicit human direction.
  • Covers: OUT-011
• AC-036: A Full Code Review Pass completes one comprehensive primary review with explicit coverage of all five mandatory axes 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 require five separate review workers. The parent adjudicates findings and owns the report; incomplete primary or challenger coverage is not clean or complete.
  • Covers: OUT-006, OUT-011

Constraints

• Preserve the canonical terms in the Implement Spec Execution Policy Glossary and Project Verification Capability Glossary.
• Preserve one recorded current branch throughout an implement-spec run.
• Preserve unrelated worktree changes and enforce disjoint Active Write Scopes.
• Preserve provider task identities and provider-readback authority when provider tasks apply.
• Preserve cumulative Architecture Checkpoints and final zero-drift closure for architecture-bearing plans.
• Preserve verify-behavior as the single Verification entrypoint and Project Verifier content as project-owned executable knowledge.
• Keep review-phase readonly and separate from Verification execution and freshness.
• Use the detailed review topology defined by the Delivery Phase Flow Optimization specification without duplicating that contract here.
• Reusable skill changes originate in the shared Devpunks skills authority before Harness projections update.

Dependency Readiness

No Stack Required.

The Project Verification Capability specification at immutable commit 120c99c8afe8ae5894531fa24b4f52d4f05b69b4 is accepted requirements evidence for the Verification and Code Review boundary. This specification does not require its implementation to be landed as a code dependency.

Branch/Base Intent

Not applicable.

Accepted Technical Decisions

• Replace ordinary worker-wave release barriers with an Execution Frontier recomputed after each Task Gate result.
• Keep workers on the current branch and use exclusive Active Write Scopes instead of worker worktrees or merger agents.
• Separate task release, shared-artifact reconciliation, final acceptance, and post-implementation Code Review states.
• Keep Architecture Checkpoints as explicit cumulative barriers; ordinary scheduling batches do not become architecture barriers.
• Use Context Pointers for progressively disclosed specification, code, architecture, and skill detail.
• Permit bounded source-attributed derived context excerpts or rationale with pointers and freshness when they avoid predictable lookups; the source remains authoritative.
• In the swarm-planner primitive of the create-plan step of delivery-phase, record read dependencies and shared runtime resources alongside Active Write Scopes and invalidate affected evidence when relevant inputs change.
• Allow authorized diagnosis to produce discriminating evidence before another repair; hand back at an actual boundary or when useful diagnosis is exhausted.
• Create or reuse a draft pull request after the first meaningful pushed commit and accepted branch/base gate.
• Complete implement-spec before the subsequent delivery-phase review step invokes review-phase.
• Default to one Full Code Review Pass; reserve a second pass for accepted high-risk repair triggers and require explicit human direction beyond two.
• A Full Code Review Pass uses one comprehensive primary reviewer for all mandatory coverage and one mandatory independent risk-focused challenger for a bounded independent risk area; additional challengers may be added when larger changes require separate independent risk areas. It does not require five separate review workers, with parent adjudication and report ownership.

Accepted Testing Decisions

• Prove that a short prerequisite releases its dependent while an unrelated longer task remains active.
• Prove that a failed Task Gate blocks only its dependents and does not stop independent eligible work.
• Prove that overlapping Active Write Scopes cannot run concurrently on the shared branch.
• Prove the minimum inline task kernel and Context Pointer progressive-disclosure contract.
• Prove that ordinary task release does not wait for final Verification, with the accepted consumed-visible-result exception.
• Prove that Architecture Checkpoints still block affected work and final closure still requires zero drift with an empty migration ledger.
• Prove draft pull-request creation for the first meaningful pushed commit, reuse for an existing pull request, and no empty-commit path.
• Prove that Code Review occurs only after implement-spec returns to delivery-phase.
• Prove one default Full Code Review Pass, focused post-repair checks, affected Verification reruns, risk-triggered second review, and the two-pass ceiling.
• Prove shared-artifact reconciliation completes before Architecture Checkpoints and finalization even when dependent dispatch occurs first.
• Prove the swarm-planner primitive of the create-plan step of delivery-phase records read dependencies and shared runtime resources, blocks only conflicting frontier releases, and invalidates affected evidence after relevant input changes.
• Prove bounded derived context remains source-attributed, pointer-resolvable, and freshness-aware without competing authority.
• Prove authorized diagnosis can produce new evidence before a justified repair and that stagnant repair loops hand back.
• Prove interrupted or invalidated review attempts are incomplete and do not consume the completed Full Code Review Pass allowance; preserve the accepted semantic-invalidation and ordinary-repair routes.

Verification Seams

• Execution Frontier state shows task eligibility changing immediately after a prerequisite Task Gate passes.
• Active Write Scope state shows exclusive ownership for every running worker.
• Plan and worker-brief outputs expose the minimum inline execution kernel and resolve each Context Pointer to its authority.
• Draft pull-request provider state proves branch/base intent, meaningful pushed state, and one pull request for the recorded branch.
• implement-spec completion evidence proves task checks, applicable Architecture Checkpoints, Verification, shared-artifact reconciliation, and final acceptance before delivery review begins.
• The delivery review handoff and retained review report prove one default Full Code Review Pass, accepted repair routing, focused validation, affected Verification reruns, and any qualifying second-pass trigger.

Parked Decisions

• External GitHub or Codex pull-request reviewer integration. Owner: Harness maintainers. Resume trigger: an explicit request to combine external reviewer findings with the delivery review budget.

Decision Log