@deftai/directive-content 0.107.0 → 0.108.0

package/scm/github.md

@@ -338,8 +338,38 @@ auth.
    `deft github-auth-modes --json` validates API reachability and optional
    repo access.
 
+### Ambiguous Cursor runtime and the host-gh opt-in (#3859)
+
+`CURSOR_AGENT` is set by local desktop Cursor, by Cursor-managed cloud VMs, and
+by Windows "My Machines" workers, so it cannot decide the runtime by itself.
+
+- ! Cursor-managed VMs serve a metadata API on `CURSOR_AGENT_SOCKET` whose
+  `agent/runtime` is `managed`. A positive read classifies `cloud-headless` at
+  higher precedence than any other Cursor signal **and** than the opt-in below.
+- ⊗ Treat absence of that socket as proof of local desktop. Absence means "not
+  managed, or unreachable" and MUST NOT select host credentials -- that is the
+  marker-absence grant this rule exists to prevent.
+- ! When `CURSOR_AGENT` is set and the probe does not report `managed`, the
+  runtime is **ambiguous**. Deft does not guess from `process.platform`. Host
+  credentials then require an explicit selection:
+  `DEFT_GITHUB_AUTH_MODE=host-gh`, set in the execution environment on a
+  machine you control. Dispatchers should export the same `github_auth_mode`
+  label they already record in the dispatch envelope.
+- ! Absent that selection, behaviour is unchanged: the runtime stays
+  `cloud-headless` and SCM-dependent gates are skipped. The skip names its
+  reason (`runtime_mode_reason` in `scm:status --json`, and in the `[deft scm]`
+  session-start lines) and points at this opt-in.
+- ⊗ Use an OS predicate (`process.platform === "win32"`) as a cloud
+  discriminator. Cursor's managed fleet being Ubuntu is a versioned fact about
+  a third party's infrastructure, not a runtime invariant.
+
+Reason ids: `cursor-managed-runtime-probe`, `cursor-marker-runtime-ambiguous`,
+`explicit-host-gh-selection`, `ci-marker`, `cursor-sandbox-marker`,
+`no-runtime-marker`.
+
 Contract file: `content/contracts/scm-readiness.md`. Implementation:
-`packages/core/src/scm/readiness.ts`.
+`packages/core/src/scm/readiness.ts`,
+`packages/core/src/platform/cursor-managed-runtime.ts`.
 
 ## Windows / ASCII Conventions for Machine-Editable Sections
 

package/skills/deft-directive-build/SKILL.md

