@rness/cli 0.8.1 → 0.9.1

package/README.md

@@ -29,6 +29,7 @@ Inside a workspace, every `rness` delegates to the copy pinned in
     rness logout
     rness context [--scope <name>] [--json]
     rness validate
+    rness mcp
 
 `create` never runs inside a workspace. `add`, `sync` and `create` ask for
 confirmation in a terminal; pass `-y`/`--yes` in scripts. `sync --check`
@@ -61,7 +62,8 @@ the files a given agent needs, for the agents the team declares in
   `../../.rness` in `permissions.additionalDirectories`, so a session in the
   repository reads the context repository without a prompt. Claude Code
   applies it once the repository has been trusted interactively. Verified
-  with Claude Code 2.1.284 on 2026-09-29.
+  with Claude Code 2.1.284 on 2026-09-29. Each clone also gets `.mcp.json`,
+  which registers the MCP server; see "MCP server".
 - rness owns values, not files: what is missing is added, nothing else is
   touched, and a file it cannot parse is reported, never rewritten.
   `sync --check` and `validate` report a missing value. Removing an agent
@@ -69,6 +71,39 @@ the files a given agent needs, for the agents the team declares in
 - Other agents (Codex, Cursor, GitHub Copilot) read the `AGENTS.md` block;
   `sync` refuses an agent it has no target for.
 
+### MCP server
+
+    rness mcp      # started by the agent over stdio, not by hand
+
+A local, read-only MCP server over the workspace's `.rness/`, for an agent to
+find what applies to the repository it works in and where a subject was
+decided:
+
+| Tool                                   | Returns                                                                                                                                             |
+| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `rness_context({ scope? })`            | the scope of the working directory (or the one named) and what applies to it: standards, decisions, specifications, plans — id, status, title, path |
+| `rness_list({ collection, status? })`  | every document of a collection, across scopes, optionally of one status                                                                             |
+| `rness_read({ path })`                 | one file of `.rness/`, 256 KiB at most; nothing outside it                                                                                          |
+| `rness_search({ query, collection? })` | the documents that match, most matching first, with the matching lines                                                                              |
+
+- MCP over stdio, one message per line: the `2026-07-28` revision and the
+  earlier ones that open with `initialize` (`2025-11-25` back to
+  `2024-11-05`). No MCP SDK, no added dependency.
+- `.rness/` is read again on each call, so an edit shows at once. Nothing is
+  written.
+- With `claude` in `agents`, `sync` registers it in each clone:
+  `.mcp.json` gets `mcpServers.rness`, which runs the pinned copy
+  (`node ../../.rness/node_modules/@rness/cli/dist/bin/rness.js mcp`). A
+  team's own `rness` entry is left as it is.
+- Each developer approves the server once, in Claude Code's own dialog.
+  rness does not pre-approve it: `enabledMcpjsonServers` in a committed
+  settings file would let any change to the `rness` entry of `.mcp.json` run
+  unasked. Review such a change like code.
+- Verified with Claude Code 2.1.284 on 2026-09-29: the server starts from the
+  repository and its tools answer.
+- Another agent can run the same command from a clone; rness writes no
+  configuration for it.
+
 ### Log in
 
     rness login     # shows a code and https://github.com/login/device
@@ -143,8 +178,9 @@ dependency does this: `util.styleText`, and a banner kept as a constant.
 
 The version is written in one place, `.rness/package.json`. `upgrade` pins it
 there (exact, the rest of the file untouched), installs with the workspace's
-package manager, then syncs through the new copy; a failed install restores
-the file. Commit `.rness`. Teammates pull, and the next `rness` command in that
+package manager, syncs through the new copy, then commits `.rness`
+(`chore: rness <version>`); a failed install restores the file. Push
+`.rness`. Teammates pull, and the next `rness` command in that
 workspace installs the new pin itself — frozen, so the working tree stays
 clean — and carries on: nothing to remember, nothing to run.
 `RNESS_NO_INSTALL=1` turns that off and restores the warning, for CI, a
@@ -182,8 +218,10 @@ now names; `rness validate` warns while it is behind.
   scaffold did not change; overlapping lines conflict, and `upgrade` stops
   before installing — resolve with git (`git checkout --ours <file>` keeps
   yours, `--theirs` takes the scaffold's), commit, run `upgrade` again.
-- `.rness` must be a clean git repository. The merge is staged, not
-  committed: the next steps end in one commit.
+- `.rness` must be a clean git repository with no merge in progress.
+  `upgrade` commits the merge itself, through the repository's hooks. When a
+  hook refuses, everything stays staged, what it said is shown, and
+  `upgrade` exits 1 with the commit to make.
 - A workspace with no scaffold commit (made by hand, or older than
   `create`) is adopted: identical files merge silently, a differing one
   conflicts once.
@@ -197,13 +235,44 @@ pin merges the scaffold of the copy installed in `.rness`. A global below
 `npx` form, or the pinned copy from inside `.rness`. A workspace pinned below 0.5.0, whose copy has no such
 command, starts with the `npx` form.
 
-An upgrade touches `.rness` only: a generated block is current when its hash
-is, whatever wrote it, so no `AGENTS.md` of the organization changes unless
-its content does.
+An upgrade commits `.rness` only. Its sync rewrites a block only when the
+block's content changed — a block is current when its hash is, whatever
+wrote it — and writes the agent files a release adds. The next steps list,
+per repository, the files to commit there.
 
 Exit codes: 0 success, 1 failure, 2 usage — or a refusal without a TTY.
 `RNESS_DEBUG=1` adds stack traces; `RNESS_NO_DELEGATE=1` skips the delegation.
 
+## 0.9.1 — upgrade ends in its commit; the MCP server approved per developer
+
+- `rness upgrade` commits `.rness` itself (`chore: rness <version>`), with
+  the repository's hooks; a refusal leaves everything staged and exits 1.
+  The next steps say what is left: push, and per repository the files the
+  sync changed.
+- `upgrade` syncs every time, the Dependabot case included (pin and install
+  already at the target). In 0.9.0 it skipped the sync there, so the values
+  0.9.0 added to the agent files were missing and the scaffold's
+  pre-commit hook refused the commit.
+- `upgrade` refuses a `.rness` with a merge in progress.
+- `validate` counts a merge in progress: the commit recording a scaffold
+  merge no longer warns that the scaffold is not merged.
+- The Claude target no longer writes `enabledMcpjsonServers`: each developer
+  approves the MCP server once. After syncing with 0.9.0, remove `rness`
+  from `enabledMcpjsonServers` in each `.claude/settings.json` by hand —
+  rness never removes a value.
+
+## 0.9.0 — the context on demand: `rness mcp`
+
+- `rness mcp`: a local, read-only MCP server with four tools —
+  `rness_context`, `rness_list`, `rness_read`, `rness_search`. See "MCP
+  server".
+- The Claude target registers it: each clone gets `.mcp.json`
+  (`mcpServers.rness`) and `rness` in `enabledMcpjsonServers` of
+  `.claude/settings.json`. After upgrading, run `rness sync` once and commit
+  both files in each repository; until then `sync --check` and `validate`
+  report them missing.
+- Blocks are unchanged.
+
 ## 0.8.1 — adoption without placeholders
 
 - Adopting the scaffold no longer adds a `.gitkeep` to a directory that

package/dist/bin/rness.js

@@ -6,7 +6,7 @@ import {
   findDelegate,
   reportError,
   run
-} from "../chunk-ONLF4VFA.js";
+} from "../chunk-N3F6N6GA.js";
 
 // src/bin/rness.ts
 import { pathToFileURL } from "url";