@1aboveio/skills 1.0.19 → 1.0.21

package/skills/engineering/better-review/references/result.md

@@ -64,6 +64,12 @@ P2 lacks its follow-up URL when the caller asked for follow-ups.
       "file": "src/billing/refund.ts", "line": 42,
       "trigger": "refund 100 USD at rate 0.9 returns 111.11 EUR, expected 90.00",
       "rule": "every currency conversion multiplies by the source-to-target rate",
+      "reproducer": {
+        "command": "pnpm test -- src/billing/refund.test.ts",
+        "cwd": ".",
+        "expected": "refund 100 USD at rate 0.9 returns 90.00 EUR",
+        "evidence": "<run>/reviews/1201/refund-probe.log"
+      },
       "paths": [
         { "path": "src/billing/refund.ts:42", "status": "open", "evidence": "divides by rate" },
         { "path": "src/billing/charge.ts:31", "status": "closed", "evidence": "convert() at :31" }
@@ -104,6 +110,14 @@ P2 lacks its follow-up URL when the caller asked for follow-ups.
 - `trigger` is required on P0/P1: the concrete input, state, or sequence that breaks it; for
   an explicitly unmet requirement or missing required proof, identify the requirement and the
   evidence of what is missing.
+- `reproducer` is optional on P0/P1. When an executable case established the finding,
+  attach its actual `command`, workspace-relative `cwd` (`.` for the root), and `expected`
+  observable result from the existing contract. An optional `evidence` names its retained
+  probe/log. Keep the probe available through the fix loop. The command must exercise the
+  reported trigger; establish its defining state in the case so a different fixture cannot
+  silently bypass the failure. An unmet written requirement need not have an executable case.
+  The caller carries these references, including distinct earlier witnesses of a still-open
+  finding, into the fix brief. Their old results are baseline evidence, never candidate passes.
 - `rule` and `paths` are required on P0/P1, with at least one row `open`: the rule as one
   sentence, and one row per path the diff adds, changes, or relies on (a writer, caller, sweep
   place, or async cell), each `open` or `closed`, a closed row citing its guard's `file:line`.

package/skills/engineering/e2e-test/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test
 description: "Playwright end-to-end guidance for affected browser journeys, render health and presentation checks, with route manifests and sweeps for broader audits. Use when browser routes or user flows ship or change, or a Playwright test flakes. NOT for non-browser tests, defining what to test (ensure-coverage), the curated ALIVE/DEAD golden-path gate (golden-path), or CI workflow YAML (github-actions)."
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # E2E Testing Standard
@@ -77,6 +77,13 @@ Whether you added tests, wrote notes, or reviewed a PR, the first line answers "
 
 ## CI
 
+For issue Acceptance Criteria that need browser proof, map the criteria to real
+assertions and keep the affected specs runnable through maintained local and CI
+commands. Use isolated fixtures and retain failure traces. Workers run focused
+development checks; CI executes qualifying acceptance against the candidate. Report
+CI pending until its applicable cases pass; a spec file or unrelated green job is
+not acceptance.
+
 Run the repo's existing required checks; routine feature work does not create or change a golden-path gate. When explicitly tasked with CI wiring, see [ci-integration.md](references/ci-integration.md) and [ci-playwright-container.md](references/ci-playwright-container.md).
 
 ## Reviewing

package/skills/engineering/engineering/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: engineering
 description: "Engineering conventions: feature-delivery priorities, focused verification and review, operational boundaries, and tracker routing. Standalone /engineering offers Global, Project, or Session setup and targeted resets for configured scopes; /engineering init keeps explicit project setup. Use when setting up AGENTS.md or CONTRIBUTING.md, saving or resetting engineering defaults, or before creating an engineering issue, spec, epic, ticket, or sub-issue on GitHub or Linear. Reads existing policy without writing during ordinary work. NOT the issue-to-PR workflow (resolve-issues), release execution (resolve-release), Git delivery (github-flow), or CI setup (github-actions)."
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Engineering

package/skills/engineering/engineering-runtime/SKILL.md

@@ -3,7 +3,7 @@ name: engineering-runtime
 description: Internal support package for shared Engineering Workflow executable behavior. Never select or invoke this package as a user capability.
 disable-model-invocation: true
 user-invocable: false
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Engineering Runtime

package/skills/engineering/engineering-runtime/coherence/workflow.json

@@ -369,7 +369,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "93ac20a3d5d41b233b13e521ba1b65d0a3e339958422a56ffad00a844656a23f",
+      "contentDigest": "528de8e948bcd1cfdbe92bcb4c14129cbb78d5d9037d8d378d5ac540017cd248",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "915715a605bf78f6f69cb8c95f7227548a6d71a6ef0ce502b5b5c5a357676d19",
+      "contentDigest": "1b1074c002a7d3ca2dfebe625b65128aee10a662f7f9d4060a018fbaecf3225f",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "1ef2fd2ad328c373c7c6fe42007908766860cd8051e1807739797303aaadeae4",
+      "contentDigest": "61d744eeddd5b3a5d2fa7a94ea01ec3a570c72a7c19ad526761f21aac993abff",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "3c9509027191a2b2612f3905defb5ed9c47580709ba77b46c0e8433d354c4d33",
+      "contentDigest": "3140da610485146538ee76048446ea7bac8927890a1469eb8108e63e4056d655",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5e419edc77397a9021a24fc9da83d07c83aa786853dcb24916d8fb2655f81ea9",
+      "contentDigest": "12f5230e47afdeab750cb6b1454b3172edb29b922155b2994e96a93f386b6dbd",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "ecee12f24d18d49ec1be030e3f831c3d07a66f37b0b16aa5efef365ca381e558",
+      "contentDigest": "b8d908580483f3954545e392c11d439ed100688eadc3b41ce508569f6dddc3bc",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "2fbd1a9e15087045fa80b47d9b6db8695009c900c2e4aeeab71207875b071c74",
+      "contentDigest": "256eac4a31f95d536ef487359df4c84fe7e85436c3b7550f6200f1b15cca4d0b",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "8c33282acdf9a7b3ba3adf46065249126efdd8669487ad7def1b4302155db3dd",
+      "contentDigest": "25ad674c96748cb5313d13c80dd1ac4be5bdb287e75e7f978d8e5b97f5892833",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "e612b320be1b3aee539a26494e2048e0bbdc1947166fa4cffbdfe8085a64b50a",
+      "contentDigest": "1d10c734eaef6bb20bf99bf9fa6dcfde6460ea2eecb84c33d7c0474e470684a9",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "53732d354995ca40c0325b2f860a4facf2e79b9d6d373fbc76a5ce5b3a1f1e29",
+      "contentDigest": "229a6d752c9b17c298172a022c36f8e28e409d665df4ed89f1655c17f37db3f3",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "61f8b7f04887b86338984f03527fdaf66ec90df7ff89c19ee9dca6f362fe212a",
+      "contentDigest": "c44aa11db1f62995c8b77929143892e421d7068193c959930c8af4fbe8a2d7f5",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "ad9bdbfbaeb4c575f8fad5b53367403096594aafce8e686926ddb734c185155a",
+      "contentDigest": "14439c4b1390b3dde50dcf8d56ff5c578bbbe08b17627f7bd504db099ba5e92a",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "2ed547516d442d0bfad21952001956420f71a972849049507530f80ad16eda83",
+  "releaseIdentity": "d7ab71565826655a05f576e53932870e4d0176329a1b4110a460457e5cb2d0b8",
   "lifecycleAuthority": "native-skills-cli",
   "repairRecipe": {
     "id": "engineering-workflow-dependency-first",

package/skills/engineering/ensure-coverage/SKILL.md

@@ -2,7 +2,7 @@
 name: ensure-coverage
 description: "Define or audit behavior-first test criteria — ACs, required test levels, mock/integration/E2E policy — across three axes: breadth (Coverage Ledger), depth (over-mocking), presentation (perceivability of browser surfaces). NOT judging whether a single test is any good (test-quality), authoring browser tests (e2e-test), reviewing a PR (better-review), or delivering issues (resolve-issues)."
 disable-model-invocation: true
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Ensure Coverage
@@ -16,6 +16,13 @@ Read the relevant source and governing project guidance. When product behavior o
 
 ## Scope and proof
 
+- Start from the issue's Acceptance Criteria, requirements elsewhere in the issue,
+  and later human corrections. Map each criterion to sufficient existing tests or
+  missing automation, its qualifying CI lane, and any human or physical-device
+  remainder. One test may prove several criteria; choose the lowest sufficient level.
+  Record this in the existing issue or findings without requiring a new ledger.
+  Workers deliver the tests; CI executes automated acceptance. Grade a criterion
+  satisfied only when the relevant assertions and candidate's results support it.
 - Choose the smallest sufficient proof for the outcome and material risks; reuse existing tests and required CI results when they prove the behavior. Do not automatically require multiple test layers, a ledger, a criteria document, a presentation campaign, or reconciliation of every ADR.
 - Existing required repository checks and adopted coverage floors remain binding unless an approved change alters them. Authentication, money, tenancy, and data-integrity protections remain binding. Read applicable ADRs and project policy for the touched work, not every ADR in the repository.
 - Consider breadth, depth, and presentation where relevant: what behavior is in scope, whether evidence actually exercises it, and whether a user can perceive and use a changed interface. Do not turn every axis or hypothetical state into a separate blocking obligation.

package/skills/engineering/golden-path/SKILL.md

@@ -3,7 +3,7 @@ name: golden-path
 description: "Golden-path E2E: the short list of user journeys whose failure blocks a release, kept in a repo as one contract (golden-paths.json) with a generated GOLDEN_PATHS.md and a generated GitHub Actions workflow, and run against a local build or a deployed URL for an ALIVE/DEAD verdict. Use to set golden paths up in a repo ('init golden paths', 'add golden-path CI'), to migrate an older smoke.manifest.json or a hand-built smoke setup ('audit', 'migrate smoke'), to add, change, or remove a golden path, to ask 'is the build alive?' or run them before a PR or release, or when a change touches a flow listed in GOLDEN_PATHS.md. NOT for writing the Playwright specs themselves (e2e-test), deciding what a change must prove (ensure-coverage), or general workflow YAML (github-actions)."
 dependencies:
   - e2e-test
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path
@@ -42,6 +42,10 @@ repo has a copy.
 
 ## Rules
 
+Golden paths are the curated release-critical subset, not the full set of issue
+Acceptance Criteria. Keep other automated acceptance tests in their appropriate CI
+suites; an ALIVE verdict proves only the selected paths and their assertions.
+
 1. **A person decides which flows are golden.** Draft candidates; never promote one
    on your own judgment. A flow the user names in the request is confirmed, and so
    are paths carried over from an older smoke manifest (ask about trimming them).

package/skills/engineering/harness-runtime/SKILL.md

@@ -3,7 +3,7 @@ name: harness-runtime
 description: Internal import-only library shared by first-party engineering packages. Not a workflow skill; never select or invoke it as a user capability.
 disable-model-invocation: true
 user-invocable: false
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Harness Runtime

package/skills/engineering/resolve-issues/SKILL.md

@@ -8,7 +8,7 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.49.1
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues
@@ -63,8 +63,8 @@ preflight: ready label -> model fills -> plan draft
   -> when a unit's code is done, for that unit:
        rebase on its parent (stack, chain) or the target (wait)
        -> independent review, while CI runs -> review-verdict.mjs decides:
-          `pass`: review passes (P2 goes to the dropbox, never fixed
-          here; P3 is skipped); `fix`: only its fixBrief (P0/P1),
+          `pass`: review passes (route P2 by its contribution to delivery;
+          P3 is skipped); `fix`: its fixBrief (P0/P1) plus explicitly selected supporting P2,
           push, re-review; `review-again`: review again
        -> CI red: fix, push; after a passing review, carry it (no reviewer)
        -> review passed and CI green on one HEAD: mark ready
@@ -116,16 +116,34 @@ Read each procedure right before its stage; never substitute your own.
 - **The human.** Ask once, at the approval. Record every decision, correction, and scope change in
   `decisions` at once, and each standing instruction in `standingOrders`; re-read the standing orders on
   resume and before any push, enqueue, data write, or deletion. Default merge mode is `autonomous`.
-- **Proof.** Treat producer reports as claims until the reviewer or CI checks them. A check that exits 0 needs no
-  further evidence. A unit owes coding acceptance only: its criteria at its `proof.level` plus the required CI
-  on its final HEAD. Integrated release acceptance (a device or system campaign the spec or repository assigns
-  to a release or campaign gate) runs at that gate, never per unit; the handback links its owning issue. Produce
-  no evidence documents; the plan, findings, and reviews are the only records.
+- **Proof.** Treat producer reports as claims until the reviewer or CI checks them. Tests and diagnostic probes
+  encode failure in their exit status under [Proof](references/implementation.md#proof); printing an exception
+  and returning 0 is not a passing check. Coordination CLIs keep their documented structured-verdict contracts.
+  Apply the [Acceptance criteria](#acceptance-criteria) contract below. Use the plan,
+  findings, reviews and CI artifacts as the records; produce an additional checklist or
+  evidence document only when the issue or repository requires it, deriving results from actual runs.
 - **Delivery.** A dependent starts on its parent's finished code. Stack its PR on the parent's (a GitHub-native
   stack) under a live Mergify queue; chain it when the merge keeps commits; else open it once the parent merges. Live
   steps are only the read-only warehouse canary (never blocks) and the isolated, run-owned resources
   [preflight.md](references/preflight.md#never-block-on-the-human) allows.
 
+## Acceptance criteria
+
+Treat Acceptance Criteria, other issue requirements and later corrections as the contract.
+Reuse or implement automated tests at the lowest sufficient level. Workers deliver behavior
+and tests, run focused local checks, and return with CI pending. CI qualifies the candidate;
+the coordinator verifies results. Human or hardware criteria stay pending until their step passes.
+
+At preflight, record coverage, missing automation, the CI lane and manual remainder in
+findings. Reuse sufficient tests; one may cover several criteria. Acceptance-focused issues
+are supported: automate criteria, fix in-scope defects and qualify results in CI.
+Tests added or code merged alone do not satisfy acceptance.
+
+Defer acceptance only when the issue or agreed policy assigns it to a later gate; link
+its owner. An issue requesting the campaign remains incomplete until its criteria pass.
+Preserve required checks and merge rules. Surface missing execution or enforcement;
+change neither branch protection nor acceptance scope without authorization.
+
 ## Delivery progress
 
 Before briefing or continuing a unit, read [delivery-progress.md](references/delivery-progress.md).
@@ -169,7 +187,8 @@ efforts are run metadata, never a question.
 ### 2. Implement and open the PR
 
 Give each unit a branch, its prepared workspace, and an implementer with its findings entry
-and parents' contracts; state outcome and validation, not method. Refill
+and parents' contracts; retain its [implementation owner](references/implementation.md#implementation-owner)
+through review/CI fixes, separately from its active worker slot. State outcome and validation, not method. Refill
 slots at once. At a unit's first coherent commit its PR opens as a draft, so CI
 starts and the work is safe; later work goes to the same PR (in a Mergify stack
 repository, amend the one commit); review starts when its code is done
@@ -178,13 +197,13 @@ the unit's own PR branch need no approval.
 
 ### 3. Review
 
-Spawn one `better-review` reviewer once the unit's code is done, unless a
+Spawn one fresh `better-review` reviewer once the unit's code is done, unless a
 trusted complete result for that HEAD is posted on the PR; it runs alongside
 CI. From round 2, carry a HEAD that follows a pass, else pick the tier: a
 carry or skip writes its record and spawns no reviewer ([review.md](references/review.md#tier-then-verdict)).
 Merge [GitHub reviews](references/review.md#github-reviews) into its result,
 run `review-verdict.mjs`, and follow the `verdict` it prints (exit 0; 2 only if it could not run): `pass`; `fix`, give the
-`fixBrief` (P0/P1 only) to a fix worker as its `action` says, then review
+`fixBrief` (P0/P1), its retained reproducers and any selected supporting P2 under [dropbox routing](references/dropbox.md#supporting-p2-work) to the implementation owner as its `action` says, then review
 again; `review-again`; `handback`, defer the PR with its open findings; `wait`,
 request the awaited re-review; `decide`, answer the `decide` file
 ([expire.md](references/expire.md#decide-before-you-defer)) and rerun with `--decision`.
@@ -216,6 +235,9 @@ that same `planRevision`.
 
 ## Done
 
+Check each issue's [acceptance contract](#acceptance-criteria) against qualifying results;
+record later-gate obligations. A merged PR does not close pending acceptance.
+
 First [clean every delivered unit's environment](references/done.md#clean-before-handoff), then
 [settle blocked units](references/done.md#settle-blocked-units). Every PR is reviewed, green on its exact HEAD, and merged (`autonomous`) or
 handed back merge-ready (`supervised`). For a blocked unit, hand back it, its

package/skills/engineering/resolve-issues/references/ci.md

@@ -7,6 +7,18 @@ the queue owner's watcher where applicable. Workers may make short status reads
 fetch failed logs for diagnosis, but must not run `gh run watch`,
 `gh pr checks --watch`, a delivery watcher, or create background monitoring.
 
+Qualify the issue's Acceptance Criteria as well as required repository checks.
+Verify that the mapped tests actually ran in the assigned lane against the intended
+candidate and their assertions cover the claimed behavior. A skipped case, missing
+acceptance job, or green unrelated check is not acceptance. Use CI results and artifacts
+for any required checklist; retain manual or explicitly later-gate obligations with
+their owner. Worker completion with CI pending is not issue acceptance. Queue checks
+qualify the combined candidate; post-deploy checks qualify the deployed revision.
+Require each result at its assigned stage: PR admission checks before enqueue,
+queue acceptance before merge, and deployed acceptance after deployment or before
+promotion as specified. Queue-only acceptance is pending at admission, not missing
+PR CI; it cannot be required to pass before the queue candidate exists.
+
 1. Watch the required checks for every pushed HEAD. Pushes to the unit's own
    PR branch need no approval. Green means every required check ran and passed
    on that HEAD: a check that never reported is missing, not passed. Example: a
@@ -105,7 +117,9 @@ provider shows that PR merged.
 
 Clean that unit's workspace and resources, then finish it, in every scheduler
 mode: `next-actions.mjs` prints `cleanup-workspace` until its cleanup settles.
-First record the intent through the [checkpoint mechanism](task-plan.md#checkpoints) (`lifecycle.cleanup`
+First [release any session retention still held](implementation.md#settle-session-retention)
+for it, even while other units remain active; a conversation launched without protection has
+nothing to release. Then record the intent through the [checkpoint mechanism](task-plan.md#checkpoints) (`lifecycle.cleanup`
 `{state: applying, headSha: <the unit's headSha>}`), then run:
 
 ```bash

package/skills/engineering/resolve-issues/references/delivery-progress.md

@@ -13,6 +13,12 @@ units keep their own checkpoints and continue in parallel within actual resource
   observation that would distinguish the remaining causes. Run the relevant host,
   integration or device check before another broad acceptance cycle. After a correction,
   run affected checks and the required delivery checks, not extra assurance work.
+- **Keep the repair's contract intact.** Reproduce the reported input/state and check
+  the observable result the existing criteria require. Reuse sufficient checks; an added
+  regression establishes the condition that reaches the failure. If that operation exposes
+  another failure of the same contract, continue the repair while preserving earlier
+  assertions. Return when affected criteria and required local checks pass, or an existing
+  stop/handback condition applies. This adds no fixed journey or test layer.
 - **Justify infrastructure before adding it.** State which existing criterion requires
   it, why the current path cannot provide that proof, and the smallest alternative.
   Record the choice in the existing decision/note, within current authorization. Routine
@@ -39,6 +45,13 @@ issue or automatic scheduler gate. They do not waive required validation.
 
 ## Every brief contains
 
+Use the full checklist for a fresh or replacement worker. For a retained conversation,
+send the new feedback, current checkpoint, latest failure/fix brief and local evidence,
+current standing orders and changed decisions, affected skill/proof pointers, and new
+result path. Re-read the saved source/criteria after context loss; do not resend the original
+role or whole assignment already in that session. This shorter continuation keeps the same
+acceptance bar, launch-authority rules and history; it is not a new setup or proof campaign.
+
 - the source and criteria, as a file already in the run directory
 - the plan's `standingOrders`, verbatim, and the decisions that answer this unit's questions
 - absolute run, workspace, and findings paths; for implementers, the unit's
@@ -46,11 +59,16 @@ issue or automatic scheduler gate. They do not waive required validation.
 - model id, effort, and a required read-back
 - an absolute skill path when the stage invokes a leaf skill; for validating, the unit's `proof.suite` `skill` (read it first) and `local`, when set
 - the outcome and validation, with no prescribed method or evidence format
+- the Acceptance Criteria mapping: existing or missing tests, qualifying CI lane,
+  and manual or explicitly later-gate obligations; include any issue-required checklist
 - the [immediate acceptance checkpoint](#delivery-progress), existing baseline (or none),
   and, for a continuation, the last result, remaining uncertainty and next distinguishing
   test; retain the same checkpoint/history when changing workers
 - for a fix after a failed check or case, the last `failure` block (case, step, error,
   evidence path) verbatim, so the worker starts from the cause
+- for review fixes, the generated brief's `reproducers` with their original triggers,
+  source rounds/HEADs, command, workspace-relative cwd, expected result and retained evidence;
+  run them against the candidate, rather than replaying in the reviewer's old checkout
 - a concise worker-specific contract: business outcome and context, full acceptance,
   security and quality requirements, and principles relevant to the assigned work; a
   reviewer gets review.md's two rules instead. Do not forward coordinator scheduling

package/skills/engineering/resolve-issues/references/done.md

@@ -15,6 +15,13 @@ nothing is left to settle.
 
 ## Clean before handoff
 
+[Release any session retention still held](implementation.md#settle-session-retention) for each
+unit before normal workspace cleanup; this also applies at each merge while other units
+continue. A launch that asked for none has nothing to release, and an acknowledgement is
+recorded only where protection was actually held. Record any
+resource intentionally kept under the existing lifecycle; never claim it was cleaned
+because its worker exited.
+
 Clean every delivered unit's workspace and resources before the report, in every
 scheduler mode ([workspaces.md](workspaces.md#cleanup-after-delivery-before-finish)).
 Its `lifecycle.cleanup` is `complete`, or `retained` with the current `headSha`
@@ -24,6 +31,11 @@ cancelled, pending, or merge-ready handed-back unit that keeps its environment.
 
 ## Close the run
 
+Before closing, distinguish run completion from issue acceptance. Verify the issue's
+Acceptance Criteria against qualifying CI results and required manual results. Keep
+an issue open when its own acceptance remains pending, even if its automation PR
+merged or its human-only remainder was excluded. Link that obligation in the report.
+
 After the report ([SKILL.md](../SKILL.md#done)):
 
 The run is done when nothing it can do is left: every unit landed,

package/skills/engineering/resolve-issues/references/dropbox.md

@@ -8,8 +8,9 @@ Workers report problems; you route them.
 
 ## Route every problem
 
-Ask these in order; the first yes decides. Never route by the stated P-number:
-labels miss in both directions.
+Skip P3: no repair, dropbox entry or follow-up issue. For the remaining problems,
+ask these in order; the first yes decides. A P2 label alone does not decide whether
+work supports this delivery.
 
 1. **Could it hurt someone now?** Security, auth, tenancy, money, data loss,
    a failure users see, a flake that knocks other PRs out of the queue, or a
@@ -19,15 +20,17 @@ labels miss in both directions.
    Example: a reviewer notes, as P2, that a provider webhook amount is parsed
    without a check, "unreachable today". The input is external: file it now.
 2. **Does it stop this unit from being finished or proven?** Small and in the
-   unit's files: fix it in the unit. A question: take its automatic answer
+   unit's files: fix it in the unit; for P2, first record the explicit selection
+   under [Supporting P2 work](#supporting-p2-work). A question: take its automatic answer
    ([preflight.md](preflight.md#never-block-on-the-human)); defer it only when it is human-only. Anything else outside the unit's files, code or
    environment: an [infrastructure failure](expire.md#infrastructure-failures).
    Example: the shared test helper the unit's tests need is broken on the
    target: an infrastructure failure.
 3. **Did this unit cause it?** Fix it in the unit, however small; it costs
    less now than as an issue. `dropbox.mjs check` decides (`inDiff` true inside the
-   unit's diff), and `add` refuses an implementer entry there. A reviewer's
-   P2 never starts a fix round: it stays in the dropbox marked `inDiff`.
+   unit's diff), and `add` refuses an implementer entry there. For a reviewer's P2,
+   `inDiff` records location, not repair authorization: apply the supporting-work
+   test below; otherwise keep it in the dropbox.
 4. **Would fixing it change nothing** for behavior or for a reader? A style
    nit, a smell no documented rule names, hardening the
    code shows cannot trigger (internal input only, and this unit adds no new
@@ -44,6 +47,28 @@ labels miss in both directions.
 Record a blocking relation with `--blocks <#n | owner/name#n | issue URL>`:
 the posted issue says `Blocks #n` so a later run takes it first.
 
+## Supporting P2 work
+
+Select a P2 for the current unit only when it directly enables an existing
+authorized outcome, agreed verification or delivery. For example, include the
+unit's new regression module in its existing CI test list. Nearby cleanup,
+optional hardening and unrelated performance work stay deferred, even inside the diff.
+
+Record the finding/dropbox id, existing criterion and concrete reason in the plan's
+`decisions`, and include that selection in the implementer or fix brief. Keep P2
+nonblocking: its severity alone changes no verdict, fix counter or acceptance bar.
+Use the existing implementation or fix work when available. When review already
+passed, return the unit to implementation for the selected repair while retaining
+its passed review. After the repair push, use the existing post-pass carry and final
+CI rules; it does not reopen the blocking review loop.
+
+After the selected work is verified, record its SHA and check result in the unit's
+existing result/note and mark the dropbox entry with `--drop "fixed on <sha>; <check
+and result>"` so it is not filed as unfinished work. Leave the original review
+unchanged. If the work is not completed, retain its pending entry and report it
+truthfully. Shared-environment changes and changes to required checks keep their
+existing authorization boundaries.
+
 ## Commands
 
 ```bash
@@ -56,7 +81,7 @@ node $D add --dropbox <run>/dropbox.json --unit <id> --source implementer \
   --summary "<one line: what is wrong>" [--pr <url>] [--blocks <issue>] \
   --git <workspace> --base <review base>
 # coordinator, after every review round, before the verdict: adds every P2 (P3 is skipped),
-# then route each new entry; questions 1, 4, 5 change it:
+# then route each new entry, including any explicitly selected supporting work:
 node $D from-review --dropbox <run>/dropbox.json --review <run>/reviews/<unit>-r<N>.json \
   --pr <url> --git <unit review clone> --base <review base>
 node $D post --dropbox <run>/dropbox.json --repo <owner/name> --ids D3   # 1: file now

package/skills/engineering/resolve-issues/references/expire.md

@@ -235,15 +235,18 @@ missing, or names a step without a reason.
 | Review: `review-verdict.mjs` verdict `fix` | Follow its `action` ([review.md](review.md#fix-loop)). |
 | Review: `review-verdict.mjs` verdict `handback` (`not-converging`) | Stop fixing; mark the unit `blocked` (`blockedReason: review-handback`) and defer the PR with its open findings on its issue. |
 | Review: `review-verdict.mjs` verdict `decide`, or a worker's `decisionNeeded` | [Decide before you defer](#decide-before-you-defer). |
-| CI: a fix cycle without progress | Treat the failing check as the failing test: the next fix worker runs on the escalation model with that check as its only target. 2 cycles in a row without progress: `blocked` (`blockedReason: retry-ci`), deferred on its issue. |
+| CI: a fix cycle without progress | Treat the failing check as the failing test: continue the implementation owner with the required escalation fill and that check as its only target, using the [continuation/replacement selection](task-plan.md#worker-selection-on-resume) rather than fabricating a pin. 2 cycles in a row without progress: `blocked` (`blockedReason: retry-ci`), deferred on its issue. |
 | Too big for one attempt | Resume in the kept workspace while each resume makes [progress](#retry-by-failure-mode); after 2 in a row without verified checkpoint/failure-count progress, draft a split in `<run>/splits/`, file it into the spec's tree, and run the slices the sync adds ([preflight.md](preflight.md#put-every-filed-issue-in-the-tree)). |
 | A required proof the unit has no environment for yet | The unit builds it; see [Proof stays with its unit](#proof-stays-with-its-unit). |
 | Dependency | Fix the edge; resume when runnable. |
 | A capability the unit needs is missing and no unit builds it (a shared driver, fixture, or hook) | Build it inside the first unit that needs it; units that need it later get `dependsOn` on that unit. Only when that puts the unit past the size check's line limit, file it as its own issue beside them, with `blocked_by` on the units that use it, never on their parent issue. Example: three proof units each need a device-state reader: the first builds it, the other two depend on the first. |
 | [Human-only](#human-only) blocker | Take its automatic answer ([preflight.md](preflight.md#never-block-on-the-human)); when that defers it, mark `blocked` (`blockedReason: human-decision`, its `humanItem` and `humanNeed`), keep the work, and record what is needed on its owning issue; never ship part of the unit. |
 
-Continue in the kept workspace with the findings entry, never the old
-transcript. Record a queue stall with the
+Continue the retained owner in the kept workspace with the current checkpoint, findings
+and failure evidence. If its process state or required selection prevents continuation,
+use an explicit replacement under the [owner contract](implementation.md#implementation-owner),
+keeping its old session reference for settlement; replacement briefs use those local facts
+rather than an old transcript. Keep the response limits and history above. Record a queue stall with the
 provider pending as a wait and watch again. End the run only when
 `next-actions.mjs`, invoked with [live capacity](implementation.md#live-capacity), prints `finish`, and never claim the spec complete.
 

package/skills/engineering/resolve-issues/references/exploration.md

@@ -125,6 +125,12 @@ The coordinator and any delegated explorer use these rules:
 5. **`layers`:** the parts changed (`backend`, `web`, `android`, `shared`,
    `migration`).
 6. **`proof`:**
+   Map the issue's Acceptance Criteria and other binding requirements to existing
+   tests, missing automation, the qualifying CI lane, and any manual remainder in
+   the existing notes/proof fields. Preserve criterion identifiers when supplied;
+   no new ledger or schema is required. For acceptance-focused issues, include
+   implementing the cases and connecting their execution to CI in the unit's scope.
+
    - `level`: the weakest the run can reach that shows the behaviors work:
      `unit`, `database`, `browser`, or `emulator`.
    - `suite` (`browser`/`emulator` only): the repository's end-to-end suite
@@ -157,9 +163,10 @@ The coordinator and any delegated explorer use these rules:
      Example: a campaign's 25 scenario groups each cover one feature issue; 20
      share "owned emulator, database, and fixture pool" (900 lines).
 
-   `level` is coding acceptance. Integrated acceptance the spec or repository
-   assigns to a later gate (a release device campaign, all-ABI or signed
-   builds, a cross-feature journey) goes in `handback`, naming its gate.
+   `level` selects the test depth for automated acceptance. Put integrated acceptance
+   in `handback`, naming its gate and owner, only when the issue or agreed repository
+   policy assigns it to a later gate. A cross-feature or device journey is not deferred
+   merely because it is expensive; an issue requesting that acceptance still owes it.
 7. **`estimatedLines`: your honest estimate of changed source and test
    lines,** excluding generated files and docs, including every missing
    prerequisite. Do not pad it: the size check scales it by 1.3.