13 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	2ee24b9d2b	feat(rules): rules before tools — a PreToolUse arm keyed on the action (#3476) ... The only just-in-time rule surface was registered on `Write|Edit` and queried with `code or path`, so a rule could be retrieved at the moment of a code write and nowhere else. Every rule about which tool to reach for — don't curl the forge, don't stand up a stack, don't run the suite locally, don't branch — was unreachable exactly when it mattered, and residency in the always-on preload was the only surface it had. That is the pressure that grew the resident set to 31 against #3089's ceiling of ~23; it was never a judgment anybody made. A reflex generates no query, so an instruction to check the rules cannot catch one. A mechanical trigger can: the tool call IS the query, and a reflex has to become a tool call before it can do anything. `build_tool_rule_hint` is deliberately tool-agnostic — a name and a string — so widening the matcher later is a hooks.json edit with no server change. The hook starts on Bash, which is where the action reflexes live. The two pre-tool arms share ONE session ledger of already-named rules (`<state>/<sid>.rules.ids`). Two ledgers would mean a rule named by one arm gets re-offered by the other, and the hint that fires most often is exactly the one that must not repeat itself. A test asserts both scripts build the same path, and another checks the shell hook and the Python route agree on every query-arg name (rule 33) — a rename there fails silently, looking like a surface that never finds anything rather than a broken one. Deliberately silent on outage, unlike the prior-art hook: a write is occasional, a Bash call is not, and an outage line before every command is what gets a channel muted. `tier="conditional"` matches the write arm and is the transition point — an always-on rule is already resident, so re-tier one and it starts arriving here instead of in every session's preamble. `pre_tool_rule` joins RANKED_SOURCES: this arm chose what it showed, so a pull can settle whether the choice landed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ	2026-09-02 23:31:22 -04:00
bvandeusenandClaude Opus 5	f5a3643da8	refactor(plugin): retire what the hand-bump scheme left behind — the README that taught it, the floor test, the stale rationale (#3328) ... #3127 checklist 19. The step's own deletion list turned out to be largely spent: `check_version_bump()` came out with #3327, and the machinery the step expected to delete alongside it is load-bearing for its replacement. `manifest_version(ref=…)`, `--base`, `--no-version` and the `origin/main` resolve path all STAY. Derivation makes the value right; it does not make the comparison unnecessary. `check_version_is_minted` still has to ask "did the version move when the shipped content did?", and that is a base-branch question no matter who chose the number. The step was planned before #3327 landed, when the assumption was that these died with the guard. What was actually still standing, all of it teaching or asserting the retired scheme: - `plugin/README.md` told the reader to "set a `version` bump per release." A shipped file, instructing the exact act the mint replaced — this is how a deleted control gets re-added by someone following the docs. Now says not to hand-edit the field, names `make mint-plugin`, and says what a forgotten mint costs. (`make` is not installed on every workstation, so the direct script invocation is given too.) - `test_plugin_version_bumped_with_the_hook` asserted `version >= (0,1,31)` as a tuple of ints. Under a minted value it passes vacuously — every date clears a floor of 0.1.31 — and `int("0415")` silently eats the padding the format exists to keep. Superseded by `test_the_shipped_manifest_carries_a_minted_version`, which asserts the canonical shape instead of an ordering the comparator does not perform. Removed whole (rule 22). - The module preamble still ended on "a written rule that depends on being remembered is not a control; this is" — true of the bump guard, and read as a stronger claim than the mint can support. Replaced with what the change did and did not remove: choosing a number is gone, running the mint is not, and the difference is that forgetting is now loud rather than silent. - An orphaned `# --- the version bump ---` section header with nothing under it, and a test docstring still naming `check_version_bump`. `--no-version` keeps its one legitimate case — on `main` the version is measured against itself — and now says so in both the usage block and its `--help`, so it does not read as an escape hatch. `check_session_context_ reports_its_version` stays untouched: a different check with a different job, and the only thing that makes step 6 readable from a transcript (#2220). Version minted 2026.09.02.0415 -> 2026.09.02.0438 for the README change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TcCs1CcQ1ormdnzSshKqvN	2026-09-02 00:38:50 -04:00
bvandeusenandClaude Opus 5	64cb719a12	fix(plugin): mint() rendered whatever offset it was handed, not UTC (#3327) ... Run 5175 red on the Python tests lane. The failing assertion was test_the_mint_is_UTC_not_local, and it was right: `strftime` renders the offset the datetime carries, so mint() only produced UTC because its DEFAULT argument happens to be datetime.now(timezone.utc). Hand it an aware datetime in any other zone and it formats that zone's wall clock -- 22:52Z and its +09:00 twin, the same instant, minted as 2026.09.01.2252 and 2026.09.02.0752. The docstring already claimed "UTC, always", so this was a contract the code did not hold rather than a test asking for something new. Two people minting the same instant would disagree, and the string IS the artifact's identity. Now converts explicitly. A naive datetime is read as UTC rather than as the machine's zone: that is this function's stated contract, and guessing the host's offset is how the same bug returns by another route. Two things found while walking the rest of the module by hand: - test_a_failed_diff_FAILS_rather_than_passing_quietly stubbed EVERY git call to fail, so it tripped the base-branch guard first and passed while proving nothing about the diff arm. rev-parse now succeeds and only the diff fails, and the assertion names the diff message instead of the substring both messages happen to share. - the base-branch failure still said "version-bump check", a name that went away with check_version_bump. The mint script is in the version-relevant set, so fixing it is itself a version-relevant change and forced a fresh mint -- 2026.09.02.0415. That is the asymmetry in #3127 section 3 working as intended rather than a quirk: a format change that did not re-mint would leave the manifest reporting a value the current deriver can no longer produce. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DN4zBVFWhBST9YqjCfQmPb	2026-09-02 00:15:45 -04:00
bvandeusenandClaude Opus 5	f1896bfe9d	feat(plugin): mint the version, and make CI the control that it moved (#3327) ... Milestone 334 step 3. 0.1.48 was the last of 48 numbers a person typed by hand; forgetting to type the 49th is #2209, #1040 and #2220, three separate times a shipped fix reached the repo and stopped there. WHY A SCRIPT AND NOT A BUILD STEP. plugin/ is not in the image -- installs fetch it from this repo via marketplace.json, so the push IS the release and there is no moment at which CI could stamp a version in. Every other artifact in the family derives during a build (#3127 section 2). This one has no build to derive during, so the value is minted before the commit and CI's job is to prove it moved when it had to. MINT TIME, a fourth clock section 2 does not name. It prescribes commit time so two lanes building one source report one string; the plugin has one lane and no build, so that reason does not reach it. What is given up is reproducibility-from-history -- you cannot recompute the value, only verify it moved. That is acceptable ONLY because #3325 read the installer's code and found the refresh test is `P.version === H`, plain equality, with zero ordering comparisons anywhere. Where a comparator orders, an unreproducible version would be unverifiable too. Two artifacts in one repo now derive from different clocks on purpose, one directory apart. "Let's make these consistent" is the obvious tidy-up and breaks whichever loses, so the divergence is pinned in tests rather than only explained in a comment -- including an AST assertion that the mint script never imports subprocess, since a mint that can read history is a commit-time deriver wearing the wrong name. check_version_bump becomes check_version_is_minted. It gains the shape gate and a future-value gate, and it keeps deliberately NOT failing when the version moved without content changing: a needless re-mint costs one cache refresh, and failing the lane over a harmless act is how a check earns a --no-version in somebody's muscle memory and stops running at all. The implication that matters is one-directional. The mint script joins the version-relevant set, which is step 2's DERIVERS table finally being read by something. Section 3's asymmetry is why it is not optional: change the format string, change nothing else, and a diff over the shipped paths alone says "no content change" while the manifest keeps a value in the old format forever. Its own introduction demonstrates this -- adding the deriver is itself the version-relevant change that forced this mint. fetch-depth: 0 was NOT added, against this step's own brief. The plugin job carries a comment refusing it, backed by an observed act_runner failure (any `with:` block made checkout fail to extract, run 3027), and the reasoning holds: the check diffs two trees and the workflow already fetches main at depth 1. Checklist 6 is about jobs that derive; this one checks. Verified live before pushing: the session-context marker reports v2026.09.01.2252 keylessly, and both failure arms were probed by hand rather than assumed. The shape gate fires first on a reverted 0.1.48, so the stale arm is covered by unit test rather than by that probe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DN4zBVFWhBST9YqjCfQmPb	2026-09-01 18:54:55 -04:00
bvandeusenandClaude Opus 5	ea972ac3f7	refactor(plugin): one definition of what ships, and the exclusion that makes the version check mean something (#3326) ... Milestone 334 step 2. The set of files that reach a plugin install lived in two hand-kept copies -- SHIPPED in check_plugin.py and the workflow's paths: filter -- with a comment asking a human to keep them in step. That is the shape #3127 section 3 warns about, and both copies had drifted. The load-bearing change is the exclusion. The version check reads "did shipped content change against the base?", and plugin.json lives INSIDE plugin/ -- so bumping the version is itself a change to the set, which then reads as the change that justifies the bump. Every bump passed, no bump could ever fail, and the check proved nothing while looking green. manifest_differs_beyond_version compares parsed objects with `version` dropped from both sides. One field, never the whole file: plugin.json also carries description, mcpServers and userConfig, all of which reach an install, and excluding the file wholesale would let a userConfig-only edit compute an unchanged version and never refresh -- #2209 again with a narrower trigger. Unreadable input answers "changed", because a spurious bump costs one cache refresh while a missed one is the fix reaching the repo and stopping there. shipped_content_changed returns None, not False, when the diff fails. #2663 is why: a read that failed inside a broad except reported the same zero as an empty window, and every counter read zero for weeks. Two dead trigger paths removed, both found by writing the guard rather than by review. fable-mcp/** outlived its directory by three months (deleted in 91bafb6, 2026-05-27) and assets/** named a path that never existed at all. A paths: entry matching nothing never fires, so neither ever failed anything. Their two orphaned bump scripts go with them -- a third manual-bump mechanism, wired into no settings file. DERIVERS is section 3's (deriver -> artifacts whose identity it decides) table. The membership test is "can changing this file change what the artifact says about itself?", not "is it copied in" -- a deriver is never in the COPY list. A checker is not a deriver, which is why check_plugin.py is absent from it; step 3's mint script adds its own row. The workflow's paths: filter is YAML and cannot import Python, so "one definition" is held by drift tests rather than an import. Said plainly in the test module, because it is the honest shape rather than the ideal one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DN4zBVFWhBST9YqjCfQmPb	2026-09-01 18:28:26 -04:00
bvandeusenandClaude Fable 5	a8f35e465e	refactor(plugin+tests): the last two parallel-family gaps — pageable list tools, one config preamble (#2278) ... DRY pass 3's remainder. Both halves start from enumeration, because the task's candidate list was hypotheses and the process requires counting before proposing — and counting changed the answer twice. ## The list_* family: a limit with no offset Enumerated all 19 `list_*` MCP tools first. They are genuinely heterogeneous — 8 take `project_id`, 6 take `limit`, six take no arguments at all — so a common-parameter guard would invent a convention the API does not have, which is the over-DRY trap (§5). One contract IS real: a `limit` without an `offset` is a truncation with no continuation. The caller is told there are 250 results, handed 50, and given no way to ask for the rest. Two tools had it, and both were capped over a service that already accepted an offset: `snippets_svc.list_snippets(offset=0)` was simply not exposed, and `list_processes` passed a hardcoded `offset=0` into `query_knowledge`. The capability existed one layer down in both; only the door was missing — the missing-sibling shape exactly. Both now expose it. `tests/test_mcp_list_family.py` guards it, with `list_tags` exempted for a stated reason (a ranked top-N over a bounded vocabulary has no "rest" to page into). Candidates derived, decision explicit, same design as test_mcp_auth — plus the reverse checks: a stale exemption, and an offset with no limit, which would page through an unbounded result set. Verified non-vacuous by running the sweep against the pre-fix tree, where it fails naming both tools. ## The verb pairs: no finding, which is the finding `preview`/`apply` and `dry_run`/`commit` do not exist anywhere in the 102 tools — those were guesses about a shape Scribe never adopted. `count_*` does not exist either. Of the create/delete stems only `project_rule` lacks a `delete_X`, and deliberately: a project rule IS a rule, `delete_rule` removes it, and the docstring says so. `force` sits on 6 of 7 duplicate-gated creates; the exception is `create_system`, whose gate is an exact normalized-NAME match rather than a semantic near-match — forcing it would split one area's records across two piles, which its own message explains. No guard added: it would need a seven-entry exemption list to defend against a hypothetical. Recorded on the leave-alone list instead, which the process asks for by name. ## The hook config preamble Not 3 of 6 hooks as recorded — all FIVE carried their own copy, and of four lines rather than two. The extra two are a guard treating an unexpanded `${...}` placeholder as unset, so it is never sent as a garbage Bearer token: precisely the correctness detail a sixth hook would omit with nothing failing loudly. Now `scribe_config` in scribe_defs.sh, which also declares the two names it owns. It sets globals rather than echoing, so a token never passes through a subshell's output where xtrace or a log could catch it, and returns a status so a caller can bail (`|| exit 0`) or continue degraded — the session-context hook still owes its static floor when Scribe is unconfigured. `check_plugin.py` now runs shellcheck with `-x`. Without it the shared helpers were invisible: every variable they set read as unassigned and every bug inside them went unlinted at the call site, which is the opposite of what sharing them was for. All twelve fail-open scenarios still pass, and all five hooks were probed live against the instance — prior_art and after_write both still name canon, autoinject returns context, session_context serves 11k chars of rules, sync_processes stays silent. Plugin 0.1.46 (#2209). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-24 01:28:07 -04:00
bvandeusenandClaude Fable 5	0ab94b2a00	fix(plugin): write-path hooks say when Scribe did not answer — once per outage, shared marker, record nudge withheld on an unanswered call; check_plugin allows exactly that line when unreachable; plugin 0.1.43 (#2932) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-23 10:59:54 -04:00
bvandeusenandClaude Fable 5	5925335ca0	feat(plugin): after-write hook — PostToolUse on Bash diffs the working tree and runs the prior-art + ledger arms on what was just written; shared scribe_defs.sh; plugin 0.1.39 (#2901, milestone 299 step 3) ... Edits made through sed/heredocs/scripts never reached the PreToolUse Write|Edit hook, so a whole class of writes got no prior-art hint, no ledger feed and no duplicate-family warning. scribe_after_write.sh asks git what changed since it last looked (per-session path+blob snapshot; first call = files touched in the last minute), extracts the definitions in the added lines and calls /api/plugin/prior-art with the same three dedup channels the pre hook keeps. Never blocks; silent on any failure. The extractor, the prose/data skip list and the local by-name arm move to scribe_defs.sh, sourced by both hooks. Version bump covers the step-2 hook change too (run 4239 failed only on the bump check). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-22 13:35:45 -04:00
bvandeusenandClaude Opus 5	841506b10c	feat(plugin): every session says which plugin version is executing ... Twice a shipped fix failed to reach a live install, and both times the only detector was the operator saying "I don't think it updated" (#2198, #2209). The reason it is hard to see: an install has two halves and only one self-updates. The marketplace clone pulls on its own; the CACHE is what executes and refreshes only when the manifest version changes. So inspecting the clone shows the fix present while the broken copy keeps running — the obvious debugging move actively misleads. The SessionStart context now names the version it is running. That makes "what is actually executing?" answerable from the transcript rather than by archaeology in the cache directory. DELIBERATELY SMALLER THAN THE ISSUE PROPOSED. #2220 recommended reporting the version to the server, storing last-seen per user, and surfacing it in Settings. That is three surfaces and a migration to answer a question the session can answer about itself. Per the operator's framing on #2338 — "I'm afraid of building another integration between two more surfaces, you being able to notice is enough" — the visibility is the deliverable, not the plumbing. It also lands the issue's own caveat, which the server-side design could not: the state most needing diagnosis is the one where credentials never arrive, and there the dynamic tier does not run at all. This marker is keyless and networkless, so it still appears — verified against both the unconfigured and unreachable-instance paths. CI pins it, asserting WITHOUT credentials for the same reason. Manifest 0.1.22 -> 0.1.23, because a shipped hook changed and an unbumped manifest is precisely the failure this commit is about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:57:33 -04:00
bvandeusenandClaude Opus 5	6d01788326	test(plugin): pin both halves of the local prior-art arm ... CI caught the previous commit: the fail-open contract asserts a hook stays SILENT with no working instance, and the new local arm deliberately speaks there. The invariant is right and the hook is right — the smoke event was wrong. It used `def f`, which this repo really does define, so the hook found something and "silent" was asserting the wrong thing. Fixed by asserting the two properties separately: - SILENT for a symbol that genuinely does not exist. - SPEAKING, with NO credentials, for one that does. That is the point of the arm — the other arms ask Scribe what was RECORDED; this one asks the repo what EXISTS, which needs no instance. Were it to start depending on configuration it would stop covering the case it was built for, and only this assertion would notice. Second trap, hit while fixing the first: spelling the absent symbol out in full wrote `def <name>(` into check_plugin.py, so the smoke event DEFINED the very symbol it claimed was missing, and the hook found it again. The name is now assembled from fragments so the contiguous string never appears in the source. scribe_prior_art.sh joins scribe_session_context.sh as a hook that legitimately produces output without credentials — for the same reason, that it carries something needing neither network nor config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:49:10 -04:00
bvandeusenandClaude Opus 5	dd878bc498	ci(plugin): add shellcheck + jq, and the fail-open smoke test they unlock ... Per-job installs, not an image change. CI-runner's docs/process.md decision checkpoint is explicit: "If only one project needs the dep, prefer that project installing it per-job in their workflow — at least until a second consumer arrives." Scribe is the only consumer, and shellcheck is not a natural extension of a Python image's purpose. Promotion into ci-python is filed as an issue on CI-runner rather than assumed here — same doc, step 1: the maintainer's call goes in the issue, then the PR. This also corrects something I got wrong earlier in this work: I cited rule #5 as blocking a per-job install. Rule #5 is about language TOOLCHAINS via setup-* actions, not small lint utilities, and CI-runner's own process doc positively recommends per-job installs in exactly this case. jq is load-bearing rather than convenient. Every hook opens with `command -v jq || exit 0`, so without it a "runs and stays silent" smoke test passes while exercising nothing — a green tick proving less than no test at all. That is why the smoke test didn't ship with the first cut. The smoke test pins the fail-open contract: each hook, with no credentials and then against a refused connection, must exit 0. Three must also stay silent; scribe_session_context.sh must NOT, because its static behavioural floor is meant to survive having no credentials and no network — asserting silence there would encode the opposite of the design. Verified it can actually fail, rather than assuming: injected a non-zero exit and separately a stray stdout write, and confirmed each is caught. shellcheck and jq are both optional at runtime — missing either SKIPs its check loudly rather than passing. A check that quietly no-ops is the exact failure mode this file exists to prevent. ci-requirements.md updated: jq + shellcheck recorded under per-job installs (the input CI-runner's maintainer uses for the next promotion decision), plus two stale entries corrected — the sheet claimed four jobs when there are six, and listed `uv` as a per-job install when it has been in the image since the ci-python Dockerfile started pip-installing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 22:39:55 -04:00
bvandeusenandClaude Opus 5	1feef179d2	ci(plugin): drop with: from the plugin job's checkout ... Run 3027: the Plugin hooks job failed at checkout, before the script ran. Adding a `with: fetch-depth: 0` block made actions/checkout@v6 fail to extract on the act_runner — Cannot find module '/var/run/act/actions/<sha>/dist/index.js' — while every bare `uses: actions/checkout@v6` in the same run succeeded. The runner's action-cache handling is the difference, not git. No depth was needed in the first place. The version check compares two TREES, and a tree diff needs both trees, not a common ancestor. Verified against a real depth-1 clone: after `git fetch --depth=1 origin main:refs/remotes/origin/main`, both `git diff origin/main -- plugin` and `git show origin/main:plugin/.claude-plugin/plugin.json` work. So the explicit fetch already in the step is sufficient, and cheaper than the full history the `with:` block was asking for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 21:00:14 -04:00
bvandeusenandClaude Opus 5	51e5c22818	ci(plugin): gate plugin/** — the path that shipped two live defects ... `plugin/` is not built into the image; installs fetch it from this repo via .claude-plugin/marketplace.json, so a push IS the release. It was absent from the workflow's `paths:` filter entirely, meaning plugin changes ran no CI at all. Two separate defects reached a live install through that gap: #2198 — all four hook scripts inert (lowercase userConfig env vars, line-oriented `jq -rR`, line-oriented `cut -c`) #2209 — the fix for #2198 couldn't reach an install because the manifest version wasn't bumped, so the installer never refreshed its cache Adds `plugin/**` + `.claude-plugin/**` to `paths:` and a `plugin` job running scripts/check_plugin.py: 1. `bash -n` on every hook. 2. The three known-bad patterns from #2198. Verified by replay against c569cdd^ — all three are caught. Narrow by design; see below. 3. Shipped plugin content differs from origin/main => the manifest version must differ too. Stated against the base branch, not per-commit, so a batch needs one bump rather than one per commit. Replayed against c569cdd: correctly fails. The checker found a real outstanding bug on its first run: the `cut -c1-2000` prompt cap in scribe_autoinject.sh was still line-oriented. Only the prior-art hook's copy got fixed in c569cdd. Now `head -c`. It then failed on this very commit for a missing version bump, which is the third time that rule has mattered and the first time something other than memory enforced it. Manifest bumped to 0.1.20. WHAT THIS DOESN'T COVER, and why. shellcheck is the right tool for check 2 and is NOT in ci-python; nor is jq, which every hook requires and silently bails without — so a "runs and stays silent" smoke test would pass vacuously today and prove nothing. Both need those two packages added to the CI image in the CI-runner repo, which is a separate change to a separate repo (rule #5: the toolchain comes from the image, not from apt-get at job start). Verified against CI-runner's Dockerfile and scripts/install-common.sh rather than assumed (rule #37). `plugin` is not in the build job's `needs`: the plugin doesn't ship in the image, and blocking the build wouldn't un-publish a bad hook — the push already did. A failed job still reddens the run. Closes #2204 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 20:56:15 -04:00