@@ -107,7 +107,7 @@ The gate exits 0 only when the candidate xBRIEF lives in `xbrief/active/` AND `p
 
 A project is **pre-cutover** if ANY of the following are true. This prose mirrors the executable helper in `scripts/_precutover.py`; when in doubt, the helper is canonical.
 
-1. `SPECIFICATION.md` exists and is neither a deprecation redirect nor a current generated spec export. A current generated spec export contains `<!-- Purpose: rendered specification -->` and `<!-- Source of truth: xbrief/specification.xbrief.json -->`, and `xbrief/specification.xbrief.json` plus all five lifecycle folders exist.
+1. `SPECIFICATION.md` exists and is neither a deprecation redirect nor a current generated spec export. A current generated spec export contains `<!-- Purpose: rendered specification -->`, all five lifecycle folders exist, and its `<!-- Source of truth: ... -->` marker names an authority artifact that exists: either `xbrief/specification.xbrief.json` for full-spec compatibility or `xbrief/PROJECT-DEFINITION.xbrief.json` for greenfield authority (legacy `vbrief/...` aliases remain read-compatible).
 2. `PROJECT.md` exists and contains neither the legacy `<!-- deft:deprecated-redirect -->` sentinel NOR the current `Purpose: deprecation redirect` canonical-banner marker (real content, not a deprecation redirect)
 3. `xbrief/specification.xbrief.json` exists but the lifecycle folders (`xbrief/proposed/`, `xbrief/pending/`, `xbrief/active/`, `xbrief/completed/`, `xbrief/cancelled/`) do NOT exist
 4. Strategy output shape violations (run `task verify-strategy-output` -- the canonical gate -- or the direct form `python .deft/core/scripts/validate_strategy_output.py --project-root <path>` after `deft` install):

package/skills/deft-directive-cost/SKILL.md

@@ -24,8 +24,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## When to Use
 
-- After `skills/deft-directive-setup/SKILL.md` Phase 3 has produced an
-  approved `xbrief/specification.xbrief.json` (status `approved`)
+- After `skills/deft-directive-setup/SKILL.md` Phase 3 has produced either greenfield authority (`xbrief/PROJECT-DEFINITION.xbrief.json` plus lifecycle scopes) or an approved full-spec compatibility artifact
 - Before `skills/deft-directive-build/SKILL.md` kicks off
 - When the user says "cost", "budget", "pre-build cost", "how much will
   this cost", or asks to estimate cost before building
@@ -60,12 +59,9 @@ two skills agree on the user's preferences file.
 
 ## Inputs
 
-- ! `xbrief/specification.xbrief.json` MUST exist with `plan.status =
-  "approved"`. If the spec is not yet approved, stop and redirect to
-  `skills/deft-directive-setup/SKILL.md` Phase 3 / the spec approval
-  gate.
-- ~ `xbrief/PROJECT-DEFINITION.xbrief.json` (for tech-stack and
-  architecture narratives). Optional but improves the estimate.
+- ! Resolve the same two-path authority used by `task project:export-spec`: prefer an existing full-spec artifact, otherwise use `xbrief/PROJECT-DEFINITION.xbrief.json` plus lifecycle scopes.
+- ! For full-spec authority, require its existing approval contract. For greenfield authority, require the setup approval decision and at least one lifecycle scope; do not require `plan.status = "approved"` on PROJECT-DEFINITION.
+- ⊗ Require or create `xbrief/specification.xbrief.json` solely to estimate a greenfield project.
 - ~ `templates/COST-ESTIMATE.md` (canonical artifact body).
 - ~ `references/cost-models.md` (methodology).
 
@@ -73,8 +69,8 @@ two skills agree on the user's preferences file.
 
 ### Phase 1 -- Read the spec & detect categories
 
-- ! Read the approved spec and the project definition.
-- ! Walk the spec and identify which cost categories apply for this
+- ! Read the resolved authority: the full-spec artifact when present, otherwise PROJECT-DEFINITION plus relevant lifecycle scopes.
+- ! Walk the resolved narratives and scope requirements to identify which cost categories apply for this
   project: hosting / infrastructure, API / third-party fees, pre-flight
   account sign-ups, build & maintenance time. Drop categories that do
   not apply.
@@ -139,7 +135,7 @@ This is your project's cost estimate. Pick one.
   `skills/deft-directive-refinement/SKILL.md` to pull spec scope back,
   or the interview), then re-run this skill from Phase 1.
 - ! On `No-build`, write the decision to `COST-ESTIMATE.md`, mark the
-  spec scope xBRIEF accordingly, exit, and do NOT chain into the build
+  applicable lifecycle scope xBRIEFs accordingly, exit, and do NOT chain into the build
   skill.
 - ! On `Skip`, write the decision and skip reason to `COST-ESTIMATE.md`
   and proceed to the build kickoff.

package/skills/deft-directive-design-critique/SKILL.md

@@ -44,12 +44,19 @@ After critic post: posted successor lean, then verbs.
 Auto-stamp after operator confirm; not while same-round siblings outstanding.
 Walk / walk all. Auto-stamp when agents agree: Operator verbs.
 Parent chip write: scm:issue:design-critique-chip.
+Chip apply miss is non-blocking convenience; do not halt. Ingest waits on the completed-arc record, not a catalog chip.
 
 Each critic dispatch EXITs after posting.
 
+## Motion shape
+
+Not sequential review. Same-round critics are isolated: each reads one fixed input ceiling and cannot read other siblings' posts through the thread. More: [`references/motion-shape.md`](references/motion-shape.md).
+
+After each critic EXIT, the parent posts the successor lean; the operator confirms or amends before bind or stamp.
+
 ⊗ Auto-dispatch critics from this skill.
 ⊗ Copy the variant table, synthesis rules, or other contract bodies into this skill.
 
 ## EXIT
 
-deft-directive-design-critique complete -- exiting skill. Next: fill the brief template and dispatch.
+deft-directive-design-critique complete -- exiting skill. Next: operator fills the brief template and dispatches the next envelope.

package/skills/deft-directive-design-critique/references/motion-shape.md

@@ -0,0 +1,19 @@
+# Design critique — motion shape
+
+Orientation only. Normative rules: [`contracts/design-critique.md`](../../../contracts/design-critique.md).
+
+## Same-round critics
+
+- Parallel, not sequential. Each critic in a round reads one fixed input ceiling set before any sibling dispatch.
+- A sibling's post is out of envelope for every other sibling in that round — they cannot read each other through the issue thread.
+- Serial dispatch (critic B after critic A posts) destroys isolation even when bind guards still pass.
+
+## Who adjudicates
+
+| Step | Actor | Action |
+|------|-------|--------|
+| After critic EXIT | Parent | Post successor lean with proposed per-heading takes |
+| Before bind/stamp | Operator | Confirm or amend that lean |
+| Next envelope | Operator (or parent after operator verb) | Fill brief template and dispatch |
+
+Comment-lead chips (model then role) govern comment signing — see brief template and Stop 3.

package/skills/deft-directive-interview/SKILL.md

@@ -196,7 +196,7 @@ The answers map format:
 
 ## Output Targets
 
-Interview output writes to `specification.xbrief.json` `plan.narratives` — the xBRIEF draft is the sole authoritative output. PRD.md is never generated. All xBRIEFs target the canonical v0.6 schema (`xbrief/schemas/xbrief-core.schema.json`, strict `const: "0.6"`); see [`../../conventions/references.md`](../../conventions/references.md).
+Interview output writes to the authority selected by the calling skill. Greenfield setup writes project-level narratives to `xbrief/PROJECT-DEFINITION.xbrief.json` and implementation requirements to lifecycle scope xBRIEFs in `xbrief/proposed/`; it does not create `xbrief/specification.xbrief.json`. A caller that explicitly owns a full-spec workflow may target the compatibility specification artifact. PRD.md is never authoritative. New xBRIEFs target the current v0.8 schema; see [`../../conventions/references.md`](../../conventions/references.md).
 
 When the interview captures origin provenance (e.g. the user links to a GitHub issue or Jira ticket), include a `references` entry in the canonical form documented in [`../../conventions/references.md`](../../conventions/references.md):
 
@@ -212,7 +212,7 @@ When the interview captures origin provenance (e.g. the user links to a GitHub i
 
 ### Full Path Output
 
-! On the Full path, the interview populates `specification.xbrief.json` `plan.narratives` with `xBRIEFInfo.version: "0.6"`, `status: draft`, and rich keys:
+! On the greenfield Full path, the calling setup skill merges these rich keys into `PROJECT-DEFINITION.xbrief.json` and creates traceable proposed scope xBRIEFs:
 
 - `ProblemStatement`: What problem this project solves
 - `Goals`: High-level project goals
@@ -224,23 +224,23 @@ When the interview captures origin provenance (e.g. the user links to a GitHub i
 
 ! All narrative values MUST be plain strings — never objects or arrays.
 
-! The human approval gate reviews the xBRIEF draft narratives directly — reviewing the narratives IS the approval step. On approval, update `status` to `approved` and generate downstream scope xBRIEFs.
+! The human approval gate reviews the PROJECT-DEFINITION narratives and proposed scope plan directly. On approval, the calling setup skill records the decision and generates downstream scope xBRIEFs without manufacturing a specification artifact.
 
 ### Light Path Output
 
-! On the Light path, the interview populates `specification.xbrief.json` with `status: draft` and slim narratives:
+! On the greenfield Light path, the calling setup skill merges these slim narratives into `PROJECT-DEFINITION.xbrief.json`:
 
 - `Overview`: Brief project summary
 - `Architecture`: System design description
 
-! On approval, update `status` to `approved`. Scope xBRIEFs are then created in `xbrief/proposed/` for each identified work item.
+! On approval, the calling setup skill creates scope xBRIEFs in `xbrief/proposed/` for each identified work item; it does not create `specification.xbrief.json`.
 
 ### PRD.md (deprecated — never authoritative)
 
-PRD.md is not generated as part of the interview workflow on either path. The `specification.xbrief.json` xBRIEF draft is the sole source of truth.
+PRD.md is not generated as part of the interview workflow on either path. It is a read-only export from the resolved authority.
 
-- ? If stakeholders require a traditional PRD document, run `task prd:render` to export a read-only `PRD.md` from `plan.narratives`
-- ! PRD.md is never authoritative — `specification.xbrief.json` is the source of truth
+- ? If stakeholders require a traditional PRD document, run `task prd:render` to export a read-only `PRD.md` from the resolved project narratives
+- ! PRD.md is never authoritative — greenfield authority is PROJECT-DEFINITION plus lifecycle scopes; full-spec compatibility authority remains supported when present
 - ⊗ Generate an authoritative PRD.md during the interview process
 - ⊗ Treat PRD.md as a source of truth — it is a generated export artifact
 
@@ -375,7 +375,7 @@ Tatooine), branded characters (Mickey Mouse, Spider-Man), sports leagues
 2. ! Emit the plain-English risk summary from
    `scripts/ip_risk.py:plain_risk_summary(hits, intent)` into the
    interview output AND into an `IPRisk` narrative on the
-   `specification.xbrief.json` draft. The summary opens with `not legal
+   authoritative interview output selected by the calling skill. The summary opens with `not legal
    advice`, names the detected categories, and (for commercial intent)
    states explicitly that lawyer consultation is **not optional output**
    from this interview.
@@ -513,7 +513,7 @@ for it.
 - ⊗ Skip the depth gate and generate artifacts with known ambiguity remaining
 - ⊗ Exit the interview without producing a structured answers map for the calling skill
 - ⊗ Combine interview questions with artifact generation in the same message
