chore: bump CLI version v0.3.1

Author: ivklgn

.archcore/plugin/cli-path-index.plan.md

@@ -40,7 +40,7 @@ What the hook actually needs from each grep is: *which document files mention th
 
 ### What the CLI already produces
 
-`.sync-state.json` today carries the relation manifest (source/target/type triples) plus some metadata. The file is written by `archcore sync` and read by `archcore validate` / other subcommands, and serves as the git-committed truth for relations. Readers treat unknown top-level keys as opaque, so additions are backward-compatible. The plugin's MCP server reads from the same file when listing relations.
+`.sync-state.json` today carries the relation manifest (source/target/type triples) plus some metadata. The file is written by `archcore sync` and read by `archcore doctor` / other subcommands, and serves as the git-committed truth for relations. Readers treat unknown top-level keys as opaque, so additions are backward-compatible. The plugin's MCP server reads from the same file when listing relations.
 
 Adding `path_index` on this same write path is a pure extension: same sync cadence, same atomic write, same git-tracked artifact. No new commands, no new files.
 
@@ -159,7 +159,7 @@ The CLI indexes against the *same* root list the plugin uses by default — this
 - Thread the active roots list through `internal/config/settings.go` — resolve priority `.archcore/settings.json` → CLI flag → default.
 - Update the manifest serializer to include `path_index`; ensure existing manifest fields stay byte-identical when `path_index` is absent (unchanged behaviour when the indexer is disabled).
 - Add `--no-path-index` CLI flag for emergency disablement. Operators can drop the index without a CLI downgrade.
-- Update `archcore validate` to accept (but not require) `path_index` and lightly check schema (`schema=="v1"` means required keys present). Never hard-fail on index anomalies — the index is advisory, manifest correctness is load-bearing.
+- Update `archcore doctor` to accept (but not require) `path_index` and lightly check schema (`schema=="v1"` means required keys present). Never hard-fail on index anomalies — the index is advisory, manifest correctness is load-bearing.
 
 ### Phase CLI-3 — Tests and docs
 
@@ -170,7 +170,7 @@ The CLI indexes against the *same* root list the plugin uses by default — this
 
 ### Phase CLI-4 — Release coordination (when plugin consumer ships)
 
-- Cut CLI release (target `0.1.8` from current `0.1.7` — minor bump, additive feature, no breaking changes). Confirm by running `archcore validate` against a plugin repo with the *previous* CLI's `.sync-state.json` — must pass unchanged.
+- Cut CLI release (target `0.1.8` from current `0.1.7` — minor bump, additive feature, no breaking changes). Confirm by running `archcore doctor` against a plugin repo with the *previous* CLI's `.sync-state.json` — must pass unchanged.
 - Plugin consumer ships in a later release (not v0.4.0); coordination with that release's planning owns the `bin/CLI_VERSION` bump.
 - Announce in CLI CHANGELOG; plugin-side changelog entry appears only when the consumer ships.
 
@@ -244,7 +244,7 @@ Upgrade order therefore does not matter — both directions are safe. The target
 
 1. `archcore sync` on a fresh repo produces a `.sync-state.json` with a valid `path_index` object conforming to the schema above, verifiable via `jq '.path_index.schema' == "v1"`.
 2. `archcore sync` on a pre-existing repo (without `path_index` in the prior manifest) does not alter any relation data; only the new `path_index` field appears.
-3. `archcore validate` passes on both pre-migration and post-migration manifests.
+3. `archcore doctor` passes on both pre-migration and post-migration manifests.
 4. `archcore sync --no-path-index` produces a manifest without `path_index` even if one was present before; idempotent.
 5. Benchmark in `internal/pathindex/pathindex_bench_test.go` shows build time ≤ 50 ms for a 100-document synthetic corpus on commodity hardware.
 6. Index size ≤ 5% of the cumulative body size of included documents on a real-world test repo.

.archcore/plugin/codex-host-support.idea.md

@@ -1,6 +1,6 @@
 ---
 title: "Codex CLI Host Support — Promote from P2 Future to Implemented"
-status: draft
+status: accepted
 tags:
   - "architecture"
   - "codex"

.archcore/plugin/codex-host-support.plan.md

@@ -1,6 +1,6 @@
 ---
 title: "Codex CLI Host Support Implementation Plan"
-status: draft
+status: accepted
 tags:
   - "codex"
   - "multi-host"

.archcore/plugin/codex-host-support.prd.md

@@ -1,6 +1,6 @@
 ---
 title: "PRD: Codex CLI Host Support"
-status: draft
+status: accepted
 tags:
   - "codex"
   - "multi-host"

.archcore/plugin/context-skill-implementation.plan.md

@@ -27,6 +27,8 @@ Deferred (non-blocking, tracked here for follow-up):
 - CLI MCP-instructions nudge to steer models toward the skill when appropriate.
 - `/archcore:align` push-mode command — **superseded** by the shipped hook + /context skill. See `code-alignment-intent-skill.idea.md` (rejected).
 
+> **Note (post-merge cleanup, 2026-05-07):** This plan originally referenced `/archcore:status` and `/archcore:graph` in its routing matrix and anti-regression checklist. Both were removed/merged after the plan landed (see `merge-review-status-remove-graph.adr.md`): `/archcore:status` is now the default short mode of `/archcore:review`; `/archcore:graph` was deleted entirely. The references below have been updated accordingly so the doc remains a useful reference.
+
 ## Goal
 
 Ship `/archcore:context` as the user-facing pull-mode entry point for JTBD #1 ("repo-alignment at coding time"), backed by the CLI's `search_documents` MCP tool. Close the JTBD-implementation gap for on-demand code-area lookup and session pickup, without touching PreToolUse hooks (deferred to Phase 2).
