Delivery Phase Flow Optimization Grill Status

Phase State

• Topic: prompt-level delivery flow optimization across routing, planning, implementation, Verification, Code Review, recovery, handoff, and closeout.
• Input: direct bounded requirements input. No Finder provider artifact is in scope.
• Scope boundary: requirements only. No skill implementation, backlog mutation, release, merge, or deployment.
• Authority shape: one umbrella specification will compose the two retained leaf specifications without flattening their decision trails.
• Working completion: 100%.
• Shared-understanding confirmation: confirmed.
• Last reviewed: 2026-09-05 (R5 Astra re-analysis).

Branch Dashboard

Technical Grounding

Accepted Round R1

• Q1: Carry one disposable current-state projection between in-task phases; cold-route when its authority or freshness fails.
• Q2: The parent alone writes shared plan and implementation-note summaries; workers return concise deltas and evidence pointers.
• Q3: The parent orchestrates delegated edits at Task Result granularity and never waits for full-wave completion.
• Q4: Reuse one frozen review input through one Full Code Review Pass while retention and routing revalidate it.
• Q5: [Superseded by R6] Run autoreview once and five distinct normative axes once and concurrently; keep integrated review experimental until parity is proven.
• Q6: Use eligibility- and native-capacity-based fan-out without a universal numeric cap.
• Q7: Require paired performance evidence and equal assurance without a fixed percentage target yet.

Accepted Round R2

• Q8: Delivery Context Packet is a compact disposable current-task projection containing pointers, not copied authority.
• Q9: Warm continuation requires matching task, goal, bounds, authority, Git target, and evidence freshness; otherwise cold-route.
• Q10: Phase Result is the compact canonical phase-exit contract.
• Q11: Task Result is the compact canonical worker-return contract.
• Q12: Dispatch newly eligible dependents immediately after their prerequisite Task Gate passes; reconcile shared summaries before checkpoints and finalization.
• Q13: Worker-worthy Tasks are cohesive implementation scopes with exclusive ownership, acceptance boundaries, and Task Gate checks. Planning folds in microtasks.
• Q14: Review Packet is the pointer-based frozen input for one Full Code Review Pass.
• Q15: Semantic-input changes restart review. Retention-only failures reuse the matching report and packet.
• Q16: Performance uses an assurance-constrained Pareto acceptance rule.
• Q17: Controlled comparison covers delivery, dependency skew, worker context, review defects, recovery, and Project Verifier paths.

Accepted Round R3

• Q18: Context Pointer contains authority kind, stable locator, optional selector, content or state identity, and consumer freshness rule.
• Q19: Phase Result outcome is exactly complete, blocked, failed, skipped, or human_steering_required.
• Q20: Workers report ready_for_gate or blocked. Only the parent records Task Gate passed, repair_required, or blocked.
• Q21: Delivery Handoff is a compact cross-task pointer record. The receiving task always cold-routes.
• Q22: Failed or repair-required work blocks only its dependent chain. Its Active Write Scope stays reserved through validated cleanup or one repair worker.
• Q23: Review Lens Result is a compact candidate envelope. The parent verifies, deduplicates, assigns stable finding IDs and final severity and route, and assembles the report.
• Q24: When capacity is constrained, prioritize assumption-invalidating work, longest dependency chain, unlock count, then plan order.
• Q25: Benchmarks use three matched pairs, extend to five only after disagreement, then return inconclusive.
• Q26: Review parity requires no missed critical or high findings and equal-or-better axis recall, severity, routing, freshness, and retention.

Accepted Round R4

• Q27: Context Pointer resolution fails closed. The parent gets one bounded refresh from the named authority; unresolved identity returns blocked.
• Q28: Only Full Delivery uses the continuing packet loop. Direct, HITL, standalone, resume, and closeout invocations emit one Phase Result and stop at their requested boundary.
• Q29: Capacity one runs sequentially through unchanged contracts. A harness without subagent capability reports blocked when implementation delegation is required; the parent does not implement.
• Q30: Roll shared contracts atomically through canonical Devpunks source, then sync the exact receipt into this single Harness pull request.
• Q31: Normalize valid legacy artifacts at read time. Do not bulk rewrite history. Preserve valid retained report identities and ordinals.
• Q32: Permit repair only with new actionable evidence. Stagnant loops, redesign, or weaker-gate requests return human_steering_required through $handback.
• Q33: Failed or inconclusive benchmarks cannot activate the optimized default without an explicit retained human exception.
• Q34: Enforce compactness structurally through required fields, pointer-only authority, forbidden copied payloads, and concise deltas. No unsupported universal token limit.

