@abelxiaoxing/cadence 1.3.0 → 1.4.1

package/prompts/abel-design.md

@@ -6,13 +6,21 @@ tags: [abel, design, openspec, PBT, evidence]
 argument-hint: "<requirement> | --change <change_name>"
 ---
 
-Load the bundled `abel-workflow` Skill and read the complete value inside `<abel-request>` without tokenizing it a second time.
+This procedure applies only when the user explicitly invokes `/abel-design`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
+Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
 </abel-request>
 
 <!-- ABEL:PROMPT:abel-design -->
+
+This stage is scoped to the invoked task.
+Direct answers and same-task continuations stay in this stage.
+If the user ends the workflow or requests an unrelated task, first send `{"action":"finish"}` to `abel_dispatch`, then handle the new task normally with the restored tools.
+Exit preserves resumable work and never means completion or discard.
+Never start another stage automatically.
 <!-- ABEL:START -->
 
 # Design outcome
@@ -20,9 +28,37 @@ $ARGUMENTS
 Design resolves product and technical decisions, collects cited evidence, and compiles one trusted delivery.
 It never launches an implementation Worker, creates a product-code candidate, applies a product diff, runs Red/Green/Refactor, or mutates the main workspace.
 
-If the requirement/change is missing, absent, ambiguous, or not unique, stop before exploration and ask one focused question.
+If no requirement can be identified or several changes cannot be distinguished, ask one focused question about the target.
+Otherwise make Design `start` the first control call, before repository discovery.
+It creates only private resumable identity and does not approve scope.
+Then resolve discoverable unknowns from repository evidence and choose reversible defaults within existing authority; only unresolved substantive choices require a user decision.
 An explicit `--change <name>` resumes only that existing change; never reinterpret a misspelling as a new requirement.
 
+## Durable Design identity
+
+Use the same `action: "design"` envelope from the first call through finalization.
+Call `start` once with either the complete new requirement or an explicit existing change name, then use the returned `runId` for every later Design operation.
+For a new requirement, the control plane normalizes and hashes the transient text itself; the raw requirement is not written to the durable journal.
+After Gate A fixes its name, bind that same provisional run with `bind-change` rather than starting a second run.
+Use `status` by `runId` to recover local lifecycle and Design facts without a model or endpoint request.
+A completed Design run is immutable; an explicit later `--change <change>` starts the next durable Design revision for that change while preserving prior approval facts for receipt verification.
+
+```json
+{"action":"design","request":{"operation":"start","requirement":"<complete-requirement>","operationId":"<unique-operation>"}}
+{"action":"design","request":{"operation":"start","change":"<existing-change>","operationId":"<unique-operation>"}}
+{"action":"design","request":{"operation":"status","runId":"<run-id>"}}
+{"action":"design","request":{"operation":"bind-change","runId":"<run-id>","operationId":"<unique-operation>","change":"<gate-a-approved-change>"}}
+```
+
+## Focused evidence collection
+
+For a local change with known paths, read applicable repository instructions, the package manifest, the affected implementation and existing tests in the same assistant turn when independent.
+Expand to callers, fixtures or architecture only for a concrete unresolved impact or verification question.
+Once observable behavior, authorized scope, existing-test impact and an executable verification command are established, proceed to the accepted contract and draft.
+Do not continue broad directory traversal or read Cadence implementation sources to reconstruct its protocol; use the current tool schema, its installed example paths and returned field diagnostics.
+The `start` / `status` response includes a current-step hint; it is guidance, not new approval authority.
+Evidence packets are optional: use them only for independent evidence gaps that justify another model call.
+
 ## Write boundary
 
 - During verified Design, the parent tool set is mechanically limited to the previously active `read`, `grep`, `find`, and `ls` tools plus `abel_dispatch`.
@@ -47,22 +83,6 @@ Identical replay is idempotent and conflicting reuse of an operation id fails cl
 {"action":"design","request":{"operation":"delete-artifact","runId":"<run-id>","operationId":"<unique-operation>","path":"specs/<capability>/spec.md"}}
 ```
 
-## Durable Design identity
-
-Use the same `action: "design"` envelope from the first call through finalization.
-Call `start` once with either the complete new requirement or an explicit existing change name, then use the returned `runId` for every later Design operation.
-For a new requirement, the control plane normalizes and hashes the transient text itself; the raw requirement is not written to the durable journal.
-After Gate A fixes its name, bind that same provisional run with `bind-change` rather than starting a second run.
-Use `status` by `runId` to recover local lifecycle and Design facts without a model or endpoint request.
-A completed Design run is immutable; an explicit later `--change <change>` starts the next durable Design revision for that change while preserving prior approval facts for receipt verification.
-
-```json
-{"action":"design","request":{"operation":"start","requirement":"<complete-requirement>","operationId":"<unique-operation>"}}
-{"action":"design","request":{"operation":"start","change":"<existing-change>","operationId":"<unique-operation>"}}
-{"action":"design","request":{"operation":"status","runId":"<run-id>"}}
-{"action":"design","request":{"operation":"bind-change","runId":"<run-id>","operationId":"<unique-operation>","change":"<gate-a-approved-change>"}}
-```
-
 ## Read-only evidence packets
 
 Use `abel_dispatch` with `action: "run"` only for bounded Design evidence.
@@ -112,6 +132,31 @@ Do not put prompts, transcripts, hidden reasoning, credentials, environment valu
 Ask the user only for substantive choices: observable behavior, scope/non-goals, data/security/privacy/compatibility/migration policy, new dependencies, architecture/policy, irreversible changes, and technical choices with real trade-offs.
 Resolve reversible details mechanically from one established repository convention and do not ask them repeatedly.
 
+Aim for one consolidated user decision round for a clear requirement.
+Investigate repository evidence before asking about implementation details.
+Present the observable contract, any substantive technical trade-offs, and your recommended defaults together; include authorization to mechanically compile and seal the plan within those choices.
+An explicit acceptance of that complete proposal covers both its behavior and the presented technical choices.
+Do not ask a second time merely because the compiler has now produced the exact task DAG or receipt.
+Ask a further focused question only when new evidence changes a substantive choice that was not covered by the accepted proposal.
+Explain that difference, retain all other decisions, and group related unresolved choices into the same question.
+Existing instructions and accepted same-task decisions are authorization evidence; do not require the user to restate them.
+Design settles the goal, main decisions, explicit constraints, and non-goals.
+Make the implementation delegation clear in the accepted proposal: the parent will choose its recommended solution for later implementation choices within those constraints, record material decisions, and continue to verified results without another selection or confirmation round.
+Do not ask the user to approve this delegation separately or attempt to enumerate every future implementation detail.
+
+## Structured authority for new work
+
+Use a structured `ChangeContract` as the Gate A `contract` for new designs: `goal`, `acceptance` (stable `id`, accepted `statement`, complete structured `verification`), `constraints` (stable `id` and `statement`), and `policy` (`writeRoots`, allowed dependency names in `dependencies`, and `verificationModes`).
+Use `behavior` by default; explicitly permit `mechanical` or `refactor` only for suitable work.
+Present the accepted goal, constraints and scope together with the recommended choices.
+Do not include secrets or raw conversation in the contract.
+
+Code normalizes and hashes the object.
+The journal retains the normalized authority and injects it into compiled plans; callers do not compute hashes.
+Keep acceptance IDs and statements stable when reshaping a plan.
+Compilation rejects missing acceptance verification, outside-policy writes/dependencies, or substituted authority.
+Historical prose approvals remain readable; their existence does not authorize new scope.
+
 Gate A approves the complete WHAT: goal, observable scenarios, failures, scope/non-goals, compatibility/migration/security policy, and success criteria.
 Before approval, present the unresolved behavior decisions together.
 After explicit approval:
@@ -122,19 +167,61 @@ After explicit approval:
 4. materialize schema-ready behavior artifacts one at a time.
 
 ```json
-{"action":"design","request":{"operation":"approve-gate","runId":"<run-id>","operationId":"<unique-operation>","gate":"gate-a","contract":"<complete-approved-what-contract>"}}
+{"action":"design","request":{"operation":"approve-gate","runId":"<run-id>","operationId":"<unique-operation>","gate":"gate-a","contract":{"goal":"<accepted goal>","acceptance":[{"id":"<acceptance-id>","statement":"<accepted behavior>","verification":{"kind":"static-check","id":"<acceptance-verifier-id>","runner":{"kind":"node","script":"<observed-test-path>"},"args":[],"classification":"expected-green"}}],"constraints":[],"policy":{"writeRoots":["<approved-source-path>","<approved-test-path>"],"dependencies":[],"verificationModes":["behavior"]}}}}
 ```
 
 The control plane generates the canonical behavior-contract hash; the returned proof contains its approval revision, contract hash, and owner-private record hash.
 `gate-a.yaml` is installed later by code-owned finalization, not hand-authored here.
 
 Gate A is not tool permission and carries no session/model/timestamp identity.
+A later behavior decision invalidates both Gates; a later technical decision or changed plan compilation invalidates Gate B only.
+Compiling identical canonical bytes after unchanged decisions preserves the existing plan revision and both Gates, even with a new operation id.
 
 ## Technical contract and ImplementPlan
 
 Derive HOW from Gate A plus repository evidence.
 Ask only unresolved substantive technical decisions, then build a complete task DAG with stable Requirement → Scenario → Verification → Task references.
 
+Start from the package's [single-task PlanDraft example](../config/plan-draft.example.json), resolved relative to this prompt's installed path.
+It describes a small Node consumer with `package.json`, `src/add.mjs` exporting `add`, and one existing `test/add.test.mjs` that uses Node assertions and currently covers `add(0, 0) === 0`.
+The Red phase preserves that assertion and adds `add(2, 3) === 5` with the failure marker `[ADD:positive-integers]`; Green repairs the function.
+The example's nested `changeContract` also shows the structured Gate A shape.
+Replace its goal, acceptance, paths, context, impact evidence, and verification commands with observed repository facts before approval; its sample evidence is not evidence about the current project.
+Use the project's actual full suite when adapting this single-test example.
+The control plane inherits the approved `changeContract`, so the draft may omit that duplicate object.
+Keep author input separate from the complete sealed execution plan; execution never reads author shorthand.
+Reuse an atomic command through `verificationDefinitions` and `{ "use": "name" }`; place `expectedFailure` on its Red use.
+Definitions contain an existing atomic verifier's command fields, without identity, classification, bindings, nested references, or arbitrary use-site overrides.
+Inline atomic contracts may also omit `id` and `classification`; the compiler derives stable purpose identities and phase classifications.
+In PlanDraft, omit a package-script `command` (including in a named definition or package-script runner) to bind the literal package.json script value before identity generation.
+An explicit `command` must be that exact manifest value, never a launcher such as `npm run test`.
+Gate A acceptance verifiers remain complete explicit contracts; use the observed literal script value there.
+Explicit task `read` supplies common reads to its phases, unioned with any phase-local `read`; writes, deletes, roots, dependencies, and output producers remain explicit.
+The compiler also supplies fixed baseline/repair boundary fields and `agents.managedOnly`; retain recovery attempt limits and observed AGENTS impact.
+It supplies an empty AGENTS checkpoint only when every explicitly declared impact is `none`.
+The [dependent-task example](../config/plan-draft.multiple-tasks.example.json) shows a Red-produced test consumed by another task's ordered verification, with an explicit dependency and producer.
+Ordered `steps` remain complete inline contracts; reuse means separate verification executions, never reuse of a prior successful report.
+Omit `tracking` to generate parent-owned `tasks.md` metadata from the task ids; an explicitly supplied block must match those ids and the fixed tracking policy.
+In the author portion of `tasks.md`, write one checkbox with each backticked task ID, its objective and its owned backticked `specs/<capability>/spec.md#Requirement title/Scenario title` references.
+Every Scenario must have exactly one reference.
+Do not copy generated phase verifier IDs into this text.
+Compilation installs their code-owned `ABEL:VERIFICATION-BINDINGS` region while preserving the author text.
+Editing tasks afterward requires recompilation before finalization.
+Omit phase `verificationInputs`: the compiler derives the exact paths from each verification contract and binds them to a unique declared output or an existing workspace file.
+Keep supporting sources and fixtures in `read`; input derivation never adds read/write paths, outputs, or dependencies.
+Omit each `relatedTests` entry's `disposition` and `regressionTaskId` to derive ownership from task writes; retain its observed `path` and `evidence`.
+An ambiguous producer or test owner requires an explicit correction; explicitly supplied fields are checked, never silently replaced.
+Scope, verification choices, recovery limits, and necessary AGENTS operations remain explicit.
+
+Mechanical tasks may write document/data/config files (`.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.toml`, `.lock`).
+Refactor tasks preserve accepted verifier inputs.
+Both must declare no public behavior change and require an explicitly allowed mode in Gate A. Specify task `verificationMode` and Green (plus optional Refactor); omit Red in the draft.
+The compiler handles its internal compatibility representation.
+Runtime captures baseline and executes Green with affected, cumulative and post-apply verification, without generating a Red candidate.
+Behavior tasks continue to require Red/Green.
+
+An AGENTS checkpoint additionally requires its exact target path in `policy.writeRoots`; a broad source root does not grant AGENTS authority.
+
 Each task must seal:
 
 - stable id, objective, exact dependencies and edge reasons;
