wood-fired-tasks 2.0.6 → 2.1.1

package/AGENTS.md

@@ -95,8 +95,10 @@ Treat these as off-limits unless your task explicitly requires touching them.
 ## Task-orchestration skills (`/tasks:*`)
 
 This repo ships agent skills under `skills/tasks/` that automate the
-plan→execute→audit loop over a wood-fired-tasks project. They install to
-`~/.claude/commands/tasks/` via `install.sh`. The orchestration set:
+plan→execute→audit loop over a wood-fired-tasks project. They are copied to
+`~/.claude/commands/tasks/` by `wood-fired-tasks setup` (the published-npm
+install path; the old root `install.sh` is a deprecated shim that just delegates
+to `setup`). The orchestration set:
 
 | Skill | Status | One-line purpose |
 |---|---|---|

package/CHANGELOG.md

@@ -13,6 +13,72 @@ vulnerabilities, supply-chain pinning) are always called out under `Security`.
 
 _No changes yet._
 
+## [v2.1.1] - 2026-06-09
+
+### Fixed
+- **`tasks self-update` now re-syncs bundled skills/agents into `~/.claude`**
+  (PR #57, task #934). The command previously only ran
+  `npm i -g wood-fired-tasks@latest`, so a release that added or changed a
+  skill (first hit: v2.1.0's `/tasks:set-models`) left self-updaters with
+  stale `~/.claude/commands/tasks/` while reporting success — violating the
+  README's "keep it up to date" contract. After a clean install, self-update
+  now runs the same idempotent `copySkills()`/`copyAgents()` sync `tasks
+  setup` uses, reports what it refreshed, and exits non-zero with a
+  `tasks setup` remediation hint if the sync itself fails. A contract test
+  pins the default sync to setup's own implementation so the update and
+  onboarding paths cannot drift.
+
+## [v2.1.0] - 2026-06-09
+
+### Added
+- **Configurable Task Models** (PR #55, project 39 — 17 tasks). Route the
+  `/tasks:loop` worker (`execution`), verifier (`validation`), and planning
+  agents — decompose / audit / integration-auditor (`planning`) — to different
+  Anthropic models via a per-project + database-default `model_policy`.
+  - **Policy model:** six power categories (`minimal…maximum`, a 1:1 relabel of
+    the WSJF jobSize Fibonacci tiers) plus an `auto` sentinel; per-role
+    `byCategory` routing with a uniform `byCategory → constant → default →
+    null` slot walk, two-layer per-slot merge (`project ?? global`). Migration
+    016 adds `projects.model_policy` and the `app_settings` singleton.
+  - **Runtime model catalog:** live discovery via the Anthropic Models API
+    (set the optional `ANTHROPIC_API_KEY`) with a static fallback marked
+    `stale: true` — the read path never throws.
+  - **MCP:** four new tools — `list_models`, `resolve_model`,
+    `get_model_defaults`, `set_model_defaults` — on **both** the stdio and
+    remote servers (tool count 27 → 31).
+  - **REST:** `GET /models`, `GET|PUT /settings/model-policy`,
+    `GET /projects/:id/resolve-model`, and `model_policy` on project
+    create/update/get.
+  - **CLI:** `tasks models list`, `tasks project-set-models <id>`, and
+    `tasks settings-set-models` — the set-models commands fetch-merge-write
+    client-side, so incremental invocations never destroy earlier role config.
+  - **Skills:** a `/tasks:set-models` interview (one four-stage checklist
+    question per role, fixed option order, catalog-only options) and a
+    canonical, telemetry-grounded **Default Model Map** in `loop-shared.md` §R
+    that makes `auto` resolution deterministic (execution
+    sonnet/sonnet/opus/fable across the category ladder, validation
+    haiku/sonnet/opus/opus, planning opus). Optional
+    `--execution-model` / `--validation-model` / `--planning-model` run-arg
+    overrides ride LOOP-RUN frontmatter for replay provenance.
+
+### Fixed
+- **Test suite no longer launches the developer's real browser.**
+  `setup.remote.test.ts` drove the device flow with `openBrowser: true`, so
+  every `npm test` on a DISPLAY-set desktop spawned `xdg-open` at a mock
+  server. `openBrowser()` now honors `WFT_NO_BROWSER`, set for every test via
+  `vitest.setup.ts`.
+- **Documentation counts drift.** README / `docs/INTERFACES.md` / `docs/MCP.md`
+  had stale tool (27 vs 31), route (52/45 vs 59/52), and CLI command (42 vs 45)
+  counts, plus a stale "model tools are stdio-only" claim from before remote
+  parity landed; the `interfaces-counts` drift guard now covers the model-tools
+  file so the next addition cannot dodge it.
+
+### Security
+- No security-relevant changes. The new `/models`, `/settings/model-policy`,
+  and `resolve-model` routes inherit the standard `/api/v1` auth chain; the
+  optional `ANTHROPIC_API_KEY` is only ever sent to the Anthropic Models API
+  and is never echoed in responses or logs.
+
 ## [v2.0.6] - 2026-06-08
 
 ### Added
@@ -763,7 +829,9 @@ and the task/project/dependency/comment/subtask domain model.
 - Task hierarchy (subtasks), dependency service, comments, time estimates
   (phase 06).
 
-[Unreleased]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v2.0.0...HEAD
+[Unreleased]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v2.1.1...HEAD
+[v2.1.1]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v2.1.0...v2.1.1
+[v2.1.0]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v2.0.6...v2.1.0
 [v2.0.0]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v1.18.2...v2.0.0
 [v1.15]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v1.14...v1.15
 [v1.14]: https://github.com/Wood-Fired-Games/wood-fired-tasks/compare/v1.13...v1.14

package/README.md

@@ -15,8 +15,8 @@ Wood Fired Tasks is open-source coordination infrastructure for fleets of AI cod
 **Key capabilities:**
 
 - `/tasks:*` skill files implementing the plan→decompose→loop→audit lifecycle (ship as Claude Code slash commands; the recipes are vendor-neutral)
-- MCP server with 27 tools for native agent integration (local SQLite or remote HTTP modes) + cross-platform installers (Linux/macOS and Windows)
-- REST API with 52 route handlers across `src/api/routes/` (1 public `/health`; the rest authenticated; a single instance serves up to 45 — OIDC-disabled stubs are mutually exclusive with the live OIDC routes) and a `tasks` CLI with 42 commands
+- MCP server with 31 tools for native agent integration (local SQLite or remote HTTP modes) + a single cross-platform npm install (Linux/macOS/Windows)
+- REST API with 59 route handlers across `src/api/routes/` (1 public `/health`; the rest authenticated; a single instance serves up to 52 — OIDC-disabled stubs are mutually exclusive with the live OIDC routes) and a `tasks` CLI with 45 commands
 - Atomic task claiming with optimistic locking + workflow automation (parent auto-complete, dependency auto-unblock) for multi-agent coordination
 - Real-time Server-Sent Events (SSE) for task/project change notifications
 - SQLite database with WAL mode, FTS5 full-text search, and automatic migrations
@@ -62,25 +62,58 @@ Coding agents (Claude Code, Cursor, Gemini, Codex, and others) should start with
 2. [docs/AGENT_CONTEXT.md](docs/AGENT_CONTEXT.md) — the vendor-neutral context contract.
 3. [.agent-context.json](.agent-context.json) — machine-readable manifest of canonical files and their budgets.
 
-Vendor-specific files (`CLAUDE.md`, `.cursor/`, `.gemini/`, `.codex/`) are adapters and MUST NOT carry unique facts — see `docs/AGENT_CONTEXT.md` §6.
+A root [`llms.txt`](llms.txt) (the emerging agent-discovery convention) also
+points here, and both it and the curated agent docs ship inside the npm tarball.
+Vendor-specific files (`CLAUDE.md`, `.cursor/`, `.gemini/`, `.codex/`) are
+adapters and MUST NOT carry unique facts — see `docs/AGENT_CONTEXT.md` §6.
 
-## Quick Start
+## Install & run modes
 
-Install from npm — **no git clone, no build, no admin rights.** The global
-install ships the server, the `tasks` CLI, the MCP bridge, and the `/tasks:*`
-skills together; `setup` wires them into Claude Code and `serve` runs the API.
+**One install, no git clone, no build, no admin rights.** Installing from npm
+ships the API server, the `tasks` CLI, the MCP bridge, the `wft-router`
+automation daemon, and the `/tasks:*` skills together — the *same* install backs
+every way you might run it.
 
 ```bash
-# 1. Install the CLI globally (never needs sudo — see the admin-free note below)
-npm i -g wood-fired-tasks
+npm i -g wood-fired-tasks      # never needs sudo — see the admin-free note below
+```
+
+This puts three identical CLI entry points on your PATH — `wood-fired-tasks`,
+`tasks`, and the short alias `wft` — plus `wft-router`. Requires **Node ≥ 22**;
+works on Linux, macOS, and Windows. (There is no `curl | bash` bootstrap and the
+old `install.sh` / `install.ps1` git-clone scripts are retired — npm is the one
+supported install path.)
+
+### Pick how to run it
+
+The install is the same everywhere; what differs is *where the database and API
+server live*. Pick the row that matches your environment:
+
+| Run mode | Use it when | After installing, run | Guide |
+|----------|-------------|-----------------------|-------|
+| **Solo / local** | You want a tracker on your own machine, backed by a local SQLite DB. | `wood-fired-tasks setup` → `wood-fired-tasks serve` | [Local setup](docs/SETUP.md#frictionless-install-npm--no-clone) |
+| **Background service** | Keep the local API running across logout/reboot (user-scoped, admin-free). | `wood-fired-tasks service install` | [Background service](docs/SETUP.md#background-service-keep-the-server-running) |
+| **Remote client** | A shared server already exists — point this machine at it. | `wood-fired-tasks setup --remote <url> --token wft_pat_…`  *(or `tasks login`)* | [Setup modes](docs/SETUP.md#setup-modes) |
+| **Self-hosted server** | Stand up the shared API for a team to point at. | `deploy/install.sh` on the host | [Self-hosting & upgrades](docs/SETUP.md#self-hosting-and-upgrades) |
+| **Multi-OS fleet** | Many Windows/Linux/macOS machines on one shared backlog. | self-host once, then `setup --remote` per client | [Multi-OS fleet](docs/SETUP.md#multi-os-client-fleet-one-shared-on-prem-server) |
+
+> **New here? Start with Solo / local** — three commands and the `/tasks:*`
+> workflow is live in Claude Code. Nothing is wasted if you move to a shared
+> server later: the modes coexist (a Local stdio entry and a Remote bridge entry
+> can both live in `~/.claude.json` at once).
 
-# 2. Wire it into Claude Code: merges the local stdio MCP server into
-#    ~/.claude.json and copies the /tasks:* skills + subagents — idempotent,
-#    no manual JSON editing.
+### Solo / local — fastest start
+
+After `npm i -g wood-fired-tasks` (above), two commands wire it into Claude Code
+and run the server:
+
+```bash
+# Merge the local stdio MCP server into ~/.claude.json and copy the /tasks:*
+# skills + subagents — idempotent, no manual JSON editing.
 wood-fired-tasks setup
 
-# 3. Run the API server. Migrates the OS app-data DB on start and listens on
-#    127.0.0.1:3000 (set HOST=0.0.0.0 to expose on the LAN).
+# Run the API. Migrates the OS app-data DB on start; listens on 127.0.0.1:3000
+# (set HOST=0.0.0.0 to expose on the LAN).
 wood-fired-tasks serve
 ```
 
@@ -110,21 +143,16 @@ user scope.
 
 ```bash
 wood-fired-tasks service install   # Linux: user-scoped systemd unit (admin-free)
-wood-fired-tasks self-update       # npm i -g wood-fired-tasks@latest (no sudo)
+wood-fired-tasks self-update       # npm i -g @latest + re-sync skills (no sudo)
 ```
 
-**Point at a shared remote server** instead of running it locally:
-
-```bash
-wood-fired-tasks setup --remote https://tasks.example.com --token wft_pat_…
-```
-
-This writes a URL-only `wood-fired-tasks-remote` MCP entry (proxying every tool
-to the REST API) and persists the validated PAT to the CLI credentials file —
-the same file `tasks login` writes; the bridge reads its bearer token from there
-at runtime (the PAT is never stored in `~/.claude.json`). Omit `--token` to run
-the interactive device-flow / manual-PAT onboarding instead. For a full
-Windows/Linux/macOS fleet on one on-prem server, see
+**Point at a shared remote server** (the *Remote client* mode above) with
+`wood-fired-tasks setup --remote https://tasks.example.com --token wft_pat_…`: it
+writes a URL-only `wood-fired-tasks-remote` MCP entry (proxying every tool to the
+REST API) and persists the validated PAT to the CLI credentials file — the same
+file `tasks login` writes; the bridge reads its bearer token from there at
+runtime, never from `~/.claude.json`. Omit `--token` for the interactive
+device-flow / manual-PAT onboarding. Full fleet recipe:
 [Multi-OS client fleet](docs/SETUP.md#multi-os-client-fleet-one-shared-on-prem-server).
 
 Browse the bundled guides from anywhere with `wood-fired-tasks docs list` /
@@ -284,7 +312,7 @@ flowchart TB
 | Interface | Access Method | Transport | Auth |
 |-----------|--------------|-----------|------|
 | REST API | HTTP endpoints | Port 3000 (configurable) | PAT (`Authorization: Bearer`) or OIDC session cookie |
-| CLI | `tasks` command | HTTP to API server (most cmds); direct SQLite for offline ops (`backup`, `doctor`, `stats`, `db-check`, `completed`) | `API_KEY` env var (holds a PAT, sent as `Authorization: Bearer`) |
+| CLI | `tasks` command | HTTP to API server (most cmds); direct SQLite for offline ops (`backup`, `doctor`, `stats`, `db-check`, `completed`) | Credentials file from `tasks login` / `setup --remote --token` (preferred); else `API_KEY` env or `--token` flag — each a PAT sent as `Authorization: Bearer` |
 | MCP Server | stdio JSON-RPC (local) or HTTP (remote variant) | MCP client integration | None for stdio (local access); Bearer PAT for remote |
 | Slack subprocess | Slack Socket Mode | WebSocket to Slack | Slack signing secret + bot token |
 
@@ -426,7 +454,7 @@ The OIDC/session/PAT surface backing the auth model lives partly outside the tas
 
 A device-authorization flow under `/auth/device*` (`GET /auth/device`, `POST /auth/device/code`, `POST /auth/device/token`, `POST /auth/device/verify`) supports headless PAT minting. When OIDC is **not** configured, the `/auth/*` and `/auth/device/*` routes are replaced by disabled-stub handlers (HTTP 501), so they exist in both modes but only one set is live per instance. When `SESSION_COOKIE_SECRET` is set, top-level HTML web routes (`GET /login`, `GET /me`, `GET /me/tokens`, `POST /me/tokens/:id/revoke`) are also served for the browser sign-in UI.
 
-This brings the full registered surface to **52 route handlers** under `src/api/routes/` — derived by counting `fastify.<verb>(` / `server.<verb>(` registrations across the route files (excluding tests). A single running instance serves up to **45** of them: the 7 OIDC-disabled stub handlers are mutually exclusive with the live OIDC `/auth/*` routes.
+This brings the full registered surface to **59 route handlers** under `src/api/routes/` — derived by counting `fastify.<verb>(` / `server.<verb>(` registrations across the route files (excluding tests). A single running instance serves up to **52** of them: the 7 OIDC-disabled stub handlers are mutually exclusive with the live OIDC `/auth/*` routes.
 
 For detailed API documentation including request/response schemas, see [docs/API.md](docs/API.md).
 
@@ -434,11 +462,12 @@ For detailed API documentation including request/response schemas, see [docs/API
 
 The `tasks` command provides terminal access to all task operations.
 
-Every `tasks <command>` example below is shorthand for `npm run cli -- <command>`
-(everything after `--` is forwarded verbatim). Running `npm link` once from the
-project root is **optional** — it installs a global `tasks` command so the
-examples work verbatim from any directory. See [docs/CLI.md](docs/CLI.md) for the
-full reference.
+If you installed from npm (`npm i -g wood-fired-tasks`), the `tasks`, `wft`, and
+`wood-fired-tasks` commands are already on your PATH and every `tasks <command>`
+example below works verbatim. Working from a clone instead? Use
+`npm run cli -- <command>` (everything after `--` is forwarded verbatim), or run
+`npm link` once from the project root to install a global `tasks`. See
+[docs/CLI.md](docs/CLI.md) for the full reference.
 
 **Global Flags:**
 - `--json` - Output in machine-readable JSON format
@@ -508,7 +537,7 @@ full reference.
 
 | Command | Description |
 |---------|-------------|
-| tasks login | OIDC sign-in; caches a PAT to the local credentials file |
+| tasks login | OIDC device-flow sign-in, or `--token <pat>` for a manual PAT (required for remote non-`https` servers); writes a PAT to the local credentials file |
 | tasks logout | Revoke the active PAT and clear the local credentials |
 | tasks whoami | Show the currently authenticated identity |
 
@@ -531,7 +560,7 @@ For detailed CLI documentation including all options and examples, see [docs/CLI
 
 ## MCP Tools Summary
 
-The MCP server exposes 27 tools and 1 resource for Claude Code integration — Task (9), Project (5), Comment (3), Dependency (3), Health (1), Topology (1), Wait (1), and WSJF (4). A second entry point (`npm run mcp:remote`) exposes the REST-backed tool surface (also 27 tools at full parity; `wait_for_unblock` resolves over the SSE event stream rather than the in-process EventBus) for clients running on a different host than the bugs API — see [docs/MCP.md#remote-mcp-server](docs/MCP.md#remote-mcp-server).
+The MCP server exposes 31 tools and 1 resource for Claude Code integration — Task (9), Project (5), Comment (3), Dependency (3), Health (1), Topology (1), Wait (1), WSJF (4), and Model (4). A second entry point (`npm run mcp:remote`) exposes the same 31 tools REST-backed (the four Model tools proxy `GET /models`, `GET /projects/:id/resolve-model`, and `GET|PUT /settings/model-policy`; `wait_for_unblock` resolves over the SSE event stream rather than the in-process EventBus) for clients running on a different host than the bugs API — see [docs/MCP.md#remote-mcp-server](docs/MCP.md#remote-mcp-server).
 
 ### Task Tools (9)
 
@@ -600,6 +629,15 @@ The MCP server exposes 27 tools and 1 resource for Claude Code integration — T
 | rescore_project | (Mutation) Deterministically rescore a project's scored tasks against the current value charter; skips locked components; returns evaluated/changed/skipped-locked counts |
 | wsjf_health | Non-blocking degeneracy/pitfall linter for a project's WSJF state (empty findings ⇔ healthy) |
 
+### Model Tools (4)
+
+| Tool | Description |
+|------|-------------|
+| list_models | Runtime-discovered Claude model catalog (Anthropic Models API, TTL-cached); `stale: true` when serving the static fallback |
+| resolve_model | Resolve the model for a pipeline role (`execution` \| `validation` \| `planning`) for a project, optionally task-scoped for jobSize→category routing; returns `{ model }` or `null` (inherit the session model) |
+| get_model_defaults | Read the database-wide default `ModelPolicy` (`null` when unset) |
+| set_model_defaults | (Mutation) Set or clear the database-wide default `ModelPolicy` |
+
 ### Resources (1)
 
 | URI | Description |
@@ -732,66 +770,39 @@ variables) lives in [docs/SETUP.md → Environment Variables](docs/SETUP.md#envi
 ### Key Commands
 
 ```bash
-# Development mode with hot reload
-npm run dev
-
-# Run tests (~2600+ tests)
-npm test
-
-# Watch mode for tests
-npm run test:watch
-
-# Build TypeScript
-npm run build
-
-# Run CLI in development (without building)
-npm run cli -- <command>
-
-# Run MCP server in development
-npm run mcp:dev
+npm run dev              # REST API, hot reload      npm run build   # typecheck + compile
+npm test                 # full suite (~3,700+)      npm run mcp:dev # MCP server (stdio)
+npm run cli -- <command> # run the CLI in-tree       npm run lint    # biome check
 ```
 
+The canonical command table (focused tests, migrations, quality gate) lives in
+[AGENTS.md → Essential commands](AGENTS.md#essential-commands).
+
 ### Database
 
-SQLite with better-sqlite3 driver, WAL mode, and automatic migrations via Umzug. Fifteen migration files in `src/db/migrations/`:
-
-1. `001-initial-schema.ts` — projects, tasks, task_tags (plus the tasks_fts FTS5 virtual table and sync triggers)
-2. `002-task-hierarchy-and-dependencies.ts` — adds `parent_task_id` to tasks and creates the `task_dependencies` table
-3. `003-comments-and-estimates.ts` — creates the `task_comments` table and adds `estimated_minutes` to tasks
-4. `004-claim-protocol.ts` — version field, claimed_at, idempotency_keys table
-5. `005-backlogged-status.ts` — adds `backlogged` to the status CHECK constraint (rebuilds tasks table; preserves FTS triggers)
-6. `006-slack-channel-subscriptions.ts` — `slack_channel_subscriptions` table for the Slack notifier
-7. `007-completed-at.ts` — `completed_at` column on tasks (set on transition into `done`, backfilled from `updated_at`)
-8. `008-identity-tables.ts` — `users` and `api_tokens` tables (OIDC/PAT identity)
-9. `009-parallel-fk-columns.ts` — parallel `*_user_id` FK columns alongside the legacy TEXT identity columns
-10. `010-identity-uniqueness-indexes.ts` — uniqueness indexes on user identity (oidc_sub, email)
-11. `011-acceptance-criteria.ts` — `acceptance_criteria` column on tasks
-12. `012-verification-evidence.ts` — `verification_evidence` column on tasks (verifier verdict + checks)
-13. `013-wsjf-fields.ts` — adds the per-task WSJF columns: four Fibonacci-constrained component columns (`wsjf_value`, `wsjf_time_criticality`, `wsjf_risk_opportunity`, `wsjf_job_size`) plus five JSON metadata columns (`wsjf_evidence`, `wsjf_locked`, `wsjf_source`, `wsjf_classifications`, `wsjf_features`); all-four-or-none invariant enforced at the DTO boundary
-14. `014-value-charter.ts` — adds the nullable `value_charter` JSON column on `projects` (the per-project Business-Value reference frame)
-15. `015-wsjf-audit.ts` — creates the three append-only audit tables: `wsjf_rescore_run`, `wsjf_score_history` (one immutable row per score write), and `project_charter_history` (full charter snapshot per interview version)
+SQLite with the better-sqlite3 driver, WAL mode, and automatic forward
+migrations via Umzug. The 15 migration files in `src/db/migrations/` are the
+canonical, self-documenting schema history — from `001-initial-schema` (projects,
+tasks, FTS5) through the identity tables (`008`–`010`, OIDC/PAT), acceptance
+criteria + verification evidence (`011`–`012`), and the WSJF columns, value
+charter, and append-only audit tables (`013`–`015`). Read the files directly for
+exact DDL; [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) covers how they fit
+together.
 
 ### Testing
 
-~2600+ tests covering:
-- Service layer unit tests
-- API route integration tests (all endpoints)
-- MCP tool tests (all tools)
-- CLI command tests
-- Event system tests (EventBus, SSEManager, events API)
-- Claim protocol tests (including 20-agent concurrency)
-- Workflow engine tests (auto-complete, auto-unblock, cascade depth)
-- Skill file validation tests
+~3,700+ vitest tests span the service layer, every API route, every MCP tool,
+the CLI, the event system (EventBus/SSEManager), the claim protocol (including
+20-agent concurrency), the workflow engine (auto-complete/auto-unblock/cascade
+depth), and skill-file validation. Run `npm test`; see
+[docs/WORKFLOWS.md](docs/WORKFLOWS.md) for focused-run recipes.
 
 ### Code Quality Roadmap
 
-The current TypeScript service quality baseline and the prioritized
-uplift roadmap (lint/format gate, stricter compiler flags, architecture
-guardrails, migration safety, CI/release automation) live in
-[docs/CODE_QUALITY_ROADMAP.md](docs/CODE_QUALITY_ROADMAP.md). It is the
-source of truth for the `Code Quality Uplift Roadmap` project tracked
-in the bugs database and should be linked from future PR/release
-quality checklist work.
+The TypeScript quality baseline and the prioritized uplift roadmap (lint/format
+gate, stricter compiler flags, architecture guardrails, migration safety,
+CI/release automation) live in
+[docs/CODE_QUALITY_ROADMAP.md](docs/CODE_QUALITY_ROADMAP.md).
 
 ## Integrations
 
@@ -813,7 +824,7 @@ slash-command reference, channel subscription model, error handling.
 ### Claude Code (MCP)
 
 The shipped MCP server registers as a stdio MCP target in `~/.claude.json`
-and exposes 27 tools plus the `/tasks:*` skill files. See
+and exposes 31 tools plus the `/tasks:*` skill files. See
 [docs/MCP.md](docs/MCP.md) and the "Claude Code Integration" section in
 [docs/SETUP.md](docs/SETUP.md#claude-code-integration).
 
@@ -837,12 +848,11 @@ guarantee.
 
 ## Release Verification
 
-Before publishing to npm, run `npm run pack:check` (alias for
-`npm pack --dry-run`) and inspect the printed file list. Confirm that
-`dist/` JS + `.d.ts` files, `LICENSE`, `README.md`, `CHANGELOG.md`, and
-`SECURITY.md` are present, and that `src/`, `.env*`, `data/*.db`,
-`.planning/`, and test files are **absent**. The package uses an explicit
-`files` allowlist in `package.json` — adjust it there if the output drifts.
+Before publishing, `npm run pack:check` (`npm pack --dry-run`) prints the tarball
+file list — confirm `dist/` + `.d.ts`, `LICENSE`, `README.md`, `CHANGELOG.md`,
+`SECURITY.md` are present and `src/`, `.env*`, `data/*.db`, `.planning/`, and
+tests are absent. The `files` allowlist in `package.json` controls this. Full
+release procedure: [docs/RELEASE.md](docs/RELEASE.md).
 
 ## License
 

package/SECURITY.md

@@ -14,11 +14,11 @@ security updates. Older tags are provided as-is.
 | Version           | Supported          |
 | ----------------- | ------------------ |
 | `main` (HEAD)     | :white_check_mark: |
-| `v1.18` (latest)  | :white_check_mark: |
-| `v1.0` – `v1.17`  | :x:                |
+| `v2.1.1` (latest) | :white_check_mark: |
+| `v1.0` – `v2.0.6` | :x:                |
 
 "Latest" tracks whichever tag is most recent on GitHub; at the time of
-writing that is `v1.18`. If you are reading this on an older checkout,
+writing that is `v2.1.1`. If you are reading this on an older checkout,
 verify the current latest release via
 `git tag --sort=-creatordate | head -1` or the GitHub Releases page.
 

package/dist/api/api-response.d.ts

@@ -115,6 +115,44 @@ export declare function parseProjectResponse(payload: unknown, endpoint: string)
         interview_version: number;
         updated_at: string;
     } | null | undefined;
+    model_policy?: {
+        execution?: {
+            byCategory?: {
+                minimal?: string | undefined;
+                light?: string | undefined;
+                moderate?: string | undefined;
+                strong?: string | undefined;
+                heavy?: string | undefined;
+                maximum?: string | undefined;
+            } | undefined;
+            constant?: string | undefined;
+            default?: string | undefined;
+        } | undefined;
+        validation?: {
+            byCategory?: {
+                minimal?: string | undefined;
+                light?: string | undefined;
+                moderate?: string | undefined;
+                strong?: string | undefined;
+                heavy?: string | undefined;
+                maximum?: string | undefined;
+            } | undefined;
+            constant?: string | undefined;
+            default?: string | undefined;
+        } | undefined;
+        planning?: {
+            byCategory?: {
+                minimal?: string | undefined;
+                light?: string | undefined;
+                moderate?: string | undefined;
+                strong?: string | undefined;
+                heavy?: string | undefined;
+                maximum?: string | undefined;
+            } | undefined;
+            constant?: string | undefined;
+            default?: string | undefined;
+        } | undefined;
+    } | null | undefined;
 };
 /** Convenience: validate a task list (envelope or bare array). */
 export declare function parseTaskListResponse(payload: unknown, endpoint: string): {
@@ -174,6 +212,44 @@ export declare function parseProjectListResponse(payload: unknown, endpoint: str
             interview_version: number;
             updated_at: string;
         } | null | undefined;
+        model_policy?: {
+            execution?: {
+                byCategory?: {
+                    minimal?: string | undefined;
+                    light?: string | undefined;
+                    moderate?: string | undefined;
+                    strong?: string | undefined;
+                    heavy?: string | undefined;
+                    maximum?: string | undefined;
+                } | undefined;
+                constant?: string | undefined;
+                default?: string | undefined;
+            } | undefined;
+            validation?: {
+                byCategory?: {
+                    minimal?: string | undefined;
+                    light?: string | undefined;
+                    moderate?: string | undefined;
+                    strong?: string | undefined;
+                    heavy?: string | undefined;
+                    maximum?: string | undefined;
+                } | undefined;
+                constant?: string | undefined;
+                default?: string | undefined;
+            } | undefined;
+            planning?: {
+                byCategory?: {
+                    minimal?: string | undefined;
+                    light?: string | undefined;
+                    moderate?: string | undefined;
+                    strong?: string | undefined;
+                    heavy?: string | undefined;
+                    maximum?: string | undefined;
+                } | undefined;
+                constant?: string | undefined;
+                default?: string | undefined;
+            } | undefined;
+        } | null | undefined;
     }[];
     total: number;
     limit: number;

package/dist/api/routes/models/index.d.ts

@@ -0,0 +1,14 @@
+import { FastifyPluginAsyncZod } from 'fastify-type-provider-zod';
+import { z } from 'zod';
+/** The `{ models, stale }` envelope returned by GET /models. */
+export declare const ModelCatalogResponseSchema: z.ZodObject<{
+    models: z.ZodArray<z.ZodObject<{
+        id: z.ZodString;
+        display_name: z.ZodString;
+        family: z.ZodString;
+        created_at: z.ZodString;
+    }, z.core.$strip>>;
+    stale: z.ZodBoolean;
+}, z.core.$strip>;
+declare const modelsRoutes: FastifyPluginAsyncZod;
+export default modelsRoutes;

package/dist/api/routes/models/index.js

@@ -0,0 +1,48 @@
+import { z } from 'zod';
+/**
+ * Configurable Task Models (Task 13) — GET /api/v1/models
+ *
+ * Exposes the runtime-discovered Claude model catalog (task #917's
+ * `model-catalog.service`) over REST so the remote MCP proxy / dashboard /
+ * `set-models` interview can enumerate the available models. The 200 body is
+ * `{ models, stale }` — identical to the service's `ModelCatalog` and the
+ * stdio MCP `list_models` tool's structured output.
+ *
+ * `stale: true` signals the catalog was served from the static fallback (no
+ * ANTHROPIC_API_KEY, non-OK Models API response, or a network error). The
+ * service NEVER throws from `list()`, so this route always returns 200.
+ *
+ * Auth: inherits the standard `/api/v1` auth chain (the parent plugin is
+ * mounted inside the `/api/v1` scope that wires `authPlugin`). No custom guard.
+ */
+/** One discovered model, mirroring `ModelCatalogEntry` from the catalog service. */
+const ModelCatalogEntrySchema = z.object({
+    id: z.string(),
+    display_name: z.string(),
+    family: z.string(),
+    created_at: z.string(),
+});
+/** The `{ models, stale }` envelope returned by GET /models. */
+export const ModelCatalogResponseSchema = z.object({
+    models: z.array(ModelCatalogEntrySchema),
+    stale: z.boolean(),
+});
+const modelsRoutes = async (fastify) => {
+    fastify.get('/', {
+        schema: {
+            tags: ['models'],
+            description: 'List the available Claude model catalog (runtime-discovered via the ' +
+                'Anthropic Models API, TTL-cached). Returns `{ models, stale }`; ' +
+                '`stale: true` means the static fallback was served (no API key / ' +
+                'unreachable Models API).',
+            response: {
+                200: ModelCatalogResponseSchema,
+            },
+        },
+    }, async (_request, reply) => {
+        const catalog = await fastify.modelCatalogService.list();
+        return reply.send(catalog);
+    });
+};
+export default modelsRoutes;
+//# sourceMappingURL=index.js.map

package/dist/api/routes/projects/index.js

@@ -3,6 +3,7 @@ import { CreateProjectSchema, UpdateProjectSchema } from '../../../schemas/task.
 import { ProjectResponseSchema, ProjectListPaginatedResponseSchema } from './schemas.js';
 import dependencyGraphRoutes from './dependency-graph.js';
 import topologyRoutes from './topology.js';
+import resolveModelRoutes from './resolve-model.js';
 import projectWsjfRoutes from './wsjf.js';
 // Pagination query schema for GET /projects. Mirrors task list bounds.
 const QueryProjectListSchema = z.object({
@@ -78,6 +79,11 @@ const projectRoutes = async (fastify) => {
     // MCP `topology_check` proxy tool. Registered as a child plugin alongside
     // dependency-graph so its colocated `schema:` block lives in its own file.
     await fastify.register(topologyRoutes);
+    // GET /:id/resolve-model — model-policy resolver over REST (task #926),
+    // backing the remote MCP `resolve_model` proxy tool. Registered as a child
+    // plugin alongside topology so its colocated `schema:` block lives in its
+    // own file.
+    await fastify.register(resolveModelRoutes);
     // WSJF 4.5 (#645): GET /:id/charter-history + GET /:id/rescore-runs.
     // Registered as a child plugin alongside topology so its colocated `schema:`
     // blocks live in their own file.

package/dist/api/routes/projects/resolve-model.d.ts

@@ -0,0 +1,3 @@
+import { FastifyPluginAsyncZod } from 'fastify-type-provider-zod';
+declare const resolveModelRoutes: FastifyPluginAsyncZod;
+export default resolveModelRoutes;