@deftai/directive-content 0.105.0 → 0.107.0

package/scm/github.md

@@ -306,7 +306,11 @@ auth.
   `--with-network` / `DEFT_SESSION_START_NETWORK=1`.
 - ! `deft scm:status` (alias `scm:readiness`) is the explicit probe verb:
   exit `0` ready / `1` not ready / `2` config. Flags: `--json`,
-  `--deep` / `--shallow` / `--depth shallow|deep`.
+  `--deep` / `--shallow` / `--depth shallow|deep`, `--repo OWNER/REPO`,
+  `--expected-login`.
+  Deep validation derives the target repository and compares an expected
+  user login when one is supplied (#3665). GitHub App installation identity
+  is deferred to #3693.
 - ! When not ready, diagnostics MUST name the reason
   (`binary-absent` | `missing-token` | `unauthenticated` | ...) and list
   skipped gates (`triage:queue`, `issue:ingest`, `pr:*`, `reconcile:issues`,
@@ -373,6 +377,35 @@ Agent `edit_files` operations can fail when structured file sections contain Uni
 
 **Mirror** (if using `triage:classify -- --mirror`): at least `triaged`; optional `triage:deferred` / `triage:archived` when `actionLabels` maps them
 
+### Consumer hard-blocker (`adoption-blocker`)
+
+**Framework source (`deftai/directive` only).** Consumer kits do not ship this label; see `.github/ISSUE_LABELS.md`.
+
+**Positive-only:** the `adoption-blocker` label means the issue is *classified as a blocker*. Its absence means *not classified*. Absence never means a workaround exists.
+
+This is the canonical ranking label for **a Directive consumer cannot complete an intended flow and has no reasonable workaround**. The range is install, first session, update, `task check`, and ship -- not onboarding alone. Do not invent a second ranking label for that class.
+
+**Title classification (the one sanctioned exception, #3713):** `BLOCKER` in the title is permitted for this class, and is the **only** classification allowed in an issue title. Every other classification stays label-only. Reason: the filing population cannot apply labels -- GitHub requires push access to set them at issue creation. The token is an inbound flare; it never writes `adoption-blocker`. A privileged actor applies the label after the body-evidence test below. Absence of the token does not mean "not a blocker." `task feedback:file --blocker` is the consumer filing path that carries the token and this evidence.
+
+**Classification test** (all must hold, and a second person must be able to check them from the body):
+
+1. An intended consumer flow at a named version does not complete.
+2. Documented alternatives were tried and failed, or are not a reasonable workaround.
+3. Recovery cost is observed (time, lost work, or a stuck session), not inferred.
+
+**Required body evidence** -- apply the label only when all four are present:
+
+- affected consumer flow and version
+- documented alternatives attempted, or why the documented alternatives are not a reasonable workaround
+- observed recovery cost
+- triage owner and date
+
+**Upgrade path:** a hard stop on the upgrade flow is still a consumer hard stop. Apply `adoption-blocker` so it ranks. Also apply `Upgrade Blocker` as the upgrade-specific adjacent signal. `Upgrade Blocker` alone does not rank. A hard stop at `task check` or ship is `adoption-blocker` only.
+
+**Not this label:** `status:blocked` means *this issue* waits on something else. `urgent` is priority; an issue may be `urgent` and still not a consumer hard stop.
+
+**Ranking / display:** `plan.policy.triageRankingLabels` already lists `adoption-blocker` (after `blocks-merge` and `blocks-release-tag`). `triage:queue` prints `(label: adoption-blocker)` on matched rows. Confirm participation; do not add ranking code.
+
 ### Post-1.0.0 Issue Linking
 
 Following a v1.0.0 release, commits:
@@ -503,7 +536,7 @@ Three consumer-facing surfaces enforce the branch-policy contract:
 - `deft verify:branch` — refuses default-branch commit unless `plan.policy.allowDirectCommitsToMaster = true` (typed) or `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1`.
 - `.githooks/pre-commit` / `pre-push` — installed via `deft setup`; verify via `deft verify:hooks-installed`. After a framework upgrade, run `deft update` to refresh hook templates (#2049).
 - `deft policy:show --field=allowDirectCommitsToMaster` — inspect policy; `deft policy:allow-direct-commits -- --confirm` writes typed override with audit row.
-- `deft verify:forward-coverage` — forward-coverage gate (#1310), wired into `deft check` + pre-commit (`--staged`); document exceptions via `--allow-list <path>`.
+- `deft verify:forward-coverage` — fail-closed new-source-file existence (#1310) plus warn-first diff coverage of added/modified branches (#3514). Intersects `coverage/coverage-final.json` with the diff (90% per-change branch threshold). That 90% is not the 75 global floor. Wired into `deft check` + pre-commit (`--staged`); `--enforce` fail-closes the diff half; `--allow-list <path>` documents exceptions.
 
 When `plan.policy.allowDirectCommitsToMaster = true`, the agent MUST surface at session start (after alignment confirmation):
 

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

@@ -494,7 +494,7 @@ feat(phase-2): add REST API endpoints with integration tests
 
 ## Completion
 
-- ! When all phases pass and `task check` is green, complete each implemented story via `task scope:complete -- <active-story-path>` before final PR handoff.
+- ! When all phases pass and `task check` is green, run `task scope:complete -- <active-story-path>` only as the post-merge scope lifecycle in `templates/agent-prompt-preamble.md` §9 (AGENTS.md `#2321`) specifies for `drive-to: merge-ready` versus `stop-at: pr-open`. That section is the single statement of the ordering; this skill does not restate it.
 
 > "The project is built and all quality checks pass. Describe any new features you'd like to add — I'll follow the deft standards we've set up."
 

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

@@ -0,0 +1,55 @@
+---
+name: deft-directive-design-critique
+description: >-
+  Thin router for the design-critique motion: triggers and pointer stops into
+  the contract, including the operator-gated loop. Use when the operator asks
+  for a design critique, design-critique, critique panel, or mechanism-shaped
+  triage. Do NOT trigger on ordinary implement, build, or swarm work.
+triggers:
+  - design critique
+  - design-critique
+  - critique panel
+  - mechanism-shaped triage
+---
+<!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
+<!-- Purpose: rendered skill -->
+<!-- Source of truth: packs/skills/skills-pack-0.1.json -->
+<!-- Regenerate with: task packs:render -->
+<!-- Edit the source, not this file. Slice instead of loading every SKILL.md: task packs:slice skills by-trigger --trigger <kw> (or list) -->
+
+# Design Critique
+
+Thin router into the design-critique contract. Operator dispatches from the brief template.
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+## When to Use
+
+- Operator asks for a design critique, a design-critique, a critique panel, or mechanism-shaped triage
+- ⊗ Ordinary implement, build, or swarm work
+
+## Stops
+
+Normative rules live in [`contracts/design-critique.md`](../../contracts/design-critique.md). Fill [`templates/design-critique-brief.md`](../../templates/design-critique-brief.md) and dispatch from there. Phase 1 gate: [`docs/decisions/ADR-005-design-critique-judgment-gate.md`](../../../docs/decisions/ADR-005-design-critique-judgment-gate.md). Parent-audit principle: [`docs/decisions/ADR-006-parent-side-substantiation.md`](../../../docs/decisions/ADR-006-parent-side-substantiation.md).
+
+1. Stop 1 — Gate
+2. Stop 2 — Variant selection
+3. Stop 3 — Critic envelope
+4. Stop 4 — Residual reiteration
+5. Stop 5 — Verified synthesis
+
+Comment lead (model then role): Stop 3 — Critic envelope.
+Operator-gated loop. Successor lean. Parent-side substantiation. Operator verbs. Dual stop. Halt line. Bind after accepted synthesis.
+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.
+
+Each critic dispatch EXITs after posting.
+
+⊗ 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.

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

@@ -37,12 +37,19 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 - ! Batch multiple friction items into one upstream issue when they share a root cause; otherwise prepare separate drafts
 - ~ Prefer attributed phrasing ("encoding gate blocked a valid file") over vague quality claims
 
+## Phase 1.5 -- Adoption-blocker judgment
+
+- ! Ask whether the gap blocks adoption. A gap blocks adoption when the consumer cannot complete an intended Directive flow and has no reasonable workaround.
+- ! When the answer is yes, collect the body evidence a privileged actor needs before applying `adoption-blocker`: affected consumer flow and version; documented alternatives attempted, or why they are not a reasonable workaround; observed recovery cost. Pass `--blocker` (and `--flow`, `--alternatives`, `--recovery-cost` when known) so the title carries `BLOCKER` and the body carries those sections.
+- ! When the answer is no or unknown, omit `--blocker`. Absence of the token does not mean "not a blocker" -- it means not classified.
+- ⊗ Apply or request the `adoption-blocker` ranking label from a consumer-authored title. The label is a privileged write after the body-evidence test.
+
 ## Phase 2 -- Draft + dedup
 
 - ! For each candidate report, run a dry draft:
 
 ```bash
-task feedback:file -- --summary "<one-line summary>" --context "<session context>" --expected "<expected>" --actual "<actual>" --notes "<optional>"
+task feedback:file -- --summary "<one-line summary>" --context "<session context>" --expected "<expected>" --actual "<actual>" --notes "<optional>" [--blocker --flow "<flow and version>" --alternatives "<alts>" --recovery-cost "<cost>"]
 ```
 
 - ! Read the printed draft title/body with the operator before proceeding
@@ -55,7 +62,7 @@ task feedback:file -- --summary "<one-line summary>" --context "<session context
 - ! Only after approval, re-run with `--confirm`:
 
 ```bash
-task feedback:file -- --summary "<one-line summary>" --context "<session context>" --expected "<expected>" --actual "<actual>" --confirm
+task feedback:file -- --summary "<one-line summary>" --context "<session context>" --expected "<expected>" --actual "<actual>" --confirm [--blocker]
 ```
 
 - ! Print the filed issue URL to the operator
@@ -71,3 +78,5 @@ task feedback:file -- --summary "<one-line summary>" --context "<session context
 - ⊗ Filing from the maintainer framework repo (consumer-only guard)
 - ⊗ Skipping dedup review when the command reports an existing open issue
 - ⊗ Treating `--confirm` as implicit from broad session approval -- require an explicit filing confirmation step
+- ⊗ Infer "not a blocker" from an unmarked report -- absence of `BLOCKER` means not classified
+- ⊗ Auto-apply `adoption-blocker` from a consumer-authored title

package/skills/deft-directive-issue-eval/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: deft-directive-issue-eval
+description: >-
+  Thin router for Stage A issue evaluation: isolated origin/master validity,
+  parent WIP census, named gitignored sink. Use when the operator asks to
+  evaluate issues, run issue-eval, or triage:evaluate. Do NOT trigger on
+  ordinary implement, build, swarm, or design-critique dispatch.
+triggers:
+  - issue-eval
+  - issue eval
+  - triage:evaluate
+  - evaluate issues
+---
+<!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
+<!-- Purpose: rendered skill -->
+<!-- Source of truth: packs/skills/skills-pack-0.1.json -->
+<!-- Regenerate with: task packs:render -->
+<!-- Edit the source, not this file. Slice instead of loading every SKILL.md: task packs:slice skills by-trigger --trigger <kw> (or list) -->
+
+# Issue Eval
+
+Thin router into the issue-eval contract. Operator runs `task triage:evaluate`.
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+## When to Use
+
+- Operator asks to evaluate issues, run issue-eval, or `triage:evaluate`
+- ⊗ Ordinary implement, build, swarm, or design-critique dispatch
+
+## Stops
+
+Normative rules live in [`contracts/issue-eval.md`](../../contracts/issue-eval.md).
+
+1. Split read sources
+2. Verdict sink
+3. Evaluator worktrees
+4. Value advice grammar
+5. No GitHub writes
+6. Fan-out
+
+⊗ Emit `design-critique: warranted | not warranted, because` from evaluation.
+⊗ Reuse `swarm:launch` until #3649.
+⊗ Write `xbrief/proposed/` or GitHub from this skill.
+
+## EXIT
+
+deft-directive-issue-eval complete -- exiting skill. Next: run `task triage:evaluate`, then decide with existing `triage:*` verbs.

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

@@ -43,6 +43,8 @@ While probe completion criteria (below) are NOT met:
 
 ! Read existing context and interrogate only — artifacts land in the Output phase after completion.
 
+**Waiver (#3556):** This skill keeps the no-artifact guard and does not require `deft probe-session`. The probe strategy names `deft probe-session`. Silence is not agreement.
+
 ## Workflow
 
 ### Step 1: Establish the plan
@@ -95,7 +97,7 @@ Walk the decision tree depth-first. For each unresolved branch:
 
 `{scope}` is the project name from `PROJECT-DEFINITION.xbrief.json`, or the feature/component name if probing a sub-scope. Use the same value consistently throughout the session.
 
-- ! Produce a `xbrief/proposed/{scope}-probe.xbrief.json` scope xBRIEF with three mandatory narratives:
+- ! Produce a `xbrief/proposed/YYYY-MM-DD-{scope}-probe.xbrief.json` scope xBRIEF with three mandatory narratives:
   - `LockedDecisions` — what was resolved and why
   - `SurfacedRisks` — concerns raised, even if not fully resolved
   - `DeferredDecisions` — explicitly acknowledged items with justification
@@ -105,7 +107,7 @@ Walk the decision tree depth-first. For each unresolved branch:
 
 ## Chaining Gate
 
-After the probe is complete and `xbrief/proposed/{scope}-probe.xbrief.json` is written:
+After the probe is complete and `xbrief/proposed/YYYY-MM-DD-{scope}-probe.xbrief.json` is written:
 
 - ! Register artifacts in `./xbrief/plan.xbrief.json` (`completedStrategies`, `artifacts`)
 - ! Return to [interview.md Chaining Gate](../../strategies/interview.md#chaining-gate) when invoked from the interview flow

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

@@ -180,7 +180,7 @@ See [`docs/RELEASING.md`](../../../docs/RELEASING.md) § Routine vs hard cut for
 6. ! **Run `task reconcile:issues -- --apply-lifecycle-fixes` to clear any closed-issue / non-completed-folder xBRIEFs before invoking `task release`** (#734). The release pipeline carries the deterministic gate at Step 3 (`scripts/release.py::check_vbrief_lifecycle_sync`, refuses with `EXIT_VIOLATION` on any Section (c) mismatch), but Phase 1 is the operator's first-line defence -- running the apply-mode flag here is the canonical clean path; `--allow-vbrief-drift` on the pipeline exists only as the explicit-acknowledgment escape hatch (analogous to `--allow-dirty`). The recurrence record is the v0.21.0 cut, which surfaced 13 stranded xBRIEFs (8 cycle-relevant + 5 historical residue) post-publish; the gate now blocks that drift before any irreversible action
 7. ! **Verify the proposed `v<version>` tag is not already in use locally, on origin, or as a published GitHub release** (#784). The release pipeline carries the deterministic gate at Step 4 (`scripts/release.py::check_tag_available`, refuses with `EXIT_VIOLATION` before any state mutation -- CHANGELOG promotion, ROADMAP refresh, build, commit), but Phase 1 is the operator's first-line defence. Quickly probe with `git tag -l v<version>` (local), `git ls-remote --tags origin refs/tags/v<version>` (remote), and `gh release view v<version> --repo <owner>/<repo>` (release-only, where `gh release view` exits 0 only when the release exists). The recurrence record is the v0.22.0 → v0.23.0 release attempt on 2026-05-01: the operator typed `0.22.0` (the prior release from 12 hours earlier) and the legacy pipeline ran 8 steps before failing at `git tag` -- leaving a wrong-version local commit + `dist/deft-0.22.0.zip` orphan + manual `git reset --hard` recovery. The new pre-flight gate blocks that mode before any irreversible action
 8. ! **Verify the npm credential path is configured before cutting the tag** (#1910, #1909). A `v*` tag now auto-triggers `.github/workflows/npm-publish.yml`, which publishes the four `@deftai/directive*` packages with `npm publish --provenance`. Confirm the publish path can authenticate: either the `NPM_TOKEN` repo secret is present (`gh secret list --repo <owner>/<repo>` shows `NPM_TOKEN`) OR an npm OIDC trusted publisher is configured for the `@deftai/directive*` packages. If neither is in place, WARN loudly that the tag will fire a publish job that fails (red X on the tag, no packages) -- the operator may still proceed for a GitHub-only release, but the npm channel will not land until #1909's credential is provisioned. Cross-reference #1909.
-9. ! **Disclose npm irrevocability before any tag push (#1972, #2002).** A `v<version>` tag push is the **real npm publish gate** -- NOT Phase 5 or `task release:publish`. Tag push fires `.github/workflows/npm-publish.yml` in a separate workflow that is NOT draft-gated; npm packages ship immediately and **cannot be retracted** (`npm unpublish` is forbidden). Recovery is forward-only: deprecate, dist-tag, or ship a patch. The operator's explicit `yes` in Phase 2 (dry-run) and the decision to invoke `task release` in Phase 4 are the last human gates before npm goes live. Phase 5 only controls GitHub release visibility (draft → public); it does NOT gate npm.
+9. ! **Disclose npm irrevocability before any tag push (#1972, #2002, #3527).** A `v<version>` tag push is the **real npm publish gate** -- NOT Phase 5 or `task release:publish`. Tag push fires `.github/workflows/npm-publish.yml` in a separate workflow that is NOT draft-gated; npm packages ship immediately and **cannot be retracted** (`npm unpublish` is forbidden). Recovery is forward-only: deprecate, dist-tag, or ship a patch. The last human gates before npm goes live are: (a) Phase 2 dry-run `yes`, (b) a human-origin closed-verb grant (`deft authz:grant -- --template release-publish --target <version>` or `DEFT_ALLOW_RELEASE_PUBLISH=1`). `task release` fails closed at the Step 10–11 tag-push boundary without that grant. Phase 5 only controls GitHub release visibility (draft → public); it does NOT gate npm. The draft-flip `release:publish` closed-verb check remains (#1095).
 10. ~ Ask the operator for an optional one-line release **summary** (recommended 80-160 chars; can be skipped). The summary is the canonical narrative for THIS release across three audiences: (a) injected as a Markdown blockquote at the top of the promoted `CHANGELOG.md [<version>]` section, (b) auto-flowed into the GitHub release body via the existing `_section_for_version` pickup, and (c) populated VERBATIM into the Phase 8 Slack `*Summary*:` slot. Capture the wording once here; do NOT regenerate per-audience downstream
 
 ⊗ Skip the version-bump magnitude check -- a patch release that ships breaking changes is the kind of regression that Repair Authority [AXIOM] (#709) is designed to prevent.
@@ -201,7 +201,7 @@ task release -- <version> --dry-run --skip-tag --skip-release --summary "<text>"
 
 The dry-run prints `[N/13] <step>... DRYRUN (would <action>)` for every pipeline step (Step 13 is the post-create verify-isDraft gate added by #724; Step 4 is the tag-availability pre-flight gate added by #784). Step 6 (CHANGELOG promotion) surfaces whether a summary was supplied (truncated to ~60 chars in the preview) so the operator can validate the wording before any file is written. Capture the output and present it to the user, then wait for explicit confirmation before continuing.
 
-! Wait for explicit user confirmation: `yes` / `back` / `quit`. Remind the operator that Phase 4's tag push will irrevocably publish npm (#1972) -- this `yes` is the last safe abort before that channel opens.
+! Wait for explicit user confirmation: `yes` / `back` / `quit`. Remind the operator that Phase 4's tag push will irrevocably publish npm (#1972) and requires a `release-publish` grant (or `DEFT_ALLOW_RELEASE_PUBLISH=1`) -- this `yes` is the last safe abort before that channel opens (#3527).
 - `yes` (or `confirmed` / `approve`) → proceed to Phase 3
 - `back` → return to Phase 1 for re-validation (e.g. user wants to amend the version or `[Unreleased]` content)
 - `quit` → abort the workflow cleanly; no state changes
@@ -232,7 +232,7 @@ The harness provisions `deftai/deftai-release-test-<ts>-<uuid6>`, runs the smoke
 
 ## Phase 4 — Production draft
 
-! **Last human gate before npm (#1972, #2002).** Immediately before invoking `task release`, re-state that the tag push in this step will irrevocably publish all four `@deftai/directive*` packages to npm via `.github/workflows/npm-publish.yml`. There is no undo on npm; only forward recovery (deprecate / dist-tag / patch). Proceed only when the operator explicitly confirms.
+! **Last human gate before npm (#1972, #2002, #3527).** Immediately before invoking `task release`, re-state that the tag push in this step will irrevocably publish all four `@deftai/directive*` packages to npm via `.github/workflows/npm-publish.yml`. There is no undo on npm; only forward recovery (deprecate / dist-tag / patch). Proceed only when the operator explicitly confirms **and** a human-origin grant covers `release-publish` for this version (`deft authz:grant -- --template release-publish --target <version>` or `DEFT_ALLOW_RELEASE_PUBLISH=1`). The pipeline fails closed at Step 10–11 without that grant -- that is the npm-distributing boundary. ⊗ Rely on Phase 5 `release:publish` as the npm gate; it only flips the GitHub draft. ⊗ Delete the draft-flip check as a substitute for the tag-push gate.
 
 ! Invoke `task release -- <version>` (NO `--dry-run`, NO `--skip-tag`, NO `--skip-release`, NO `--skip-ci`). If Phase 1 collected an operator summary, pass `--summary "<text>"` so the production cut writes the same blockquote the dry-run previewed.
 
@@ -377,6 +377,8 @@ Where `<one-line guidance>` is one of:
 - ⊗ Run `task release` without a Phase 2 dry-run preview -- the dry-run is the only safe place to catch a bad version, malformed CHANGELOG, or wrong base branch
 - ⊗ Skip Phase 3 (e2e rehearsal) on the assumption that "the dry-run is enough" -- the e2e harness catches gh-CLI auth issues, repo permission gaps, and pipeline-shape regressions that the dry-run cannot detect
 - ⊗ Pass `--no-draft` to `task release` without explicit operator opt-in -- the default-draft contract is the foundation of the safety hardening surface
+- ⊗ Invoke `task release` without `--skip-tag` when no `release-publish` grant or `DEFT_ALLOW_RELEASE_PUBLISH` is present -- the v0.105.0 cut published npm with no authz because the closed-verb check sat only on the later draft flip (#3527)
+- ⊗ Delete the `release:publish` draft-flip closed-verb check as a substitute for the tag-push gate -- placement, not strength; both stay (#3527 / #1095)
 - ⊗ Treat Phase 5 as the npm authority gate or require a redundant human `publish` prompt when npm already succeeded -- npm ships at tag push (#1972); Phase 5 is GitHub draft QA only
 - ⊗ Expect `task release:rollback` to retract npm packages -- rollback is GitHub-only; npm recovery is forward-only (deprecate / dist-tag / patch)
 - ⊗ 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

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

@@ -75,7 +75,7 @@ On OpenClaw hosts with Directive installed (`.deft/core/` or equivalent content
 ! Before entering the review/fix loop, run the skill-level branch-policy guard (#746 / #747). Halt before any state mutation if the project's `plan.policy.allowDirectCommitsToMaster` is unresolvable AND the operator has not set `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1`. Concretely:
 
 ```
-task verify:branch || exit 1
+deft verify:branch || exit 1
 ```
 
 The skill MUST NOT modify files, push, or comment on the PR until the guard passes -- this catches the case where a malformed PROJECT-DEFINITION quietly disabled the policy and the agent would have committed directly to master mid-review.

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

@@ -29,7 +29,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 ! Before any state mutation (creating worktrees, dispatching sub-agents, opening PRs), run the skill-level branch-policy guard (#746 / #747). Halt with the actionable disclosure message when the project's `plan.policy.allowDirectCommitsToMaster` is unresolvable AND `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT` is unset:
 
 ```
-task verify:branch || exit 1
+deft verify:branch || exit 1
 ```
 
 The swarm skill creates branches per agent so the guard is mostly informational here, but a malformed PROJECT-DEFINITION (missing `plan.policy` block AND no legacy narrative) is a fail-closed signal worth surfacing before the swarm spawns N agents.

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

@@ -37,7 +37,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## Deterministic Questions Contract
 
-! Every numbered-menu prompt rendered in this skill (Phase 2 candidate selection, Phase 3 per-item decision walk) ! MUST follow [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md): render the canonical numbered menu in chat unless the host UI visibly preserves numeric option labels and returns numeric selections or exact displayed option text. The final two numbered options are `Discuss` and `Back`, in that order, and the Discuss-pause semantic from the contract applies verbatim -- on `Discuss` the agent halts the in-progress sequence and resumes only on an explicit user signal.
+! Every numbered-menu prompt rendered in this skill (Phase 2 candidate selection, Phase 3 per-item decision walk, post-Accept offer) ! MUST follow [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md): render the canonical numbered menu in chat unless the host UI visibly preserves numeric option labels and returns numeric selections or exact displayed option text. The final two numbered options are `Discuss` and `Back`, in that order, and the Discuss-pause semantic from the contract applies verbatim -- on `Discuss` the agent halts the in-progress sequence and resumes only on an explicit user signal.
 
 ## Work selection fork (#2542 / #2402)
 
@@ -101,6 +101,7 @@ What would you like to do with this candidate?
 - ~ Bulk: `task triage:bulk-{accept,reject,defer,needs-ac}`; results still flow through the audit log.
 - ⊗ Write to `xbrief/proposed/` directly -- only `task triage:accept` is authorised.
 - ~ **Accept → pending chain (#1136):** `task triage:accept` ingests into **`proposed/`**. To stage into WIP (`pending/`) in one operator action: `task triage:accept -- --issue <N> --repo OWNER/NAME --auto-promote` (WIP cap still enforced; use `--force` on the accept command for WIP override). Separately, promote an already-accepted proposed scope by issue: `task scope:promote -- --from-issue=<N> [--repo OWNER/NAME]` (gates on latest `candidates.jsonl` decision = `accept`; non-accept refuses unless `--force-no-cache`; no decision soft-warns, `--strict` fails). Path-based `task scope:promote -- <file>` remains ungated for refinement scaffolds.
+- ? **After Accept (#3708):** offer `deft-directive-design-critique`. Optional; same after `--auto-promote` (promote already happened). Decline writes nothing. Menu: 1. Run critique (existing ADR-005 path) 2. Skip 3. Discuss 4. Back. Back = Skip (do not re-open Accept; undo is `task triage:reset`).
 
 ## Phase 4 -- Audit
 
@@ -141,5 +142,5 @@ Live walkers (`triage:queue`, scope-drift, bootstrap) scan `.deft-cache/github-i
 
 ## References
 
-- #1119 D6; #1128 D11 (`triage:queue` / `show` / `audit`); #2890 Phase 3 operator brief; #3116 validity + URL-first; #1122 / #1123 / #1127 / #1129 / #1131; #1136 (`scope:promote --from-issue` / `triage:accept --auto-promote`)
+- #1119 D6; #1128 D11 (`triage:queue` / `show` / `audit`); #2890 Phase 3 operator brief; #3116 validity + URL-first; #1122 / #1123 / #1127 / #1129 / #1131; #1136 (`scope:promote --from-issue` / `triage:accept --auto-promote`); #3708 (post-Accept design-critique offer)
 - Siblings: `deft-directive-refinement`, `deft-directive-swarm`, `deft-directive-sync`

package/strategies/README.md

@@ -36,7 +36,7 @@ Every strategy has a **Type** that determines its behavior in the
   via `/deft:run:<name>` — when invoked outside an interview context, they present their
   own next-step options instead of returning to the chaining gate. See each strategy file
   for standalone support.
-- **`spec-generating`** — Produces v0.20-conformant output per [v0-20-contract.md](./v0-20-contract.md) (lifecycle folders + PROJECT-DEFINITION.vbrief.json + date-prefixed proposed/ scope vBRIEFs only; SPECIFICATION.md/PROJECT.md as deprecation stubs or omitted). Selecting one at the chaining gate switches the pipeline to that strategy’s spec flow.
+- **`spec-generating`** — Produces v0.20-conformant output per [v0-20-contract.md](./v0-20-contract.md) (lifecycle folders + PROJECT-DEFINITION.xbrief.json + date-prefixed proposed/ scope vBRIEFs only; SPECIFICATION.md/PROJECT.md as deprecation stubs or omitted). Selecting one at the chaining gate switches the pipeline to that strategy’s spec flow.
 
 Custom strategies MUST declare their type in this table. If the `Type` column is missing,
 the chaining gate cannot include the strategy.
@@ -45,9 +45,9 @@ the chaining gate cannot include the strategy.
 
 All spec-generating strategies (interview, yolo, speckit, rapid, enterprise) MUST produce output conforming to [v0-20-contract.md](./v0-20-contract.md):
 
-- Five vbrief/ lifecycle folders (proposed/ pending/ active/ completed/ cancelled/)
-- vbrief/PROJECT-DEFINITION.vbrief.json (full)
-- Scope vBRIEFs ONLY as date-prefixed in vbrief/proposed/YYYY-MM-DD-*.vbrief.json
+- Five xbrief/ lifecycle folders (proposed/ pending/ active/ completed/ cancelled/)
+- xbrief/PROJECT-DEFINITION.xbrief.json (full)
+- Scope vBRIEFs ONLY as date-prefixed in xbrief/proposed/YYYY-MM-DD-*.xbrief.json
 - Never dual-write legacy vbrief/specification.vbrief.json
 - SPECIFICATION.md/PROJECT.md only as deprecation-redirect stubs (banner + sentinel) or omitted
 

package/strategies/bdd.md

@@ -57,7 +57,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ! Before writing output artifacts, follow the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light).
 
-! Resolve all ambiguities surfaced by Step 3. Record decisions in `vbrief/proposed/{feature}-bdd.vbrief.json`.
+! Resolve all ambiguities surfaced by Step 3. Record decisions in `xbrief/proposed/{feature}-bdd.xbrief.json`.
 
 - ! Write a scope vBRIEF with two narratives:
   - `Scenarios` -- Given/When/Then scenario descriptions from Step 1
@@ -67,32 +67,32 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 - ⊗ Leave ambiguities unresolved -- every question surfaced in Step 3 must have a locked answer
 - ⊗ Write decisions to a hand-authored markdown file -- use vBRIEF narratives for token-efficient agent consumption
 
-! After emitting the scope vBRIEF to `vbrief/proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).
+! After emitting the scope vBRIEF to `xbrief/proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).
 
 ### Step 5: Generate Spec
 
 ! Derive SPECIFICATION.md tasks from the now-stable test scenarios and locked decisions.
 
 - ! Each scenario maps to one or more spec tasks with traceability (`traces: scenario-N`)
-- ! Locked decisions from `vbrief/proposed/{feature}-bdd.vbrief.json` `LockedDecisions` narrative flow into the spec as constraints
+- ! Locked decisions from `xbrief/proposed/{feature}-bdd.xbrief.json` `LockedDecisions` narrative flow into the spec as constraints
 - ~ Use the Light or Full path from [strategies/interview.md](./interview.md) based on project size
 
 ### Step 6: Chain into Interview Sizing Gate
 
 ! Follow [strategies/interview.md](./interview.md) sizing gate for SPECIFICATION.md finalisation.
 
-- ! On completion, register artifacts in `./vbrief/plan.vbrief.json`:
+- ! On completion, register artifacts in `./xbrief/plan.xbrief.json`:
   - Update `completedStrategies`: increment `runCount` for `"bdd"`, append artifact paths
   - Append all new artifact paths to the flat `artifacts` array
 - ! Return to [interview.md Chaining Gate](./interview.md#chaining-gate)
-- ! The locked decisions from `vbrief/proposed/{feature}-bdd.vbrief.json` and the acceptance tests MUST flow into subsequent strategies and spec generation
+- ! The locked decisions from `xbrief/proposed/{feature}-bdd.xbrief.json` and the acceptance tests MUST flow into subsequent strategies and spec generation
 
 ---
 
 ## Output Artifacts
 
 - Executable test files in the project's standard test directory -- derived from Given/When/Then scenarios
-- `vbrief/proposed/{feature}-bdd.vbrief.json` -- scope vBRIEF with `Scenarios` and `LockedDecisions` narratives
+- `xbrief/proposed/{feature}-bdd.xbrief.json` -- scope vBRIEF with `Scenarios` and `LockedDecisions` narratives
 
 ---
 

package/strategies/discuss.md

@@ -55,7 +55,7 @@ Use the Feynman technique: if the user (or you) can't explain the feature in sim
 
 - ! If the user suggests a capability belonging to a different feature, capture it as **deferred**
 - ~ Redirect: "That sounds like a new capability — I'll note it. For now, let's focus on [current scope]."
-- ~ Record deferred ideas in `./vbrief/plan.vbrief.json` with `deferred` status and a narrative explaining why
+- ~ Record deferred ideas in `./xbrief/plan.xbrief.json` with `deferred` status and a narrative explaining why
 
 ## Domain-Sensitive Questions
 
@@ -70,14 +70,14 @@ Adapt question focus to what's being built:
 
 ! Before writing output artifacts, follow the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light).
 
-- ! Produce a `vbrief/proposed/{scope}-context.vbrief.json` scope vBRIEF with a `LockedDecisions` narrative
+- ! Produce a `xbrief/proposed/{scope}-context.xbrief.json` scope vBRIEF with a `LockedDecisions` narrative
 - ! Each decision includes: **what** was decided, **why**, and **alternatives considered**
 - ! When the lock is an intentional under-build (weaker Now + decided end-product Later), the decision MUST also include dual-path graduation fields: `now`, `later`, `graduationRef`, `trigger`, and `status` (`open` | `shipped` | `cancelled`) — see [Graduation (Now+Later)](#graduation-nowlater-dual-path-locks-2899)
 - ! This vBRIEF is injected into all downstream work: planning, execution, verification
 - ! Persist decisions as vBRIEF narratives on the relevant plan items
 - ⊗ Write decisions to a hand-authored markdown context file -- use vBRIEF narratives for token-efficient agent consumption
 
-! After emitting the scope vBRIEF to `vbrief/proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).
+! After emitting the scope vBRIEF to `xbrief/proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).
 
 ## Decision Locking
 
@@ -128,18 +128,18 @@ Glossary naming for this term is owned by sibling work (#2907). Strategy prose h
 
 ## Then: Chaining Gate
 
-After alignment is complete and decisions are locked in `vbrief/proposed/{scope}-context.vbrief.json`,
+After alignment is complete and decisions are locked in `xbrief/proposed/{scope}-context.xbrief.json`,
 return to the [chaining gate](./interview.md#chaining-gate) so the user can
 run additional preparatory strategies or proceed to spec generation.
 
-- ! On completion, register artifacts in `./vbrief/plan.vbrief.json`:
+- ! On completion, register artifacts in `./xbrief/plan.xbrief.json`:
   - Update `completedStrategies`: increment `runCount` for `"discuss"`,
-    append artifact path (`vbrief/proposed/{scope}-context.vbrief.json`)
+    append artifact path (`xbrief/proposed/{scope}-context.xbrief.json`)
   - Append the path to the flat `artifacts` array
 - ! Return to [interview.md Chaining Gate](./interview.md#chaining-gate)
   (the discuss phase replaces the interview's question-gathering -- decisions are
   already made, so the interview will be short or skipped entirely)
-- ! The locked decisions from `vbrief/proposed/{scope}-context.vbrief.json` MUST flow into subsequent
+- ! The locked decisions from `xbrief/proposed/{scope}-context.xbrief.json` MUST flow into subsequent
   strategies and spec generation
 - ⊗ End the session after discuss without returning to the chaining gate
   or the invoking strategy's next-step menu
@@ -154,7 +154,7 @@ run additional preparatory strategies or proceed to spec generation.
 
 1. **Open** -- Start with the user's goal statement; restate it in your own words
 2. **Explore** -- Follow energy, challenge vagueness, ask domain-sensitive questions
-3. **Lock** -- Record each decision in `vbrief/proposed/{scope}-context.vbrief.json` `LockedDecisions` narrative with what/why/alternatives (and dual-path graduation fields when the lock is an under-build; #2899)
+3. **Lock** -- Record each decision in `xbrief/proposed/{scope}-context.xbrief.json` `LockedDecisions` narrative with what/why/alternatives (and dual-path graduation fields when the lock is an under-build; #2899)
 4. **Verify** -- Explain the full picture back to the user (Feynman check)
 5. **Chain** -- Return to [interview.md Chaining Gate](./interview.md#chaining-gate), or -- if invoked from a standalone strategy (e.g. map's standalone next-step menu) -- return to the invoking strategy's menu per the [standalone-context rule](#then-chaining-gate) above
 

package/strategies/emit-hints.md

@@ -16,7 +16,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## When to Use
 
-This file is not a standalone strategy — it is a shared hint referenced by other strategies. It activates at the emission step, right after a strategy writes scope vBRIEFs to `vbrief/proposed/` (or `vbrief/pending/`).
+This file is not a standalone strategy — it is a shared hint referenced by other strategies. It activates at the emission step, right after a strategy writes scope vBRIEFs to `xbrief/proposed/` (or `xbrief/pending/`).
 
 - ! Referenced by spec-generating strategies: [speckit](./speckit.md) (Phase 4 and Phase 4.5), [enterprise](./enterprise.md), [rapid](./rapid.md), [interview](./interview.md), [yolo](./yolo.md)
 - ! Referenced by preparatory strategies: [bdd](./bdd.md), [discuss](./discuss.md), [research](./research.md), [map](./map.md), [probe](./probe.md)
@@ -38,12 +38,12 @@ This file is not a standalone strategy — it is a shared hint referenced by oth
 <strategy> emitted N scope vBRIEF(s).
 
 Optional: track these in GitHub issues.
-  - task deft:issue:emit --umbrella -- vbrief/<path>/<glob>     (one roadmap issue, all vBRIEFs reference it)
-  - task deft:issue:emit --per-vbrief -- vbrief/<path>/<glob>   (one issue per vBRIEF)
+  - task deft:issue:emit --umbrella -- xbrief/<path>/<glob>     (one roadmap issue, all vBRIEFs reference it)
+  - task deft:issue:emit --per-vbrief -- xbrief/<path>/<glob>   (one issue per vBRIEF)
   - Default behavior (vBRIEF-only) requires no further action.
 ```
 
-~ Replace `<path>/<glob>` with the actual emission target (e.g. `vbrief/proposed/2026-06-15-*.vbrief.json`).
+~ Replace `<path>/<glob>` with the actual emission target (e.g. `xbrief/proposed/2026-06-15-*.xbrief.json`).
 
 Note: `task deft:issue:emit` is the consumer-installed surface (this is what strategies render to). The maintainer-side, in-repo form is `task issue:emit` — the same command without the `deft:` prefix.
 
@@ -52,8 +52,8 @@ Note: `task deft:issue:emit` is the consumer-installed surface (this is what str
 ## The Three Patterns
 
 1. **None (default)** — emit vBRIEF(s) only; file no GitHub issue. Requires no further user action. This is the framework default and is unchanged by this hint.
-2. **Umbrella** — `task deft:issue:emit --umbrella -- vbrief/<path>/<glob>` files ONE roadmap issue, and every matched vBRIEF references it.
-3. **Per-vBRIEF** — `task deft:issue:emit --per-vbrief -- vbrief/<path>/<glob>` files one issue per matched vBRIEF.
+2. **Umbrella** — `task deft:issue:emit --umbrella -- xbrief/<path>/<glob>` files ONE roadmap issue, and every matched vBRIEF references it.
+3. **Per-vBRIEF** — `task deft:issue:emit --per-vbrief -- xbrief/<path>/<glob>` files one issue per matched vBRIEF.
 
 - ! Name all three patterns (none / `--umbrella` / `--per-vbrief`) when surfacing the hint — do not hide the umbrella / per-vBRIEF escape hatches.
 - ⊗ File a GitHub issue automatically as part of emission. No strategy files an issue unless the user explicitly invokes `task deft:issue:emit`.

package/strategies/enterprise.md

@@ -8,7 +8,7 @@
 
 Compliance-heavy workflow -- v0.20 date-prefixed story/phase vBRIEF + PROJECT-DEFINITION with explicit approval gates at each stage.
 
-**v0.20 note (s5-migrate-speckit-rapid-enterprise / #1166):** Enterprise now emits only the canonical v0.20 shape (date-prefixed story/phase vBRIEFs in proposed/, full PROJECT-DEFINITION.vbrief.json via task project:render, seeded lifecycle folders, no legacy specification.vbrief.json). PRD.md and SPECIFICATION.md (if any) are deprecation-redirect derivatives only. See the dedicated ## v0.20 Output Shape section and the canonical contract `strategies/v0-20-contract.md` (s1-contract of #1166).
+**v0.20 note (s5-migrate-speckit-rapid-enterprise / #1166):** Enterprise now emits only the canonical v0.20 shape (date-prefixed story/phase vBRIEFs in proposed/, full PROJECT-DEFINITION.xbrief.json via task project:render, seeded lifecycle folders, no legacy specification.vbrief.json). PRD.md and SPECIFICATION.md (if any) are deprecation-redirect derivatives only. See the dedicated ## v0.20 Output Shape section and the canonical contract `strategies/v0-20-contract.md` (s1-contract of #1166).
 
 Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
@@ -38,12 +38,12 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ! Before writing output artifacts, follow the guards in [artifact-guards.md](./artifact-guards.md) (Preparatory Guard for proposed/ scope items; Spec-Generating Guard for PROJECT-DEFINITION).
 
-! Run the Full interview path from [interview.md](./interview.md) unconditionally -- write PRD narratives as date-prefixed story/phase vBRIEF(s) to `vbrief/proposed/YYYY-MM-DD-<kebab-slug>.vbrief.json`.
+! Run the Full interview path from [interview.md](./interview.md) unconditionally -- write PRD narratives as date-prefixed story/phase vBRIEF(s) to `xbrief/proposed/YYYY-MM-DD-<kebab-slug>.xbrief.json`.
 
 - ! Use the Full path regardless of project size -- enterprise always requires a PRD
 - ! Write PRD content as narratives in the proposed/ vBRIEF `plan.narratives`: `ProblemStatement`, `Goals`, `NonGoals`, `UserStories`, `Requirements` (functional + non-functional), `SuccessMetrics`
 - ! Record the PRD approver(s) in the `Approvers` narrative
-- ! Run `task prd:render` (if UX continuity needed) to produce `PRD.md` **only as a deprecation-redirect derivative** (see v0.20 Output Shape); the source of truth is the vbrief/ artifacts.
+- ! Run `task prd:render` (if UX continuity needed) to produce `PRD.md` **only as a deprecation-redirect derivative** (see v0.20 Output Shape); the source of truth is the xbrief/ artifacts.
 
 ### Gate 1: PRD Approval
 
@@ -76,14 +76,14 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ! Before writing output artifacts, follow the guards in [artifact-guards.md](./artifact-guards.md) (Preparatory Guard for proposed/ scope items; Spec-Generating Guard for PROJECT-DEFINITION).
 
-! Enrich or emit date-prefixed vBRIEF(s) in `vbrief/proposed/` with architecture and plan narratives derived from the approved PRD narratives and accepted ADRs. (No singular `specification.vbrief.json`.)
+! Enrich or emit date-prefixed vBRIEF(s) in `xbrief/proposed/` with architecture and plan narratives derived from the approved PRD narratives and accepted ADRs. (No singular `specification.vbrief.json`.)
 
 - ! Add HOW narratives to the proposed/ vBRIEF `plan.narratives`: `Architecture`, `TechDecisions`, `ImplementationPhases`, `TraceabilityMatrix`
 - ! Every spec task must trace to a PRD requirement and, where applicable, an ADR
 - ! Use the Light or Full path from [interview.md](./interview.md) for specification generation
 - ! Include traceability matrix: spec task → PRD requirement → ADR (where applicable)
-- ! Run `task spec:render` (if UX continuity needed) to produce `SPECIFICATION.md` **only as a deprecation-redirect derivative** (see v0.20 Output Shape); the source of truth is the vbrief/ lifecycle + PROJECT-DEFINITION.
-- ! After proposed/ vBRIEFs exist, invoke `task project:render` to produce/refresh `vbrief/PROJECT-DEFINITION.vbrief.json`.
+- ! Run `task spec:render` (if UX continuity needed) to produce `SPECIFICATION.md` **only as a deprecation-redirect derivative** (see v0.20 Output Shape); the source of truth is the xbrief/ lifecycle + PROJECT-DEFINITION.
+- ! After proposed/ vBRIEFs exist, invoke `task project:render` to produce/refresh `xbrief/PROJECT-DEFINITION.xbrief.json`.
 
 ! After emitting the proposed/ vBRIEF(s), surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).
 
@@ -107,13 +107,13 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## Output Artifacts
 
-- `vbrief/proposed/YYYY-MM-DD-*.vbrief.json` (one or more) -- source of truth for PRD and specification narratives (date-prefixed per v0.20 contract)
-- `vbrief/PROJECT-DEFINITION.vbrief.json` -- complete via `task project:render`
+- `xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (one or more) -- source of truth for PRD and specification narratives (date-prefixed per v0.20 contract)
+- `xbrief/PROJECT-DEFINITION.xbrief.json` -- complete via `task project:render`
 - `PRD.md` -- rendered export via `task prd:render` **only if deprecation-redirect sentinel** (read-only stakeholder review artifact; otherwise omit)
 - `docs/adr/adr-NNN-*.md` -- accepted Architecture Decision Records (unchanged location)
 - `SPECIFICATION.md` -- rendered export via `task spec:render` **only if deprecation-redirect sentinel** (read-only stakeholder review artifact; otherwise omit)
 - Traceability matrix (inline in the proposed/ vBRIEF narratives or as a separate `docs/traceability.md`)
-- `vbrief/{proposed,pending,active,completed,cancelled}/` -- all five lifecycle folders seeded
+- `xbrief/{proposed,pending,active,completed,cancelled}/` -- all five lifecycle folders seeded
 
 ---
 
@@ -139,11 +139,11 @@ Enterprise is a **spec-generating** strategy. It uses the Forced-Full path and a
 
 This strategy has been migrated to the full v0.20 output shape so enterprise-generated projects are accepted by the build skill Pre-Cutover Detection Guard with zero errors on first attempt (resolves the enterprise row from the #1166 inconsistency table and the s5 story acceptance criteria).
 
-- ! Seed the five lifecycle folders under `vbrief/` if any are missing: `proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`.
-- ! Emit scope items (PRD, spec phases, etc.) exclusively as date-prefixed scope vBRIEFs: `vbrief/proposed/YYYY-MM-DD-<kebab-slug>.vbrief.json` (use the run's creation date for the prefix; choose descriptive slugs). Decompose into focused, buildable vBRIEFs (v0.6 schema) rather than a monolithic legacy spec.
-- ! After the proposed/ vBRIEFs are written, invoke `task project:render` (run from the repo root) to generate/refresh the complete `vbrief/PROJECT-DEFINITION.vbrief.json` (items registry is derived from the lifecycle folders).
+- ! Seed the five lifecycle folders under `xbrief/` if any are missing: `proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`.
+- ! Emit scope items (PRD, spec phases, etc.) exclusively as date-prefixed scope vBRIEFs: `xbrief/proposed/YYYY-MM-DD-<kebab-slug>.xbrief.json` (use the run's creation date for the prefix; choose descriptive slugs). Decompose into focused, buildable vBRIEFs (v0.6 schema) rather than a monolithic legacy spec.
+- ! After the proposed/ vBRIEFs are written, invoke `task project:render` (run from the repo root) to generate/refresh the complete `xbrief/PROJECT-DEFINITION.xbrief.json` (items registry is derived from the lifecycle folders).
 - ⊗ Never emit `vbrief/specification.vbrief.json` (or any legacy dual-write).
-- ~ `PRD.md` and `SPECIFICATION.md` at the project root, if produced at all, must be only read-only derivatives that include the v0.20 deprecated-redirect sentinel (see conventions/machine-generated-banner.md). The source of truth is the vbrief/ lifecycle vBRIEFs + PROJECT-DEFINITION. ADRs remain in `docs/adr/`.
+- ~ `PRD.md` and `SPECIFICATION.md` at the project root, if produced at all, must be only read-only derivatives that include the v0.20 deprecated-redirect sentinel (see conventions/machine-generated-banner.md). The source of truth is the xbrief/ lifecycle vBRIEFs + PROJECT-DEFINITION. ADRs remain in `docs/adr/`.
 - ! Before writing any proposed/ vBRIEFs or PROJECT-DEFINITION, follow the guards in [artifact-guards.md](./artifact-guards.md) (Preparatory Guard for scope items in proposed/; Spec-Generating Guard for PROJECT-DEFINITION).
 - ! Final output tree must pass the deterministic v0.20 strategy output validation gate (s2-deterministic-gate) and the build Pre-Cutover Detection Guard with zero warnings/errors. See full acceptance in the s5 vBRIEF and the 1166 decomposition.
 - ! Cite the canonical contract `strategies/v0-20-contract.md` (s1-contract) for the exact shape and the per-strategy table row.
@@ -156,9 +156,9 @@ This strategy has been migrated to the full v0.20 output shape so enterprise-gen
 
 | Artifact | Purpose | Created By |
 |----------|---------|------------|
-| `vbrief/proposed/YYYY-MM-DD-*.vbrief.json` (one or more) | PRD + specification narratives as date-prefixed scope items (per v0.20 contract) | Enterprise |
-| `vbrief/PROJECT-DEFINITION.vbrief.json` | Project identity gestalt + complete scope items registry | `task project:render` (invoked by Enterprise) |
-| `vbrief/{proposed,pending,active,completed,cancelled}/` | All five lifecycle folders seeded | Enterprise |
+| `xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (one or more) | PRD + specification narratives as date-prefixed scope items (per v0.20 contract) | Enterprise |
+| `xbrief/PROJECT-DEFINITION.xbrief.json` | Project identity gestalt + complete scope items registry | `task project:render` (invoked by Enterprise) |
+| `xbrief/{proposed,pending,active,completed,cancelled}/` | All five lifecycle folders seeded | Enterprise |
 | `docs/adr/adr-NNN-*.md` | Accepted Architecture Decision Records (traceable) | Enterprise (unchanged) |
 | (optional derivative) `PRD.md` / `SPECIFICATION.md` | Human-readable (includes deprecated-redirect sentinel only) | `task prd:render` / `task spec:render` (if invoked) |
 
@@ -168,13 +168,13 @@ This strategy has been migrated to the full v0.20 output shape so enterprise-gen
 - Primary handoff `PRD.md` or `SPECIFICATION.md` at project root (without sentinel)
 - Bare-named vBRIEFs in proposed/
 
-See the full table and rules in `strategies/v0-20-contract.md` (enterprise row: Must Create Lifecycle Folders: Yes; Must Write PROJECT-DEFINITION: Yes; Scope vBRIEFs Location: proposed/YYYY-MM-DD-*.vbrief.json only; specification.vbrief.json: Never; SPECIFICATION.md / PROJECT.md: Omit or deprecation redirect only).
+See the full table and rules in `strategies/v0-20-contract.md` (enterprise row: Must Create Lifecycle Folders: Yes; Must Write PROJECT-DEFINITION: Yes; Scope vBRIEFs Location: proposed/YYYY-MM-DD-*.xbrief.json only; specification.vbrief.json: Never; SPECIFICATION.md / PROJECT.md: Omit or deprecation redirect only).
 
 ---
 
 ## Invoking This Strategy
 
-Set in PROJECT-DEFINITION.vbrief.json narratives:
+Set in PROJECT-DEFINITION.xbrief.json narratives:
 ```json
 "Strategy": "strategies/enterprise.md"
 ```