@@ -145,21 +232,31 @@ Each task must seal:
 - AGENTS impact/target and managed-only ownership;
 - precise context sufficient for a fresh Worker without a conversation transcript.
 
+Seal the supporting repository files needed by the whole task, including callers, types, fixtures, and conventions; Workers may read the union of that task's approved phase paths.
+Writes and deletes remain phase-local.
+This task-wide read authority is part of the proposal, not an ad hoc escalation during Implement.
+Keep tasks small enough for one complete patch using compact exact replacements, and separate independent outputs during planning.
+
 Impact closure must name affected existing tests and fixtures; a suite made only from newly added tests is insufficient.
+In `impactClosure.relatedTests`, `current-task` means this task edits that test: its path must appear in a phase's `write` set.
+Use `regression-task` with `regressionTaskId` when another planned task owns the edit; use `unaffected` with evidence when an existing test is preserved without edits, even if it remains in `affectedSuite`.
+Do not expand write sets merely to satisfy a disposition label.
 For public UI or API work, seal the relevant route authorization, page state, API response and contract, public HTML/template/theme behavior, and an approved browser E2E check when those surfaces are affected.
 
 The plan admits only shell-free `vitest`, `package-script`, `static-check`, or ordered `steps` contracts.
-Pin local runners, package scripts, arguments, `minTests`, classifications, and `noInstall` behavior.
+`dev-browser` is required only by an approved browser E2E contract; its absence does not block unrelated tasks or stages.
+Pin local runners, package scripts, arguments, `minTests`, and `noInstall` behavior; sealed classifications are derived from phase/purpose when omitted.
 Reject shell operators, implicit downloads, absolute/escaping paths, missing local capability, and unsupported verification shapes during Design readiness.
 
-After current Gate A approval, send the complete draft through `write-artifact` only to the relative path `plan-draft.json`.
+After current Gate A approval, send the author draft through `write-artifact` only to the relative path `plan-draft.json`.
 Before mutation-owning compilation, use the read-only typed preflight; it validates the same fixed draft and returns task/output counts plus hashes without installing canonical files or journaling a plan revision:
 
 ```json
 {"action":"design","request":{"operation":"validate-plan-draft","runId":"<run-id>"}}
 ```
 
-If preflight fails, use its safe structured diagnostics (`code`, and when applicable `taskId`, `phase`, `field`, `category`, `owner`, `verificationId`, or `outputId`) to repair the exact boundary.
+If preflight fails, correct the returned diagnostic batch using `field`, `path`, `expectedPaths`, `actualPaths`, and code-owned `hint` where available.
+Path lists marked `pathsTruncated` are partial; inspect only the identified boundary when more detail is needed.
 Do not bisect the draft blindly or repeat an unchanged validation/finalization request.
 After preflight succeeds, invoke code-owned compilation:
 
