@use-the-fork/spindle 0.0.2 → 0.2.0

package/build/Assets/Blueprints/Catalog.js

@@ -21,7 +21,12 @@ export const blueprintCatalog = {
             stacks: [],
             canReview: true,
         },
-        "sdd-task-reviewer": { path: "sdd-task-reviewer.agent.md", status: "active", stacks: [] },
+        "sdd-task-reviewer": {
+            path: "sdd-task-reviewer.agent.md",
+            status: "active",
+            stacks: [],
+            canReview: true,
+        },
         "shared-explore": { path: "shared-explore.agent.md", status: "active", stacks: [] },
         "shared-r": { path: "shared-r.agent.md", status: "active", stacks: [] },
         "shared-rw": { path: "shared-rw.agent.md", status: "active", stacks: [] },
@@ -60,16 +65,16 @@ export const blueprintCatalog = {
         },
     },
     skills: {
-        "asd-ste100": { path: "asd-ste100/", status: "active", stacks: [] },
+        "ref-asd-ste100": { path: "ref-asd-ste100/", status: "active", stacks: [] },
         "author-agent": { path: "author-agent/", status: "active", stacks: [] },
-        "author-design": { path: "author-design/", status: "active", stacks: [] },
+        "sdd-author-design": { path: "sdd-author-design/", status: "active", stacks: [] },
         "author-instruction": { path: "author-instruction/", status: "active", stacks: [] },
         "author-skill": { path: "author-skill/", status: "active", stacks: [] },
         grill: { path: "grill/", status: "active", stacks: [] },
-        "grill-design": { path: "grill-design/", status: "active", stacks: [] },
+        "sdd-grill-design": { path: "sdd-grill-design/", status: "active", stacks: [] },
         "grill-with-docs": { path: "grill-with-docs/", status: "active", stacks: [] },
         implement: { path: "implement/", status: "active", stacks: [] },
-        "implement-spec": { path: "implement-spec/", status: "active", stacks: [] },
+        "sdd-implement-spec": { path: "sdd-implement-spec/", status: "active", stacks: [] },
         "improve-codebase-architecture": {
             path: "improve-codebase-architecture/",
             status: "active",
@@ -102,9 +107,14 @@ export const blueprintCatalog = {
         "int-writing-instruction": { path: "int-writing-instruction/", status: "active", stacks: [] },
         "int-writing-skills": { path: "int-writing-skills/", status: "active", stacks: [] },
         retrospective: { path: "retrospective/", status: "active", stacks: [] },
-        "setup-project": { path: "setup-project/", status: "active", stacks: [] },
-        "to-spec": { path: "to-spec/", status: "active", stacks: [] },
-        "to-tickets": { path: "to-tickets/", status: "active", stacks: [] },
-        "update-tooling": { path: "update-tooling/", status: "active", stacks: [] },
+        "ref-php-laravel-saloon-api-integrations": {
+            path: "ref-php-laravel-saloon-api-integrations/",
+            status: "active",
+            stacks: ["php-laravel"],
+        },
+        "sdd-to-spec": { path: "sdd-to-spec/", status: "active", stacks: [] },
+        "sdd-to-tickets": { path: "sdd-to-tickets/", status: "active", stacks: [] },
+        "spindle-project-setup": { path: "spindle-project-setup/", status: "active", stacks: [] },
+        "spindle-tooling-update": { path: "spindle-tooling-update/", status: "active", stacks: [] },
     },
 };

package/build/Assets/Blueprints/agents/sdd-implementer.agent.md

@@ -1,17 +1,17 @@
 ---
 name: sdd-implementer
-description: "Use when an orchestrator assigns one ticket or corrective round for subagent-driven development in an existing shared checkout."
+description: "Use when an orchestrator assigns one ticket or corrective round in its isolated worktree."
 tools: [read, search, edit, execute, read_skill, list_skills, skill]
 user-invocable: false
 agents: []
 metadata:
   spindle:
-    version: 1.4.1
+    version: 1.5.0
 ---
 
 # SDD implementer
 
-Implement one orchestrator-assigned ticket in an existing shared checkout. The orchestrator is the controller; it owns dispatch, execution states, acceptance, and the ticket-wide checks. Work sequentially with other editors and return evidence for the assigned ticket.
+Implement one orchestrator-assigned ticket in its isolated worktree. The orchestrator owns dispatch, execution states, acceptance, and the ticket-wide checks. Other tickets may run concurrently in their own worktrees.
 
 ## Required assignment gate
 
@@ -20,14 +20,14 @@ Before entering the flowchart, loading implementation skills, inspecting the che
 | Field                       | Required content                                                                                                                                      |
 | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `TICKET_ID`                 | The single assigned ticket identifier.                                                                                                                |
-| `CHECKOUT`                  | Absolute path to the existing shared checkout.                                                                                                        |
+| `CHECKOUT`                  | Absolute path to the assigned ticket worktree.                                                                                                        |
 | `ABSOLUTE_SOURCE_POINTERS`  | Absolute paths to the canonical ticket, comments, and spec/brief. Explicitly identify any source that does not apply.                                 |
 | `CRITERIA_AND_SEAMS`        | Acceptance criteria and confirmed test seams.                                                                                                         |
 | `DEPENDENCIES_AND_SNAPSHOT` | Completed dependencies and starting revision, including existing dirty/untracked changes. Explicitly state when there are no dependencies or changes. |
 | `FILE_SCOPE`                | Allowed code, test, and `.scratch` files.                                                                                                             |
 | `CHECKS_AND_DIRECTORY`      | Approved project checks and their test working directory; identify any checks explicitly scheduled for this worker.                                   |
 | `PERMISSIONS`               | Allowed actions, including explicit commit authorization or denial.                                                                                   |
-| `REPORT_PATH`               | Assigned `.scratch` report path within `FILE_SCOPE`, absolute or relative to `CHECKOUT`.                                                              |
+| `REPORT_PATH`               | Assigned absolute report path in the canonical feature workspace, within `FILE_SCOPE`.                                                               |
 | `MODE`                      | `INITIAL` or `CORRECTIVE`.                                                                                                                            |
 
 Accept populated template labels or equivalent structured fields, including grouped headings with labeled values beneath them. Legacy `For a fix: NONE` selects initial mode; populated fix context selects corrective mode. For `CORRECTIVE`, read `references/implementer-corrections.md` in the `int-subagent-driven-dev` skill before accepting the gate. Initial assignments need no corrective fields or resource.
@@ -74,4 +74,4 @@ Save the report at `REPORT_PATH` with:
 - For corrective mode, include the finding evidence required by `references/implementer-corrections.md` in the `int-subagent-driven-dev` skill.
 - A concise hand-back summary; include commit identifiers only when authorized.
 
-Update only assigned tracker files in `.scratch`, preserving history. Failed or unavailable required implementer checks block completion. Return the report path and concise summary, then stop. If the assignment gate is incomplete, return the context request instead of writing a report.
+Write only the assigned report in the canonical feature workspace; the controller owns tracker updates. Failed or unavailable required implementer checks block completion. Return the report path and concise summary, then stop. If the assignment gate is incomplete, return the context request instead of writing a report.

package/build/Assets/Blueprints/agents/sdd-orchestrator.agent.md

@@ -4,10 +4,10 @@ description: "Use when coordinating feature tickets, implementation, review, and
 argument-hint: The feature spec, tickets, constraints, and permissions.
 user-invocable: true
 tools: [vscode/askQuestions, execute, read, agent, edit, web, todo, read_skill, list_skills, skill]
-agents: [sdd-implementer, sdd-reviewer, sdd-code-reviewer, shared-explore]
+agents: [sdd-implementer, sdd-task-reviewer, sdd-reviewer, sdd-code-reviewer, shared-explore]
 metadata:
   spindle:
-    version: 1.2.1
+    version: 1.4.0
 ---
 
 You are the SDD orchestration agent for feature tickets and feature-level delivery. Follow the user's scope and permissions.
@@ -23,11 +23,8 @@ the current harness before dispatch. Catalog `canReview: true` establishes
 eligibility only; it does not establish harness access. Never create an
 automatic or default specialist batch.
 
-Close a ticket with `sdd ticket update --status closed` after its acceptance
-criteria are met. Do not require per-ticket accept or integration commands.
-Feature completion requires every ticket closed, current passing feature checks
-and reviews, and no unresolved delivery blockers. Use the normal Git workflow;
-never ask the CLI to stage, commit, stash, discard, push, or publish.
+Finish only after aggregate review, the final merge, and its declared checks.
+Preserve worktrees and records whenever validation or cleanup is blocked.
 
 <communication-style>
 - **ALWAYS** think and respond in the same spoken language the prompt was written in.

package/build/Assets/Blueprints/skills/author-agent/SKILL.md

@@ -1,26 +1,27 @@
 ---
 name: author-agent
 description: Create or revise a workspace custom agent from requirements.
-argument-hint: "[--test] <agent idea or requirements>"
+argument-hint: "<agent idea or requirements>"
 disable-model-invocation: true
 user-invocable: true
 metadata:
   spindle:
-    version: 1.0.0
+    version: 1.0.2
 ---
 
 Create or update a project agent in `.github/agents/<agent-name>.agent.md` based on the user's requirements.
 
-## Required skills
+## Authoring flow
 
-Before drafting or editing, read:
+{{ computed.authoring_flowchart }}
+
+Before grilling, read and consider only the `int-writing-for-agents` and `ref-asd-ste100` skills. Do not follow their workflows or load skills they reference yet.
+
+After the user confirms shared understanding, load and follow:
 
 - **REQUIRED:** `int-writing-agents`
-- **REQUIRED:** `int-writing-for-agents`
 - **REQUIRED:** `int-testing-agent-guidance`
 
-These skills define the complete authoring workflow. Every agent change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
-
-When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+Apply the clarity rules from the `ref-asd-ste100` skill. Include a before/after table only when the user requests one. Run the core and expanded testing workflows in `int-testing-agent-guidance` for every authoring request.
 
 Do not modify unrelated files. Report the skill changed and validation performed, including any blockers or unverified requirements.

package/build/Assets/Blueprints/skills/author-instruction/SKILL.md

@@ -1,27 +1,28 @@
 ---
 name: author-instruction
 description: Create or revise workspace-scoped Copilot instruction files from the user's requirements
-argument-hint: "[--test] <instruction requirements>"
+argument-hint: "<instruction requirements>"
 disable-model-invocation: true
 user-invocable: true
 metadata:
   spindle:
-    version: 1.0.0
+    version: 1.0.2
 ---
 
 Create or update a project instruction in `.github/instructions/**/*.instructions.md` based on the user's requirements.
 
-## Required skills
+## Authoring flow
 
-Before drafting or editing, read:
+{{ computed.authoring_flowchart }}
+
+Before grilling, read and consider only the `int-writing-for-agents` and `ref-asd-ste100` skills. Do not follow their workflows or load skills they reference yet.
+
+After the user confirms shared understanding, load and follow:
 
 - **REQUIRED:** `int-writing-instruction`
-- **REQUIRED:** `int-writing-for-agents`
 - **REQUIRED:** `int-testing-agent-guidance`
 
-These skills define the complete authoring workflow. Every instruction change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
-
-When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+Apply the clarity rules from the `ref-asd-ste100` skill. Include a before/after table only when the user requests one. Run the core and expanded testing workflows in `int-testing-agent-guidance` for every authoring request.
 
 Verify any `applyTo` glob against concrete in-scope files and near misses; every intended file must match, and out-of-scope files must not.
 

package/build/Assets/Blueprints/skills/author-skill/SKILL.md

@@ -1,26 +1,27 @@
 ---
 name: author-skill
 description: Create or update a project skill from the user's requirements
-argument-hint: "[--test] <skill idea or requirements>"
+argument-hint: "<skill idea or requirements>"
 disable-model-invocation: true
 user-invocable: true
 metadata:
   spindle:
-    version: 1.0.0
+    version: 1.0.2
 ---
 
 Create or update a project skill in `.github/skills/<skill-name>/SKILL.md` based on the user's requirements.
 
-## Required skills
+## Authoring flow
 
-Before drafting or editing, read:
+{{ computed.authoring_flowchart }}
+
+Before grilling, read and consider only the `int-writing-for-agents` and `ref-asd-ste100` skills. Do not follow their workflows or load skills they reference yet.
+
+After the user confirms shared understanding, load and follow:
 
 - **REQUIRED:** `int-writing-skills`
-- **REQUIRED:** `int-writing-for-agents`
 - **REQUIRED:** `int-testing-agent-guidance`
 
-These skills define the complete authoring workflow. Every skill change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
-
-When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+Apply the clarity rules from the `ref-asd-ste100` skill. Include a before/after table only when the user requests one. Run the core and expanded testing workflows in `int-testing-agent-guidance` for every authoring request.
 
 Do not modify unrelated files. Report the skill changed and validation performed, including any blockers or unverified requirements.

package/build/Assets/Blueprints/skills/grill/SKILL.md

@@ -4,7 +4,7 @@ description: "Grill the user relentlessly about a plan, decision, or idea. Use w
 user-invocable: false
 metadata:
   spindle:
-    version: 1.0.2
+    version: 1.0.3
 ---
 
 Stress-test the user's proposal until its decisions are explicit and you share an understanding. Treat dependent decisions as a **design tree**.
@@ -16,13 +16,13 @@ Stress-test the user's proposal until its decisions are explicit and you share a
 3. Apply the answer and continue the queue, revising or skipping questions whose premises changed. Newly unlocked decisions wait for the next round.
 4. When the queue is exhausted, recompute the frontier and start the next round.
 
-Label each question visibly as **Round <R>, Question <Q> of <TOTAL> - <title>**, in chat or the tool's user-visible title. Start both counters at 1; increment the question number for each question asked and reset it to 1 when the round advances. The first question announces the new round without exposing the remaining queue.
+Label each question visibly as **Round <R>, Question <Q> - <title>**, in chat or the tool's user-visible title. Start both counters at 1; increment the question number for each question asked and reset it to 1 when the round advances. The first question announces the new round without exposing the remaining queue.
 
 Include the context needed to decide and a recommended answer. Phrase confirmations so "yes" accepts the recommendation; for choices, identify the recommended option.
 
 Example opening:
 
-> **Round 1, Question 1 of 5 - Output format**
+> **Round 1, Question 1 - Output format**
 >
 > CSV meets the agreed export requirements. I recommend CSV. Shall we use it?
 

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/SKILL.md

@@ -4,15 +4,13 @@ description: "This is an internal skill do not load it unless explicitly require
 user-invocable: false
 metadata:
   spindle:
-    version: 1.4.0
+    version: 1.6.0
 ---
 
 # Subagent-Driven Development
 
 The controller coordinates a feature's tickets, workers, checks, reviews, and completion. The feature workspace and `sdd.json` are the source of truth for structured ticket and delivery state; each ticket Markdown file holds its requirements, acceptance criteria, and discussion.
 
-Use the existing checkout and preserve user changes and report history. TDD is optional; write appropriate tests and record verification evidence. Load and follow `int-verification-before-completion` before claiming work is complete. Serialize implementation and fixes, and keep implementation edits frozen while a review batch is running.
-
 ## Workflow map
 
 Before acting on each chart node, announce `Step <node ID> - <node label>`, including initial entries, resumed steps, and loop re-entries. After each decision, state its result and selected branch before entering the target node.
@@ -20,7 +18,7 @@ Before acting on each chart node, announce `Step <node ID> - <node label>`, incl
 ```mermaid
 flowchart TD
     A[Restore feature state and readiness] --> B{Ready ticket available?}
-    B -- Yes --> C[Claim, implement, verify, submit, close ticket]
+    B -- Yes --> C[Implement, review, integrate, and validate tickets]
     C --> A
     B -- No --> D{All tickets closed?}
     D -- No --> E[Resolve prerequisites or record blocker]
@@ -41,21 +39,27 @@ flowchart TD
 
 ## Ticket workflow
 
-1. Read the feature spec, tickets, applicable instructions, glossary, and ADRs. Inspect `spindle sdd status --spec <path>` and `spindle sdd ready --spec <path>` to understand blockers, dependencies, and available work.
-2. Create a ticket for independently actionable work with `spindle sdd ticket create`. Fill its `[REQUIREMENTS]` and `[ACCEPTANCE CRITERIA]` placeholders. Use `spindle sdd ticket update` for tracker status, explicit blockers, and dependencies; the supported lifecycle is `open`, `in-progress`, and `closed`. Readiness is derived from status, blockers, and dependencies rather than stored as a separate triage state.
-3. Claim a ready ticket with `spindle sdd claim`. Dispatch implementation with `spindle sdd implement`; pass the worker the exact assignment and report destination. Submit its report with `spindle sdd submit --role implementation`.
-4. Run relevant tests and checks and record their actual outcomes against the current snapshot. TDD is not required, but verification is.
-5. Address implementation and verification gaps, then close the ticket with `spindle sdd ticket update --status closed` once its acceptance criteria are met. Do not use per-ticket accept or integrate steps.
+1. Read the feature spec, tickets, applicable instructions, glossary, and ADRs. Inspect `{{ computed.spindle_package_manager }} spindle sdd status --spec <path>` and `{{ computed.spindle_package_manager }} spindle sdd ready --spec <path>` to understand blockers, dependencies, and available work. Inspect feature records for secrets and start the feature worktree with `{{ computed.spindle_package_manager }} spindle sdd start --spec <path> --workspace <external-directory> --confirm-records`. Handle unrelated changes before starting. Run subsequent controller commands in the feature worktree using its returned spec path.
+2. Create a ticket for independently actionable work with `{{ computed.spindle_package_manager }} spindle sdd ticket create`. Fill its `[REQUIREMENTS]` and `[ACCEPTANCE CRITERIA]` placeholders. Use `{{ computed.spindle_package_manager }} spindle sdd ticket update` for tracker status, explicit blockers, and dependencies; the supported lifecycle is `open`, `in-progress`, and `closed`. Readiness is derived from status, blockers, and dependencies rather than stored as a separate triage state.
+3. Choose a safe concurrency limit. Use `{{ computed.spindle_package_manager }} spindle sdd implement --workspace <external-directory>` for each ready ticket and dispatch the returned assignment until capacity is full. As workers finish, dispatch other ready independent tickets without waiting for unrelated work. Inspect changed canonical records for secrets and pass `--confirm-records` before any automatic record commit. Each worker uses its own worktree. Give workers the canonical source and report paths; submit each implementation report with `{{ computed.spindle_package_manager }} spindle sdd submit --role implementation`.
+4. Have each implementer commit its changes. Record relevant checks and submit reviews against that exact ticket commit. Keep its worktree frozen during review; any changed commit requires fresh checks and review.
+5. Use `{{ computed.spindle_package_manager }} spindle sdd integrate` to merge reviewed work, inspecting changed canonical records and passing `--confirm-records` before any automatic record commit. Serialize merges and their post-merge checks. Declare the full non-empty check list with `checks require --scope post-merge`, run it in the feature worktree, and record results with `checks record --scope post-merge`. Passing checks close the ticket automatically and unblock eligible dependents.
+
+   If closure is blocked by a ticket blocker or unmet dependency, resolve it and repeat `checks require --scope post-merge` with the same complete list. Passing evidence is retained; rerun checks if their snapshot became stale.
+
+   If a post-merge check fails, keep other merges blocked. Fast-forward the clean ticket worktree to the recorded failed merge commit, then use `sdd correct --check-failure <command>` to dispatch a fix. Commit, check, and review the fix before merging it and rerunning the frozen post-merge check list.
+
+   If integration reports a conflict, rebase the ticket worktree onto the current feature branch, resolve and commit the conflict there, and use `sdd checks require --rebase-baseline` with an existing required command. Run fresh checks and obtain fresh review before retrying integration. Preserve all uncommitted changes and stop if recovery is unsafe.
 
-If work is interrupted, inspect `spindle sdd status` and use `spindle sdd resume` to restore the recorded assignment. Preserve existing reports, findings, and evidence. Do not invent missing results or reset progress.
+If work is interrupted, inspect `{{ computed.spindle_package_manager }} spindle sdd status` and use `{{ computed.spindle_package_manager }} spindle sdd resume` to restore the recorded assignment. Preserve existing reports, findings, and evidence. Do not invent missing results or reset progress.
 
 ## Feature review and completion
 
-After every ticket is closed, establish current feature-level checks and request the comprehensive review with `spindle sdd review --scope delivery --inventory <json-array>`. The `sdd-reviewer` is the default reviewer. Add specialists only for justified objectives with `spindle sdd review require --scope delivery --type <agent-name>`; eligible names must be marked `canReview: true` in the Blueprint Catalog, and actual agent access must be confirmed before dispatch.
+After every ticket is closed, establish current feature-level checks and request the comprehensive review with `{{ computed.spindle_package_manager }} spindle sdd review --scope delivery --inventory <json-array>`. The `sdd-reviewer` is the default reviewer. Add specialists only for justified objectives with `{{ computed.spindle_package_manager }} spindle sdd review require --scope delivery --type <agent-name>`; eligible names must be marked `canReview: true` in the Blueprint Catalog, and actual agent access must be confirmed before dispatch.
 
 Submit every assigned review report against its exact assignment. Register findings from their report and snapshot. A blocking finding can name `--related-ticket`; once the complete review batch is submitted, that ticket is reopened so work can resume. Resolve blocking findings through ticket work and repeat any invalidated checks and reviews.
 
-For detailed review, findings, correction, and finish steps, read [feature delivery](./references/full-spec.md). For feature-level corrective work, follow [corrective rounds](./references/corrective-rounds.md). Feature completion requires all tickets closed, current passing required checks and reviews, and no unresolved delivery blockers. Use the normal Git workflow; SDD does not stage, commit, or publish work and has no per-ticket integration command.
+For detailed review, findings, correction, final merge, checks, and cleanup, read [feature delivery](./references/full-spec.md). For feature-level corrective work, follow [corrective rounds](./references/corrective-rounds.md). Feature completion requires all tickets integrated, current passing required checks and reviews, no unresolved delivery blockers, and passing checks on the final merge. Do not modify the affected checkout concurrently with a Git transition. Never stash, discard, force-delete, push, or publish without authorization.
 
 ## Reports and verification
 

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/assets/implementer-prompt.md

@@ -4,7 +4,7 @@
 ## Assignment
 
 Implement ticket: [TICKET_ID]
-Checkout: [CHECKOUT]
+Ticket worktree: [CHECKOUT]
 Mode: [INITIAL_OR_CORRECTIVE]
 
 ## Requirements and starting state
@@ -20,7 +20,7 @@ Completed dependencies and starting snapshot:
 
 ## Scope and permissions
 
-Allowed code, test, and `.scratch` files:
+Allowed code and test files in the ticket worktree, and the canonical report path:
 [FILE_SCOPE]
 
 Permissions, including commit authorization:

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/references/corrective-rounds.md

@@ -38,7 +38,7 @@ adjudication rather than another automatic dispatch.
 
 ## C. Record objective and dispatch correction
 
-Use `spindle sdd correct --scope delivery` to record and dispatch the feature-level
+Use `{{ computed.spindle_package_manager }} spindle sdd correct --scope delivery` to record and dispatch the feature-level
 correction. Preserve prior attempts, reports, and report destinations.
 Serialize implementation edits and keep the assignment limited to the
 recorded objective.

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/references/example-workflow.md

@@ -5,21 +5,23 @@ Markdown holds requirements and acceptance criteria; `sdd.json` holds tracker
 status and dependencies.
 
 1. Create a feature workspace and split independent work into tickets:
-   `spindle sdd create`, then `spindle sdd ticket create` for each ticket.
+   `{{ computed.spindle_package_manager }} spindle sdd create`, then `{{ computed.spindle_package_manager }} spindle sdd ticket create` for each ticket.
 2. Record the dependency with
-   `spindle sdd ticket update --ticket T-0002 --blocked-by T-0001`. Check `spindle sdd ready`:
+   `{{ computed.spindle_package_manager }} spindle sdd ticket update --ticket T-0002 --blocked-by T-0001`. Check `{{ computed.spindle_package_manager }} spindle sdd ready`:
    the prerequisite is ready and the dependent ticket is not.
-3. Claim and implement `T-0001`, submit its report, run and record relevant
-   checks, then close it with `spindle sdd ticket update --status closed`.
-4. `T-0002` becomes ready because its dependency is closed. Implement and
-   verify it in the same way, then close it.
+3. Start the feature worktree in the supplied external directory. Implement
+   `T-0001` in its ticket worktree, submit its report, review the committed
+   change, and merge it into the feature branch. Declare and record passing
+   post-merge checks before it closes.
+4. `T-0002` becomes ready once its dependency is integrated and validated.
+   Branch it from the updated feature branch and deliver it in the same way.
 5. Record current feature-level required checks and request the comprehensive
-   review with `spindle sdd review --scope delivery`. Add only justified specialists.
+   review with `{{ computed.spindle_package_manager }} spindle sdd review --scope delivery`. Add only justified specialists.
 6. Submit every assigned report. Register findings from their report and
    snapshot. A blocking finding can reopen its related ticket; complete the
    correction, close the ticket again, and refresh stale checks and review.
-7. Finish when every ticket is closed, all required checks and reviews pass on
-   the current feature snapshot, and no delivery blockers remain.
-
-Use the normal Git workflow for code. There is no per-ticket accept or
-integration step; the SDD CLI does not stage or commit changes.
+7. Inspect canonical records and run `sdd finish --confirm-records` from the
+   feature worktree. In the original checkout, declare and run the complete
+   `checks require --scope final` list, record results against the returned
+   merge and snapshot, then run `sdd finish` again to clean up. The checked
+   merge and the later metadata-only commit are reported separately.

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/references/full-spec.md

@@ -7,16 +7,16 @@ checks, review assignments, findings, and corrections.
 
 ## Checks and review
 
-Inspect `spindle sdd status --spec <spec>` and `spindle sdd next --spec <spec>`. Establish
-required final checks with `spindle sdd checks require --scope delivery`, run them, and
+Inspect `{{ computed.spindle_package_manager }} spindle sdd status --spec <spec>` and `{{ computed.spindle_package_manager }} spindle sdd next --spec <spec>`. Establish
+required final checks with `{{ computed.spindle_package_manager }} spindle sdd checks require --scope delivery`, run them, and
 record actual results against the returned snapshot. Then dispatch the
 comprehensive review with
-`spindle sdd review --scope delivery --inventory <json-array>`. Its inventory must
+`{{ computed.spindle_package_manager }} spindle sdd review --scope delivery --inventory <json-array>`. Its inventory must
 cover the feature's current Git-derived changes.
 
 The `sdd-reviewer` is the default comprehensive reviewer. Before dispatch,
 record any justified specialist with
-`spindle sdd review require --scope delivery --type <agent-name> --details <objective>`.
+`{{ computed.spindle_package_manager }} spindle sdd review require --scope delivery --type <agent-name> --details <objective>`.
 Only catalog agents with `canReview: true` are eligible. Confirm that the
 controller can actually dispatch each selected agent; catalog eligibility does
 not guarantee harness access.
@@ -28,45 +28,65 @@ failed, unavailable, stale, or mismatched review blocks completion.
 ## Findings and correction
 
 Register findings from their assigned reports and snapshots with
-`spindle sdd finding create --scope delivery`. Delivery findings have feature-scoped
+`{{ computed.spindle_package_manager }} spindle sdd finding create --scope delivery`. Delivery findings have feature-scoped
 IDs, provenance, ruling history, and status. Use `--related-ticket <id>` for a
 finding that should return work to a specific ticket. A blocking linked finding
 reopens its ticket after the complete review batch is submitted; dependent
 tickets remain blocked until that ticket is closed again.
 
-Use `spindle sdd finding update --scope delivery` for explicit rulings. Deferring a
+Use `{{ computed.spindle_package_manager }} spindle sdd finding update --scope delivery` for explicit rulings. Deferring a
 blocker requires rationale, a follow-up reference, and an approved delivery
 requirements decision. Record that decision with
-`spindle sdd requirements decide --scope delivery` only after a requirements change
+`{{ computed.spindle_package_manager }} spindle sdd requirements decide --scope delivery` only after a requirements change
 and completed prior review. Approval invalidates earlier aggregate assignments.
 
 For actionable feature findings, follow [feature correction](./corrective-rounds.md)
-and use `spindle sdd correct --scope delivery` to record
+and use `{{ computed.spindle_package_manager }} spindle sdd correct --scope delivery` to record
 each independent correction attempt. Record passing checks against the changed
 feature snapshot and submit the implementation report before requesting a new
 feature review. Pause unproductive work, recurring failures, or requirements
-disagreement for adjudication. Resume with `spindle sdd resume --scope delivery`;
+disagreement for adjudication. Resume with `{{ computed.spindle_package_manager }} spindle sdd resume --scope delivery`;
 preserve existing assignments, attempts, evidence, and adjudication.
 
 ## Finish
 
-Use the normal Git workflow for code changes. SDD does not stage, commit,
-publish, or require a per-ticket integration confirmation. A changed code or
+Review each committed ticket before merging it into the feature worktree, then
+record post-merge checks before unblocking dependents. A changed code or
 requirements snapshot invalidates evidence that no longer covers it.
 
-Legacy feature workspaces without a recorded Git baseline stay blocked until
-the original comparison baseline is identified. Do not silently use the
-current `HEAD` after implementation; that could omit completed feature work
-from review.
+Do not silently substitute the current `HEAD` for the recorded Git baseline;
+that could omit completed feature work from review.
 
-Finish with `spindle sdd finish --spec <spec> --author <author>`. Completion requires
-at least one ticket, every ticket closed, current passing required feature
-checks and reviews, and no unresolved delivery blockers. The retrospective
-policy is stored at feature creation: when required, attach a Markdown report
-with `--report`; otherwise it is optional. Any report must remain inside that
-feature's `reports/` directory.
+Completion requires at least one ticket, every ticket integrated and validated,
+current passing required feature checks and reviews, and no unresolved delivery
+blockers. The retrospective policy is stored at feature creation: when required,
+attach a Markdown report with `--report`; otherwise it is optional. Any report
+must remain inside that feature's `reports/` directory.
 
-Use `spindle sdd status`, `spindle sdd next`, and
-`spindle sdd resume --scope delivery` to inspect blockers and
+Inspect canonical records for sensitive content, then run
+`{{ computed.spindle_package_manager }} spindle sdd finish --spec <feature-spec> --author <controller> --confirm-records`
+from the feature worktree, adding `--report <absolute-report-path>` when needed.
+This merges into the recorded original branch and returns a pending final
+validation, merge SHA, snapshot, and original spec path; it does not yet complete
+the feature.
+
+In the original checkout, declare the entire non-empty final list with
+`{{ computed.spindle_package_manager }} spindle sdd checks require --spec <original-spec> --scope final --command <command> --author <controller>`,
+repeating `--command` for each check. Run each command there, then record each
+actual result with `{{ computed.spindle_package_manager }} spindle sdd checks record --spec <original-spec> --scope final --merge <merge-sha> --snapshot <snapshot> --command <command> --result <result> --author <controller>`.
+Failed or unavailable results require `--details` and block cleanup until the
+latest result for each command passes. The list is frozen once declared.
+
+Run `{{ computed.spindle_package_manager }} spindle sdd finish --spec <original-spec> --author <controller>`
+again to preflight and clean up the recorded worktrees and branches. The final
+merge is the checked commit; the subsequent ledger-only relocation commit is
+reported separately and is not itself checked. Preserve any dirty or unexpected
+work and follow the reported journal for recovery rather than forcing cleanup.
+Ignored files in worktrees slated for removal also block cleanup; do not discard
+them without authorization. After a crash, remove a reported finalization lock
+only after verifying its recorded owner has stopped.
+
+Use `{{ computed.spindle_package_manager }} spindle sdd status`, `{{ computed.spindle_package_manager }} spindle sdd next`, and
+`{{ computed.spindle_package_manager }} spindle sdd resume --scope delivery` to inspect blockers and
 restore interrupted feature-level work. These commands do not close tickets or
 publish changes.

package/build/Assets/Blueprints/skills/int-subagent-driven-dev/references/review-inputs.md

@@ -6,18 +6,18 @@ Read when preparing or accepting a review assignment. The controller supplies th
 
 `REVIEW_INPUTS` names an absolute, read-required package/manifest path. Read it and its required sources before inspecting the checkout or reviewing. Equivalent structured inputs inline remain valid; preserve supplied values rather than inferring missing revisions from Git.
 
-| Input                  | Required meaning                                                                                                                                                                                                                          |
-| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Requirements           | Canonical ticket/spec/comments pointers, applicable instructions, criteria, and constraints. Identify inapplicable sources explicitly.                                                                                                    |
-| Workspace and snapshot | Absolute shared checkout; exact reviewed identity, comparison base and head revisions, and included dirty/untracked changes or `NONE`. SHAs are provenance metadata and may live in the package rather than repeated prompt fields.       |
-| Complete change        | Complete assigned diff with file inventory, stat, and enough context, or approved read-only retrieval using supplied revisions. Include dirty/untracked additions and binary changes, or identify unavailable material as a coverage gap. |
-| Verification           | Commands, results, test summary, exact snapshot covered, and unavailable required checks. Evidence pointers are valid; read them before judging coverage.                                                                                 |
+| Input                  | Required meaning                                                                                                                                                                                                                                               |
+| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Requirements           | Canonical ticket/spec/comments pointers, applicable instructions, criteria, and constraints. Identify inapplicable sources explicitly.                                                                                                                         |
+| Workspace and snapshot | Absolute ticket or feature worktree, as appropriate; exact reviewed identity, comparison base and head revisions, and included dirty/untracked changes or `NONE`. SHAs are provenance metadata and may live in the package rather than repeated prompt fields. |
+| Complete change        | Complete assigned diff with file inventory, stat, and enough context, or approved read-only retrieval using supplied revisions. Include dirty/untracked additions and binary changes, or identify unavailable material as a coverage gap.                      |
+| Verification           | Commands, results, test summary, exact snapshot covered, and unavailable required checks. Evidence pointers are valid; read them before judging coverage.                                                                                                      |
 
 Keep every meaning authoritative in one place: reference canonical requirements, reports, and evidence rather than copying full logs or the entire ledger. A pointer must identify the required material, not merely say "see ledger". The role-specific assignment supplies phase, objective, history relevant to that role, and its distinct report destination.
 
 ## Snapshot ownership and completeness
 
-The controller owns construction, freezing, and freshness checks. Reuse existing durable complete diffs and evidence; no additional packaging command or hash scheme is required. The identity must distinguish uncommitted/untracked content, not just HEAD. Keep implementation frozen throughout the review batch, allowing assigned report writes without changing the reviewed code identity.
+The controller owns construction, freezing, and freshness checks. Reuse existing durable complete diffs and evidence; no additional packaging command or hash scheme is required. Ticket reviews must cover the exact committed ticket revision and its complete change against the assigned base. Keep that worktree clean and frozen throughout the review batch; reports are written to the canonical feature workspace.
 
 Corrections produce a new reviewed identity with fresh covering checks. Preserve the previous package and evidence as history rather than relabeling them as verification of changed code.
 

package/build/Assets/Blueprints/skills/int-testing-agent-guidance/SKILL.md

@@ -2,7 +2,7 @@
 name: int-testing-agent-guidance
 metadata:
   spindle:
-    version: 1.0.0
+    version: 1.0.1
 description: "{{ computed.internal_skill_description }}"
 user-invocable: false
 ---
@@ -32,7 +32,7 @@ Use this workflow for behavior-shaping changes to skills, agents, prompts, instr
 
 ## Expanded testing
 
-Use expanded testing when the user requests it or the skill is invoked with `--test`. This adds independent samples; it does not replace the core baseline and retest.
+Always run expanded testing for authoring tasks. It adds independent samples and does not replace the core baseline and retest.
 
 1. Freeze scenario prompts and observable pass criteria before dispatch. Cover each meaningful branch. For discipline-enforcing guidance, use at least three scenarios, each combining at least three pressures such as deadline, authority, sunk cost, or exhaustion.
 2. Run five independent read-only agents against the baseline. For a new document, provide no proposed guidance; for an edit, provide the current version. Each agent runs every scenario once and reports its concrete choices and rationalizations verbatim.

package/build/Assets/Blueprints/skills/int-writing-skills/SKILL.md

@@ -4,7 +4,7 @@ description: "{{ computed.internal_skill_description }}"
 user-invocable: false
 metadata:
   spindle:
-    version: 1.3.0
+    version: 1.3.1
 ---
 
 # Writing Skills
@@ -118,7 +118,7 @@ Compare observed behavior with the unchanged criterion. An unresolved failure se
 
 ### G. Refactor and deliver
 
-Prune duplication, stale material, and speculative rules. Retest after wording changes. Verify frontmatter, relative links, resource packaging, and any required version bump. Run expanded testing only when requested, including `--test`.
+Prune duplication, stale material, and speculative rules. Retest after wording changes. Verify frontmatter, relative links, resource packaging, and any required version bump. Always run expanded testing with `int-testing-agent-guidance`.
 
 **Complete when:** final validation passes or limitations are explicit, and the change is ready for authorized delivery. Commit, push, or open a PR only when requested.
 

package/build/Assets/Blueprints/skills/int-writing-skills/references/testing-skills.md

@@ -36,7 +36,7 @@ For discipline-enforcing guidance, consult [Persuasion principles](./persuasion-
 
 Rerun the same prompt and criterion with the full revised guidance in a fresh context. Check actual choices, resource loads, and artifacts. Correct remaining failures narrowly, then rerun after each wording change.
 
-Run expanded testing only when explicitly requested or when `--test` is present, using `int-testing-agent-guidance`. It adds coverage rather than replacing the focused baseline and retest.
+Always run expanded testing with `int-testing-agent-guidance`. It adds coverage rather than replacing the focused baseline and retest.
 
 | Testing pitfall                         | Required evidence                                               |
 | --------------------------------------- | --------------------------------------------------------------- |
@@ -45,4 +45,4 @@ Run expanded testing only when explicitly requested or when `--test` is present,
 | "There is no time"                      | Recorded validation or an explicit blocker, not claimed success |
 | "The output is close enough"            | The unchanged observable criterion passes                       |
 
-**Complete when:** the final focused scenario passes without unresolved failures, requested expanded testing is complete, or remaining failures and validation limits are explicitly reported.
+**Complete when:** the final focused scenario passes without unresolved failures, expanded testing is complete, or remaining failures and validation limits are explicitly reported.