cohorte 2.10.1 → 3.0.0-dev.1

package/core/commands/cohorte-ship.md

@@ -1,122 +0,0 @@
----
-model: sonnet
-description: At a SHIP verdict, dispatch the release agent to commit, push, and open the PR (with your confirmation).
-argument-hint: <feature_id>
----
-
-You are the **lead**. Ship feature **$ARGUMENTS**. This is the outward-facing gate.
-
-> Read `PIPELINE.md` §`vcs` (host, remote, default_branch, feature_branch_prefix) **and
-> §`release_notes`** — §2b below is skipped or required based on it, and skipping it when it is
-> required opens a PR that CI fails on arrival.
->
-> **Kanban** (SCHEMA.md §Kanban) is mirrored in **explicit steps** below, not as an afterthought:
-> §1 moves the card → **Ship**; §4 moves it → **Shipped** and writes the PR number. Both are one
-> call to `<core>/pipeline/scripts/kanban-move.sh auto …`, which resolves the board from the config itself and exits 0 with a
-> `kanban: <reason>` line when there is none. **Never decide "no board is configured" without running
-> it** — a ship session that inferred that, having opened neither the config nor `PIPELINE.md`, is
-> exactly how a merged feature's card stayed in "Ready to build". Do not skip §4's move either.
-
-## 1. Pre-flight (confirm before doing anything irreversible)
-
-- Confirm the latest `/cohorte-review` returned **SHIP** (no CRITICAL, no security). If not reviewed, or the
-  verdict was REVISE/BLOCK, stop and say so.
-- **Freshness gate** — the reviewed code must be exactly what ships. If the spec front-matter carries
-  `reviewed_base` + `reviewed_digest`, recompute
-  `git diff <reviewed_base> -- . ':(exclude)specs/' | sha256sum | cut -c1-16` (`shasum -a 256`
-  then the first 16 hex chars where there is no `sha256sum` — macOS) and compare to
-  `reviewed_digest`. **Match** ⇒ source unchanged since the SHIP verdict, proceed. **Mismatch** ⇒ source
-  (or the contract) was edited after review — the verdict is **stale**: stop and tell the human to re-run
-  `/cohorte-review $ARGUMENTS` before shipping. Missing fields (spec predates the gate) ⇒ skip, don't block.
-- **DoD gate (verify, don't tick — `/cohorte-review` owns the ticking).** Read `specs/$ARGUMENTS.md`
-  §`Acceptance criteria / DoD`; if any item is still `- [ ]`, list the open ones and ask the human to
-  confirm shipping anyway (they may be deferred on purpose — e.g. a UI item on a backend-only feature).
-  All `- [x]` ⇒ proceed silently.
-- Show `git status` + `git diff --stat`; confirm the branch is `<prefix>$ARGUMENTS`, where `<prefix>`
-  is `vcs.patch_branch_prefix` (falling back to `fix/` on a profile that predates the key) when the
-  spec front-matter carries `kind: patch`, and `vcs.feature_branch_prefix` otherwise. Resolve it once
-  here and pass the **literal** branch to §3's dispatch — the release agent must not re-derive it.
-- **Ask the human to confirm** they want to commit, push, and open the PR. Wait for yes.
-- After the yes: `<core>/pipeline/scripts/kanban-move.sh auto $ARGUMENTS ship`. Report what it
-  printed — `moved #…` or `kanban: <reason>` — never a guess about which happened.
-
-## 2. Mark the spec shipped (BEFORE dispatch, so it ships in the same commit)
-
-Once the human confirms, edit `specs/$ARGUMENTS.md` front-matter `status: → shipped` — **before**
-dispatching the release agent, so the status flip is part of the tree it commits (otherwise it lands
-uncommitted after the PR opens). Only flip after the human's "yes"; if they decline, leave it.
-
-## 2b. Write the release note (only if `release_notes.enabled` — same reason: it must ship in the commit)
-
-`release_notes.enabled: false` (or `tool: none`) ⇒ skip this section entirely, silently.
-
-Otherwise **you** write it — never the release agent, never the implementers. Picking the bump is
-project policy and the prose is outward-facing copy; both are the lead's, exactly like the contract.
-See SCHEMA.md §Release notes.
-
-- Write `<release_notes.dir>/<release_notes.filename>` (`<feature_id>` substituted), front-matter
-  carrying the **single** key `release_notes.anchor_package` and the chosen level, then the prose body
-  in `release_notes.language`.
-- **Choose the level** against `release_notes.guidance`, and refuse any level in
-  `release_notes.forbid_levels` (a `0.x` repo forbidding `major` declares the rupture `minor`).
-- **Ambiguous between two defensible levels?** State your reading in one line and **ask the human to
-  pick** before writing. A wrong bump becomes a published version number.
-- A `kind: patch` spec is a `patch` bump by default — that is what the level means. It is a default,
-  not a rule: a bug fix that changes documented behaviour is still a `minor`, and one that removes it
-  is still breaking. Say which you chose when it isn't `patch`.
-- The body describes what changed **for the user**, from the spec §1/§2 — no client names, no internal
-  paths, no exploitable attack vector, no file lists.
-- If the feature genuinely must move no version, use `release_notes.empty_cmd` instead. Prefer that to
-  skipping: the CI job wants a file, not a version.
-- Then say in one line which level you chose and why — this is the human's last chance to correct it
-  before it is committed.
-
-> **Why this is its own gate.** The requirement usually lives in the project's `<memory>`, which this
-> flow never reads. Skip it and everything below still "succeeds": commit, push, PR opened, kanban card
-> moved to **Shipped** — and CI red on a job nobody watched. The feature reads as shipped while being
-> unmergeable.
-
-## 3. Dispatch the `release` agent
-
-Spawn one agent (`subagent_type: release`, or the equivalent dispatch for this runtime):
-"Release feature `$ARGUMENTS` on branch
-`<the branch §1 resolved>`. Read `PIPELINE.md` §vcs first. Spec: `specs/$ARGUMENTS.md` (already
-`status: shipped` — stage it). Write conventional commit(s), push (no force), open the PR (use `gh` if
-`host: github` + available; else emit the compare URL + drafted PR body from `<core>/templates/pr-body.md`).
-Stage **all** the feature's changes including `specs/$ARGUMENTS.md` and, if `release_notes.enabled`, the
-release note at `<release_notes.dir>/<release_notes.filename>` — it is already written, stage it as-is and
-never author or edit one yourself. Never edit source, never force-push, never run migrations."
-
-## 4. Relay + move the card to Shipped (do not skip)
-
-Print the release agent's report: commit SHA(s), pushed branch, PR URL (or compare URL + drafted body).
-Confirm `specs/$ARGUMENTS.md` was committed as `status: shipped` (part of the release commit), and — if
-`release_notes.enabled` — that the release note is in that same commit
-(`git show <sha> --stat | grep <release_notes.dir>`). Missing ⇒ commit and push it now, before §5's CI
-watch, rather than letting the job go red.
-
-**Move the card to Shipped — required, and verify it actually moved.** Run
-`<core>/pipeline/scripts/kanban-move.sh auto $ARGUMENTS shipped --pr <num>`, which **appends the PR
-number** so the line reads `- [ ] <title> #$ARGUMENTS — PR #<num>`. Take `<num>` from the PR URL
-(`…/pull/13` ⇒ `13`); **always pass it when a PR was created** (the `gh` path) — it is what a
-board reader turns into a PR link. If only a compare URL was emitted (no PR yet), drop `--pr`.
-
-Then **read the script's own output**, which is the verification: `moved #$ARGUMENTS -> Shipped
-(PR #<num>)` means done, and a `kanban: <reason>` line means the mirror is off and says why. Both are
-exit 0 and they are not interchangeable — say which one you got. Only if it moved, confirm placement
-with a **grep for `#$ARGUMENTS`** on the board it named (with surrounding heading context —
-`grep -B20 '#$ARGUMENTS' | grep '^##'`, or an offset-limited Read around the match): exactly one card,
-under the `shipped` heading — never re-read the whole board into context.
-
-## 5. After the PR — CI gate + teardown
-
-- If `host: github` and `gh` is available, watch the PR's checks (`gh pr checks <url> --watch`) and
-  report the result — the human merges only on green. A red check ⇒ back to `/cohorte-fix $ARGUMENTS`,
-  **except** a red `release_notes.ci_job`: that one is this command's own miss, not a code finding —
-  write the note per §2b, commit, push, and re-watch. Never send a missing release note through `/cohorte-fix`.
-- Once the human confirms the PR is **merged**: if `isolation.enabled`, propose the teardown —
-  `scripts/remove-feature.sh $ARGUMENTS` (add `--drop-db` to also drop the feature db; kept by
-  default). It removes the worktree, deletes the merged branch, frees the slot. Never run it before
-  the merge is confirmed, and only with the human's go-ahead (the gate will ask anyway).
-- Feature closed — **recommend a `/clear`** before starting the next one; nothing from this session
-  is needed again (spec `shipped`, PR merged, board updated).

package/core/commands/cohorte-spec.md

@@ -1,101 +0,0 @@
----
-description: Interactively capture a frozen feature spec (or apply a review return) into specs/<id>.md.
-argument-hint: [paste brainstorm return OR review report]
----
-
-You run the **spec** step in the main thread — interactive, with the human. Pasted input below:
-
-**$ARGUMENTS**
-
-> Read `PIPELINE.md` first: `contract` (mechanism/path — so §5 names the right schema types),
-> `design.enabled` (whether §8 matters), and §Conventions. Use `specs/_template.md` as the section list.
->
-> **Decision journal** (SCHEMA.md §Decisions): read `specs/_decisions.md` §Live if it exists — one
-> line per standing decision, so it is cheap. It is the ONLY place the project's transverse rules
-> live; a spec that contradicts one silently un-decides it. Absent ⇒ nothing to honour yet.
->
-> **Kanban** (SCHEMA.md §Kanban): when the spec opens, run
-> `<core>/pipeline/scripts/kanban-move.sh auto <feature_id> spec --title "<human title>"`; on freeze
-> (`status: frozen`, Mode A), the same call with `ready`. `auto` resolves the board from the config itself and exits 0 with a
-> `kanban: <reason>` line when there is none — so **never decide "no board is configured" without
-> running it**.
-
-Detect the mode from the pasted content:
-
-## Mode A — new spec (input is a brainstorm return, or empty)
-
-1. If empty, look for a staged brainstorm return first — `specs/reports/*-brainstorm.md` (where
-   `/cohorte-brainstorm` stages its output); one match ⇒ read it and confirm, several ⇒ ask which. None ⇒
-   ask the human to paste the return (or describe the feature) and wait.
-2. Derive a `feature_id` (kebab-case slug). Confirm it.
-2b. **Size budget — a spec is a contract, not a novel.** Target ≤ ~300 lines; hard-think at 500.
-   Every implementer re-reads the whole spec on every first build, so each extra line is paid
-   `surfaces × dispatches` times. If the feature genuinely needs more, that's the signal it is TWO
-   features: propose a split (e.g. `<id>-core` + `<id>-admin`, each independently shippable, the
-   second consuming the first's contract) and let the human pick. Trim the usual bloat before
-   writing: exhaustive UI walkthroughs (the design brief carries those), restated conventions
-   (PIPELINE.md carries those), speculative edge cases nobody asked for.
-3. Walk the human through each section of `specs/_template.md`, **section by section**, with focused
-   questions. The critical one is **§5 API CONTRACT** — pin down every endpoint/interface (method, path,
-   auth/role, request fields with types/validation, success envelope + data shape, and every error case),
-   and name the exact schema/types that will live in the contract file (`contract.path/<id>.<ext>` in the
-   profile's `mechanism`). Don't move on until frontend and backend could each build from it with zero
-   further questions. _If `contract.enabled` is false, capture the interface precisely in prose instead._
-4. Capture the **design brief** content (only if `design.enabled` / the feature has UI): screens,
-   states, components, responsive notes — it will be authored to `specs/design/<id>.md` in step 6;
-   spec §8 carries only a short summary + the pointer `> full brief: specs/design/<id>.md` (so
-   non-design surfaces never re-read the full brief on every dispatch).
-4b. **New-surface heads-up.** If the feature clearly introduces an area no existing `surfaces[].path`
-   owns (a new service/app/top-level module), note it in the spec (a line in the relevant task section:
-   `> needs new surface: <proposed key/path>`). Don't render agents here — `/cohorte-build` §1.5 auto-reconciles
-   it. This is just so the human isn't surprised when `/cohorte-build` proposes a new agent.
-5. When the human validates, **freeze**: write `specs/<id>.md` (`status: frozen`, front-matter filled).
-   Create the file — do not ask the human to. **Postcondition:** `grep -q '^status: frozen' specs/<id>.md`
-   — if it fails the freeze didn't land; fix it before pointing the human at `/cohorte-build`.
-5b. **Record the transverse decisions — the journal, not a summary.** Walk what the interview settled
-   and keep ONLY the decisions that **outlive this feature**: a rule the next spec would otherwise
-   re-litigate or contradict (auth model, id/naming scheme, where a kind of state lives, an error
-   convention, a deliberate non-goal that binds future features). Typical yield: **0–3 lines**; zero
-   is a normal, healthy outcome for a feature that decided nothing new — never invent lines to fill
-   the section. Append them to `specs/_decisions.md` §Live (create the file from
-   `<core>/templates/decisions.template.md` on first use), each exactly:
-   `- <YYYY-MM-DD> · <area> · <decision> — because <reason> · <feature_id>`
-   - **Never** duplicate what §5, `PIPELINE.md` §Conventions or the code already states — the journal
-     carries the *non-obvious rule*, not the feature's content. A line that restates a spec section is
-     a line every future `/cohorte-spec` pays for and learns nothing from.
-   - **Contradicting an existing line** is allowed but never silent: tell the human which line this
-     feature overrides, get their go-ahead, then append the new line with
-     `· supersedes <YYYY-MM-DD> <area>` and move the old one to `## Superseded`.
-   - Append with one `>>` Bash call, not a full-file rewrite (the file is append-only, and reading it
-     back to re-write it is the one way to make a bounded file expensive).
-6. Author the **design brief** — `specs/design/<id>.md`, rendered via
-   `<core>/templates/design-brief.md`.
-   _Only if `design.enabled` / the feature has UI; skip entirely for a backend-only feature._
-   - **Write it to `specs/design/<id>.md`** (the authored artifact, versioned with the spec; spec §8
-     holds the summary + pointer). Create the file — do not ask the human to. Keep it in the
-     `specs/design/` subfolder, **not** `specs/<id>....md`: the `specs/*.md` glob that drives the
-     kanban backfill and `/cohorte-doctor` is non-recursive, so a brief in the subfolder never gets mistaken
-     for a spec (no phantom card, no bogus stage). Overwrite it on every freeze.
-   - Print ONLY the path + a one-line summary — never echo the brief into chat (it would sit in this
-     session's history; echo it only if the human asks). Tell the human: copy it from
-     `specs/design/<id>.md` into the design tool (if any — typically a fresh design project for this
-     feature), then run `/cohorte-build <id>` and hand its design gate the resulting page link(s) — a full
-     `https://claude.ai/design/p/<projectId>?file=<file>` link carries its own project + page, no
-     profile change needed. (They can also paste the links into the spec's `design_files` themselves.)
-     **Recommend a `/clear` before `/cohorte-build`** — the frozen spec + `specs/design/<id>.md` are the whole
-     handoff.
-
-## Mode B — review return (input is a REVIEW REPORT)
-
-1. Read the report — pasted as input, or (whenever nothing is pasted) read from
-   `specs/reports/<id>.md`, where `/cohorte-review` stages its last report. Identify `feature_id` from its
-   header; open `specs/<id>.md`.
-2. Append each finding to the spec's **`## Remediation`**, one per line:
-   `- [ ] <severity> · <file:line> · <spec-violation|quality|security|complexity> · <concrete fix>`
-   (Keep prior items; add the new round under a dated/numbered subheading.)
-3. If a finding implies the **contract** must change, update §5 and flag it so the lead re-authors the
-   contract file.
-4. Set `status: in-review`. Tell the human to run `/cohorte-build <id>` to re-dispatch fresh agents.
-   **Recommend a `/clear` before `/cohorte-build`** — the spec is the whole handoff.
-
-In both modes the spec is the single source of truth; agents are stateless and read only it + the diff.

package/core/commands/cohorte-update-pipeline.md

@@ -1,165 +0,0 @@
----
-model: sonnet
-description: Refresh this runtime's global or project-local pipeline core, then reconcile the project's generated files — /cohorte-init-pipeline stays one-time.
-argument-hint: [path-to-local-checkout]
----
-
-You are the **pipeline updater**. Refresh the installed pipeline core to the latest version of the pipeline
-repo. The installer's `--update` mode never touches generated files: `PIPELINE.md`, rendered surface agents,
-`gate-config.json`, `settings.json`, and the filled `<config>` are all preserved.
-YOU then bring those generated files up to the new core yourself (§3.5) — additively, never clobbering
-the human's choices — so `/cohorte-init-pipeline` never needs re-running for an upgrade.
-
-## 1. Detect the install scope + current version
-
-- **Global** install ⇒ `<core>/pipeline/VERSION` exists. **Bundled** ⇒ this repo's
-  `<core>/pipeline/VERSION` exists. (Both can exist; prefer the bundled one when running inside such a
-  repo, and update both if the human wants.)
-- **Never migrate a repo between bundled and global mode on your own.** Updating means refreshing the
-  core *in its current mode*. Only migrate (e.g. delete a bundled core in favor of the global one) if
-  the human explicitly asks — and confirm before deleting anything, since it rewrites the repo's
-  committed `.claude/` and the `pipeline.json` pointer teammates rely on.
-- Read the VERSION file(s) — a semver like `0.1.0`, possibly suffixed `(abc1234)` for from-main
-  installs, or a bare commit hash on old cores. If missing, note "unknown (pre-versioning)".
-
-## 2. Run the update
-
-<!-- cohorte:if runtime:codex -->
-Preserve the existing install scope and explicitly select Codex:
-
-- Local source checkout supplied: `node <path>/bin/cli.js update --runtime=codex [--global]`.
-- Published release: `npm i -g cohorte@latest`, then `cohorte update --runtime=codex [--global]`.
-
-Expand `[--global]` to `--global` only for a global core; otherwise omit it. Run from the target
-project, or pass its path. Keep the user's normal `CODEX_HOME`. The global core and generic
-agents may be shared, but reconciliation always writes surface agents in this project's
-`.codex/agents/*.toml`.
-<!-- cohorte:else -->
-- If `$ARGUMENTS` is a path to a local checkout of the pipeline repo (contains `core/` + `install.sh`),
-  run from there — useful when iterating on the pipeline itself:
-
-  ```sh
-  sh <path>/install.sh --update --global     # global core
-  sh <path>/install.sh --update              # bundled core of the current repo
-  ```
-
-- Otherwise use the published npm package (preferred — installs the latest tagged release):
-
-  ```sh
-  npm i -g cohorte@latest              # the CLI itself, refreshed
-  cohorte update --global              # global core
-  cohorte update                       # bundled core of the current repo
-  ```
-
-  If `cohorte` is not on PATH, `npx cohorte@latest update [--global]` runs the same thing
-  without installing anything.
-
-- If npm is unavailable, fall back to piping the installer from the repo's latest `main`:
-
-  ```sh
-  curl -fsSL https://raw.githubusercontent.com/TheBidouilleAgency/cohorte/main/install.sh | sh -s -- --update --global
-  # bundled:  … | sh -s -- --update
-  ```
-
-  (The piped installer clones the repo itself; `-s --` forwards the flags.)
-<!-- cohorte:endif -->
-
-## 3. Report old → new
-
-Re-read the VERSION file(s) and print `old → new`. If unchanged, say the core was already up to date.
-
-**Sync the pointer — in BOTH modes.** If this repo has a `<state>/pipeline.json` whose `core_version`
-differs from the core you just installed, rewrite that one field (leave every other field untouched)
-and tell the human to commit it. In **bundled** mode the installer already did it; in **global** mode
-**nothing does** — the installer refreshes one shared core and cannot know which repos point at it,
-so before 1.2.5 the field simply drifted forever (a repo on a current core still claiming `1.0.0`).
-`/cohorte-doctor` check 1 requires the pointer to be coherent with the VERSION file, so a drifted field reads
-as a broken install when nothing is broken.
-
-Then print **What's new**: read the installed `<core>/pipeline/CHANGELOG.md` and show the entries
-between the old and new versions (most recent first). File absent ⇒ the old core predates 0.1.14 —
-skip silently.
-
-## 3.5 Reconcile this repo's generated files
-
-Only when the current repo has a `PIPELINE.md`: run the **Reconcile procedure** from the installed
-`pipeline/SCHEMA.md` §Reconcile — top up the profile's machine block with new fields at their defaults
-(one batched question set for any genuinely new human decision — e.g. choosing a `retrieval` provider,
-or the **quiet command variants**: `test_quiet_cmd`/`lint_quiet_cmd` + `commands.test_quiet`/
-`lint_quiet`, proposing the detected bridled forms per §Output discipline; `gate.preflight` tops up
-silently at its defaults), re-render the surface agents from the current `implementer.template.md`
-(this refreshes each agent's **baked §Conventions slice** — required after any hand-edit of the
-profile's prose).
-<!-- cohorte:if runtime:codex -->
-Write surface agents as `.codex/agents/*.toml`, validate TOML, and preserve explicit Codex model
-choices (legacy Anthropic aliases mean inheritance). Patch `<state>/gate-config.json` and
-verify the selected scope's hook covers shell and `spawn_agent`/`Agent`; do not duplicate it.
-Verify `<fixed-agents>/profile-reader.toml` and the other shipped generic agents. Workflows are
-unavailable on Codex and their absence is expected. Reconcile MCP in `.codex/config.toml` using
-SCHEMA.md §Code retrieval, preserving unrelated configuration and checking actual connectivity.
-If a previous install wrote this project's agents globally, compare ownership/content before
-moving them locally; never remove unrelated global agents or overwrite modified local copies.
-Remove project-only `CODEX_HOME` workarounds only after verifying native discovery. Do not copy
-authentication into the repository. Report what changed and anything still unverified.
-<!-- cohorte:else -->
-Additively patch `settings.json`/`gate-config.json` (including the `preflight`
-block and the workflow-agent `allow` entries from init step 5), and run any newly-added capability's
-wiring (e.g. Serena's project-scope `claude mcp add`). Verify the refreshed core actually carries
-`<core>/workflows/` + `agents/profile-reader.md` — missing means the update half-ran: re-run the
-installer. Even when no capability is new, **re-run the retrieval provider's
-health check** (SCHEMA.md §Code retrieval: CLI resolvable from PATH, `.mcp.json` entry present —
-upgrading a bare `serena` entry to the PATH-proof launcher form, `.serena/` gitignored, server
-actually connected) and repair whatever fails — wiring that worked at
-init can rot (PATH changes, uninstalls, hand-edits). Report what was reconciled; if nothing was
-missing, say so. This is why `/cohorte-init-pipeline` never needs re-running for a core upgrade.
-<!-- cohorte:endif -->
-
-Four of the §Reconcile steps matter specifically here:
-
-- **Local-artifact hygiene** (§Reconcile step 8): gitignore + untrack the pipeline's runtime files
-  (`<state>/preflight.ok`, `<state>/pipeline-metrics.jsonl`, `specs/reports/`). A tracked
-  `preflight.ok` — what every pre-2.0.0 install ends up with once a release agent stages `.claude/` —
-  makes the phase gate ask on every single review dispatch, so fix it here and say so.
-
-- **Spec-template top-up** (§Reconcile step 7): `specs/_template.md` was seeded at install and never
-  refreshed since, so add the front-matter fields the current `templates/spec.template.md` has and the
-  repo's copy lacks — and drop `loop_pass`/`loop_phase`, retired with `/cohorte-loop` in 2.2.0 —
-  front-matter only, never the body.
-
-- **Global config seed** (§Reconcile step 5): if `<config>` is absent, seed it
-  from the template so the kanban + shared-vault config has a home. Never clobber an existing filled
-  file. Report what was seeded. Then **scrub the retired `telemetry:` block** if the existing file
-  still has one (every install seeded before 2.3.0 does) — one targeted Edit deleting the block and
-  its comment header, nothing else touched. That capability was removed in 2.3.0, sender included,
-  so the block is dead config: nothing reads it, and an `enabled: true` left sitting in a file the
-  human may open reads as though data were still leaving the machine. Say you removed it.
-- **Kanban sync** (§Reconcile step 6): resolve this project's board with
-  `<core>/pipeline/scripts/kanban-move.sh --check` — it prints either the board path or the exact
-  missing link. **Not linked** → offer to link/create a board (confirm the vault + `<folder>/Tasks.md`,
-  write the `boards` entry, create the board file per §Kanban). **Linked** → verify the board file
-  exists (recreate if the human confirms) and its columns match `kanban.columns` (repair drift). Either
-  way, run the §Kanban **full sync/backfill** from `specs/*.md` — one
-  `kanban-move.sh auto <id> <stage>` per spec, `<stage>` from the status mapping — this is what adds
-  every already-developed feature to the board and repositions cards to match each spec's `status`.
-  Report cards added / moved / already-correct. Skip silently if `kanban.enabled` is false and the
-  human doesn't want to turn it on.
-- **A project renamed since its last update loses its board silently** — `boards` is keyed by the
-  profile `name`, so a `name:` edit orphans the old entry and no lookup matches the new one. When
-  `--check` finds no entry for `<name>` but `boards` holds exactly one other key whose board file
-  exists, say so and offer to re-key it rather than creating a second board.
-
-## 4. Tell the human the follow-ups
-
-- **Restart / reload the coding-agent session** so it picks up updated commands, agents, and any
-  newly-registered MCP server.
-- **Other repos using the global core:** their core is already fresh, but reconcile is per-repo — run
-  `/cohorte-update-pipeline` inside each (it will skip the already-done core update and just reconcile).
-<!-- cohorte:if runtime:codex -->
-- **Commit** the reconciled `PIPELINE.md`, `.codex/agents/*.toml`, `.codex/config.toml` if added,
-  and versioned `<state>` files. Never commit auth or session state.
-<!-- cohorte:else -->
-- **Commit** the reconciled files (`PIPELINE.md`, `.claude/`, `.mcp.json` if added) so teammates get them.
-<!-- cohorte:endif -->
-- The kanban config is global and user-scoped
-  (`<config>`) — never committed. The core update never touches it; only the
-  reconcile above seeds the file and writes kanban board links (into that global file, not the repo).