Implement Spec Execution Policy Grill Log

Scope

Evolve implement-spec for higher throughput without weakening its risk-triggered assurance, architecture conformance, or final acceptance contract.

Scheduling And Worker Ownership

Q1

Prerequisites:

• none

Evidence anchor:

• .agents/skills/implement-spec/references/parallel-orchestration.md:Step 3
• .agents/skills/implement-spec/references/parallel-orchestration.md:Step 5

Observed constraint:

• The current scheduler launches an unblocked worker wave, then waits for the whole wave to be validated and logged before it computes the next wave.

Question: Should a dependent task start as soon as its own prerequisites pass, even while unrelated tasks from the earlier wave are still running?

Code consequence:

• The scheduler becomes event-driven and recomputes eligible work after each task result instead of advancing only at a whole-wave barrier.

Accepted answer:

• Yes. Release dependent work as soon as its own prerequisites pass. Do not wait for unrelated workers.
• The exact prerequisite release gate remains open in Q8.

Q2

Prerequisites:

• none

Evidence anchor:

• .agents/skills/implement-spec/SKILL.md:Branch and PR invariant
• .agents/skills/implement-spec/references/parallel.md:Contract

Observed constraint:

• The current Harness contract already keeps one recorded branch checked out and prevents concurrent workers from sharing write scope.

Question: Should implementers use isolated worktrees and merger agents, or write directly in the current branch under disjoint ownership?

Code consequence:

• Shared-branch execution needs exclusive active write scopes and parent integration checks, but no worktree lifecycle or merger-agent layer.

Accepted answer:

• Workers write directly in the current branch.
• Active worker write scopes remain disjoint.
• Do not introduce worker worktrees or merger agents.

Context And Assurance

Q3

Prerequisites:

• none

Evidence anchor:

• .agents/skills/create-plan/references/plan-schema.md:Task contract
• .agents/skills/implement-spec/references/parallel-worker-brief.md:Required Context

Observed constraint:

• Each task currently repeats a large set of planning, TDD, review, runtime, architecture, provider, and skill-guidance fields in the plan and worker brief.

Question: Should tasks use durable context pointers to avoid repeating information already held by the spec, plan, code, and skill sources?

Code consequence:

• Planning and worker dispatch can shrink, but the minimum inline execution kernel and pointer freshness rules must remain explicit.

Accepted answer:

• Yes. Prefer durable context pointers and reduce duplicated task metadata.
• The minimum inline execution kernel remains open in Q9.

Q4

Prerequisites:

• none

Evidence anchor:

• .agents/skills/implement-spec/references/lifecycle.md:Shared execution invariants
• .agents/skills/implement-spec/references/runtime-product-validation.md:Run an isolated scenario
• .agents/skills/implement-spec/references/ui-screenshot-evidence.md:Contract

Observed constraint:

• Harness has explicit TDD, runtime, UI, provider-readback, and acceptance evidence because automated or local code checks do not prove every product result.

Question: Should those assurance gates remain?

Code consequence:

• The hybrid scheduler must preserve applicable evidence gates while avoiding fields and work for gates that do not apply.

Accepted answer:

• Yes. Keep the applicable TDD, runtime, UI, provider-readback, and final acceptance gates.
• Apply conditional gates only when their existing risk trigger is present.

Q5

Prerequisites:

• none

Evidence anchor:

• .agents/skills/implement-spec/references/architecture-conformance.md:Cumulative conformance checkpoint

Observed constraint:

• Architecture-bearing plans require cumulative ownership, dependency, public-seam, responsibility, and migration checks before dependent architecture work advances.

Question: Should architecture conformance remain a hard execution barrier?

Code consequence:

• Dynamic task release must stop at declared architecture checkpoints until cumulative conformance passes.

Accepted answer:

• Yes. Preserve cumulative architecture checkpoints and final zero-drift closure.
• Ordinary task batches do not become architecture barriers merely because they were previously called waves.

Pull Request And Review Policy

Q6

Prerequisites:

• none

Evidence anchor:

• .agents/skills/implement-spec/SKILL.md:Branch and PR invariant
• apps/wiki/content/docs/project/grilling/stack-workflow-grill-status.md:Implementation Branching Policy

Observed constraint:

• Current policy defaults to PR creation after implementation and makes an early draft PR opt-in.

Question: Should the default move toward an eager draft PR?

Code consequence:

• The new decision will supersede the closed PR-after-implementation default while preserving accepted branch/base and stack intent.

Accepted answer:

• Yes. Move the default toward an early draft PR for visibility and durable integration state.
• The exact creation trigger remains open in Q10.

