@deftai/directive-content 0.55.1 → 0.55.2

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

@@ -140,34 +140,15 @@ Loop body, per candidate (top-of-queue first):
 
 #### Phase 0d -- Cohort dispatch
 
-- ! After the promote-fill loop exits (cap reached, queue empty, or operator `stop`), `vbrief/pending/` now holds the cohort. On the interactive path, Phase 0e below captures the intended sub-agent backend before Step 0.5 hardens lifecycle state. Then the existing Step 0.5 (Lifecycle Bridge -- Promote and Activate Proposed Scope vBRIEFs, #1025) moves the cohort `pending/ -> active/`, and Steps 1-5 (readiness report, blockers, allocation, present, approval) proceed against the activated set. Existing swarm Phase 1+ (Select, Setup, Launch, Monitor, Review, Close) proceeds unchanged.
+- ! After the promote-fill loop exits (cap reached, queue empty, or operator `stop`), `vbrief/pending/` now holds the cohort. Phase 0e below is now deprecated (#1891) -- per-role operator model routing (`task swarm:routing-set`, #1739) supersedes the sub-agent backend enum; `task verify:routing -- --advise` is the session-start disclosure surface. The existing Step 0.5 (Lifecycle Bridge -- Promote and Activate Proposed Scope vBRIEFs, #1025) moves the cohort `pending/ -> active/`, and Steps 1-5 (readiness report, blockers, allocation, present, approval) proceed against the activated set. Existing swarm Phase 1+ (Select, Setup, Launch, Monitor, Review, Close) proceeds unchanged.
 
-#### Phase 0e -- Interactive sub-agent backend selection (#1568)
+#### Phase 0e -- Interactive sub-agent backend selection (DEPRECATED -- #1568 / superseded by #1739)
 
-! On the **interactive** swarm path, before Step 0.5 hardens lifecycle state and before any `task swarm:launch` / headless launch-manifest handoff is attempted, run `task policy:subagent-backends` and inspect `plan.policy.swarmSubagentBackend`.
+> **This phase is superseded.** Per-role operator model routing (`.deft/routing.local.json`, #1739) is the current mechanism for recording which model each worker role uses. Run `task verify:routing -- --advise` at session start and `task swarm:routing-set` to configure routing decisions. The `plan.policy.swarmSubagentBackend` enum and `task policy:subagent-backend(s)` surface are still present but deprecated (#1891); do not consult them for new work.
 
-! If `plan.policy.swarmSubagentBackend` is unset, ask the operator which subagent backend they intend to use. This question captures operator preference; probe availability is supporting evidence only. Display all stable backend choices with their probed status, but do NOT rank the menu by availability and do NOT imply `cursor-cloud` is the default just because it is probe-available.
+~ If `plan.policy.swarmSubagentBackend` is already set in the project policy and no `.deft/routing.local.json` is present, surface a one-line nudge asking the operator to run `task swarm:routing-set` to migrate to the routing surface before dispatch.
 
-Render the backend-selection prompt as a deterministic numbered menu in chat (or via a host UI that visibly preserves the same numeric option labels and exact displayed option text) with `Discuss` and `Back` final per [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md):
-
-1. Local Composer/Cursor subagents (`composer`) -- intended local Composer-class coding agents; probe status: `<available|unavailable|unknown>`.
-2. Cursor cloud agents (`cursor-cloud`) -- intended remote/cloud agents; probe status: `<available|unavailable|unknown>`.
-3. Grok Build subagents (`grok-build`) -- intended `spawn_subagent` workers; probe status: `<available|unavailable|unknown>`.
-4. Discuss
-5. Back
-
-! After the operator selects a backend, ask whether to persist it to project policy with `task policy:subagent-backend -- <id>` or record it as a per-run launch-context choice for this swarm only. Render the persistence/per-run follow-up as a deterministic numbered menu with `Discuss` and `Back` as the final two options:
-
-1. Persist backend to project policy with `task policy:subagent-backend -- <id>` -- use this backend for future swarms.
-2. Record backend as a per-run launch-context choice for this swarm only -- do not change project policy.
-3. Discuss
-4. Back
-
-! If the operator chooses a backend whose probe status is unavailable or unknown, surface the remediation or uncertainty for that backend (for example, switch runtime, enable `spawn_subagent`, inject cloud credentials, or rerun the probe in the target environment) and stop before launch planning unless the operator explicitly records a per-run launch-context choice for a later environment where that backend will be available or verifiable.
-
-⊗ Treat probe availability as operator intent. A single probe-available backend is not a recommendation, default, or consent token; the operator must choose the intended backend in the interactive path when policy is unset.
-
-⊗ Add an interactive prompt to the headless / autonomous `task swarm:launch` path. Autonomous/headless launch remains fail-closed when neither `plan.policy.swarmSubagentBackend` nor an explicit launch-context backend choice is present; `scripts/swarm_launch.py` is the guardrail, not a prompt surface.
+⊗ Prompt the operator to select or persist a `swarmSubagentBackend` enum value for new work -- the routing surface (#1739) supersedes the enum; using the enum steers agents into a dead configuration path.
 
 #### Phase 0f -- Greenfield swarm-ready bootstrap (#1053)
 
@@ -429,9 +410,9 @@ Cross-references: `scripts/platform_capabilities.py` (#1557a), `scripts/github_a
 
 ! **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.
 
-~ **Policy surface (#1531a):** `plan.policy.swarmSubagentBackend` (set via `task policy:subagent-backend`) records the operator's preferred coding sub-agent provider for leaf workers; `task policy:subagent-backends` probes stable provider IDs and role capabilities. The policy complements — does not replace — per-dispatch provider selection at launch time.
+! **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.
 
-! **Operator model routing (#1739, supersedes the swarmSubagentBackend enum):** 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.
+~ **DEPRECATED — Policy surface (#1531a / #1891):** `plan.policy.swarmSubagentBackend` (set via `task policy:subagent-backend`) was the previous mechanism for recording the operator's preferred coding sub-agent provider. It is superseded by per-role operator model routing above (#1739). The enum and associated `task policy:subagent-backend(s)` tasks remain functional but deprecated; hard deletion is tracked by #1860. Use `task swarm:routing-set` instead.
 
 ! **Role boundaries for cheaper leaf agents:** Cheaper, high-context leaf agents are appropriate for **leaf implementation** work in isolated worktrees when vBRIEF scope is tight and gates (`task check`, Greptile review cycle) hold. The following roles MUST remain on strong, review-capable agents regardless of backend availability:
 

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

@@ -20,7 +20,7 @@ triggers:
 
 Session-start framework sync -- pull latest deft submodule updates, validate vBRIEF lifecycle structure, and detect stale origins.
 
-> **Canonical bootstrap / update path (post #1334 Epic, #1409):** Use the published Go installer binary (`deft-install` / platform-specific `install-*` from releases) to (re)bootstrap or update the framework payload. The canonical headless one-command refresh for an existing install is `deft-install --yes --upgrade --repo-root . --json` (drop `--json` for human-readable output) -- it actually replaces the framework payload in `.deft/core/` plus the manifest and AGENTS.md. After install the canonical `scripts/doctor.py --session --json` (or `task doctor`) runs automatically and, when the manifest sha shows the payload is stale, recommends that exact command. Legacy `run upgrade` / `task upgrade` are metadata-only acknowledgment (they do NOT replace the payload); git-submodule / `task framework:doctor` paths are back-compat only. See UPGRADING.md and the installer-doctor handoff in #1339/#1340.
+> **Canonical bootstrap / update path (#761 npm cutover):** Install and upgrade via npm: `npm i -g @deftai/directive` (install) or `npm i -g @deftai/directive@latest` (upgrade); Node >= 20 is required. For machines without Node, the frozen legacy Go installer (`deft-install` / platform-specific `install-*` from GitHub Releases) is a no-Node bootstrap bridge (#1912) -- migrate to npm once Node is available. After a session start the canonical `scripts/doctor.py --session --json` (`deft doctor` / `task doctor`) reports install + payload state and, when the manifest sha shows the payload is stale, recommends `npm i -g @deftai/directive@latest`. Legacy `run upgrade` / `task upgrade` are metadata-only acknowledgment (they do NOT replace the payload), and git-submodule / `task framework:doctor` paths are back-compat only -- the submodule sync in Phases 1-2 below is the legacy update flow, de-emphasized in UPGRADING.md / README. See UPGRADING.md and #761 / #1912.
 
 Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 

package/templates/agents-entry.md

@@ -62,9 +62,9 @@ Check what exists before doing anything else:
 
 ⊗ Self-report the session-start ritual as complete without a fresh `deft session:start` state, or bypass `deft verify:session-ritual` before implementation dispatch. Headless workers and CI MAY set `DEFT_SESSION_RITUAL_SKIP=1`; the verifier exits 0 but warns when the bypass hides a failure.
 
-`deft doctor` remains the install-integrity + toolchain + AGENTS.md managed-section freshness probe (#1308). When the managed-section is stale, the doctor points the operator at `deft agents:refresh` to regenerate AGENTS.md from `templates/agents-entry.md`. The canonical `scripts/doctor.py` (single owner post #1335/#1336) also detects payload staleness from the `<install>/VERSION` manifest and, when behind, emits the canonical headless upgrade command `deft-install --yes --upgrade --repo-root . --json` (#1339 / #1409). The installer itself calls `scripts/doctor.py --session --json` at the end of every run for the unified handoff.
+`deft doctor` remains the install-integrity + toolchain + AGENTS.md managed-section freshness probe (#1308). When the managed-section is stale, the doctor points the operator at `deft agents:refresh` to regenerate AGENTS.md from `templates/agents-entry.md`. The canonical `scripts/doctor.py` (single owner post #1335/#1336) also detects payload staleness from the `<install>/VERSION` manifest and, when behind, emits the canonical upgrade command `npm i -g @deftai/directive@latest` (#1339 / #1409 / #1912).
 
-**Canonical bootstrap / update path (#1339 #1340 #1409 Epic-5/6):** Use the published platform installer binary (from GitHub Releases) as the single deterministic entrypoint. For an existing install, the canonical headless refresh is `deft-install --yes --upgrade --repo-root . --json` (drop `--json` for human-readable output) -- it replaces the payload + manifest + AGENTS.md in one shot. Legacy `deft upgrade` / `run upgrade` are metadata-only acknowledgment (they do NOT replace the payload) and `deft relocate -- --confirm` is back-compat only; git-clone / submodule / legacy doctor surfaces are de-emphasized in UPGRADING.md / README / skills. Agent example: after running the installer command, start your session; the doctor output (or `deft doctor`) tells you the exact state and whether a re-install is needed for freshness.
+**Canonical bootstrap / update path:** Install and upgrade via npm: `npm i -g @deftai/directive` (install) or `npm i -g @deftai/directive@latest` (upgrade). Node ≥ 20 is required. For machines without Node, the frozen legacy Go installer is available from GitHub Releases as a no-Node bootstrap bridge (#1912) — migrate to npm once Node is available. Legacy `deft upgrade` / `run upgrade` are metadata-only acknowledgment and `deft relocate -- --confirm` is back-compat only; git-clone / submodule / legacy doctor surfaces are de-emphasized in UPGRADING.md / README / skills. Agent example: after installing, start your session; `deft doctor` tells you the exact state.
 `deft triage:welcome` emits the triage one-liner and, when state is incomplete, nudges the operator at `deft triage:welcome --onboard` (#1143). Default mode is non-interactive; the `--onboard` flag runs the 6-phase interactive ritual.
 
 ## Resume nudge (conditional, #1269)