Accepted Round R5 (2026-09-05)

• Q35: Select instruction surfaces by trigger: always-loaded project facts and hard boundaries, workflow contracts required by the current action, and optional techniques only when their trigger applies. Record selected surface identities and freshness.
• Q36: Permit bounded source-attributed derived excerpts or rationale in disposable task context when they avoid a predictable lookup. Excerpts carry source identity, freshness, and an explicit non-authoritative marker; full bodies and broad payload dumps remain excluded.
• Q37: Permit bounded authorized hypothesis-discriminating diagnosis to produce new evidence before a repair. Stagnant repeated repair, scope redesign, changed requirements, missing access, human decisions, or weaker-gate requests hand back through $handback.
• Q38: Read dependencies, shared runtime resources, and evidence-stability inputs belong to the swarm-planner primitive within create-plan, the planning step of delivery-phase, alongside write scopes. No runtime lock or execution engine is introduced.
• Q39: Project Verifier composition includes falsifiable observable claims, important negative or failure checks, matching proof reuse when evidence identity and conditions permit, and targeted retirement or supersession of obsolete Feature Map knowledge by reference to the leaf authority.
• Q40: Review Lens Results use clean, findings, or incomplete; partial coverage is never clean, and an incomplete attempt may retry only through bounded useful authorized diagnosis or the existing review route. Semantic input changes during an active pass restart review; accepted repairs after a completed pass follow the existing focused-validation or risk-triggered second-pass rules. Same-snapshot complete evidence may be reused only when identity, scope, and freshness still match.
• Q41: The parent always delegates implementation edits. Read-dependency and evidence-stability detail is scoped to the swarm-planner primitive within create-plan, the planning step of delivery-phase.
• Q42: Additional brainstorm experiments comparing delegation topology, hybrid excerpts, reduced instruction surfaces, or verifier maintenance cost are declined. Existing AC044-048 and the assurance-constrained admission policy remain unchanged.

Accepted Round R6 (2026-09-05)

• Q43: Replace five separate lens executions with one comprehensive primary reviewer covering all five retained coverage obligations and one independent risk-focused challenger. autoreview fills the primary role; it is no longer an extra advisory scan.
• Q44: Prepare shared factual frozen target, rules, evidence, and relevant dependencies once, without a persuasion narrative or target rediscovery. Mechanical schema, identity, evidence-cardinality, serialization, and routing checks use existing helpers.
• Q45: The parent groups duplicates before investigation, verifies every distinct claim, preserves primary/challenger provenance, and owns stable IDs, severity, routing, and report retention. No automatic parent discovery pass.
• Q46: Challenger coverage runs in parallel when capacity allows and may split independent risk areas for larger changes without a fixed numeric cap; primary coverage must retain every obligation, including security.
• Q47: Existing incomplete-with-candidates, one-pass focused repair, and maximum-two-pass rules remain. Legacy five-lens reports normalize at read time without rewriting history.

Current Round

• Round: R6
• Current frontier: empty
• Shared-understanding confirmation: confirmed

Glossary

Canonical Terms

