@deftai/directive-content 0.106.0 → 0.108.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`,
@@ -334,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
 
@@ -373,6 +407,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:

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):
@@ -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-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

@@ -1,10 +1,10 @@
 ---
 name: deft-directive-design-critique
 description: >-
-  Thin router for the design-critique motion: triggers and five pointer stops
-  into the contract. 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.
+  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
@@ -30,7 +30,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## 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).
+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
@@ -38,9 +38,25 @@ Normative rules live in [`contracts/design-critique.md`](../../contracts/design-
 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.
+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-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-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-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-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: