Goal Driven Queue

Goal-Driven Queue

This skill owns the queue lifecycle: persistent backlog, intake-time approval capture, concurrent consumption, queue-level caps, progress document, acceptance package, and the post-run human per-card verification gate. Single-run methodology lives in goal-driven-workflow (the engine); merge decisions stay human. Loading this skill MUST NOT start consumption by itself — consumption starts only on an explicit queue request or a scheduled pull. References stay thin: evolution-review (kill vocabulary, record-the-failed-recipe), learn-and-improve (carrier decision tree) and solution-review (reversibility / CBAM / WSJF vocabulary) supply vocabulary only and are deliberately not frontmatter dependencies — their absence degrades a recommendation's richness, never a gate.

The value proposition is the detach-run-accept cycle: a human drops approved goals into the backlog during spare moments, leaves, and returns later to a packaged result. Every design choice below serves that promise — nothing may stall waiting for an absent human, and nothing may proceed past what the human actually approved.

Prerequisite Skill Check

Run at startup against frontmatter dependencies: scan available skills; abort immediately with install guidance (npx skills add FuDesign2008/open-skills -g) if report-output-discipline, goal-driven-workflow, design-approval-gate, or intake-interview-discipline is missing; abort likewise for ai-proxy-discipline when any card records Stage-exit policy: ai-proxy, for jira-fix-workflow / opsx-jira-fix-workflow when any card names them as Engine, and for git-worktree-discipline when the queue's resolved concurrency is ≥ 2 (missing at concurrency 1 is not a failure); missing with no such card or concurrency is not a failure. No silent downgrade — a missing engine means queued tasks cannot execute correctly; a missing intake discipline means enqueue-time depth collapses to a shallow one-shot confirm; a missing proxy discipline means opted-in cards lose their checkpoint challenge; a missing worktree discipline means concurrent children would lose their isolation.

Queue Layout

.goal-driven/
├── queues/<queue-id>/
│   ├── config                            # concurrency / isolation / caps, settled at enqueue
│   ├── <task-card>.md
│   ├── approaches/<signature>.md        # only when a card is marked Reusable: yes
│   └── runs/<batch-id>/progress.md      # + triage record in the same directory
└── (legacy) <task-card>.md + runs/    # readable as queue-id `default`

Each conversation gets its own backlog automatically. The human never picks a queue name. Isolation is a folder under .goal-driven/queues/<queue-id>/ (minted id, not a platform session UUID).

Queue identity

Resolve the bound queue-id at every enqueue, Jira list-enqueue shortcut, and consume entry — never by asking the human to choose:

1. This conversation already bound an id → reuse it (same chat continues the same drawer).
2. Else mint q-YYYYMMDD-HHMMSS (append - plus four hex digits on collision), bind it for this conversation, and use that directory. First enqueue or 「跑队列」 mints; a mere load does not.
3. A scheduled / unattended pull with no conversation bind consumes default only (legacy root cards + .goal-driven/queues/default/ if present). It does not mint and does not drain sibling q-* drawers.

Scope: card writes, consumption, relationship pass, mid-run re-scan, progress documents, and the acceptance package stay inside this conversation's directory. Sibling queues are invisible to those operations.

Legacy: markdown cards directly under .goal-driven/ (not under queues/ or runs/) plus .goal-driven/runs/ belong to default. Interactive conversations do not auto-bind default (that would steal leftover cards). New writes always go to .goal-driven/queues/<queue-id>/.

Resume: same conversation → same bound id via chat memory and the files in that folder. A new conversation mints a fresh queue and does not pick up another conversation's leftover cards. Jira list-enqueue inherits this bind — the shells do not keep a second layout.

Task-card status vocabulary (shared with the progress document): pending → in progress → done | failed | skipped (covered) | waiting dependency | conflict pending confirmation

done means "engine completed"; acceptance is tracked separately by the card's Verification state — awaiting | verified | returned — recorded in its Acceptance Summary and the progress document's Verification column. A batch MUST NOT be presented as accepted while any executed card is awaiting, and the batch summary reports Verified: N / Awaiting: M / Returned: K.

Card format and all output templates live in reference.md.

Human-Facing HTML Views

Every human-facing queue record has a generated HTML view; the Markdown file remains the canonical record. config and approaches/*.md stay Markdown-only. The dispatcher never hand-writes human-facing HTML — the single HTML generator is this skill's adapter scripts/render-html.mjs (Markdown for records, small JSON for review/evidence via renderReviewPage / renderEvidencePage), which uses the shared core from report-output-discipline. When Node or the shared renderer is unavailable, print the .md paths instead of writing HTML by hand. Ensure the target repository ignores .goal-driven/**/*.html by appending that line (never overwriting existing rules), so derived views stay out of the change set.

Covered views render at Stage 1 approval handoff and Stage 3 package assembly, and re-render immediately before any open. verification.html is the acceptance entry page. Auto-open it at Stage 3 handback only when the first progress entry records Trigger: interactive; scheduled/unattended runs print paths. An enqueue shell does not write a view. Human-facing records and HTML chrome follow the human's conversation language; localize labels and footers via renderer lang / labels.

Layout, navigation, theme, file/URL linking, CLI flags, and designed-document parts (TOC, KPI tiles, field cards, callouts, timeline, verdict) live in reference.md § Human-Facing HTML Views — keep this section a thin pointer; do not paste that methodology here.

Path Overview

Stage 1: Enqueue & Pre-approve

This stage exists because both questions and approval are cheapest while the human is present. Load intake-interview-discipline and run its §A here (deep interview with presence tiers → approach freeze → pre-launch self-review); the card freezes exactly what will run, which way it will go, and what it may cost. That frozen text is what makes unattended launches safe later, standing in for the launch approval the engine would otherwise demand from a person who is no longer there (design-approval-gate named-escape pattern; record the intake confirmation as the 留痕, e.g. in the card's approval line plus the git commit).

Batch triage (before any interview)

Run triage once per enqueue interaction over the cards being added, before the per-card interviews — work eliminated here is never interviewed. It produces equivalence groups, root-cause clusters, and suggested kills. intake-interview-discipline's §A stays per-card; triage sits in front of it.

• Mechanically provable outcomes apply automatically: an exact problem-signature plus target-path-set match, or a verified card's (Verification: verified) report already covering the outcome. Each superseded card is archived — never deleted — inside the bound queue directory with superseded-by recorded, and the event lands in the triage record. Anything short of an exact match is not equivalence.
• Value judgments stay human: a card judged not worth doing is a suggestion, and the card keeps its current status until a human acts on it. Under declared absence or Stage-exit policy: ai-proxy, only the mechanical outcomes apply and the rest goes to the triage record for the human's return; the proxy MUST NOT confirm a value-judgment kill — on hit it tickets and parks the item.
• Cluster folding preserves every member card's goal text inside the folded card, and the members are archived rather than dropped.
• The triage record is written into the bound queue directory (a pre-run enqueue has no batch directory yet) and rides the acceptance package.

Jira list-enqueue shortcut

When invoked by jira-fix-queue or opsx-jira-fix-queue, or when the enqueue input is a list of Jira IDs/URLs with Engine already frozen to jira-fix-workflow or opsx-jira-fix-workflow, use this shortcut instead of one full deep-intake per issue:

1. Parse distinct issue IDs/URLs — one card per issue.
2. Ask one interaction-budget ticket for the whole list; write the same Stage-exit policy on every new card.
3. Skip the engine ticket — Engine is frozen by the caller; record it on each card.
4. Per card: Goal Condition = that issue's Jira link; Frozen Decisions = run the named engine as queue-child, remaining product/tech fog deferred to the child per Stage-exit policy; budget clause from the batch ticket or the conservative default in reference.md.
5. Open with a batch three-part base (issue table), then one approval event covering all new cards. Display Decisions-I-made for the batch. Approval is not run-start — stop here.
6. Do not share one branch or one OpenSpec change across the new cards.

Default enqueue

Queue-level ticket — concurrency and isolation (asked once per queue, on its first enqueue, and recorded in the queue config). Concurrency is a choice with a recommended default of 3; choosing ≥ 2 accepts worktree-mandatory isolation (one worktree per concurrent child), and declining worktrees caps the queue at concurrency 1 and keeps today's branch-or-worktree behavior. State the consequences derived by walking this project's actual configuration (per intake-interview-discipline §A) — at minimum the sibling-path breakage risk for multi-repository projects, the disk cost of one worktree per concurrent child, and the fact that acceptance will pre-run conflicts rather than hand the human N unassisted merges. Absent, unattended and scheduled runs reuse the recorded values; with nothing recorded they fall back to 1, and a concurrency above 1 is never assumed.

1. Deep intake interview — per the loaded discipline, run its §A with its presence tiers. Fixed first ticket — interaction budget (before scope tickets): one three-way choice for how the child run's stage stop-points are handled — A. full-human (child manual mode, every exit asks) / B. AI-proxy (Stage-exit policy: ai-proxy: child auto mode + proxy checkpoints per charter, ledger trail, your review at acceptance is the per-card verification document and the per-card verdict stays human-only) / C. auto (child auto mode, named escapes + self-answer) — pre-filled from the assessment recommendation only under the same all-factual high-certainty gate as the engine ticket, otherwise mandatory with no default — and state the layer split in the output: intake tickets freeze task-level WHAT; process-level forks that emerge during analysis belong to the layer this ticket assigns. Then per tier: present (default) → one question per turn until fog graduates, high-impact self-answers escalated to questions, and the intake output opens with the three-part base (restatement / key elements / open questions) so the human checks the unfolded understanding before anything is frozen — the card is the product of that display, not its replacement; declared/structural absence → once-confirm + full ledger, unchanged. Steps: (a) destination; (b) open-decision tickets, resolved one question per turn until fog graduates; (c) approach comparison — the human picks; (d) freeze into the task card (reference.md § Task Card). Explicit-skip escapes are the discipline's own (recorded assumptions). If the card's problem signature matches a reusable record whose factual entries still verify, seed the interview from it — the approach comparison starts at the recorded approach and already-resolved tickets are presented as decisions to confirm rather than questions to re-answer, with approval still a separate event; a record that fails verification is not used as a seed.
2. Shape the result into a task card (reference.md § Task Card): measurable goal condition with a mandatory budget clause, frozen-decisions block (incl. the ticket list), the Decisions-I-made-for-you section (self-answered decisions + impact tiers; displayed at approval), constraints, the human-chosen priority (vocabulary per reference.md § Task Card; default P1 when unstated), status pending, plus a coarse duration estimate (advisory; derivation in reference.md). Give the card its Certainty/Difficulty field — a band derived from four signals (reversibility, evidence, blast_radius, dependency_shape), each marked factual or preference, with the most conservative band winning on conflict (derivation rule: the change design's D1). No numeric score; factual signals are verified at the consumption-entry check like any other factual entry, and a falsified signal parks the card there. Set Waits-on when the card depends on another card's outcome (edges must stay acyclic), on Reusable: yes when the frozen approach is worth seeding a future equivalent card from, and Modules: by extracting and normalizing the card's Constraints paths/modules — the concurrent-admission criterion reads that field and never the Constraints prose, and the field is treated as factual for the consumption-entry check. When the project has an openspec/ directory and a usable openspec CLI (or equivalent), offer traceability: openspec | none as an intake decision — default off; project policy may mandate on; the user's explicit choice wins — and record it as the card's Traceability field. Record the interaction-budget ticket's choice as the card's Stage-exit policy: manual | ai-proxy | auto field (legacy Counterpart: on / counterpart values read as ai-proxy; legacy manual-pause / auto-escape read as manual / auto); proxy = ai-proxy-discipline occupies the human seat at this card's enumerated checkpoints (absent-mode intake Q&A, the batch triage / batch approval event, approval event, record-step report check, conflict re-adjudication) under its bounded charter — with one reservation: a value-judgment kill is outcome acceptance and stays human-only, so at the triage checkpoint the proxy tickets and parks it rather than confirming. Then the engine ticket: which child executor runs the card, among goal-driven-workflow | solve-workflow | opsx-solve-workflow | jira-fix-workflow | opsx-jira-fix-workflow (exact skill names, fixed at freeze as the Engine field) — goal-harness loop / stage-gated PDCA (openspec variant needs the openspec environment) / end-to-end Jira fix flow with PR-open terminal / the same with native OpenSpec sedimentation and an archive+PR-open terminal; present fit guidance and a recommended answer. The ticket carries no default unless every certainty signal is factual and verified and the derived band is high-certainty/low-cost, in which case the assessment's recommendation is pre-filled and the human or proxy confirms or overrides in the same interaction; state that a card with neither a chosen nor a defaultable engine parks at dispatch (never silently defaulted).
3. Approval event, distinct from run-start — confirm condition + budget with the human once, now as one approval event closing the interview ("once" = one approval event, not one question total); the approval MUST display the card's Decisions-I-made-for-you section. One approval event MAY cover the whole triage batch — the batch path already used by the Jira list-enqueue shortcut extends to the general enqueue path, covering that batch's merges, clusters and suggested kills together with each card's condition and budget; a suggested-kill item the human does not explicitly act on keeps its current status, and the proxy may never confirm one. With Stage-exit policy: ai-proxy and the human absent, the proxy grants the approval as bounded pre-authorization per ai-proxy-discipline (Decisions-I-made displayed to it; decision ledger-marked proxy-made). Starting a run is a separate explicit instruction — even when the two confirmations are consecutive, never bundle approve-and-run into one unreviewed step. Record approval in the card.
4. Suggest committing the card so backlog changes stay reviewable.

At the approval handoff, render the task card and triage record to HTML and show their paths; do not auto-open them.

Loading without a queue request: if this conversation already bound a queue, give a one-glance overview of that queue (pending/in-progress counts, any executed card awaiting verification with the latest verification.md path, total estimate of remaining pending work, next actionable card) and wait; if not yet bound, say this conversation has no queue until the next enqueue or 「跑队列」 (do not mint, do not list sibling queues as a picker).

Stage 2: Run the Queue

Triggered by an explicit request («跑队列» variants) or by whatever the platform scheduler pulled in. Resolve the bound queue-id first (Queue identity above) — consume only that directory. Resolve the run's concurrency from the trigger statement when it names one, otherwise from the queue config; an attended run with nothing recorded asks, an absent run falls back to 1. Resolve the three queue-level caps the same way (max-tasks / max-concurrent / wall-clock; use the default in reference.md when unstated) — these exist so the worst case is a clean early stop with work left pending, never a runaway night. Report the summed card estimates in the first progress-doc entry as reference only — under concurrency they are no longer an upper bound on wall-clock, so never present them as one. Concurrency is expressed as intent: when the platform cannot run the resolved number of children, fall back to the highest supported value and state the fallback in the progress document rather than silently pretending to be concurrent.

Mode propagation: a card's Stage-exit policy, when present, overrides trigger-word propagation (manual → child manual; proxy → child auto + proxy checkpoints; auto → child auto with named escapes); with no field, the legacy trigger rule applies — a trigger containing 「自动」/"auto" runs children in auto mode, otherwise children keep their default mode. State this explicitly per admitted child — do not rely on ambient inheritance, and treat each child's completion as final for continuity purposes (their auto-revert rules apply within their own run, not across the queue).

While a slot is free and an admissible pending card exists — the order defined by reference.md § Task Card (priority level → information leverage descending → certainty band → FIFO as the final tie-break) decides admission sequence, not how many children run — admit the next card whose Modules: set does not overlap any in-flight card and start its child run; refill at each completion boundary. An overlapping card waits as pending rather than being admitted to keep a slot busy, and when nothing is admissible the slot stays idle without error and without deadlock. The steps below run per admitted child:

1. Consumption-entry check — re-validate the card: budget clause present, constraints still hold against current repo state (target files/branches still exist, dependencies not yet merged away); an opsx-solve-workflow or opsx-jira-fix-workflow engine additionally requires the openspec environment (openspec/ + usable CLI) — a missing environment parks the card as conflict pending confirmation, never a silent engine downgrade. Decisions-I-made entries marked factual (branch baselines, dependency existence, target paths) are cheaply verified here against the current code world (symbol-exists grep / git branch --contains / merge-base topology) — a falsified entry parks the card now instead of surfacing as a mid-run clean stop. A card with no Engine field parks here as conflict pending confirmation (awaiting engine decision — one added line un-parks it; the queue never silently picks an engine). A changed world invalidates the frozen approval, so park such cards as conflict pending confirmation instead of running them (with Stage-exit policy: ai-proxy, the proxy may re-adjudicate continue/stop within the original frozen scope per ai-proxy-discipline; anything needing a scope change stays with the human).

2. Relationship pass (light, across remaining cards in the bound queue): equivalence and root-cause clustering were already settled by enqueue triage, so this pass owns dependency, overlap-conflict and derived, plus the already-covered check against verified reports. An outcome already covered by an accepted (Verification: verified) report → mark skipped (covered) pointing at the covering report; a report whose card is only done (still awaiting verification, or returned) does not cover. A card whose Waits-on target is not yet verified → hold waiting dependency and hand the target's summary/branch to the child once it is accepted (a done-but-awaiting target keeps holding), while Waits-on edges forming a cycle, or a target ending in any state other than verified (returned, skipped, archived, failed, parked), park the affected cards as conflict pending confirmation; overlap-conflict → park conflict pending confirmation; derived (fixing A reveals B as follow-on or deeper root cause) → record in progress Notes and either depend, keep serial, or park for a human split — never merge two in-progress cards onto one branch or one OpenSpec change. Re-check remaining cards after each completion since code state moved, and recompute information leverage at that same completion boundary — a recomputation that moves the queue head is logged as a reordering note. Pass the judgments into each child's card supply (opsx-jira children write them as ## Related Issues in design.md). Same-module work is amortized: the first card on a module produces an exploration record in the Approach Record shape (reference.md § Approach Record), and later cards on that module seed from it instead of re-exploring — writes to that module stay serialized because the admission criterion never admits two overlapping cards at once. A record whose factual entries fail verification is not used as a seed.

3. Isolate — put the child run on a dedicated branch, or a linked worktree, based off latest main per git-worktree-discipline. At concurrency 1 that stays branch-or-worktree exactly as before; at concurrency ≥ 2 each concurrent child SHALL get its own worktree, because a single working tree cannot serve two children on two branches. One task owns one branch; no task ever carries another's edits.

4. Delegate — dispatch by the card's Engine. With Engine: solve-workflow or Engine: opsx-solve-workflow, invoke that skill for this single task instead: the card's problem + frozen-decisions block supplies its stage 1, the card's Stage-exit policy rides along and decides its exit behavior (proxy → auto mode with proxy-occupied exits per that skill's unattended-proxy-exits section; manual → manual mode; auto → auto with named escapes); queue contracts (isolation, recording, caps) apply unchanged. An opsx-jira-fix-workflow child receives the same supply plus the openspec environment gate, with an archive + PR-open terminal: it archives its OpenSpec change (archiving is native to its model and always happens), then stops at PR open — merge + Jira writeback defer to the human. A jira-fix-workflow child is invoked with the card's Jira link as the goal, the frozen decisions as its stage 0–1 supply, an explicit queue-child context flag, and a PR-open terminal — it stops after stage 9 (PR open, record-only closeout); merge + Jira writeback ride the acceptance package as pending human follow-ups, and a 🔴 difficulty-grading termination records as a normal non-blocking failure. For Engine: goal-driven-workflow — invoke goal-driven-workflow for this single goal (auto mode if propagated). The card supplies the inputs for its requirements alignment (stage 1) and acceptance/goal-condition design (stage 2) — the frozen-decisions block answers the child's stage 1 intake, and the child MUST NOT re-pause to re-ask what the card already froze (the consumption-entry check above guards its continued validity). Sub-agent division (stage 3), launch companions, and fallback harness selection remain the engine's own calls. Mid-run decisions follow intake-interview-discipline §B: evidence falsifying the frozen approach → clean stop + ticket report, never a silent pivot; one task's stop never cancels the rest — in-flight children continue uninterrupted, and the freed slot is refilled at the next completion boundary. For unattended runs remind once per batch about the engine's unattended-companion setup (convention file, validation hooks, minimal tools). Each card supply states in one line that the engine enforces its own context budget (phase-boundary resets and ledger handoff per context-budget-discipline). Each card supply also requires: on completion, commit, push the feature branch, and open a PR/MR; record one of MR: opened <url>, MR: failed — <reason>, or MR: skipped — no reviewable diff (<status output>; <diff output>) in the completion report; merge stays human. A reviewable diff requires git status --porcelain -- . ':(exclude).goal-driven' ':(exclude).explain-clearly' to print nothing and git diff --stat "$(git merge-base origin/main HEAD)" HEAD to print at least one changed file; the report records both commands and a short output summary. A scoped status that still prints a change is committed or reported as MR: failed, never as skipped. A done card with a diff and no opened URL or failure reason is set to failed; an MR failure is a delivery failure and is set to failed; only a scope or constraint change beyond the frozen card uses conflict pending confirmation. The MR URL is recorded in the completion report, the progress document, the verification document, and the acceptance package. Merge, release, protected-branch operations, and any auto-merge remain human-only. The queue does not edit a child engine's completion-report template; the supply carries this rule.

5. Record — the dispatcher is the sole writer of the progress document and the queue-level records; a child reports back and never writes a shared queue file, and completions arriving together are recorded sequentially so no entry is lost. On each child completion update the card status + acceptance summary and the progress document immediately (per-status updates make crashes cheap to resume and the morning review honest), and record the effective concurrency achieved next to the resolved value so slots that idled on module overlap — or a platform fallback — are visible rather than silently slower. Note the child report's verification-checklist status in the acceptance summary; with Stage-exit policy: ai-proxy, the checklist goes to a fresh-context proxy per ai-proxy-discipline (tagged verdicts; failing items bounce or ticket — never a silent done), and checkpoint events from several in-flight children are adjudicated serially by the dispatcher so two adjudications never interleave; when the card carries Traceability, run openspec validate for its change at this boundary. Clean-stop tickets and ledger entries ride the child's completion report; reference its path in the card's acceptance summary. A clean stop (falsified frozen approach) parks the card as conflict pending confirmation — distinct from the pre-run consumption-entry check. One task failing or capping out MUST NOT block later tasks; the freed slot is refilled at the next completion boundary. The explanation (说明), the evidence record (证据留痕), and the acceptance verdict (验收裁决) stay separate. The explanation states the problem, the cause, and the completed fix. The evidence record shows a screenshot when a check opened a screen, and the command with a short output summary when it did not. The acceptance verdict is the person's decision that a finished card is accepted or returned. The evidence record does not carry that decision. When the card's status becomes done, under Stage-exit policy manual, auto, or ai-proxy, the dispatcher writes one review JSON (problem, cause, fix from the child report) and one evidence JSON, then generates both HTML pages with renderReviewPage / renderEvidencePage — never hand-written HTML. The review page path is .goal-driven/queues/<queue-id>/runs/<batch-id>/review/<card>.html. The evidence page path is .goal-driven/queues/<queue-id>/runs/<batch-id>/evidence/<card>.html. The <card> segment is the card slug and contains no path separator. Pass the same shared navigation block into both pages (via navHtml from renderNav, or --nav), with relative items that at least cross-link review ↔ evidence and reach the acceptance entry page; mark a missing target unavailable. The evidence page title and kicker follow the human's conversation language. The dispatcher reads the evidence list on the child completion report. Copy each regular file from that list that exists, is non-empty, and is a png, jpg, jpeg, or webp into evidence/<card>/, and reference the copy by a relative path. If two copies would share a basename, prefix the later file with its 1-based list index. A check that did not open a UI shows the command and the output summary and has no image. A missing or empty image is pending and states the capture still required. Do not invent an image. Before an opened-UI image supports the check, inspect it per completion-evidence-discipline. Put each item's pending status and inspection note on the evidence JSON so the evidence page shows the copied image and that inspection. An empty evidence list still gets the page, and the page states that no checks were recorded and contains no image. A card that is not done does not get the review HTML page. A card that is not done does not get an evidence page. An enqueue shell does not write the evidence page. The review page does not add a standalone evidence link; the acceptance entry page and the shared navigation reach the evidence page. Record the child's MR state and URL in the card acceptance summary and the progress document; a done card with a diff and no MR state is failed.

6. Re-assess the queue budget spent so far before admitting the next card into a freed slot.

7. Re-scan for mid-run additions — re-scan .goal-driven/queues/<queue-id>/ (plus legacy root cards when the bound id is default) for newly added pending cards: admit a well-formed card carrying a budget clause and an approval record into the admission sequence for the remainder of the run — subject to the resolved concurrency and the same non-overlap criterion as any other card, never preempting the in-flight children — and count it against the remaining task cap; a malformed card or one without approval stays pending with a progress note (awaiting approval (added mid-run)). Sibling queues are not admitted. Log each discovery in the progress notes.

When caps hit or the queue empties: stop cleanly — stopping mid-backlog is a feature, leftover cards simply stay pending.

Stage 3: Acceptance Package & Human Verification

Assemble into .goal-driven/queues/<queue-id>/runs/<batch-id>/: the progress document, the triage record (referenced by path from the queue directory: merges, clusters, suggested kills and parked items with their basis, including every proxy-made decision), each executed task's engine completion report (copied into runs/<batch-id>/reports/<card-slug>.md and rendered to reports/<card-slug>.html), for each done card its review HTML at review/<card-slug>.html and its evidence HTML at evidence/<card-slug>.html (plus copied images under evidence/<card-slug>/), the dedicated verification document verification.md (reference.md § Verification Document), and the branch/MR list awaiting review, with each card's MR URL or recorded no-diff/failure reason — each waiting branch rebased inside a temporary scratch worktree for conflict prediction only, so the human reviews real conflicts instead of performing N unassisted merges. The prediction MUST NOT push, force-push, or rewrite a branch that already carries an open PR/MR; the actual rebase and merge stay human. Before handing back, run the queue-level verification checklist — (1) caps accounting: tasks dispatched vs the resolved caps, which cap stopped the run; (2) progress-document completeness: every status change has an entry, discovery notes present for mid-run additions; (3) per-task report-checklist status: each executed task's engine report carries its numbered verification checklist, overall status recorded in the card's acceptance summary; (4) leftover pending inventory: what remains, at which priorities, for the next run; (5) archive status per task when Traceability is set; (6) verification coverage: every executed card appears in verification.md with its verdict state and its section populated from the engine report, awaiting count reported. Surface failing items, never drop them.

Human per-card verification gate. Engine completion stays done; acceptance is separate. At assembly the dispatcher marks every executed card Verification: awaiting (card Acceptance Summary + progress-document Verification column) and writes verification.md — one section per executed card consolidating goal condition, engine/result/branch/report, layered acceptance, the engine report's numbered checklist, side effects, ledger items and conflict pre-run, plus a verdict line. The batch MUST NOT be presented as accepted until every executed card carries a human verdict verified / returned. The per-card verdict is human-only — with Stage-exit policy: ai-proxy the proxy MAY still run the record-step report-checklist check (thin pointer to ai-proxy-discipline), but MUST NOT fill, infer, or pre-fill a card's verdict; an absent verdict stays awaiting. Non-executed outcomes (failed / skipped (covered) / waiting dependency / conflict pending confirmation / parked / leftover pending) go to the document's "items needing your decision" section, not a verdict slot. Batches and cards predating this state behave exactly as before. The card's verification.md section records the review HTML path and the evidence page path. Then hand back:

• Present the summary: per-task result, each done card's review HTML path and evidence page path, evidence location, branch tip, the verification-document path with each card's verdict state, and the outcome-type items only a human can judge (the engine separates those; never self-certify them).
• At an interactive handback (Trigger: interactive), open verification.html in the system default browser; an explicit view request opens the requested page; a scheduled or unattended run prints the paths only.
• Roll up each task's decision/assumption ledger (intake-interview-discipline §C) and the triage record: "Needs your judgment" aggregates outcome-type items plus unresolved tickets, low-confidence assumptions, high-impact-if-wrong entries, and every triage decision awaiting a human — un-acted suggested kills, parked clusters, dependency stalls, and proxy-made triage decisions; clean-stop tickets each carry their options for a one-glance decision.
• Stop at the conflict picture and the per-card verification. Merge authority is exclusively human — surface only genuine conflicts plus the suggested merge order, and do not merge, push to protected branches, or close anything irreversible.
• Route acceptance findings (including returned verdicts) back into new or revised cards so the next run starts better informed.
• When the human returns and supplies verdicts, record each verdict on the card's Acceptance Summary, the progress-document Verification column, the batch counts, and verification.md — the dispatcher is the sole writer of these durable records. verified closes that card's acceptance; returned routes back per the bullet above.

Red Flags

• Starting consumption just because the skill was loaded, or letting a child launch re-pause for approval the card already froze (silently re-approving changed conditions is worse than pausing)
• Shallow one-question intake ("confirm once" read as "ask once") that defers direction ambiguity into the unattended run; a child silently re-deciding or re-asking what the card froze
• Interviewing from the pointer line alone — intake-interview-discipline never loaded, so depth collapses to its five-word summary
• Reading the queue into memory once and never noticing mid-run that code state shifted under the remaining cards
• Exceeding the resolved concurrency, letting two children share one worktree, or letting one failed card cancel the rest
• Treating "budget exhausted" as task success — the report must say which acceptance tiers actually passed
• Running a mid-run discovered card that lacks an approval record, or letting a malformed half-written card stall the loop
• Consuming or re-scanning a sibling queue, asking the human to pick among queues, or writing a project-level current-queue pointer another conversation could overwrite
• Starting consumption from a Jira list-enqueue (or from jira-fix-queue / opsx-jira-fix-queue) without a separate run instruction
• Sharing one OpenSpec change or one branch across two in-progress Jira cards "because they share a root cause"
• Auto-applying a value-judgment kill, or letting a batch approval swallow a suggested kill the human never acted on — mechanical equivalence may be applied automatically, a judgment about worth may not
• Unlocking an engine or stage-exit-policy default from a band whose derivation rested on any preference signal
• Presenting a batch as accepted while any executed card is still Verification: awaiting; filling, inferring, or pre-filling a per-card verdict on the human's behalf (an AI proxy included)
• Assembling the acceptance package without the dedicated verification.md, or leaving an executed card without its consolidated section
• Auto-opening a browser on a scheduled/unattended run, or presenting the package without its HTML views and MR URLs