14 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	f1fdc4a951	feat(moments): skills and stored processes declare the moments they are for (milestone 458 step 5, #4923) ... Loading a procedure now also reaches the moment it is for. Loading the reporting procedure is a report; loading the release procedure is a delivery. - Bundled skills: each SKILL.md declares `metadata: moments:`. The same declaration ships as Skill defaults (BUNDLED_SKILL_MOMENTS), because the server never sees the plugin's files. test_skill_moments holds the two together and pins the plugin name that qualifies the skill. - Stored processes: `moments` on create_process and update_process, stored in the note's data and returned by get_process. A `scribe-proc-<slug>` load resolves its process through the sync manifest at load time. The moments are not copied into the stub, which would go stale mid-session. - reachable_tools lists the skill loader whenever anything is mounted, since a process's moments are known only when it loads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 14:23:24 -04:00
bvandeusenandClaude Opus 5.5	b3b616b20a	fix(moments): the tools import the delivery module, and the tool-list cache leaves the swept directory (milestone 458 step 4a, #4922) ... Two guards caught 7865313: - test_mcp_tool_processes reads every coroutine in a tool module's namespace as a tool, and a name-imported attach_moment_rules looked like one. All seven modules now call moment_delivery.attach_moment_rules, and the parity guard accepts the attribute form. - The session-ledger convention: a file in a swept directory must be a .ids ledger. The tool-list cache describes the install, not the context, so it moves to its own directory, scribe-moment, where a compaction does not sweep it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 12:24:30 -04:00
bvandeusenandClaude Opus 5.5	78653130d6	feat(moments): mounted rules arrive when their moment happens, through every door (milestone 458 step 4a, #4922) ... A rule mounted on a moment now reaches the session when an act reaches that moment, with no semantic match involved: - run_moment_arm on the pipeline: a lookup, not a ranked search. Each line names the moment and the act that reached it ("at work.deliver, reached by `git push`"), so a misfire is visible where it lands and can be unmapped in-session. A repeat is cited, not quoted; fresh rules are recorded surfaced under source moment_rule with the moment in detail. No retrieval_logs row, as for the other lookups, so no latency is persisted for this arm. - rule_scope: a rule's home clause, moved out of semantic_search_rules so the moment lookup scopes by the same one. - rulebooks.rules_on_moments / mounted_moments. - The plugin door: a catch-all PreToolUse hook (scribe_moment.sh). It keeps /moment-tools' answer on disk for five minutes, so a call to a tool that cannot reach a mounted rule sends nothing, and an install that has mounted nothing sends one request per window. It shares the rules ledger with the other arms and fails open silently. - The MCP door: Scribe's own tools named by the shipped mappings carry moment_rules in their response, so a client without the plugin gets them too. The hook skips those tools. A guard pins the attach on every one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 12:21:45 -04:00
bvandeusenandClaude Opus 5	43ed7f4db7	fix(access): tag a record as the user doing it, not as its owner (#4249) ... `set_record_systems` is not a dumb setter. It runs its own `can_write_note` and then links only the Systems the given user can READ. Four of twenty call sites handed it the record's owner instead of the acting user, which did two quiet things at once: the access check became trivially true, since an owner can always write their own record, and the System filter used the owner's visibility rather than the actor's. On a single-user install neither is observable. With a share it is an editor acting with the owner's reach — the shape rule 47 exists to prevent, and the same reasoning routes/notes.py already spells out for `set_supersedes` two lines away. This is NOT a permission change. Every one of the four sites establishes the caller's write access first: routes/lessons.py and routes/snippets.py call `can_write_note(uid, …)`, mcp/tools/processes.py does the same, and mcp/tools/snippets.py reaches `set_record_systems` only after `update_snippet` has raised PermissionError if the caller may not write. So nobody gains or loses the ability to edit anything. What changes is whose reach the tagging runs with, which is exactly the kind of difference that survives review because every call site reads fine on its own. The four: routes/lessons.py:243 owner_uid -> uid routes/snippets.py:211 owner_uid -> uid mcp/tools/snippets.py:486 note.user_id -> uid mcp/tools/processes.py:196 note.user_id -> uid The last one was written earlier in this same session, an hour before the sweep that found it, with a comment confidently explaining why the owner was correct. That is the argument for the guard rather than for care: the unified stance was known and still got it wrong at the next opportunity. So the guard is the point again. `test_every_tagging_write_acts_as_the_caller` walks every `set_record_systems` call in src/ and asserts the first argument is a bare local named `uid` or `user_id` — an attribute access is a record's owner by construction. Verified against `git show HEAD:` as well as the working tree: clean now, four offenders on the code it replaces. Reads are deliberately untouched. `list_record_systems(owner_uid, …)` gates on reading the NOTE, which the caller can do anyway, so it returns the same list either way; it is a different operation and churning it would add noise without changing behaviour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-21 16:09:41 -04:00
bvandeusenandClaude Opus 5	e2e1ea3667	fix(systems): a record can be filed under a System from whichever door wrote it (#4249) ... A System tag is how `list_system_records` gathers an area's pile, so a record that cannot be tagged is reachable by search and by nothing else. `update_lesson` did not take `system_ids` while `create_lesson` did, which made tagging available exactly once — at the moment of least information. A lesson is usually written at the end of a piece of work, which is precisely when that argument gets dropped, and after that the record could never be filed at all. Filling in the rest of the table found three more gaps, and the issue's own generalisation was wrong. It read as "the REST door can do something the MCP door cannot", on three instances in a row. In fact: * `create_preference` is the exact MIRROR of the lesson bug — update takes `system_ids`, create does not. The same capability missing from the opposite end of the same lifecycle. * `routes/notes.py` handled `system_ids` NOWHERE, while the MCP door handled both ends. That runs the opposite way round from the premise. * `create_process` / `update_process` took it at neither door, though a process is a note and has always been taggable in the data model. The real pattern is that whichever door nobody exercised for a kind is the one that never grew the parameter — which is a better statement of #4248 than the one recorded there, and is not something a reviewer reliably notices, because each door is only ever read on its own. Milestones are NOT a fifth gap. `RecordSystem.note_id` is a ForeignKey to `notes.id` and milestones are their own table, so they cannot be tagged at any door by construction. Pinned in the test so the next pass does not re-open it. So the guard is the point, not the four parameters. `update_lesson` alone would have left the shape that produced it intact. The new test asserts the TABLE — every kind taggable anywhere is taggable everywhere it is written — and keys the registry-coverage check on the SIGNATURE rather than on a grep, so a module that only names the argument in prose is not swept in and no hand-kept skip list can go stale. A fifth kind fails there rather than shipping half-wired, the same reasoning test_derived_mirror_generic_door.py records for derived mirrors (#3734). One inconsistency found and deliberately not changed here: for the same operation `routes/tasks.py` scopes `set_record_systems` by the caller while `routes/lessons.py` and `routes/snippets.py` scope it by the owner. The new notes code follows tasks.py and says why in a comment (#47 — an editor-share holder should tag from what they can see rather than inherit the owner's reach). Recorded in #4249 rather than fixed as a drive-by. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-21 16:02:16 -04:00
bvandeusenandClaude Opus 5	a4aae974a2	feat(telemetry): a usage event records which project the reader was in (#4196, #3735) ... `RetrievalLog` has carried `project_id` since it existed, so "this record was SURFACED on project B" was always answerable. `note_usage_events` had none, so "this record was OPENED on project B" was not — and the two cannot be joined to recover it, because there is deliberately no session identity server-side. NoteUsageEvent's own docstring rules that out. That gap sat exactly on the question milestone 385 exists to answer. A lesson's whole claim is that it reaches a session on a project it was not written on, and step 8's acceptance is "retrieved on a different project AND opened". Each half was answerable; the conjunction was not. WHICH project, because the name is ambiguous and the wrong reading makes the column useless: it is the project the READER was in, never the one the record belongs to. The record's own project is already on the note; copying it here would answer a question nobody asked while looking like it answered this one. The surfacing half is free — every arm already holds the scope it just searched, so auto_inject, lesson_slot, the write-path arms and enter_project now record it. process_skill_sync does not and should not: it installs every Process the operator can reach, which is not a project-scoped question, so a project there would be a fiction. The pull half needs the caller, since a getter knows only what it was handed. The five single-record getters take `project_id: int = 0` and pass it through, following the convention `search` and `create_*` already set. Null stays an ordinary answer meaning "not reported" — a pull with no project is still a pull and still counts toward dead weight; it simply cannot speak to transfer. The four REST detail views report none for now: a human opening a record in a browser is a different event from an agent recalling one, and #2245 left that asymmetry deliberately undecided. Guarded the way #2245 and #2476 taught: by source inspection, because a parameter that was never threaded through changes no return value and shows up only as a column that is mysteriously always null. Three guards — the signature, the pass-through, and the arms — plus the can-fail test rule 167 asks for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-19 23:26:55 -04:00
bvandeusenandClaude Opus 5	16805ca22c	docs(mcp): every create_* tool says what it is NOT for (#3123) ... Scribe's record kinds get reached for interchangeably, and the moment of choice is the only moment a correction is cheap. Rule 119 puts product guidance in the instruction surfaces, so the docstring is where this belongs — but a docstring that only documents parameters answers "how do I call this" and leaves "should I be calling this at all" unasked. The gap was lopsided. create_rule and start_planning already carried real disambiguators; create_note — far and away the highest-volume surface — carried none at all. The guidance sat in the rarest tool and was missing from the most common one. Each surface now opens with ONE deciding question in its own terms rather than a pasted block: create_note WHAT ELSE COULD HOLD THIS? note is right when nothing is owed and nothing enforces create_task IS ANYTHING ACTUALLY OWED? nothing owed -> note; an arc -> start_planning create_snippet SHAPE, OR ADVICE? a snippet is code with a LOCATION create_process FOLLOWED, OR READ? applies uninvoked -> rule create_project_rule now points at the entity check too; it had only ever covered rule-vs-rule scope. The guard asserts STRUCTURE, never wording: each surface must name at least two siblings. Pinning phrasing would make every improvement a test failure, and a test that punishes editing is a test that gets deleted. Its second half asserts the Args: block survives — the first check is satisfiable by turning a docstring into an essay about the other tools, which would be a worse contract than the one being fixed. The guard caught two gaps on its first run, one of them its own: "design system" is hard-wrapped across a line break in create_rule, so matching the raw docstring reported it absent. _doc() now flattens whitespace. It also caught start_planning naming only one alternative, which was true and is now fixed. Deliberately NOT built: an intent-router tool. It has a bootstrapping problem — it is itself a tool that must be reached for — and MCP clients already list every tool's description. Recorded in #3123; build it only if wrong-surface reaches survive this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 18:18:42 -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	5cb7cfe706	feat(processes): authoring contract — a process is a shape, never a script ... Operator's generalization of #2582: the benefit of nearly every stored process is the accumulated SHAPE — steps, taxonomy, quality bar — and a process must not force anything or overwrite the intent of the request that invoked it. create_process now states the authoring side of the composition contract: no embedded approach mandates, no pre-granted approvals, clarify steps seed from the conversation instead of re-asking it. (All three stored processes were also audited: DRY Pass and Rulebook Review were already propose-approve-apply with no forcing language; both gained the seeded-clarify line — data changes, live already.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-10 09:40:23 -04:00
bvandeusenandClaude Fable 5	9c68faa0bd	feat(processes): composition contract — the process is the skeleton, the conversation supplies the parameters ... Extends #2582's fix per the operator's direction: a stored Process must incorporate the context it was triggered with, not displace it. No new plumbing needed — the live context is already in the session; what was missing is the stated contract. get_process now carries it: live constraints/scope/focus fold into the procedure and override its defaults where they disagree; a clarify step asks only what the conversation has NOT already answered (confirm interpretations, don't re-ask); stated concerns become lenses the procedure applies, not text it discards. The sync-generated skill stubs state the short form. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-10 08:39:02 -04:00
bvandeusenandClaude Opus 5	63c213b617	fix(processes): the least-equipped kind is the one that gets followed ... Survey pass 3 (#2250) tabulated capabilities per record kind. Processes came out lowest on every column, and they are the kind with the most authority: build_process_manifest turns each one into a skill file on the operator's machine that auto-surfaces and is followed as written — its own docstring calls it "the most consequential passive surface Scribe has." Three gaps closed. NO PULL TELEMETRY (#2476). get_process recorded nothing, while the auto-inject menu header names get_process as the way to open that kind. Every note is embedded regardless of note_type, so a Process is surfaceable — and the getter the product points at was the one getter that recorded nothing, leaving every Process permanently at zero pulls and looking like dead weight beside kinds that merely had a counter. get_note's own comment already listed processes as a reason to record pulls. The fix for #2245 covered notes, tasks and snippets: it enumerated the kinds someone thought of rather than the kinds that exist. NO DEDUP GATE. create_process had no near-duplicate check and no force flag, while notes, tasks, snippets and rules all have both. It matters more here than elsewhere: two near-identical procedures don't just bloat the corpus, they compete to be followed, and which one wins is decided by a slug collision. NO DELETE. list/create/get/update, no delete — a kind that reads as one you cannot retire. Deletion was always possible via delete_note, since a Process is a note and the trash is kind-agnostic, so this was discoverability rather than capability. delete_process checks note_type before trashing: the tool is reached for by name, and letting it destroy an ordinary note whose id happened to resolve would be a destructive action taken on a mistyped argument. THE GUARD, which is the part that stops a fourth repeat. tests/test_mcp_pull_telemetry.py discovers every get_* MCP tool by AST and requires a record_pulled from any that loads a single note. Not a list of getters — a get_<newkind> added tomorrow is covered the moment it loads a note the way the others do. get_milestone is correctly excluded: it calls list_notes for a milestone's steps, which is a surfacing, not an opening. The loader NAMES are a list, and that residual weakness is pinned against a rename rather than papered over. An earlier draft tried to discover new loaders by return annotation and would have failed on create_note — which also returns a Note. Readers and writers aren't distinguishable by type, so the honest version is a pinned list, a non-empty assertion, and a docstring saying which hole remains. test_register_attaches_four_tools became a derived check of the module's public coroutines, so the next tool added can't be left unregistered. MCP _INSTRUCTIONS updated: product behaviour belongs in the instruction surfaces, not in a rule (rule #119). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 16:32:05 -04:00
bvandeusenandClaude Opus 5	3ffdbbc521	fix(acl): align MCP writes with the share model — editor edits, viewer doesn't ... Option B, per the operator. Closes the last inconsistency from the ACL work. The agent path had drifted into an indefensible position: delete_snippet honoured editor shares (I made it share-aware so widening the read wouldn't let a VIEWER trash things) while update_snippet still resolved through the owner-only notes.get_note. So through an agent you could destroy a colleague's snippet but not improve it — and the refusal claimed "not found" for a record you could plainly open. Now update_snippet, merge_snippets and update_process all resolve the read scope and then require can_write_note, matching the REST routes and the sharing UI's own promise that viewer / editor / admin are distinct grants. A viewer grant is refused with the actual reason ("shared with you read-only — ask its owner for edit access, or record your own version"), because not-found would send an agent hunting for a missing id instead of recording its own copy. Authorised writes are performed as the OWNER, since the underlying note update is owner-scoped and a shared editor's own id would match nothing. Merge additionally requires each source to share the TARGET'S owner and to be writable by the caller — merging trashes the source, so read access isn't enough, and cross-owner merge stays out of scope (#231). Sources failing either test are skipped rather than half-merged. A record the caller cannot read at all still returns not-found rather than forbidden, so the error can't be used to confirm that an id exists. Also fixed _fake_snippet's missing user_id proactively — the same auto-MagicMock-reads-as-foreign trap that broke CI twice (see note 2109). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLwAaV4DQEmVyn496HnEvt	2026-07-26 00:04:48 -04:00
bvandeusenandClaude Opus 5	04b58ce01e	feat(acl): shared records are search-only and always labelled as someone else's ... Narrows the b7d6fc7 widening per the operator's call, and fixes a regression it introduced. Decision recorded as note 2094. Two scopes now, deliberately different: readable_notes_clause — everything the ACL permits, including records reached only via a direct/group note share. For EXPLICIT acts: a search the caller typed, a fetch by id. browsable_notes_clause — the caller's own records plus anything in a project they can reach. For PASSIVE surfaces: browse lists, facet counts, the process->skill manifest. The split is a trust boundary. Anything appearing unasked — in your own list, your own counts, or as a skill installed on your machine — reads as material you endorsed. A one-off someone shared with you hasn't earned that standing, so it waits until you go looking. This also dissolves the shared-Process problem by construction rather than by special case: the manifest is a passive surface, so a directly-shared Process is never installed as an auto-surfacing skill. Regression fix (#2093): b7d6fc7 widened the list queries but left the fetch path owner-only, so on the MCP path a record could be listed and then not opened — get_snippet raised not-found, get_process couldn't resolve, and the manifest emitted stubs whose get_process call would fail. snippets.get_snippet and notes.resolve_process now resolve the read scope. delete_snippet gained an explicit can_write_note guard, since being able to SEE a shared snippet must not imply being able to bin it. Provenance, so nothing arrives looking like the operator's own work: - access.describe_provenance / label_shared_items add shared/owner/permission; labelling costs no query when everything is the caller's own. - MCP: get_snippet, list_snippets, get_process and list_processes carry it, and get_process now says outright NOT to follow a shared process verbatim — its follow-as-written contract was the sharpest instance of the problem. - The skill stub for a shared Process names its author and asks for a go-ahead, instead of describing it as "the operator's saved Scribe process". - Policy stated once in the MCP _INSTRUCTIONS and the reusing-code skill: a shared record is that person's suggestion, weigh it, attribute it, ask before adopting it. - UI: shared snippets show "by <owner>" in the list and a notice above the code in the detail view, reusing SharedWithMeView's vocabulary. Plugin 0.1.15 -> 0.1.16 (skill text changed). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLwAaV4DQEmVyn496HnEvt	2026-07-25 22:43:00 -04:00
bvandeusenandClaude Opus 4.8	b255a0f90e	refactor: rename package fabledassistant -> scribe (code-only) ... Renames src/fabledassistant -> src/scribe and all imports, plus the default DB name and DB user/password (fabled -> scribe) in config + compose. 952 refs / 154 files. Reverses the old 'internal name stays fabledassistant' convention. Code-only: live databases are still physically named 'fabledassistant'. Deployed environments must set POSTGRES_DB / POSTGRES_USER (or rename the DB) since the defaults now resolve to 'scribe'. Repo (FabledScribe), git host (fabledsword), MCP (fabled-git) and the image name (fabledscribe) are intentionally unchanged. ruff check src/ clean locally; CI (typecheck + pytest) is the gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-03 15:48:35 -04:00