309 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	84c5c0dc81	fix(snippets): satisfy the parity guards the drift check tripped ... Two CI failures, both the guards working as intended rather than defects in them: - The MCP tool-name manifest and the REST route/service parity lists are explicit, so a new capability has to be added to both surfaces or the test fails. verify_snippet / verify_snippet_route / record_verification added, plus an assertion that the `verification` filter reaches both callers — a verdict an agent records must be visible to the human looking at the same corpus, or the two surfaces disagree about what's rotten (rule #33). - vue-tsc rejected two object-literal lookups keyed by the status union: `status` includes "ok" and "unverified", and an object literal has to enumerate every member even just to say "nothing to show for these". Typed as Record<string, string>, which is what the ?? "" fallback already assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 18:24:48 -04:00
bvandeusenandClaude Opus 5	35f3f09d12	feat(snippets): drift check — verify a snippet still matches its source ... A recorded snippet points at a repo · path · symbol that WILL rot: files move, symbols get renamed, implementations diverge from the copy stored here. Nothing detected any of it, so a record degraded silently from "canonical reference" to "confidently wrong" — worse than no record, since it is surfaced with the same authority either way. WHERE THE CHECK RUNS. Agent-side, which the task flagged as the design question to settle first. Scribe has no checkout of the operator's repos and must not acquire one: giving the server repo access would make every install a credential problem and break instance-agnosticism (rule #115). The agent already has the working tree, so it does the comparing; the server remembers the verdict, makes it queryable, and knows when it has expired. New MCP tool verify_snippet teaches the four-step procedure and records the result; a REST endpoint mirrors it so the UI can clear a marker after a manual fix. WHY THE VERDICT CARRIES A CODE HASH. A verdict describes the code it was checked against. Invalidating it on edit means deciding which edits count — a when_to_use tweak shouldn't void a code check, a rewrite must — which is fiddly and easy to get subtly wrong, and easy for a new write path to forget entirely. Stamping the verdict with a hash sidesteps all of it: one whose code_sha no longer matches is self-evidently expired, computed at read time, no invalidation branch to maintain. That makes "expired" the interesting filter case. It is not `drifted` (nothing was found wrong) and not `unverified` (a check did happen), yet it plainly needs looking at — so `verification=attention` covers both. To keep that one index-served predicate rather than a post-filter that would make the pagination total a lie, data now also mirrors the CURRENT code's fingerprint as data.code_sha, and a jsonpath compares the two fields within the row. The filter is implemented in both dialects, SQL and Python, for the same reason the location filter is: the semantic arm's candidates arrive already fetched. A merge deliberately carries no verdict forward — the survivor's code is a union of several sources, so no prior check describes it, and unverified is the honest answer. UI: a danger-toned drift badge on each card (an actively misleading record outranks a merely unused one), and a "Needs attention" filter. Its empty state says plainly that never-verified snippets don't appear there — otherwise `attention` would mean "everything" on day one and be useless as a worklist. Refs #2086 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 18:20:33 -04:00
bvandeusenandClaude Opus 5	2b85443dd1	feat(snippets): usage signal — was a surfaced record ever actually pulled? ... retrieval_logs answers "what did the ranker return, at what scores" — the right substrate for tuning a threshold. It cannot answer the question the snippet corpus actually needs: did anyone open this? A snippet nobody opens is not neutral. It takes a slot in every future auto-inject menu and crowds out something useful. Adds note_usage_events (migration 0071): one row per note per event, either 'surfaced' (we put its title in front of an agent) or 'pulled' (someone opened it in full), tagged with which surface produced it. Closes the gap #2082 recorded against this work. The write-path PLACE arm carries no score, so it has no home in retrieval_logs — folding it in would corrupt the score distribution that table exists to capture. The result was that the arm firing on the STRONGEST claim ("there is already a canonical helper in this exact file") was the one arm nobody could measure. Both arms now emit usage events under distinct sources, so their pull-through rates are finally comparable. Deliberate departures from the task as written: - Not in-session correlation. The original framing was "correlate result_ids against a later get_note in the same session." There is no session identity server-side — the MCP endpoint is stateless and the hooks send no session id — and adding one would mean threading an opaque client-supplied token through every read path. Two independent counters answer the question without it: surfaced 40×, pulled 0 is dead weight regardless of how those events distribute across sessions. - Pulls record at the ENTRY POINTS (MCP tools, REST detail route), not in snippets_svc.get_snippet, which update and merge also reach. Counting those would inflate precisely the number meant to say "someone chose to look at this." - get_note records for every note kind, not just snippets. The auto-inject menu surfaces tasks and processes too; scoping this to snippets would pin those at zero pulls forever and make them read as dead weight next to snippets that merely had a counter. Surfaced in the Snippets list as an "N/M used" badge, warning-toned once a record has been offered 3+ times and never opened, with the tooltip saying what to do about it (usually: its "when to reach for it" doesn't say when). No badge at all below one surfacing — "0/0" reads as a verdict when it's an absence of evidence. Also returned from MCP list_snippets so the agent can see dead weight without opening the UI. Telemetry keeps the retrieval_telemetry contract throughout: writes are fire-and-forget, reads degrade to zeroes, and no path can raise into the surface it observes. Refs #2085 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-28 18:09:17 -04:00
bvandeusen	e0328f2b1c	feat(plugin): write-path trigger — offer prior art before code is rewritten ... The milestone headline. Auto-inject fires on the operator's prompt; the moment reuse is actually lost is later, when the agent decides mid-task to write a helper. A PreToolUse hook on Write|Edit now fires there. Channel: `additionalContext` with NO permissionDecision, so the note reaches Claude beside the tool result and the write is never blocked — a recall aid must not be able to stop the operator's work. Plain stdout would have been invisible to the model, and deny/ask would have made a nudge into a gate. Two arms, different in kind: - BY PLACE — a snippet recorded at this path (or its directory) is prior art by definition, not resemblance, so it is neither scored nor thresholded. This is what #2083's reverse lookup was built to answer. - BY MEANING — semantic search restricted to snippets (new `note_type` filter on semantic_search_notes) over the code about to be written. Place ranks first; the top-k cap spans both arms. Gates carried over from milestone 93 verbatim: threshold, margin, session dedup, titles-never-bodies. Own `source='write_path'` in retrieval_logs so precision is tunable separately — the docstring records that the place arm is unlogged and hands that to #2085. Its own on/off in Settings but the SAME threshold/top-k: one "how loud may Scribe be" knob is easier to reason about than two that drift, and splitting them later is then a data-backed change rather than a guess. Details worth keeping: the hook sends a REPO-RELATIVE path because that is how locations are recorded; the git remote resolves to a project and is never used as the location `repo` filter (different namespaces, would silently match nothing); the endpoint stays a GET because a read-scoped API key cannot POST and every other hook depends on that. plugin.json 0.1.17 -> 0.1.18. Refs #2082, milestone #232.	2026-07-28 09:08:17 -04:00
bvandeusen	dd1b5e5ddb	feat(snippets): reverse lookup — find snippets by repo/path/symbol ... "What canonical helpers already live in this file?" was unanswerable: location lived only in the body markdown. It is now a jsonpath containment query over the `notes.data` mirror added by migration 0070. - One predicate in two dialects in services/knowledge.py: SQL (`data @?`, applied in the browse arm and the keyword arm before count/pagination, so totals stay honest) and Python (`location_matches`, for the semantic arm which post-filters candidates it already holds). Both must change together. - Parts are ANDed within a SINGLE locations entry — repo A in one entry and path B in another is not "recorded at A/B". `path` also matches as a directory prefix, via jsonpath `starts with` rather than `@>`, which the same GIN index serves. - `repo`/`path`/`symbol` reach the service, the REST list and the MCP tool under one name with one default (rule #33); the MCP docstring teaches the place form, and so does the reusing-code skill (plugin.json bumped). - UI: a Location disclosure beside the snippet search, with its own empty state — "nothing kept there, so what you're about to write is new." Settles #2083's open question (pre-0070 NULL `data`) by backfilling after all: `backfill_snippet_data` runs at startup, deriving the mirror from the body with the same parser the read path trusts. 0070's caution was about mangling a hand-edited body; this never touches the body. The alternative was a permanent second body-regex arm, or a query that silently answers "nothing here" for an old snippet and gets the helper written twice. Refs #2083, milestone #232.	2026-07-27 23:09:37 -04:00
bvandeusenandClaude Opus 5	0d396de215	feat(snippets): record merge provenance on the survivor ... Merge kept the target's fields, unioned locations and tags, and trashed the sources — recording nothing about what it absorbed. If a variant handled an edge case the survivor doesn't, that difference left the visible record entirely; recovering it meant knowing to go digging in the trash. The survivor now carries `merged_from`: a "**Merged from:** #2, #3" line in the body for humans, and the same list in the `data` mirror for queries, written from one value like every other field (#2087). It accumulates rather than replaces — a target merged twice keeps both histories — and skipped sources (cross-owner, per #231) are excluded, so the record never claims to contain something it never absorbed. Ordinary edits carry it forward. update_snippet recomposes body and mirror from scratch, so an omission there would silently erase the history on the next unrelated edit; that path is pinned by its own test, including the pre-0070 case where the body line is the only copy. Surfaced in the snippet detail view as a "Merged from" row — the view renders parsed fields, not the raw body, so the body line alone would have been invisible to the operator (rule #27). Un-merge, the other half of #2087, stays open: restoring a source from trash still doesn't strip its locations off the survivor, and what partial un-merge should mean is a design question, not a coding one. `merged_from` is the record that makes it tractable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLwAaV4DQEmVyn496HnEvt	2026-07-27 15:23:41 -04:00
bvandeusenandClaude Opus 5	ef1dbdfc86	feat(acl): unify the retrieval scopes; mark shared rows in Knowledge browse ... Closes #2092 and the Knowledge-browse provenance gap. The two halves of a hybrid search disagreed: the keyword half honoured shares while the semantic half was pinned to NoteEmbedding.user_id, so a shared record was findable by wording and invisible by meaning — the case a semantic search exists to serve. semantic_search_notes now scopes on Note via a `scope` parameter, and each of its five callers declares which kind of act it is: mcp/tools/search.py read the agent asked routes/search.py read the user typed it knowledge.py (semantic) read matches the keyword half beside it plugin_context.py browse nobody asked; never a one-to-one share dedup.py own a verdict that blocks a write must not hinge on another person's notes That last one is the reason this isn't a single global widening: the dedup gate returns "update the existing one instead", so matching a stranger's record would refuse a legitimate create and point at something the caller can't edit. Scope defaults to "own" so a caller that forgets is wrong in the safe direction, and an unknown scope raises rather than falling back — a typo there would be a data-exposure bug. Auto-inject keeps the browse scope, which still admits a collaborator's note via a shared project. Its menu line is the only provenance an agent sees, so a foreign hit now reads: #12 "Title" (0.71) - shared by alex, treat as a suggestion. MCP and REST search results carry shared/owner too. Knowledge browse: the feed hydrates cards from /api/knowledge/batch rather than the list route, so both paths label rows now, and KnowledgeView shows "by <owner>" on records the viewer doesn't own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLwAaV4DQEmVyn496HnEvt	2026-07-25 23:06:52 -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 5	b33e2a79c6	fix(snippets): close the recall-surface gaps found reviewing the Drafter ... Four defects from the 2026-07-25 review of the recall (#227) and merge (#231) milestones. The theme: a snippet could be recorded but not fully corrected, and the agent and web surfaces had drifted apart. - #2076 language was mis-derived from the first caller tag, so a snippet created with tags and no language read that tag back as its language — corrupting the tag set and the code fence on the next update. Only the FIRST tag can carry the language, since compose_tags emits [language, "snippet", *caller]. - #2077 MCP update_snippet mapped "" to "unchanged", so no field could ever be cleared and no snippet detached from its project. Now an omitted field is left alone, an empty string clears, and project_id follows the -1 = detach convention. A service-level UNSET sentinel keeps None available as the clear. - #2078 surface parity: adds delete_snippet (MCP had none, so a wrong snippet could not be retired by the agent that recorded it), locations on MCP create and update, system_ids through the REST routes and the editor, and the near-duplicate gate on REST create with a "record it anyway" escape. - #2079 project scoping: list_snippets takes project_id through the service, the MCP tool and the REST route, defaulting to every project — reaching across projects is the point when the helper you need was written elsewhere. Sharing the list across owners is deliberately NOT in here: query_knowledge is shared with the Knowledge browse surface, so widening it changes behaviour well beyond snippets. Left open on #2079 for a scope decision. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RLwAaV4DQEmVyn496HnEvt	2026-07-25 19:00:05 -04:00
bvandeusenandClaude Opus 4.8	7a81b7333e	feat(scribe): snippet merge UI — multi-select merge, repeatable locations ... Step 3 of the snippet-merge milestone (#231): the human surfaces for merge + multi-location, at v1 quality. Frontend: - SnippetListView: a Select mode (checkbox on each card) → a sticky action bar → a merge modal that lets you pick which selected snippet is the canonical (the others fold in and go to trash). Accent border on selected cards, Moss action buttons (Hybrid rule). - SnippetEditorView: the single Location fieldset becomes a repeatable locations list (add/remove rows), so editing a merged snippet no longer collapses its call sites — no data loss. Sends `locations`. - SnippetDetailView: renders every location (Location vs Locations label). - api/snippets.ts: SnippetLocation type, `locations` on fields/input, mergeSnippets(). Backend (editor enablement): - create_snippet service + POST route accept an optional `locations` list; PATCH route forwards `locations` — so the editor's location list works uniformly on create and edit. Single repo/path/symbol remain the one-location shorthand (MCP create contract unchanged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Pa2EsuB54BuWQ8GfJq9c7t	2026-07-25 17:22:01 -04:00
bvandeusenandClaude Opus 4.8	d257c0fd67	feat(scribe): snippet management UI + REST routes; embed snippets on create ... Step 6 of the Drafter recall milestone (#227): a human-facing surface for the reusable-code snippets that agents record via MCP, plus the REST API behind it. Backend embeds snippets inline on create/update so they're recallable immediately, not only after a restart. Backend: - routes/snippets.py: GET/POST /api/snippets, GET/PATCH/DELETE /api/snippets/<id>. Share-aware per rule #78 (get_note_for_user + can_write_note), writes performed as the owner; list owner-scoped — mirrors routes/notes.py. Registered in app.py. - services/snippets.py: embed on create/update via a _embed_snippet fire-and-forget helper, covering BOTH the MCP tool and the REST route by construction. A snippet's value is immediate recall, so it can't wait for the startup-only backfill (see issue: MCP create path doesn't embed inline for notes/tasks generally). - tests/test_routes_snippets.py: structural registration + handler/service contract + PATCH-field ↔ update_snippet-kwarg parity (rule #33). Frontend (Vue 3 + TS): - api/snippets.ts: typed client, modeled on api/systems.ts. - views: SnippetListView (search, skeleton/empty/error states), SnippetDetailView (read + copy-to-clipboard, ConfirmDialog delete), SnippetEditorView (create/edit all fields, Ctrl/Cmd+S, Esc, autofocus, validation). v1 quality per rules #24/#27. - router: /snippets, /snippets/new, /snippets/:id, /snippets/:id/edit. - NoteType union widened to include 'snippet'; Snippets nav link added to AppHeader (desktop pill bar + mobile menu). - Design system: Moss --color-action-primary for action buttons, accent --color-primary reserved for tags/brand (Hybrid rule); focus rings; JetBrains Mono for code/name/signature/location. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Pa2EsuB54BuWQ8GfJq9c7t	2026-07-25 14:16:02 -04:00
bvandeusenandClaude Opus 4.8	12f71fabdf	refactor(scribe): remove calendar + entity surfaces from web UI (frontend) ... Frontend half of the narrowing (milestone #194); matches backend b49efdc. - delete CalendarView, EventSlideOver, WeatherCard (orphan) - drop /calendar route + nav link + the g→l keyboard shortcut - strip the calendar-events API client + event/metadata bits from note types and the notes store - KnowledgeView: remove People/Places/Lists tabs, entity cards, create buttons and the upcoming-events widget; keep notes/tasks/plans/processes + the overdue-task badge - NoteEditorView: remove person/place/list forms + list-builder + entity metadata; keep note + process editors (type select = Note/Process) - DashboardView: drop the "Upcoming · 7 days" events rail card - SettingsView: remove the CalDAV integration card + save/test (its endpoints were deleted backend-side) - prune the now-dead entity/event CSS RecurrenceEditor + task recurrence rules are kept (task machinery, not calendar). Verified by a full dangler sweep. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BPtbSzA4JLMAKgFZ8VTg7Q	2026-07-19 16:10:24 -04:00
bvandeusenandClaude Opus 4.8	8126db3203	feat(plugin): knowledge auto-inject (Path A) — title-first per-turn awareness ... New UserPromptSubmit hook (scribe_autoinject.sh) + GET /api/plugin/retrieve that surface the TITLES (never bodies) of the few notes clearing four anti-bloat gates: a per-user confidence threshold (stricter than pull search), a margin gate, per-session dedup (exclude_ids), and a top-k ceiling. Each retrieval is logged to retrieval_logs as source=auto_inject so the threshold can be tuned from data. Per-user config (enable / threshold / top-k) is DB-backed via /api/settings with a Settings UI card; defaults enabled, threshold 0.55, top-k 3 (conservative — tune once auto_inject telemetry accrues). Scribe: project 2, milestone 93, task 1033. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xz4j1H7pjYSjKsEpgcNH5E	2026-06-22 20:31:07 -04:00
bvandeusenandClaude Opus 4.8	96079d5b77	feat(db): table-health readout — per-table bloat metrics in admin card ... You can't decide what to maintain without seeing what's bloating. Adds a read-only health panel driven by Postgres' own statistics views. - services/db_maintenance.py: get_table_health() queries pg_stat_user_tables + pg_total_relation_size + pg_database_size — per-table size, live/dead tuples, dead-tuple ratio (the bloat signal), and last (auto)vacuum/(auto)analyze. - routes/admin.py: admin-only GET /api/admin/db-maintenance/health. - SettingsView.vue: 'Table health' table in the maintenance card, all tables sorted by dead tuples, rows >=20% dead-ratio flagged; total DB size shown; refreshes after a Run-now so the dead-tuple drop is visible. - Tests: health row/size shaping + null-timestamp passthrough; route + service surface. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-14 17:53:24 -04:00
bvandeusenandClaude Opus 4.8	c4553d937c	feat(db): scheduled DB maintenance — daily targeted VACUUM (ANALYZE) ... Adds a daily off-hours VACUUM (ANALYZE) over the high-churn tables the retention/purge sweeps churn (app_logs, notifications, token tables, notes, note_versions), on top of Postgres autovacuum, to reclaim bloat left by the nightly bulk DELETEs and keep planner stats fresh. - services/db_maintenance.py: run_maintenance() over a closed table allowlist via an AUTOCOMMIT connection (VACUUM can't run in a txn); per-table summary persisted as the db_maintenance_last_run admin setting. - services/db_maintenance_scheduler.py: BackgroundScheduler cron (default 04:00 UTC, after the 03:30 trash purge); enabled-gate checked at fire time; live reschedule on hour change. Wired into app.py start/stop. - routes/admin.py: admin-only GET/PUT /api/admin/db-maintenance + POST /run. - settings.py: set_admin_setting() (write-side of get_admin_setting) for out-of-request writes. - SettingsView.vue: admin 'Database maintenance' card — enable toggle, run-hour (UTC), Run-now, last-run summary. - Tests: allowlist is closed, VACUUM issued per table, one failure doesn't abort the rest, summary persisted; route/scheduler/service surface. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-14 16:42:04 -04:00
bvandeusenandClaude Opus 4.8	f7742173aa	chore(plans): make kind=plan retirement consistent across MCP, REST, UI, skills ... Audit of the plugin + MCP surface after milestone-as-plan (T3): every path that could still create a kind=plan task or describe the old plan-task model is now aligned with the hard-retire decision. - create_task (MCP + REST POST /api/tasks): reject kind=plan with a message pointing to start_planning. The 'plan' enum value stays valid so legacy plan-tasks remain readable; update paths never touch kind, so they round-trip. - create_task / get_task docstrings: 'plan' dropped from creatable kinds; get_task's rules-augmentation noted as legacy-only (get_milestone for new plans). - skills/writing-plans: rewritten for milestone-as-plan (body = design, steps = child tasks, get_milestone to read back). - skills/using-scribe: "plans live in milestones via start_planning", not kind=plan. - TaskEditorView Kind selector: offers Work/Issue; "Plan (legacy)" shown only when the loaded task is already kind=plan (display round-trip). - test: create_task rejects kind=plan. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 12:31:51 -04:00
bvandeusenandClaude Opus 4.8	1f6c592226	feat(plans): milestone-as-plan-container; retire kind=plan (T3) ... The milestone becomes the plan container: a new nullable milestones.body holds the design/intent (Goal/Approach/Verification) and individual steps live as first-class child tasks (milestone_id) instead of checkboxes crammed into one kind=plan task body. start_planning now creates a MILESTONE seeded with the body template (not a kind=plan task) and returns it with applicable rules; a new get_milestone MCP tool reads the plan back (body + steps + rules). kind=plan is hard-retired going forward — start_planning never creates one. The 'plan' task_kind enum value stays valid so the 11 historical plan-tasks remain readable in place; no body-shredding backfill (corpus review showed auto-splitting their checklists into tasks would be lossy: embedded code blocks, a non-binary [~] state, tables, ID-encoded hierarchy). - migration 0066: add milestones.body - model/service/route/MCP: body passthrough on create+update; get_milestone - server _INSTRUCTIONS: "plan" = milestone w/ body + child step-tasks - UI: ProjectView shows/edits a milestone's plan body; start_planning expands the new milestone and opens its plan editor - tests updated to the milestone contract + new body/get_milestone coverage Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 12:22:22 -04:00
bvandeusenandClaude Opus 4.8	b6d01686d8	feat(issues): S4b editor controls — Kind selector + Systems multi-select ... In the full task editor (TaskEditorView) sidebar: - Kind selector (Work / Plan / Issue), mirroring the Status/Priority selects. - Systems multi-select (checkboxes of the project's systems, fetched via the systems store), shown when a project is set. Both wired through load (prefill from task.task_kind / task.systems), dirty tracking, and save (kind + system_ids via the store's IssueFields). No new colors — existing sb-field/sb-select tokens. Deferred: the arose-from (provenance) picker — least-critical control and the riskiest (task-search UI); the field is already supported by API/store/route for a later add. NEEDS operator browser verification (CI typechecks only). Refs plan 825 (S4b editor). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 10:56:53 -04:00
bvandeusenandClaude Opus 4.8	94d32c524a	feat(issues): S4b frontend — open-issues lists + issue plumbing ... - types/note.ts: Note gains systems? + arose_from_id?; TaskKind includes 'issue'. - stores/tasks.ts: create/update accept IssueFields (kind/system_ids/arose_from_id). - api/systems.ts: getProjectIssues + TaskLike. - DashboardView.vue: 'Open issues' rail section from dashboard.open_issues (links to /tasks/<id>, project + status). - SystemsSection.vue (project Systems tab): 'Open issues' list via getProjectIssues, with system chips, links to /tasks/<id>. Both reuse existing CSS tokens. Issue-editor controls (kind selector / system multi-select / arose-from picker in WorkspaceTaskPanel) are the remaining S4b piece. NEEDS operator browser verification (CI typechecks only). Refs plan 825 (S4b frontend — lists). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 10:50:41 -04:00
bvandeusenandClaude Opus 4.8	4da29562bd	feat(issues): S4a UI — Systems management section in project view ... Frontend foundation for Issues + Systems (spec #825, S4a). - frontend/src/api/systems.ts: typed client (System + list/create/update/delete) over /api/projects/<id>/systems, matching the rulebooks api style. - frontend/src/stores/systems.ts: Pinia store keyed by project (fetch/create/ update/archive/unarchive/delete), toast-on-error. - frontend/src/components/SystemsSection.vue: a Systems management section — cards (color swatch, name, description, 'N open' issue-count badge) with inline create/edit, archive (hidden behind a 'show archived' toggle), and a delete-confirm modal. v1 quality: loading skeleton, empty state, error toasts, keyboard a11y, focus rings; reuses existing CSS tokens (no new colors). - ProjectView.vue: new 'Systems' tab (between Notes and Rules), rendering <SystemsSection :project-id>, wired like the existing rules tab. S4b (next) adds issue-editor controls (kind=issue/system multi-select/arose-from), open-issues lists, and the dashboard surface. NEEDS operator browser verification (CI typechecks but can't render). Refs plan 825 (S4a). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:42:40 -04:00
bvandeusenandClaude Opus 4.8	da511fcc9f	feat(ui): declutter dashboard done-recently + MCP-access, add per-project stats ... Dashboard: - 'Done recently' chip-cloud -> compact uniform list (Active-now row style), showing 5 with inline expand to the rest (backend already returns up to 8). - New 'Projects' rail card: each active project with 'N open · M done'. Backend already computed done_count (dashboard.py) — now surfaced in the /api/dashboard payload per active project. MCP Access (Connect Claude / Claude Code): - Progressive disclosure: lead with the pre-filled plugin-install snippet; fold server name, scope, marketplace URL, and the MCP-only path into a single 'Customize' expander. Desktop tab keeps its own server-name field. - Marketplace URL now defaults to this instance's own repo via config.PLUGIN_MARKETPLACE_URL (env-overridable); /api/plugin/marketplace-url falls back to it, so the field + install snippet are pre-filled out of the box instead of showing a generic placeholder. Refs #761 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 11:04:23 -04:00
bvandeusenandClaude Opus 4.8	1d82e81527	feat(plugin): admin-configurable marketplace URL as the install default ... The Settings install command had a <your-scribe-repo> placeholder — not copyable. Add an instance-global 'plugin_marketplace_url' setting (admin sets it to the app's own repo) that every user's MCP Access reads, so the /plugin marketplace add command is copyable out of the box. Keeps it universal (each deployment configures its own repo) rather than hardcoding one. - services/settings.get_admin_setting(key): admin-scoped global read. - routes/plugin: GET /api/plugin/marketplace-url (any user) + PUT (admin). - SettingsView: Admin → 'Plugin marketplace' field to set it; MCP Access marketplace field falls back to the configured value. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 00:17:05 -04:00
bvandeusenandClaude Opus 4.8	c0b3ec7d9b	feat(settings): lead MCP Access with plugin install, demote raw MCP ... Per operator: the plugin install should supersede the bare MCP connection in Settings, since the plugin incorporates the MCP and adds the session-start hook + skills. The Claude Code tab now leads with /plugin marketplace add + install (with a persisted marketplace-URL field and the base-URL/key/project-id prompts spelled out), and the old 'claude mcp add' command moves into a collapsed 'Advanced: connect the MCP only' disclosure. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-09 23:52:15 -04:00
bvandeusenandClaude Opus 4.8	70ab3f38c6	chore: remove pre-pivot dead code + finish Scribe rebrand (#599 t1-3) ... - Header wordmark Fabled -> Scribe; fable:calendar-changed event -> scribe:calendar-changed; SettingsView CSS comment. - Drop dead Project.auto_summary + summary_updated_at columns (migration 0063) -- the Ollama-era summarizer is gone; model + 2 frontend types + projects test updated. - Remove pivot vestiges: diagnostics _curator_busy()/curator_busy heartbeat field, tz BRIEFING_DAY_START_HOUR/user_briefing_date dead aliases, the ignored 'model' param on get_embedding (+ its test). ruff src/ clean; CI is the gate. Part of scribe plan #599. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-03 16:16:44 -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
bvandeusenandClaude Opus 4.8	65c85bab15	feat(dashboard): DashboardView landing + route + nav ... Task 3 of #583. New DashboardView at /dashboard composes the approved layout: done-recently strip, Active-now project panels (project -> active milestones -> open tasks, in-progress flagged, + no-milestone group), and a rail with upcoming events / week stats / quick-create (Task/Note/Process). '/' now redirects to /dashboard; AppHeader gains a Dashboard link and relabels Knowledge -> Browse (route unchanged). Empty + loading states included. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-02 23:24:32 -04:00
bvandeusenandClaude Opus 4.8	8b3bd4804e	feat(processes): monospace prompt editor for note_type=process ... Task 6 of #582. NoteType gains 'process'. NoteEditorView branches to a plain monospace textarea (labeled Prompt) for processes instead of the TipTap rich-text editor — prompts are plain markdown and rich-text round-tripping would mangle them. Title/tags/save path unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-02 22:33:23 -04:00
bvandeusenandClaude Opus 4.8	74b337b587	feat(processes): surface processes in the Knowledge view ... Task 5 of #582. Add 'process' to the KnowledgeItem/activeType/KnowledgeCounts types, a Processes entry in the type-filter row, a Workflow-icon quick-create button (createNew('process') -> /notes/new?type=process), and a Process card badge. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-02 22:33:23 -04:00
bvandeusenandClaude Opus 4.8	64bc50c788	chore(frontend): drop dead settings toggle, types, and store list-surface ... Drift-audit Group 7 frontend cleanup (no behavioral change): - SettingsView: remove the 'auto-consolidate task bodies' toggle and its saveAutoConsolidate handler. The auto_consolidate_tasks setting has zero backend readers (curator removed in Phase 8); the control did nothing. - AppSettings type: drop the dead assistant_name / default_model hints (kept the open string index signature the store actually uses). Delete the fully orphaned types/chat.ts (zero importers). - notes/tasks Pinia stores: remove the list/filter/sort/pagination surface that backed the removed /notes and /tasks list views (verified no consumer uses the tasks/notes arrays, refresh, or any filter/sort/pagination method). Kept currentNote/currentTask, loading, fetch/create/update/delete, convert, patchStatus, startPlanning, backlinks, tags. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-02 19:47:28 -04:00
bvandeusen	e5565b73dc	feat(trash): Settings retention field (trash_retention_days, 0=keep forever)	2026-05-29 12:12:04 -04:00
bvandeusen	b579aa1c88	feat(trash): TrashView page, nav links, and g+x shortcut	2026-05-29 12:10:27 -04:00
bvandeusen	d04b6f4bba	style(rulebook): narrow the Topics column in /rules	2026-05-28 11:42:08 -04:00
bvandeusen	dc93675470	feat(plan): KnowledgeView Plans facet + plan badge (knowledge endpoints + UI)	2026-05-28 11:12:59 -04:00
bvandeusen	2f5ef9124a	feat(plan): Start planning button on project view	2026-05-28 10:44:40 -04:00
bvandeusen	b30cf06096	fix(plan): move Applicable Rules panel to TaskEditorView (the routed task surface)	2026-05-28 10:43:41 -04:00
bvandeusen	75d3d40038	feat(plan): plan-task viewer shows Applicable Rules panel	2026-05-28 10:42:03 -04:00
bvandeusen	9658e9a35c	feat(rulebook): Project Rules tab — applicable rules + subscription chips	2026-05-27 22:20:19 -04:00
bvandeusen	75d8e7ab49	feat(rulebook): RulesView three-pane shell + child panes + rule editor	2026-05-27 22:00:32 -04:00
bvandeusenandClaude Opus 4.7	4806c34a3c	refactor: Phase 10 — Ollama service, image cache, config, frontend orphans ... Final cleanup phase of the MCP-first pivot. docker-compose: - docker-compose.yml: drop ollama service + OLLAMA_URL/MODEL env vars + IMAGE_CACHE / VAPID env comments - docker-compose.prod.yml: drop ollama service + Ollama env + GPU reservation - docker-compose.quickstart.yml: drop ollama service + Ollama env + GPU-reservation comment; quickstart instructions now point at the MCP Access tab instead of model-pull Config: - Drop OLLAMA_URL, OLLAMA_MODEL, OLLAMA_BACKGROUND_MODEL, OLLAMA_KEEP_ALIVE_*, OLLAMA_NUM_CTX, EMBEDDING_MODEL (fastembed is hard-coded inside services/embeddings.py) - Drop IMAGE_CACHE_DIR, IMAGE_MAX_BYTES (image cache subsystem deleted) - Drop VAPID_PRIVATE_KEY, VAPID_PUBLIC_KEY, VAPID_CLAIMS_SUB (push deleted in phase 8) - Drop VOICE_ENABLED, STT_BACKEND, STT_MODEL, TTS_BACKEND (voice deleted in phase 8) - Drop Config.validate() rules for those keys Image cache deletion: - services/images.py, routes/images.py, models/image_cache.py - models/__init__.py: drop ImageCache import - app.py: drop images_bp registration - alembic/versions/0054_drop_image_cache.py: DROP TABLE image_cache Frontend client.ts orphan exports stripped: - getVoiceStatus, getVoiceList, getVoiceLibrary, installVoice, uninstallVoice, transcribeAudio, synthesiseSpeech, VoiceStatusResult / VoiceEntry / VoiceLibraryEntry types - getJournalConfig, saveJournalConfig, getJournalToday/Day/Days, triggerJournalPrep, runJournalCurator, listPendingActions, approvePendingAction, rejectPendingAction, listJournalMoments, updateJournalMoment, deleteJournalMoment, geocodeAddress - JournalConfig / JournalLocation / JournalConversation / JournalMessage / JournalDayPayload / JournalMoment / CuratorRunResult / PendingCuratorAction types - consolidateProfile, clearProfileObservations, listProfileObservations - ProfileObservationEntry, learned_summary/observations_* fields on UserProfile - consolidateTask (cascading update to TaskEditorView) - getFableMcpInfo, getNewsItems, GetNewsItemsParams, NewsItem import TaskEditorView: - Drop the auto-summary banner + Re-consolidate button - Drop isBodyAutoMaintained gate (editor is always user-controlled now) - Drop reconsolidate function + reconsolidating ref SettingsView: - profile ref no longer initialises learned_summary / observations_count / observations_updated_at (those fields are gone from UserProfile type) Surviving frontend composables/components flagged for likely future cleanup but not deleted in this commit (no compile errors, just unreferenced after Phase 7-8): - useAssist, useFloatingAssist, useTagSuggestions, useVad, useListenMode, useOnnxPreloader (composables) - WorkspaceNoteEditor, WorkspaceTaskPanel, WeatherCard, InlineAssistPanel (components) - api/client.ts still references /api/notes/assist/* and /api/notes/suggest-tags via useAssist + useTagSuggestions — those endpoints 404 now but no caller hits them; dead at runtime, harmless. Compose stack collapses to two services: `app` + `db`. No Ollama, no voice models, no fable-mcp wheel build. First-boot install reduces to: docker compose up -d → visit web UI → register → Settings → MCP Access → copy snippet → claude mcp add … → done. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 19:10:25 -04:00
bvandeusenandClaude Opus 4.7	91bafb641f	refactor: Phase 8 — backend deletion (chat / voice / push / journal / curator) ... Mega-commit. Strips all server-side LLM machinery now that Phase 7 has removed the corresponding UI surfaces and the MCP HTTP endpoint is the sole assistant interface. Deleted (services/): chat, generation_buffer, generation_log, generation_task, llm, tools/ (entire package), stt, tts, voice_config, voice_library, push, journal_closeout, journal_pipeline, journal_prep, journal_scheduler, journal_search, curator, curator_scheduler, consolidation, tag_suggestions, research, weather, article_fetcher, pending_actions, moments, assist, wikipedia. Deleted (routes/): chat, voice, push, journal, quick_capture, fable_mcp_dist. Deleted (models/): conversation, generation_tool_log, push_subscription, pending_curator_action, moment, weather_cache. Deleted (tests/): test_generation_log, test_journal_*, test_consolidation, test_lookup_tool, test_notes_consolidation_trigger, test_record_moment_guards, test_research_pipeline, test_tools_*, test_tool_use_fixes, test_voice_library, test_weather_service, test_calendar_tool_tz, test_wikipedia. Deleted (top-level): fable-mcp/ (legacy standalone stdio package — wheel-build pipeline also removed from Dockerfile). app.py: - blueprint registrations for the 6 deleted routes - startup hook trimmed: no more Ollama warmup, KV-cache priming, journal/curator schedulers, voice model loading - shutdown hook simplified - httpx import dropped (was for Ollama calls) pyproject.toml: - removed deps: pywebpush, feedparser, html2text, trafilatura - removed [voice] extras entirely - description updated for the MCP-first architecture Dockerfile: - removed faster-whisper / piper-tts install steps - removed bundled piper voice download stage - removed fable-mcp wheel build stage Surviving-file edits: - services/auth.py: drop Conversation table claim on first-user setup - services/backup.py: drop conversation / push-subscription export+restore; v1/v2 restore now silently skip pre-pivot conversation data - services/notes.py: drop maybe_consolidate trigger on task done/cancelled; drop _maybe_trigger_project_summary (LLM auto-summary) - services/projects.py: drop generate_project_summary + backfill_project_summaries (both LLM-driven) - services/user_profile.py: drop append_observations / consolidate / clear_learned_data (curator-tied) and build_profile_context (was LLM system-prompt builder) - services/notifications.py: stub out _fire_push_notif (was send_push_notification) - services/event_scheduler.py: drop event-reminder push + chat-retention cleanup job; keep CalDAV pull-sync + reminders job (in-app) - services/diagnostics.py: _curator_busy() always False - routes/notes.py: drop /assist, /assist/stream, /suggest-tags endpoints - routes/tasks.py: drop /<id>/consolidate endpoint - routes/settings.py: drop /models, KV-cache-prime-on-save, journal-schedule timezone hook, and the SearXNG search-test endpoint; inline _is_private_url (was in services/llm.py) - routes/admin.py: drop /voice, /voice/reload endpoints - routes/profile.py: drop /consolidate, /observations (GET, DELETE) - models/__init__.py: drop the 6 dead model imports Frontend cascade: - stores/push.ts: deleted entirely (no callers after Phase 7) - stores/settings.ts: drop checkVoiceStatus + voice-status state - views/SettingsView.vue: drop Locations section + journalConfig state (was tied to /api/journal/config); drop JournalConfig + journal/voice api/client imports - frontend/api/client.ts: orphaned voice/journal/profile-observation/ fable-mcp-dist exports are left as dead but harmless (call them and they 404; type-check is clean). Pre-existing v1 backups that contained conversations/messages still restore — those tables are silently dropped from the import path. Anyone pulling the new image with a populated database will need the Phase 9 migration to drop the dead tables (coming next). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 17:47:18 -04:00
bvandeusenandClaude Opus 4.7	8bec68abc0	fix(ui): restore missing </div> closing the Notifications tab ... The earlier sed-delete of the Push/ChatHistory/About sections from the Notifications tab also clipped the tab's outer </div>. Vue's type-checker happily accepted the unbalanced structure (templates type-check on script bindings, not tag pairing) but Vite's Vue compiler failed at build time: Element is missing end tag. file: src/views/SettingsView.vue:1062:5 (The reported line 1062 was the outermost .settings-content div — Vue's parser blames the outermost open tag when an inner sibling goes unclosed.) Confirmed by counting: 115 open <div, 116 </div> before — and now 116/116 after restoring the closing tag between the Email Notifications section and the Integrations tab. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 15:38:06 -04:00
bvandeusenandClaude Opus 4.7	ba6f2c7614	refactor(ui): purge SettingsView dead JS left over from Phase 7 ... The Phase 7 template strip left script-level state, functions, and imports that no template ever referenced. TypeScript strict mode (noUnusedLocals + noUnusedParameters) caught all of them on CI. Removed from the script: - chat retention: chatRetentionDays, savingRetention, saveRetention - VAPID/push: vapidResetting/Msg/Error, resetVapidKeys, usePushStore, pushStore.checkSubscription() call in onMounted - admin voice block: adminVoiceEnabled, adminVoiceSttModel, savingAdminVoice, adminVoiceSaved, voiceLoadingModels, saveAdminVoice, reloadVoiceModels (plus the matching admin template block — that was still present and referenced these) - user voice block: voiceStatus, voiceStatusLoading, availableVoices, voiceTtsVoice, voiceTtsSpeed, voiceSpeechStyle, savingVoice, voiceSaved, voiceTabLoaded, the whole voice library (voiceLibrary, voiceLibraryLoading/Error/Filter/Expanded, installingVoiceIds, uninstallingVoiceIds, filteredVoiceLibrary, formatVoiceSize, loadVoiceLibrary, refreshInstalledVoices, installLibraryVoice, uninstallLibraryVoice, loadVoiceTab, voicePreviewing, previewVoice, saveVoiceSettings) - observations / consolidation: consolidating, clearingObs, observations, observationsExpanded/Loading/Loaded, toggleObservations, onToggleCloseout, runConsolidate, clearObservations - assistant / model management: assistantName, defaultModel, backgroundModel, installedModels, defaultChatModel, OllamaModel interface, ollamaModels, pullModelName, pullProgress, pulling, deletingModel, formatBytes, loadOllamaModels, pullModel, deleteModel, saveAssistant, saving, saved - api/client imports: getVoiceStatus, getVoiceList, getVoiceLibrary, installVoice, uninstallVoice, synthesiseSpeech, consolidateProfile, clearProfileObservations, listProfileObservations, VoiceStatusResult, VoiceEntry, VoiceLibraryEntry, ProfileObservationEntry Surviving: journalConfig + locations editor + temp_unit selector (Profile→Locations section still uses these to manage home/work addresses for any future feature; the journal-specific prep/closeout fields on the same object are dead but harmless as object members). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 15:26:51 -04:00
bvandeusenandClaude Opus 4.7	18eb1e7ab2	refactor(ui): Phase 7 — strip chat/voice/journal/workspace/home surfaces ... Frontend deletion phase of the MCP-first pivot. All in-app conversational surfaces are gone — Claude/MCP is the assistant now. Deleted views: ChatView, JournalView, WorkspaceView, HomeView Deleted components: ChatPanel, ChatInputBar, ChatMessage, ChatStreamingBubble, ToolCallCard, ToolConfirmCard, WorkspaceChatWidget Deleted composables + store: useVoiceRecorder, useVoiceAudio, useStreamingTts, stores/chat Router changes: - / now redirects to /knowledge (was /journal) - dropped /chat, /chat/:id, /journal, /workspace/:projectId - /tasks still redirects to / (→ /knowledge) - /notes still redirects to /knowledge KnowledgeView: - removed ChatPanel + ChatInputBar embeds - removed minichat floating widget + state + handlers - removed Chat link from today bar - removed `chatStore` driven auto-refresh-on-tool-call watch App.vue: - removed useChatStore + startStatusPolling/stopStatusPolling - removed VAD ONNX preloader (voice subsystem dead) - removed visibilitychange listener (only did voice status re-check) - removed `c` single-key shortcut (focus chat / goto chat) - removed `g+c` two-key sequence (goto chat) - removed Chat section from shortcuts overlay - removed `.chat-page` / `.workspace-root` CSS overflow rule AppHeader.vue: - removed useChatStore + status indicator (Ollama model status) - removed Chat / Journal nav links (desktop + mobile) SettingsView.vue (4598 → 4079 lines): - removed Voice tab entirely - Notifications tab: dropped Push Notifications + Chat History + About sections (kept Email Notifications) - General tab: dropped Assistant (name + model pickers) + Model Management sections (kept Tasks + Timezone) - Profile tab: dropped Journal + Observations sections - VALID_TABS + tab list array no longer include "voice" - removed `loadVoiceTab()` activation trigger Service worker (frontend/public/sw.js): - dropped push and notificationclick handlers (push subsystem only fired on internal generation completion, which is gone) - kept empty fetch handler as PWA installability shell Script-level dead code (state refs, helper functions referencing removed APIs) remains in SettingsView and stores/push.ts and stores/settings.ts for now — Phase 8 backend deletion will clean those up alongside the matching backend route removals. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 15:14:00 -04:00
bvandeusenandClaude Opus 4.7	0cc09f917d	fix(ui): claude mcp add takes URL as positional arg, not --url ... The generated Claude Code snippet was outputting: claude mcp add ... scribe-dev --url <URL> --header ... But `claude mcp add` errors out with `unknown option '--url'`. The URL is a positional argument, not a flag: claude mcp add [--transport ...] [--scope ...] <name> <url> [--header ...] Dropped --url and put the URL inline as a positional. Claude Desktop JSON snippet was already correct (uses {url, headers} keys, not a CLI flag). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 12:45:28 -04:00
bvandeusenandClaude Opus 4.7	97c22941a8	feat(ui): configurable MCP server name + scope; start Scribe rebrand ... Settings → MCP Access now lets you tune the generated snippet: - Server name input (default: 'scribe', stored per browser in localStorage). The name appears both in the claude mcp add command and as the JSON key in claude_desktop_config.json's mcpServers map. - Scope dropdown: user / project / local. Drives the --scope flag in the claude mcp add snippet. Picks 'project' to commit the server into the current repo's .mcp.json. User-visible 'Fable' → 'Scribe' in MCP Access tab copy (lead text, Claude Desktop step). Branding pivot in the rest of the app (assistant_name placeholder, SMTP defaults, version line, etc.) is deferred — chat/journal copy is going away in Phase 7 anyway. Deliberately NOT touched: - Tool names (fable_*) — protocol-level identifiers; renaming breaks any Claude session, agent, or automation that referenced them. Warrants its own phase. - mcp/server.py: FastMCP('fable', ...) server name — same reason. - Internal package name fabledassistant — per the project's naming convention (CLAUDE.md memory), internal stays. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 11:22:28 -04:00
bvandeusenandClaude Opus 4.7	27b5c45f27	feat(ui): MCP Access tab — HTTP transport, in-app endpoint ... Rewrites the apikeys settings tab for the new MCP architecture: - Tab label: 'API Keys' → 'MCP Access' - Shows the in-app MCP URL (<origin>/mcp) with a copy button - Claude Code snippet uses --transport http + --url + --header - Claude Desktop snippet uses {url, headers: {Authorization}} - Drops the wheel-download flow, the 'Other' client tab, and the stdio env file / Claude config download helpers — those were for the standalone fable-mcp package which goes away in phase 8 The api_keys backend stays unchanged — keys double as bearer tokens for the /mcp endpoint via the existing auth.py middleware. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-26 21:23:06 -04:00
bvandeusenandClaude Opus 4.7	1b65c44339	ux: rename model fields + enforce serial curator execution ... Three coordinated changes per operator request 2026-05-24: 1. Settings UI rename matching the language we actually use: - Chat Model -> Chat & Voice Model - Worker Model -> Curator Model Setting KEYS (default_model / background_model) unchanged on purpose; renaming them requires a migration touching 50+ call sites for purely UX-facing benefit. 2. Settings UI help text rewritten: - Chat & Voice: documents that it handles chat AND small conversational automations (titles, tags). Recommends OLLAMA_NUM_PARALLEL=2+ on the Ollama server so background automations get their own KV-cache slot and don't evict the chat model's working state. - Curator: notes the app enforces SERIAL execution regardless of NUM_PARALLEL — only one curator pass runs at a time. This matters most for 70b CPU models where a second instance would waste system RAM. 3. Enforce serial curator execution globally: - New module-level _CURATOR_RUN_LOCK in services/curator.py. - run_curator_for_conversation now wraps its body in 'async with _CURATOR_RUN_LOCK' — every entry point (scheduler sweep, manual route trigger, future hooks) is serialized through it. - is_curator_running() helper exposes the lock state. - routes/journal.py manual trigger checks is_curator_running() first and returns 409 {busy: true} immediately rather than blocking the HTTP request for minutes waiting for a 70b CPU pass to finish. The user can retry once the curator clears. Why a 409 instead of queue: a curator pass on a 70b CPU model can take 5+ minutes. Tying up an HTTP worker that long is bad; making the user wait without feedback is worse. 409 surfaces the busy state immediately and the user retries when they want. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-24 11:30:42 -04:00
bvandeusenandClaude Opus 4.7	85b212fbf2	refactor(models): route tasks to chat vs worker per new architecture ... Chat and background model roles effectively swapped during the conversation+curator pivot, but call sites still used OLD routing. This commit re-routes each call to the model whose new role fits. Moved to background_model (worker — heavy, deliberate): - services/journal_prep.py: daily prep generation. - services/user_profile.py: observation consolidation. Moved to default_model (chat — small, fast): - services/chat.py save_response_as_note: note title generation. - services/tag_suggestions.py: tag suggestions. Already routed correctly (unchanged): curator, closeout, consolidation, project summaries, history summarization. SettingsView.vue: help text rewritten for both model fields to describe new roles. Background Model UI label renamed to Worker Model so the heavier role is visible from the picker. Warning copy updated to recommend OLLAMA_MAX_LOADED_MODELS=2+ so chat and worker can stay loaded simultaneously. Schema names default_model and background_model unchanged on purpose (renaming requires migration + touches ~50 call sites for UX-only gain). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 11:00:47 -04:00
bvandeusenandClaude Opus 4.7	48b99b62be	feat(curator): Needs Review panel in journal right rail (C5/5) ... The frontend half of the review queue. Closes the curator approval loop end-to-end. JournalView.vue: - New 'Needs Review' section in the right rail, ABOVE the Captures panel (per the design decision: pending stands out, captures are ambient). Hidden entirely when nothing is pending so the rail stays calm. - Each pending action renders as a card: - Header: action_type chip (e.g. 'update_note') + human-readable title built from pendingTitle() ('Update Famous Supply network restage', 'Delete Old grocery list', etc.). - Diff body: - For deletes: a red 'Permanent delete' warning. - For updates: field-level diff rows (field name | old | → | new) computed by pendingDiff(), which compares the curator's payload against the snapshot taken at proposal time. Skips lookup-only params (query, task, project, milestone, confirmed) so the diff shows only what'd actually change. - Empty-diff fallback for tools without snapshot helpers. - Approve / Reject buttons. Disabled while a request is in flight via reviewingIds Set so double-clicks can't fire twice. - Approve calls approvePendingAction → server replays the original tool call with authority='user'; toast on success/error. - Reject calls rejectPendingAction → marks rejected, no execution. - Both actions refresh the pending list AND the moments list (since approving an update_note could affect what shows in captures). - loadPendingActions() also runs after every manual curator trigger and on initial mount, so the panel reflects current state without manual page refresh. CSS: warm-tinted panel using --color-warning so the section visually distinguishes from the neutral captures feed below. Approve button in success-green, reject in muted. Diff rows use a grid layout with old-value strikethrough and an arrow separator. End-to-end demo loop: 1. Have a journal conversation that includes 'mark the Famous Supply task as done'. 2. Wait for curator sweep or hit 'Process captures'. 3. Curator search_notes('Famous Supply'), then update_note(...) is intercepted by execute_tool(authority='curator') and queued. 4. The Needs Review panel shows: 'Update task Famous Supply network restage' with status diff todo→done. 5. Click Approve → execute_tool replays with authority='user' → the task moves to done. Card disappears from Needs Review. This is the last C* commit in the queue. The curator now has a safe path to mutate user data via proposals, with the user firmly in the loop on every change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 10:33:42 -04:00
bvandeusenandClaude Opus 4.7	37596ce31c	remove(llm): retire think_enabled setting entirely ... Two-in-one cleanup motivated by the chat hang in dev 2026-05-22. The crash root cause from the guarded-task traceback: UnboundLocalError: cannot access local variable 'get_setting' where it is not associated with a value File generation_task.py:257, in run_generation think = (await get_setting(user_id, 'think_enabled', 'false'))... generation_task.py imports get_setting at module top, but a later 'if voice_mode: from ... import get_setting' block scopes it as a function-local. When voice_mode=False the local import never runs, but Python had already flagged get_setting as local for the entire body — the think_enabled read at line 257 hit UnboundLocalError. The line itself was dead-weight anyway. With the conversation+curator architecture: chat ships tools=[] (think on a no-tools pass is pure latency cost; nothing for the model to reason ABOUT in tool-call terms), and the curator hardcodes think=False already. The user setting was a holdover from before the architecture pivot. Removing it entirely is cleaner than fixing the scoping bug to preserve a toggle nobody should be using: - generation_task.py: think hardcoded False. Removed the get_setting call (which fixes the UnboundLocalError as a side effect). - SettingsView.vue: dropped the Enable model thinking checkbox, the thinkEnabled / savingThinkEnabled refs, the saveThinkEnabled function, and the think_enabled load step. - Migration 0050: DELETE FROM settings WHERE key='think_enabled' to clean up any stored rows. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 21:03:25 -04:00