Sync docs: 15->16 MCP tools, add init+branch to REPO_STRUCTURE, add smriti_close_branch to tools table

ARCHITECTURE.md

@@ -349,7 +349,7 @@ Surfaces:
   own reasoning in their own context, using their own LLM provider. Smriti is
   their shared memory, not their runtime.
 - **MCP server** (`cli/smriti_cli/mcp_server.py`, entry point `smriti-mcp`) —
-  the same surface wrapped as 15 MCP tools for hosts that speak the Model
+  the same surface wrapped as 16 MCP tools for hosts that speak the Model
   Context Protocol natively (Claude Code, Cursor, Windsurf). Stdio transport.
   Each tool is a thin shim: build a `SmritiClient`, call one or two methods,
   run the result through an existing formatter, return markdown. Feature

DECISIONS.md

@@ -286,7 +286,7 @@ agent surface narrow and composable.
 
 After shipping the CLI and the MCP server, the next friction item from real
 agent sessions was not about the tools — it was about agents not reaching for
-them. An agent dropped into a Smriti-enabled project with 15 MCP tools
+them. An agent dropped into a Smriti-enabled project with 16 MCP tools
 available would call a few of them reactively, miss the reflex of reading
 state at session start, and quietly fall back to writing `HANDOFF.md` under
 context pressure because markdown handoff files are what the training data

README.md

@@ -150,7 +150,7 @@ So Smriti now has four surfaces on the same core:
 
 1. **The chat UI**: how a human reads, steers, and debugs shared reasoning state. Still the primary way I inspect what is happening in a project.
 2. **A CLI** (`smriti`): how a coding agent reads and writes the same reasoning state from a shell tool loop. Works from any host that can run a shell command. `smriti state` is multi-branch by default — it shows main plus active non-main branches plus a lightweight divergence signal when agents disagree on decisions.
-3. **An MCP server** (`smriti-mcp`): the same surface, wrapped as 15 MCP tools for hosts that speak the Model Context Protocol natively (Claude Code, Cursor, Windsurf). Agents call `smriti_state`, `smriti_create_checkpoint`, `smriti_fork`, etc. as structured tool calls instead of shelling out.
+3. **An MCP server** (`smriti-mcp`): the same surface, wrapped as 16 MCP tools for hosts that speak the Model Context Protocol natively (Claude Code, Cursor, Windsurf). Agents call `smriti_state`, `smriti_create_checkpoint`, `smriti_fork`, etc. as structured tool calls instead of shelling out.
 4. **An agent skill pack**: a versioned markdown instruction file installed into an agent host's project directory (`.claude/skills/smriti/SKILL.md` for Claude Code, `AGENTS.md` for Codex). The skill pack teaches the agent *when* and *why* to use Smriti's tools — when to checkpoint, critically when NOT to checkpoint, when to fork, how to detect drift, and the explicit anti-patterns to reject. Install it once per project with `smriti skills install <target>` and Smriti becomes the agent's default reflex instead of a tool it has to remember to call.
 
 One project, one Smriti Space, multiple agents reading from and writing to the same structured state. Agents don't need to know about each other. They just need to (a) know how to read the current state and write a checkpoint at each inflection point, which is what the skill pack teaches, and (b) see each other's work on that state, which is what multi-branch `smriti state` makes visible.

REPO_STRUCTURE.md

@@ -99,9 +99,10 @@ smriti/
 │   ├── pyproject.toml          Installable as `pip install -e ./cli`
 │   │                             → `smriti` + `smriti-mcp` on PATH
 │   ├── smriti_cli/
-│   │   ├── main.py             argparse dispatcher: space, state, checkpoint,
-│   │   │                         fork, restore, compare, claim, skills
-│   │   ├── mcp_server.py       FastMCP server (15 tools, stdio transport)
+│   │   ├── main.py             argparse dispatcher: init, space, state,
+│   │   │                         checkpoint, fork, restore, compare,
+│   │   │                         branch, claim, skills
+│   │   ├── mcp_server.py       FastMCP server (16 tools, stdio transport)
 │   │   ├── client.py           SmritiClient HTTP wrapper (includes claims)
 │   │   ├── formatters.py       Continuation-oriented markdown renderers
 │   │   │                         (multi-branch, active claims, divergence)

cli/README.md

@@ -44,7 +44,7 @@ Run Smriti as a local MCP server so agents inside Claude Code, Cursor, or Windsu
 
 Restart the host and the `smriti_*` tools appear in the tool picker.
 
-**Available tools (15):**
+**Available tools (16):**
 
 | Tool | Purpose |
 |---|---|
@@ -60,6 +60,7 @@ Restart the host and the `smriti_*` tools appear in the tool picker.
 | `smriti_restore` | Print a specific checkpoint as a continuation brief |
 | `smriti_fork` | Fork a new session from an existing checkpoint |
 | `smriti_compare` | Structured diff between two checkpoints |
+| `smriti_close_branch` | Mark a branch as integrated, abandoned, or active |
 | `smriti_claim` | Declare a work claim before starting work (pre-work intent visibility) |
 | `smriti_claim_done` | Mark a work claim as done or abandoned |
 | `smriti_install_skill` | Return the Smriti agent skill pack for a host (`claude-code` / `codex`) |
@@ -80,7 +81,7 @@ Restart the host and the `smriti_*` tools appear in the tool picker.
 mcp dev smriti_cli.mcp_server:mcp
 ```
 
-Opens a browser-based tool explorer connected over stdio. Click through `tools/list` (expect 15 entries, all prefixed `smriti_`) and try each tool interactively.
+Opens a browser-based tool explorer connected over stdio. Click through `tools/list` (expect 16 entries, all prefixed `smriti_`) and try each tool interactively.
 
 ## Installing the Smriti skill pack
 
@@ -252,7 +253,7 @@ Surfaces possible contradictions, hidden assumptions, already-resolved open ques
 
 A second agent (different process, different model family, different session) starts fresh. It runs `smriti state my-project` — or calls `smriti_state` from inside its MCP host — and receives the same brief the first agent just wrote. There is no prose handoff, no pasting markdown between windows, no re-explaining. The agent picks up where the previous one left off and continues working.
 
-This is the core loop. Rounds 3 through 5 of dogfood testing exercised exactly this pattern across Claude Code ↔ Codex handoffs, same-family Codex ↔ Codex handoffs, and a round 5 end-to-end test that drove all 15 MCP tools from a host-less Python client. The shape holds.
+This is the core loop. Rounds 3 through 5 of dogfood testing exercised exactly this pattern across Claude Code ↔ Codex handoffs, same-family Codex ↔ Codex handoffs, and a round 5 end-to-end test that drove all 16 MCP tools from a host-less Python client. The shape holds.
 
 ## Branching when you want to explore an alternative