vaultspec-execute ยท diff
git:20260905.f755314 to git:20260908.af390dd
19 added, 14 removed. Audit A to A.
---
name: vaultspec-execute
description: Execute an approved plan Step by Step, across sessions. Use to start or resume a plan; it is the only skill that spans sessions.
---
# Execute (vaultspec-execute)
Works an approved plan from its next open Step, leaving a checkpoint after every Step so
any later session resumes without re-reading the cluster. Precondition: the plan has an
- approval reply from the user. A plan without one is not executed.
+ scoped authorization from the user, recorded per the vaultspec system section.
## Resume
- `vaultspec-core status <feature>` (or the `status` tool) names the next open Step. A
- plan whose Description lacks an `Approved` line is presented again first.
+ plan whose Description lacks an `Approved` line needs its authorization established:
+ persist existing authorization or present it and ask when none exists.
- On the plan's first entry read it whole; on resume, read the next Step's row and the
- ADR sections it depends on.
+ ADR sections it depends on, if any. Confirm the decisions needed by the next Step are
+ accepted; reassess coverage when reopening historical work.
- Ground the Step per the `vaultspec-discovery` rule before editing.
- A dispatched worker skips orientation (the orchestrator did it) and works its assigned
container from the named Step onward.
## Per Step
- Implement exactly the Step's action in the files it names. Run the project's tests,
lint, and type checks.
- - **Blocker:** if the Step admits implementations of different scope, names a path that
- does not exist, or depends on something missing, stop and ask the user (a worker
- raises it to the orchestrator and waits). The answer goes into the row via `plan_edit`
- and is quoted back in the reply; then continue. Never resolve a blocker on your own
- judgment. Otherwise do not ask between Steps.
+ - Apply the system's blocker and approval contract. Expected new files, routine path
+ corrections, and implementation choices within approved constraints can proceed;
+ record row corrections through `plan_edit`. Raise missing prerequisites or uncovered
+ choices to the user only when existing authority cannot resolve them. Workers report
+ these to the orchestrator. Record the answer and continue.
- Log the Step:
`vaultspec-core vault exec log --feature {feature} --step S## --related <plan-stem> --row M:path`
(or the `log` tool), one `--row` per path touched, `--verify '<cmd>=pass'` when a
check ran, `--note` only on exception. The plan row states the intent and the commit
carries the diff.
- Close the Step: `plan_progress` tool or `vaultspec-core vault plan step check`. Never
edit the checkbox by hand.
- Commit once per Step, code, ledger, and plan together, adding the `Vaultspec-Step`
trailer (`vaultspec-core vault plan trailer emit --step S##`) when the repository
already uses it. Code never cites the vault.
## Delegation
- Do the Steps yourself unless the plan's Parallelization section names containers that
+ Do the Steps yourself unless the plan's Parallelization section names assignments that
may run concurrently; then dispatch executor personas (`vaultspec-low-executor`,
`vaultspec-standard-executor`, or `vaultspec-high-executor` by the Step's difficulty) at
- approved Steps, each told the plan stem, the feature tag, its container, and its
- starting Step id, and to follow this skill as a worker; they return in their persona's
- Return message format. Workers never change plan structure; that routes back to you.
+ approved Steps, each told the plan stem, the feature tag, its Steps or container, and
+ its starting Step id, and to follow this skill as a worker; they return in their
+ persona's Return message format. Workers never change plan structure; that routes back
+ to you.
- ## Phase close and finish
+ ## Review and finish
- At each point of the review cadence in the vaultspec section, run
`vaultspec-code-review`; a worker under `vaultspec-team` reports the close to its
supervisor instead, who reviews. `critical` or `high` findings reopen the affected
Steps (`vaultspec-core vault plan step uncheck`) and are fixed before continuing;
- lower findings are recorded and fixed only under a Step the user approves.
+ lower findings are recorded. In-scope corrections use approved Steps; new scope or
+ costly decisions require authorization. Review integrated behavior, not individual
+ documents. L1 has no Phase close; combine coincident plan-close and handoff reviews.
- At `L4`, report Wave and Epic completion against the external artifact named in the
plan's `## Epic intent`.
- When every Step is closed and the last review passes, report the plan complete with
the modified files and the audit's status.