• Execution Frontier: Worker-worthy Tasks whose dependencies passed Task Gates and whose required Active Write Scopes are available now.
• Task Gate: 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.
• Context Pointer: Reference containing authority kind, stable locator, optional selector, content or state identity, and the freshness rule its consumer must check.
• Delivery Context Packet: Disposable current-task projection containing only identities, Context Pointers, freshness, current action, blocker, and stop condition needed to route Full Delivery.
• Phase Result: Compact phase-exit result containing one common outcome, changed authority or evidence, invalidations, next routing, blocker, stop reason, and only the next Context Pointers.
• Task Result: Compact evidence-bearing return from one scoped implementation worker for parent Task Gate evaluation.
• Worker-worthy Task: Atomic, cohesive implementation outcome with exclusive paths, an acceptance boundary, and Task Gate checks.
• Architecture Checkpoint: Declared cumulative barrier for ownership, dependency, public-seam, responsibility, and migration conformance.
• 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 application-specific executable knowledge consumed through the single verify-behavior entrypoint.
• Review Packet: Pointer-based frozen identity and authority for one Full Code Review Pass.
• Review Lens Result: Compact output from the comprehensive primary reviewer or independent challenger containing assigned coverage identity, packet identity, and clean, findings, or incomplete; incomplete coverage may retain candidates but never completes 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: 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 its 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 factual Review Packet supplies frozen authority and relevant dependencies to autoreview as the comprehensive primary reviewer and to an independent risk-focused challenger; the primary reports every one of the five retained coverage obligations, including security, 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. Affected Verification reruns only when repair invalidates its evidence.
• Delivery Handoff crosses tasks; the receiving task cold-routes and creates a new Delivery Context Packet only if Full Delivery continues.

Axioms

• Existing specifications, plans, notes, handoffs, review reports, Git state, provider readbacks, and retained evidence remain their own authorities.
• Delivery Context Packet and Review Packet are disposable projections, never durable authorities.
• The user-selected native harness executes and coordinates work.
• The parent orchestrates. Scoped workers perform every implementation edit.
• A passed Task Gate can release its dependents before unrelated workers finish and before shared-summary reconciliation finishes.
• Shared-summary reconciliation finishes before an applicable Architecture Checkpoint or finalization.
• Faster delivery cannot weaken an applicable assurance gate.
• Verification and Code Review remain separate gates with separate evidence.
• An ordinary repair does not cause another Full Code Review Pass.
• Warm and cold describe routing cost, not durable lifecycle states.

Flagged Ambiguities

• None in the accepted umbrella boundary. Further review-phase optimization brainstorming remains a candidate set outside this requirements edit.

Parked Or Rejected

• Rejected: Delivery executor, deterministic Delivery runtime, compiled delivery kernel, scheduler, watcher, outbox, lock, journal, or cache service.
• Rejected: weakening or merging TDD, architecture, runtime, UI, provider-readback, Verification, final acceptance, or Code Review authorities.
• Rejected: worker worktrees, worker branches, merger agents, or one pull request per Task.
• Parked: external GitHub or Codex pull-request reviewer integration.
• Parked initial implementation: one integrated size-adaptive semantic reviewer. Resume only after controlled seeded-defect parity and a later accepted requirement.
• Declined for this round: additional optimization experiments. Existing AC044-048 remain the sole accepted experiment and admission policy.

Final Domain-Model Consistency Pass

• No unanswered umbrella requirement remains. Review-phase efficiency ideas raised during R5 are candidates for a later review-phase grill and are outside this closure.
• Ownership is consistent: the native harness executes, the parent orchestrates and owns shared projections and gates, scoped workers own implementation edits, and review lenses return candidates.
• Authority is consistent: durable source artifacts remain authoritative; packets and results carry identities, pointers, and deltas only.
• Lifecycle is consistent: Full Delivery may continue warm within one valid task; every narrower or cross-task route respects its stop boundary and cold-routes.
• Assurance is consistent: optimization changes scheduling and context movement, not the number or meaning of gates.
• The umbrella specification must preserve the two leaf specifications as separate authorities and resolve only their cross-skill composition.
• No contradiction or unresolved synonym remains among the canonical terms, relationships, axioms, and accepted Q1-Q34 decisions.

Non-Design Validation

• git diff --check: passed after R5 persistence.
• Wiki synchronization and content checks: passed after R4 persistence.
• hi check --json: the R4 historical readback recorded an unavailable check because Commit Gate Consumer apps/api had an incomplete Quality Command Contract; current scaffold guard remains unresolved for this docs-only edit.

Next Transition

• Requirements grill closed with shared understanding confirmed.
• Invoke create-spec immediately from the retained decision record.
• Do not invoke write-backlog until the specification is pushed or explicitly retained and a stable blob URL is verified.