-- ⊗ Generate an authoritative PRD.md — interview output targets `specification.xbrief.json` narratives only
+- ⊗ Generate an authoritative PRD.md — interview output targets the calling skill's resolved xBRIEF authority
 - ⊗ Treat PRD.md as a source of truth — it is a read-only export via `task prd:render`
 - ⊗ Auto-advance to the next question on number press without echoing the selection and waiting for confirmation
 - ⊗ Refuse backward navigation during the interview -- the user must be able to revisit previous answers

package/skills/deft-directive-release/SKILL.md

@@ -321,12 +321,13 @@ Race-condition mitigation: `download_count` is double-read with a 5s sleep betwe
 
 ! Only enter Phase 7 if Phase 6 took the Publish branch (rollback branch ends here with the unwind log).
 
-1. ! **Re-verify npm publish landed (#1910, #1909, #2002).** Phase 5 checked workflow status before the GitHub publish flip; Phase 7 confirms registry truth AFTER `task release:publish`. For each of `@deftai/directive-types`, `@deftai/directive-core`, `@deftai/directive-content`, and `@deftai/directive`, run `npm view <pkg>@<version> version` (expect `<version>`) and confirm provenance on the npm page. A green GitHub release with missing npm packages means consumers cannot `npm i -g @deftai/directive@<version>` -- escalate immediately. (Real-registry verification depends on #1909's credential; until then verify workflow-run status and flag credential gaps.)
-2. ! Verify GitHub auto-closed the discrete-task issue(s) referenced via `Closes #N` in the release notes (mirrors `skills/deft-directive-swarm/SKILL.md` Phase 6 Step 2)
-3. ! Run `gh issue view <N> --json state --jq .state` for each closed issue. If any didn't auto-close, manually close with `gh issue close <N> --comment "Closed by release v<version> (squash auto-close did not trigger)"` (Layer 1, #167)
-4. ! Verify ROADMAP.md correctness via `task roadmap:render` (the release pipeline already invoked this; Phase 7 is the second-pass sanity check)
-5. ! Verify binaries are downloadable from the public release URL: `gh release view v<version> --json assets --jq '.assets[].url'` and curl one to confirm 200 OK
-6. ! For any umbrella / staying-OPEN issue (`Refs #N`) referenced in the release notes, run the Layer 3 reopen sweep from `skills/deft-directive-swarm/SKILL.md` Phase 6 Step 1: any protected issue that auto-closed MUST be reopened with a comment citing #701
+1. ! **Re-verify npm publish landed (#1910, #1909, #2002).** Phase 5 checked workflow status before the GitHub publish flip; Phase 7 confirms registry truth AFTER `task release:publish`. For each of `@deftai/directive-types`, `@deftai/directive-core`, `@deftai/directive-content`, and `@deftai/directive`, run `npm view <pkg>@<version> version --prefer-online` (expect `<version>`) and confirm provenance on the npm page. A green GitHub release with missing npm packages means consumers cannot `npm i -g @deftai/directive@<version>` -- escalate immediately. (Real-registry verification depends on #1909's credential; until then verify workflow-run status and flag credential gaps.) Reading one package is not sufficient — sibling publish is not atomic.
+2. ! **Report local-vs-released CLI drift (#3753).** After the all-four registry check, print the local global CLI version, the released version, whether they match, and the exact remediation `npm i -g @deftai/directive@<version> --prefer-online`. Compare versions with `checkActiveCliAgainstTarget` (not bare `deft --version`) so a PATH-shadowed install cannot report success (#3233). If some siblings are visible and others are not, report **still propagating**. If none are visible after this wait, report **publish incomplete**. `task release` already emitted a non-blocking snapshot of the same report at pipeline completion (single probe, no wait — Step 13 returns before `npm-publish.yml` is green). Phase 7 is the bounded wait. ⊗ Run `npm i -g`. The report must not fail the release.
+3. ! Verify GitHub auto-closed the discrete-task issue(s) referenced via `Closes #N` in the release notes (mirrors `skills/deft-directive-swarm/SKILL.md` Phase 6 Step 2)
+4. ! Run `gh issue view <N> --json state --jq .state` for each closed issue. If any didn't auto-close, manually close with `gh issue close <N> --comment "Closed by release v<version> (squash auto-close did not trigger)"` (Layer 1, #167)
+5. ! Verify ROADMAP.md correctness via `task roadmap:render` (the release pipeline already invoked this; Phase 7 is the second-pass sanity check)
+6. ! Verify binaries are downloadable from the public release URL: `gh release view v<version> --json assets --jq '.assets[].url'` and curl one to confirm 200 OK
+7. ! For any umbrella / staying-OPEN issue (`Refs #N`) referenced in the release notes, run the Layer 3 reopen sweep from `skills/deft-directive-swarm/SKILL.md` Phase 6 Step 1: any protected issue that auto-closed MUST be reopened with a comment citing #701
 
 ⊗ Skip the post-publish verification. The closing-keyword false-positive (Layer 1 / Layer 2 / Layer 3) and the incremental-renderer-drift (#641, #614) are exactly the kind of issues that surface only AFTER a release is public.
 
@@ -384,6 +385,9 @@ Where `<one-line guidance>` is one of:
 - ⊗ Run `task release:rollback` against a release that has > 30 minutes of consumer-driven downloads without first weighing the hot-fix path -- a withdrawal note in the next patch is almost always less disruptive than deleting a public artifact
 - ⊗ Use `--allow-data-loss` without first reading the script docstring's hot-fix-path recommendation -- the flag is an explicit acknowledgment of consumer impact, not a default
 - ⊗ Skip the Phase 7 Layer 3 reopen sweep -- protected umbrellas can auto-close on a release-merge squash even when the release notes use `Refs #N` only
+- ⊗ Run `npm i -g` from the release pipeline or Phase 7 (#3753) -- report local-vs-released drift only; no global mutation
+- ⊗ Trust bare `deft --version` after a cut -- use `checkActiveCliAgainstTarget` so a PATH-shadowed install cannot report success (#3233 / #3753)
+- ⊗ Treat a missing sibling package as a failed publish without distinguishing still-propagating from publish-incomplete (#3753)
 - ⊗ Post the Phase 8 Slack announcement directly from this skill -- the user owns the broadcast; the skill only generates the template
 - ⊗ Hardcode `master` as the base branch -- delegate to the configured base branch from `task release --base-branch <branch>`
 - ⊗ Skip the post-create verify-isDraft gate (#724) -- a successful `gh release create` exit code does NOT prove the release actually landed in draft state; the 5-second poll-and-flip gate in `scripts/release.py` Step 11 is the only safety net against operator-error variants and partial-success races, and any manual recovery path that bypasses `scripts/release.py` MUST run `gh release view --json isDraft` followed by `gh release edit --draft=true` on `isDraft=false` before handing off to Phase 5

package/skills/deft-directive-review-cycle/SKILL.md

@@ -624,6 +624,39 @@ Cross-links: swarm decision tree `skills/deft-directive-swarm/references/core-ph
 6. ! On register conflict when the prior owner is **still alive**: attach to the existing owner or stop — do not parallel-fix.
 7. ⊗ Refuse replacement of a dead owner solely because the 30-minute lease has not expired without attempting force takeover (#3044).
 
+### Advisory pass-open mark on issue threads (#3607)
+
+! **Advisory, not a lock.** On an **issue** thread the same `<!-- deft:review-owner -->` marker carries `kind: pass` to say a structured pass (triage, design-critique, review-response) is open: pass kind, owner, declared ceiling, and `expires_at`. An arriving agent **reads and is informed**; nothing is held and no write is blocked. A pass has N+1 writers by construction (parent plus panel), so an exclusive hold names no actual actor — blocking was refuted 3/3 by the #3607 panel.
+
+! **Read before writing into an open pass.** Fetch the mark (`fetchActivePassMarker`, or `gh api repos/<owner>/<repo>/issues/<N>/comments` filtered on the marker). When a mark is open, prefer flagging your comment as post-ceiling, or hold voluntarily — your call, not a gate.
+
+! **The lifecycle runs on the issue thread itself — there is no separate verb.** Open the mark by posting a comment whose body is the marker block; clear it at synthesis by editing that same comment to carry `ended_at`. Engine callers use `openPassMarker` / `closePassMarker` / `fetchActivePassMarker` (`packages/core/src/review-monitor/github-lease.ts`); an agent without those bindings posts the identical block through the safe-body verbs, exactly as the #2878 gh-only lease fallback does.
+
+```text
+<!-- deft:review-owner -->
+kind: pass
+pass_kind: design-critique
+owner: <github-login>
+agent_id: <pass owner agent id>
+ceiling: <declared ceiling comment id>
+started_at: 2026-08-28T19:48:24Z
+expires_at: 2026-08-28T20:48:24Z
+<!-- /deft:review-owner -->
+```
+
+1. ! **Open** at pass start with a **new** comment, and keep the comment id it returns: `task scm:body:comment:create -- --repo <owner>/<repo> --issue <N> --body-file <file>`.
+2. ! **Read** on arrival: `gh api repos/<owner>/<repo>/issues/<N>/comments`, then take the **oldest unexpired** `kind: pass` block. A mark already open means you were informed, not stopped.
+3. ! **Refresh or clear** only the comment id your own open returned: `task scm:body:comment:edit -- --repo <owner>/<repo> --comment <id> --body-file <file>`, adding `ended_at: <now>` at synthesis.
+
+⊗ Edit a marker comment you did not open, including one carrying your own login from another pass — a comment belongs to the pass that created it. Editing another author's comment is also a 403 for a non-maintainer. Open your own and let oldest-comment-id-wins settle which mark arrivals honour.
+
+! **Expiry is the release.** A mark self-clears on read once `expires_at` passes, and the owner clears it at synthesis (`ended_at`), so an abandoned pass never marks a thread forever and no heartbeat is needed. Concurrent marks resolve **oldest comment id wins**, matching the lease; the later mark is removed and its author is told which mark stands.
+
+! **Trust boundary.** Pass marks are read from **any** author association, including `CONTRIBUTOR`, because they inform rather than gate. Ownership leases stay maintainer-authored (`OWNER` / `MEMBER` / `COLLABORATOR`, #2307) because `verify:review-monitor` / `verify:l4-owner` exit 0 on a live lease.
+
+⊗ Treat a pass mark as permission to hold, block, or gate another actor's write.
+⊗ Read a `kind: pass` mark as a review-owner lease — a pass mark never satisfies `verify:review-monitor` / `verify:l4-owner`.
+
 ### Required non-empty monitor handback (#3044)
 
 ! Approach 1 review-monitor prompts (including `templates/swarm-greptile-poller-prompt.md` and any host-filled spawn prompt) MUST require a **non-empty** final handback with these fields:

package/skills/deft-directive-setup/SKILL.md

@@ -127,6 +127,8 @@ When guiding an operator through migration on the pinned release, mention the mi
 - ! If `$DEFT_USER_PATH` is set, it takes precedence on any platform
 - ! Create parent directories as needed when writing USER.md
 - ~ `$DEFT_PROJECT_PATH` overrides the default project config path (`./xbrief/PROJECT-DEFINITION.xbrief.json`) if set
+- ! Resolve `<policy-project-root>` to the user's working directory at skill entry. When `$DEFT_PROJECT_PATH` is set, resolve it relative to that root and preserve the environment variable for every Phase 2 command; the public policy writer, inspector, lock, and conformance gate honor the configured file even when it is outside the canonical `xbrief/` path.
+- ! Pass `--project-root <policy-project-root>` to every Phase 2 policy inspector, writer, and conformance command. Do not unset or rewrite `$DEFT_PROJECT_PATH`, and do not let those commands fall back to a different working directory.
 
 ## Agent Behavior
 
@@ -418,6 +420,15 @@ for project-scoped settings (strategy, coverage).
 - ~ Skip if `./xbrief/PROJECT-DEFINITION.xbrief.json` exists (or `$DEFT_PROJECT_PATH` if set) and user doesn't want to replace
 - ⊗ Count `./deft/PROJECT-DEFINITION.xbrief.json` or `./deft/core/project.md` as the user's project config — those are framework-internal
 
+### Re-entry shadow guard (#3609)
+
+! Before any Phase 2 confirmation or file mutation when PROJECT-DEFINITION already exists, run `deft policy:show --field=plan.policy.allowDirectCommitsToMaster --project-root <policy-project-root>` and inspect **stderr as well as the exit code**. The inspector intentionally exits 0 when it can still read the namespaced value, so a warning that bare `plan.policy` coexists with `plan["x-directive/policy"]` is a hard stop even when the command succeeds.
+
+! On that warning, do not regenerate, overwrite, or run a policy writer. Inventory the keys in both blocks; fold every bare-only key into `plan["x-directive/policy"]`; resolve every collision explicitly; delete bare `plan.policy`; then rerun the inspector. Preserve all unrelated PROJECT-DEFINITION content. Resume only when exactly one policy block remains.
+
+⊗ Treat matching `allowDirectCommitsToMaster` values as safe while other keys may still be stranded in the shadowed block
+⊗ Copy arbitrary policy values into a diagnostic or silently choose one side of a collision
+
 ### Inference
 
 - ! Before asking, infer from codebase — look for `package.json`, `go.mod`, `requirements.txt`, `Cargo.toml`, `pyproject.toml`, `*.csproj`
@@ -491,21 +502,21 @@ apply here too. Do not combine questions. See `skills/deft-directive-interview/S
   ! **Capability-cost disclosure (#746):** When the user picks option 2 (trunk-based), the agent MUST present the capability-cost disclosure verbatim BEFORE writing the typed flag, then re-prompt for explicit confirmation:
 
   > "Capability-cost disclosure -- enabling direct commits to the default branch turns OFF the deft branch-protection policy. The pre-commit + pre-push hooks will no longer block default-branch commits, `task verify:branch` will pass on the default branch, and the skill-level guards in deft-directive-{swarm,review-cycle,pre-pr,release} will not halt for default-branch work. The change is reversible (`task policy:enforce-branches`) and is recorded to meta/policy-changes.log for auditability. The CI sanity check (head_ref != base_ref) remains independent and will continue to flag master->master PRs. Are you sure?"
-  > 1. Yes, opt out -- write `plan.policy.allowDirectCommitsToMaster = true`
-  > 2. No, keep branch-protection enforced -- write `plan.policy.allowDirectCommitsToMaster = false`
+  > 1. Yes, opt out -- persist `allowDirectCommitsToMaster=true` through the policy writer
+  > 2. No, keep branch-protection enforced -- persist `allowDirectCommitsToMaster=false` through the policy writer
   > 3. Discuss
   > 4. Back
 
   ! Default to option 2 (enforce). Explicit affirmative on option 1 is required to opt out -- a broad `proceed` does NOT satisfy this gate. The same affirmative-only rule applies as in `/deft:change` (`yes`, `confirmed`, `approve`).
 
-  ! Write the answer to `plan.policy.allowDirectCommitsToMaster` (typed boolean) on the PROJECT-DEFINITION xBRIEF. Default `false` (enforce branches) when the user picks option 2 OR omits the question entirely. Writing this typed surface is what the framework reads going forward; agents MUST NOT write the legacy free-form `Allow direct commits to master:` narrative key (#746 part A migrates the legacy narrative away).
+  ! Record the answer as the logical field `plan.policy.allowDirectCommitsToMaster`, but do not hand-write either policy block. The common Output Path gate below invokes the only writer and stores the boolean under `plan["x-directive/policy"].allowDirectCommitsToMaster`. Default `false` (enforce branches) when the user picks option 2 OR omits the question entirely. Agents MUST NOT write bare `plan.policy` or the legacy free-form `Allow direct commits to master:` narrative key.
 
-  ! **Re-running the interview detects the existing flag (#746 part G2):** If `xbrief/PROJECT-DEFINITION.xbrief.json` already exists and has `plan.policy.allowDirectCommitsToMaster` set, the interview MUST surface the current value (e.g. "Current setting: `allowDirectCommitsToMaster=false` (branch-protection ON)") and ask whether to keep it or change it before re-prompting. Do not silently overwrite an existing typed value.
+  ! **Re-running the interview detects the existing flag (#746 part G2):** After the Re-entry shadow guard passes, surface the resolved current value (e.g. "Current setting: `allowDirectCommitsToMaster=false` (branch-protection ON)") and ask whether to keep it or change it before re-prompting. A keep choice still runs the selected writer so legacy-only storage is migrated; an already-namespaced match is a no-op with no audit append. On Track 2 or 3, preserve an existing resolved boolean by default without asking a new branching question. Never replace an existing `true` with the greenfield `false` default unless the operator explicitly chooses the Track 1 change flow.
 
-  ! **Slash-command alternatives (#746 part G2):** Once the project is set up, the typed flag can also be flipped via slash commands wrapping `task policy:*`:
-  - `/deft:policy:show` -- display the current resolved policy and source
-  - `/deft:policy:enforce-branches` -- set `allowDirectCommitsToMaster=false`
-  - `/deft:policy:allow-direct-commits` -- set `allowDirectCommitsToMaster=true` (requires `--confirm` to apply)
+  ! **Consumer command alternatives (#746 part G2):** Once the project is set up, use the public CLI directly:
+  - `deft policy:show --field=plan.policy.allowDirectCommitsToMaster --project-root <policy-project-root>` -- display the current resolved policy and source
+  - `deft policy:enforce-branches --actor agent:deft-directive-setup --project-root <policy-project-root>` -- set `allowDirectCommitsToMaster=false`
+  - `deft policy:allow-direct-commits --confirm --actor agent:deft-directive-setup --project-root <policy-project-root>` -- set `allowDirectCommitsToMaster=true`
 
   Each transition is recorded to `meta/policy-changes.log` for auditability.
 
@@ -515,14 +526,30 @@ apply here too. Do not combine questions. See `skills/deft-directive-interview/S
 - Step 3: Ask languages (show detected, confirm or adjust; if none detected, infer from type and ask)
 - Step 4: Ask strategy (default to USER.md Defaults; ask if this project needs different — show Available Strategies numbered list with descriptions and recommended marker)
 - Default coverage to USER.md Defaults without asking
+- ! Do not ask a branching question. For greenfield or absent policy, the common Output Path gate persists `allowDirectCommitsToMaster=false`. On re-entry it preserves the resolved existing boolean, including `true`; change it only through the Track 1 disclosure gate.
 
 **Track 3 (non-technical) — 1 step:**
 - Step 1: Present summary of inferences: "Based on your project: {name} ({type}), built with {stack}. Look right?"
 - ⊗ Ask about strategy or coverage — use Phase 1 defaults
+- ! Do not ask a branching question. For greenfield or absent policy, the common Output Path gate persists `allowDirectCommitsToMaster=false`. On re-entry it preserves the resolved existing boolean, including `true`; change it only through the Track 1 disclosure gate.
 
 ### Output Path
 
-`./xbrief/PROJECT-DEFINITION.xbrief.json` (or `$DEFT_PROJECT_PATH` if set). Create `./xbrief/` directory and lifecycle subfolders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`) if they don't exist.
+`./xbrief/PROJECT-DEFINITION.xbrief.json` (or the resolved `$DEFT_PROJECT_PATH` if set). Create `<policy-project-root>/xbrief/` and its lifecycle subfolders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`) if they don't exist. A configured PROJECT-DEFINITION may live elsewhere; the lifecycle root remains under `<policy-project-root>`.
+
+### Branch-policy persistence gate (#3609)
+
+! This gate applies to **every track**, including default/greenfield and keep/re-entry paths. For greenfield setup, first write the confirmed PROJECT-DEFINITION base without any hand-authored policy block. On re-entry, merge base changes while preserving the existing policy block byte-for-byte: keep a legacy-only bare `plan.policy` intact until the shared writer migrates the whole block, and keep a namespaced block intact until that writer updates it. Never delete or reconstruct a legacy-only block before the writer because it may contain unrelated keys such as `wipCap`. Then invoke exactly one public writer:
+
+- Branch-based/greenfield-default/keep-false: `deft policy:enforce-branches --actor agent:deft-directive-setup --project-root <policy-project-root>`
+- Explicitly confirmed trunk-based/keep-true/Track 2 or 3 existing-true: `deft policy:allow-direct-commits --confirm --actor agent:deft-directive-setup --project-root <policy-project-root>`
+
+! A nonzero writer exit halts Phase 2 immediately. Do not print a completion claim and do not retry by hand-editing JSON. Resolve the reported configuration problem, rerun the Re-entry shadow guard, and invoke the writer again.
+
+! Before Phase 2 can complete, re-read PROJECT-DEFINITION and verify all three postconditions: `plan["x-directive/policy"].allowDirectCommitsToMaster` is the selected boolean; bare `plan.policy` is absent; and `deft verify:vbrief-conformance --project-root <policy-project-root>` exits 0. Also run `deft policy:show --field=plan.policy.allowDirectCommitsToMaster --project-root <policy-project-root>` and confirm its resolved value matches the selection. Any mismatch is a hard stop.
+
+⊗ Finish Phase 2 after writing only the narrative template
+⊗ Add a setup-specific policy writer or weaken conformance to permit bare `plan.policy`
 
 ### GitHub PR Template Scaffolding (#531)
 
@@ -579,7 +606,7 @@ omit = [
       "Strategy": "Use {strategy name} for this project",
       "Quality": "Run task check before every commit. Achieve >= {coverage}% coverage overall + per-module. Store secrets in secrets/ dir.",
       "ProjectRules": "{Any rules the user specified, or 'No project-specific rules defined.'}",
-      "Branching": "{If trunk-based: 'Allow direct commits to master: true', else omit or 'Branch-based workflow (default)'}",
+      "Branching": "{If confirmed trunk-based: 'Trunk-based workflow', otherwise 'Branch-based workflow (default)'}",
       "DeftVersion": "0.20.0"
     },
     "items": []
@@ -614,7 +641,7 @@ omit = [
 ! **Path Resolution Anchor**: Same rule as Phase 2 -- resolve ALL paths relative to the user's pwd at skill entry, never relative to the skill file, AGENTS.md, or any framework directory.
 
 - ~ Skip if user already has scope xBRIEFs in `./xbrief/` they're happy with
-- ! Check `./xbrief/specification.xbrief.json` or `./xbrief/proposed/` for existing scope xBRIEFs
+- ! Check `./xbrief/PROJECT-DEFINITION.xbrief.json` and `./xbrief/proposed/` for existing greenfield authority; treat `./xbrief/specification.xbrief.json` as a full-spec compatibility artifact only
 - ⊗ Count ANY file inside `./deft/` as the project's spec — those are framework-internal
   (e.g. `deft/PROJECT.md`, `deft/specs/`, `deft/templates/`, `deft/core/project.md`
   are all part of the framework, NOT the user's project)
@@ -682,8 +709,10 @@ project complexity per [strategies/interview.md](../../strategies/interview.md#s
 - ⊗ Combine the sizing proposal with the first interview question
 - ⊗ Proceed to interview questions before the user has confirmed the path
 
-**Light** (small/medium): Interview → `specification.xbrief.json` with slim narratives (Overview + Architecture) → scope xBRIEFs in `xbrief/proposed/`.
-**Full** (large/complex): Interview → rich narratives in `specification.xbrief.json` (user approval) → scope xBRIEFs with traceability.
+**Light** (small/medium): Interview → slim narratives (Overview + Architecture) in `PROJECT-DEFINITION.xbrief.json` → scope xBRIEFs in `xbrief/proposed/`.
+**Full** (large/complex): Interview → rich PROJECT-DEFINITION narratives for user approval → scope xBRIEFs with traceability.
+
+! Neither greenfield path creates `xbrief/specification.xbrief.json`; that file remains a full-spec compatibility artifact.
 
 ### Interview Process (interview strategy)
 
@@ -715,7 +744,7 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 
 ### Output — Light Path
 
-1. ! Write `./xbrief/specification.xbrief.json` with `"xBRIEFInfo": { "version": "0.8" }`, `status: draft`, and slim narratives:
+1. ! Merge the confirmed slim narratives into `./xbrief/PROJECT-DEFINITION.xbrief.json`:
    - `Overview`: Brief project summary
    - `Architecture`: System design description
 2. ! Create scope xBRIEFs in `./xbrief/proposed/` for each identified work item
@@ -733,8 +762,8 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
        }
      ]
      ```
-3. ! Summarize decisions, ask user to review the xBRIEF narratives
-4. ! On approval, update `specification.xbrief.json` status to `approved`
+3. ! Summarize decisions and ask the user to approve the PROJECT-DEFINITION narratives and proposed scope set
+4. ! Record approval in the setup session; do not manufacture or require `specification.xbrief.json`
 - ⊗ Create a separate PRD.md on the Light path
 - ⊗ Generate an authoritative PRD.md — if needed, users run `task prd:render`
 
@@ -747,7 +776,7 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 
 ### Output — Full Path
 
-1. ! Write rich narratives to `./xbrief/specification.xbrief.json` with `"xBRIEFInfo": { "version": "0.8" }`, `plan.status: draft`, and these narrative keys:
+1. ! Merge these rich narratives into `./xbrief/PROJECT-DEFINITION.xbrief.json` for review:
    - `ProblemStatement`: What problem this project solves
    - `Goals`: High-level project goals
    - `UserStories`: User stories in standard format
@@ -755,8 +784,8 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
    - `SuccessMetrics`: Measurable success criteria
    - `Architecture`: System design and technical architecture
    - `Overview`: Brief project summary
-2. ! **Human approval gate**: Present the xBRIEF draft narratives to the user for review — reviewing the `specification.xbrief.json` narratives IS the approval step (replaces the former PRD.md review). The user may request changes before approving.
-3. ! On approval, update `status` to `approved` and proceed to downstream generation
+2. ! **Human approval gate**: Present the PROJECT-DEFINITION narratives and proposed scope plan to the user for review. The user may request changes before approving.
+3. ! Record approval in the setup session and proceed to downstream generation; do not manufacture or require `specification.xbrief.json`
 4. ! Create scope xBRIEFs in `./xbrief/proposed/` with traceability to requirement IDs from the narratives
 - ! Scope xBRIEFs MUST trace tasks back to requirement IDs (FR-1, NFR-1) from the `Requirements` narrative
 - ⊗ Generate an authoritative PRD.md — if needed, users run `task prd:render`
@@ -813,8 +842,9 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 
 ### Handoff to deft-directive-build
 
-- ! Emit a structured-tool question asking whether to continue to the build phase only when the host preserves numeric labels; otherwise emit the deterministic numbered menu in chat. Options: `1. Yes (continue)`, `2. Not now (exit setup)`, `3. Discuss`, `4. Back (revisit previous phase)`. The numeric labels MUST remain visible and be returned as numeric selections or exact displayed option text.
-- ~ If platform supports skill invocation and the user picks Yes, invoke `skills/deft-directive-build/SKILL.md`
+- ! Emit a structured-tool question asking whether to continue toward the build phase only when the host preserves numeric labels; otherwise emit the deterministic numbered menu in chat. Options: `1. Yes (run cost phase)`, `2. Not now (exit setup)`, `3. Discuss`, `4. Back (revisit previous phase)`. The numeric labels MUST remain visible and be returned as numeric selections or exact displayed option text.
+- ! If the user picks Yes, invoke `skills/deft-directive-cost/SKILL.md`; only a recorded Build or Skip decision from that skill may hand off to `skills/deft-directive-build/SKILL.md`
+- ⊗ Invoke the build skill directly from setup and bypass the required cost decision
 - ⊗ Leave user with a dead end -- always offer the next step via the structured-tool phase-transition question
 - ⊗ Ask the handoff-to-build question as unnumbered conversational prose or through a structured UI that hides the canonical numeric labels -- it is a deterministic menu and MUST preserve visible numbers (#478, #1563).
 
@@ -832,7 +862,8 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 4. ! If the user says `no`: re-display the values and ask which ones to correct, then re-confirm before writing
 5. ! If any value appears to be auto-generated filler (e.g. repeated default text, placeholder strings, or values that echo the question prompt), warn the user explicitly: "Some values look like they may have been auto-filled rather than provided by you. Please review carefully."
 
-⊗ Write USER.md, PROJECT-DEFINITION.xbrief.json, specification.xbrief.json, or any other deft-directive-setup artifact without first displaying captured values and receiving explicit user confirmation.
+⊗ Write USER.md, PROJECT-DEFINITION.xbrief.json, lifecycle scope xBRIEFs, or any other deft-directive-setup artifact without first displaying captured values and receiving explicit user confirmation.
+⊗ Create `specification.xbrief.json` on a greenfield Light or Full path solely to satisfy export, cost, or build handoff.
 ⊗ Treat a broad "proceed" or "continue" as confirmation to write files -- the user must explicitly confirm the displayed values.
 
 ? **Yolo strategy carve-out**: When the user's chosen strategy is `yolo` (auto-pilot), the confirmation gate still applies but the agent (Johnbot) may self-confirm on the user's behalf by displaying the summary and immediately proceeding -- the user has already opted into auto-pilot by selecting yolo. The summary must still be displayed so the user can interrupt if values look wrong.

package/skills/deft-directive-swarm/references/core-ops.md

@@ -61,6 +61,8 @@ Task B (xBRIEF: [filename], issue #[N]): [one-paragraph description with specifi
 STEP 3 — Validate: Use iteration fast lane during commits (affected/static gates). Run full task check once before push/PR (#1704). Fix any failures.
 
 STEP 4 — Commit: Add CHANGELOG.md entries under [Unreleased].
+Commit early: as soon as a coherent unit exists (source + tests that compile), then at checkpoints.
+A host-kill must not leave the only copy unversioned (#3730).
 Commit with message: [type]([scope]): [description] — with bullet-point body.
 
 STEP 5 — Push and PR: Push branch to origin. Create PR targeting <configured-base-branch> using gh CLI.
@@ -77,6 +79,8 @@ CONSTRAINTS:
 - Iteration commits: affected/static fast lane only; full task check required before push (#1704)
 - Never force-push
 - Dual stop (#2442): multi-iteration fix/repair loops need success + failure/budget stop (build defaults: max 5 quality-fix iters or 3 identical no-progress; pre-PR: max 3 polish passes). On halt: operator-visible report (tried / missing / human decision). Single-turn work is exempt. Delivery/acceptance mechanical ledger is #3143 (`packages/core/src/delivery-attempt/` / `docs/delivery-attempt.md`).
+- Heartbeat (#1365 / #3730): write `.deft-scratch/subagent-status/<agent-id>.json` immediately on start (`phase: starting`) and every 2-3 minutes. See `docs/subagent-heartbeat.md`.
+- Commit early (#3730): first coherent unit, then checkpoints. Do not hold a complete correct diff uncommitted until PR time.
 ```
 
 ### Template Rules

package/skills/deft-directive-swarm/references/core-phase-1-2.md

@@ -37,7 +37,7 @@
 #### Mode A -- Pre-created worktree map (C3, headless via `--worktree-map`)
 
 - ! When `task swarm:launch -- ... --worktree-map <path>` supplied a **pre-created worktree map** (**C3**), Phase 2 CONSUMES it instead of running `git worktree add` per agent. The C3 map is a JSON array of `{ "story_id": str, "worktree_path": str, "base_branch": str }`.
-- ! The launch engine resolves the worktree map via `resolveWorktreeMap` (`packages/core/src/swarm/worktrees.ts`), which validates normalized C3 records and RAISES on same-path collisions or base-branch mismatches. The monitor MUST surface any such raise verbatim and HALT setup -- a same-path collision means two agents would share one worktree (the Duplicate-Agent Failure Mode in Phase 4).
+- ! The launch engine resolves the worktree map via `resolveWorktreeMap` (`packages/core/src/swarm/worktrees.ts`), which validates normalized C3 records and RAISES on same-path collisions, base-branch mismatches, or a registered path whose HEAD OID differs from the requested base OID. The HEAD check is a snapshot at resolution time -- `swarm:launch` emits a manifest and stops, so HEAD can still move before spawn. The monitor MUST surface any such raise verbatim and HALT setup -- a same-path collision means two agents would share one worktree (the Duplicate-Agent Failure Mode in Phase 4).
 - ! Each resolved record's `worktree_path` and `base_branch` feed straight into Phase 3 dispatch and MUST match the **C2** launch-manifest's `worktree_path` / `branch` fields for the same `story_id`.
 
 #### Mode B -- Monitor-created worktrees (interactive path)

package/skills/deft-directive-swarm/references/core-phase-3.md

@@ -100,7 +100,9 @@ Cross-references: `packages/core/src/platform/platform-capabilities.ts` (#1557a)
 
 ! **Supported backend examples (none mandatory):** Composer-class coding agents, Grok Build `spawn_subagent` workers, Cursor/cloud agents, and future adapters are all first-class examples. No single backend is required — Grok Build is one implementation of provider-neutral routing, not the only target.
 
-! **Implement-leaf pre-dispatch (#3228):** Before the actual spawn primitive for an implement leaf (and before any re-dispatch), run `task swarm:pre-dispatch -- --scope-id <id> --target-id <worktree-or-branch>` — exit **0** only means spawn is allowed; exit **1** is `DENY_DUPLICATE_ACTIVE` (do not spawn). Depth + takeover: [`core-phase-4.md`](core-phase-4.md) Pre-dispatch deny gate; library #3143.
+! **Implement-leaf pre-dispatch (#3228 / #3730):** Before the actual spawn primitive for an implement leaf (and before any re-dispatch), run `task swarm:pre-dispatch -- --scope-id <id> --target-id <worktree-or-branch>` — exit **0** only means spawn is allowed; exit **1** is `DENY_DUPLICATE_ACTIVE` (do not spawn). Begin on a filesystem worktree target also mkdirs `.deft-scratch/subagent-status/` so `verify:subagent-alive --require-agent` can return REDISPATCH_OK instead of exit 2. Depth + takeover: [`core-phase-4.md`](core-phase-4.md) Pre-dispatch deny gate; library #3143.
+
+! **Arm the heartbeat path at dispatch (#3730):** Create the worker worktree's `.deft-scratch/subagent-status/` before spawn (mechanical on `swarm:launch` worktree-map and `swarm:pre-dispatch` begin). Instruct the worker to heartbeat per `templates/agent-prompt-preamble.md` § 10.5 and to commit early. Monitors MUST pass `--require-agent <agent-id>` on `task verify:subagent-alive`. ⊗ Put liveness on the C2 launch manifest or in `occupancy.json`.
 
 ! **Operator model routing (#1739):** the concrete per-role model lives in the gitignored, per-machine `.deft/routing.local.json`, keyed by `(dispatch_provider, worker_role)`. Record a decision with `task swarm:routing-set -- --role <role> (--model <slug> | --harness-default)`. `task swarm:launch` resolves the active provider's route and stamps `resolved_model` + `model_source` into each C2 manifest record. When `resolved_model` is non-null, the monitor MUST pass it as the **model argument of the actual dispatch primitive** (e.g. the Task tool's `model` field for a Cursor sub-agent) — stamping the manifest is prep; a recorded model that never reaches the spawn call is the bug #1739 closes. Run `task verify:routing` before dispatching a cohort (pre-dispatch hard gate; fails when a dispatched role is undecided) and `task verify:routing -- --advise` at session start (non-blocking disclosure). For harness-bound providers (e.g. `grok`) only `--harness-default` is recordable and `resolved_model` stays null.
 

package/skills/deft-directive-swarm/references/core-phase-4.md

@@ -11,16 +11,17 @@
 
 ! On the Grok Build hybrid path (`spawn_subagent` dispatch, no native lifecycle channel back to the monitor), worktree git state alone is INSUFFICIENT to distinguish a healthy mid-poll sub-agent from a stalled one. Long-running review-cycle pollers spend most of their wall-clock waiting on Greptile and emit no commits during that wait -- the #1166 swarm session is the recurrence record (two of three dispatched pollers went silent with zero observable signals; the monitor could not tell).
 
-! The canonical alive-check on the Grok Build hybrid path is the heartbeat contract documented in `docs/subagent-heartbeat.md`. Every long-running sub-agent (pollers, watchdogs, implementation agents whose tool loop exceeds ~3 min) writes a JSON heartbeat to `.deft-scratch/subagent-status/<agent-id>.json` per the canonical poller template + agent preamble; the monitor reads those records via `task agent:monitor` (three-state exit 0 ok / 1 stale-or-malformed / 2 config error). Default threshold is 30 minutes; `--threshold-minutes` overrides.
+! The canonical alive-check on the Grok Build hybrid path is the heartbeat contract documented in `docs/subagent-heartbeat.md`. Every long-running sub-agent (pollers, watchdogs, implementation agents whose tool loop exceeds ~3 min) writes a JSON heartbeat to `.deft-scratch/subagent-status/<agent-id>.json` per the canonical poller template + agent preamble. Default threshold is 30 minutes; `--threshold-minutes` overrides.
+
+! Monitors MUST poll with `task verify:subagent-alive -- --require-agent <agent-id> [--scratch-dir <worktree>/.deft-scratch/subagent-status]` so a missing required record is exit `1` + `REDISPATCH_OK`, not a raw sweep that treats an empty dir as OK. `task agent:monitor` remains the raw sweep.
 
 ```
-# Scan all worktrees in the cohort
-task agent:monitor -- \
-  --scratch-dir <worktree-1>/.deft-scratch/subagent-status \
-  --scratch-dir <worktree-2>/.deft-scratch/subagent-status
+task verify:subagent-alive -- \
+  --require-agent <agent-id> \
+  --scratch-dir <worktree>/.deft-scratch/subagent-status
 ```
 
-! Run the heartbeat sweep alongside the worktree git checks at every monitor polling iteration (~2-3 min). When a record is reported STALE (mid-flight, terminal_state unpopulated, age > threshold), treat it as a candidate for the Takeover Triggers below; when it is reported MALFORMED, surface the diagnostics to the user and re-dispatch the agent with a fresh prompt that re-establishes the heartbeat contract. A TERMINAL record (terminal_state set) is NEVER stale -- the agent reached its exit on its own terms.
+! Run the liveness gate alongside the worktree git checks at every monitor polling iteration (~2-3 min). When a record is reported STALE (mid-flight, terminal_state unpopulated, age > threshold), treat it as a candidate for the Takeover Triggers below; when it is reported MALFORMED, surface the diagnostics to the user and re-dispatch the agent with a fresh prompt that re-establishes the heartbeat contract. A TERMINAL record (terminal_state set) is NEVER stale -- the agent reached its exit on its own terms.
 
 ~ The heartbeat is filesystem-only by design; a network partition or rate-limit ceiling cannot mask agent liveness. Pair the on-disk sweep with the worktree git checks (`git status --short`, `git log --oneline -3`) and the per-PR readiness gate (`task pr:merge-ready`) for the full alive + progressing + clean picture.
 
@@ -144,12 +145,14 @@ task swarm:pre-dispatch -- \
   --scope-id <id> --target-id <target> \
   --action complete --status succeeded|failed|cancelled|blocked
 
-# Takeover: cancel prior attempt, THEN pre-dispatch begin again (never dual active)
+# Takeover after REDISPATCH_OK: cancel prior attempt, THEN pre-dispatch begin again (never dual active)
 task swarm:pre-dispatch -- --scope-id <id> --target-id <target> --action cancel
 task swarm:pre-dispatch -- --scope-id <id> --target-id <target>   # begin
+# If verify:session-ritual --tier=gated fails first:
+task session:start --rearm --session-id=<same>
 ```
 
-! Gate authority is **#3143** `DENY_DUPLICATE_ACTIVE` (`maxActiveAttempts: 1`) on the delivery-attempt unit ledger (`scopeId` + `targetId` + `workflowId`, default workflow `drive-to:merge-ready`). CLI is authoritative; this section is a pointer only.
+! Gate authority is **#3143** `DENY_DUPLICATE_ACTIVE` (`maxActiveAttempts: 1`) on the delivery-attempt unit ledger (`scopeId` + `targetId` + `workflowId`, default workflow `drive-to:merge-ready`). A killed worker stays `queued`/`running` until cancel; `REDISPATCH_OK` does not lift the deny (#3730). CLI is authoritative; this section is a pointer only.
 ⊗ Spawn a second implement leaf while pre-dispatch exits 1 (active attempt exists).
 ⊗ Treat "resume failed" / host false-alive as license to skip the gate.
 ⊗ Lift DENY by concurrent dual active — escape hatch is cancel-then-begin, not override-while-both-run.

package/skills/deft-directive-swarm/references/host-cursor.md

@@ -11,6 +11,7 @@ Load this file only after detect selects Cursor. Do not load other host adapters
 ### Step 2e: Cursor Launch (Task tool available) — #1877
 
 ! When the platform descriptor is `cursor-composer` or `cursor-cloud-agent` (Cursor `Task` tool detected with Cursor signals, no `start_agent`, no `WARP_*`, no Claude Code classification, no OpenClaw `sessions_spawn`, no `spawn_subagent`), dispatch each worker via the Cursor `Task` tool with:
+0. Create `<worktree>/.deft-scratch/subagent-status/` before spawn if `swarm:launch` / `swarm:pre-dispatch` did not already (#3730). Include preamble § 10.5 (heartbeat + commit early) and poll with `task verify:subagent-alive -- --require-agent <agent-id>`.
 1. The canonical `templates/agent-prompt-preamble.md` content as the preamble (AGENTS.md read mandate, #810 xBRIEF gate, #798 PowerShell UTF-8, pre-PR + review-cycle mandates).
 2. The standard worktree prompt (STEP 1-6 from the Prompt Template below).
 3. The worktree path set to the agent's isolated git worktree.

package/skills/deft-directive-swarm/references/host-grok-build.md

@@ -24,6 +24,7 @@ This path became first-class in #1342 (platform adapter slices 1-3) and is fully
 ### Step 2d: Grok Build Launch (spawn_subagent available)
 
 ! When the platform descriptor is `grok-build` (spawn_subagent detected, no start_agent, no WARP_*, no Cursor `Task`, no OpenClaw `sessions_spawn`), dispatch each worker via `spawn_subagent` with:
+0. Create `<worktree>/.deft-scratch/subagent-status/` before spawn if launch/pre-dispatch did not already, and instruct the worker to heartbeat + commit early (#3730).
 1. The canonical `templates/agent-prompt-preamble.md` content as the preamble
 2. The standard worktree prompt (STEP 1-6 from the Prompt Template below), adapted to use `get_command_or_subagent_output` for polling rather than `start_agent` lifecycle events
 3. The worktree path set to the agent's isolated git worktree