1117 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	07bf58de46	fix(project): grid tracks that cannot shrink pushed the milestone rows off-page ... Reported after deploy: the milestone rows and the kanban's Done column run past the right edge and get cut. Both grids here use a bare `1fr`, and a `1fr` track carries an AUTO minimum — it cannot size below its content. So one wide descendant anywhere in the content column widens the column past the grid, everything inside inherits that width, and `.project-view`'s `overflow-x: clip` cuts it at the page edge. The milestone header only made it visible: it is a flex row now, so its tail (progress track, percent, actions) sits at the right edge where the clipping happens, where before those children stacked at the left and never reached it. `minmax(0, 1fr)` on both, plus `min-width: 0` on the content area — a grid item's default `min-width: auto` refuses to shrink even when its track will, so the two halves are needed together. Worth naming, because it is the same property twice with opposite intent: the header nav was fixed two commits ago by RELYING on the auto minimum, so neither side could be squeezed under its content and the pill bar stays centred. Here that same behaviour is the defect. `1fr` is not a neutral default — it is a statement that the track may not shrink. I could not isolate which descendant was the wide one by reading, and said so rather than guessing at it; this is the structural fix, which holds whichever of the candidates it was. Not changed: RulesView's `280px 300px 1fr` is the same shape and a plausible latent instance, but nothing has reported it and I have not seen that surface misbehave. Guessing at unreported layouts is how eleven fixes become eleven regressions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 10:08:48 -04:00
bvandeusenandClaude Opus 5	a6d6550483	fix(ui): walk the eleven dangling-style reports — two were real ... #2444. Each needed reading rather than a batch fix, and the split was 2 real losses, 4 false reports, 5 wrappers that are bare on purpose. REAL: .system-card was a flex row, and every child still says so — .system-swatch and .system-actions are flex-shrink: 0, .system-body and .system-form--inline are flex: 1. align-items: flex-start is why the swatch carries margin-top: 0.3rem: nudged onto the first line of text. .systems-list no rule AT ALL, so the systems list rendered with browser bullets and indent. Invisible to the check — see below. .graph-embed the panel is a flex column whose header is flex-shrink: 0, so this is the item that takes the remaining height. Without it the `height: 100%` on the line below resolves against auto and does nothing, which left the comment above it specifying a rule that could not work. FALSE REPORTS, and the checker was wrong rather than the code: `.pane.empty` and `td.num` are base rules for the element that carries those classes — the check read any compound with more than a lone class as a modifier. It now records a compound's whole class SET and clears an element carrying all of them, which is exact: recording the classes individually would have cleared `.pane` everywhere on the strength of a rule that only applies alongside `.empty`. Four reports gone, and a check with false reports is one that gets skimmed. BARE ON PURPOSE — .rb, .topic-group, .new-topic, .sub-list, .dash-head, and both .detail-row rows. Each namespaces descendant rules and assumes nothing about layout, which is the tell that separates them from a deleted base. All seven now carry a comment saying so, so the next reader doesn't re-litigate them and a NEW entry in the report means something actually changed. Also recorded in the script: it cannot see a class with no rule anywhere, since that is indistinguishable from a semantic-only hook. `.systems-list` was found by reading the file beside a class that WAS half-styled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 09:26:35 -04:00
bvandeusenandClaude Opus 5	46271ccaa7	fix(project): the goal field is a textarea, not a one-line input ... A project goal is a paragraph in practice. This one rendered as "Maintain Scribe as the reliabl" with no way to read the rest but arrowing through it, in a sidebar with room to spare. Description gets two more rows for the same reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 08:42:58 -04:00
bvandeusenandClaude Opus 5	6ac821178f	fix(design): declare --tp-fill so the token check can see it ... The swatch set it inline only, and a custom property that exists nowhere in a stylesheet is exactly what check_design_tokens reports as unresolvable — it was right, and it caught this on the commit that introduced it. Declaring it on .tp-swatch is the real fix rather than a silencer: a token that resolves to nothing now renders as bare checks instead of an invalid gradient, which is what the inline value would produce when empty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 08:41:24 -04:00
bvandeusenandClaude Opus 5	4a9744172f	fix(ui): restore four base rules a CSS sweep deleted, and check for the rest ... Operator reported four things looking wrong. Two were the same bug, and it is not a design drift — it is deleted CSS. Removing a rule from a scoped stylesheet leaves its modifiers behind. The selector still exists, so nothing reads as unused, and the element renders with no base styling at all: .btn-workspace base gone, :hover survived — the Workspace link rendered as raw browser blue, underlined .milestone-header base gone, .clickable and :hover survived. Every child is written for a flex ROW (.ms-name { flex: 1 }, the progress track, .ms-pct), so without the parent they stacked and a one-line milestone became five. That is the "projects section uses space poorly" — a deletion, not a redesign. .milestone-group no rule at all; the card around each milestone .ds-header only its h1 descendant survived vue-tsc cannot see any of it. A dead style typechecks perfectly. scripts/check_dangling_styles.py finds the shape: an element whose every static class has no base rule anywhere, while at least one carries modifier rules. It reports 11 more. Reported and not gated, because a genuinely bare wrapper is legitimate — the signal is the count growing. Runs in the lint lane, stdlib only, and knows no class name or convention (rule #115). Also from the same report: - The header pill bar was `position: absolute; left: 50%`, so it did not participate in layout: out of room, it OVERLAPPED the brand and the utility cluster instead of pushing them. A sixth link reached that at ~1270px, an ordinary window. Now `1fr auto 1fr` — a 1fr track has an auto minimum, so neither side can be squeezed under its content and the two stay equal, which is what keeps the bar centred in the viewport rather than in the leftover space. Overflow becomes the header growing, not two things sharing pixels. - The token preview put its checkerboard on the whole specimen stage, so every swatch sat in a frame of checks and the pattern read as the loudest thing on the page. The checks now sit UNDER the colour as a second background layer: an opaque value hides them, a 15% tint shows exactly as much as it should. Text-bearing specimens lose the box entirely, and name/value/purpose are one line each with the full text on hover — they wrapped freely before, so a card was two lines tall or five depending on how long its color-mix() happened to be, and the grid had no rhythm. - .btn-cta joins the shared button family: the gradient-and-glow brand moment the system carries tokens for, which had been living in one view's scoped block. That is what made it deletable. The header actions are now one size and one family instead of four sizes and two. - The shared button shape gained inline-flex + gap, so a button carrying an icon centres it without each caller rebuilding the row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-05 08:40:41 -04:00
bvandeusenandClaude Opus 5	8087ba4db0	feat(design): a project reports drift in its own recorded components ... The check has taken a project id since it was written — check_snippets_against_ system(user_id, design_system_id, project_id=0), and the route has always read ?project_id=. Nothing on the frontend ever passed one and no project-side surface existed, so the capability shipped and stayed unreachable. A Design tab on the project, beside Systems and Rules, reporting three things per snippet: no such token var(--x) the system doesn't declare. Renders as NOTHING — no error, no failing test, just an element quietly unstyled. Leads for that reason. defines its own a component minting a custom property instead of reaching for the shared one. This is the DRY finding and the reason the surface exists: the codebase re-solving a solved problem, one component at a time, visible only when someone changes the shared value and half the components don't move. write the token a literal the sheet says to stop writing, paired with what to write instead. Three empty states, kept distinct, because collapsing them is how a check comes to sit dead: no design system bound, no snippets recorded (nothing was checked), and checked-and-clean. The last one says how many were checked. Bound to the SAVED pointer rather than the sidebar picker's draft, so an unsaved change can't make the tab report against a system the project isn't using. Scope is recorded code, per the operator: snippets are what Scribe holds, and a repository's own sources are checked where they live, by that project's CI. Step 3 of milestone #274. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-04 10:41:49 -04:00
bvandeusenandClaude Opus 5	7b0984579d	feat(design): preview any design system, resolved from the record ... The record view listed values as text and drew a swatch only where the value looked like a colour. Two problems, one cause: a derived value such as color-mix(in srgb, var(--accent) 15%, transparent) was drawn by resolving --accent against THIS app, so previewing another project's system showed Scribe's palette. It looked right, which is why nobody noticed. TokenPreview draws the system from its own record. Every value is resolved on an offscreen probe carrying only that system's declarations, so a system whose app this browser has never loaded renders in its own colours — which is the difference between a tool and a mirror. Specimens are chosen by value SHAPE, never by name: colours become swatches, lengths become rules drawn to scale, gradients and shadows get a surface, font stacks are set in themselves. Nothing matches --fs-space-* or any other convention, because the convention belongs to the install (rule #115) — a system that calls its spacing --gap-N gets the same treatment. Translucent values sit on a checkerboard, or a 15% tint over a solid card reads as opaque and shows the wrong colour. Modes come from the system, not from the app: a system declaring base and light offers both, independent of the theme this page is in. The provenance list keeps its swatches only for self-contained colours — the ones needing no resolution, which it can therefore draw honestly. Everything with a var() inside is left to the preview built for it. Step 2 of milestone #274. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-04 10:39:45 -04:00
bvandeusenandClaude Opus 5	dcd4efcea0	refactor(design): retire /design — a surface that could only inspect itself ... The design surface is for the projects an install tracks. /design read the running app's own stylesheet — names out of a bundled theme.css, values out of getComputedStyle(document.documentElement) — so it could only ever describe the instance serving the page. Scribe is one project among the projects Scribe tracks; it gets no view hardcoded into every install. The mechanism that makes this a tool rather than a mirror already existed and already covers Scribe: scripts/check_design_tokens.py runs in CI against a sheet path it knows nothing about, using check_code_against_tokens — the same engine behind check_snippets_against_system. /design was redundant even here. Removed: DesignView, DesignTabs (nothing left to tab between), api/design.ts, routes/design.py and its blueprint, the /design route, ui_design_system() and its setting, and the Settings picker that designated "this app's UI". utils/designTokens.ts and utils/designDrift.ts go with it — between them they were the browser-reading half. What survives is utils/designValues.ts, which works on a record rather than a document: valueForMode, modesPresent, and resolveDeclared. resolveDeclared gained real isolation in the move. Custom properties inherit and `all: initial` does not reset them, so a probe sitting in this page would resolve any reference a record leaves undeclared against the SURROUNDING app's tokens — previewing another project's system would quietly borrow this one's palette wherever that system was incomplete, and a token already reported under unknown_refs would render as though it were fine. Undeclared references are now blanked on the probe first, so they resolve to nothing, which is what the record says they are. Migration 0075 absorbs ui_design_system_id alongside design_rulebook_id rather than an 0076 undoing it: 0075 has not run anywhere, since dev is unmerged and deploys come from main. Both keys named a design source for the running install, and a project already carries its own pointer. This retires the agreement panel shipped yesterday. It asked whether the sheet was actually loaded and applied — the one question a record cannot answer about itself — but only ever about the app you are already inside. Nothing replaces it; recorded in #2430 rather than quietly dropped. Step 1 of milestone #274. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-04 10:35:52 -04:00
bvandeusenandClaude Opus 5	4d2be27935	feat(nav): Design is primary navigation, not a utility icon ... It sat in the right-hand icon cluster with Trash and Settings, filed as a meta-surface. That was true when /design was a read-only gallery and false since: a design system is a record you author, with its own table, inheritance, sharing under the same ACL, and MCP tools. It is the content of the applications being built, which is the same rule that puts Snippets and Rulebooks in the bar. The pill bar is absolutely centred, so a sixth link doesn't push the brand and the utility cluster aside — it overlaps them. Added a 1150px breakpoint that drops the wordmark (the logo says the same thing and is still the link home) and tightens the link padding, rather than leaving Design out of the bar to avoid the collision. Mobile menu moves Design above the divider with the other content links, so both layouts sort it the same way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-04 08:26:43 -04:00
bvandeusenandClaude Opus 5	5b824c1626	feat(design): the panel now asks whether the app agrees with its own sheet ... Retiring rulebook #2 left the /design drift panel with no data source, and because its empty state was well-written the feature read as working while it could only ever render "nothing designated" (#2419). The original question is genuinely gone: theme.css is generated from design system 2, so checking the system against a sheet derived from it would be a tautology. The question that survives is the one no server can answer. A generated sheet still has to be LOADED and APPLIED, and nothing checked that it was: absent the record declares a token the app doesn't have — the sheet was never regenerated after the record changed, or never loaded differs the app has it with another value — a stale sheet, or a later rule that overrode it unrecorded the app declares a token in the record's own family that the record has never heard of Both sides go through the same engine so the comparison is honest: declared values are set on an offscreen probe and read back, which performs the same var() substitution the browser already did to the live values. Comparing raw strings would mark every derived token as drift. The designation moved with the feature — design_rulebook_id becomes ui_design_system_id, with a migration deleting the retired key rather than leaving an inert row. The prose extractor it fed goes too (#2288 said its runtime role ended when the import landed). Three orphans of the same shape, found alongside and fixed here: - darkOverriddenNames hardcoded [data-theme="dark"]. The sheet went dark-first months ago, so it matched nothing and the "mode-aware" flag silently left the gallery. Now matches the SHAPE of a mode selector, which also holds for an install whose modes aren't light and dark. - groupFor's prefix table never heard of --fs-, so 110 tokens sat under "other". Groups now come from the record where there is one; the table can only know families that shipped with the product (rule #115). - The type scale was a hand-written table of nine sizes marked "no token", true when written and false since the scale was recorded. Now rendered from whatever size tokens the sheet declares, so it can't go stale twice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 20:50:03 -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	c34454b840	refactor(theme): the accent was hand-written 16 times — now derived ... `rgba(91, 74, 138, …)` is Scribe's accent in decimal. It appears sixteen times across five files at ten different opacities, plus once as #5B4A8A. Change the accent in the design system and none of them would have moved — which is the precise failure the token system exists to prevent, hiding in a notation that does not look like a colour constant. Now `color-mix(in srgb, var(--color-primary) N%, transparent)`, so every one follows the accent. The design system already uses this form for its own tints (--fs-accent-soft, -faint, -wash), so this is the established idiom rather than a new one. The CI literal count barely moves (45 -> 44) because its regex matches #hex and fifteen of these were rgba(). Worth stating plainly: **the count was never the goal, and the check is blind to this whole class.** An rgba triple is a colour literal in every sense that matters and the report does not see it. Not touched: the badge palette in KnowledgeView (#7A6DA8, #fbbf24, #818cf8 for note/task/plan) and the remaining greys. Those are genuine unmade decisions — what colour IS a plan badge — not drift, and inventing tokens for them would be deciding by implementation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:53:54 -04:00
bvandeusenandClaude Opus 5	bd60d679d9	refactor(theme): remove 184 var() fallbacks — every one was unreachable ... #2277 counted ~150 "raw colour literals bypassing the tokens". Measuring them told a different story: 184 sat in `var(--token, #fallback)` position, and a check against theme.css shows every one of those tokens IS declared. So the fallbacks could not render. Not drift — vestigial. They were also not this palette. The most common were Tailwind and Flat-UI defaults — #6366f1 indigo, #22c55e green, #f59e0b amber, #3b82f6 blue, #e74c3c and #27ae60 — a second, unsanctioned colour scheme sitting in the codebase looking like the app's colours to anyone reading it. Removing them is not tidying. #2319's lesson is that a fallback is WORSE than a missing token: a missing token renders as nothing and someone eventually notices, while a fallback renders something plausible forever. These 184 were one token rename away from silently repainting the app in Tailwind. The design token check would catch the rename — but the fallback is precisely the thing that would make it invisible if the check were ever bypassed. Literal count 152 -> 45, which matters beyond the number: a report that is mostly unreachable noise is one people stop reading, and then it stops working while still passing. What remains should be genuinely worth looking at. Done with a paren-aware transform, not a regex — `var(--x, rgba(0,0,0,.5))` nests parens and `[^)]+` would cut at the first one and leave `))` behind. Verified after: every changed line is a fallback strip and nothing else, and every var() reference still resolves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:52:04 -04:00
bvandeusenandClaude Opus 5	174ec8af46	feat(design): the starter-role checklist, in the creation UI ... Rule #27 — the backend half shipped without a surface an operator can touch, so this is the other half of #2349. StarterRolePicker is a component rather than inline markup because DesignSystemsView has TWO creation forms: the empty state is a sibling branch of the body, not a parent, so a form written into one is unreachable from the other. Inlining the checklist would have made it the next thing in this codebase defined twice and free to drift — which is what the button migration spent nine commits undoing. What it offers is names and purposes, never values. "Named now, valued later": a role you haven't filled shows as to-be-decided, while a role that doesn't exist is what gets written as a literal instead. Every group unchecks individually, and the prefix is editable because `--fs-` is one family's convention, not the product's. Three deliberate details: - All groups checked by DEFAULT, and that default lives in the UI, not the service. create_design_system treats None and [] alike (seed nothing) so it can never write 40 rows into a system whose caller never asked; a UI default is visible and reversible before the click. Different layers, different safe answers. - A failed catalogue fetch is NOT fatal and does not read as an error. Starter roles are an accelerator, not a prerequisite — the form still creates, and the operator adds tokens by hand. - The refs are not cleared after a successful create. The picker owns them and re-seeds on mount; resetting here would race that and silently create the next system with no roles. props + defineEmits rather than defineModel, matching TagInput and the rest of components/. defineModel is available (Vue 3.5) and would be shorter, but being the only file in the codebase using a different binding idiom costs more than the lines it saves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:45:48 -04:00
bvandeusenandClaude Opus 5	4852b0d3df	test(design): add the starter-roles endpoint to the URL enumeration ... CI caught it: tests/test_routes_design_systems.py enumerates every routed rule, and I added a handler without adding its rule. The guard doing exactly what its docstring says it is for. Two enumerations govern this blueprint and I had only extended one — the parity list (handlers exist on both surfaces) but not the URL list (handlers are actually routed). They catch different failures, which is why both exist. Noted in place: /api/design-systems/starter-roles is a static segment sharing a prefix with /api/design-systems/<int:design_system_id>. That pairing is where a silently-shadowed route hides, so it is worth being explicit that the int converter cannot match "starter-roles" — verified rather than assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:42:11 -04:00
bvandeusenandClaude Opus 5	22f907c44d	feat(design): offer starter token ROLES at creation, never values ... A literal gets written into a stylesheet when there is no role to reach for. This codebase demonstrated it: the house style had no "text on a filled colour" role, so 76 call sites wrote a pure-white literal — not out of defiance, but because nothing existed to write instead. The correction was not a better ban list; it was declaring the missing role (#2275, #2349). So the useful moment is creation. A system whose roles are named on day one never presents the occasion. Ten groups, ~40 roles: surface, text, action, semantic, border, accent, radius, space, motion, state. Operator's call was one flat list, every group individually skippable — presets keyed to app shape (web / CLI / docs) were rejected because they need the product to hold opinions about app categories, and a wrong category is worse than a list someone prunes once. TWO BOUNDARIES THIS HAS TO HOLD, both rule #115: - The ROLES ship; the VALUES never do. Every seeded token has an empty value_by_mode, so a fresh system is a set of named, deliberately-unanswered questions. A test asserts no hex appears anywhere in the module — not just that tokens are blank, but that no palette hides in a comment waiting to be pasted in. - The PREFIX is the install's. `--fs-` is FabledSword's convention, not the product's; the default is a neutral `--ds-` and callers pass their own. Valueless roles are already legible downstream — render_stylesheet emits them as commented-out declarations and stylesheet_for_system reports them under `valueless` (#2299) — so "declared but undecided" reads correctly with nothing new built. Both surfaces, per rule #33: MCP gains starter_role_groups/token_prefix plus list_starter_role_groups(); REST gains the same on POST plus GET /api/design-systems/starter-roles. The parity enumeration is extended rather than loosened. Note create_design_system treats None and [] alike (seed nothing), while starter_tokens treats None as "all". Deliberate: creation must never write 40 rows into a system whose caller never asked, and the everything-checked default belongs in the UI where the operator can see it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-03 11:37:20 -04:00
bvandeusenandClaude Opus 5	5795fa908a	feat(projects): cap milestone bars at 10, open work first ... Roundtable's card rendered ~35 milestone bars and ran several viewport-heights tall, so one tile dwarfed the grid and stopped being scannable — which is the whole job of a card (#2391). Now 10 bars, ordered OPEN WORK FIRST and newest first within each group, with "+25 more milestones" beneath. Ordering by recency alone would have been wrong, and the operator's call was to lead with open work: a long-running project's oldest milestones are usually its finished ones, so the ten most recent could easily have been ten completed bars while the three in flight were the ones hidden. A card answers "what is happening", not "what happened". Three details that are the actual work: - The palette index is captured from the FULL list before slicing. Colour keyed to visible position would have recoloured every bar on the card each time a milestone closed or was added. - Computed once per load into a Map rather than called from the template. A helper invoked inside v-for re-runs on every render, and this one sorts. - The overflow notice is plain text, not a link. The whole card already navigates to the project, and a link nested inside a clickable region is a trap for keyboard and screen-reader users. Saying the count matters more than the cap: a list that simply stops reads as a rendering bug, while a count reads as a summary. Payload is unchanged — the API still returns every milestone. Capping server-side would also need the total to travel with it, or the "+N" has nothing to count from; not worth it while the response is two queries (#2384). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-02 19:38:48 -04:00
bvandeusenandClaude Opus 5	be3a0ffaf9	fix(projects): batch the summary queries — the fan-out was exhausting the pool ... Reported live: Projects and Snippets showed skeletons that never resolved, /knowledge worked intermittently. The logs named it exactly: QueuePool limit of size 5 overflow 10 reached, connection timed out, 30.00 GET /api/settings 500 30584.0ms GET /api/projects 200 30882.9ms /api/projects was not hanging — it was waiting out the 30-second checkout timeout and then returning 200 with summaries silently missing, because _attach swallowed the TimeoutError. Nobody waits 31 seconds, so it read as a hang. THE SHAPE: routes/projects.py ran asyncio.gather over every project. Each _attach called get_project_summary, which opened its own session for three queries and then called get_project_milestone_summary — which opened one more session PER MILESTONE. So 25 projects asked for roughly 250 concurrent checkouts against a pool of 15 (SQLAlchemy's default 5 + 10 overflow). That is why unrelated routes failed too. Snippets and /knowledge were never broken; they queued behind the burst and inherited its timeout. /api/settings returning 500 while /api/projects returned 200 is the same cause wearing two faces. The comment above the gather said "one backend pass instead of N+1 frontend calls". It did remove the N+1 from the network — and recreated it against the connection pool, where it is worse, because the browser had at least been serialising those calls. Now: get_project_summaries() does all projects in four queries and one session, and get_project_milestone_summaries() does all milestones in two. Two sessions total for the whole page, independent of how many projects exist. The progress calculation is extracted to _progress_from_counts and shared by both the batch and single paths, so the cancelled-exclusion rule cannot drift into two versions that disagree about whether a milestone is finished. Tests assert the SESSION COUNT, not just the values. An implementation that returned identical output while opening a session per project would pass a correctness test and reproduce the outage. Deliberately NOT done: raising pool_size. It would move the cliff rather than remove it, and this endpoint now needs two connections regardless of scale. Closes #2384. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-02 19:09:36 -04:00
bvandeusenandClaude Opus 5	5f8b824523	refactor(ui): the remaining views migrate; 2 dead classes, 2 off-palette hovers ... Twelve more files onto the shared buttons. What the pass turned up: DEAD, verified not merely unnamed: - .btn-reconsolidate (TaskEditorView). A comment eleven hundred lines up in the same file says the feature was removed in Phase 8. The CSS outlived it. - .btn-remove-slot (SettingsView), style rules only, no template anywhere. OFF-PALETTE, the #2319 shape: TrashView's restore and purge hovers used `var(--color-primary, #6366f1)` and `var(--color-danger, #ef4444)` — Tailwind indigo and Tailwind red, from no palette in this system. The fallback is what renders if the token is ever absent, and it renders something plausible forever. Now the action and destructive colours, no fallback. A REAL BREAKAGE MY OWN CHECK COULD NOT SEE, worth recording. Deleting a rule whose selector was part of a comma-separated group left the leading selectors behind: .btn-log-edit, <nothing> .log-textarea { … } which silently swallows the next rule. Brace counting passed — there are no braces in a dangling fragment. Found by scanning for selector lines ending in `,` not followed by another selector; three instances across two files, one of them interleaved with comments so the first sweep missed it. The sweep is now part of the verification, not a one-off. Kept bespoke, deliberately: .btn-pin/.btn-unpin (pill-shaped history badges), .btn-add-share and .btn-new-note (gradient CTAs — brand moments, which the house style does sanction), .btn-icon/.btn-bell (icon buttons, a different component), .btn-add-system/.btn-add-milestone (dashed "add" affordances). These are not drift; they are other things wearing a btn- prefix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:53:13 -04:00
bvandeusenandClaude Opus 5	3fc693443e	refactor(ui): the settings family migrates; two colour bugs and a dead class ... SettingsView and UserManagementView had near-identical button vocabularies — btn-delete, btn-cancel-delete, btn-confirm-delete, btn-toggle/-open/-close — defined separately in each. Parallel duplication (#2278's shape), and it had already diverged twice: - .btn-confirm-delete used --color-danger in UserManagement and --color-action-destructive in Settings. Those are different colours on purpose: the house style keeps error (something went wrong) distinct from destructive (something is about to). A delete confirmation is destructive. UserManagement was showing the error colour for a button nothing had failed in yet. - .btn-remove-slot's hover reached for --color-danger for the same reason, and is the same correction. It turned out to be dead anyway — style rules only, no template reference anywhere in the app — so it is gone. .btn-danger-outline was defined TWICE inside SettingsView, at 0.4rem 0.9rem and 0.45rem 1rem. One file, one class, two geometries, ~1200 lines apart. That is the clearest single argument for this whole task that I have found: the drift does not need two files, only enough distance that nobody sees both at once. The registration toggle keeps .btn-toggle-close, and only that. It is bound dynamically (:class="registrationOpen ? … : …"), so a name-based scan reads it as unused — checked before deleting. .btn-toggle-open went, because btn-primary now says the same thing; the close state stays because it must NOT read as the primary action it sits on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:48:35 -04:00
bvandeusenandClaude Opus 5	3d6931b838	refactor(ui): editor-shared buttons alias onto the variants; 3 dead classes go ... editor-shared.css defined thirteen button rules with hand-written geometry. Ten are now thin aliases onto the shared variants — same class names, because these are used across six views and pointing a name somewhere is cheaper than rewriting every call site (the .btn-small precedent). Three were DEAD: .btn-assist-toggle, .btn-close-assist and .btn-toggle-view had no template reference and no dynamic binding anywhere in the app. Verified before deleting rather than assumed from the name — a class with no user is indistinguishable from one bound dynamically until you look. Named honestly in the file: CSS has no @extend, so each alias carries the variant's declarations rather than inheriting them. That is duplication this migration cannot remove. But it is duplication of a REFERENCE — var(--color- action-primary) — not of a value, so a palette change still moves everything at once, which is the property that actually mattered. Also gone: eight hardcoded geometries (0.4rem 1rem, 0.85rem, and so on) that now come from --fs-space and --fs-size tokens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:46:01 -04:00
bvandeusenandClaude Opus 5	c7cf07824a	refactor(ui): the two workspace panels migrate onto the shared buttons ... Eighteen bespoke button rules across the two densest components, replaced by composition in the template. Net -279 lines. These files are where the size taxonomy earns itself: almost every button here is an inline affordance — a dismiss ×, a confirm tick, an add-chip — sitting inside a card or a line of text. Forcing them to the standard 8/16px would have broken the layouts, which is why the previous commit measured the clusters before assuming a button is a button. What the migration left behind is the useful signal. Each residual rule is now one line stating only what the shared classes genuinely cannot: .btn-add { font-size: 1rem; } a '+' glyph, not a label .btn-search-clear { padding: 0; flex-shrink: 0; } sits in the field .btn-suggest-tags { flex-shrink: 0; align-self: center; } .btn-delete-task { margin-left: 0.25rem; } Four residuals were deleted rather than kept, because the shared sheet already said the same thing: a disabled opacity, two hover colours, and a danger-outline hover fill. Keeping them would have recreated the drift in miniature. Two accent hovers went with them. .btn-suggest-tags tinted its border and label with the accent on hover, which is the same house-style violation corrected in f491b6d — it survived that pass because it was a hover, not a fill. .btn-tag-suggestion and .btn-chip-link stay bespoke, deliberately. They are tag-shaped rather than button-shaped, and the house style does put the accent on tags — so they are not drift, they are a different component wearing a btn- prefix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:44:21 -04:00
bvandeusenandClaude Opus 5	67fdf7c55b	refactor(ui): auth views migrate onto the shared buttons; two variants added ... The five auth views each defined .btn-submit identically — full-width, filled, 0.6rem — and LoginView additionally defined .btn-oauth. Those rules are now gone entirely rather than tokenised: the template composes `btn-primary btn-block` and `btn-ghost btn-block`, and there is nothing left per-file to drift. That is the difference between this and the earlier chunks. Consolidating the core four moved geometry into one place but left every semantic name defining its own; this removes the definition. Two variants added, both earned rather than invented: - .btn-text — no fill, no border. The most common shape in the dense surfaces (dismiss, cancel-beside-confirm, clear-search) where a border would draw a box around something that should read as an action on the adjacent text. Distinct from ghost, which IS a box. - .btn-danger-outline — already existed independently in three views before this sheet, which is what makes it a variant and not a one-off. It is what a delete looks like when it must not shout. .btn-block composes with a variant rather than being one, because width is orthogonal to appearance. Also corrected the sheet's own header, which claimed "no template changes" — true when it was written, false as of this commit. It now states the actual model: a button is variant + size, composed in the template. Semantic per-view names are named as the thing that drifted, and why: a name says what a button is FOR and nothing about what it should look like, so two buttons doing the same job in two views had no reason to match, and didn't. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:42:14 -04:00
bvandeusenandClaude Opus 5	37616682f0	feat(ui): three button sizes, because the app has three kinds of button ... Measured before deciding: across the ~100 bespoke button rules, vertical padding does not spread — it clusters. ~27 at 0.4–0.45rem, ~28 at 0.25–0.3rem, ~23 at 0.1–0.15rem. Those are three different components that happen to share a name prefix: a page action, a row action, and an affordance that lives inside a card. Collapsing them to the single size the shared sheet had would have visibly broken every card layout, which is why the one-off migration stopped here for a decision rather than proceeding on the assumption that a button is a button. default 8px 16px page action — what the house style specifies .btn-compact 4px 12px toolbar, table row, list item controls .btn-inline 2px 4px dismiss ×, confirm tick, add-chip .btn-small and .btn-sm already sat at the compact step, so they are kept as aliases for it — no template churn, and the two spellings stop being a third thing that might drift. .btn-inline is deliberately below the spacing scale's first step on the vertical axis: 4px of padding on an 11px label already exceeds the line box these sit in. Stated in the file so it reads as a measured exception rather than someone ignoring the scale. DesignView renders all three as real specimens. A size scale described in prose is one nobody can check; rendered from the actual classes, it cannot claim something the app does not do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:21:44 -04:00
bvandeusenandClaude Opus 5	97b93bcaea	refactor(ui): buttons stop using weights the system doesn't have ... Eleven buttons set font-weight 600. The house style permits exactly two weights, 400 and 500, and says so explicitly — 600 and 700 are not part of the system. Every auth Submit, plus Invite, Toggle, Confirm-delete, Add-share, the OAuth button and the assist Reject. Now var(--fs-weight-medium), which is 500. Buttons get very slightly lighter. Small on its own, but it is the third kind of drift the same five auth views have now produced: geometry that differed per file, an accent fill the style forbids, and a weight the system does not define. None of the three was a deliberate choice — each is what happens when a button is written by copying the nearest existing one. Weight declarations only. No geometry, no colour, no templates. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:19:16 -04:00
bvandeusenandClaude Opus 5	f491b6d7b9	refactor(ui): action buttons stop wearing the accent ... 21 buttons filled with --color-primary, which resolves to Scribe's violet accent: every auth Submit (Login, Register, Invite, Forgot, Reset), plus Invite, Add, Confirm, Restore, Generate, Log-save, Subtask-confirm, Toggle-open, the modal primary, the version-restore, the inline-assist button, the milestone-plan actions, the task-advance hover, and both empty-state CTAs. The house style is explicit that the accent never appears on an action button: action colours are universal across the family precisely so a Save button looks identical in every app, while the accent carries identity. Doing both makes the accent mean two things and neither clearly. Operator's call, and the reasoning is worth keeping: the violet-on-Scribe- actions treatment was a deliberate early choice to give the web UI its own personality, made when much more of the app was user-facing. That is no longer true, so consistency is now worth more than the distinction it was buying. Found in two passes, which is the part worth noting. The first scan looked for `.btn-*` and found 13. Seven more were the same thing under different names — .modal-btn-primary, .vh-btn-restore, .inline-assist-btn, .empty-action, .task-advance-btn — plus .ms-plan-actions .btn-primary, a compound override flagged in the previous commit. Searching by naming convention finds what was named consistently, which is never the whole set. Deliberately NOT changed: progress-bar fills, active tab / page / selection states, tag-pill hover, the duration badge, the skip link, the assist pulse. Those are identity and active-state, which is exactly where the accent belongs. After this the accent appears only there, which is what makes it read as identity rather than as decoration. Colour swaps only — 25 lines changed, no geometry, no structure, no templates. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 22:13:58 -04:00
bvandeusenandClaude Opus 5	1a959b1db0	refactor(ui): one button definition, aligned to the design system ... `.btn-primary` was defined five times in five scoped stylesheets and all five had drifted: three paddings, three font sizes, three disabled opacities — and ProjectListView had no disabled style at all, so a disabled button there looked enabled. Nothing detected any of it. A scoped duplicate is not a rule violation, not a broken reference, and not a recorded snippet, so no existing check could see it (#2273). assets/components.css is now the single definition of the core four — primary, secondary, ghost, danger — plus the small modifier, in design-system tokens throughout. Operator's call to align to the system rather than to the majority of current values, so buttons move to the 8px radius and 12px label the system specifies, from the app's 4px/14.4px. Class names are unchanged, so there are no template edits: the existing surface is repurposed, not rebuilt. STAGING PROPERTY that makes this safe to land ahead of the rest: a Vue `<style scoped>` rule compiles to `.btn-primary[data-v-…]` (specificity 0,2,0) and beats a plain global selector (0,1,0). So the shared sheet changes nothing for a view still carrying its own copy, and every intermediate state of the remaining migration is coherent rather than half-applied. Two divergences corrected on the way, both worth naming: - SnippetEditorView's `.btn-secondary` was a GHOST in disguise — outline styling under the secondary name, while the house style says secondary is filled bronze. It now looks like what it is called. - SnippetDetailView and SnippetListView tinted a ghost button's label with the ACCENT on hover. The house style reserves the accent for identity and active state, never general chrome. DesignView reported "no shared button exists" as an honest gap and declined to draw a look-alike. That gap is closed, so it now renders the app's real classes — the specimens cannot drift from the app without drifting the app. Net -177 lines. Follows: the ~20 semantic one-offs (.btn-save, .btn-delete, .btn-toggle …) and the compound overrides in ProjectView, one of which puts the accent on a primary action button. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-01 19:52:35 -04:00
bvandeusenandClaude Opus 5	6d01788326	test(plugin): pin both halves of the local prior-art arm ... CI caught the previous commit: the fail-open contract asserts a hook stays SILENT with no working instance, and the new local arm deliberately speaks there. The invariant is right and the hook is right — the smoke event was wrong. It used `def f`, which this repo really does define, so the hook found something and "silent" was asserting the wrong thing. Fixed by asserting the two properties separately: - SILENT for a symbol that genuinely does not exist. - SPEAKING, with NO credentials, for one that does. That is the point of the arm — the other arms ask Scribe what was RECORDED; this one asks the repo what EXISTS, which needs no instance. Were it to start depending on configuration it would stop covering the case it was built for, and only this assertion would notice. Second trap, hit while fixing the first: spelling the absent symbol out in full wrote `def <name>(` into check_plugin.py, so the smoke event DEFINED the very symbol it claimed was missing, and the hook found it again. The name is now assembled from fragments so the contiguous string never appears in the source. scribe_prior_art.sh joins scribe_session_context.sh as a hook that legitimately produces output without credentials — for the same reason, that it carries something needing neither network nor config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:49:10 -04:00
bvandeusenandClaude Opus 5	17d59fa3e0	feat(prior-art): ask the repo, not just the record, before writing a definition ... Scribe has never read a line of the codebase. Every Drafter surface recalls from the RECORD — things someone deliberately recorded — so a helper nobody thought to record is invisible to all of them. That is how `.btn-primary` came to be defined four times, in four scoped stylesheets, already diverged: it was never a snippet, so no threshold and no query rewrite could ever have surfaced it (#2280). The write-path hook already runs on the developer's machine, inside the repo, holding the code about to be written. It can simply look. No index, no storage, no staleness story, no server round-trip. Verified against this repo with Scribe unconfigured: .btn-primary is already defined in 4 other file(s): DesignSystemsView.vue ProjectListView.vue SettingsView.vue SnippetEditorView.vue Three properties it needs, all checked by hand: - DEFINITION-shaped patterns only. Grepping bare occurrences would match every call site and bury the real finding, and a hint that is mostly noise is one people learn to skip — worse than none. A payload containing only calls to embed_note() stays silent; one containing `def embed_note` does not. - The target file is excluded, so editing the file that already defines something doesn't report it against itself. - It runs when Scribe is UNCONFIGURED, and a failed request no longer discards it. The remote arms answer "what was recorded"; this one answers "what exists", and that question needs no instance to produce an answer. `curl || exit 0` became `curl || true` for the same reason. Plugin 0.1.21 -> 0.1.22. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:43:58 -04:00
bvandeusen	6a6a388ecd	docs: Fabled-Git, not Forgejo, in ci-requirements ... The instance has run Gitea since the migration. Prose only — no workflow or path change. Scribe issue #2272.	2026-07-31 23:42:25 -04:00
bvandeusenandClaude Opus 5	2cc9e1380e	test(backup): assert the version constant, not a copy of it ... The export test pinned `out["version"] == 4`, so bumping BACKUP_VERSION broke a test that was only ever checking the payload carries the version — which it still did. Asserts against backup.BACKUP_VERSION now, and covers the six v5 sections alongside the v3 ones. The guard itself passed on the first run: every table in Base.metadata was accounted for, in both directions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:13:16 -04:00
bvandeusenandClaude Opus 5	84541f392b	fix(backup): six tables were silently absent, and nothing would catch a seventh ... services/backup.py enumerated its tables as hand-maintained literals with nothing tying them to the schema. Tables added since that list was last extended were absent from every backup — no error, no warning, and a restore that reports success. Missing: systems, record_systems (0065), note_usage_events (0071), design_systems, design_tokens (0072), and repo_bindings — which the issue itself had not spotted, found only by diffing the model tablenames against the two lists instead of trusting either. _NOT_INCLUDED was worse than incomplete: it named "embeddings", "invitations" and "password_resets", none of which are tables. It read as coverage while naming nothing the schema could confirm. Now real names, plus retrieval_logs — observational telemetry that grows per query and that nothing reads for correctness. THE DELIVERABLE IS THE GUARD, not the six sections. Extending a list fixes today and changes nothing about the next table; a new one now fails a test until someone either backs it up or states that it shouldn't be. It checks both directions — an unaccounted table, and a listed name that no longer exists, which is what the three phantom entries above would have tripped. Design systems need ordering care: parent_id is a self-FK. The export orders parent-first (parent_id NULLS FIRST, then id — a parent always has the smaller id), so restore resolves each parent from the map as it goes, with no second pass. A child whose parent is missing lands as a root rather than failing the whole restore. Usage events are kept because pull-through is the evidence base for whether recall works, and it only ever accumulates — a restore that dropped it would reset that measurement to zero while everything still looked fine. BACKUP_VERSION 4 -> 5. Every new restore section is data.get()-guarded, so v2/v3/v4 payloads restore unchanged. Closes #2293. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:09:25 -04:00
bvandeusenandClaude Opus 5	da2383b079	fix(retrieval): verify the reserved slot's kind instead of trusting the query ... CI caught six failures on f8522fb. Five were fixtures; one was a real assumption. THE REAL ONE: _reserve_slot_for_reuse trusted that a query filtered by note_type could only return reuse kinds. It now checks _record_kind on the way in. That slot exists FOR snippets and processes — one silently spent on something else is worse than no slot at all, because the resulting line is indistinguishable from one that earned its place on score. THE FIXTURES, all the same shape: MagicMock notes with is_task left to auto-create. It is truthy, and _record_kind reads task-ness FIRST — so every mock snippet in three test modules was rendering as "task". Two of those fixtures already carried a comment explaining this exact hazard about `.data`; the same reasoning applies to `.is_task` and nobody had needed it until the menu started naming kinds. One assertion was genuinely stale rather than broken: test_write_path_trigger pinned note_type == "snippet", which was the behaviour the widening replaced. Updated to the new contract, including the task_kind="issue" filter that keeps the open to-do list out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 23:01:31 -04:00
bvandeusenandClaude Opus 5	f8522fb28f	fix(retrieval): give reuse a slot, and let experience reach the write path ... Two mirror-image scoping mistakes, neither deliberate (#2246). AUTO-INJECT let every kind compete on raw cosine. That is fatal rather than merely imperfect here, because Scribe's project records are ABOUT software work: a task titled "surface snippets before the agent writes code" is a near-perfect lexical match for "write a function…" while answering none of it. Measured live, a prompt asking for a helper returned three records about BUILDING the retrieval system and zero snippets. Snippets are ~0.5% of the corpus, and the ratio worsens as the project record grows — which is the direction Scribe is meant to grow, so no threshold tuning fixes it. Now the best snippet or process takes the LAST slot when none won on score. Deliberately NOT held to the margin band: that band measures distance from the top overall score, and the top score is the very thing snippets lose to. It still must clear the configured threshold, so a weak snippet cannot buy the slot — silence stays the default. Skipped entirely when reuse already won, so the fix is invisible in the case it isn't needed. WRITE-PATH was snippets-only — the same mistake inverted. An issue recording "we tried this and it deadlocked" could never reach the moment that code was about to be written, though it is arguably the better prior art: it says what NOT to do. Widened to snippets plus recorded experience. That needed a filter the search layer couldn't express. "Experience" is issues plus dev-logs, which differ on is_task, so neither note_type nor is_task alone covers it. semantic_search_notes gains task_kind, which restricts TASKS to the given kinds while leaving non-task notes untouched — so note_type=("snippet", "note") + task_kind="issue" yields snippets, fixed problems and durable notes, without the open to-do list. note_type now accepts a sequence too. Non-snippet hits are labelled with their kind, because an unlabelled issue on that menu reads as "here is code to reuse", the opposite of what it says. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 22:56:31 -04:00
bvandeusenandClaude Opus 5	5c51e29f26	fix(embeddings): embed in the service, so every caller gets it (#2056) ... A note or task created through MCP was not semantically searchable until the next restart's backfill ran. Embedding fired at the five REST route handlers and nowhere else; the MCP tools call the service directly, so they skipped it. The shape of this bug is the reason to care: it is invisible on an instance that redeploys constantly (this one does, per rule 46) and permanent on one that doesn't. Rule 115 — the product has to stand up for the install that restarts twice a year, not just for the one that restarts hourly. Moved to services/notes.embed_note(), called from create_note and update_note, and deleted from all five routes. Every caller — REST, MCP, recurrence, snippets — now gets it by construction rather than by remembering. Two things fall out of having one implementation instead of six: - It uses note.user_id, the OWNER. The routes were inconsistent: some passed the caller's uid, some the owner's. On a shared record the caller's id mints a second embedding row that nothing reads. - services/snippets.py's _embed_snippet existed only because snippets are created via MCP and the routes couldn't cover them. Every one of its four call sites goes through notes_svc, so the helper and its four calls are gone, along with the eight test patches that existed to neutralise it. RuntimeError (no running loop — unit tests, scripts) and any indexing failure are both swallowed: a write that succeeded must not be failed by its index. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 22:46:57 -04:00
bvandeusenandClaude Opus 5	4c9a637507	fix(theme): text on a filled colour needs its own token — the old one inverts ... 76 hardcoded `color: #fff` now resolve to --fs-text-on-action, a new token that is parchment in BOTH modes. The design system said they should supersede to --fs-text-primary, on the recorded reasoning that "there is no 'text on action' colour, there is just the text colour." That is true on dark and wrong on light. --fs-text-primary inverts to #14171A; the surfaces underneath it do not invert at all — every one of these 76 sits on an action colour, a semantic colour, the accent, or the CTA gradient, all of which hold a single value across modes. Sweeping as recorded would have put obsidian text on moss green: roughly 2.4:1, against a house style whose stated floor is WCAG AA. It would have looked correct to me, because I checked it in the mode where it was correct. --color-accent-fg had the same defect independently and is repointed too. The token check now reports zero superseded literals, down from 30 files, and raw colour literals drop 246 -> 169. Closes #2275. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 22:40:58 -04:00
bvandeusenandClaude Opus 5	731ca284c3	feat(design-systems): give a design system a way to reach the session ... Storing a design system never made a session aware of one. Rules get pushed into every session by the SessionStart hook and returned by enter_project; a design system had neither, so its standards were reachable only by an agent that already knew to call resolve_design_system — the same silent failure as a token nobody declares. That gap was invisible while the operator's visual standards also lived in a rulebook. Retiring that rulebook (which is what this unblocks) would have deleted design guidance from every session with nothing to say so. - services/design_systems.design_context() — the delivery side. Guidance is chain-merged ANCESTOR-FIRST: a child system holds only what it CHANGES, so its own guidance describes a departure from a house style it never restates, and the leaf alone is a fragment. Tokens are summarised (count + group names), not listed — a hundred declarations would crowd out the context they are meant to inform. - enter_project returns `design_system`, null when the project has none. - The SessionStart context gains a Design system block with pointers to the values, alongside the always-on rules. - server.py's entity list gains Design system, including the negative: do NOT record one as a rulebook, because a token kept as prose cannot be resolved, inherited, rendered or checked. - The rulebook-tier passage used "a design-system rulebook" as its worked example of a subscribed rulebook — it now teaches the opposite, plus a new "is this a rule at all?" test pointing at design systems, processes and snippets. - using-scribe gains a section on building UI against the project's system. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 22:10:09 -04:00
bvandeusenandClaude Opus 5	1e139d0d18	chore(plugin): bump to 0.1.21 for the planning-guidance edits ... The two skills changed in 6eedb0f are shipped plugin content, and the installer compares manifest versions to decide whether to refresh the cache that actually executes. Without the bump the edits reach the repo and stop there (#2209) — which is exactly the silent no-op the check exists to catch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 20:43:01 -04:00
bvandeusenandClaude Opus 5	6eedb0f6b9	fix(instructions): stop mandating a milestone for every non-trivial task ... Four product surfaces told the agent to call start_planning FIRST for any "non-trivial" work, while a fifth — the milestone bullet four lines up in the same file — had the criterion right: use one when the work has an arc. The loudest surface won, so sessions wrapped bug fixes and one-file changes in milestones that never meant anything. Mandating one project shape is what rule #115 forbids: some projects are milestone-shaped, others are a flat task list and always will be. Now the arc test is stated ONCE in full, in writing-plans, along with what to do when there is no arc (a task, driven by status and work-logs). The other surfaces name it and defer: - writing-plans/SKILL.md gains a "first decide whether this work wants a plan" section; its frontmatter trigger is the arc, not "non-trivial" - using-scribe reflex #4 points at the skill instead of restating it - server.py's Plan bullet adopts the milestone bullet's own criterion - server.py's planning paragraph drops from 11 lines to 6: it keeps the claim MCP instructions should make (a plan's HOME is a milestone, not a local .md) and drops the how, which the skill carries - start_planning's docstring gains the when Also removed "call start_planning FIRST — before any brainstorming, design, or plan-writing skill runs." That was the server asserting priority over the skill layer. Tools describe what they do; skills decide when they apply. The structural point outlasts the wording: a surface that restates a rule is a surface that will eventually contradict it, and nothing checks prose against prose. Closes #2322. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-07-31 20:39:20 -04:00
bvandeusen	378a4b8f99	feat(ci): check the app's own components against the tokens, not just snippets ... Closes the gap the theme.css repoint exposed (#2319, part of #2277). `check_code_against_tokens` could always answer "does this code use the sheet correctly?" — it was only ever fed recorded SNIPPETS. The app's own components, where sixteen unresolvable references were living quietly, were checked by nothing at all. That was structural rather than an oversight: the drift panel runs in the browser and cannot read source files, and the server has no repo access. CI is the only place holding both the sources and the ability to run the check — and it only became cheap once theme.css became a generated artifact, so the source of truth is a committed file with no network and no credentials. **The sheet now carries its own SUPERSEDES block.** That is what keeps the checker instance-agnostic (rule #115): it knows nothing about any palette, and reads both the declarations and the discouraged literals out of whatever stylesheet it is pointed at. Hardcoding "#fff means use the text token" would have baked one install's kit into the tool. Two severities, split on whether the count is already zero: FAIL an unresolvable var() reference — zero today, so this is a ratchet holding a line already reached. It cannot false-positive either: the name is declared or it is not. REPORT superseded literals (32 files) and raw colour literals (246). Gating those means a permanently-red job, and a check nobody reads is worse than no check. **Comments are stripped before scanning, and that fired on the first real run.** A comment explaining why a literal is avoided necessarily contains that literal — DesignSystemsView's stylesheet documents exactly that about `#fff`, and the checker reported the explanation as a violation. A checker that flags the documentation of a rule teaches people to stop documenting rules. Also narrowed `--fs-weight-medium`'s supersedes to the keywords. `600` and `700` are real violations of the two-weight rule, but a bare number matches too much to find by literal scan — `z-index: 600` is not a font weight. That needs a property-aware check, which is a different tool. Verified end to end: the generator's output parses back through the checker's reader, so the two halves cannot drift into disagreeing about the format.	2026-07-31 14:52:06 -04:00
bvandeusen	67a529a38e	feat(theme): repoint theme.css at the design system, and find what wasn't captured ... theme.css is now generated from design system 2 (Scribe, inheriting FabledSword) plus a compatibility alias layer, so the record decides the styling rather than describing it after the fact. **Dark is now the base layer.** The kit is dark-mode-first, so `:root` carries the dark palette and `[data-theme="light"]` overrides it — the inverse of how this file read before. `useTheme` already sets the attribute explicitly to "light" or "dark", so the flip needed no JS change. It also closes the one-way scoping gap #251 recorded: there IS a `[data-theme="light"]` block now, so a container can add light as well as dark. **60 dark overrides became 12.** The other 48 were restating relationships the derivations now express: `--color-bg` follows `--fs-surface-page` because an alias resolves at use time, so it needs stating once rather than per mode. ## What the audit found, which is the actual deliverable **12 dead tokens, removed.** Declared in both modes, referenced by nothing: seven from the removed chat subsystem (bubbles, input bar), plus `--glow-soft`, `--color-action-ghost-border`, `--radius-pill` and two chat widths. 17% of the file was styling a feature that no longer exists. **16 names referenced but NEVER declared** — not by this change, not by the file before it. Fourteen carried hardcoded fallbacks, so pages rendered and nothing ever failed, but the fallback was what rendered, every time. Several were off the palette entirely: --color-primary-bg fell back to rgba(99,102,241,0.15) — an indigo --color-destructive fell back to #b85a4a — not the oxblood --color-status-cancelled fell back to #6b7280 — a grey from no palette here --color-muted fell back to #888 All 16 now resolve to real tokens. Expect small visual shifts exactly where a fallback had drifted; the shift is the fix. **Two tokens the app needed and never had**: `--fs-status-cancelled` (Scribe has had a cancelled task status since the lifecycle was built and never had a colour for it) and `--fs-layout-header` (referenced with a 52px fallback, so 52px was always the real value — just not one anybody could look up). ## The system grew to cover what the app improvised Per the operator: the kit wasn't growing with the app, and this is the result. Recorded as tokens with GAP RECORDED FROM PRACTICE in their rationale — action hover states, disabled opacity, the modal scrim, both code backgrounds, the table stripe, the CTA gradient and glows, the accent-deep and accent-wash tints, and the layout dimensions. Scribe's own system gained its domain semantics — task status, priority, overdue, wikilink — all DERIVED from family colours, so twelve rows of duplicated hex became twelve formulas and zero new values. Priority maps onto the semantic ladder deliberately: low is info, medium is warning, high is error. 95 tokens resolved, none valueless, 34 derived, no broken references, no cycles.	2026-07-31 12:42:15 -04:00
bvandeusen	473280e690	chore(design-systems): stop teaching one install's kit in product copy ... The operator's check: this must be a system for managing design systems, not one with the FabledSword family built into it. No LOGIC was coupled — the audit found zero behavioural dependencies. But every docstring example, every UI placeholder and several comments named this install's palette, so a stranger creating their first design system was shown "FabledSword" as the expected shape and `--fs-obsidian` as the expected token. Examples teach, and these taught the wrong thing. Placeholders now describe the SHAPE ("Your house style", "--surface-page") rather than naming one instance's contents, and the token-name placeholder now says the thing worth saying: name it for its purpose, because `--obsidian` and `--button-bg` both stop being true the moment the value or the element changes. Not fixed here, and it is the one real coupling left: DesignView.vue hardcodes rule 65's button variants and rule 60's type scale as literal arrays, so a stranger's Design page would display this family's specs. Those arrays exist because there was no design system to read from — which there now is. They go when the panel is repointed (#2295), not before. Scribe's own stylesheet comments ("Moss action-primary per Hybrid") are left alone: that is the app CONSUMING the family style, which is what dogfooding looks like, not the tool assuming it.	2026-07-31 10:18:53 -04:00
bvandeusen	1fde646c60	feat(design-systems): formulas — derived tokens that follow their source ... Operator: "build in a way to support formulas like this so that the colors shift as expected and have less to clean up when testing color changes." The storage needed no change at all, which is the good news. A formula is just a value: --fs-accent-soft: color-mix(in srgb, var(--fs-accent) 15%, transparent) It passes the value sanitiser untouched (verified, and now pinned by a test — had `color-mix(... var(...) ...)` been rejected as unsafe, derivation would have needed a storage shape of its own), and the browser resolves the `var()` at use time. Change `--fs-accent` and everything derived from it shifts. **One declaration covers every mode**, and that is the "less to clean up" part. A derived token written once in the base layer follows its source through dark mode automatically, because `var()` resolves where it is USED rather than where it is written. A stored computed literal would need a row per mode and would silently stop tracking the source the moment the source changed — the whole problem this avoids. What derivation DID need is the check. A formula pointing at a token that does not exist is invalid-at-computed-value-time: the browser drops the declaration outright and the token has no value. No error, no warning, nothing in the toolchain notices — the same family as `--color-accent`, `_parent_map`, and the scripted edit whose anchor matched nothing. So `derivation_report` returns three things alongside the sheet: which tokens are computed and from what, which formulas point at nothing, and which derive from each other in a loop. CSS resolves a loop to nothing rather than hanging, so the cycle check is about telling the operator, not protecting the renderer — but a token that quietly resolves to nothing is exactly what is worth being told. A self-reference with a fallback (`var(--fs-x, 8px)`) is deliberately not a dependency; counting it would report every such token as a one-node loop. The UI leads with broken formulas, then loops, then the healthy derived set — the first two are unambiguously wrong, where a duplicate value is a judgement call.	2026-07-31 09:51:54 -04:00
bvandeusen	23a385e2db	revert(design-systems): drop the rulebook import — a migration, not a feature ... Operator's call, and it corrects a scope error rather than a bug: "this is a path for a user to go from a rulebook to a design system. we don't need to build this path in the app itself ... you should be the one that does the import ... going forward no one else should have to do such a migration." Right. Nobody starting from a design system will ever go rulebook -> system, so the whole path was permanent product code serving a single act on one install. Rule #22: remove it, don't flag it off. Gone from the service, the REST route, the MCP tool, the UI panel, the API client and its tests. There is a second consequence I had missed, and it is the better argument. The parser was WORSE at this than doing it by hand. `propose_tokens` leaves radius steps and type sizes valueless because "Small 4px" is not a hex and nothing here parses it — a limitation I documented carefully and shipped anyway. But that limitation only exists because the importer had to run unattended. Done as work rather than as a feature, those values are just read and written, and the result is a complete design system instead of one with a dozen blanks and a count explaining them. Scaffolding built around my own absence from the loop, when I am the loop. KEPT: `extract_expectations` and `design_expectations` in services/design_rulebook_import.py. The live drift panel still reads them until it is repointed at a resolved design system (#2295), and removing them now would take the /design page's only content with it. They go with that change, not this one.	2026-07-31 09:46:12 -04:00
bvandeusen	8eef9e7845	fix(design-systems): the empty state's create button did nothing, and one surface ... Two reports, one root cause each. **The dead button.** "Create the first one" set `showCreate = true`, but the create form lived inside `<div v-else class="ds-body">` — the sibling branch of the empty state. The two are mutually exclusive, so on a fresh install the flag flipped and nothing rendered. The first action a new install can take was the one that didn't work, which is a poor way to honour "an install with zero design systems is the ordinary state". The first system now gets its own form outside the list layout, and it drops the parent picker entirely: there is nothing to inherit from yet, so it says so instead of offering an empty select. **Two surfaces, the wrong one first.** /design and /design-systems are halves of one thing — the record that decides the styling, and what the browser renders from it — and I had added them as two separate nav entries with the read-only diagnostic listed first. Backwards: the record is what you work with; the live view is the check on it. Now one nav entry pointing at the record, with a shared tab bar joining the two. The explorer is renamed "Live tokens", which is what it actually shows. The tab bar is a component rather than the same markup in both views. Two copies diverge the moment a third tab appears — and a design surface that ships duplicated markup would be arguing against itself.	2026-07-31 08:29:37 -04:00
bvandeusen	15d2e0c682	fix(design-systems): declare tokenRationale — the ref its usages referenced ... Broke the typecheck on 0f80b79. The scripted edit that added the three `tokenRationale` usages and the one that declared the ref were separate replacements, and only the declaration's anchor was wrong — so three usages landed against a name that did not exist. The declaration's replacement had no assertion on it while its neighbours did. An anchor that matches nothing is a no-op, and a no-op looks exactly like success.	2026-07-30 21:56:02 -04:00
bvandeusen	0f80b790c7	feat(design-systems): central prose — guidance on the system, rationale on tokens ... Last piece of the architecture in #2296. The operator: "the prose doesn't have to live as one offs, there's a central system for managing it." Two fields, both free-form: design_systems.guidance the narrative a token table cannot hold — aesthetic, voice and tone, what is deliberately out of scope. design_tokens.rationale WHY a token is this value, which is a different question from `purpose` (what it is FOR). "Success equals Moss, aligned by design" is a rationale; "page bg, deepest surface" is a purpose. Rules carry the first routinely and a token row had nowhere to put it. Free-form rather than a column per category, deliberately. A schema with `voice`, `aesthetic` and `scope` columns would bake one rulebook's table of contents into every install (rule #115), leaving the next install three empty columns and nowhere for what it actually cares about. Both nullable: a design system with no prose at all is complete, not a draft. `rationale` cascades like `purpose` — deepest non-empty wins — so an app overriding a colour keeps the family's reasoning rather than blanking it. Same argument as `supersedes`: the override was about the value, not the meaning. In the generated sheet the inline comment prefers `purpose` and falls back to `rationale`, so a token carrying only the why still says something instead of rendering bare.	2026-07-30 21:52:16 -04:00
bvandeusen	46d88f9e7e	feat(design-systems): check the components against the sheet they claim to use ... "The snippets use the tags from the sheet" was a relation nobody could verify. Now it is three checks, and all three currently fail SILENTLY in this codebase: unknown `var(--x)` where the system declares no `--x`. Renders as nothing at all — no error, no failing test, no visual clue beyond the element quietly not being styled. superseded literals a value the sheet said to stop writing, paired with the token to write instead. Only possible because `supersedes` is declared rather than inferred. local definitions custom properties a snippet mints for itself instead of reusing the sheet's — the bloat a shared sheet exists to prevent, where a value stops being reused and starts being restated per component. The first is not hypothetical. Writing DesignSystemsView.vue earlier in this same session I used `--color-accent` throughout; it does not exist, and nothing in the toolchain noticed. This check is the thing that would have. A token that is both defined and read locally is reported ONCE, as an unknown reference — "--btn-bg does not exist in the sheet" is the more precise statement of the same problem, and reporting both would double-count one fact. Literal matching is boundary-aware and case-insensitive: `#fff` must not fire inside `#ffffff` (different colours, and a finding on the wrong one sends someone to change correct code), while `#FFFFFF` in a rulebook has to match `#ffffff` in a stylesheet — the same trap `normalize_hex` exists for. Snippets with nothing to report are omitted entirely. A list of everything that is fine is a list nobody reads twice — the same principle the auto-inject menu and the drift panel are both built on. Two integration mistakes fixed while wiring it: `list_snippets` returns `(rows, total)` and caps its limit at 100, and `get_snippet` returns a Note model rather than a dict. The list rows carry a preview, not the code, so the check reads each full body — checking the preview would have reported on a truncation.	2026-07-30 21:47:47 -04:00
bvandeusen	b0a7d9e89b	feat(design-systems): the master sheet — purpose tokens, not per-element values ... Operator's new requirement (#2299, architecture in #2296): a design system does not just hold tokens, it generates and manages a master CSS sheet. That settles the milestone's open "authority mechanism" question — the record is authoritative because the stylesheet comes out of it. **The sheet is shaped by purpose and styles no elements.** It declares custom properties, grouped by what they mean, and contains no `.btn-primary`, no `table`, no `input`. That is the design, not a shortcut: a sheet that styled elements would restate the same handful of values once per element and grow with the UI, where purpose-named values are stated once and reused. Components live as SNIPPETS that reference these names — a surface that already exists and already carries prose, locations, drift checks, merge and write-path recall. A token named after an element (`--fs-button-bg`) is the smell that the two have been mixed; a purpose name (`--fs-action-primary`) is reused across all of them. Alongside the CSS the endpoint returns what the text cannot say for itself: which tokens are still valueless, and which VALUES are declared under more than one name. The second is the operator's "reuse consistent values" constraint made checkable — and it reports rather than refuses, because a design system legitimately aligns colours on purpose ("Success = Moss, by design") and only a human knows which case it is. Mode maps to selector the way the codebase already does it: base on the root selector, every other mode layered on `[data-theme="…"]`. The root selector is a PARAMETER — #251 recorded that a container-scoped preview cannot use `:root`, so hardcoding it would have made the generator useless to the preview surface. A token the rulebook names but states no value for is emitted as a commented-out declaration IN ITS GROUP rather than dropped. Its absence is the finding, and a comment puts that finding where the reader already is. Values are validated, not escaped, and this is a real boundary rather than tidiness: design systems are shareable records (rule #47), so `red; } body { display: none` in a system shared with you would otherwise inject CSS into your page. A value containing `{ } ; @ < >`, a comment delimiter or a newline is REFUSED and rendered as a comment saying so — rejecting beats stripping, since a partially-sanitised value is one the operator never wrote and the sheet's whole claim is that it is the record. Not in scope, and deliberately: serving this as the app's actual stylesheet. Generating and exposing a sheet is reversible; swapping theme.css for a generated one is not, and it should be an explicit call rather than a side effect.	2026-07-30 21:42:08 -04:00
bvandeusen	4dc57f8ab2	feat(design-systems): import a design system out of a rulebook's prose ... Milestone #254 step 3 (#2288). Reuses #251's prose extractor as the reader and adds the part that makes it an import rather than a list of claims. **The join is the whole trick.** A rulebook states a design system in two places and neither half is a token: one rule names the colours ("Obsidian #14171A (page bg, deepest surface)"), another names the custom properties (`--fs-obsidian/iron/slate`). The import pairs them on the word — `--fs-obsidian` ends with `obsidian` — which is the only reason it produces something usable instead of seventy empty names. The parenthetical becomes the token's purpose, which is the field a bare hex could never carry. **Prohibitions arrive as replacements, per the operator's reframe.** Rule 52 declares Parchment and forbids pure white in one breath, so the import emits "write --fs-parchment instead of #ffffff" — the same fact stated forwards. It attaches to the FIRST token that rule supplied a value for, not to every token of that rule, because claiming Vellum is also the replacement for white would be putting words in the rulebook's mouth. **A token the rulebook names but states no readable value for is still proposed, with an empty value.** Radius steps and type sizes are prose ("Small 4px") and nothing here parses them; inventing a parse per shape would be guessing. The name is real and the value needs a human, so the proposal says exactly that — and the UI leads with the COUNT of those, because an import that hid them would look more complete than it is. Preview is the default on both surfaces and in the UI. An import is a proposal: rulebooks are written aspirationally and some of what they describe was never built, so every entry carries the rule id and the sentence it came from and a reviewer can check the claim rather than trust it. Existing token names are never overwritten. A value already in the record was put there deliberately — most likely correcting this importer — so a re-run fills gaps and lists the rest as skipped, which also makes it safe to repeat. Colours the rulebook names but never exposes as a custom property produce no token: it never asked for one, and inventing a name would put something in the record no rule sanctions.	2026-07-30 21:23:32 -04:00