mason-context 0.6.0 → 0.8.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -138,7 +138,7 @@ When a lot of files drifted at once, the assistant runs a **scoped refresh** ins
138
138
 
139
139
  ### Drift checks in CI
140
140
 
141
- Because the check is deterministic, it also ships as a tiny standalone binary — the one exception to "MCP-only", read-only and LLM-free:
141
+ Because the check is deterministic, it also ships as a tiny standalone binary — read-only and LLM-free:
142
142
 
143
143
  ```bash
144
144
  npx -p mason-context mason-drift --dir . # exit 0 fresh · 1 stale · 2 error
@@ -180,6 +180,63 @@ jobs:
180
180
 
181
181
  Omit `agent-command` for detect-only mode: free, no credentials, fails the check when the map goes stale.
182
182
 
183
+ ## Context-file audit
184
+
185
+ Your repo's AI context files — `CLAUDE.md`, `AGENTS.md` — are read by every agent on every task, and nobody owns them. Each merge makes them a little more wrong, and agents act on what they read: a stale claim becomes a misinformed edit. `mason-audit` keeps those files true. It finds claims that are provably out of date — deterministically, no LLM, no network — and works on any repo with a context file. No Mason setup required.
186
+
187
+ ```bash
188
+ npx -p mason-context mason-audit --dir . # exit 0 clean · 1 issues · 2 error
189
+ npx -p mason-context mason-audit --json # full report as JSON (additive-only schema)
190
+ npx -p mason-context mason-audit --fix-prompt # issues? print a work order for any agent
191
+ npx -p mason-context mason-audit --checks deleted-reference,stale-count,dead-command
192
+ ```
193
+
194
+ What it checks:
195
+
196
+ | Check | Flags | Confidence |
197
+ |---|---|---|
198
+ | `deleted-reference` | a referenced path that no longer exists — including paths inside ASCII directory trees; renames resolve to the new path | certain (git history proves it) / likely (never tracked) |
199
+ | `new-module` | a directory with source files that no context file mentions | likely |
200
+ | `stale-count` | "6 packages" vs what the workspace manifest actually resolves to | certain |
201
+ | `dead-command` | `npm run <script>` naming a script no package.json has | certain |
202
+ | `deps-changed` | dependency manifests committed after the doc's last commit | advisory |
203
+ | `decision-anchor-drift` | a decision record whose anchor files changed (only when `.mason/decisions/` exists) | advisory |
204
+
205
+ Issues drive the exit code; **advisories never do** — they're facts an agent can't close by editing the doc, so they're reported for humans instead. Every issue carries a `doc:line` anchor and git-derived evidence (the deleting commit, the rename target, the actual count and its source). A claim you want left alone — say, a deliberate reference to a removed directory — gets an ignore marker: `<!-- mason:ignore -->` on the line, or `<!-- mason:ignore-start -->` / `<!-- mason:ignore-end -->` around a block.
206
+
207
+ ### The context files maintain themselves
208
+
209
+ Same split as the concept map: detection is deterministic and free, the fix is any agent you already run. `--fix-prompt` emits a work order scoped to exactly the flagged claims — fix only these, minimal diffs, never invent content, never touch source code. The reusable workflow runs the audit, hands the work order to your agent, verifies the audit is clean afterwards (and that the agent touched nothing but the context files), then opens a PR citing the evidence — it never commits to the audited branch, and it skips cleanly when an audit PR is already open:
210
+
211
+ ```yaml
212
+ name: Context audit
213
+ on:
214
+ schedule: [{ cron: "0 6 * * 1" }]
215
+ workflow_dispatch:
216
+ permissions: { contents: write, pull-requests: write }
217
+ jobs:
218
+ audit:
219
+ uses: adrianczuczka/mason/.github/workflows/mason-audit.yml@main
220
+ with:
221
+ agent-command: >-
222
+ claude -p "$MASON_AUDIT_PROMPT" --allowedTools "Read,Grep,Glob,Edit"
223
+ secrets: inherit
224
+ ```
225
+
226
+ Omit `agent-command` for detect-only mode: no agent, no credentials — the job fails when the context files have drifted, which is a reasonable default for repos that want the signal before the automation. Two GitHub notes: the repo setting **"Allow GitHub Actions to create and approve pull requests"** (Settings → Actions → General) must be enabled for the PR step, and PRs created with the default `GITHUB_TOKEN` don't trigger the repo's own CI — run your agent with PAT-backed auth if you need that.
227
+
228
+ ## Decision injection (mason-hook)
229
+
230
+ Recorded knowledge only helps if it shows up. Retrieval tools depend on the model deciding to call them — and it often doesn't. `mason-hook` removes the gamble: it's a Claude Code `PostToolUse` hook that fires when a session reads or edits a file, looks up the decision records anchored to that file (exact path or directory prefix), and injects them into the model's context. Deterministic lookup, no LLM call, ~100ms, silent when nothing matches. Each decision is injected at most once per session, and records whose anchors drifted since verification carry a verify-before-relying marker.
231
+
232
+ ```bash
233
+ npx -p mason-context mason-hook --print-config # the settings block to add
234
+ ```
235
+
236
+ Add the printed block to `.claude/settings.json` — the *committed* project settings, so every teammate's sessions get the same rail. The loop this closes: someone records a constraint once with `save_decision` ("this screen has a v1 and v2 — new work goes in v2 behind flag X"), and from then on any session that touches those files gets told, whether or not it thought to ask.
237
+
238
+ For faster fires than `npx` resolution allows, install the package (`npm i -D mason-context`) and point the command at `node_modules/.bin/mason-hook`.
239
+
183
240
  ## Confluence sync
184
241
 
185
242
  Keep a Confluence wiki in sync with the concept map, in plain product language that PMs and designers can read. Each sync rewrites the snapshot through your assistant into PM-friendly descriptions, pushes one page per feature, and posts a "what changed since last sync" entry to a changelog page. Mason owns these pages and overwrites each one on every sync, so edit the code, not the page — manual edits to a page body are replaced. Re-running a sync with no code change is a no-op: it makes no Confluence edits at all.