12 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	5c9bb40777	feat(rules): a session is told when its rules move under it (#3244, milestone 323 step 5) ... The rules payload carries a marker; the write-path hook hands it back; the server says which rules moved. Nothing is said when nothing moved. THE COUNT IS NOT DECORATION. max(updated_at) alone cannot see a DELETED rule — it moves no timestamp — and that is the single change that takes an instruction OUT of force, which is the one a session most needs to hear about. The marker is `<max updated_at>|<count>`, and a deletion is reported through the count because there is no row left to name. THE HOOK IS THE CARRIER because it already fires before a write, which is the moment acting on a stale rule costs something. One comparison, no payload, no extra round trip. WHERE THE MARKER IS CAPTURED, and it could not be anywhere else: the SessionStart hook, from /api/plugin/context. The model also receives one from list_always_on_rules, but a hook cannot see an MCP tool's result — so the value the write path compares has to be stored where a shell script can reach it. Keyed by session id in the state dir the prior-art hook already uses, so "changed since" means since THIS session loaded its rules. NOT ON rules_payload, against the task's letter. Those are applicable_rules — a different, subscription-derived set. One key name over two sets is how a comparison starts reporting phantom changes, and the write path compares against the always-on set. WHAT IT CANNOT SEE is stated in both the service and the write-path arm as a table, because a reader who finds an etag will assume it covers staleness generally: another session edits a rule mid-flight | caught the session is misremembering a rule read hours ago | caught compaction summarised the rules out of context | NOT caught The third is the most common, and the marker is blind to it — the etag was in context too and went with the rules. The SessionStart nudge is that case's only mechanism and must not be softened because this shipped. A test asserts both modules still explain that. Instance-agnostic (rule 115): an install with no rules produces a stable marker rather than an error, and "no rules" reads as a state rather than as a change. An unreadable or absent marker reports nothing — a signal that cries wolf is worse than none, because it trains a reader to skip the line that will one day be true. The arm fails open like every other arm on this hook. The delivery is tested through the real build_write_path_hint rather than the helper alone: the feature IS a line arriving in a session, and the arithmetic being right proves nothing about that. Live acceptance is deploy-gated and not yet recorded on the task. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 13:02:00 -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 Opus 5	841506b10c	feat(plugin): every session says which plugin version is executing ... Twice a shipped fix failed to reach a live install, and both times the only detector was the operator saying "I don't think it updated" (#2198, #2209). The reason it is hard to see: an install has two halves and only one self-updates. The marketplace clone pulls on its own; the CACHE is what executes and refreshes only when the manifest version changes. So inspecting the clone shows the fix present while the broken copy keeps running — the obvious debugging move actively misleads. The SessionStart context now names the version it is running. That makes "what is actually executing?" answerable from the transcript rather than by archaeology in the cache directory. DELIBERATELY SMALLER THAN THE ISSUE PROPOSED. #2220 recommended reporting the version to the server, storing last-seen per user, and surfacing it in Settings. That is three surfaces and a migration to answer a question the session can answer about itself. Per the operator's framing on #2338 — "I'm afraid of building another integration between two more surfaces, you being able to notice is enough" — the visibility is the deliverable, not the plumbing. It also lands the issue's own caveat, which the server-side design could not: the state most needing diagnosis is the one where credentials never arrive, and there the dynamic tier does not run at all. This marker is keyless and networkless, so it still appears — verified against both the unconfigured and unreachable-instance paths. CI pins it, asserting WITHOUT credentials for the same reason. Manifest 0.1.22 -> 0.1.23, because a shipped hook changed and an unbumped manifest is precisely the failure this commit is about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:57:33 -04:00
bvandeusenandClaude Opus 5	b0a0bf8abd	fix(plugin): justify the one shellcheck finding (SC1007, false positive) ... First CI run with shellcheck (run 3029) flagged exactly one thing: scribe_session_context.sh:44 SC1007 Remove space after = if trying to assign a value here=$(CDPATH= cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd) `CDPATH= cd` is the deliberate POSIX idiom for running a single command with CDPATH empty — it stops `cd` resolving through the operator's CDPATH and echoing the resolved path into our stdout, which for a hook whose stdout IS its protocol would be a real bug. shellcheck cannot distinguish that from a typo'd `CDPATH=cd`, so this is a false positive. Scoped `# shellcheck disable=SC1007` with the reason above it, matching how CI-runner's own scripts/install-common.sh handles SC2086. One line-scoped disable, no file-level or blanket suppression — a lint you silence broadly stops being a lint. Everything else in that run passed, including the parts that could only run once jq was installed: all four hooks exit 0 and stay silent unconfigured and against a refused connection, with the session-context hook correctly still emitting its static floor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 22:43:30 -04:00
bvandeusenandClaude Opus 5	c569cdd0eb	fix(plugin): every hook's credential + URL encoding was broken ... Three defects, each of which independently made a hook a no-op, and all three failing silently — which is why the whole dynamic side of the plugin looked "shipped" while doing nothing. 1. Wrong env var case. Claude Code exports userConfig to hooks as CLAUDE_PLUGIN_OPTION_<KEY> with the key UPPERCASED. All four hooks read CLAUDE_PLUGIN_OPTION_api_endpoint / _api_token, so both values were always empty. That killed the SessionStart dynamic tier, process sync, prompt auto-inject, and the write-path prior-art trigger at once. 2. jq -rR is line-oriented. `@uri` under -R encodes input LINE BY LINE, so a multi-line payload came back as several encoded lines joined by raw newlines — an invalid URL, curl fails, hook exits 0 in silence. Now -sRr. This one hid behind (1): auto-inject only ever worked for single-line prompts, and prior-art (which posts code, always multi-line) could never have worked at all. 3. cut -c1-1200 caps each LINE, not the payload, so the prior-art code budget wasn't a budget. Now head -c 1200. Also widens the SessionStart warning: "neither URL nor token arrived" used to be treated as a benign unconfigured install and stayed quiet. That is exactly the state defect (1) produced, so the one install state that most needed a signal was the only one that emitted none. It now says so, and names the two other features it silently disables. Verified against the live instance: dynamic rules + project context load, auto-inject surfaces #2192 on a multi-line prompt, and the write-path trigger returns the [here] place-arm hit on a multi-line edit with session dedup suppressing the repeat. Refs #2198, #2082 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 18:00:11 -04:00
bvandeusenandClaude Opus 4.8	f6629d4bcf	fix(plugin): keep always-on rules alive across compaction (0.1.10 → 0.1.11) ... Always-on rules were on-demand, not always-present: Tier-1 static context only tells the agent to call list_always_on_rules(), and Tier-2 dynamic fetch is dark (token doesn't reach the hook subprocess). On compaction the fetched rules get summarized away while the harness's own built-in git instruction ("branch first") survives in the base prompt — so post-compact the generic git instinct wins and rule #1 ("dev is home") is missed. - scribe_static_context.md: new "Operator rules govern consequential actions" bullet — before any git branch/commit/push or hard-to-reverse action, loaded rules beat generic harness/default habits; re-pull rules if not loaded or summarized by a compaction. Tier 1 = always fires, keyless, re-fires on compact. - scribe_session_context.sh: compaction banner now re-pulls list_always_on_rules(), not just enter_project(). - plugin.json: 0.1.10 → 0.1.11 so autoUpdate ships the plugin/ change (#1040). Generic and instance-agnostic per rules #115/#119 — no operator-specific rule text hardcoded. Refs issue #1197. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4bNefPFAz7esmMZMZmkzL	2026-06-30 12:41:45 -04:00
bvandeusenandClaude Opus 4.8	d99c4e3c15	feat(plugin): compaction re-grounding in SessionStart hook (A7) ... Deliver 'don't silently lose work at compaction' via the mechanism that actually works. Verified contract: a PreCompact hook CANNOT make the model flush to Scribe (host hooks can't trigger model tool calls, and can't know the in-flight task ids), and its additionalContext only shapes the one-shot summary. The correct tool is SessionStart scoped to source=compact, which fires AFTER compaction and injects context the model reads. Our SessionStart hook is matcher-less, so it already fires on compact — it just said nothing compaction-specific. Now it reads the stdin event and, when source==compact, leads with a banner telling the model to reload the active project + in-flight tasks from Scribe and reconcile half-remembered state. Durable path = record-as-you-go (A4/B8) + this post-compaction reload. Refs plan 812 (A7); supersedes the literal 'PreCompact hook' idea. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:49:10 -04:00
bvandeusenandClaude Opus 4.8	700cfc664b	feat(plugin): surface dynamic-tier failures in SessionStart hook (A2) ... Fail-open but no longer silent. When the dynamic context fetch yields nothing, append a short status line to the injected context so a session can tell 'couldn't load live context' apart from 'Scribe had nothing to say': - endpoint+token present but fetch empty/failed -> 'instance unreachable / request failed' - endpoint present but token absent -> fingerprints the known Claude Code userConfig export gap ('API token did not reach this hook') A fully unconfigured install (no url AND no token) stays quiet — static-only is the intended mode there. Static Tier 1 still always carries the mandate. Refs plan 812 item A2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:14:27 -04:00
bvandeusenandClaude Opus 4.8	d11eb9145b	feat(plugin): two-tier SessionStart hook — static keyless floor + dynamic enrichment ... The SessionStart push channel was single-tier: it curled /api/plugin/context with a Bearer token and, on any failure (missing/unexported token, network error, missing curl), injected nothing and exited 0 — silently. A known upstream Claude Code gap (sensitive userConfig not reliably exported to hook subprocesses) trips this routinely, so a fresh session gets no signal to reach for Scribe and falls back to local file-memory (root cause of unlogged work on remote/rc sessions). Split into two tiers: - Tier 1 (static, keyless, networkless, always fires): inject bundled scribe_static_context.md — the load-bearing behavioral mandate. Cannot be suppressed by the upstream key bug. - Tier 2 (dynamic, best-effort, fails open): existing curl for live rules + active-project context, appended below the static block. Lights up as enrichment once the key reaches the hook. Only jq is now required (JSON envelope); curl/token gate the dynamic tier only. Bump plugin 0.1.5 -> 0.1.6 so clients pick up the change. Refs milestone 55; task 809; decision note 810. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 15:01:35 -04:00
bvandeusenandClaude Opus 4.8	8fe571e175	feat(plugin): resolve session project from git remote, not a pinned project_id ... The SessionStart hook asked for a project_id via plugin userConfig, which pins one install to a single project — wrong for an operator working across many repos/projects. Resolve the active project server-side from the working repo's git remote instead (a stable identifier, not a dir-name guess). - repo_bindings table (migration 0064) + RepoBinding model: (user, repo_key) -> project, FKs CASCADE. - services/repo_bindings: normalize_repo_key collapses ssh/https/scp/creds/port/ .git to host/owner/repo; resolve/set/list/delete. - GET /api/plugin/context takes ?repo=<remote>; unbound repo -> a "bind this repo" hint with a ready bind_repo() call. project_id kept as manual override. - MCP tools: bind_repo / list_repo_bindings / unbind_repo. - Hook sends ?repo=$(git remote get-url origin) URL-encoded; all project_id handling removed. plugin.json drops the project_id userConfig (0.1.2 -> 0.1.3). - Tests: normalize equivalence classes + unbound-hint rendering. Refs task 755 (Scribe-as-plugin push channel). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 01:33:58 -04:00
bvandeusenandClaude Opus 4.8	651119cfb0	fix(plugin): read API token from CLAUDE_PLUGIN_OPTION env, not user_config placeholder ... The SessionStart push-channel hook passed the key via SCRIBE_TOKEN="${user_config.api_token}" in hooks.json, but api_token is sensitive:true. Claude Code keeps sensitive userConfig in the keychain and does not interpolate it into hook command strings (only into mcpServers headers), so the hook received the literal placeholder, sent it as the Bearer token, and the context endpoint 401'd -> fail-open -> no context injected. Read the harness-exported CLAUDE_PLUGIN_OPTION_<key> env vars instead (SCRIBE_* still override for the settings.json dogfooding path), and treat any unexpanded ${...} literal as unset so the hook fails open cleanly instead of 401-ing. Bump 0.1.1 -> 0.1.2 so installs refresh the cache. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 00:43:40 -04:00
bvandeusenandClaude Opus 4.8	9924f873b9	feat(plugin): ship the Scribe Claude Code plugin in-repo (marketplace + plugin) ... Per operator: the plugin lives in the app repo so it ships and versions in lockstep with the app and the /api/plugin/context contract it targets (same co-location rationale as the former in-repo MCP). A git-cloned marketplace supports relative plugin sources, so the FabledScribe repo IS the marketplace. - .claude-plugin/marketplace.json — source ./plugin - plugin/.claude-plugin/plugin.json — userConfig (base URL, api key, project id) - plugin/.mcp.json — http scribe server, ${user_config.*} substitution - plugin/hooks/ — SessionStart push-channel hook (fail-open) - plugin/skills/using-scribe — bootstrap skill - plugin/README.md — install via the FabledScribe repo marketplace Phase 2 of plan #755. Install/userConfig-substitution test pending. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-09 23:04:09 -04:00