1488 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	a7d736860f	fix(retrieval): the newest two rows are not the newest row of each dial (#4104) ... `current_settings` read a surface's history with one query and `limit(2)`, then keyed the rows by dial. That is only the same thing while both dials have moved equally often — and they do not. Floors get walked; budgets rarely move. Three floor changes and one budget change returns two floor rows, and the budget change vanishes. Under #4102 that cost a missing reason. Since #4104 it is worse: the dial then reports `source: "shipped"` — still on the value Scribe shipped — for a number somebody deliberately tuned. A wrong calibration answer, in the direction a reader has no cause to double-check. One query per dial, `limit(1)` each. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 12:49:15 -04:00
bvandeusenandClaude Opus 5	def144df06	fix(tests): a Result's .all() is sync, and the module has a fourth tool (#4104) ... Two failures in the tests added with the step, both mine. `make_mock_session` is an AsyncMock and every child of an AsyncMock is one too, so leaving `.all` as it came handed `migrate_floor` a coroutine where it reads a list — the same trap the helper's own docstring already flags for `add`. And the registration test enumerated three tools by name, which is exactly what it is for: `migrate_retrieval_floor` made it four. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 12:47:57 -04:00
bvandeusenandClaude Opus 5	aee24c9c1c	feat(retrieval): a tuned number carries the space it was measured in (#4104) ... Milestone 416 step 6. A retrieval floor is a cosine similarity, which only means something inside one embedding model's geometry over documents cut one particular way. Change either and every floor on the install keeps applying while describing nothing — and nothing anywhere says so, because the scores simply come out different and the bar goes on cutting. `CHUNKER_VERSION` already solved this for documents: stamped per row, so the backfill re-embeds precisely what is stale. The same idea, applied to the numbers: - `calibration_stamp()` — embedding model + document shape, one definition. TWO fields, never a fused string (rule 149): a mismatch has to say WHICH half moved, because they call for different responses. - `retrieval_tuning_events` gains `embedding_model` / `shape_version` (migration 0104), stamped on every write. Nullable and NOT backfilled — "unstamped" is the honest answer for a row written before this existed, and it reports as `stale: null`, never as fine. - `current_settings` reports calibration per dial: tuned rows from their event, untouched dials from the registry default's own stamp. - `retrieval_surfaces` and the Settings panel show the mismatch. The panel renders ONLY when something is stale, so seeing it at all is the signal. - `migrate_floor` / `migrate_retrieval_floor` answers "a path for thresholds to be inherited by the next model so that they don't have to recalibrate a lot": the raw cosine cannot cross models, but the PERCENTILE it represented can. Measure what fraction of a surface's logged calls the old floor admitted, re-score those queries under the current model, take the value admitting the same fraction. Dry run by default; applying writes an ordinary tuning event with the arithmetic in its reason. Nothing auto-retunes. A stale stamp says a number is no longer a measurement; it does not say what the number should be, and #4102 measured the one case where the statistic and the correct action pointed opposite ways. The load-bearing test is an ABSENCE: no chat-model identifier may appear anywhere in the calibration path. Claude produces none of these scores, so a Claude upgrade must trigger nothing — a false alarm here teaches the operator to ignore the real one on the day bge-small becomes bge-base. Backup v17 carries both columns, unfilled on the way out and on the way back: a round trip must not turn "we don't know" into a stated fact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 12:45:48 -04:00
bvandeusenandClaude Opus 5	dcf800ed65	fix(plugin): a line break split the token a guidance guard matches on (#4103) ... CI 6973 — `test_guidance_ownership` on "rules are retrieved; ask before a consequential act": the using-scribe skill was missing the marker `content_type="rule"`. It was there. I had hard-wrapped the new bullet across `content_type=` / `"rule"`, and that guard matches its MARKERS raw while normalising whitespace only for the longer `statement` — which is why the failure reported the statement present and the marker absent in the same breath. Rewrapped so the token sits on one line. Worth noting rather than just fixing: the markers are deliberately raw-matched, since a marker IS a literal a reader copies. `tool_doc` flattens for exactly the opposite reason one layer over. Both are right; the trap is that they differ. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 12:20:56 -04:00
bvandeusenandClaude Opus 5	381c90ca7e	feat(retrieval): the wide net becomes a pull — fifty candidates, no bar (#4103) ... Milestone 416 step 5. The operator's compromise — "if you're worried about excluding potentially important data let limit it to 50 entries" — moved to the surface where it is safe. Fifty in the push would be milestone 394 with extra steps; fifty in a pull crowds nothing out. `what_might_apply(query)` returns ranked rule candidates with NO threshold. The moment it serves is the one where the caller does not trust a bar to decide for them, so it does not have one — every row carries its score and the reader judges. WHY IT IS NOT A BIGGER `limit` ON `search` `_search_rules` returns statement, why and how_to_apply in full, on the stated reasoning that a caller who went looking deserves the whole record. That is the DEEP pull and should stay that way. This is the SHALLOW one — many candidates, each just enough to decide whether to open it. Opposite trade-offs, so it is a second tool. THE PREMISE THE STEP GOT WRONG The task said fifty "costs nothing". `_rule_hint_line` had already measured otherwise: ~143 tokens per line once the trigger is rendered, and #3855 tripled trigger lengths across the corpus. Fifty is ~7,000 tokens — cheap next to an arm firing before every Bash call, but not free, and a tool promising a free wide net gets reached for casually and then regretted. So it reuses the graduated shape #3851 measured for the push: the top few carry their trigger whole, the rest carry a cut of it. TRUNCATED, never dropped — the trigger is what lets a reader judge without opening, and a teaser without one is just an id. The cut borrows `_goal_line`'s technique including the fallback that matters (#4036): `textwrap.shorten` returns a bare "…" for one unbroken word. TELEMETRY Logged under its own pull source, asserted absent from both the tunable push registry and AMBIENT_SOURCES. That guard is load-bearing right now: the push arms' near-miss distributions are the evidence #4121 argues from, and a pull folded into them would move those numbers. INSTRUCTION SURFACES The using-scribe reflex and the MCP instructions both pointed at `search(content_type="rule")` for the consequential moment — the deep tool, at the moment you want breadth. They now point here, and keep `search` for reading a rule you already suspect. Written as a practice rather than a prohibition (rule 165). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 12:18:25 -04:00
bvandeusenandClaude Opus 5	ea108acac5	fix(docs): two comments cited the wrong snippet for the duplication (#4102) ... Both said the repeated read-and-clamp was "canon #2860 across 295 of 372 siblings". Wrong on both halves, and checked rather than assumed: #2860 is "Scribe service function — the async_session unit", the service-layer canon, and its instance count is that canon's dominance in src/scribe/services — nothing to do with a threshold helper. The divergence hook flagged the new module against it because the new module is a service, which is the hook working correctly and me misreading it. The duplication itself was real and is what the registry consolidated: `plugin_context` read and clamped the pair twice over, three rule arms did it again, and `reply_preferences._threshold` once more. The comments now say that, and claim nothing about a ledger count. `rule_usage.py:122` cites #2860 correctly as the service canon and is untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:41:30 -04:00
bvandeusenandClaude Opus 5	c8bfa6947c	docs(retrieval): stop asking the operator to diagnose retrieval (#4102) ... The last item in this step's done-when: no wording anywhere asks an operator to tune for correctness. Four Settings hints told them to do exactly that — "raise it if rules keep arriving unread", "lower it if a git push arrives with nothing", "lower this if genuine duplicates go unnoticed". Every one of those asks the operator to diagnose a ranker from symptoms, which is the job the model now does from the records: the telemetry says what each bar refused, and reading those records is what separates a real miss from a bar doing its job. The hints keep the explanation of WHAT each number is — that is worth reading — and drop the homework. `plugin_context.py` said the defaults "are meant to be tuned from retrieval_logs once data accrues", which was true and had no owner. It now names who does it and with what. `retrieval_telemetry`'s docstring gained the warning that belongs beside it: this readout has been measured pointing the wrong way, so the ids it returns are the point, not its percentiles. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:38:16 -04:00
bvandeusenandClaude Opus 5	6240652dce	feat(retrieval): the operator can see what was tuned, and every write is recorded (#4102) ... The other half of the bargain in milestone 416 step 4. The model moves these dials; this is what makes that reviewable rather than merely automatic. THE HOLE THIS CLOSES Every retrieval floor is an ordinary settings key, and `/api/settings` accepts any key at all. A floor written through it landed correctly and recorded nothing — a tuning history with holes in it, which is worse than no history because it reads as complete. So the generic endpoint now routes registry-owned keys through `set_dial` instead of writing them as plain rows. ROUTED, not refused: refusing would only work for callers that had been updated, while this way the form, a script, and an old client all leave the trail, and there is no version of "forgot to use the other endpoint". Clearing a control is written as an explicit set back to the shipped default, because the operator reverting something is the single most important move this history can record. `set_dial` now also refuses to record a no-op. The Settings form re-sends every field on every save, so without that one press of Save would write six rows saying the operator set six dials to the numbers they were already on — and a history nobody can skim is one nobody reads. WHAT THE OPERATOR GETS `/api/retrieval/surfaces`, `/surfaces/<name>` and `/tuning-history`, with `actor` fixed server-side rather than taken from the payload: a payload-supplied actor would let a model claim to be the operator, and "did I do this, or did the session?" is the first question this list is asked. In Settings: the five missing BUDGETS (until now only auto-inject had one, so the only control over a noisy surface was to raise its bar — which discards that surface's best candidates along with its worst), and a "What has been tuned" panel showing each change, who made it, and the reason given. The operator's own changes are marked. The MCP tool demands a reason; these endpoints do not. That asymmetry is deliberate and stated in routes/retrieval.py: the requirement exists to make the MODEL read the records before moving a number on someone else's behalf, and the operator is that someone — a mandatory justification box on every control would be friction charged to the one participant who owes no explanation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:36:22 -04:00
bvandeusenandClaude Opus 5	25bd6742e0	fix(mcp): the three tuning tools get a read/write classification (#4102) ... CI 6962 — `test_every_registered_tool_is_classified_exactly_once`. The backup gap is closed (1692 passed); this is the next guard, and the same shape of one: a tool registered without a classification is silently denied to a read key, with nothing to notice (#3191). `retrieval_surfaces` and `retrieval_tuning_history` read. Read access matters more than usual for these two — a session that cannot see the bar in force, or the reason it was last moved, is one that will move it again blind. `tune_retrieval` writes in both senses: the number the arm reads, and the reason appended to the audit trail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:30:32 -04:00
bvandeusenandClaude Opus 5	ca49a46c23	feat(retrieval): the model moves its own floors, and says why (#4102) ... Milestone 416 step 4's write half. `retrieval_surfaces.py` made the six push arms describe their `{floor, budget}` the same way; this adds the three MCP tools that let the model READ that and change it, and the backup sections that carry the reasons. The operator's decision, which this implements: "the floor should be chosen and adjusted by the model using it… the user should be able to touch it but the model should be the thing handling it 9 times out of 10." WHY A REASON IS REQUIRED, AND WHY THE TOOL ARGUES AGAINST PERCENTILES The milestone originally listed self-tuning as a non-goal on one measured case, and that case is now the tool's docstring rather than a prohibition: `report_preference` logged 69 consecutive declines with the refused record 0.0006 under the bar, and every percentile said "lower it". The refused record was rule 77 "Extract intent from loose phrasing" matched against a query about report layout — a false positive. Lowering would have attached that rule to every completion report ever written. What separated the statistic from the correct action was OPENING the record. So `tune_retrieval` refuses a blank or perfunctory reason, tells the caller to read `retrieval_telemetry(near_miss_samples=5)` and the record ids it names, and carries that 69-decline example — an abstract warning loses to a number. The non-goal that survives is *statistical* auto-tuning; nothing here reads a percentile and picks a value. BACKUP (v16), which is what CI caught `retrieval_tuning_events` was neither backed up nor excluded, and #2293's guard said so. It is backed up: `settings` already carried the numbers, so dropping this would restore an install with six moved dials and no argument for any of them — precisely the state the table exists to prevent, and worse now that the model is the one moving them. One `_retrieval_tuning_event_rows` builder called from both exporters (snippet #2851); `user_id` travels because a restore has to remap it, which is why the row builder is not the model's `to_dict()`. `surface` is a registry name rather than a foreign key, so the history survives a restore into an install whose ids all differ. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:28:17 -04:00
bvandeusenandClaude Opus 5	003bfd7a0a	fix(tests): two readers moved, and the settings guard now checks the registry (#4102) ... CI on 09b4845 caught both, and the second is an improvement rather than a repair. `test_services_reply_preferences` patched `reply_preferences.get_setting`, which the registry refactor removed — its floor and budget are resolved through `retrieval_surfaces` now. Its key-independence test also asserted the arm asks for exactly one key; it asks for two, because both of its numbers are its own since this step, so the assertion names both and adds a check that the registry and the module constant still agree about the floor key. They writing different keys is the failure where the Settings form saves one string and the arm reads another. `test_settings_defaults_agree` parsed `plugin_context.py` for a bare module-level float, and those constants now alias the registry. Rather than teach the regex about aliases, the six retrieval floors are keyed on their SURFACE NAME and read from the registry directly — which is strictly better for this guard: a surface name is also its telemetry source, so a row names the same arm the readout does, and a floor cannot be checked against a stale constant that happened to keep its old value. `PLAN_MATCH_DEFAULT_THRESHOLD` is not a push surface and keeps the older shape, with a note saying why. Added while there: `test_every_tunable_surface_has_a_control`, derived from the registry, so a seventh surface arrives as a failing test rather than as a number only the model can reach (rules 25, 27). Also lands the audit trail this step needs — `retrieval_tuning_events` (model + migration 0103) and `services/retrieval_tuning.py`. The tool layer on top is the next commit; the table is here because `reason` being REQUIRED is the whole guardrail, and the schema is where that starts. A number moved silently leaves nothing for the operator to review or disagree with, and the operator's decision is that the model moves these "9 times out of 10". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:20:47 -04:00
bvandeusenandClaude Opus 5	09b48457ff	refactor(retrieval): one registry for every surface's floor and budget (#4102) ... Groundwork for the step's real change. The operator's decision is that the floor is chosen and adjusted by the model using it, not shipped as a value somebody has to defend: "we need a model consistent surface for the adjustment of these floor values. the user should be able to touch it but the model should be the thing handling it 9 times out of 10." A tuning surface cannot be consistent across six arms that each spell their configuration differently, so the arms stop owning their numbers. `retrieval_surfaces.SURFACES` names each one, its floor key and default, its budget key and default, and — because they are rendered by the tuning tool and the Settings UI — what it asks, over what corpus, and how often it fires. A floor cannot be moved responsibly by anyone who does not know those three. Three things fall out: - **`k` becomes a real budget everywhere.** Only auto-inject had a configurable one; `RULEHINT_LIMIT`, `PROMPTRULE_LIMIT` and `reply_preferences.LIMIT` were constants. `k` is what binds under a low floor, so it has to be settable per surface — and per surface is the point, since `pre_tool_rule` fires before every Bash call while `prompt_rule` fires once a turn. - **`write_path` gets its own budget, inherited not reset.** It shared auto-inject's outright on the argument that "how many titles at once" means the same thing on both. It does not, for the same reason. Unset, it still reads auto-inject's key, so an install that tuned the shared knob does not silently drop to a new default. - **The duplicated read-and-clamp goes.** That shape is canon #2860 across 295 of 372 judged siblings. Survivable while the numbers were constants; not once they are meant to move. The long measurement comments stay exactly where they are — #2223's noise-floor probe, #3853's command-vs-code split, #3851's band measurement. The constants they annotate now alias the registry, so there is one value and the reasoning still sits beside it. Tests build the write-path config from the registry (`helpers.writepath_cfg`) instead of from hand-written dicts. That is not tidiness: the rule arms read their numbers inside a fail-open `except`, so a dict missing one key does not raise where a reader would see it — the arm silently becomes a no-op that reads exactly like "fired and found nothing". Ten hand-written dicts each looked complete on the day they were typed. tests/test_retrieval_surfaces.py pins the identity everything rests on: a surface's name IS its telemetry source. Nothing in the type system says so — `record_retrieval(source="pre_tool_rule")` is a literal in another file — and renaming one without the other yields an arm that can be tuned and not measured, or measured and not tuned, with no symptom either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-17 11:17:23 -04:00
bvandeusenandClaude Opus 5	5d47342fbc	fix(tests): two expectations that the new contract corrected (#4101) ... Both were mine, and both show the change behaving as designed. `test_session_dedup_marks_the_reuse_arms_rather_than_silencing_them` asserted #12 stays out of the search's `exclude_ids`. It does not, and should not: the place arm has just listed it, so the semantic arm must not list it again. That is the same-call rule, not the ledger. The claim I meant — the LEDGER never reaches the query — is asserted on its own against a record the call has not otherwise rendered. `test_a_pulled_snippet_already_seen_is_evidence_not_menu` expected #7 and #8. It gets #7 alone, because #7 (0.91) now anchors the margin band at 0.81 and #8 scores 0.80. Withholding #7 used to promote a materially weaker hit into a slot it had not earned, with nothing in the output saying so — the band measures distance from the best answer, and letting the ledger decide which answer that is was the axis confusion the rule band was written to avoid. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:19:05 -04:00
bvandeusenandClaude Opus 5	825491d859	fix(retrieval): the place arm marks its repeats too, and three tests meet the new contract (#4101) ... CI on 5c64ea0 surfaced a half-measure I had shipped and three tests pinning the semantics it replaces. **The half-measure.** Only the semantic arm was marking repeats; the write path's PLACE arm still dropped a nearby snippet that was on the ledger. One menu, two rules, decided by which arm happened to find a record — and the marker would then read as a complete account of what the session has met while covering half the lines. `seen` now means this call's own menu and nothing else, so both reuse arms mark and neither withholds. **test_session_dedup_excludes_ids_from_the_reuse_arms** asserted the drop and the ledger going into the query. Both are the defect; it is renamed and asserts the marker instead. **test_a_pulled_snippet_already_seen_is_evidence_not_menu** asserted #7 was evidence and NOT menu, with the limit widened by one to pay for the drop. The premise was the hard exclusion; #7 is now both, and the widening is no longer needed for it. **test_a_record_this_arm_withheld_itself_is_not_a_near_miss** is the interesting one. Its property still holds and its setup no longer reaches it: a ledger repeat comes back from the search and is rendered, so nothing is withheld and `best_available` describes the bar. The one post-search filter left is a PULLED record this same call already listed by place — kept in the query because `resembles` needs its score, dropped from the menu because it is already on it — so the test is rebuilt on that, and a sibling test pins the direction that changed, so nulling the score whenever the ledger matches cannot pass both. Also stubs `superseded_ids` and `owner_names_for` in the new test file, which were reaching for Postgres in a unit job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:16:10 -04:00
bvandeusenandClaude Opus 5	f1e63d207f	fix(plugin): the sweep missed the arm that fires most — two ledger directories (#4101) ... CI caught two things in c61f730, and the second is the one that mattered. 1. `scribe_autoinject.sh` keeps its note ledger in `${TMPDIR}/scribe-autoinject`, not `scribe-priorart`. Every ledger NAMED in the hooks was in the one directory the sweep visited, so it read as complete — and the arm that fires most (598 calls in five days) was the only one still carrying the bug. The clear ran, found nothing to remove, and exited 0. `SCRIBE_LEDGER_DIRS` in `scribe_defs.sh` is now the roster, and the guard reads that string rather than a copy of it, so a test can no longer agree with itself forever. 2. The convention guard over-reached: it flagged `<sid>.snap` and `<sid>.blocked`, which live in `scribe-afterwrite` and `scribe-reportcheck` and can never be touched by the sweep. It is now two tests keyed on the directory, because the two assumptions fail differently — one lets a ledger sit where nothing sweeps, the other lets it sit in the right place under a name the sweep does not match. `test_only_the_rule_ledger_is_cleared_and_the_note_ledgers_are_left` also went red, correctly: the note arms' exemption was a real decision, recorded in a test, and my commit message said nothing about it had been decided. That was wrong and the test was right to stop me. The decision is reversed rather than ignored, and the reasoning is that #4101 removed its premise: it rested on a note repeat being WITHHELD, so clearing the ledger meant re-injecting whole menu lines the session already had. Now a repeat is rendered with a `seen` marker, so the ledger only decides whether that marker is true — and across a compaction it is false, telling a freshly-summarised session it has already seen a record that is nowhere in its context. The test keeps its name and records the reversal with the reason, rather than being deleted. Verified by running the hook directly: all six ledgers across both directories gone on `compact`, `<sid>.unreached` left standing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:11:43 -04:00
bvandeusenandClaude Opus 5	5c64ea0b4f	feat(retrieval): a repeat on the note arms is a reference, not silence (#4101) ... #3750 settled this for rules: a record the session was told about an hour ago is not a record in front of the reader now, so the second time it is the best answer it is rendered again with a tail saying so. The note and snippet arms never got that fix, and theirs was worse — the ledger went into `semantic_search_notes` as `exclude_ids`, so the repeat left the candidate set entirely. Three things followed: - the second time a note was the best answer the session got SILENCE, indistinguishable from "nothing matched", on the arms that fire most (`auto_inject` alone ran 598 calls in five days); - a compaction made that permanent, since the ledger outlived the context it described — fixed one layer down in c61f730; - and `best_available` was measured against a candidate set the caller had already edited, so the bar could be blamed for a record the caller withheld (#3739, from the side its fix never reached). The ledger is now a RENDERING fact. Every repeat is still ranked, still shown, and carries a `seen` marker; the band is computed over all hits, because letting the ledger move the cutoff would make "you were shown this" change what counts as relevant. The marker is one word and deliberately not the rule arms' phrasing — "before deciding it does not apply" is the voice of a record that binds, and a dev-log borrowing it would claim authority it does not have. Telemetry takes the rule arms' contract (#3752): `results` and `record_surfaced` both take fresh only, the repeat is counted in `suppressed`, so this source's surfaced set still matches its own log row (#3668). That makes a fact readable that could not be stated here before — `result_count == 0` with `suppressed_count > 0` is "everything that matched, the session has already seen", which is a different claim about the bar from "nothing cleared it". On the write path this also splits a variable that carried two claims. `seen` was the ledger plus everything the call had already rendered, and both were treated as reasons to withhold; `in_menu` keeps the same-call exclusion while the ledger becomes a marker. That narrows the `best_available` compromise at its old comment to the pulled-and-already-listed case, and retires the argument that a suppression count here would be partial — nothing is hidden inside the query any more. Deliberately unchanged: the write-path SYNC class still shows once. Its claim is about an edit in progress rather than a record's continuing relevance, and repeating it every write to the same file would be nagging. tests/test_ledger_references_not_silence.py pins both arms — the ledger never reaching the search, the repeat rendered and distinguishable, the telemetry split, the all-repeats call being readable, and the two exceptions (this call's own menu, and the sync class). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:08:10 -04:00
bvandeusenandClaude Opus 5	c61f7301bc	fix(plugin): a compaction clears every session ledger, not the two on the list (#4101) ... `scribe_session_context.sh` cleared `.rules.ids` and `.opened.ids` by name and left `.ids`, `.sync.ids` and `.derive.ids` standing, under a comment asserting that was a decision. Reading the note arms says it was not: their exclusions go straight into `semantic_search_notes`, so a surfaced note leaves the result set rather than being rendered as a reference the way #3750 gave a repeated rule, and unlike the rules ledger they never age. Hard, permanent, never cleared — a note surfaced in a session's first minute is unreachable for the rest of it, which is milestone 386's own defect alive on the arms that fire most often. The list was the bug, so the fix is not a longer list. `scribe_clear_session_ ledgers` matches the naming convention instead — a per-session ledger is `<sid>[.<kind>].ids` — which covers all five and covers the sixth on the day it is written. `<sid>.unreached` is deliberately outside it: that records an outage, not held context, and #2932 needs it to survive. tests/test_session_ledger_clear.py runs the hook rather than grepping it for `rm -f`, since grepping for the names is the pattern being removed. It pins both directions — `compact`/`clear` take all five, `startup`/`resume` take none — plus the convention the glob rests on, checked against the hooks themselves so a ledger named outside it fails loudly instead of silently never clearing. Also drops a stale comment pointing at a rules-etag marker that milestone 394 retired. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:00:42 -04:00
bvandeusenandClaude Opus 5	957a72c501	fix(tests): the compact band pins three holding states, not two (#4100) ... CI run 6945: 11 failures down to 1. The survivor is test_shortening_a_line_does_not_decide_what_it_says_about_holding, which asserted "no longer hold it" appears in the compact line for seen=True — the phrase that now belongs to the OPENED state, not the named one. Its subject is a property, not a string: `compact` and the ledger are independent axes, and shortening a line must not change what it claims about holding. So the fix follows the axis rather than swapping the phrase. The axis grew from two states to three, and the test now checks all three are distinct under compact — pinning only two would let the compact branch collapse the new middle state into either neighbour, which is the same regression it was written for with one more place to hide. Added the assertion that matters most when room is short: a line the session never opened must not imply it did. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 17:35:08 -04:00
bvandeusenandClaude Opus 5	ebd6cb203c	fix(tests): the repeat tail is the middle state now, not the opened one (#4100) ... CI run 6943: 11 failures, two causes, both existing guards correctly catching the behaviour change rather than defects in it. TEN were `_SEEN_TAIL = "You saw it earlier this session"`. Every one of those tests drives an arm with `exclude_rule_ids` alone — the NAMING ledger — which since this change is the middle state, not the opened one. That is the whole point of the step: `seen` stopped meaning "you saw it". The constant now holds the middle tail, so each test keeps asserting exactly what it was written to assert (a repeat gets a line distinct from a first surfacing) against the wording that is now true. Added `_HELD_TAIL` and a negative assertion with it: neither call names an opened ledger, so neither may claim the session read anything. That catches `held` defaulting true, which would have every repeat assert the strongest of the three claims on no evidence — and none of the ten existing tests would have noticed. THE ELEVENTH was my own test edit being wrong, not the code. I asserted `held_rule_ids` would appear in `re.findall(r"printf '([a-z_]+)=", defs)`, but `scribe_held_query` spells it `printf '&held_rule_ids=`, and the leading `&` means that regex never matches it. The regex enumerates SCOPE keys — the alternatives that open a query — and the ledger key is appended to a query that already has one. Two different contracts that happened to share a file, so they are now asserted separately and the difference is written down. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 17:19:19 -04:00
bvandeusenandClaude Opus 5	ad26b3f458	feat(retrieval): the ledger records what was OPENED, not merely what was shown (#4100) ... Milestone 386 made a repeat REFERENCED rather than withheld, and the line it chose says "You saw it earlier this session". Nothing ever checked that. The arms emit a TEASER — title, trigger, get_rule(N) — so a session can be shown a rule twenty times and never read a word of it, and a compaction summarises the teaser away leaving nothing behind. The server was asserting something about the reader's context it had no way to know. Three states now, where there were two: never surfaced "it is not in this session's loaded set" named, unopened "Mentioned earlier this session but not opened — read it…" opened "You opened it earlier this session; pull it… again" The middle one is the honest one and the one that was missing. It keeps the full invitation, because a session that skipped a teaser is in nearly the position of one never shown it. HOW "OPENED" BECOMES OBSERVABLE. A new PostToolUse hook watches the get_rule call itself and appends to `<sid>.opened.ids`. PostToolUse does fire for MCP tools — the event's own output schema carries `updatedMCPToolOutput`, which would be meaningless otherwise — and the matcher is `mcp__.*__get_rule` so the server segment, which varies by install, is not pinned. This is NOT the self-report 386 rejected. That objection was to ASKING a model whether it holds a rule, which is unverifiable. A tool call is an event the harness reports whether anyone asks. Recording what a session DID and believing what it SAYS about itself are different kinds of evidence. Both ledgers clear together on compact/clear. Keeping `.opened.ids` across a compaction would have the arms telling a freshly-summarised session "you opened it earlier" about a rule now nowhere in its context — a more confident version of the bug being removed. Same reader (scribe_rules_live) for both, so ageing, last-entry-wins and the bare-id format are defined once. Also closes two smoke-coverage holes the checker was reporting as SKIP: the new recorder, and scribe_precompact_preserve.sh from #3680. The latter needed STATIC_FLOOR to become a set — PreCompact's contract is inverted, its stdout BECOMES the summarizer's instructions, so silence is its failure mode and a generic read of it looks like a leak. Step 2 of milestone 416, and a hard prerequisite for step 4: while suppression keys on shown, widening k marks records "seen" faster than they are read, and the ledger would degrade in proportion to the improvement. Plugin minted 2026.09.16.1232 -> 2026.09.16.2102. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 17:03:39 -04:00
bvandeusenandClaude Opus 5	bb6ab0f2a8	fix(tests): the trigger backfill assumed keyword calls; three fixtures pass positionally (#4099) ... CI run 6937 red — 3 collection errors, `positional argument follows keyword argument`, in the three integration fixtures that call the service positionally (`create_rule(topic.id, uid, "title", "statement")`). The script that added `when_to_apply=` to 15 fixtures inserted it as the FIRST argument, which is valid only where every other argument is already a keyword. Moved to the last argument in every call, which is legal in both styles, and the continuation indent now matches the surrounding arguments. Also repairs self-inflicted damage: the same script added a trigger to the two tests in test_rule_trigger_required.py whose whole purpose is to call the creators WITHOUT one. They would have stopped raising and the guard's own proof would have inverted — a test that passes for the opposite reason than the one it names, which is worse than a failing one. Caught by ast.parse across tests/ rather than by the next CI round trip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 14:49:05 -04:00
bvandeusenandClaude Opus 5	07bdbf1647	feat(rules)!: a rule cannot be created, or edited into, having no trigger (#4099) ... `when_to_apply` is not metadata. `rule_document` embeds a rule as `{title} — {trigger}` / `When to apply: {trigger}\n\n{statement}`, the trigger appearing twice so purpose dominates a short vector — the shape note 2485 measured on snippets (a 0.153 top-to-second gap against 0.010–0.023 for everything else). Without one the document silently becomes title + statement: a DIFFERENT shape, ranked against a corpus it does not match, with nothing to report it. Every bar and every rank in the system assumes one shape. `create_preference` has refused an empty trigger since it shipped. The two rule creators defaulted it to "" — so the shape was enforced for the record kind that guides and optional for the kind that binds. The guard lives in the SERVICE, because both doors reach it: the MCP tools and the frontend's fast path in routes/rulebooks.py. Written in either alone, the other could still create a rule that never fires. The route keeps a matching check for the STATUS CODE only (400, not the 404 it maps ValueError to). update_rule refuses to EMPTY an existing trigger, checked after the mutation so it covers `clear=[...]`, an emptied form input, and any route added later. Deliberately asked as "did this edit remove one" rather than "does one exist": a rule predating the guard has none, and refusing to save it would freeze precisely the unreachable records that most need fixing. Deliberately not following arose_from_id, which the human door exempts itself from because provenance is about auditing what the AGENT changed. That reasoning does not reach this field — a missing trigger is not a missing explanation, it is a rule that does not work, and it fails an operator as badly as a session. 15 test fixtures across 6 files were creating rules with no trigger. They now pass one; that they did not is the point — curation is not a guarantee. Step 1 of milestone 416 "Retrieval stops guessing a bar". First because every later step assumes one document shape, and it is much cheaper to guarantee before a corpus grows than to backfill after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 14:45:32 -04:00
bvandeusenandClaude Opus 5	5ae60734bb	fix(retrieval): the completion-report arm gets its own bar, not the prompt arm's (#3860) ... `report_preference` shipped reading PROMPTRULE_THRESHOLD_KEY, so the two arms were one dial: tuning the bar for an operator's prose silently retuned the lookup that runs when a task closes. That coupling is worse on this arm than it would be anywhere else. Every other retrieval arm scores a query that varies per call, so a mis-set bar shows up as a changed clear-rate. COMPLETION_QUERY is a fixed string, so this arm's best score for a given corpus is a CONSTANT — and a constant sitting under the bar is a dead arm rather than a quiet one. No volume of traffic reveals it. Found by the first live read for milestone 394 step 9: 69 calls, 69 declines, every one naming the same record at the same score (0.7194 against a 0.72 bar). Reading `best_available_id` (#3807) showed the record was about interpreting a REQUEST, not about report shape — so the declines were correct and the arm is healthy. The percentile alone would have said "lower the bar", which would have delivered a false positive on every completion report ever written. The bar does not move; the key does. Both defaults stay 0.72, so this changes no behaviour on any install — it makes "leave this one where it is" expressible, which it was not before. Settings grows the control (rules 25, 27), and the default-agreement check grows a row. Deliberately NOT included: a change to PROMPTRULE_DEFAULT_THRESHOLD. The evidence for moving it is this install's near-miss table, and rule 115 keeps a shipped default from being justified by one instance's corpus. That bar is a per-user setting and belongs in the operator's Settings, not in the product. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 13:47:34 -04:00
bvandeusenandClaude Opus 5	dd08f9858c	fix(tests): the rule-33 contract follows the scope key into the shared helper (#4085) ... Two interface-contract tests read each hook's own source for the query args it sends. The project-scope key now comes from scribe_scope_query, so `repo=` was no longer spelled in the hook and both read that as the hook having stopped sending it. They now pin the pair: the hook delegates to the helper, and the helper emits exactly `repo=` and `project_id=`. That is a stronger assertion than the one it replaces — it catches a hook rolling its own scope resolution again, and it pins the new key, which the route must read for a non-git session to reach its project at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 08:34:55 -04:00
bvandeusenandClaude Opus 5	aa94c73d9e	feat(plugin): a directory says which project it belongs to, git repo or not (#4085) ... All six hooks scoped their requests one way: `git remote get-url origin`, resolved server-side through the repo bindings. That key does not exist outside a git repo, so a session in a plain directory was unscoped in every hook at once — no project context, no prior-art scoping, no project rules — and silently, because a missing remote is indistinguishable from a remote nobody bound. A `.scribe` file is the second key, read by the shared scribe_scope_query so a directory scopes the same way everywhere: {"instance": "https://scribe.example.com", "project_id": 2, "project": "…"} `instance` is why the file is not just a number: an id is a different project on every Scribe, so a marker that travels — a copied directory, a shared machine, a repo someone else clones — would otherwise scope the session to the wrong project without a word. Compared host-only, and a mismatch drops the id: no project beats the wrong project. A bare integer is accepted too, since it is what a person writes by hand. The marker beats a git remote — someone put the file there on purpose — which is also how a directory overrides its binding. Two things it found on the way: * An explicit project_id that did not resolve rendered NO message at all — the branch hung off `if project_id` as an `elif`, so a caller holding a pointer it believed in got a context that silently omitted the project it had asked for. Now reported. * The refusal reason was a global set inside a function every caller reads through `$( )`. The assignment died with the subshell, leaving the caller to read an unset variable under `set -u` — which aborts the hook and costs the whole session's SessionStart context, to fetch a warning about a file. It comes back through stdout with the id instead, and a test pins it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 08:32:29 -04:00
bvandeusenandClaude Opus 5	47388eda36	fix(tests): the no-block guard reads the shell, not the comment explaining it (#3680) ... The hook's header quotes `{"decision":"block"}` while explaining why this hook must never emit one, and the instructions it prints use "decision" in a sentence. Grepping the whole file caught both and failed the guard on the file doing its job. Strips comments and the heredoc first, and guards the stripper: `_code()` returning nothing would make all three static checks pass against an empty string, which is the circularity rule 167 is about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 08:13:56 -04:00
bvandeusenandClaude Opus 5	4b8d22e3ec	feat(plugin): a PreCompact hook tells the summarizer what must survive (#3680) ... Spike #3680 asked whether a PreCompact hook can reach the model. Read out of the installed Claude Code build (2.1.273), the answer is yes — through a different channel than note #3679 assumed: * `hookSpecificOutput.additionalContext` is NEVER read on PreCompact. The hook-output schema has no PreCompact variant; the field is honoured for SessionStart, SubagentStart and Stop, and silently dropped here. * A PreCompact hook's STDOUT becomes `newCustomInstructions`, merged with the operator's own `/compact` instructions and passed into the prompt that writes the summary. Manual, auto and partial compaction all do this. So the hook does not interrupt the compaction — it steers the summary, which is what the next turn reads. Blocking is the thing not to do: a PreCompact block SKIPS compaction, tells the model nothing, and leaves the session running on uncompacted with no summary at all. scribe_precompact_preserve.sh names what the summary is the only copy of: Scribe record ids WITH titles, the in-progress task and its milestone, work done but not yet recorded, governing rules, and unfinished operator asks. No network and no config — what must survive is already in the conversation being summarized; the hook only says which parts are load-bearing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 08:11:52 -04:00
bvandeusenandClaude Opus 5	5e4fd017ae	fix(mcp): list tools return rows that say what a record is, not what it says (#4061) ... list_tasks returned every row's to_dict(), body included: a project's todo list came to 93-165k characters, past what an MCP client accepts inline, so the list arrived as a file to page through (the #4045 failure, one call over). - notes.brief_row: id, title, type, project, tags, updated_at; for tasks, status, kind, priority, milestone id and title; description, parent and due date only when set. - milestones.titles_for: one query for the milestone titles a page of rows names. - Brief rows on list_tasks, list_notes, get_milestone's steps, get_system and list_system_records. get_task / get_note / get_snippet read a record in full, and each docstring says so. - tests/test_list_rows_brief.py pins the ceiling: 100 rows of ~5k-character step plans stay under 40k characters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 16:07:00 -04:00
bvandeusenandClaude Opus 5	6eb5ef5c73	docs(plugin): a request for the operator's approval gets its own "Approval requested" section (#4084) ... A session's go-ahead request sat inside a completion list as "Blocked by the permission check", and the operator read it as a fault rather than a question waiting on them. The reporting-back skill now puts any action held for a yes under a section headed "Approval requested", near the top of whatever reply it is: each change numbered so part can be approved, why it needs them, how it is undone, and what happens after. The Asks table gains an Approval row, and the completion report's "Needs you" points at the section. test_reporting_back_skill pins the heading and the row. Plugin version minted: 2026.09.15.1921. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 15:21:28 -04:00
bvandeusenandClaude Opus 5	21a701c572	fix(planning): the plan gate's default drops to 0.80, where reworded plans actually score (#4079) ... Measured live after deploy: three plans reworded from existing active milestones scored 0.83-0.87 against the milestone they restated, and the nearest distinct plans 0.72-0.77. At the inherited 0.90 the semantic arm matched nothing, so only an identical title was caught. 0.80 sits in the gap. The Settings form's default moves with it (test_settings_defaults_agree). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 14:53:14 -04:00
bvandeusenandClaude Opus 5	fb36599f2d	docs(plugin): find the existing plan before making one, and file related work into it (#4080) ... Step 5 of milestone 415 "An existing plan is found before a new one is made". Sessions opened a second milestone beside the roadmap milestone that already covered the work, and filed related tasks loose, because no surface told them to look first. - writing-plans: a section on finding the plan that exists (enter_project's unplanned_milestones, search(content_type="milestone"), list_milestones); when an active milestone covers the work, add steps to it; a second milestone only for a separate arc; the gate's existing_milestone reply. - using-scribe: "when you plan" gains the same check and milestone_id on related tasks. - _INSTRUCTIONS PLAN line points at the milestone search (1,689 of 2,000). - test_guidance_ownership pins the topic on writing-plans. - Plugin version minted: 2026.09.15.1744. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:45:52 -04:00
bvandeusenandClaude Opus 5	2811fc9025	fix(planning): the plan gate joins step text through embedding_text (#4079) ... test_nothing_else_builds_the_embedding_document_itself caught start_planning building f"{title}\n{body}" inline for the plan gate's candidate text. That is the embedded-document shape; plan_candidate_text now takes (title, body) pairs and calls embedding_text, so the candidate moves with the corpus it is ranked against (#2486). Also carries the create_task / create_records milestone_id docstring lines from step 5 (#4080), which share the file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:45:52 -04:00
bvandeusenandClaude Opus 5	59407728e6	feat(planning): start_planning hands back the active plan that already covers the work (#4079) ... Step 4 of milestone 415 "An existing plan is found before a new one is made". A session that could not see an existing plan made a second one beside it. start_planning and create_milestone now ask first: an ACTIVE milestone in the project with the same title, or one that reads as the same plan (title, design and steps against milestone embeddings), is returned with its progress and a pointer to create_records(milestone_id=...). Nothing is created; force=true bypasses. - dedup.find_matching_plan / plan_gate / plan_match_response; access-checked before either arm (rule 78), fail-open like the other gates. - Done milestones never block; the semantic arm needs 200+ chars of candidate. - kb_plan_match_threshold (default 0.90) is a setting, in the Settings view, and pinned against the Python default by test_settings_defaults_agree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:43:18 -04:00
bvandeusenandClaude Opus 5	3a501c2cac	feat(search): milestones are searchable by meaning — "is there already a plan for this?" (#4078) ... `search` covered notes, tasks and rules, and a milestone — the record a plan lives in — could not be found. A project whose roadmap was written as milestones had every later plan opened beside the one that already described it, because nothing could have told the session it existed. - milestone_embeddings (migration 0102): the third sibling of note_ and rule_embeddings, for note 3163's reason — the search is milestone-specific. The document is title — description, then description and the plan body, so a roadmap milestone with no description is still found by its design. - Written on create, on a title/description/body update, and for a plan made through start_planning / create_records, fire-and-forget with the parent-row claim (#3262); a startup backfill covers every existing milestone. Derived, so it joins _NOT_INCLUDED beside the other embeddings. - semantic_search_milestones: a project's milestones when the caller can read it (access.can_read_project), otherwise the caller's own; optional status. - search(content_type="milestone"): id, title, description, status, project and progress. Its own shape, and not part of "all", whose results are note-shaped. The docstring says what it is for: ask before start_planning. - Integration test on real Postgres: found in its project and not another, status narrows, an unreadable project returns nothing. Milestone 415 step 3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:34:03 -04:00
bvandeusenandClaude Opus 5	6d0dee48fa	feat(board): the No Milestone group collapses, and every group's Done column starts folded (#4077) ... Operator, 2026-09-15: the unmilestoned group should collapse, "especially the done column as it currently consume a lot of vertical space for [work] that's already done." - The "No Milestone" group gets the milestones' chevron and collapse, keyed as 0 in the same Set (no milestone id is 0), and starts collapsed on first load when everything in it is finished — the rule finished milestones already follow. - Each group's Done column header becomes a button that folds its cards, with the count still showing and aria-expanded set. Folded by default: done work is the part of a board nobody is reading. - Not persisted, matching the milestone collapse beside it. Milestone 415 step 2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:30:11 -04:00
bvandeusenandClaude Opus 5	e886bd2a87	test(rules): rules_payload fixtures carry a title, as every rule_brief does (#4081) ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:28:45 -04:00
bvandeusenandClaude Opus 5	184a3e026d	feat(mcp): enter_project names active milestones with no steps as open work (#4076) ... A plan written as a milestone with a description and no steps was invisible to the session handshake: it lists the 5 most recently touched milestones (#4045), and touching is a step changing, so a step-less milestone can never qualify. FabledLibrarian's roadmap (nine such milestones) sat unseen while later plans were opened as new milestones beside the ones that already described them. enter_project adds `unplanned_milestones`: active milestones with no steps, in roadmap order, id/title/description, up to 10 with an omitted count, none repeated from the recent list, and absent when there are none. The docstring says what they are for: check them before starting a new milestone, and add steps to a match with create_records(milestone_id=...). Milestone 415 step 1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:28:05 -04:00
bvandeusenandClaude Opus 5	ac01eee040	fix(rules): planning reads list rules by id and title instead of restating them (#4081) ... start_planning on project 2 replied with 92,645 characters, 65k of them applicable_rules. Milestone 414 made a project's listing every global rule tagged to an area it works in (before, the rules of subscribed rulebooks, and project 2 subscribed to none), and the non-brief rules_payload sent each as a full rule_brief. get_milestone, get_project and get_task carried the same. Every rules_payload form now lists: id, title, the topic a global rule sits in, and `via` for a co_surfaces partner. get_rule reads one in full, and retrieval delivers them in full when work matches — the reasoning #4045 applied to the handshake. A test pins 81 full-length rules under 6k characters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:26:48 -04:00
bvandeusenandClaude Opus 5	0bf7406f42	fix(mcp): two rule reads reach a read-only key, and every tool must now be classified (#3191) ... rules_due_for_verification (the rule staleness sweep) and rule_history (what a rule used to say) are pure reads, and a read-scoped API key was refused both: neither is in _READ_ONLY_TOOLS, and the completeness test that should have caught it only looked at tools whose NAMES start like a read (get_, list_, search…). Neither does. - Both join _READ_ONLY_TOOLS; the comment that pointed at this issue now says why they sat unlisted. - _WRITE_TOOLS declares every writing tool by name. Nothing reads it at runtime — default-deny already refuses an unlisted tool — it exists so the classification is total. - test_every_registered_tool_is_classified_exactly_once takes its candidates from what build_mcp_server() actually mounts, requires each in exactly one of the three sets, and still flags a classified name that is no tool. The decision stays explicit; only the candidate set widened. - test_the_completeness_check_can_fail drops a real tool from its set and asserts it is noticed (rule 167). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 12:31:04 -04:00
bvandeusenandClaude Opus 5	4e4020c040	feat(rules): move a rule between global and project scope, keeping its id, history, areas and edges (#4063) ... A rule's home is its reach: a rulebook topic makes it global, a project makes it that project's. There was no way to change one, so a project rule decided to be global could only be recreated and the original trashed — losing the id every record cites, its edit history, its area tags and its relations. - services.rulebooks.move_rule(rule_id, user_id, topic_id= | project_id=): exactly one destination (the model's CHECK), owned by the caller, not the rule's current home. A topic already holding a live rule with the same title is refused with a message naming that rule, instead of uq_rule_per_topic failing the commit. Someone else's rule reads as not found. - Deliberately NOT done, and said in the docstring: no version (a version is what a rule said, milestone 323 decision 4), no duplicate gate (nothing new enters the corpus), no re-embed (retrieval reads the home at query time). - Both doors: MCP move_rule, REST POST /api/rules/<id>/move (rule 33). - UI: RuleHomePicker, one component in the rule editor (a global rule) and a project's rules tab (a project rule), so the two cannot drift on what a destination is. - using-scribe names move_rule under "Where a new rule goes". Plugin 2026.09.15.1626. Milestone 414 step 3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 12:26:39 -04:00
bvandeusenandClaude Opus 5	b6751e4214	test(backup): pin BACKUP_VERSION 15 (#4052) ... The subscription and suppression sections left the payload in 0bcd4b5; the version moved with them and the pin did not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 12:22:31 -04:00
bvandeusenandClaude Opus 5	0bcd4b5540	feat(rules)!: retire rulebook subscriptions and per-project suppressions (#4052) ... A rule's home is its scope now: a rule in a rulebook topic is global, a rule on a project applies to that project, and retrieval reads that directly (#4074). A subscription had stopped changing anything a session received; a suppression muted rules from a subscription. Operator, 2026-09-15: "we have global and project scoped rules, we don't need the subscriptions now." What goes, whole (rule 22): - Migration 0101 drops project_rulebook_subscriptions, project_rule_suppressions and project_topic_suppressions, and strips subscribe_rulebooks (and 394's leftover exclude_always_on_rulebooks) from stored inception choices. - Service, MCP and REST: subscribe/unsubscribe and the four suppress/unsuppress operations. The Subscribers checklist, the subscribe chips, the skip buttons and the Suppressed section in the rules UI. - Inception asks two questions (design system, seed Systems). create_project and decide_project_inception lose subscribe_rulebooks. - Backup v15 stops exporting the three sections; older archives still restore, the keys simply unread. Trash no longer hard-deletes suppression rows. What changes meaning: - get_applicable_rules is a project's LISTING: its own rules, plus the global rules tagged to an area it works in. Untagged global rules apply everywhere and arrive by retrieval, so they are not listed. A co_surfaces partner on a different project is not dragged in. - list_rules(project_id) lists that project's own rules. - rules_payload drops subscribed_rulebooks and suppressed_*; the handshake's brief form is project_rules alone. - using-scribe's "Where a new rule goes" and inception sections, tool docstrings and docs say global vs project. Plugin 2026.09.15.1620. Milestone 414 step 2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 12:20:57 -04:00
bvandeusenandClaude Opus 5	188e78bbcd	feat(rules): retrieval honours a rule's home — global everywhere, a project's rules only in that project (#4074) ... semantic_search_rules searched every rule the user owned, and every hook arm called it without a project, so each project's rules were injected into every other project's sessions and a project rule meant nothing a session could feel. The search now takes a scope: global rules by default (an unbound session, or a caller that forgets to say), global plus project N when given project_id (N's rules only if the caller can read that project, through access.can_read_project), and every owned rule with everywhere=True. The four hook arms and the report preference lookup pass the session's project; an explicit search(content_type="rule") scopes to its project_id, or asks the whole rulebook without one. Milestone 414 step 1. Guarded by an AST walk that every hook call site passes project_id, and an integration test on real Postgres that a rule is reached only from its home. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 12:06:34 -04:00
bvandeusenandClaude Opus 5	7f974d9749	feat(mcp): enter_project becomes a small primer: goal, recent work, open work, vocabulary (#4045) ... The handshake carried the whole project record, every milestone's plan, full rule text, the notes most recently edited and ~9k of design guidance. For project 2 that was ~222k characters, past what an MCP client accepts as a tool result. Each category was walked through with the operator and sized to what a session needs on arrival; each names the call that has the rest. - project: id, title, status and the full goal (session start's "full goal" pointer still lands here). get_project keeps the whole record. - milestone_summary: the 5 most recently touched milestones, any status, most recent first, without plans. Summaries gain last_touched_at: the later of the milestone's own edit and its newest step update, from the query that already counts steps. milestone_summary_omitted counts the rest and points to list_milestones. get_project and list_milestones list every milestone, also without plans. - open_tasks: the 10 most recently touched open tasks, with or without a milestone, each naming its milestone. list_notes gains sort="touched" (the later of updated_at and the newest work-log), because a log doesn't bump updated_at. - recent_notes: dropped. Retrieval surfaces notes by relevance, and get_recent covers recency. - systems: id and name. - design_system: summary plus guidance_call. get_design_system gains resolved_guidance, the chain-merged prose; its own guidance field is only the departures, so session start's old pointer to it led to a fragment. The session start pointer and using-scribe's "Building UI" section now name resolved_guidance. - rules: rules_payload(brief=True) gives project_rules as id and title plus subscribed_rulebooks, and records only what it shows. Retrieval delivers rules in full and ignores subscriptions (#4052). Other callers unchanged. - pattern_coverage, inception and systems_bootstrap: unchanged. Clients: the plugin's using-scribe skill, the compaction notice and session start are updated here; the REST project summary only gains last_touched_at. Plugin version minted. Tests: a size ceiling on the handshake for a large project; milestone and task selection and naming; brief rules; resolved_guidance; the session start pointer; and a real-Postgres test that a work-log touches its task and a step update touches its milestone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-14 22:04:38 -04:00
bvandeusenandClaude Opus 5	9b2de3552f	fix(mcp): project reads list milestones without their plans, and cap done ones (#4045) ... enter_project returned every milestone's full plan body. On a project with 39 milestones the handshake came to ~222k characters, 168k of them bodies (110k from done milestones). That is past what an MCP client accepts as a tool result, so the call meant to orient a session arrived as a file to page through. It grows with a project's history, so any long-lived project on any install gets there. - brief_milestone_summary (services/milestones.py) trims summary rows to the listing fields: id, title, description, status, order_index and progress. The plan is get_milestone's job. user_id, project_id and timestamps repeat what the caller knows. - enter_project and get_project share one block: every open milestone plus the 5 most recently updated done ones, in order. milestone_summary_omitted is attached only when older done ones were left out, and names list_milestones and get_milestone. - list_milestones lists every milestone, done included, without bodies. It is the call the omitted line points to, and it had the same size problem. - The REST project summary is unchanged; the web UI reads it. Tests: trimming, the done cap and its order, the omitted key present and absent, get_project and list_milestones, and a size ceiling on enter_project's milestone block for a 200-milestone history. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-14 19:48:24 -04:00
bvandeusenandClaude Opus 5	0fab08276c	fix(plugin): an early-exiting head no longer voids its own output under pipefail (#4042) ... In a repo where 3,000 files define `slug`, scribe_local_dups printed nothing; with 3 files it printed the duplicate line. Every hook runs under `set -uo pipefail`, and `hits=$(git grep -l … | head -4) || hits=""` lost head's four lines whenever git grep was still writing when head exited. That is a SIGPIPE, the substitution fails, and the outer fallback wipes the result. So the by-name duplicate arm went silent for exactly the most-duplicated names. Found while fixing the same trap in the new Stop hook (#4041). - The fallback moves inside the substitution, `$(… | head -N || true)`, at all five sites: scribe_defs.sh (local dups), scribe_prior_art.sh (names, old_first, shapes) and scribe_after_write.sh (names). A real upstream failure still yields empty output. - check_plugin gains a known-bad pattern for the shape, so no hook can bring it back. - Tests: the real function against a 3,000-file repo (past the pipe buffer), and the pattern shown to flag the old shape and pass the fix. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 18:54:49 -04:00
bvandeusenandClaude Opus 5	c7531d3700	fix(409): the report check's prefilter no longer depends on compact JSON (#4014) ... CI run #517 failed five of the new hook tests, all of them expecting a request that never went out. The prefilter matched `"name":"…update_task"` with no space after the colon, which is how Claude Code writes its transcripts, while the tests wrote theirs with json.dumps defaults (`"name": "…"`). The hook exited at the prefilter for every test transcript. The silent-case tests passed for the same wrong reason. - The prefilter now allows whitespace after the colon. The jq parse behind it never depended on formatting. - The test transcripts are written compact, matching the real file. The silent-case tests now reach the turn parse rather than stopping at the prefilter. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 18:37:13 -04:00
bvandeusenandClaude Opus 5	dd80e2bc86	feat(409): a Stop hook checks that a reply closing a task has the completion sections (#4014) ... Everything else Scribe gives an agent arrives before the reply is written. A Stop hook is the one moment the finished reply exists, so it is the last chance to fix a report the operator can't read, and the only place adherence to the shape can be measured. - plugin/hooks/scribe_report_check.sh (Stop): deterministic, no model call. 1. Did this turn close a task? That means an update_task/create_task call with status "done" since the turn's prompt, whose tool_result is not an error. Otherwise it stays silent, which covers most turns (one grep). 2. Does the reply that ends the turn say where the work sits (a record by id and title, or step N of M), what needs the operator, and what comes next? Matched on those words, not on exact headings. 3. If sections are missing, it blocks once. With stop_hook_active set, a rewrite is recorded (passed_after_rewrite / missing_after_rewrite) and never blocked again. A block loop started by another plugin (no marker from this hook) is left alone. - Measured: every checked reply is reported to GET /api/plugin/report-check (passed / blocked / after rewrite). Turns that close nothing are not reported; they would cost a request per turn and add nothing to the rate. Outcomes go to app_logs as category "plugin", action "report_check". - It blocks only when the block was recorded, and only in the server's words. The endpoint returns the block reason, so the hook carries timing and transport only (PACKAGING.md), and an unconfigured or unreachable instance never stops a session. - The transcript format is read from real transcripts and marked in the hook as observed rather than documented. The Stop contract (transcript_path, stop_hook_active, decision/reason, no matcher, SubagentStop separate) was checked against the Claude Code hooks docs. A prompt-type hook was not needed: the deterministic check passed a real completion report from this session and blocked a stripped one. - A pipefail trap was caught while exercising the hook: `tail | grep -q` reports failure exactly when grep matches, because tail dies of SIGPIPE. The prefilter reads through process substitution; the section checks use here-strings. - Tests: an end-to-end hook suite over synthetic transcripts and the shared HTTP sink (silence, pass, server-worded block, rewrite recorded, foreign loop, errored write, earlier turn, unwritten reply, no recorded check, bare id), and service tests for the reason wording and the outcome record. Smoke event added to check_plugin; README and PACKAGING list the hook and endpoint. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 18:34:46 -04:00
bvandeusenandClaude Opus 5	921565696c	feat(409): an operator's own reply shapes reach the reply they are about (#4013) ... The reporting-back skill ships default shapes; an operator's adjustments to them are preference records. Prompt-time retrieval matches the operator's message, and a shape preference is about the reply, so those preferences were on file and never arrived. Operator's decision (logged on #4013): the server delivers them for a completion report, and the skill asks for every other kind. - Completion reports (option C): closing a task with update_task runs a kind-filtered preference search for the moment "writing the completion report after finishing a task" and returns matches as `reply_preferences` ({id, title, statement, kind}), with a sentence added to `report_back` naming the key. A preference says it is about completion reports through its own when_to_apply; no tag or column. Omitted when nothing matches, and the lookup fails open. - Telemetry: every call logs to retrieval_logs under `report_preference` (empty calls included; a search that never ran writes no row) and hits are recorded surfaced. The source is ranked, so it counts toward pull-through. The bar is the prompt arm's setting until step 6 reads this source's near misses. - Every other reply (option A): reporting-back gains "The operator's own shapes come first". Before a finding, decision, handoff or "where are we", search(content_type="rule") in the words of that moment and follow what comes back. Registered in the ownership guard with reporting-back as owner. - Loading reply shapes at session start (option B) was rejected: it would be a small copy of the preloading milestone 394 retired. Domain-neutral query (pinned); works on an install with no preferences. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 17:43:16 -04:00
bvandeusenandClaude Opus 5	9071cb05da	fix(410): using-scribe states the retrieval reflex once, and the adapter stops restating it (#4039) ... Step 7's live check (#4034 "a real session shows each topic stated once") found nothing copied across surfaces, but found the owner repeating itself: using-scribe said "rules are retrieved; ask before a consequential act; an empty session is not an empty rulebook" in "Do this first", in reflex 2, and twice more further down reflex 2. - using-scribe: reflex 2 now holds the one full statement (how rules arrive, why that is the surface working, what silence means, when to ask). "Do this first" keeps the enter_project step and a short lead-in pointing at reflex 2. "A retrieved rule outranks a default habit" and "Ask hardest where you feel most certain" stay, since each adds something. - Adapter static context: "Lines injected beside your work" keeps only the Claude Code timing and leaves "never the whole set" to the skill. "Keep one copy" names CLAUDE.md and auto-memory and points at using-scribe, which already says to leave a client's settings as they are. - The ownership registry's markers and statement for the topic still sit on using-scribe, and nothing else changed owner. Plugin version minted. Sizes: using-scribe 18,823 -> 18,197 chars; scribe_static_context.md 1,797 -> 1,714. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 16:01:34 -04:00