@systemdox/mcp-server 0.1.48 → 0.1.49

package/README.md

@@ -113,17 +113,18 @@ npx @systemdox/mcp-server setup
 
 | Variable | Required | Default | Purpose |
 |----------|----------|---------|---------|
-| `SYSTEMDOX_API_KEY` | yes | — | Your SystemDox API key |
+| `SYSTEMDOX_API_KEY` | no | the key in `~/.claude/systemdox/credentials.json` | Your SystemDox API key. `setup` stores it in `~/.claude/systemdox/credentials.json` and nowhere else, so the server reads it there when this is not set |
+| `SYSTEMDOX_WORKSPACE` | no | — | The workspace whose key to read when `credentials.json` holds several |
 | `SYSTEMDOX_API_URL` | no | `https://api.puglieseweb.com/systemdox` | REST API base URL |
 | `SYSTEMDOX_CACHE_TTL` | no | `300` | Response cache TTL (seconds) |
 
 ## Tools
 
 Read: `get_checks`, `get_specs`, `get_docs`, `get_tech_stack`,
-`get_planning_context`, `get_plan_board`, `get_context`, `get_project_rules`,
-`get_prompt_templates`. Write: `create_check`, `update_spec`,
-`report_decision`, `create_project_rule`, `create_prompt_template`. Write tools
-require an API key with `editor`+ role.
+`get_planning_context`, `get_plan_board`, `get_change`, `get_context`,
+`get_project_rules`, `get_prompt_templates`. Write: `create_check`,
+`update_spec`, `report_decision`, `create_project_rule`,
+`create_prompt_template`. Write tools require an API key with `editor`+ role.
 
 Skills (ADR-216): `publish_skill`, `list_skills`, `install_skill`. A Claude
 Code skill folder (`SKILL.md` plus its references and scripts) is published
@@ -172,8 +173,10 @@ One command sets up your computer, and the same command updates it:
 npx -y @systemdox/mcp-server setup [--project <name>] [--dir <checkout>] [--yes] [--overwrite]
 ```
 
-- It first writes the SystemDox MCP server into your AI tool's config, as it
-  always has. Then, when your workspace has anything published, it checks that
+- It first writes the SystemDox MCP server into your AI tool's config, without
+  your key: the key is stored once, in `~/.claude/systemdox/credentials.json`
+  (readable by you alone), and a key an earlier `setup` wrote into that config
+  is removed from it. Then, when your workspace has anything published, it checks that
   Claude Code is 2.1.316 or later (`claude update` otherwise) and shows you
   everything it will add: the marketplace entry for `~/.claude/settings.json`,
   the plugin with every hook command and every MCP server's command or URL
@@ -181,9 +184,7 @@ npx -y @systemdox/mcp-server setup [--project <name>] [--dir <checkout>] [--yes]
   its file count and folder, and the `autoMemoryDirectory` it will set. On an
   update it shows only what changed, with a line diff for hooks and
   instructions. Nothing changes until you answer `y`.
-- Then, in this order: your key goes into
-  `~/.claude/systemdox/credentials.json` (readable by you alone, and nowhere
-  else); the team instructions into `~/.claude/systemdox/<workspace>/CLAUDE.md`
+- Then, in this order: the team instructions into `~/.claude/systemdox/<workspace>/CLAUDE.md`
   (if you edited that file, it stops unless `--overwrite`); one marked import
   block into `~/.claude/CLAUDE.md`; one `extraKnownMarketplaces` entry,
   `systemdox-<workspace>`, into `~/.claude/settings.json` (nothing else in
@@ -255,6 +256,18 @@ Both read your key from `SYSTEMDOX_API_KEY`, then from
 alone). A key is never written into a settings file, a plugin entry or a
 command line.
 
+### `get_change` (ADR-218)
+
+`get_change { repo, slug }` reads one change, a `specs/changes/<slug>/` folder
+of a connected repository, as SystemDox last synced it from GitHub: each part
+of its brief (decision, contract, behaviour, plan) and its release with its
+state and pull request, the contract files, every scenario as
+`id · state · title`, the plan and the release pull requests, then the change
+as JSON. The last line is `The brief is passed` or
+`The brief is not passed: <part> is <state>`: a build session calls it first
+and stops on the second. A change the key may not read answers
+`No such change <repo>/<slug>`, as one that does not exist.
+
 ### `get_context`
 
 The aggregator. It ranks checks, specs and docs against the task, then
@@ -293,7 +306,7 @@ node scripts/mcp-release-gate.mjs               # from the monorepo root
 ```
 
 Entry points: `src/index.ts` (stdio), `src/http.ts` (hosted HTTP handler),
-`src/cli.ts` (`setup` command). Tool registration is shared via
+`src/cli.ts` (`setup` command: `src/setup-mcp.ts`, then `src/setup-team.ts`). Tool registration is shared via
 `src/server.ts` (`createServer`). The hosted handler is deployed as a Lambda by
 the product-systemdox backend stack (`systemdox-backend-prod`), reached through
 the `*.mcp.systemdox.com` custom domain.