@@ -167,35 +264,33 @@ After preflight succeeds, invoke code-owned compilation:
 {"action":"design","request":{"operation":"compile-plan","runId":"<run-id>","operationId":"<unique-operation>"}}
 ```
 
-The compiler reads only that fixed safe path, validates capability and graph closure again, atomically installs canonical `implement-plan.json`, and returns its raw and canonical hashes.
+The compiler reads only that fixed safe path, validates capability and graph closure again, installs the generated verification bindings into the existing `tasks.md` and canonical `implement-plan.json` under the same compilation lease, and records the plan only after both writes succeed.
+It returns the plan’s raw and canonical hashes.
 Do not hand-assemble canonical plan bytes, hashes, generated task Markdown, or receipts.
 The canonical `ImplementPlan` contains:
 
 - tasks and regular-file outputs;
 - target/affected/full-suite baselines and normalized failure identity policy;
 - change-level affected, full-suite, and post-apply verification;
-- an explicit `artifactCorrection.maxAttempts` of 2-3 total candidate launches per task phase and operation, including the initial launch;
+- an explicit `artifactCorrection.maxAttempts` of 2-3 attempts for a verification obligation and phase, including the initial attempt; operation ids, rollback lineage, route changes, task renaming, and rewording do not replenish it;
 - bounded in-boundary repair policy and attribution classes `pre-existing | introduced | unresolved | environment`;
 - parent-owned `tasks.md` tracking;
 - when required, one sealed managed-block AGENTS operation per approved target, including impact, owning task ids, complete marker-bounded content, and verification.
 
-Use the shared readiness proof to require an executable static closure with no diagnostics.
+Use the code-owned readiness proof to require an executable static closure with no diagnostics.
 A write set grants authority but never proves that an output exists.
 Every absent future input must be a unique declared output from a transitive dependency.
 
 ## Gate B and trusted delivery
 
-Gate B approves the complete HOW: substantive technical choices, task DAG, exact boundaries, verification/repair contracts, output postconditions, dependency changes, scheduling declarations, tracking, and AGENTS operations.
-Do not request approval while any capability, closure, traceability, or blocking decision is unresolved.
+Gate B is a code-owned plan certificate, not a second user decision round.
+The accepted proposal covers behavior, substantive technical choices, and authority to compile their realization.
+Ask about any newly discovered substantive choice before recording that changed decision; preserve all existing decisions by id instead of restating their contract text.
+`compile-plan` atomically records the validated plan and its Gate B proof after the current Gate A and substantive decisions.
+Do not request a separate Gate B confirmation or an extra approve-gate call after successful compilation.
+Finalization still validates strict OpenSpec artifacts, traceability, graph closure, and the current private proofs.
 
-After explicit approval, materialize any remaining schema artifacts through `write-artifact` one at a time and complete the code-owned sequence below.
-First approve Gate B; the control plane accepts only a plan compiled after the current Gate A approval and latest substantive decisions, then binds that stored canonical hash so the caller never copies or recomputes it:
-
-```json
-{"action":"design","request":{"operation":"approve-gate","runId":"<run-id>","operationId":"<unique-operation>","gate":"gate-b"}}
-```
-
-Then request finalization:
+Request finalization:
 
 ```json
 {"action":"design","request":{"operation":"finalize-delivery","runId":"<run-id>","operationId":"<unique-operation>"}}
@@ -205,6 +300,8 @@ Finalization revalidates both current private Gate proofs, the stored plan, stri
 It atomically installs canonical `gate-a.yaml`, writes `ready.yaml` last, rereads the installed delivery, removes `plan-draft.json`, marks the Design run completed, and returns `deliveryRevision` plus `receiptHash`.
 Any failure leaves Design nonterminal and installs no new `ready.yaml`.
 
+Finalization serializes artifact mutation through an expiring ownership lease; never bypass a lease conflict or manually repair code-owned receipt bytes.
+
 The canonical receipts bind the Gate A and Gate B approval revisions, canonical contract hashes, and owner-private record hashes.
 `ready.yaml` references the plan path, raw-byte hash, canonical plan hash, executable verification closure, Gate A hash, artifact hashes, and traceability hash.
 It does not embed caller-owned runtime task state, completed/blocked arrays, snapshots, launch identities, or retry budgets.
@@ -216,15 +313,21 @@ Every other byte remains bound.
 
 On resume, validate current artifacts and receipts first.
 Use Design `status` to recover bounded accepted-evidence identities/hashes, latest decision revisions, Gate currentness, and compiled-plan identity without relying on a prior child session.
+A new revision of a completed change inherits decisions, Gate authority, and the canonical plan from the latest completed owner-private finalization for that same root and change.
+Evidence packets are not inherited as current observations: recheck affected repository facts.
+Technical-only changes keep Gate A; changed behavior invalidates both Gates.
 Preserve decisions whose bound content did not change.
-A mechanical hash, formatting, checkbox, stale path, or traceability repair regenerates only invalidated artifacts and does not reopen a Gate.
-Reopen Gate A only for changed behavior authority; reopen Gate B only for changed technical authority.
+A mechanical hash, formatting, checkbox, stale path, or traceability repair regenerates only invalidated artifacts and does not reopen a user decision.
+Reopen Gate A only for changed behavior authority; ask about changed substantive technical authority only when it is not already accepted.
+The compiler regenerates Gate B as needed without a separate confirmation.
 Report the exact invalidated decision/artifact instead of restarting the whole Design process.
 
 Endpoint/transport failure in an evidence packet pauses that packet and retains other evidence.
 Missing package scripts/runners or a non-executable verification contract must be corrected before Gate B; they must not be deferred as an Implement surprise.
 