Q7

Prerequisites:

• none

Evidence anchor:

• .agents/skills/delivery-phase/phases/review.md:Prepare Review
• .agents/skills/review-phase/phases/run-review.md:Review Execution
• apps/wiki/content/docs/project/grilling/review-phase-graph-rework-grill-status.md:Review cost control

Observed constraint:

• Full delivery can perform three full review passes. Each pass prepares a frozen target, runs all mandatory lenses, persists an immutable report, routes findings, repairs, and repeats.

Question: Should normal delivery spend less time in review-phase?

Code consequence:

• The default number of full review passes and the validation required after repairs must change without losing an escalation path for risky repair work.

Accepted answer:

• Yes. Reduce automatic full-review repetition materially.
• The replacement default and escalation rule remain open in Q11.

Frontier Closure

Q8

Prerequisites:

• Q1
• Q2

Evidence anchor:

• .agents/skills/implement-spec/references/parallel-orchestration.md:Step 5
• Accepted Q8 handoff evidence, preserved in this entry.
• apps/wiki/content/docs/project/specs/cli/project-verification-capability/SPEC.md:AC-001

Observed constraint:

• A dependent needs trusted prerequisite behavior, but it does not need unrelated workers, final Verification, Code Review, or all shared bookkeeping to finish first.

Question: What exact evidence releases a dependent task, and may plan and notes bookkeeping finish after release?

Code consequence:

• implement-spec needs a task-local release state distinct from final acceptance and closeout.

Accepted answer:

• Release a dependent after the prerequisite worker completes its TDD target, relevant typecheck, and relevant lint; then the parent performs a quick task-local acceptance and Active Write Scope check.
• Do not wait for unrelated workers or review-phase.
• Verification normally blocks final acceptance, not the task transition.
• Verification joins the Task Gate only when the prerequisite task owns a complete visible journey or runtime side effect that the dependent consumes.
• implement-spec updates the Feature Map before it runs Verification for an Uncovered Behavior.
• PLAN.md and IMPLEMENTATION-NOTES.md reconciliation may finish after dependent dispatch, but must finish before an applicable Architecture Checkpoint or finalization.

Q9

Prerequisites:

• Q3
• Q4
• Q5

Evidence anchor:

• .agents/skills/create-plan/references/plan-schema.md:Task contract
• .agents/skills/implement-spec/references/parallel-worker-brief.md:Required Context

Observed constraint:

• The current task schema copies information already held by the spec, plan, code, architecture views, and skill sources.

Question: Which task fields stay inline, and what may become a Context Pointer?

Code consequence:

• create-plan and worker briefs keep a small execution kernel and progressively disclose the rest.

Accepted answer:

• Keep task identity, dependencies, owned paths, intended outcome and acceptance references, validation and required RED/GREEN commands, applicable risk gates and Architecture Checkpoint IDs, execution status, and provider identity when applicable.
• Use Context Pointers for specification detail, code symbols, architecture views, and exact skill guidance instead of copying their contents.

Q10

Prerequisites:

• Q6

Evidence anchor:

• .agents/skills/implement-spec/SKILL.md:Branch and PR invariant
• apps/wiki/content/docs/project/grilling/stack-workflow-grill-status.md:Implementation Branching Policy

Observed constraint:

• An empty draft PR adds noise, while waiting until all implementation finishes delays visibility and durable integration state.

Question: At which durable branch checkpoint should the draft PR be created?

Code consequence:

• The PR lifecycle starts after real branch state exists and before most implementation proceeds.

Accepted answer:

• After the branch and base gate passes, create the draft PR when the first meaningful commit is pushed.
• If the recorded branch already contains a meaningful pushed commit, create or reuse the draft PR immediately.
• Do not create an empty commit only to open a PR.

Q11

Prerequisites:

• Q4
• Q5
• Q7

Evidence anchor:

• .agents/skills/delivery-phase/phases/review.md:Prepare Review
• .agents/skills/review-phase/phases/run-review.md:Review Execution
• project-verification capability SPEC.md:US-007, AC-027, AC-028

Observed constraint:

• implement-spec owns implementation, task checks, Verification through verify-behavior and the Project Verifier, reruns, and final acceptance evidence.
• The subsequent delivery-phase review step owns invocation of readonly review-phase against the frozen implemented change.

Question: After implement-spec completes, how many Full Code Review Passes should the subsequent delivery-phase review step run, and what happens after review-triggered repairs?

Code consequence:

• The delivery state graph must replace its default review-repair-review repetition while preserving focused repair checks, invalidated Verification reruns, and escalation for high-risk repairs.