@@ -50,7 +52,7 @@ Frontmatter (final, post-prompt-engineer review):
 
 - `name: context`
 - `argument-hint: "[file, directory, or topic; leave empty for current-focus pickup]"`
-- `description`: trigger phrases include "what rules apply to X", "before I refactor Z", "pick up where we left off", "where is the payments work right now", "what was I working on in X", "show me the decisions/rules/specs for X". DO-NOT list routes creation/planning/audits/graph/status away.
+- `description`: trigger phrases include "what rules apply to X", "before I refactor Z", "pick up where we left off", "where is the payments work right now", "what was I working on in X", "show me the decisions/rules/specs for X". DO-NOT list routes creation/planning/audits away.
 
 Body sections:
 - **Classify scope** — empty/whitespace → pickup; contains `/` OR is an existing repo directory → path; otherwise → topic.
@@ -109,15 +111,14 @@ Two or three fixture `.archcore/` repos under `tests/fixtures/context/`. Run the
 - No section header is rendered when its group is empty (other than the classification footer).
 - Classification footer is always present.
 
-**Routing precision (manual test matrix — 14 cases)**
+**Routing precision (manual test matrix — 13 cases)**
 - "what rules apply to src/payments/" → `/archcore:context` path mode
 - "before I touch the billing flow" → `/archcore:context` path or topic
 - "pick up where I left off" → `/archcore:context` pickup mode
 - "where is the payments work right now" → `/archcore:context` pickup
 - "show me the decisions for src/payments/" → `/archcore:context` path
-- "how many docs do we have" → `/archcore:status` (NOT context)
-- "draw the graph" → `/archcore:graph` (NOT context)
-- "review docs health" → `/archcore:review` (NOT context)
+- "how many docs do we have" → `/archcore:review` (NOT context — short dashboard mode)
+- "review docs health" → `/archcore:review --deep` (NOT context)
 - "check for stale docs" → `/archcore:actualize` (NOT context)
 - "document the auth module" → `/archcore:capture` (NOT context)
 - "we decided on PostgreSQL" → `/archcore:decide` (NOT context)
@@ -142,9 +143,9 @@ Two or three fixture `.archcore/` repos under `tests/fixtures/context/`. Run the
 
 1. `skills/context/SKILL.md` present, frontmatter parses (name, description, argument-hint).
 2. No YAML frontmatter errors across all modified SKILL.md files (lint: plugin test suite).
-3. Manual routing test — run 14 trigger phrases above in Claude Code + Cursor, confirm activation / non-activation matches expectations.
+3. Manual routing test — run 13 trigger phrases above in Claude Code + Cursor, confirm activation / non-activation matches expectations.
 4. Manual skill execution — `/archcore:context src/payments/`, `/archcore:context "money rounding"`, `/archcore:context` on a non-trivial `.archcore/` repo; verify output shape.
-5. Anti-regression — run `/archcore:status`, `/archcore:graph`, `/archcore:review`, `/archcore:actualize` to confirm siblings still work after edits.
+5. Anti-regression — run `/archcore:review`, `/archcore:actualize` to confirm sibling intent skills still work after edits.
 6. README renders cleanly on GitHub (no broken code fences, valid markdown).
 7. Plan doc (this file) links in the graph (relations to jtbd-alignment-analysis, code-alignment-intent-skill, inverted-invocation-policy, pre-code-context-injection, intent-skill-implementation).
 8. No direct writes to `.archcore/` — all doc ops via MCP.

.archcore/plugin/zero-content-onboarding.idea.md

@@ -9,7 +9,7 @@ tags:
 
 ## Idea
 
-A new user installs the plugin on an existing repo. `.archcore/` is empty. SessionStart loads zero documents. They open a file in `src/api/` — `check-code-alignment` greps an empty knowledge base and injects nothing. `/archcore:context src/api/` returns "no documents reference this path." `/archcore:status` reports "0 documents."
+A new user installs the plugin on an existing repo. `.archcore/` is empty. SessionStart loads zero documents. They open a file in `src/api/` — `check-code-alignment` greps an empty knowledge base and injects nothing. `/archcore:context src/api/` returns "no documents reference this path." `/archcore:review` reports "0 documents."
 
 The plugin gives no signal that anything has changed. The user does not know what to do next, sees no value, and uninstalls or forgets. **All the machinery that delivers JTBD #1 / #2 / #3 silently no-ops on a fresh repo until the user manually populates `.archcore/` — but nothing in the plugin guides them through that first step.**
 
@@ -31,7 +31,7 @@ This already removes the "I installed it and nothing happens" failure mode. It d
 
 A new Layer 1 intent skill that runs an explicit first-time onboarding flow:
 
-1. **Detect state.** If `.archcore/` already has ≥3 documents, inform the user it's not their first session and route them to `/archcore:context` or `/archcore:status`. Otherwise proceed.
+1. **Detect state.** If `.archcore/` already has ≥3 documents, inform the user it's not their first session and route them to `/archcore:context` or `/archcore:review`. Otherwise proceed.
 2. **One question.** "What's the most important convention or decision in this repo that you'd want a future agent to know about?" — single open question, one round trip.
 3. **Route to existing skill.** Based on the answer's shape:
     - "we always do X" → route to `/archcore:standard` (ADR → rule → guide chain)

bin/CLI_VERSION

@@ -1 +1 @@
-0.3.0
+0.3.1