-Report `READY_TO_IMPLEMENT` only when strict validation passes, both Gates have zero unresolved decisions, all artifacts/hashes/traceability resolve, and the canonical plan is executable.
+Report `READY_TO_IMPLEMENT` only when strict validation passes, user decisions are resolved and both private proofs are current, all artifacts/hashes/traceability resolve, and the canonical plan is executable.
+After successful code-owned finalization, return one brief readiness response with the change and delivery revision.
+Do not reread receipts, survey directories or restate the full decision history after that success; finalization has already reread and validated the delivery.
 Successful finalization deactivates private dispatch before an unrelated later request.
 Gate waits remain active for direct follow-up; if the user explicitly ends an unfinished Design interaction, send `{"action":"finish"}`.
 Otherwise report the current Design state, retained evidence, and the one unresolved decision or artifact that prevents readiness.

package/prompts/abel-diagnose.md

@@ -3,7 +3,9 @@ description: Diagnose and minimally repair one or more existing bugs
 argument-hint: "<problem-description>"
 ---
 
-Load the bundled `abel-workflow` Skill before work and read the complete value inside `<abel-request>` without tokenizing it a second time.
+This procedure applies only when the user explicitly invokes `/abel-diagnose`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
+Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
@@ -11,6 +13,12 @@ $ARGUMENTS
 
 <!-- ABEL:PROMPT:abel-diagnose -->
 
+This stage is scoped to the invoked task.
+Direct answers and same-task continuations stay in this stage.
+If the user ends the workflow or requests an unrelated task, first send `{"action":"finish"}` to `abel_dispatch`, then handle the new task normally with the restored tools.
+Exit preserves resumable work and never means completion or discard.
+Never start another stage automatically.
+
 The request must uniquely identify one or more existing defects.
 If required input is missing or ambiguous, stop before work and ask one focused question.
 
@@ -41,6 +49,7 @@ For each defect, keep this order:
    Run the regression after every edit and the affected suite after refactoring.
 6. Compare the full suite with baseline and require no introduced failure.
    Classify any AGENTS impact and apply only a verified managed-region update at a stable parent checkpoint.
+   Preserve every byte outside `<!-- ABEL:AGENTS-INDEX:START -->` and `<!-- ABEL:AGENTS-INDEX:END -->`; never give a Worker an AGENTS write path or put runtime/session ids, credentials, or approval state in the index.
 
 If reproduction is unavailable, root-cause evidence is insufficient, the regression cannot witness the defect, or an external capability is unavailable, return `paused` with the exact safe evidence and a concrete resume condition.
 Do not invent a repair.

package/prompts/abel-implement.md

@@ -6,13 +6,21 @@ tags: [abel, implement, openspec, TDD, recovery]
 argument-hint: "<change_name>"
 ---
 
-Load the bundled `abel-workflow` Skill and read the complete value inside `<abel-request>` without tokenizing it a second time.
+This procedure applies only when the user explicitly invokes `/abel-implement`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
+Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
 </abel-request>
 
 <!-- ABEL:PROMPT:abel-implement -->
+
+This stage is scoped to the invoked task.
+Direct answers and same-task continuations stay in this stage.
+If the user ends the workflow or requests an unrelated task, first send `{"action":"finish"}` to `abel_dispatch`, then handle the new task normally with the restored tools.
+Exit preserves resumable work and never means completion or discard.
+Never start another stage automatically.
 <!-- ABEL:START -->
 
 # Implement outcome
@@ -22,14 +30,22 @@ If it is missing, absent, or ambiguous, stop before execution and ask for the un
 
 Implement is a durable, resumable execution stage.
 The private control plane owns task scheduling, Red-Green-Refactor progression, candidate application, verification attribution, repair, task checkbox updates, AGENTS checkpoints, and the final transaction.
-The parent interprets state and makes product decisions; it must not reproduce those mechanics manually.
+The parent interprets state, owns implementation decisions, and follows automatic continuations; it must not reproduce those mechanics manually.
+Design has already established the goal, main choices, and explicit constraints.
+Invoking Implement delegates remaining implementation choices to the parent model's recommended solution.
+Choose the best supported option, record the concise decision and rationale in the same change, and continue without asking the user to select an option or confirm it again.
+Respect explicit Design constraints and non-goals; when a proposed option conflicts, choose a compliant alternative.
+A Worker request is evidence for the parent, not permission for the Worker to widen its own authority.
+Do not end the turn merely because a control call returns a nonterminal state.
+Follow its parent-owned continuation until verified completion or a concrete blocker that cannot be resolved within available capabilities and budgets.
+Keep routine decisions and repairs internal; give brief progress updates during sustained work and include material implementation choices in the final result.
 
 ## Trusted admission
 
-Before the first Worker launch, load the current `ready.yaml` and referenced canonical `implement-plan.json`; verify the Gate A binding, raw and canonical hashes, OpenSpec strict/planning status, Requirement → Scenario → Verification → Task traceability, capability closure, exact path/output contracts, repair policy, tracking contract, and sealed AGENTS operations.
+Before the first Worker launch, load the current `ready.yaml` and referenced canonical `implement-plan.json`; verify both current owner-private Gate proofs and the finalization fact binding the exact delivery revision, receipt hash, and canonical plan hash, plus the Gate A binding, raw and canonical hashes, OpenSpec strict/planning status, Requirement → Scenario → Verification → Task traceability, capability closure, exact path/output contracts, repair policy, tracking contract, and sealed AGENTS operations.
 
 An invalid or incomplete delivery is one aggregated `delivery-invalid` admission result.
-Report every safe diagnostic together.
+Inspect every safe diagnostic together and use the returned parent-owned amendment continuation to repair an executable delivery before resuming.
 Do not launch a Worker, consume a retry, mutate the main workspace, or infer a missing contract.
 
 Gate approval is not tool permission.
@@ -37,7 +53,7 @@ A fresh context validates existing approval facts and does not ask the user to a
 
 ## Closed control surface
 