Accepted answer:

• implement-spec completes before the Full Code Review Pass. It does not invoke review-phase.
• The subsequent delivery-phase review step runs one Full Code Review Pass by default.
• Delivery repairs accepted findings, runs Focused Repair Validation, and returns affected Verification scenarios to implement-spec ownership when the repair invalidates their evidence.
• Do not automatically run a second Full Code Review Pass after ordinary repairs.
• Run one second Full Code Review Pass only when a repair changes architecture, security or authorization, a public contract, runtime or deployment topology, or accepted scope.
• Do not run more than two Full Code Review Passes in one delivery goal without explicit human direction.
• Canonical term: Full Code Review Pass. Avoid: full review.

Rejected Alternatives

• Worker worktrees and merger agents.
• A whole-worker-wave barrier for ordinary task release.
• Removing runtime, UI, provider, architecture, or final acceptance proof wholesale.
• Final-only review with no task-level validation.

Current Frontier

• Empty. Shared understanding confirmed on 2026-09-04.

Closure

• The user explicitly confirmed the complete shared understanding on 2026-09-04.
• Q1-Q11 are accepted.
• External PR reviewer integration remains parked outside this capability.
• The closed artifacts are ready for wiki synthesis and create-spec.

Accepted Follow-up (2026-09-05)

The follow-up challenge revisited execution topology, concurrent evidence, compact context, recovery, and review accounting. The user accepted all findings except experiments; no benchmark or experiment requirement is added here.

Q12 — Concurrent evidence inputs

Q12 qualifies and supersedes Q1's release condition where declared read, write, or shared-runtime conflicts can affect evidence.

Question:

What must the swarm planner record when Active Write Scopes are disjoint but workers may still interfere through reads or shared runtime state?

Accepted answer:

• The swarm-planner primitive of the create-plan step of delivery-phase records each task's Read Dependencies and Shared Runtime Resources alongside its Active Write Scope.
• Frontier release respects declared read/write/runtime conflicts. Unrelated disjoint work remains eligible.
• A Task Gate is valid only against stable relevant inputs; a relevant-input change invalidates affected evidence and requires the affected checks before dependent release or finalization.
• This remains a planning and evidence rule inside the native Harness execution model. It introduces no lock service, separate executor, worker worktrees, or merger agents.

Q13 — Derived context disclosure

Question:

When may a compact plan or worker brief retain derived context rather than only a pointer?

Accepted answer:

• A bounded excerpt or rationale is allowed when it avoids a predictable lookup.
• It must identify its authoritative source, retain a resolvable Context Pointer, and carry freshness information sufficient to detect staleness.
• The source remains authoritative; derived context cannot silently diverge or become a second authority body.

Q14 — Diagnosis before repair

Question:

When may recovery continue before another repair or handback?

Accepted answer:

• Authorized diagnosis may inspect or trace the failure and gather evidence that distinguishes plausible causes.
• A repair is justified only after new actionable evidence; retrying without useful evidence or remaining diagnostic options is not progress.
• Handback occurs when requirements, gates, access, or a decision is outside the accepted boundary, or useful authorized diagnosis is exhausted.

Q15 — Review attempt accounting

Question:

How should interrupted, invalidated, and after-pass review attempts be represented?

Accepted answer:

• An interrupted or incomplete Full Code Review Pass is recorded as not clean and not completed and does not consume the completed-pass allowance.
• A semantic target change during an active pass invalidates that pass and requires a fresh pass over a new frozen target.
• An accepted ordinary repair after a completed pass uses Focused Repair Validation and affected Verification reruns; it does not automatically start another Full Code Review Pass.
• The accepted two completed-pass ceiling remains; stagnant repair loops cannot silently consume retries.

Follow-Up: Review Topology Alignment (2026-09-05)

• A Full Code Review Pass uses one comprehensive primary reviewer with explicit coverage of all five mandatory axes; it does not require five separate review workers.
• autoreview is the primary reviewer and no extra advisory scan is required. One independent risk-focused challenger is mandatory for a bounded independent risk area; additional challengers may be used when larger changes require separate independent risk areas.
• Primary and challenger reviewers consume the same frozen factual packet. Challengers complete their independent checks before consuming primary conclusions.
• The parent adjudicates findings and owns the report. Per-axis gaps or incomplete challenger work are incomplete and cannot be clean.
• Detailed topology is authoritative in the Delivery Phase Flow Optimization specification.
• Existing one-pass default, focused repairs, affected Verification reruns, risk-triggered second pass, and two-pass ceiling remain unchanged. No experiment or admission-policy change is added.