-Use `abel_dispatch` only with the change commands below; never send `version`; never send `action: "run"`; and never send `admit-graph`, `task-attempt`, caller-owned snapshots, completed/blocked arrays, or apply identities.
+For durable run operations, use `abel_dispatch` only with the change commands below; never send `version`; never send `action: "run"`; and never send `admit-graph`, `task-attempt`, caller-owned snapshots, completed/blocked arrays, or apply identities.
 
 ```json
 {"command":"start","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
@@ -48,16 +64,17 @@ Use `abel_dispatch` only with the change commands below; never send `version`; n
 {"command":"discard","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
 ```
 
-When the user approves a revised delivery boundary, resume the same run with both `deliveryRevision` and `receiptHash`.
+When a revised delivery is ready, resume the same run; the engine discovers and validates its `deliveryRevision` and `receiptHash` locally.
 The engine revalidates retained phase/repair facts, invalidates only incompatible tasks, rebuilds tracking, and preserves compatible work.
 
 `status` is local and must remain useful when every Worker endpoint is unavailable.
+`discard` is an explicit destructive request; leaving the workflow uses `{"action":"finish"}` and preserves the run instead.
 Repeating the same operation id returns its committed outcome.
 Use a new operation id for a new attempt.
 
 For an approval-needed retained run, a later explicit Implement invocation must inspect local `status`.
 When a newer owner-private-proof-bound receipt is present, status exposes its exact pair in `availableDelivery`, adds `resume` to `legalCommands`, and fills the matching `conditionalCommands` arguments.
-Resume with that discovered pair; do not require the user to copy revision or hash data from a prior Design conversation.
+Ordinary resume resolves that pair locally; do not require the user to copy revision or hash data from a prior conversation.
 Discovery never admits the delivery: `resume` still performs the full artifact, traceability, capability, and currentness validation before any Worker starts.
 
 ## Execution and verification
@@ -65,7 +82,7 @@ Discovery never admits the delivery: `resume` still performs the full artifact,
 Before any candidate, the engine records target-contract, task-affected, and full-suite baselines with normalized failure identities.
 A pre-existing failure remains separate and never satisfies Red or becomes evidence that this change caused it.
 
-For each ready task the engine runs:
+For each ready behavior task the engine runs:
 
 1. Red in a disposable child revision; the declared target must fail with the approved identity.
 2. Green with the minimum approved implementation; the declared target and task-affected contract must pass relative to baseline.
@@ -86,32 +103,93 @@ The main workspace stays unchanged before that transaction.
 Ordinary failures stay inside this Implement run:
 
 - `artifact`, wrong-Red identity, invalid/incomplete patch operation, stale candidate, or transport failure: use the bounded automatic attempt policy; after exhaustion pause with the last safe code and retain the last committed revision.
-- Artifact correction alone consumes the sealed `artifactCorrection.maxAttempts` of 2-3 total candidate launches per task phase and operation, including the initial launch; a later `resume` starts a fresh operation budget.
-- `environment` or `verification-adapter`: pause without speculative edits.
-  Resume after the capability is restored; baseline facts and completed phases are reused.
+- Artifact, stale-candidate, and verification correction share the sealed `artifactCorrection.maxAttempts` of 2-3 attempts per verification obligation and phase, including the initial attempt.
+  Automatic retries carry the safe failure code, strategy, and available failure identities to the next Worker.
+  Exhaustion survives process restart and `resume`.
+  Operation ids, route binding, rollback revisions, task renaming, and contract rewording never clear it.
+  Dedicated private incident records own the budget; displayed attempt diagnostics are not authority.
+  A run shares one cumulative work budget: 24 plus three units per largest admitted phase count, bounded by the host limit captured at run start (default 512).
+  Recompiling, renaming or returning to a previous plan size never adds credit; a genuinely larger admitted decomposition may increase capacity without refunding consumption.
+  Execution reserves work durably before launch, including nested repair proposals; restart and post-launch cancellation do not refund consumed work.
+- `environment` or `verification-adapter`: the executor pauses without speculative edits.
+  The parent inspects local diagnostics and restores available prerequisites using existing authorized capabilities, then resumes; baseline facts and completed phases are reused.
+  Do not request user input for a prerequisite the parent can restore.
+  Missing external credentials or unavailable services are reported only after local alternatives have been checked.
 - `pre-existing`: keep as baseline evidence.
   It does not authorize a code change and does not fail completion unless the change worsens it.
 - `introduced` in a task-affected contract: reopen the owning task as `repairable`, perform the minimum bounded repair inside its approved paths, record `repair-verified`, and re-run attribution automatically.
 - `unresolved` full-suite attribution: pause with failure identities and retained cumulative state; resume after evidence resolves ownership.
 - `workspace-revision-stale`, conflict, cancellation, process interruption, or apply recovery: preserve user edits and resume from the last durable checkpoint.
-  Cancellation is budget-neutral.
+  Cancellation before execution is budget-neutral; cancellation after launch does not count as a product failure and does not refund consumed work.
   During a partially visible final apply, recovery must settle before pause or discard.
-- `result-limit`: pause as `needs-task-split`; never accept a partial patch.
+- `result-limit` or a task-splitting request inside existing authority: automatically try a compact complete patch using exact replacements under the same bounded policy.
+  If it still cannot fit, the executor pauses as `needs-task-split` or `task-split-needed` and supplies an amendment continuation.
+  The parent recommends a smaller task decomposition, compiles the revised DAG, and resumes; never accept a partial patch or bypass compilation of the task DAG.
 
 No item above carries stage-routing metadata or asks the user to restart the approved workflow.
 
+Treat ordinary recovery as internal work.
+Workers may request additional ordinary regular-file reads within sealed task roots.
+The parent grants exact paths, retains their content dependencies across phases and restart, and binds them to merge and final currentness; hidden files, private-key files, out-of-root paths, and writes do not receive this discovery permission.
+Do not ask permission to correct approved code/tests, use task-wide approved read context, or retry within the sealed policy.
+Use local status and read-only diagnostics to identify environmental prerequisites before asking the user; resume once a concrete capability has been restored, and reuse baseline facts and completed phases.
+When status reports `recovery.exhausted`, do not issue unchanged `resume` calls.
+Inspect retained evidence.
+If status supplies a parent-owned amendment continuation, use it for a concrete plan correction; otherwise explain the specific missing capability or exhausted budget once.
+Rewriting prose or renaming tasks is not a correction and never replenishes execution budgets.
+A rebind may repair endpoint configuration but does not grant a new incident budget; do not repeatedly rebind and resume the same failure.
+If a revised delivery already exists, local status also discovers its exact revision/hash for an exhausted run; resume with `availableDelivery` without asking the user to copy receipt data.
+When `recovery.additionalAttempt` is present, the parent may make a concrete decision to retry once within remaining work capacity.
+Copy that object into an ordinary resume request's optional `recovery` field; do not invent incident keys or failure sequences.
+The default reason is `parent-directed-retry`; `route-changed` and `context-extended` additionally require control-plane evidence.
+This consumes one launch without resetting automatic correction history; another failure pauses again.
+Do not turn the availability of this option into an unconditional retry loop or another user approval round.
+Environment, resource and report protocol failures are unavailable verification, not product failures; restore prerequisites and reverify retained candidates.
+An unavailable endpoint, missing external credential, or irreducibly oversized task is not proof that product Design must restart.
+
 ## The only approval-needed boundary
 
-Use `approval-needed` only when continuing requires authority not present in the sealed delivery: new observable behavior, architecture or policy; a new/changed dependency; an undeclared write/delete/read target; expanded conflict/resource authority; a changed verification contract; an AGENTS target/impact/managed block change; or another irreversible scope decision.
+Use `approval-needed` only when continuing requires authority not present in the sealed delivery: new observable behavior, architecture or policy; a new/changed dependency; an undeclared write/delete target or a read outside sealed discovery roots; expanded conflict/resource authority; a changed verification contract; an AGENTS target/impact/managed block change; or another irreversible scope decision.
 
 Classify only codes in the closed authority table.
 An unknown Worker, verifier, or internal approval code is an `approval-code-invalid` integrity pause; never guess a category or Gate from keywords.
 
-Report the exact missing authority and retained run state.
-Do not discard compatible work.
-Expose `approval.category`, `approval.requiredGates`, safe `approval.refs`, and `approval.designRequest` as `/abel-design --change <change>` user guidance only; never invoke Design automatically.
-Bare `resume` is not immediately executable progress while approval is missing, so keep it out of `legalCommands` and expose it only in `conditionalCommands` with a `deliveryRevision` greater than the retained revision and the matching `receiptHash` precondition.
-If the user supplies that newly approved receipt revision, resume the same run with the revision/hash pair.
+Report all known missing authority together using `blockers` and `decisionBatch.items`; merge related choices and reuse accepted same-task decisions.
+The parent resolves new implementation choices with its recommended option under the accepted Design; do not ask the user for another decision round.
+`approval-needed` is an internal requirement to compile updated authority before a Worker continues, not a request for user input.
+`decisionBatch.resolution` identifies the parent as decision owner and `continuation` identifies the automatic next action.
+Follow it in this turn.
+`owner` and `automatic` are status metadata, not tool arguments.
+For amendment use the exact `decisionBatch.continuation` envelope plus `request`; for resume send the closed command envelope with a new operationId.
+A changed batch must cite the new evidence; never ask separately for each task's copy of the same decision.
+Retain the Implement stage and original run.
+`decisionBatch.continuation` supplies the exact `action: "amend"`, change, and batchId for the narrow private artifact revision channel.
+After selecting the recommended solution, use that envelope with a `request` containing the existing closed Design artifact operations: start the same change, retain inherited decisions, record the parent-selected changes, write the required change artifacts, compile, and finalize.
+This is implementation delegation from the accepted Design, not a fabricated new user answer.
+The same channel is available for the allowlisted `delivery-invalid`, `needs-task-split`, and `task-split-needed` technical pauses; these do not need a user decision or a fabricated approval-needed classification.
+Each run permits 64 mutating amendment attempts in a dedicated persistent budget.
+Failed writes/compilations consume that budget, successful operation replay is free, and restart or a new batch does not replenish it.
+Read-only status/preflight does not consume it.
+Fix the exact structured diagnostic before retrying compilation.
+Do not repeatedly submit unchanged invalid artifacts; once `amendmentBudget.exhausted` is true, stop mutation and report the retained result truthfully.
+For example, begin the revision with the returned change and batchId:
+
+```json
+{"action":"amend","change":"<same-change>","batchId":"<current-batch-id>","request":{"operation":"start","change":"<same-change>","operationId":"<unique-operation>"}}
+```
+
+Use the returned private revision runId on subsequent amendment requests.
+This channel does not activate Design, admit evidence packets, allow a different change, or grant product/AGENTS file writes.
+Keep the approved goal and explicit constraints stable.
+Automatic amendments retain Gate A and the structured ChangeContract.
+They cannot renew Gate A, replace behavior decisions, or rewrite proposal/spec artifacts.
+Resolve implementation gaps within the accepted goal, constraints and policy; when no conforming solution exists, report that concrete contract blocker and preserve progress rather than repeatedly attempting an invalid amendment.
+Never weaken acceptance criteria just to obtain a passing result.
+The compiler supplies Gate B automatically.
+Finish all known items in the batch before finalizing, then issue ordinary resume.
+Local delivery discovery supplies the newer verified revision/hash; do not ask the user to copy receipts or switch commands.
+An unchanged resume cannot bypass a pending decision, and stale batch ids or unrelated revision runIds are rejected.
+The user may explicitly choose a full Design discussion, but it is not the recovery instruction for an Implement blocker.
 A generated artifact defect, endpoint outage, stale snapshot, environment failure, pre-existing failure, introduced in-boundary repair, approved documentation/test edit, or approved AGENTS checkpoint is never `approval-needed`.
 
 ## AGENTS and tracking
@@ -120,9 +198,14 @@ Design-time AGENTS read-only authority does not carry into Implement.
 Gate B seals `none | update-existing | create-index | remove-index`, exact targets, owning task ids, verification, and the complete managed block.
 The parent control plane applies those operations only in the private cumulative revision, preserves all human text outside `<!-- ABEL:AGENTS-INDEX:START -->` and `<!-- ABEL:AGENTS-INDEX:END -->`, and never gives an AGENTS write path to a Worker.
 
+`remove-index` deletes a file only if no human content remains.
+Runtime/session ids, credentials, approval state, and dirty-state ledgers never enter an index.
+
 Task checkboxes are parent-owned progress facts.
 The loader may normalize only `[x]`/`[X]` to `[ ]` for the sealed task ids when checking the delivery hash; every other byte remains integrity-bound.
 
+When an approved browser E2E check requires `dev-browser` and it is unavailable, pause only that check; continue independent work when safe.
+
 ## Truthful completion
 
 Treat `queued`, `connecting`, `waiting-first-response`, `running`, `validating`, `retrying`, `verifying`, `paused`, `approval-needed`, `applying`, and `recovering` as nonterminal activity states.
@@ -131,9 +214,24 @@ Tool-call settlement is not success.
 Report success only when the durable state is `completed`, final application and post-apply verification committed, and private run content was cleaned.
 Terminal `completed`, `discarded`, or `rejected` settlement deactivates private dispatch; a nonterminal pause or approval wait keeps it active for direct follow-up.
 
-On a nonterminal result, report the safe code, affected task/scope when present, retained progress, and the exact legal command that continues or inspects the same run.
+On a nonterminal result with an automatic parent continuation, execute it and continue working; do not present internal Gate names, batch ids, receipts, or resume commands as user tasks.
+If automatic recovery is unavailable after investigation or its budget is exhausted, report the concrete blocker, retained progress, and only the external input needed to proceed.
+Respect explicit cancellation and never resume it automatically.
 Never hide an incomplete run behind a success checkmark.
 
 Do not archive, publish, release, stage, or commit implicitly.
 
 <!-- ABEL:END -->
+
+## Evidence modes and environment identity
+
+Follow the compiled task `verificationMode`.
+The default `behavior` mode retains Red/Green.
+Explicitly approved `mechanical` and `refactor` modes start execution at Green after baseline capture; do not invent a failing test or request a Red Worker.
+The compiler checks mode authority, path suitability and protected verifier inputs.
+All modes retain cumulative verification, output checks and transactional apply.
+
+`verification-environment-changed` is an unavailable environment, not a product regression.
+Installed dependency and runner content is bound to evidence; resume in a changed environment rebuilds baseline and revalidates retained phases.
+Reuse compatible sealed candidates.
+Do not edit product code to compensate for missing or drifting tools.

package/prompts/abel-init.md

@@ -3,14 +3,16 @@ description: Initialize or safely repair an Abel OpenSpec project
 argument-hint: "[project-path]"
 ---
 
-Load the bundled `abel-workflow` Skill before inspecting or writing the target.
-If it is unavailable, stop before writes and report one executable package restore or reinstall command.
+This procedure applies only when the user explicitly invokes `/abel-init`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
 Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
 </abel-request>
 
+<!-- ABEL:PROMPT:abel-init -->
+
 The request is an optional project path; when absent, use the current working directory.
 Resolve and report the canonical target root before action.
 
@@ -34,6 +36,8 @@ Resolve and report the canonical target root before action.
 5. Resolve and validate the selected schema and templates before claiming readiness.
 6. Create or repair only verified `<!-- ABEL:AGENTS-INDEX:START -->` … `<!-- ABEL:AGENTS-INDEX:END -->` managed regions.
    Preserve every byte of human content outside those markers and do not cross nested repositories.
+   Keep the index descriptive: file locations and ordinary project commands only; never instruct ordinary tasks to enter an Abel workflow.
+   Never record runtime/session ids, credentials, approval state, or dirty-state ledgers.
 7. Re-run all probes after writes.
    A second identical Init must produce no additional changes.
 
@@ -43,3 +47,6 @@ Do not probe `git-commit`, external `dev-browser`, or a dedicated time Skill; no
 
 Report one final result with the root, selected toolchain, actions actually taken, OpenSpec capability/schema/template evidence, AGENTS files changed or unchanged, research-Skill paths or remediation, and `ready | partial | paused`.
 Never report success from the initial probe when the post-write recheck did not pass.
+
+Init ends with that report; later ordinary tasks use normal engineering behavior.
+Never start another Abel stage, archive, publish, release, stage, or commit implicitly.