Everything Enhanciar can do

A Resume button for failed runs, teammates can watch a run, and the “found in your code” banner stops appearing after a failure

• Resuming always worked; nothing offered it. Completed workers and the integrator checkpoint to GCS, so a second attempt skips the domains that finished and redoes only what failed — the failure message even said “re-run the same ingest to resume”. But acting on that meant going back to Add source, finding the repo again and pressing Ingest, with nothing on screen promising it would not all be re-billed. There is a ↻ Resume button on a halted run now. It re-creates the job from the ORIGINAL document’s source, branch and workspace, so a resume cannot land somewhere other than the run it is resuming, and it carries the original model override and ingest mode — a resume should run the way the run ran, not the way today’s defaults would.
• Why a failed run still cost money. Scout runs first and SUCCEEDS — it clones and analyses the repository — and that is the spend on the Cost page (three pipeline:enhanciar_scout calls). The workers died afterwards at instruction-render time, before any model call, so they cost nothing. The money bought real work, and that work is checkpointed: Resume does not buy it twice.
• A teammate could see a run and not watch it. Activity became workspace-scoped, but both job readers still refused on uid != caller — so the invited member saw IDLE and an empty event stream beside a Recent Jobs row for the very run they could not open. Watching is now allowed for members of the workspace the job FILLS. It fails CLOSED: a membership lookup that errors denies, because this decides who reads a job’s stream — the opposite direction from the duplicate-ingest guard, which fails open because it only prevents waste.
• The “Found in the code you ingested” banner had a false premise. The database scan that feeds it runs during the clone, which succeeds even when every worker afterwards dies — so a run that produced 0/117 documents still wrote its detected-sources file, and the banner offered to connect a Firebase “found in the code you ingested” next to a job the user had just watched fail. It is silent when the workspace’s latest run failed, and judged on the LATEST run only: an older failure behind a later success is no reason to hide something the successful run stands behind.
• Picking which run to watch falls out of the above: Recent Jobs is workspace-scoped and clicking a row already selects it, so with several ingests in flight the list is the picker — and a teammate’s row now opens instead of 403-ing. Suite 2341 passed / 1 skipped; eslint clean; build green.

Escaping the braces fixed one outage and shipped another — the worker prompt now has none

• Same symptom, different engine. A prose example in the worker prompt was written ${VAR}, which .format() read as a replacement field: KeyError: 'VAR', every worker dead, 0/117 documents. Escaping it to ${{VAR}} fixed that and broke it again one layer down — .format() turns {{VAR}} back into {VAR}, and the rendered string is handed to ADK as an agent instruction, where {VAR} is a SESSION CONTEXT VARIABLE. Result: Worker error: 'Context variable not found: `VAR`.', every worker dead, 0/117 documents. The same outage, twice, from opposite fixes.
• The guard passed through both. It asked only whether .format() succeeds — which after escaping it did. Braces are load-bearing to two templating engines in sequence, and surviving the first is not surviving the second. The rule is not “escape the braces”; it is that the RENDERED instruction must contain no brace-wrapped identifier at all. The prose says shell $VAR now, which neither engine touches.
• The new guard checks what ADK sees, not what Python does: it scans the rendered output for {identifier} and fails with the reason. Verified by reintroducing ${{VAR}} and confirming the suite goes red, then restoring — a guard that has never been seen to fail is not known to work.

Search Console’s “Blocked due to unauthorized request (401)” was the sandbox refusing to hand over robots.txt

• The property covers every subdomain. Search Console is registered as sc-domain:enhanciar.in, so Googlebot crawls sandbox.enhanciar.in as part of the same site. It asked for /robots.txt to learn the rules and the password gate answered 401 — the same as everything else.
• A 401 on robots.txt does not read as “stay out”. Google’s spec treats an unreachable robots.txt as no rules at all, so the crawler kept crawling and kept collecting 401s. The errors were the symptom of the FILE being unreachable, not of the pages being protected. The X-Robots-Tag: noindex on every gated response was doing its job; it never got the chance to add “and don’t bother asking again”.
• A gated host now serves its own policy. Four static lines — disallow everything, and name the public site — and /robots.txt is exempt from the gate so they can actually be delivered. Nothing is revealed: the response is a sign on the door, not a key.
• Exact match, not a prefix. The exemption matches /robots.txt (and its two path aliases) precisely. A startswith rule — which is how every other exemption in that list works — would have quietly opened /robots.txt.bak and anything else sharing the prefix. Tests pin both halves: the file is reachable, and the app behind it is not.
• Not touched: the other two reports. “Page with redirect” is Google recording that a URL redirects, which is what a redirect is for; and “Discovered — currently not indexed” is Google’s own crawl-budget decision on a new site, not a fault to fix. Only the 401 was ours. Suite 2336 passed / 1 skipped.

The Ingest button says whether it will cost anything, before you press it

• The reassurance arrived too late to reassure. The pipeline has always run a cheap git ls-remote against the last-ingested SHA and, when they match, returned before cloning, parsing or spending a single token. But that answer appeared in the event stream AFTER the job started — so the button still read like a bill you were about to incur, and the only way to find out it was free was to commit to it. Same check, moved in front of the click: “Already up to date at a1b2c3d — no new commits, so this run costs no tokens.” A first ingest says so too, since that one really does read everything.
• “We could not check” is never dressed up as “free”. No network, a private repo with no readable installation, a slug that resolves to nothing — all return unknown and the strip says nothing at all. Claiming a run is free when we do not know is the one wrong answer this feature could give.
• Connector syncs got the duplicate guard too, and need it more. A repo re-read is nearly free when the SHA is unchanged; a connector re-sync always re-walks the source’s API, so two people pressing Sync on the same Notion is two real fetches and two sets of enrichment on real keys. Keyed on the same source string the job stores, so gdrive://folderA and gdrive://folderB stay independent work, and a Notion sync never blocks a repo ingest.
• Debounced, like the branch lookup beside it. The check shells out to ls-remote; firing one per keystroke in the paste box would be a network round trip per character.
• Private repos are covered. The freshness probe mints an installation token under the same visibility rule as everything else in the GitHub surface — only an installation the caller’s ACTIVE workspace can already see — and falls back to unknown rather than guessing.
• Tests: duplicate connector syncs detected, different filters independent, connector and repo runs not confused for one another. Suite 2333 passed / 1 skipped; eslint 0 errors; build green.

Activity shows the whole team’s runs, and a repo already being ingested is refused instead of ingested twice

• Everyone saw only their own runs. Activity queried jobs by uid, so in a shared workspace each member had a private view of a shared brain — which is exactly how two people ingest the same repository at the same time, each unaware the other started. It is scoped to the WORKSPACE now. In a personal workspace ns == uid, so nothing changes there.
• Nothing crashed when that happened, and that was the problem. Two presses produced two clones, two sets of LLM calls on real keys, and two writers racing to produce the same wiki pages, with last-write-wins deciding the result. Starting an ingest that is already running now returns 409 naming the repo and, when it was not you, the person who started it, and pointing at Ingest → Activity.
• A slug and its URL are the same repository. The comparison normalises both sides through the shared repo_source helper, because the picker sends owner/repo and the paste box sends the full address — and a guard that treats them as different repositories is bypassed by using the other box.
• Three things deliberately do NOT block. A finished run; a DEAD run (a crashed job still reads as “running” until something sweeps it, and letting it block would make one crash permanently un-ingestable); and the other kind of run on the same repo — “Ingest code” and “Ingest issues + PRs” read different things and cost differently.
• It fails OPEN. If the duplicate lookup itself errors, the ingest proceeds. This prevents waste; it is not a safety control, and refusing real work over a failed convenience check is worse than the rare duplicate it would spare. That is the opposite of the membership checks shipped earlier today, which fail CLOSED because they decide who may read a brain — the direction is chosen per check, not per codebase.
• Who started it, without adding chrome. The Recent-jobs rail is deliberately one line per row (a previous change cut three lines of it from a 260px column), so the name rides the tooltip and a small initial appears on the row — and ONLY when the run is not yours. “Started by you” on every row is noise; a teammate’s run is the one fact that changes whether you should press Ingest.
• Tests: a teammate’s run appears and another workspace’s never leaks in; a duplicate is detected across slug/URL forms; finished, dead, and different-kind runs do not block; and the guard fails open when Firestore is unavailable. Suite 2329 passed / 1 skipped; eslint 0 errors; build green.

The branch picker offered “main” for a repository whose default branch is “master”

• Picking the only branch on offer failed the clone. /api/branches recognised only sources starting with http. The repository PICKER puts a bare owner/repo slug there, so it fell through to the local-path branch, found no .git, and returned nothing — and the UI fell back to a hardcoded main. For enhanciar/treak_n_go_final-master, whose default branch is master, the dropdown offered exactly one option, main, and choosing it produced fatal: Remote branch main not found in upstream origin. The ingest pipeline had always promoted the slug correctly; it just did so INLINE, so nothing else could share it.
• Both now call one function. New enhanciar/repo_source.py, used by the branch lookup and by the pipeline. Two copies of a regex cannot promise agreement, and this is what disagreement looked like: the picker and the thing that clones held different opinions about the same string the user chose.
• Private repositories were silently branch-less too. An unauthenticated ls-remote cannot see them, so the list was empty for precisely the repositories the GitHub App exists to reach. The lookup now mints an installation token when the caller’s ACTIVE workspace has an installation that can read that repo — the same visibility rule as the rest of the GitHub surface. A token failure falls through unauthenticated rather than blanking the list, because a public repo still works that way.
• The error path is scrubbed. git echoes the URL it tried, and an authenticated URL carries the installation token, so a failed lookup could have returned it to the browser. The response runs through redact_secrets — the same scrubber the job event stream uses, which knows the x-access-token shape.
• A dead line turned out to be load-bearing. The original inline version ended in .rstrip('/'), plainly meaning to accept owner/repo/ — but the regex ran first and rejected it, so the strip was unreachable and a pasted fragment with a trailing slash stayed a “local path” forever. The trim now happens before the match, which is what it always looked like it did.
• Tests pin the slug forms, that URLs and explicit paths are left alone, that an existing local directory named foo/bar is NOT mistaken for github.com/foo/bar, the full-name extraction the installation lookup depends on — and, statically, that agent.py has not grown its own slug regex again. Suite 2321 passed / 1 skipped.

The Connectors grid and the GitHub pane stopped disagreeing about whether GitHub is connected

• Two screens, two answers. A member of a team whose GitHub App is bound to that team opened the GitHub pane and saw the installation, the account and both repositories — then went back two clicks to Connectors and was offered Connect. The detail pane resolved installations by WORKSPACE; the grid still resolved them by uid. One of them had to be wrong, and it was the grid.
• The fix is to match the line directly beneath it. Slack’s check in the same handler was already workspace-scoped, carrying a comment about this precise failure: a uid-wide answer “produced a green badge next to ‘Slack is not connected for this workspace’ on the Ingest page”. GitHub now resolves through _resolve_workspace_ns the same way. In a personal workspace ns == uid, so nothing changes there.
• What is and is not shared, stated plainly. Generic connector credentials (Notion, Jira, Confluence, Linear, Zendesk) resolve through _integration_data, which reads the ACTIVE workspace’s document — so a connector connected while a team workspace is active is stored on the team and visible to its members. Slack matches on a stamped workspace_id, so a team install is found by the team; legacy installs without that field surface only in the installer’s personal workspace, deliberately, because folding them into every workspace the installer belongs to would silently widen what a team brain can read. GitHub now behaves the same as both.
• Which workspace was active when you connected is the thing that decides it. Connect Slack with Personal selected and it stays personal; connect it with the team selected and the team gets it. That is one rule across every connector rather than a per-connector quirk — but it does mean the switcher in the header is load-bearing at the moment you press Connect.
• Tests: a bound installation is visible to the team and NOT to a member’s personal workspace; an unbound one is invisible to the team and still visible to its owner. Suite 2304 passed / 1 skipped; build green.

“Use my own key” for a workspace, and both Install buttons behave the same

• An owner with a working key was asked to type it again. With workspace_keys on, a team resolves its key from the WORKSPACE, so someone who had already configured a perfectly good personal key was sent to a form to paste it a second time — a form that cannot show them what they typed the first time. The likely outcomes were a typo, or a key pulled out of a password manager into a clipboard that did not need to hold it. There is a Use my own key button now.
• It copies the CIPHERTEXT, so nothing is ever revealed. Personal and workspace preferences are encrypted with the same application key, so the stored bytes move across unchanged: the plaintext is never decrypted, never in the server process, and never on the wire in either direction. That is also why there is no “reveal my personal key so I can paste it” flow — this is strictly better than one.
• A copy, not a link. Rotating your personal key later does NOT follow through to the workspace, because a workspace key funds other people and must not change under them as a side effect of an unrelated personal action. Press the button again to re-copy; that is the same write as any other rotation. The model and base URL travel with the key, because a Groq key under a Gemini model fails at the first call — the exact trap onboarding already solves by saving them together.
• Refused rather than silently empty. Copying with no personal key set returns an error naming what to do, instead of writing blanks and leaving the workspace configured-but-dead — a state whose error would otherwise surface later, at the first question a member asks.
• Both “install” buttons now do the same thing. The small badge in the corner had been taught to re-link an already-installed App before falling through to GitHub; the big Install Enhanciar on GitHub button in the setup card was still a bare link. Anyone who followed the numbered instructions rather than spotting the badge got the old silent bounce. Two buttons that say “install” must not behave differently.
• The scoping guard caught this change and was right to. Both documents this route touches are now listed in its allow-list with reasons. The users read is the interesting one: it must NOT be scope-resolved, because resolving through the active workspace would copy the workspace’s key onto itself and make the button a silent no-op. Suite 2302 passed / 1 skipped; eslint 0 errors; build green.

A GitHub installation can belong to a team — by binding, never by mere membership

• Teammates could not see the workspace’s GitHub connection at all. Installations were listed by installer uid only, so the person you invited to a team saw “no installations · 0 repos” while the owner saw the repos — on the same workspace, in the same product whose pitch is a shared brain. An installation BOUND to a team workspace is now visible to that workspace’s members.
• Binding is the consent signal; co-membership is not. A note in installations_for_workspace had long proposed “any installation owned by any member of this workspace”. That is deliberately NOT what shipped, because it leaks: install the App on your personal account for your own use, join a team months later, and your private repos would appear to colleagues without you ever saying so. What is shared is what its owner explicitly attached to the team using the picker on the Installations row — an affirmative act by the person whose GitHub account and LLM key are involved.
• Seeing it is not the same as governing it. Of the three routes guarded by the old owner-only check, exactly ONE opened up. Ingest code is available to members, because it spends the CALLER’s own key, once, into the workspace they are looking at. Setting the watched branch and moving where pushes land stay with the installer, because those are standing rules that spend the INSTALLER’s key on every future push. The response carries is_owner so the UI can hide what a viewer may not change.
• Re-sync now binds to the workspace you are actually in. The claim route records the active workspace — its own comment calls that “the ONE moment in the install flow where a workspace picker is in scope” — but re-sync omitted workspace_id entirely, so every installation it adopted came back bound to nothing and its row read “pushes fill your personal brain” while the header said testing team. Re-sync is such a moment too: a button pressed in the app with the switcher on screen. It resolves through _resolve_workspace_ns, so a header naming a workspace you are not a member of still falls back to personal rather than binding someone else’s brain to your pushes.
• Fails closed, everywhere. An unbound installation stays private; one bound to its owner’s PERSONAL brain is not a team share; a membership lookup that errors denies rather than allows; and a removed member loses access immediately, with no cached grant. A workspace-lookup failure degrades the listing to your own installations — never to empty, so a flaky query cannot make your own connection appear to have vanished.
• Tests cover each of those: member may ingest a bound installation, stranger may not, unbound and personal-bound stay private, the check fails closed on error, and a removed member is refused on the next call. Suite 2299 passed / 1 skipped; eslint 0 errors; build green.

The invite email’s “Accept” button now actually accepts

• The button labelled “Accept the invite” accepted nothing. The mail links to …/enhanciar/?invite=<token> and nothing in the app ever read that parameter — the token was dropped on arrival. It worked at all only because the Workspaces banner matches invites by EMAIL rather than by token, so a new person had to sign up, then discover a pane they had never heard of to find the invitation the email had just promised to accept for them. The token is redeemed on arrival now.
• The token survives sign-in, because sign-in is a page load. Held in sessionStorage, not React state: the un-signed-in case is the entire point of the link, and that case bounces through an auth provider and back, which discards anything in memory. The parameter is stripped from the address bar immediately — a live token sitting in a URL gets pasted into chat, shared in screenshots, and re-fires on every reload — and it is cleared BEFORE the request, so a failure cannot leave something that retries on every render for the rest of the session.
• Clicking the link twice is success, not an error. A spent invite used to answer “this invite has already been used or was revoked” — alarming wording for the ordinary act of clicking an emailed link a second time, or clicking it after joining in the app. When the invite is spent AND the caller is already in the workspace, the link has landed on the state it was for: the route returns 200 with status: already_member and the UI says “You’re already in Acme.” The friendly path is not a way in — only a CURRENT member gets it; a different account presenting the same spent token is still refused.
• Implemented as an AlreadyMember subclass of InviteError, so every existing except InviteError keeps behaving exactly as before and only the caller that cares looks for it first. The membership check happens outside the transaction, so the transaction’s read set does not widen.
• Joining lands you somewhere sensible — the new workspace is made active and the app opens Workspaces, rather than dropping you on Home to work out whether anything happened.
• Tests: accepting twice returns already_member with the right workspace; a spent token still 400s for an account that never joined. Suite 2295 passed / 1 skipped; eslint 0 errors; build green.

“Install” stopped silently bouncing you to GitHub, invite mail points at the environment that sent it, and Workspaces got its badge

• The one-button install could not tell “nothing to link” from “could not check”. Its helper returned null on ANY non-OK response and never threw, so the catch written for it never ran and a GitHub API failure was indistinguishable from a fresh install: the button bounced you to GitHub to install an App that was already installed, and said nothing about why. It now has three outcomes — request failed (say so and stay, because sending someone to re-install over a 502 is how you end up with two installations), linked > 0 (adopt and reload), linked = 0 (genuinely nothing to adopt, go install). The failure message names the status or the server’s own detail.
• Every link in outgoing mail pointed at production. _APP_URL was a module constant hardcoded to enhanciar.in. The sender name already read “Enhanciar [sandbox]”, but the buttons in the body did not — so a sandbox invite could only be opened on prod, where the workspace it names does not exist. Links are resolved per environment now: ENHANCIAR_APP_BASE_URL, else PUBLIC_BASE_URL (what each service already publishes about itself), else production. PUBLIC_BASE_URL is read and never written — on sandbox it is pinned to the run.app origin because that is what the Google OAuth redirect is registered under — so the override names the friendly host for mail only.
• Workspaces had no badge, and an invitation is the most badge-worthy thing in the app. It is the one piece of state that arrives from another person and blocks on you, and the pane is only useful if you know it has something in it. Unlike the Actions and Ingest badges it is deliberately NOT cleared by opening the tab: those count things you have not looked at, whereas an unaccepted invitation stays pending whether or not you looked. It clears on accept, via a workspaceMembershipChanged event — named a word apart from the existing workspaceChanged (“the ACTIVE workspace switched”) precisely because two near-identical event names are a trap.
• The invitation now says who sent it. The record stored invited_by as a raw uid, so the banner could only manage “you’ve been invited to this team workspace” — an unsigned request to join someone’s shared brain, when who is asking is the single most relevant fact for deciding. The route resolves inviters in one batched lookup, exactly as it already resolves members, so the UI never receives a bare uid. A deleted inviter degrades to the generic wording rather than printing an opaque identifier, and no lookup runs at all for an unverified invitee, who is shown no invites anyway.
• Tests: inviter resolved; unresolvable inviter yields blanks and never the uid; no lookup for unverified invitees; mail links follow the sending environment, honour the friendly-host override, fall back to production when nothing is set, and do not double a trailing slash. Suite 2293 passed / 1 skipped (2287 + 6); eslint 0 errors; build green.

Onboarding explains what a workspace is, and lets you make a team on the spot

• The switcher offered a choice nobody had been told about. The header dropdown listed “Personal” and any team workspaces, to someone who had never been told workspaces exist — so the honest reaction to it was “what am I picking?”. A third onboarding step now explains it once, in the one place where explaining a concept is the entire job: a workspace is one brain — the wiki, graph and answers built from what you ingest into it. Two cards, Personal and Team workspace, each saying plainly who can read what.
• Fully skippable, and skipping is the expected answer. A solo user already HAS a personal workspace and needs to do nothing, so the step defaults to Personal and Continue is a no-op. There is a Skip for now besides. Nothing about team structure blocks the path to a first ingest.
• Inviting is optional inside the optional step. Choosing Team asks for a name and, separately, for teammate emails marked Optional — any number, comma separated, none being a valid answer. A team can be created now and filled later from Workspaces. The copy states what an invite actually does: each person gets an invite they have to accept, so nobody is added to your brain without agreeing — which is what the endpoint has always enforced, and was previously stated nowhere the inviter would see it.
• It comes AFTER the key, deliberately. The API key is the one thing without which nothing in the product works; it should not sit behind a question about team structure that most users will skip. Both exits from the key step — saving and skipping — route here, because skipping the KEY should not also skip the question of where knowledge lands.
• A workspace created here becomes the active one immediately. Creating a team and then still writing into your personal brain is exactly the confusion this step exists to remove.
• Invites are best-effort and reported per address. One typo must not discard a workspace that was created successfully — the workspace is the hard thing to redo here; an invite is one field in Workspaces. Failures are named in a toast so it is clear which ones to retry.
• Verified end to end against a stubbed backend (throwaway harness, deleted before committing). Walked Welcome → Key → Workspace: the step chips read Welcome / Key / Workspace with the third active; picking Team reveals both fields; submitting an empty name is refused with a message and zero API calls; a filled form issues exactly POST /workspaces followed by one POST /workspaces/<id>/members per address, stores the new workspace as active, and completes the flow. Suite 2287 passed / 1 skipped; eslint 0 errors; build green.

A deleted workspace stopped haunting the switcher — and the “Select…” box goes back to saying Personal

• The remembered workspace and the real list were never reconciled. The active workspace id lives in localStorage; the switcher fetches the actual list from /api/workspaces. Nothing compared them. So a workspace that had been deleted, left, or wiped server-side survived in storage indefinitely: the switcher rendered its placeholder because no option matched, headerFor() kept putting the dead id on the wire, and every “into <workspace>” label kept printing the remembered NAME. That is how a GitHub repo card promised an ingest into “testing team” while the switcher directly above it showed nothing selected. The list now clears a stored id it does not contain.
• That is also the whole reason the box said “Select…”. Its options are Personal (value '') plus each team workspace, so the placeholder shows only when the stored value matches no option — which is precisely the stale case. With the id cleared the control reads Personal again, which is both accurate and a great deal easier to understand than an empty prompt.
• Nothing was ever written to the wrong brain. _resolve_workspace_ns verifies membership and falls back to the personal namespace for a non-member, so the dead id resolved harmlessly. The bug was that the interface named a destination the server was never going to use — quietly wrong, which is worse than loudly wrong, and the same shape as the namespace bugs fixed earlier: written under one identity, read under another.
• The labels are reactive now, not read once. GitHubPanel read the active workspace bare during render, so it would have kept printing the dead name until some unrelated state change happened to re-render the pane — exactly the window in which someone presses “Ingest code”. It holds the value in state and listens for workspaceChanged, the event the switcher already fires.
• Fails safe. The clear runs only on a list actually received: a non-OK response yields no list and the network path is caught, so a flaky request can never silently move someone out of their workspace.
• Verified by reproducing it. Seeded localStorage with a dead id named “testing team”, stubbed /api/workspaces to return a list without it, and rendered the real panel: the card first read “Read it now into testing team”, and after the reconcile the stored id was null and the card read “Read it now into your personal brain”. Suite 2287 passed / 1 skipped; eslint 0 errors; build green.

Ingest picks from the repos you have actually connected, and keeps the paste box for the ones you have not

• Your connected repos were the hardest ones to reach. They were already being fetched and offered — through a native <datalist> on the repository input. A datalist is autocomplete: invisible until you type a matching prefix, so the repos you had deliberately connected were discoverable only by guessing at their names. They are a real picker now, built on the app’s own StyledSelect rather than a bare <select>, searchable past eight repos, listing owner/name exactly as the ingest route expects. Choosing one sets the same source value typing it would, so the branch lookup and the submit path are untouched.
• The paste box stays, and that is deliberate. clone_repo() takes a plain HTTPS URL with no token, so any PUBLIC repo ingests with no GitHub App installed at all — and the ↻ sample button fills github.com/karpathy/nanoGPT, which is in nobody’s installation. “Repos you have connected” and “repos you can ingest” are therefore different sets, and a picker alone would have removed the only try-before-you-install path in the product. With nothing connected the field is the text box it always was; with repos connected the picker leads and “Paste a URL instead →” is one click away, with “← Pick from your N connected repos” to go back.
• The empty state now says what is missing and why it matters. With no installation the note reads: any public repo works as-is; private ones, and automatic re-ingest on every push, need the App — followed by a link straight to Connectors. Previously the field said nothing at all about the difference, so the reason to connect GitHub was invisible at exactly the moment it was relevant.
• One link style, not two. The inline actions reuse the existing .linkish treatment; its selector was widened from .note-row to cover .ic-note as well, rather than adding a second class for one visual treatment — which is how two link styles start drifting apart.
• Verified both states in a browser (throwaway harness with the installations endpoint stubbed, deleted before committing). Connected: the picker lists all three stubbed repos, “Paste a URL instead” swaps in the text box with the sample button, and the back link returns to the picker — a full round trip. Not connected: text box and sample button present, no picker, and the connect-GitHub prompt rendering in the accent colour, which also confirms the widened CSS selector actually applies. Suite 2287 passed / 1 skipped; eslint 0 errors; build green.

One “install” button that reconnects first, and a GitHub rail entry that appears only once GitHub is connected

• “install” and “re-sync” asked the user to know something they cannot. If the App is installed on GitHub but orphaned from the account — which happens after a delete-and-recreate, and after any wipe that drops the installation→uid mapping while GitHub still has the App installed — then pressing install does nothing. GitHub will not re-send installation.created for an App it has already installed, so the honest-looking button was the one that could not work, and the one that could was labelled with a word describing our internals. There is one button now. It tries to re-link silently; if something orphaned turns up it is adopted and you never leave the page; only if there is genuinely nothing to re-link does it send you to GitHub. Once an installation IS linked there is nothing to re-sync, so the button becomes a plain manage link out to GitHub.
• It navigates in the same tab, deliberately. window.open after an await falls outside the click’s user-gesture window and popup blockers eat it — the button would appear to do nothing at all, which is a worse failure than the one being fixed. GitHub redirects back on its own via the setup callback, so a same-tab hop is also tidier: no orphaned tab left behind. The “30 seconds” instructions and the empty-repo card were both rewritten to match; they used to say “GitHub opens in a new tab” and “click install to connect”, the second of which was precisely the wrong advice for anyone already installed.
• GitHub leaves the SOURCES rail until it is actually connected. The rail entry and the GitHub row inside Connectors render the same component, so it was one destination behind two doors — but only one of them told the truth. Sitting permanently under SOURCES next to Ingest and Connectors, the rail entry implied a source you had, while the Connectors row correctly offered Connect. It is now gated on a real installation, using the flag filter Sidebar already applies to nav items rather than a second mechanism. Once connected it earns the slot: that pane carries installations, repositories, per-repo branch pickers and webhook state, which you return to far more often than any other connector’s detail view. The check re-runs on the header’s Refresh, so an install or a re-link reveals the entry without a reload, and it fails closed — a failed probe hides the entry rather than leaving a dead one.
• Correction to the previous entry. It claimed the “Other · OpenAI-compatible” provider row rendered an empty tile because NavIcon id="link" was missing from Sidebar’s ICONS map. That was wrong: link is present, and the grep behind the claim had been truncated before reaching it. The SVG count offered as proof was taken only AFTER the change, so the “seven of eight” it was compared against was an inference, not a measurement. The row was always fine and has been reverted to link, which suits a custom endpoint better than connectors anyway. Every NavIcon id used anywhere in the app has now been checked against the map programmatically: none are missing.
• Verified. Sidebar rendered with the flag off and on: 18 items vs 19, the single difference being the GitHub entry, with SOURCES going from Ingest + Connectors to Ingest + Connectors + GitHub. Suite 2287 passed / 1 skipped; eslint 0 errors; build green.

The feature tour was being suppressed for the account that had never seen it

• One browser-wide flag stood in for a per-account fact. The seven-step post-onboarding walkthrough is gated on localStorage.getItem('enh_tour_seen') — a single unscoped key. localStorage belongs to the BROWSER, not to the account, so the second account to sign in on a machine was told it had already seen a tour it had never seen. This is not hypothetical: wiping Firestore and signing up fresh leaves localStorage completely untouched, so the new account got no walkthrough at all and the feature looked like it did not exist. Anyone reusing a laptop, a shared demo machine, or a second test account hit exactly the same thing. The key is now enh_tour_seen:<uid>, set and read at all three call sites through one tourSeenKey() helper so they cannot drift apart.
• The old key is deliberately not migrated. Anyone still holding a bare enh_tour_seen sees the tour once more under their own uid. For the accounts the bug skipped that is the correct outcome and the whole point of the fix; for everyone else it is one repeat of a seven-step carousel with a Skip button on every step. Reading the old flag forward would have preserved the exact silence being fixed.
• Per-uid rather than server-side, on purpose. A tour is a nudge, not state worth a schema change and a migration. The trade is explicit: the worst case now is seeing the walkthrough again on a second device, which is milder than the bug it replaces — never seeing it at all.
• The tour itself was verified, not assumed. Rendered standalone in a throwaway harness (deleted before committing) and stepped through: it advances 1→7, and the tab behind the overlay follows each step, ending on Connectors, which is what step 7 targets. Nothing was wrong with the component — it was simply never being mounted. Suite 2287 passed / 1 skipped; eslint 0 errors; build green.

The dropdown now looks like a dropdown, the key step says what the key buys, and “Other” got its missing icon back

• The open menu’s active row drew a square ring inside a rounded panel. The row that the arrow keys are sitting on carries its own mark — “where the cursor is” and “what is chosen” are different facts, and a list showing only the second gives a keyboard user nothing to steer by. But it was drawn as a 2px square-cornered outline on a full-bleed row, inside a panel with borderRadius: 10 and its own 1px border, with no padding between them. The two edges touched and their corners disagreed, so it read as a rendering fault rather than as focus — worst on a one-option menu (the workspace switcher with a single Personal workspace), where the ring and the panel border became two nested rectangles a few pixels apart. The row is borderRadius: 7 now, so the ring follows the curve and sits concentric with the panel, the list carries 4px of padding so the two edges never touch, and the ring is 1.5px rather than 2px. Shared control, so every dropdown in the app is affected.

• The caret was a text glyph, so the control did not read as one. StyledSelect’s trigger ended in a •-class ▾ character at fontSize: 10 and opacity: 0.6, separated from the option’s mono hint by an 8px flex gap. At that size, that weight, and that distance it read as punctuation on the end of the hostname — aistudio.google.com ▾ — rather than as an affordance, and the whole row looked like a filled-in field nobody could open. It is a real SVG chevron now: 15px, strokeWidth 1.75 to match every other icon in the app, its own layout box, and a marginLeft that separates it from the hint instead of crowding it. It still rotates 180° on open. This is the shared control, so all ~20 call sites get the better caret.
• The key step now says what the key is spent on. Cutting the four-claim BYOK paragraph and the cost badges left the card with a lead line, two fields and two buttons — correct, and mostly empty. Handing an API key to a product you have used for ninety seconds is the highest-friction moment in this flow, and the page answered “is it safe” (the lock line) without ever answering “what will you spend it on”. Three items now do: Ingest (reads your repos and connectors, once per change), Wiki (writes each page, with a citation for every claim) and Answers (every question you ask, grounded in your own code). They are named after the panes they produce, so the claim is checkable rather than reassurance. Laid out with auto-fit/minmax rather than three fixed columns — at 375px three columns would be ~110px each and the body copy would break after two words, so it collapses to one column on its own.
• The “Other · OpenAI-compatible” row was rendering an empty tile. It asked NavIcon for id="link", and there is no link in Sidebar’s ICONS map. NavIcon returns null for an unknown id — no warning, no fallback, no error — so the eighth row drew a bordered 26px tile with nothing inside it while the seven brands above all had a mark. It uses connectors now, which is what a custom endpoint is. Worth naming the failure mode rather than just the fix: an icon-by-id lookup that returns null for a typo fails silently and looks like a spacing bug, not a missing asset.
• Verified in a browser at both widths. Same throwaway harness approach as the change above (stubbed backend, deleted before committing), since the key step sits behind Firebase auth locally. Confirmed at 1280px: the chevron reads as a control and flips on open, and all eight option rows carry exactly one <svg> — the count that was seven before the link fix. At 375px: the native <select> branch renders with all eight options in “Google Gemini — aistudio.google.com” form, the three key-spend items stack to a single column, and document.body.scrollWidth equals the viewport, so nothing overflows. Suite 2287 passed / 1 skipped; eslint 0 errors, 39 warnings; build green.

Eight provider chips became one dropdown, with the real logos and no invented prices

• Chips sized to their own labels cannot be a grid. The key step rendered eight buttons that each took the width of its text — “Other · OpenAI-compatible” is three times “Groq” — wrapped into whatever rows fitted, so the break points moved with the viewport and nothing lined up with anything. They are now rows in a single Provider dropdown, and every row has the same three columns: brand mark, name, and the host that issues the key (console.groq.com, aistudio.google.com, “your endpoint” for the generic option). That last column answers the question a first-time user actually has — where do I get this? — before they choose rather than after.
• It extends the shared control instead of drawing a menu here. StyledSelect gained an optional leading icon and a right-hand hint per option, so the ~20 other call sites get both for free and this screen keeps the full ARIA combobox pattern, arrow/Home/End/typeahead keyboard handling, and the real <select> below 900px. On that native branch an <option> can only carry TEXT, so the icon is dropped — it is decoration — and the hint is folded into the option label after an em dash, because it is a FACT about the option and must not disappear with the viewport. A new proportional flag, defaulting off, is what lets a list of proper nouns be set in IBM Plex Sans while every existing caller (branches, model ids, repos — all machine strings, where a fixed advance is the point) stays in JetBrains Mono. The hint stays mono either way; it is a hostname.
• Real marks for all seven, from one source. New providerIcons.jsx, same rule and same provenance comment as connectorIcons.jsx: path data copied verbatim, never redrawn. simple-icons — which the connector icons use — has Gemini, Ollama, Anthropic, Mistral and OpenRouter but no OpenAI and no Groq, verified against a pinned 16.28.0 where both 404. Filling those two gaps from a second set would have put two different optical weights in one dropdown, so all seven come from @lobehub/icons-static-svg v1.94.0 (MIT), an icon set built for AI providers, drawn as one family. OpenAI’s is the current mark, not the retired hex-knot. Every mark is monochrome currentColor on one neutral tile, so a row’s selected and active states stay legible — and so that nothing in the file is a guess about somebody else’s brand colour. There are no hardcoded hexes, and a test enforces that.
• The cost badges are gone, and they are gone from the data. Free / Free tier / Cheap / Paid asserted third-party pricing that we do not control and cannot keep current, on the screen where a new user is deciding. One of them could never have been right: Gemini is free AND paid depending on the model and the quota, so no single word was accurate. The cost field is off the onboarding provider entries entirely, not merely unrendered, because a field left lying there is an invitation to render it again. Settings → Models & API keeps costNote() deliberately — a different question at a different time, where the user is already set up and actively choosing a MODEL, and the sentence doubles as “here is where that key comes from”.
• The BYOK paragraph is one line, and the amber box is gone. The lead stacked four claims — whose key, who bills, which are free, how it is stored — into a paragraph at step 2, where nobody reads a paragraph. It now reads “Your key, your billing — change or revoke it any time.” The storage half moved to the one quiet line above the buttons, next to the lock, which is where it belongs; the “several of these are free” half went with the badges. Nothing was relocated into a tooltip or a details expander — the instruction was to say less, not to hide it. The amber “without a key you can’t ingest or chat” notice sat directly above a Skip link that says the same thing by existing.
• The host in the row is derived from the link, never retyped. keyHostOf(keyUrl) reads the hostname off the page the “Get a key →” button already opens. Two strings for one fact drift, and this pair would drift visibly: the row naming one host while the link opened another. One literal survives in the table — “your endpoint” for the generic option, which has no host until the user types one.
• Verified in a browser; one mark is worth flagging. Signed-in panes sit behind Firebase auth locally, so the real components were rendered against a stubbed backend in a throwaway Vite harness (deleted before committing). Confirmed: all eight rows with correct marks and hosts, the trigger repeating the chosen row’s mark and host, keyboard open/arrow/End/Enter with focus returning to the trigger and type-to-jump on the closed control, the phone branch rendering a real <select> whose options read “Google Gemini — aistudio.google.com” with zero horizontal overflow at 375px, and an untouched plain StyledSelect (label + sub, no icon, no hint) rendering exactly as before. Every save path still holds: base URL absent and scheme-less both refused with zero requests, a remote endpoint with no key refused, a localhost endpoint saving with an empty key, and the Test verdict clearing on a provider switch. Ollama’s llama-head mark is the finest of the seven — it is a multi-path line drawing and at 15px inside the tile it reads a touch denser than the others. It is legible and it is the real mark, so it stays; substituting something cleaner would mean drawing their logo ourselves. Suite 2287 passed / 1 skipped; eslint 0 errors, 39 warnings; build green.

Refreshing the browser on the key step skipped onboarding entirely

• One flag meant two different things. POST /api/profile stamped onboarded_at on the FIRST save of any profile field, and onboarding’s step 1 posts the role / team-size / use-case answers the moment you press Continue. App.jsx reads that same flag as “already onboarded, skip the flow”. So the flag was written to mean “answered the first question” and read to mean “finished onboarding”, and a single browser refresh between those two moments dropped the user into the app having never seen the key step — with no key saved, and chat and ingest silently disabled. Anyone who reloads, closes the tab and comes back, or gets bounced through an OAuth round trip mid-flow hit it.
• Completion is now stated, not inferred. The route takes an explicit onboarded: true and stamps the timestamp only for that; saving profile fields is just saving profile fields. That distinction matters beyond onboarding, because the endpoint is shared: Settings → Account writes role, team_size and use_case through the very same route, so under the old rule an existing user editing their role was re-stamping a flag about onboarding. The first stamp still wins — when somebody actually finished is a fact about the past, and neither re-finishing nor a Settings edit years later rewrites it.
• The flag is owned by the EXITS, not by the steps. OnboardingFlow wraps onComplete and onSkip once at the orchestrator level, so every path that leaves the flow — Save key & continue, Skip to dashboard, Skip for now on step 1 — leaves it marked, and a step added later cannot forget to say so. That also closes a smaller hole in the same place: skipping from step 1 without answering anything saved no fields at all, so nothing was ever stamped and the whole flow reappeared on the next sign-in.
• The key-based branch stays, deliberately. App.jsx treats a saved BYOK key as “already set up” alongside the flag, which fixes a different loop: skip onboarding, paste a key in Settings, reload, and get thrown back into the flow. Only the flag’s timing was wrong. And the flag is only trustworthy as a completion signal now that nothing else writes it.
• Users already mid-flow keep their flag. Somebody who answered step 1 before this shipped has onboarded_at set for the wrong reason — but that timestamp is byte-identical to a genuinely finished user’s, and there is no field that tells them apart. Backfilling would therefore mean re-running onboarding for people who completed it. They stay onboarded; the key step is reachable from Settings → Models & API, which is where the skip path already sends everyone.
• One caveat, stated rather than papered over. A refresh now keeps the user inside onboarding, but it restarts at step 1 rather than resuming on the key step — the wizard’s step is component state and nothing persists it. They press Continue once more and they are back where they were, with a key step they can no longer be skipped past. 10 tests: what step 1 sends, what Settings sends, what each exit sends, that onboarded is a signal and never a stored field, and that the first stamp wins. Suite 2259 passed / 1 skipped; eslint 0 errors, 39 warnings; build green.

Onboarding showed a new user three paid options and hid every free one

• The fourth provider was never mentioned at the moment it matters most. The onboarding key step offered Google Gemini, OpenAI and Anthropic — two of them labelled “Paid only” — on the second screen a new account ever sees, the screen where someone decides whether this product is worth setting up. Settings has always had a fourth route, the OpenAI-compatible “custom” endpoint backed by custom_base_url + custom_key, and that route is where every genuinely free option lives: Groq, Ollama Cloud, OpenRouter. Nobody arriving at onboarding was told it existed. The step now offers eight providers and puts the cost on every chip, not only the selected one — a free option has to be visible without clicking each one to find out.
• It is not “custom endpoint” plus two blank fields. Someone at this step does not know what an OpenAI-compatible base URL is and should not have to. They pick a NAME — Groq, Ollama Cloud, OpenRouter, Mistral — and the endpoint is filled in and stated back to them (“Endpoint filled in for you: https://api.groq.com/openai/v1”), which is the same auto-fill Settings has done since the OpenRouter/Mistral URLs shipped. The generic “Other · OpenAI-compatible” option is still there, with its own base-URL and model-name fields, for the people who do know.
• One table of facts, not two lists of URLs. The four base URLs and the per-provider cost copy lived inside SettingsPanel.jsx. Copying them into OnboardingFlow.jsx would have created the classic silent drift: a URL changes, one screen is updated, the other keeps writing the stale value into the same preference field, and nothing fails loudly. They now live in frontend/src/llmProviders.js together with the curated model floor, and each screen composes its own sentence from the same facts — Settings appends “…field below”, onboarding does not. The auto-fill rule itself is one shared function, including the part that matters: a URL the user typed is theirs and is never overwritten, only one we filled in moves when the model moves.
• Every cost claim is one this codebase already made. Nothing was invented for the new chips. Groq, Ollama Cloud, OpenRouter and Mistral carry the pricing and the key-issuing page Settings already stated; Gemini, OpenAI and Anthropic carry the sentences onboarding already used, including “Paid only” unchanged. Key-shape placeholders are only shown where we have actually seen the shape — guessing one tells a user their real key is wrong — so three providers say plain “API key”. Local Ollama is deliberately NOT a named chip: the endpoint is called from our server, so localhost is our localhost and not yours, a constraint the chat model list already records. It stays reachable through “Other”, where the caveat can be stated next to the field.
• Onboarding can no longer save a state that breaks on the first ingest. resolve_ingest_model raises when the provider is custom and the base URL is empty, with a message pointing at Settings — so a screen that could save that combination would hand someone a finished onboarding and then a failure on a page they have never opened. The base URL is now checked before the request (present, http/https, has a host), and the model name is required for the generic option and prefixed custom/ when it carries no prefix the backend recognises. The step also saves the MODEL with the key, which it never did: the provider is resolved from the model id, so a saved Groq key sitting under the default Gemini model produced “No Gemini API key saved” at the first ingest. That was true of the old OpenAI and Anthropic buttons too.
• The key is optional for exactly one case, and no more. llm_model.py substitutes the literal "ollama" when custom_key is empty, because an endpoint on your own machine authenticates with nothing. So a loopback base URL relaxes the key field — the placeholder, the error and the button label all change — and a remote one does not: “a key is only optional for one running on your own machine”. Silently accepting a blank key for a remote endpoint would just move the failure to the first ingest.
• The Test button was reusable, and this is the better place for it. KeyTest was already built as its own component rather than welded into Settings, so it dropped in with the provider set to custom and the resolved base URL passed through. Verifying here is worth more than verifying in Settings, because this is where a wrong key costs you the user. It is remounted per provider so a “Key works” verdict about a Groq key can never sit under an OpenAI one, and the key field clears on switch for the same reason.
• Verified in a browser. The signed-in panes sit behind Firebase auth locally, so both real components were rendered against a stubbed backend in a throwaway Vite harness (deleted before committing). Confirmed: the eight chips with their badges; Groq filling https://api.groq.com/openai/v1 and the key placeholder becoming gsk_…; the Test button returning a verdict inline and that verdict disappearing on a provider switch; and the four save paths — a Groq key writing {model: groq/llama-3.3-70b-versatile, custom_key, custom_base_url} to PUT /api/account/preferences, an empty base URL and a scheme-less one both refused with zero requests made, a remote endpoint with no key refused, and a localhost endpoint saving with an empty key. On the Settings side, picking the OpenRouter model still auto-fills its URL and the cost line still reads “Free tier · create a key at openrouter.ai/keys”, now from the shared table. Suite 2249 passed / 1 skipped; eslint 0 errors, 39 warnings; build green.

The Map painted its empty state and its loading state on top of each other

• Two components were both answering “is there anything here”, and during a fetch they answered differently. GalaxyGraph draws its own “No graph yet — ingest a repo to grow your galaxy.” caption whenever it is handed zero nodes, and the Map pane mounted the canvas unconditionally — so while /api/wiki/graph was in flight it was handed zero nodes, every time. The pane then laid “Mapping your galaxy…” over the same centre point of the same absolutely-positioned box, and the two sentences interleaved into unreadable text.
• The fix is single ownership, not a hidden caption. Suppressing one string would have left the same two components deciding the same thing. KnowledgeGraphV2 now returns exactly one of three mutually exclusive states — PaneLoading, PaneEmpty, or the populated canvas — and the canvas is only mounted once there is something to draw. Adopting the shared PaneState component for the loading half also means the Map stops being the one pane whose “still working” state was a bare grey line: it gets the same titled, skeletoned treatment as Wiki, Tables, ERD, Skills, Impact, Actions and Reviews. The stats strip, the source chips and the cluster legend lost their !loading guards, which are now unreachable by construction. GalaxyGraph’s caption stays as a last-resort fallback for a future caller, with a comment recording that whoever owns the empty state must own the loading state too.
• The other graph panes were checked and are fine. ERDiagram already branched showLoading ? … : showEmpty ? … : canvas on a shared tables.length === 0, and DbGraph guards each of its three bodies (loading / no-connection / connected-but-unread) on the same loading flag — neither can co-occur. BlastRadiusGraph has no loading or empty state at all by design: it returns null without a result and lets ImpactPanel own both. The Map was the only pane that had split the decision across two components.
• Verified in a browser, and one thing could not be. The signed-in panes sit behind Firebase auth locally, so the real component was rendered against a stubbed /api/wiki/graph in a throwaway Vite harness (deleted before committing): loading shows “Laying out the knowledge map” alone with no stray empty-state text, empty shows “Nothing to map yet” alone, and populated shows the stats strip, the legend and the rail. The force-directed canvas itself painted nothing in the automation browser — but that is environmental, not this change: the pane reports document.hidden === true permanently, which stops GalaxyGraph’s requestAnimationFrame draw loop from ever starting, and mounting GalaxyGraph alone with no Map pane involved reproduces it identically. A plain canvas on the same page paints normally, so it is not a screenshot limitation.

The reset-the-world button can spare a few collections — as a KEEP list, never a delete list

• The direction of the list is the whole design. wipe_firestore() enumerates collections LIVE (for coll in db.collections()) precisely because the hand-maintained delete list it replaced had drifted and silently left behind google_accounts (OAuth refresh tokens), slack_installations (bot tokens) and conversations (chat PII) — credential remanence. So the ask “wipe, but keep a few things” is implemented as a KEEP list that only ever SUBTRACTS from that live enumeration. The two fail in opposite directions and only one fails safely: a stale delete list means something survives that should have gone; a stale keep list means something is deleted that could have been kept. The second is an annoyance. The first is the bug. A collection nobody names is still deleted, including one added to the schema tomorrow — there is a test that invents one and checks it dies.
• Kept: waitlist, waitlist_meta, waitlist_orders, config, and analytics by default. Each carries its reason in the code, because the reason is what makes the entry reviewable. waitlist_meta is the subtle one: it is the position COUNTER, and keeping waitlist without it resets the next position to 1, colliding with numbers live entries already hold — a test asserts the two can never be listed apart. waitlist_orders is paid early-access orders. config holds the early-access / waitlist-mode gate flags read by enhanciar/waitlist.py; wiping it leaves signup in an undefined state, worst case silently open to the public.
• Analytics is kept by default and opting out is one click. analytics_visitors and analytics_events are people who visited the landing page and never signed up — not users, and the only record that they came at all. They are the one part of the list an operator plausibly wants gone, so they are their own checkbox on the Danger Zone page and a --wipe-analytics flag on the CLI the module docstring advertises. Opting out of analytics does not take the rest of the keep list with it; that is also a test.
• What SURVIVED is reported, by name and count. A destructive tool that silently spares things is as bad as one that silently deletes them, so the return value grew from a flat {name: deleted} to {deleted, kept, kept_missing}, and the Streamlit progress log prints a KEPT n docs — <reason> line per spared collection alongside the delete lines. The keep list is also rendered in the Danger Zone UI and printed by the CLI before the confirmation phrase, not after: the operator should see what lives while deciding.
• A name that matches nothing is visible, not silent and not fatal. These names are hardcoded. If one is renamed the wipe still runs to completion and reports the keep entry as having matched nothing — so a typo shows up as a dud entry rather than as a keep rule quietly protecting an empty set. wipe_gcs and wipe_auth_users are untouched: GCS holds wiki pages and uploads, all disposable, and auth-user deletion was already a separate opt-in defaulting off.
• admin/ had zero test coverage, and cannot get CI coverage. The whole directory is gitignored on purpose — it reads cross-tenant data and ships this button, so it is never pushed. 13 tests now exercise the keep set against an in-memory fake client, and they skip cleanly on a checkout without admin/, which means CI is not a guard here and the tests only run on a machine that actually holds the tool. Stated rather than papered over. Suite 2249 + 13.

Two housekeeping fixes that had no changelog entry, and the rule that caught them

• The secret-scan test contained a shape-accurate fake GitHub token, and gitleaks failed the build on it (238b68b). Correctly — a scanner cannot tell a fixture from the real thing, which is the whole reason it is worth trusting. The test does need the right shape, since the redactor keys on ghs_ plus length; randomising the characters only swaps github-app-token for generic-api-key. Now built at run time from "ghs_" + "A" * 36: correct prefix, correct length, zero entropy, no literal a scanner can match. The old value is allowlisted as a scoped regex because history is immutable — never a path allowlist, per the note a previous whole-file skip earned itself.
• Four directories sat untracked AND unignored (f532971) — .firebase/, _claude-sessions/, brand/, AGENTS.md. That is the dangerous middle state, because git add -A stages exactly that set, and a working-tree sweep found 255 findings across them: built bundles and credentials quoted inside session transcripts. The only thing that had prevented it was an accident — staging ~1,800 files fails the push with RPC failed; HTTP 400. A size limit is not a security control.
• Both of these shipped without a changelog entry, which is the actual defect being recorded here. The process rule at the top of this page says every fix lands here; 13 of the previous 15 commits did, and the two that did not were both hand-written rather than agent-written. Documenting a red build is worth more than documenting a feature — the feature is visible, the near-miss is not.

The model already notices credentials the scanner misses. We were throwing that away.

• This is a report, and it is not the control. The gitleaks pass above is the control and stays the control: it runs before anything is read, it redacts the value, and it costs no model call. What this adds is the opposite kind of finding. The extraction workers read every file anyway — on the customer repo that started all this, one of them noticed the hardcoded Razorpay credentials unprompted and wrote about them in a wiki page. That observation was discarded. It is now collected. Because redaction already ran first, anything a worker can still see is by construction a hole in the pattern list.
• Reporting, never prevention — and the UI is not allowed to blur the two. By the time a model can notice anything, the file has already been sent to the provider. A gitleaks finding means “caught, the value never left”. A finding here means “a credential was transmitted and we did not stop it”. They are two events, not one: secrets_found stays amber and says found and redacted … never sent to a model; the new secrets_missed is red and says the pre-ingest scanner did NOT catch this, it had already been sent, this is not a block, rotate it. The counts are never added together. A test asserts the two sentences stay different, because merging them would turn a miss into a reassurance, which is worse than not reporting at all.
• No new model call, on purpose. The ask is ~30 lines folded into the worker extraction prompt that was already being sent, and a credential_sightings array added to the JSON the worker already returns. Enhanciar is BYOK: an extra call spends the customer’s money, so if it could not be folded in it would not have been built. Collection reads worker output and the clone, and a test greps the module to make sure it never grows a call.
• Four fields, and none of them is the value. A finding is {path, line, kind, why}, rebuilt field by field rather than passed through, so a field the model invents cannot ride along carrying a secret. Every string is then scrubbed on the assumption the prompt was ignored — a prompt is not a control — using the provider shapes from redact.py plus the same randomness test the scanner uses. The pinning test hands it a model that quotes the credential in why, in kind, and in three fields nobody asked for, and asserts no returned finding contains a high-entropy string.
• Every claim is re-checked against the file on disk before anyone sees it. The prompt names what not to report; the code assumes it was not read. A path outside the clone, or one the repo does not contain, is a hallucination and is dropped. A line whose neighbourhood holds nothing but process.env.X, <YOUR_API_KEY> or our own REDACTED_CREDENTIAL is dropped. A position gitleaks already owns is dropped, because that one was caught and re-reporting it under the scarier headline would be false. .env.example, docs, fixtures, mocks and snapshots are dropped. A why that restates the finding instead of giving a reason is dropped. Stated plainly: a real key committed in docs/ is missed by that filter. The deterministic scanner still redacts it.
• Measured on a real repo, not asserted. Run over 15 real files / 2,802 lines of this codebase with the shipped prompt: zero sightings, which is correct — the repo is clean. With one credential planted in the shape the scanner misses (an opaque literal assigned to authBlob, then passed as key_secret): exactly one sighting, right file, right line, value not quoted. The same files with the “do not report” list removed: four sightings, three of them false — a Razorpay key_id, a Firebase web apiKey, and a reCAPTCHA site key whose own why quoted the comment above it saying the key is public. So the exclusions are carrying about 75% of the noise, and two fixes came straight out of that run: published-by-design identifiers (site_key, publishable, client_id, project_id, app_id, bucket names) are now exempt the same way the Firebase key already was, and the “is there a candidate literal here at all” floor was raised from 8 characters to the scanner’s own 16 — at 8, projectId: "enhanciar-web-2d0c7" was enough to keep a whole Firebase config alive as a finding. All three false positives are now dropped by the code alone, with no help from the prompt.
• The exemptions are per-literal, not per-region. A whole-region veto would let one Firebase apiKey silence a real secret assigned three lines below it — which is exactly where a real one tends to sit. And the Firebase judgement is not a second copy: it calls secret_scan’s own helper, so the two cannot drift into declining to redact a line and then reporting that same line as un-redacted, in the same run, on the same file.
• The findings are filed as bugs against the scanner, which is the durable part. Each one is appended to _secret_scan_gaps.jsonl beside the wiki and logged at WARNING on enhanciar.secret_scan.gaps, where an engineer can turn it into a gitleaks rule or a secret_scan pattern. Positions and descriptions only, no values. Nothing auto-adds a pattern: a model-proposed regex inside a security control is the last thing this wants.
• 39 tests, including the no-high-entropy pin, the two-sentences-stay-different pin, and a check that the prompt fold-in is still present — without it the collector would simply never see a claim and the feature would be silently dead. Suite at 2233.

A key hardcoded in an ordinary file was ingested, sent to a model, and written into the wiki

• The guard caught credential files, and the leak was not in one. repo_tools has redacted .env, service-account JSON and .pem since early on — by filename, and by file-level fingerprints like -----BEGIN PRIVATE KEY-----. A real customer repo ingested yesterday, treak_n_go_final-master, had a live Razorpay key_secret assigned on one line of functions/index.js: an ordinary Cloud Functions file, innocent name, no fingerprint. It was ingested whole and sent to the model provider. The wiki page it produced even remarked that the code “uses hardcoded test credentials” — the model noticing in passing what no control had checked. That is the customer’s secret, not ours.
• Every clone is now scanned before Scout, the workers or the AST pass read a byte. The scanner is gitleaks — not a hand-rolled regex list, which is the thing that rots. It is already a pinned hard dependency of this repo’s own CI, so it is a maintained, deterministic version of what we would otherwise have written badly, and it now ships in the runtime image at the same version the CI gate uses. Deterministic, no model call, ~3s on a few hundred files. A small builtin pattern floor runs unconditionally underneath it, because a guard that silently no-ops when a binary is missing is not a guard.
• It redacts the value, not the file. key_secret: "jYcD…" becomes key_secret: "REDACTED_CREDENTIAL". The line stays, the key name stays — so the page can still say what the service is configured with — the file stays, and the source stays syntactically valid so the AST pass is unaffected. The whole-file stub is still right for a .pem, where the file is the secret; it is wrong here. functions/index.js is that repo’s only backend file, and losing its page to hide line 8 is the worse outcome. The public key_id beside it is untouched.
• Redaction happens on the way out, never on disk. The clone is not rewritten. That is deliberate and it is what keeps database auto-detect working: db_detect opens files directly to pull projectId, apiKey and connection strings, and scrubbing the tree would have broken a working feature to fix a different one. Only what leaves for a model, the wiki, an event or a webhook is filtered.
• A Firebase web apiKey is deliberately not a finding. It is public by design — Firebase documents it, the bundle ships it, and this repo’s own .gitleaks.toml already says so. gitleaks cannot tell it from a real server key, so left alone it would fire on essentially every Firebase repo, and an alert that always fires is one nobody reads. Exactly that shape is dropped: an AIza… browser key in an apiKey assignment. Stated plainly, because it is a real trade: a genuine GCP server key written in that same shape is missed. Any other AIza… string still gets caught.
• You are told what was found and where. Silently redacting is not enough — a key we hide is still committed, and if the repo is public it is still readable by everyone but us. Ingest › Activity now carries an amber line naming the file and line number of each finding, and saying to rotate it. Not the Actions queue: those findings are documentation drift (gap / conflict / stale / owner), they file as tracker tickets, they are rationed to five a week, and the whole layer is behind a flag that is off by default — so a live credential could be dropped on a budget meant for doc suggestions, or never shown at all. This is not a suggestion to triage.
• The value is never collected, so it cannot leak by a route nobody thought of. gitleaks runs with --redact; a finding is {path, line, rule} and nothing else. There is no field for the secret in the event, the audit record, the jobs API response or the outbound webhook, because it is not carried that far. The provider-token shapes also went into redact.py, which every one of those exits already passes through — one list, both directions, so a token this scanner learns to catch in a file cannot still walk out through the event stream.
• A repo cannot switch the scan off. Given no explicit config, gitleaks reads .gitleaks.toml from the directory it is scanning — during ingest, the customer’s repository. A permissive allowlist committed there would have disabled the guard that exists to protect them. Every scan is handed our own config instead. There is a test that plants one and checks the finding still lands.
• 34 tests, built around a fixture repo shaped like the one that leaked. The fixture credential is assembled from four-character chunks at run time: it needs the real shape — 24 characters, mixed case, no prefix, which is the entire difficulty — but a realistic literal in a committed file is indistinguishable from a live key to a scanner, and a test fixture has broken this repo’s own gitleaks gate three times before. Suite at 2192.

The outbound redactor knew our credentials and not the customer’s

• redact.py exists because a private clone URL carries a live GitHub token, and every event, job document and outbound webhook that echoed “the source” was publishing it. It has scrubbed that since it was written. But the risk at those same three exits runs in both directions: we read private repositories, and repositories commit third-party keys — AWS, Stripe, Slack, GitLab — which reach the identical choke points by the identical route, inside an exception message, a git error, or a Firestore document written months ago.
• It now knows the common provider shapes too. Ten token forms, each one a credential wherever it appears with no surrounding context needed. They go into the redactor and into contains_secret, which is this codebase’s single definition of “leaked” — so every sweep the leak suite already performs over emitted events, job documents and webhook payloads now covers the customer’s keys as well as ours, with no second mechanism to keep in step.
• Google’s AIza… key is deliberately absent from that list. A Firebase web API key has exactly that shape and is public by design; db_detect reads it to identify which database a repo uses. A blanket string filter cannot see the assignment around a value, so scrubbing it here would silently corrupt database auto-detect. It is judged positionally instead, where the surrounding line is available. There is a test that pins the exemption, so nobody “completes” the list later.

The verifier was answering a question nobody asked, and calling it a verdict

• 132 of 502 claims on one real wiki came back “unsupported”, which a reader takes to mean the product made them up. Two mechanisms produced most of that, and neither is about the claims.
• Every claim on a page was judged against the FIRST readable file it cited. A page citing cart.js and pricing.js had its pricing claims checked against cart.js — and the critic correctly reported that cart.js does not support them. That answer was then stored as a verdict about the claim. The more source a page cited, the more fabricated it looked.
• Now a claim is put to the files its page cites until one settles it. Round one is exactly what ran before; a claim that comes back supported or partial stops there, so a page whose claims verify costs what it always cost. Only the ones that did not settle go to the next cited file — precisely the set that was producing the false negatives — and each round is smaller than the last. Capped at four files per page, under one call budget for the whole run, because escalation must not multiply a ceiling whose purpose is to bound what this stage spends of your key.
• “I cannot produce a verbatim quote” was mapped to “unsupported”. That collapses two findings that mean opposite things: this file shows the claim to be wrong or absent, and there is no line here that settles it either way. Interpretive prose — a purpose, a rationale, a design intention — is always the second. There is nothing to quote because the question is not that kind of question.
• So the critic gained a fourth verdict and the rule was reversed. No quote now means unverifiable, and unsupported is reserved for what it says: the file contradicts the claim, or plainly does not do the thing named. The prompt spells out why the distinction matters, because the model is the one making it.
• Neither change moves a threshold to make the number look better. A claim unsupported by every file it cites is still unsupported — a checker that cannot say no is not a checker, and there is a test that says so. What changed is that the verdict is now about the claim rather than about whichever file happened to be listed first.

Map, Files and Skills were empty after an ingest that worked

• Nothing was lost. A team-workspace ingest wrote wiki/ws_…/; three panes read wiki/{uid}/. They were looking in the caller’s personal brain and truthfully reporting that it was empty.
• The systemic cause, fixed first: the app attached half an identity automatically. A global fetch interceptor put Authorization on every /api call — who is asking — while X-Workspace-Id, which brain they are asking about, had to be hand-spread at each of ~190 call sites. Forgetting it does not fail; it silently reads the personal namespace, because “no header” means “personal” by design. And on a personal account the two namespaces are the same string, so the mistake is invisible until someone uses a team. The interceptor now attaches both.
• Safe to send unconditionally, and that is why the global fix was possible. FastAPI ignores headers a route does not declare, so the deliberately per-person routes — billing, account preferences, API keys, workspace CRUD — are untouched: not one of them declares it. Every route that does declare it resolves through the one resolver, which verifies membership and falls back to personal for a non-member, so a stray header cannot reach a workspace you do not belong to. The existing per-call-site spreads were left in place: they set the same value, and removing sixty-seven of them is a large diff whose only effect is deleting redundancy — while one missed in the sweep reintroduces exactly this bug.
• Map needed fixing on both sides. GET /api/wiki/graph declared no workspace parameter at all, so no client change could have reached it. Its dead “merge every namespace on disk” branch — a leftover from before the route was authenticated — is now closed by an explicit check rather than by inference.
• Skills was worse, because it wrote as well as read. All four routes ignored the workspace, and job_create defaults the destination to the uid — so pressing Compile inside a team mined the personal wiki and wrote the skills back there, reporting success the whole way. A default that is right most of the time is the worst kind: it makes the omission invisible.
• Extending the guard found four more nobody had reported — the wiki manifest (twice), the operation log, and the per-workspace page counts, all reading the uid for files the ingest writes under the namespace — plus the WhatsApp ingest, which was the only connector route still not naming the workspace it fills.
• The static guard now covers the brain, not just Firestore. Every guard we had watched collection("users")-style access; none of these bugs touch Firestore at all — the wiki is a directory tree. Two new rules: a route that reads under WIKI_ROOT resolves the namespace, and a route that enqueues a job names the workspace it fills. Both are lists of reviewed exemptions with a written reason each, and both were checked against the pre-fix source: they flag exactly the reported bugs and the four latent ones.
• Correctly empty, and deliberately left alone: Tables, the DB graph and the ER diagram read database schema, which only a live introspection writes — a frontend repo with no SQL database has nothing there. Actions is legitimately empty after a clean ingest. Their header bugs are fixed by the interceptor; their emptiness was never a bug.

The database suggestion says where it read that, and what pressing the button does

• “Detected in your ingested code” named no evidence, so it read like a guess. It is not one — the detector is pure regex over manifests, config files and connection strings, with no model anywhere in it. It found trekngo-f4e81 by reading the user’s actual Firebase config. Saying so is the whole difference between a product that guessed and a product that read your code, and it was the one thing the banner did not say.
• Every evidence line now names its file. “firebase” in package.json; config file firebase.json; “firebaseConfig” in src/firebase.js; projectId “trekngo-f4e81” in src/firebase.js. The detector previously knew all of this and threw it away: it concatenated every scanned file into one corpus, so a match could not be traced back. It now keeps the file alongside the text.
• Two evidence lines were actively unhelpful and were changed. Code signals printed our own regex — code: /initializeApp\s*\(/ — at a reader who has never seen it and cannot check it against anything; they now quote the text that actually matched. And a committed database URL is evidenced by naming its file, never by quoting the DSN: that string is rendered in the UI and written to disk, and printing postgres://user:password@… to prove we found a password is publishing it.
• “Connect (auto)” did not say what it did. It writes the detected connection in immediately — no form, no confirmation — into whichever workspace you are looking at. Both facts are now on screen before the click, the workspace named in bold, because that destination has been wrong on this exact route before.
• …and it did not do what its position implied. One call saves EVERY auto-connectable detection, not the one whose card you pressed — so with three suggestions, a button drawn on the first card was quietly connecting the other two. The action moved out of the cards and below them, and counts what it will do: Connect all 3 now. The cards are now purely evidence.
• The button was also writing to the wrong brain. It posted to /api/connectors/db/auto-connect with no X-Workspace-Id, and that endpoint resolves the destination from exactly that header — so a click made while a team workspace was on screen filled the personal one. Naming a destination and then writing somewhere else is worse than naming nothing, so the header ships in the same change as the label.

Re-entering Connectors shows the connectors

• Open a connector, go to Chat, come back to Connectors — and you were looking at that connector again, with no memory of having asked for it and a “← All connectors” button as the only clue about where you were. The tab’s own name promises a list.
• The cause is a deliberate design decision with an undesigned edge. A visited tab stays mounted and is hidden with display:none rather than unmounted — that is what keeps scroll position and stops every pane refetching on every switch. The cost is that a pane with a master/detail split also keeps its detail, and there is no unmount to reset on.
• So entry is announced. The app dispatches a paneEntered event when the active tab changes, and the panes with somewhere to return to listen for it. Connectors returns to the grid; Skills closes an open skill and the process-map overlay.
• A deep link still wins. “Open the Slack connector” from the Ingest portal or from chat dispatches openConnector in the same navigation that announces entry, so the reset would have raced it and landed you on the grid. The panel marks the entry as deep-linked and consumes that mark once, rather than relying on the order two window events and a React commit happen to run in.
• Two panes were checked and deliberately left alone. Impact keeps its target and its analysis, and the wiki keeps the page you were reading. Those are not navigation positions — they are work the user produced, and one of them cost an API call to produce. Discarding them on a tab switch would be the same bug pointed the other way.

An ingest button stays shut while its own run is going

• Both buttons on a repo card stayed live while the job they started was still running. A second click re-cloned the same commit and ran the whole analysis again — on the user’s own LLM key. The only thing stopping a double-spend was the user noticing, and the card gave them nothing to notice with: the busy state cleared the moment the request was accepted, seconds into a run that takes minutes.
• No new flag was invented for this, because the jobs API already answers it. GET /api/jobs?status=active returns every job of yours that has not reached a terminal state, each carrying its source_label (“owner/repo”) and source_type. The card reads that. A per-card “syncing” boolean would have had to be kept true across a reload, a tab switch and a run started from the Ingest tab — three ways to be wrong about something the server already knows.
• Matched on source_label, not source. A code job’s raw source is a clone URL and an issues job’s is the bare owner/repo; comparing the raw field would have matched one kind and silently missed the other.
• The reason is beside the buttons, not left to be guessed. A disabled control with no explanation reads as broken. The card says which run is going, that starting another would re-read the same commit and spend the key twice, and offers a link straight to it. The button label changes to Ingest running… so it is legible without reading the sentence.
• A newly started job is recorded locally as well as polled. The poll is five seconds behind, and those five seconds are exactly when an impatient second click lands. Conversely, a failed poll leaves the buttons live: refusing to ingest because we could not reach our own API is a worse failure than the one being prevented.

Starting an ingest takes you to the run

• Pressing Ingest code showed a toast ending “Watch it in Ingest → Activity”. That is a set of directions to a place the app can simply go. The run had started, it was streaming progress, and the user was left on the GitHub pane holding a note about where to find it.
• Both buttons now navigate. They dispatch the app’s existing switchTab event — the same mechanism the Actions and Settings panes use for cross-pane links — landing on Ingest › Activity. The toast still names the repo, the destination workspace and the job id; it just no longer ends with an instruction.
• It lands on your run, not the newest one. The event carries the new job id and Activity attaches to that specific job. Without it, Activity auto-attaches to whichever active job is newest — usually the one you started, and “usually” is not good enough when two ingests are in flight and the whole point of sending you here was to show you yours.

An ingest printed the token it cloned with

• The progress line “📥 Cloning …” printed the job’s source, and for a repo reached through the GitHub App the source is a credential. github_app.clone_url_with_token builds https://x-access-token:<token>@github.com/owner/repo.git so private repos clone without a user PAT, and that whole string was written into the job’s event log — persisted in Firestore, rendered in Ingest › Activity. In a team workspace every member can read that pane, so one person’s installation access token became the whole team’s. The owner saw their own token on screen. Installation tokens expire in about an hour and are scoped to the one install, which bounds it; it does not excuse it.
• It was never one call site. The same string also went out through “Starting ingest: …”, through job.source on GET /api/jobs (and so through the “Attached to job…” line), through the ingest.start audit record — and, worst of the set, through the ingest.completed / ingest.failed outbound webhooks, which POST to a URL the customer typed in. That one carried a live token off our infrastructure to a third party. The failure paths leaked it too: git quotes the URL it was handed back at you, so “Clone failed: …” and the job’s error field republished it.
• User-facing messages now name the repo, not the URL. New enhanciar/redact.py has two functions and the split is the point. repo_label() returns owner/repo — use it when writing a message about a repo, and it cannot leak by construction. redact_secrets() is the safety net for strings that came from somewhere we cannot vouch for: git’s stderr, an exception, a Firestore document written months ago.
• The net is hung at the choke points, not at the call sites. Roughly two hundred places emit job events; exactly one function writes them, so jobs.job_append_event scrubs every event before it is stored. job_set_status scrubs the error and result. _emit_outbound scrubs at the door. clone_repo scrubs git’s stderr where it is produced — it is also an LLM tool whose return value goes into a model prompt. A fix that lives only at the call sites is undone by the next call site somebody writes.
• Jobs now carry source_label, the repo as a human names it, so no display code has any reason to reach for source at all. The Monitor list and the attach toast read it.
• Job documents already in Firestore still contain their tokens, and we did not rewrite them. Those tokens expired within the hour, and quietly editing what a job says happened would be a worse habit than the leak — the record is supposed to be evidence. They are redacted on read instead: every job that leaves the backend goes through jobs.job_public, which also derives source_label for documents that predate the field, and the SSE replay scrubs historical events on the way out. Nothing at rest is falsified; nothing renders a credential.
• Guarded by a test that sweeps emitted events with a regex, not by a fixed string comparison. It drives the real pipeline against an authenticated clone URL, fails the clone the way git fails it, and asserts that no event, no returned job document, no API response and no webhook payload matches x-access-token or a ghs_ token. Without that assertion this comes back.
• What we did not do, stated plainly: a job document still stores the authenticated URL at rest, because the out-of-process Cloud Tasks worker needs it to clone. Firestore is deny-all to clients and only the Admin SDK reads it. Removing the credential from storage entirely means minting the token at run time from the installation id instead — a real improvement, and a separate change.

A push keeps a repo current; it never reads one for the first time

• A push into any repo the App could see used to trigger a full first-time ingest. Two things wrong with that, and they compound. The user never asked for that repo to be in their brain — installing the GitHub App on an account or org grants access, and “All repositories” is the option GitHub’s own install screen lists first, which is not the same as asking us to read everything in it. And the ingest that followed spent their own LLM tokens on their own key without them pressing anything, which is the one thing this product should never do by surprise.
• Now the webhook does what the UI always promised: it keeps current what you already put there. A push to a repo this brain has never ingested is refused. The first read stays a deliberate act — Ingest code on the repo card, or the Ingest tab.
• “Already ingested” is read from the records ingest already writes, not from a new flag that would then have to be kept true: the per-repo _state/*.json hash maps and repos.json, which are the same records the MCP list_repos tool answers from — so the webhook and the agent agree about what is in a brain. Written by the run itself, so they cannot claim “ingested” for a run that failed. Branch-agnostic on purpose: “is this repo in the brain” is a different question from “is this checkout’s hash map fresh”. The key derivation moved into incremental.repo_key_from_source so the check and save_state cannot drift onto different filenames — a drifted key would silently read “never ingested”.
• The check is against the workspace the installation feeds, never the installer. On a personal install those two ids are the same string, which is exactly how this codebase’s recurring bug hides; every test for this uses a team workspace whose id is not the uid. A repo the installer ingested into their personal brain does not license pushes into the team’s.
• A negative is checked against durable storage before it is believed. On Cloud Run the pod handling a webhook may never have served a read, so _state is absent from local disk. Everywhere else that costs a wasted re-enrich; here it would silently ignore pushes for a repo the user really did ingest — wrong in the direction that looks like the feature is broken. One GCS list, only on the negative.
• Nothing is silently dropped. “I pushed and nothing happened” has to be answerable, so the ignored delivery is logged with the repo, the branch and the namespace, and the response names the reason and the way out. last_push_at is still stamped first: delivery did work — we chose not to act on it — and suppressing the stamp would make the pane report a transport fault that isn’t there.
• Docs-on-merge was gated with it. That branch enqueues the identical full, LLM-funded ingest, so leaving it would have made “we never read a repo for the first time on our own” true of pushes and false of merged PRs. A merge is a push.
• The pane stopped nagging about a webhook that could not have worked yet. With nothing ingested, “No push has been received yet” sent the user off to check their Webhook URL, secret and event subscription — debugging a path that would have been ignored on arrival even if every byte of it were right. It now says the actual first step: ingest a repo, then pushes keep it current. Each card carries an ingested / not ingested badge, and a repo that is not ingested drops its watched-branch picker and its “re-ingests on pushes to…” line rather than offering an inert control and a promise nothing will keep.

The two buttons on a repo card say what they read, where it lands, and what it costs

• “＋ Code” and “＋ Issues + PRs” told you almost nothing. The leading ＋ reads as “add” on a card that already lists the repo, so the obvious guess is that they add something to a list. They do not: each one starts a real ingest the moment it is pressed, and one of them spends the user’s own LLM tokens on the user’s own key. A button that quietly bills you should not need a hover to admit it.
• Now Ingest code and Ingest issues + PRs, matching the product’s own word for the operation (the Ingest tab), with the verb first so the action is unambiguous. Busy states say what is happening rather than a generic “syncing” that was identical on both: reading code… and fetching….
• The explanation is on the card, not inside the button. One line above them: “Read it now into <workspace>: Ingest code clones <branch> and rebuilds the wiki + graph — that is LLM work on your own key. Ingest issues + PRs just fetches them as pages: no key, no tokens.” A button wide enough to explain itself is a paragraph.
• The destination named is the right one, which it would have been easy to get wrong. Both buttons send X-Workspace-Id, so they fill the workspace you are looking at — while the line directly above them (“re-ingests on pushes to…”) names the workspace the installation feeds. Those are two different answers on the same card, and printing the install’s workspace next to a manual button is how somebody ends up hunting for pages in a brain that never received them. The toasts name it too, and point at Ingest → Activity.
• Wording checked against the handlers, not the old labels. /api/github/repos/sync mints an install token, clones at the watched branch and runs the full pipeline; /api/ingest/issues routes to _run_issues_job, which explicitly skips the BYOK key swap because the issues pipeline makes no LLM calls. Hence “on your own key” on one and “no key, no tokens” on the other — both are what the code does, not what the previous copy claimed.

The dropdown menu escapes the box it was drawn in

• Reported on the GitHub pane’s branch picker, but none of it was that pane’s fault. The menu was a position:absolute panel pinned left:0; right:0 to its trigger, and all three defects that produced follow from that one line. Fixed in StyledSelect, where the ~20 call sites that inherited them are: a stacking or clipping bug in a shared control is not a bug in the pane that noticed it first.
• The trigger was setting the menu’s width. The branch picker’s trigger is 150px wide, so release/2026.08 and feature/very-long-branch-name-here were ellipsised into two options you could not tell apart — a picker that cannot show you what you are picking. The menu is now width:max-content with the trigger as its floor, clamped to 420px and to whatever room the viewport has. Measured on the real pane: 150px → 297px, every branch legible.
• It always opened downward. A card near the fold pushed its own menu off-screen. It now measures the room above and below and flips above the trigger when there is not enough below and more above, and caps its height to the space it actually has. Verified on all four repo cards at a 620px-tall viewport: every one flips up and stays fully inside the viewport.
• Anything with overflow could clip it, and anything with a stacking context could bury it. .gh-shell is overflow-y:auto, which per spec computes overflow-x to auto as well — a clipping box on both axes. Rather than punch a hole in one ancestor, the menu is rendered into a portal on <body> and positioned fixed against the trigger’s viewport rect, then repositioned on scroll (capture phase, so scrolling ancestors count) and resize. z-index sits above every modal in the app and below the toast layer.
• Two things a portal breaks, both caught before shipping. Outside-click tested wrapper.contains(target), and the menu is no longer inside the wrapper — so every click on an option was an outside click, closing the menu on mousedown before the option’s click could fire. It now counts the portal as inside. The opposite mistake was made and then measured away: a second onKeyDown was added to the portal on the assumption that the filter box’s keystrokes no longer reached the wrapper. React bubbles synthetic events along the React tree, not the DOM tree, so they always did — the duplicate handler ran the whole switch twice and one ArrowDown moved the active option two places. Removed.

Native <select> retired, pane by pane

• Twenty browser-default dropdowns were left in the app. They are the one control that cannot be themed — the popup is drawn by the OS — so every one of them was a visible seam in an otherwise consistent light theme. They are being replaced with the shared StyledSelect, which the entry below made keyboard-complete first, on purpose: the sweep is only an improvement if the replacement is as usable as what it replaces.
• All twenty converted: the top-bar workspace switcher; the morning-Lint hour; the Actions ticket-target picker; Settings’ processing-mode and API-key workspace pickers; the Cost reporting window; the Slack backfill window; the database-kind picker in the connector credential form; all six in the Ingest portal (enrichment model, ingestion model, branch, files-per-run, and the media model in both places it is offered); the ER diagram’s repo, database and max-tables pickers; the DB graph’s database filter; and the billing country.
• One is deliberately left native, and it is not in the app. landing/tweaks-panel.jsx is a self-contained design-time shell — it ships its own compact control kit and its own stylesheet, activates only when a design host posts __activate_edit_mode, and is never reachable by a customer. Converting it would couple a standalone prototype harness to the app’s component tree and put 26px fields next to 36px ones, for a control nobody using the product will ever open.
• The conversion has one real hazard, and it is silent. A native select hands onChange an event; StyledSelect hands it the value. A call site that keeps reading e.target.value renders perfectly and does nothing at all. Every conversion rewrites the handler, and the ones whose value is a NUMBER (the Lint hour) convert explicitly in both directions — option values are compared with ===, so a number would never match its own option and the control would open showing nothing selected.
• onFocus-to-load became onOpen-to-load. The Actions target picker fetched its Jira projects / Linear teams / GitHub repos when the select took focus; the popover fires the same fetch as it opens, so the list is loading while the menu is already on screen rather than before it appears.

The custom dropdown can be used without a mouse, and gets out of the way on a phone

• A native <select> gives you Up/Down, Enter, Escape, Home/End and type-a-letter-to-jump for free. StyledSelect — the themed replacement — handled Escape and outside-click and nothing else. Swapping the product’s remaining native selects for it as-is would have made every dropdown mouse-only: a serious accessibility regression shipped as a polish task. So the keyboard work landed first, before anything adopted it.
• The full ARIA combobox pattern, not a nearby approximation. The trigger is role="combobox" with aria-expanded / aria-controls; the popover is a listbox of options carrying aria-selected and aria-disabled. Focus deliberately stays on the trigger while the list is open and aria-activedescendant names the active option, which is what lets a screen reader announce the move without DOM focus leaving the control. Escape returns focus to the trigger — closing a list should not strand you at the top of the document.
• The active option is marked separately from the selected one. “Where the arrow keys are” and “what is currently chosen” are different facts. A list that draws only the second gives a keyboard user nothing to steer by, so the active option carries its own outline and is scrolled into view.
• Arrowing walks the FILTERED list. With the inline filter open, stepping through the underlying option array would land the cursor on options the user cannot see. Disabled options are skipped by every movement key, and by typeahead.
• Below 900px it renders a real <select>. On a phone the native control opens the OS picker — a full-screen wheel on iOS — which is better than any popover at that size, is what people expect, and comes with the platform’s own accessibility. Both branches take the same props and call the same onChange, so no caller has to know which one it got. Replacing that with a custom popover everywhere would have been a downgrade justified by consistency.

Each repo picks the branch that re-ingests it

• Auto-sync was hardcoded to the repo’s default branch. github_webhook compared the pushed ref against refs/heads/{repository.default_branch} and returned early otherwise. That covered the common case — two repos defaulting to main and master were both handled — but a repo whose current state lives on a release branch, or whose default is one the owner does not want rebuilt, had no way to say so.
• Absent means default, so nothing existing changes. The watched branch is stored per repo on the installation document; a repo with no entry resolves to its own default branch, which is exactly the comparison that was hardcoded. No migration, and the two repos this was reported against keep working before anyone touches a picker.
• The picker lists branches GitHub actually has. Opening it fetches /repos/{owner}/{name}/branches with the installation token — a dropdown of branch names nobody confirmed exist is a control that looks like it validates and does not, which is the exact defect removed from the Ingest pane earlier today. If GitHub will not answer, the menu says why and falls back to the branches already on record (the default, and whatever is configured) rather than rendering empty.
• Choosing the default branch clears the override rather than pinning it. A repo that later renames its default should follow it, not keep watching a name that no longer exists.
• The card says what it does. “Auto-syncs on every push” is now true of exactly one branch and one brain, so every repo card reads “re-ingests on pushes to branch → workspace”, and the panel’s three other “default branch” sentences were corrected with it. The queued job clones the watched branch too — enqueuing the right trigger and then ingesting the default would be the same bug one layer down.
• The repo name is a map key, not a field path. owner/name contains a slash, which Firestore reads as a nested-field separator, and set(merge=True) merges maps key by key — so clearing a branch that way would have left it exactly where it was. Written whole, with update. Both facts are pinned by tests, because both are the kind that look fine until the day someone clears one.

A push re-ingests the workspace you installed from, not your personal brain

• Every push-triggered re-ingest went to the installer’s personal brain. github_webhook called job_create(uid=…) with no workspace_id, and that field defaults to the uid. Install the App from a team workspace and the team’s wiki never moved; the installer’s own filled up with a repo nobody had asked it about. The fifteenth instance of this codebase’s one recurring bug, and it shipped for the usual reason — on a personal account the person and the workspace are the same string, so there is nothing to see.
• The workspace is recorded at claim time, because that is the only moment it exists. GitHub redirects a browser back after an install, and a browser redirect carries no X-Workspace-Id — so the setup callback cannot know which brain was meant. The SPA finishes the bind from inside the app shell, where the picker is on screen; that request now sends the header, and the installation document records the answer. Nothing else in the flow had a workspace to offer.
• Membership is re-verified on every push, not trusted from the claim. A claim is a statement about a membership at one instant; the webhook fires for years afterwards. An installation recorded against a workspace its owner has since left would otherwise keep filling that workspace’s brain forever, and nobody would think to go looking for it. Same precedent, same reasoning, as API keys re-running the membership check on every single use. An unreadable member list fails closed — an error is not permission.
• A lapsed membership stops the sync; it does not quietly redirect it. Falling back to the personal brain would write the repo somewhere other than the installation names and say nothing. The push is skipped, and the GitHub pane says so in the installation row before the user notices the wiki has stopped moving.
• Existing installations carry no workspace and stay personal — exactly what they did before. No migration, and nothing silently moves brain. The webhook events that fire on every repo add/remove (installation, installation_repositories) deliberately leave the field alone rather than defaulting it, or adding a repo on GitHub would have moved a team’s install back to personal.
• The repo cards say which brain they feed, and the installation can be changed. An install whose target you cannot see is the same hazard as an API key whose scope you cannot see. Every card names its brain, and each installation carries a workspace picker — without it, installing into the wrong workspace could only be fixed by uninstalling on GitHub and starting over, which also throws away the repo selection.
• Three more jobs in the same handler had the same defect, and one in Slack’s. The issues/PR auto-sync, the docs-on-merge rebuild and the automatic code review all created jobs without naming a workspace — so one repo would have filled two different brains depending on which webhook fired. The Slack event webhook re-ingested into the installer’s personal namespace while the @mention path in the same function answered from the team’s, using a value computed twenty lines above it.
• The manual “+ Code” button now lands in the workspace you are looking at, like “+ Issues + PRs” one button over always did. Two buttons on one card filling two different brains is the confusion, not the fix. The webhook has no picker and uses the install’s recorded workspace; a button pressed by a person uses the picker in front of them.
• CI now fails on the next one. The scoping guard grew a webhook table: every job-creating webhook handler is entered there with the expression it must pass as workspace_id, a handler nobody entered fails, one that passes nothing fails, and passing the person as the workspace can never be blessed by an entry. Two further assertions pin that the resolver still re-checks membership and that the webhook resolves through it rather than reading the field itself — a second derivation of the rule is how a read and its permission check drift apart.

The GitHub install page said “read-only”; GitHub’s said “read and write”

• The connector page claimed the App never writes. “What we read: code, repository metadata, pull request titles. Read-only. We never push, never write, never modify any branch.” That stopped being true when AI code review shipped — it posts inline review comments on a pull request, which needs Pull requests: read and write.
• GitHub contradicts it one click later. The install screen lists the permissions the App is asking for, in GitHub’s own words, at the exact moment someone is deciding whether to trust it. A page that promises read-only and is immediately followed by “Read and write access to pull requests” does more damage than saying nothing: it reads as either a lie or a compromise.
• Now it separates read from write and names the one thing that writes. Reads code, repository metadata, issues and pull requests. Writes nothing unless code review is on, and then only review comments on the PR you asked about. Never pushes commits, never writes to a branch, never modifies code — which is still true, and is the part that actually matters.
• Fixed everywhere it was said, not just where it was noticed. The same claim appeared in the security page’s connector table (“We do not push, open pull requests, or write to your repository”) and on the sign-in screen (“We never push or write back to your repos”). The docs guide gained the same paragraph. Copy that is wrong in four places is a policy, not a typo.

MCP can reach a team brain, because the key says which one

• The MCP server had no workspace concept at all. It used the caller’s uid for everything — the namespace it read pages from, the ACL check, the actions queue — so Cursor and Claude could only ever see the holder’s personal brain. A team’s knowledge was unreachable over MCP. Three tool docstrings said “for this workspace”, describing behaviour that did not exist.
• The workspace lives on the key. An MCP client configures one static token and has no workspace picker, so the key is the only place the choice can be made. The alternative — a workspace argument on every tool call — means the agent guessing, which is worse than not offering it.
• The key names a (person, workspace) PAIR, and re-earns the second half on every request. This is the load-bearing detail. A key minted for a workspace is still held by a person, and membership is re-verified on every single use rather than at mint time only. Remove someone from a workspace and their keys for it stop working immediately — no revocation step for anyone to forget, and no standing credential to data its holder is no longer entitled to. A personal key never runs that check, so keys minted before this pay nothing for a feature they don’t use.
• Any member may mint one, and that is the decision. A member can already read that brain in the app, so a key for their own editor grants them no access they didn’t have. Owner-only would mean the owner minting keys and handing them out: one shared credential, unattributable, and impossible to revoke for one person without breaking everyone. The model here is owner/member with no roles and none were added — the owner’s lever is the one they already have, and it now works: remove the member.
• Existing keys carry no workspace and resolve to personal — exactly what they did before. No migration, no breakage, and no key silently gaining team access. A stored document with no workspace_id field at all is read as personal, which is what it already was.
• One resolution path. resolve_uid is now a wrapper over the resolver that returns both identities, rather than a second lookup beside it — this codebase has thirteen shipped bugs whose shape is exactly “the read and the write resolved differently”. A key refused for one surface is refused for all of them, so the REST API cannot become the way around a workspace removal. The lookup index deliberately does not carry a copy of the workspace: it is written once at mint and never updated, so a copy there would be a second source of truth that can drift from the key document.
• A dead key is refused, never downgraded. Falling back to the personal brain would answer from a different workspace than the client is configured for and say nothing about it — the exact failure the design exists to prevent. An unreadable member list fails closed: an error is not permission.
• Every tool now takes both identities and says which one it uses. Each starts uid, ns = _identity() — the PERSON (pays for the tokens, owns a proposal they file, holds the per-person actions beta flag, is the ACL viewer) and the BRAIN (which namespace is listed and searched, which workspace owns the approval queue) — and writes _ for the half it does not need. Twelve tools, twelve declarations, mirrored in a table in the scoping guard: a new MCP tool nobody entered there fails CI, and so does one whose body reaches for an identity its entry does not list. Nothing static can decide which is correct; what it enforces is that somebody wrote it down.
• The ACL check was passing the uid twice. acl.is_visible(uid, workspace_id, …) treats membership as a precondition — an ACL can narrow access within a workspace but never grant it across one — so is_page_visible(uid, uid, …) made the precondition trivially true. Now the person is checked against the workspace, on all three page-reading tools.
• A question spends the workspace’s key. query resolved model preferences without a namespace, so a team query would have been funded by whichever member was holding the MCP token. It now resolves them the way the web chat does, and the answer is metered to the person and the workspace — MCP usage was previously recorded nowhere at all.
• list_repos read a Firestore path nothing has ever written. users/{uid}/repos appears exactly once in the codebase: in that read. So the tool has returned an empty list to everybody, forever, and it was keyed by the person on top of that. It now reads what ingest actually records for the namespace — repos.json plus the per-repo incremental-state files — and reports branch rather than default_branch, because the state file records the branch that was ingested and no caller can be depending on a key that never had a row under it. The clone’s absolute path stays server-side.
• The three docstrings that said “for this workspace” are now true, and the ones that said “the user’s wiki” say which wiki they mean. A tool description is the only thing the calling agent reads before deciding to call it.
• An empty workspace now says so over MCP too — in words written for an agent. query had the same gap the web chat and Slack were fixed for two entries below: an empty namespace produced an answer that read like “I searched and missed”. It calls the same shared module those two do, so the three cannot drift, but through a third surface rather than by reusing the web wording — because the reader here is Cursor, and “open the Ingest tab” is addressed to something with no tab and no hands. The agent wording states the fact, says to relay it to the person who can fix it, and then explicitly closes off the retry: an agent’s default on an unhelpful tool result is to reword the question and call again, and no rewording gets past a namespace with nothing in it. The statement of fact is one sentence in one place across all three surfaces; only the sentences that speak to the reader differ. The response also carries empty_brain: true, so a client can tell the two states apart without parsing prose. Answered before the model, like a greeting, so it spends none of the workspace’s key.
• The docs said the opposite. “Access is scoped to the active workspace” is true in the app and false everywhere else — Cursor, Claude and a curl script never see which workspace the browser has open. The MCP guide now says the key is what chooses, that a second workspace means a second key added as a second MCP server, that a key with no workspace chosen reads your personal one, and that leaving a workspace stops its keys on the next request. A guide that contradicts the product teaches the contradiction.
• Settings › API keys asks which workspace, and the list answers it. The picker appears only when you actually belong to a team workspace — a one-option select is a question with one answer. It deliberately does not follow the app’s workspace switcher: the workspace you happen to be looking at is not necessarily the one you want a long-lived credential for, and this is far harder to reverse than a tab switch. Every row carries a badge naming what that key reaches, including the personal ones, so a missing badge never has to be read as an answer. The workspace is named once more beside the plaintext at creation — the last moment the secret and its blast radius are on screen together. A key whose workspace has since been deleted shows the raw id rather than borrowing a plausible name: the key is dead either way, and a label would hide that.

The Cost per-member table says who, not 0wsEOjKLzhRT4VhKdK2Uf5a3KFR2

• The member column was a raw Firebase uid. The table exists to answer “who spent this”, and it was answering with the one string that cannot. Nobody had looked at it with real data in it.
• Resolved server-side: display name, then email, then a shortened id. Never an invented label — a plausible-looking name on a spend table is worse than an id, because an id is obviously something to look up. A person the directory has never heard of still has real spend, so their row renders as a short id rather than disappearing, and the cell stays monospaced only when what it is showing really is an id.
• The visibility rule is unchanged, and is now enforced by construction. The owner sees the per-member breakdown; a member sees the workspace total plus their own row. The name map is built from the member rows the response has ALREADY decided the caller may see, not from the workspace roster — so a member’s response has no member table, nothing to name, and nothing is even looked up. Resolving names was the obvious way to turn a spend view into a directory of everyone’s email addresses; deriving it from the payload is what stops that being one forgettable permission check away.
• One round trip for the whole table. get_users takes a hundred identifiers at a time, so a thirty-person workspace costs one call, not thirty sequential ones before the first row paints. The Firestore profile fallback is kept but only fires for a uid the directory returned nothing for at all — anyone it knows has an email, which is a perfectly good label — so the per-row lookup does not come back under a different name. The workspace roster resolver was rebuilt on the same batch, since it had the identical problem.

A brain with nothing in it now says so, instead of claiming it searched

• “I couldn’t find anything on that in your brain yet” describes a search that happened. Said to a workspace with no pages at all it is a lie by implication: the reader goes off to rephrase, when the answer was “ingest something first”. Asking the Slack bot what it was for, in an empty team workspace, produced exactly that.
• Two states, two messages. Nothing ingested — say so, and point at Ingest. Ingested but nothing matched — the existing wording, which is correct there. Collapsing them was the bug.
• It names the workspace it is talking about. “Your brain is empty” is confusing, and sounds wrong, to someone whose personal brain is full — which is everyone who was here before repo ingest started honouring the workspace picker, since all of it went to their own namespace. In a team workspace the message says which one is empty and that each workspace has its own brain. A workspace lookup that fails falls back to a neutral phrase rather than guessing; it will not describe a team as your personal brain because Firestore hiccuped.
• Answered before the model, like a greeting. There is nothing to ground on, so the call would spend the workspace’s own key producing a worse version of this sentence. No tokens, and the Cost page records no call for it — the same as a greeting.
• It fires only when there is genuinely nothing else, which is why it sits at the last moment before the model rather than up beside the greeting shortcut. A workspace can have a database connected and nothing ingested: those live rows, and live calendar events, are real answers and still get through. So is the clarify layer’s more specific offer — “connect this database”, “which database?” beats a generic “go and ingest”. All four conditions have to hold: nothing retrieved, nothing live, nothing better to offer, and no pages in the namespace.
• One module, both surfaces. Slack and the web chat are the same product to the person asking, and a message that exists in two copies drifts — the reason greetings.py was extracted, for this same failure. A test fails if either surface stops calling the shared check.
• Existence is measured, never a count. The check stops at the first page it sees, so no sentence here quotes a number nobody measured; and it runs only after a query has already come back empty, so an ordinary question pays nothing for it. It is deliberately not ACL-filtered — that means reading every page body, the expensive half of retrieval — and the consequence lands the safe way: a workspace whose pages are all restricted from you reads as non-empty, so you get the “couldn’t find that” message, which reveals nothing.
• It runs after the cold-pod rehydrate, which is what puts the pages on disk. Checked before that, every workspace a pod had not served yet would report as empty — the loudest possible version of this bug. Pinned by a test.

Switching workspace now actually switches the app

• The panes kept showing the workspace you had just left. setActiveWorkspace writes localStorage and fires a workspaceChanged event, and exactly four surfaces listened for it. Every other pane fetches once in a mount effect and then stays mounted — tabs are kept alive on purpose so returning to one does not refetch — so nothing re-ran. Switch to a team workspace and the app carries on rendering your personal brain, with a header that says otherwise.
• The fix is a full page reload, and that is deliberate rather than lazy. The underlying problem is a race, not only stale state: a fetch issued under workspace A can resolve after the switch to B and paint A’s rows into B’s view. Remounting every tab does not stop that unless every in-flight request is cancelled or every response is re-checked against the workspace current at resolve time — dozens of call sites, each one a chance to miss. Tearing the document down cancels all of it at once, for free. Please do not “optimise” this into a remount and quietly bring the race back.
• It does not reload when nothing changed. Re-picking the workspace already active is a no-op. Personal is the empty string and a team is an id, and the two are compared as distinct values rather than by truthiness — a truthiness check reads personal→team as “no previous workspace” and team→personal as “nothing selected”. Nor does it reload on first load: the previous id is seeded when the listener is installed, not read inside the handler, where it would already hold the new value.
• It also does not reload when the switch was not persisted. setActiveWorkspace swallows a localStorage failure (private mode) and relies on the event alone to carry the switch for that page load. Reloading there would re-read the old id and silently undo the click, so the write is confirmed first. That is also why the four in-place listeners were kept rather than deleted as redundant: in that case they are the entire mechanism.
• An ingest already running is untouched. Jobs are enqueued server-side and their state lives in Firestore — an asyncio task locally, a Cloud Tasks HTTP worker in production. The browser only subscribes to events; reloading it re-fetches the job and re-attaches.
• What a reload does cost, stated plainly: an unsent chat draft, a half-filled ingest form and an unsaved wiki edit are in-memory only and are lost. Chat threads are server-side and come back. No confirmation prompt was added — that is a separate decision, not something to slip in with this.
• There is no JS test runner in this repo, so window.location.reload cannot be exercised. The tests assert on the source instead — the same approach the clarify tests already use — pinning the no-op case, the mount case, the personal/team distinction, the storage-failure case, and the write-before-dispatch ordering the reload depends on.

Ingest › Activity now draws the run the way the design draws it

• The run header was a different object. The design’s is one 16/18-padded card whose first row reads pill, source, elapsed-pushed-right, with the stage sentence, the bar and the stage strip below it inside that same padding. Ours had an “Agent activity feed” title with a broadcast glyph, a hairline rule under the row, and a second block inset by a different 10/14/4 — so one object was cut in half and inset by two amounts. The title also named the same thing as the “Event stream” heading eight pixels below it. Gone; the pill is the title.
• “Stage 3 of 8” sets its two numbers apart. The design puts the figures in mono at full ink inside an otherwise sans, secondary sentence — they are the only measured thing in it. It was one flat string.
• In the stage strip, only the dot carries the state. The name stays in ink for any stage the run has reached, muted for any it has not. Colouring the name too made a finished stage shout as loudly as the running one, so the strip read as eight competing labels instead of a track with one lit cell.
• The terminal is a log again. Design: 12/16/14 padding, 1.85 line, capped at 300px, and a row of exactly two cells — a 32%-alpha timestamp and the message. Ours was four cells on a 1.5 line inside 8px of padding, each row an 8px-radius box with a hover band: an icon glyph, an agent chip repeating a word already in the message, and a right-aligned column repeating the event type the colour already encodes. The chip and the type column said the same thing twice per line on the one surface meant to be skimmed vertically.
• Job summary reads in the design’s order, with its labels. Status · Documents · Wiki pages · Errors. It ran Status · Events · Errors · Documents · Pages, so the two counts saying how far the run had got sat below the error count they are meant to be read against. “Pages” became “Wiki pages” (alone it reads as pages of the source), and zero errors is green, not grey — grey said nothing, so “no errors” looked identical to “not measured”. Recent jobs drops its “(4)”.
• The Agents card is gone. The design’s right rail is two cards. The third one reported numbers nothing measures: Scout jumped to 100% on a regex over message text, Integrator to 70% when a line contained a party emoji, and Workers was the same done/total already stated one card above as Documents. Three bars, one real fact, and that fact had a home.
• Still deliberately unlike the comp, and staying that way: the strip shows the backend’s real stages (8 for a repo, 2 for a connector) rather than the comp’s fixed 5; there is no “Tokens so far” row and no per-job progress bar, because no event carries a token count or a percentage; and the idle / complete / failed states have no counterpart in the comp at all.
• Diffed against a real render, not a description. The owner’s screenshots were of an idle pane, where the header, bar, strip, stream and summary are all absent — the comp draws a running job. The component was rendered with running props at 1360×940 in a browser to compare like with like.

Every pane is the same width — and that width is a deliberate departure from the design

• Seven panes, seven widths. Ingest was a 960px centred column with 32/30/48 padding, Billing 980/28, Settings 1060/24, Home 1120/40-28, Workspaces 760/24-20, Workforce had no horizontal padding at all, and Connectors was full-bleed at 24/28. Switching tabs moved the content sideways every time. Each of those numbers was written into its own component, which is precisely how they drifted apart.
• They now all read one rule. A single selector block in dh-tabs.css, next to .tab-pane, sets padding: 24px 28px and no cap for every pane class, plus one .dh-pane for panes that had no class. Adding a pane means adding its name to that list, not inventing another number. The inline maxWidth/padding that four components were setting in JSX — which beat the stylesheet — is gone.
• The chosen width is Connectors’, and it is NOT what the design file says. The comp draws Ingest at 960, Billing at 980 and Home at 1120, all centred. The owner compared Ingest against Connectors in the running app and preferred the full-bleed treatment. This is recorded here, and in the rule’s own comment, so the next design pass does not “correct” it back. (Same precedent as chat, which runs at 920 where the comp says 720.)
• What was deliberately left narrow, because it is typography and not layout. A wiki page body (760px), the chat stream and composer (920px), onboarding and signed-out cards (720px), the confirmation panel (640px), modal dialogs (440–540px) and the empty-state message (560px). A full-width line of prose is worse to read, not more consistent, so none of those were flattened.
• Phones get one padding too. The 900px breakpoint used to tighten only Settings; it now tightens the same list to 16px. Verified at 375px: zero horizontal overflow, document width exactly 375.

A repo ingested from a team workspace now lands in that team’s brain

• This was the last always-personal ingest. Every connector route already honoured X-Workspace-Id; a repo or a website went to your own brain no matter which workspace you had open. So the one source a team most obviously shares — the codebase — was the only one they could not share. The frontend had been sending the header the whole time; the route simply ignored it.
• Placement moved; ownership did not. The job document has carried both identities since workspaces landed, and the code pipeline only ever read the person. The wiki root, the clone directory, the durable backup, the vector index, the code-graph artifacts and repos.json now all follow the workspace, resolved from one variable — a page written to one namespace and looked for in another is this codebase’s oldest bug, and six placement sites drifting apart independently is how it keeps happening. Who ran it stays the person: Monitor visibility, webhooks, and the meter’s caused-by identity.
• The reason it was deferred no longer holds. The old comment in job_create said a team id would misattribute the bill, because the pipeline metered tokens by this one key. The meter now records the member and the workspace separately, and the key that pays is resolved for the workspace — so the namespace is free to be the one the user is actually working in.
• The BYOK gate asks about the key that will actually pay. In a team workspace that is the workspace’s key, which is what the runner resolves. A gate reading the caller’s personal preferences while the runner read the workspace’s would have rejected a member whose job would have succeeded — the same read-and-write-disagree shape, wearing a 400.
• No header, no change: a personal ingest is byte-identical to before, pinned by a test. Every other test here uses ns ≠ uid, because at ns == uid this whole family of bugs passes.

A team workspace can run on its owner’s key — and never quietly on yours

• One key per workspace, supplied by its owner. Every member’s chat and ingest in that workspace runs on it. Personal workspaces are untouched: your own space, your own key, exactly as before.
• A member’s personal key is never consulted there, and there is no fallback. This is the load-bearing decision, not an omission. A fallback would read as helpful and would move the bill onto a member the instant the owner’s key lapsed — they would be paying for their whole team with nothing in the product saying so. Stopping, and naming the person who can fix it, is the better failure. There is a test whose entire job is to fail if someone adds the fallback back.
• “The owner needs to fix this” is a different state from “the brain is empty”, and now looks like one. A workspace with no usable key returns a named 409 carrying the provider, the workspace, and whether you are the person who can act. Chat renders it as its own amber, keyed state — not a red error, because nothing failed, and not an empty-brain message, because the wiki is all still there and only the model is unreachable. A member is not sent to a Settings page that cannot help them.
• Members see “configured”, never a mask. A last-4 tail is a fingerprint: with a shared key it is enough to confirm that a key obtained elsewhere is this workspace’s. The question a member actually has is “can this workspace answer”, and that is exactly what they get.
• Rotation is one owner-only save, and what it does to work already running is stated rather than discovered. The key is resolved once when an ingest starts and held for that run, so a rotation mid-job leaves it finishing on the key it began with; if you revoked that key at the provider, the job fails with the provider’s own auth error and can be re-run. Chat re-resolves on the next message. Every rotation is audited by which fields changed, never by their values.
• The Test button is the one from Settings, not a second one. It was built to be reusable and this is the reuse — and it reads the workspace’s key deliberately even while the feature is off, because otherwise it would quietly test the owner’s personal key and report success about a key the workspace does not have.
• Behind a flag, and off means byte-identical. With workspace_keys off, key resolution is exactly today’s per-person path and a key already stored on a workspace is inert — so the rollout is a flag flip, and so is the rollback.

You can now see what a shared workspace costs — before anyone’s key starts paying for it

• The meter recorded one identity, and a team has two. Every call was filed under the person who made it, which answers “what did I spend” and nothing at all about “what does this team cost”. An owner about to fund a workspace with their own key had no way to find that number. Calls now carry both: the member who caused the spend, and the workspace it was caused in.
• Additive, not a migration. The personal Cost page is byte-for-byte unchanged and still receives every call you make. A call in a team workspace is also recorded against that workspace, per member. Nothing moved, nothing was rewritten.
• The owner sees the breakdown; members see the total and their own row. The owner’s key is what will fund the workspace, so attribution is theirs. A table of colleagues’ token counts visible to everyone is workplace surveillance, and the number a member actually needs is “what is this brain costing, and how much of it is me”.
• The page states the date its figures start, and it is not the workspace’s birthday. Spend recorded before this change carries no workspace at all, so it cannot be attributed backwards — the data does not exist and no amount of care would invent it. A chart quietly starting at zero would be read as “this team has spent nothing”, which is false. So it says where the record begins instead.
• Which key paid is recorded, not guessed. Every row says whose key funded it. Today that is always the member’s own, which is the true statement until a workspace key exists — and it is what will make “the owner paid for this” legible the moment one does. Money-visibility deliberately ships before money-movement: nobody should get an owner-funded workspace before anyone can see what it costs.
• Still no caps, no quotas, and no free tier. Nothing here counts anything “against” anything, and a test asserts the workspace meter contains no such concept — not in prose, in names.

A credential you connected inside a team workspace was invisible to that team’s ingest

• The symptom. With a team workspace active, connect Notion — the form saves, the badge says connected, the Connectors grid says connected — and the ingest fails with “Notion is not connected for this workspace”. Same for Jira, Linear, Zendesk, Confluence, database DSNs, Slack installs and connected Google accounts. Ten connectors, one fault.
• The cause, again: one argument carrying two different things. Saving a credential in a team writes it to the workspace’s document. Every connector resolved credentials from whichever single id it was handed — and the ingest pipeline hands down the person, not the workspace. So the writer and the reader addressed different documents. On a personal workspace those are the same string, which is why it shipped, and why it is the thirteenth of these.
• The hard part was not the fix — it was not breaking the teams that work by accident. A credential saved before workspaces split, or saved from a personal context, sits on the person’s document, and that is exactly where those helpers were looking. Resolving the workspace document instead would have switched off teams that are ingesting today. So the workspace document is read first and filled in field by field from the person’s: the broken case starts working, the accidentally-working case keeps working, and a workspace that has re-saved only one connector keeps using the others still sitting in the old place.
• A credential you removed still cannot come back. The fill-in cannot tell “empty” from “never set”, so it would happily resurrect a token you revoked — except that disconnecting empties both documents, which is what makes the fallback safe rather than a way to un-revoke a key. Pinned by a test, because that property is load-bearing and invisible.
• When both documents held a value, the answer depended on who was asking. The settings page (given the workspace) showed one token; the ingest (given the person) used another. One rule now: the credential placed for the team is the team’s. Slack installs and Google accounts get the same rule at row granularity — the workspace’s own connections win, and a member’s personal one is used only when the workspace has none, so a team that has connected Slack never silently pulls a member’s personal Slack in alongside it.
• Three connectors needed nothing, and that is now written down and tested. GitHub Issues and Code resolve by the installer because an installation record carries no workspace at all; WhatsApp resolves by the person because a session is a phone pairing that belongs to a human. Failing tests came first, at ns != uid throughout — including one for the case that already worked, written before the fix so it could not be quietly broken by it — and the static guard now fails the build if a connector resolves a credential by hand or hands its resolver a single id.

Tidying up a connector’s documents is no longer the same button as disconnecting it

• They were one operation, and they should never have been. “Remove connection” deleted every page a connector had ingested and wiped its saved credentials. Deleting pages is ordinary curation of a shared brain and is undone by re-ingesting. Clearing a credential breaks the connector for everyone in the workspace and cannot be undone. Once credentials became owner-only, members lost the ability to tidy the brain at all — because the harmless thing was only reachable through the dangerous one.
• Now two operations: remove documents (any member) and disconnect (owner only). Two separate endpoints, deliberately, rather than one endpoint with a “also clear credentials” switch. A switch means the destructive path is one mistyped field away from the path members use every day. Separate endpoints mean the member-facing one contains no credential-clearing code at all, so no request can reach it — and a test asserts that shape rather than trusting a default.
• The control a member sees does not look like a disconnect. It says “Remove these N documents”, is not styled as destructive, and states that the connection stays and re-ingesting brings them back. Owners see both buttons and which one is irreversible.
• Found while splitting it: the disconnect was not sending the active workspace at all. It resolved your personal workspace regardless of which one you had open — so disconnecting from a team cleared your own credentials and left the team’s live, and the owner-only check added earlier today never fired, because you own your personal workspace. Both halves now send the workspace.

A team workspace is never left without its owner

• Deleting your account used to strand every team you owned. The workspace stayed, its brain stayed, its members kept reading it — and its owner_uid pointed at an account that no longer existed. Nobody could change its settings, invite anyone, or remove anyone. Once a workspace runs on an owner-supplied key, that stops being untidy and becomes a team that has quietly stopped working with no way to fix it.
• Account deletion now refuses, and the refusal is useful. It names the workspaces by name, explains what deleting would do to the people in them, and states the one way out: delete those workspaces first. Not a bare error code — being told you are stuck without being told how to get unstuck is its own failure.
• There is no ownership transfer, on purpose. The simple model is one owner per workspace, and the only exit is deleting the workspace. A test asserts no transfer route exists, so if one is ever added it has to break something visible rather than silently making every guarantee here conditional. Accepted limitation: if an owner becomes unreachable, the workspace can only be deleted, not rescued. That is a deliberate trade for now, written down rather than discovered later.
• The owner cannot be removed as a member either — and the refusal lives in the function that shrinks the member list, not only in the route above it, so a second caller cannot route around it. The invariant is asserted directly: whatever is asked of that function, the owner is still a member afterwards.
• A check that cannot run refuses too. If we cannot determine which workspaces you own, deleting anyway would produce exactly the outcome the check exists to prevent, so it asks you to retry instead.

A file uploaded into a team workspace never reached the brain — and we are the ones who broke it

• The symptom. With a team workspace active, uploading a file (or pasting a note, or adding a URL) reported success and queued a job, and the job reported “No documents found in Files & Notes”. Nothing errored anywhere a person could see it. The file was simply not in the brain, and nothing said so.
• We introduced it, three commits ago, fixing the other half of the same pair. Before “Feed a file into the brain you are actually asking”, uploads were stored under the uploader and the ingest looked for them under the uploader — both wrong for a team (files landed in a namespace nobody was querying), but wrong identically, so the file ingested. That change fixed the storing half to use the workspace and left the reading half on the person. Fixing one side of a write/read pair is not a partial fix; it is a new bug.
• The cause: one argument carrying two different things. An ingest has a person (who authenticated, whose credentials and key pay) and a brain (which namespace the pages land in, which workspace’s storage the bytes are under). The connector interface had a single parameter named for the brain, which the pipeline filled with the person. Every connector that authenticates as a person — Notion, Jira, Slack, Drive and the rest — was fine. Files is the one that has no credential at all: its uploads are indexed and stored by workspace, so it was the one that broke.
• Both identities now travel to every connector, and each one says which it uses. The choice is the first line of the method, and it is mirrored in a table the test suite checks against the code — so a new connector, or a changed one, has to be entered deliberately. A full audit of all fourteen connectors is written into the interface itself rather than left in a commit message, because the next person to add one will read the interface.
• Written as a failing test first. The listing returning nothing and the fetch refusing the file are both pinned, with ns != uid throughout, plus the personal case pinned in the other direction so nobody can “fix” the team path by breaking the solo one.

Three kinds of spend were being recorded where nothing reads — your Cost page will go up

• Read this bit first: your figures increase, and nothing got more expensive. Query expansion, the skills compiler and media analysis all spent real tokens on a real key and then filed the receipt under the workspace instead of under the person. The Cost page reads by person, so those rows were invisible. They are now counted. If your numbers step up, that is previously-unrecorded spend becoming visible — not a price change, and not new usage.
• Only team workspaces were affected. On a personal workspace the workspace id is your uid, so the two filing systems agreed and nothing was ever lost. This is the same fault line as the credential bugs: writer and reader resolve different keys, and it is invisible in the configuration most people test in.
• Old rows stay where they are. The usage files already written under a team workspace id are left untouched, not deleted and not migrated: they record real spend, and the data needed to attribute each historical row back to the person who caused it does not exist. Attribution starts from this change. Deleting them to make the mess tidy would destroy the only record that the spend happened at all.
• “Whose wiki” and “whose bill” are now two declarations, and forgetting one fails the build. Every request handler that names a namespace now names a payer beside it, and a static test walks the server for handlers that do one without the other. Four helpers that genuinely have no caller identity are on a reviewed list with a one-line reason each — the same shape as the scoping guard added earlier today.
• There are no caps and no quotas here, and there is no free tier. Nothing in this change counts anything “against” anything. It is attribution and visibility only.

Both verifiers looked for your API key in a folder instead of in your account

• The eleventh bug of one shape, and it broke the two features shipped this morning. API keys live on your person — users/{uid}.preferences, written by Settings → Models & API keys. Three call sites asked for them by workspace instead, which reads a document that exists for a personal workspace (where the id is your uid) and does not exist for a team. No key, no error, no clue.
• What that looked like. Claim verification and answer verification both reported “no model is reachable for this workspace (no API key saved)” to teams whose owner had a key saved and working. The contradiction scan quietly dropped to its regex extractor and reported extractor: regex without saying a model had been available all along. Every one of them worked perfectly on a personal account, which is why they shipped.
• Which workspace and which wallet are now separate arguments. The namespace still decides which pages are read, which sidecar is written and which feature flag is consulted; a new creds_uid decides whose key is spent and whose meter records it. Same split the connector pipelines and the Lint schedule already carry, and the same vocabulary, so there is one idea here rather than three.
• The bill follows the key, in the same commit. The critic’s usage record was already namespace-keyed, but it had never produced a wrong number: with the key resolved by namespace the critic returned before it ever got there. Fixing the lookup makes that line reachable for the first time, so it moves to the same identity as the key rather than becoming a real misattribution a week later.
• Every test in the new file sets ns != uid. At ns == uid — every personal account, and the configuration most testing runs in — all three of these bugs pass cleanly. That is the configuration that hid them.

A React component used without importing it is now a lint error, not a crash

• no-undef cannot see JSX element names. <Foo /> with no Foo in scope compiles, bundles, lints clean, and throws a ReferenceError the instant that branch renders. The rule that catches it, react/jsx-no-undef, was never enabled — even though the react plugin was already registered and two of its sibling rules were on. Now an error.
• It was not hypothetical. The connector credential form rendered <NavIcon> in several places with no import. Reaching it required opening one credential form — a path the build walks straight past, because bundling never resolves a JSX name, and one the test suite walked past too.
• Nothing else in the tree is affected: npx eslint src reports 0 errors across every component. Verified the rule genuinely fires by probing it with a deliberately undefined element rather than trusting a clean run — a guard that guards nothing looks exactly like a codebase with no violations.
• The value is forward-looking. This class of bug is invisible to every gate the repo had: it type-checks nowhere, bundles fine, and only a human opening that specific screen finds it.

Lint — the third operation, and the one schedule that runs it

• Karpathy’s “LLM Wiki” pattern names three operations: ingest, query, lint. This codebase had every detector and no lint — five signals, each with its own trigger, its own surface and its own idea of when it last looked. One pass now runs all five (unanswered questions, documents that disagree, stale pages, orphan pages, and pages carrying an unsupported claim) and produces one report.
• It feeds Actions; it does not get a pane. The Actions queue already collects gaps, conflicts and stale pages, and its badges are literally GAP / CONFLICT / STALE — the vocabulary Lint produces. A second surface showing the same findings would be worse than none: two lists that disagree about what is outstanding, and a user who fixes something in one and watches it persist in the other. Lint adds the run, not a second list, and it emits no fifth badge kind.
• Morning means the owner’s morning. A single fixed UTC hour is morning for one part of the world and 11pm for another, so the tick is hourly: it reads each opted-in workspace’s owner’s IANA timezone and acts only where the local hour matches. One scheduler job serves every timezone; a workspace is still touched exactly once a day.
• The setting belongs to the workspace, not to whoever is looking at it. The brain is shared, so a per-person preference would let two members disagree about whether it lints. It lives on the same document the connector credentials do — through one shared resolver, so the read and the write cannot drift — and only the owner can change it. Whose key pays is recorded at the moment of opting in rather than guessed at 7am: the owner who turned it on.
• Off means genuinely off. A workspace that never opted in is never listed, never read and never written; the sweep’s own report says candidates: 0. And a workspace nobody has linted reads as “Never linted — that is not a clean bill of health, it means nothing has looked”, structurally: a run that did not happen carries no findings and no counts, so no surface can render it as clean.
• The nightly freshness sweep is folded in rather than left beside it. The sweep is the detector that WRITES the staleness Lint reports, so running them apart would have Lint reporting yesterday’s staleness on a workspace swept an hour ago. The estate-wide nightly job stays for workspaces that never opted in and still need their orphan records pruned.
• The Cloud Scheduler job does not exist yet, and the docs say so in those words. Nothing in this repository creates scheduler jobs — every one of them is created by hand — so the exact gcloud command is written down together with what the smoke test should return and an explicit warning that until a human runs it, Lint is a switch in Settings that never fires.
• The scoping guard added an hour earlier caught this feature’s own new route and made it justify itself on the reviewed list. That is what it was for.

Claim verification, part 5: the other half — is the ANSWER supported by the pages it cites?

• Ingest checks the wiki; nothing checked the answer. A citation proves a page was retrieved, never that the sentence beside it came from there — the model can cite [[cart-service]] while paraphrasing something that page does not say. That has been item M in our own reliability notes since they were written. Every sentence a finished answer states is now adjudicated against the pages that answer actually cited.
• It reuses the verifier, it does not clone it. Same four verdicts, same evidence discipline (the page, the line, the quoted span), the same free AST oracle first, the same critic — which now takes its framing as a parameter so one module can ask “does this FILE support this page’s claim” and “does this PAGE support this answer’s sentence”. A second vocabulary would mean two meanings of “supported” in one product.
• It never delays a token. A separate request, fired by the client after the stream closes. Not before the first token (that makes the product feel broken) and not held open before the terminal done either — that would leave the spinner running over an answer already fully readable. The answer arrives first; the annotation lands on it afterwards, and “Checking this answer…” is a visible state so a verdict never appears out of nowhere.
• It flags; it does not retry. The doc said “retry on mismatch”. A blind retry doubles latency and doubles what you spend on your own key to produce a second answer nobody has checked either. Marking the unsupported sentence tells you exactly which claim to distrust, which is what the retry was trying to buy. There is no retry path, and a test pins that an all-unsupported result still makes exactly one round.
• Unverifiable is not unsupported, and that distinction is the feature. A sentence with no citation, or citing a page that no longer exists, is unverifiable — absence of a citation is not evidence a sentence is false. Only “the cited page was read and does not say this” is unsupported. The ingest-side oracle learned this the hard way when it reported every React hook in a repo as unsupported.
• Cheapest-first, and any cited page can settle a claim. One model call per cited page, each asked only about what is still unresolved — an answer whose first citation supports everything costs one call, not six. A claim is supported if ANY cited page supports it: one page’s silence must not veto another that does say it.
• Its own flag, default OFF, and also killed by the wiki’s kill switch. This bills the workspace’s own key once per ANSWER, on an interactive path — a different cost shape from an ingest the user started and is waiting on, so it does not get to inherit a flag that defaults ON. Off means no extra request, no call, no tokens. But claim_verify still stops it, because it is the same critic and a kill that left it running would not be a kill.
• Counts, not a score, and the cost is on screen. “1 unsupported, 8 supported of 9 claims”, the model calls and tokens it spent, and what the AST settled for free. Markers attach through renderer overrides, beside the sentence and never spliced into it — the shared renderer runs without raw-HTML support on purpose. Only findings are marked inline: on an answer that cited nothing every sentence is unverifiable, and a badge on each paragraph would bury the one line worth reading.
• Failure is silent and safe. No key, model error, rate limit, timeout, an exception anywhere: the answer still stands and the line reads “verification did not run” with the reason. A result that did not run carries no claims and no counts, so no surface can render it as a tick.

A team workspace’s credentials belong to the workspace, not to whoever is looking at them

• Any member could overwrite or clear a team’s connector credentials. PUT /api/account/integrations accepted the workspace header and had no ownership check of any kind — so one member could silently break every connector for the whole team, or repoint a database DSN. Disconnect was the same hole one button over, and it takes the ingested pages with it; both now require the workspace owner, as does the one-click database auto-connect that writes the same field.
• Every member was handed the last-4 mask of every secret. A last-4 tail is a fingerprint: it is enough to confirm that a credential obtained somewhere else is this workspace’s. Members now receive empty strings where the masks were, and the same configured booleans the owner gets — so “is this connected?” stays answerable without any credential material. Site URLs, subdomains and account emails are not withheld: they are not credentials and not fingerprints of one. The Google OAuth client secret’s mask leaked the same way and is fixed the same way.
• Two tiers, and deliberately no more. Workspace owner, and member. No editor/viewer split and no roles map — members ingest, chat and read, all equally; the owner controls the shared credentials.
• A refusal names who can do it. A bare 403 leaves the reader nowhere to go, so the response carries a machine-readable reason, the owner’s id, and one sentence on why these are shared. The check also runs before the body is parsed, so a refusal cannot depend on the shape of what was sent.
• Ownership is decided the same way the document is chosen — the namespace is not yours — and NOT by a ws_ id prefix. A second rule for the same question is exactly how a read and a write drift apart, which is the bug this area keeps producing. A lookup failure fails closed: a Firestore blip must not hand a member the owner’s powers.
• The form no longer offers what the server will refuse. A member sees an owner-managed panel stating whether a credential is configured, rather than a form that 403s on save — which reads as a bug rather than as a boundary.
• Personal workspaces are byte-identical to before, pinned by tests, including for someone who is a mere member of some OTHER team. Every test here uses ns ≠ uid, because at ns == uid you are the owner by definition and the hole is invisible — which is also the configuration of every personal account.
• Found while fixing it: the connector credential form used <NavIcon> without importing it, which throws a ReferenceError on render. no-undef does not resolve JSX element names — that needs react/jsx-no-undef, which is not enabled — so lint saw nothing. The import is added.

A Test button beside every API key — free, and specific about which of four things went wrong

• Saving a key told you nothing. You found out whether it worked at the first ingest or the first chat message, a long way from the field you typed it into, and the error there does not say which problem you have.
• Verification is a model LISTING, never a completion. Listing is free; generating is not. Charging someone tokens on their own key to answer “does this key work” is the wrong trade every time, so it reuses the same fetchers the model picker already uses rather than adding a second path. A test asserts structurally that no generate call can appear in it.
• “It works” is not the whole answer. A key can authenticate and still not reach the model you have selected — that is its own amber state, because nothing is broken, you just cannot use what you picked. It is only asked of the provider that model belongs to: telling someone their Google key cannot reach gpt-4o is true and useless.
• Four failures stay four. Invalid credential (401), recognised-but-refused (403 — a project or permission not enabled, where rotating the key will not help and the message says so), rate-limited (429), and provider-unreachable. Reporting a quota error as “invalid key” sends someone to rotate a credential that was fine.
• You can test before you save. That is the useful moment. The typed value is used for one request and never persisted, never cached against the account, never logged — and the verdict says out loud that it tested an unsaved key.
• No key material leaves, anywhere. Every message comes from a fixed set written in our code; the provider’s own text is never passed through, because a provider error routinely quotes the credential back — Google’s list endpoint carries the key in its query string, so even repr() of the exception would print it. Only the exception type and status code are logged. Two tests assert the key appears in neither the response nor the log.
• Untested renders as nothing. No tick, no green, no reassuring grey — a key nobody has tested must not look like one that passed. Same rule as the wiki’s “Claims not checked”. A hung provider aborts at 15 seconds with “nothing is known about the key either way” rather than spinning forever.
• Built as a reusable piece (a hook plus two small components) rather than welded into the personal Settings pane, because the same control is due on a workspace-owned key form where only the owner may press it.

The uid/namespace bug is now a test failure instead of a code review

• Ten instances of one bug have shipped. Nine in connector credentials (fixed in one pass: the disconnect that did not disconnect, the badge that went green over a connection the connector could not find, the form that re-read blank), and the usage meter’s cache-savings write. Every one has the same shape — a request handler reaching db.collection("users").document(username) by hand instead of through the accessor that decides, in one place, where that data lives. And every one passes cleanly on a personal account, because there the namespace and the uid are the same string. That is why nine of them shipped.
• A static check now walks the source and fails the suite, in the same shape as the symtable guard added a few entries ago. It does not try to decide which document is CORRECT for a given field — nothing static can. It asserts something weaker and enforceable: request-handling code that addresses a scope-keyed document by hand is on a short reviewed list with a one-line reason, or it is a bug.
• The failure message teaches. File and line, the accessors to use instead, one sentence on why it matters (a mismatched read and write saves data where nothing looks, and stays invisible on a personal account), and how to add an exemption if the access is genuinely right. A guard that only says “no” gets an exemption added instead of a fix.
• Proved against the real defect, not a hypothetical. One test reconstructs the pre-fix connector_db_auto_connect and asserts the check trips on it; another does the mirror image (reading the workspace document where the writer used the uid), because a guard that only covers one direction covers half the bug.
• Widening it past decorated routes found three more. A route that delegates to a private helper one line above it is the same bug with an extra stack frame — so every function in the request-handling module is walked, which surfaced the model-preference read, the clarify-state document and the conversation collection. None is a live bug; all three are now on the reviewed list with what would make each one wrong.
• A second test deletes stale exemptions — an entry that no longer matches any code is a documented blessing for code that has moved on, and it silently un-guards whatever replaces it. A third refuses a reason under eight words.

The token meter now knows who pays, separately from whose wiki it is

• Every entry point on the usage meter is uid-scoped, and one write passed a namespace. record, record_saved, record_from_event and get_today all take a uid, and /api/usage reads by uid — so a namespace written to it lands in a file nothing ever opens. The cache-savings write in the image tool passed the namespace, which would make “Cache savings today” read $0.00 however many hits there were.
• It has not been able to bite yet, and that is worth saying plainly. Code ingests deliberately never set a workspace_id today — jobs.job_create says so in a comment, for this exact reason — so the namespace and the uid are the same string on that path and the two agree by accident. The fix is for the day they stop agreeing, which that comment already schedules.
• Fixed by declaring the owner, not by guessing at it. The pipeline now takes an owner_uid alongside the namespace and publishes it as a contextvar; the tools underneath read it and fall back to the namespace when nobody declared one, so an undeclared context behaves exactly as it did. A contextvar and not a module global on purpose: two concurrent ingests must not be able to bill each other.
• The read side was deliberately NOT changed. Re-scoping /api/usage to the namespace would silently turn every figure on the Cost page — spend, tokens, monthly usage — from “what I spent” into “what this workspace spent”. That may well be the better product, but it is a product decision with a migration behind it, not a bug fix.
• Every test uses ns ≠ uid. At ns == uid this bug passes cleanly, which is the configuration that hid it and also the configuration of every personal account; a test there would prove nothing. One of the tests asserts the OLD behaviour is invisible, so the bug itself is pinned rather than only its fix.

The ERD labelled every relationship N : 1, because both of its 1 : 1 tests read fields that do not exist

• The unique-index test read t.indexes, a key the ERD payload has never carried. Guarded with || [], so nothing crashed — it just silently never fired, and a foreign key onto a single-column UNIQUE column was drawn as many-to-one when it is one-to-one. Worse than the missing feature: a wrong fact, stated confidently, on a diagram people design schemas against.
• The primary-key test was dead too. It derived primary_keys from a per-column key: “PRI” field — MySQL’s old SHOW COLUMNS shape, which nothing has written since the pane was rebuilt on the real database connector (that one reports primary_key on the table). So both one-to-one branches were unreachable and every single edge read N : 1. The extractor now reads the field introspection actually writes, and still resolves the legacy shape for a schema captured under it.
• There is now a third answer, and it is the point of the change. “This column is not unique” and “we could not find out whether it is” are different facts, and only the first justifies printing N : 1. Tables whose unique indexes cannot be read report it, and those edges are labelled ? : 1 with a count in the header saying how many and why — never a guess.
• Postgres reports indexes as CREATE INDEX text, so the columns have to be parsed back out, and the parse is deliberately narrow: an expression index, an INCLUDE list, a sort direction or a collation all read as unknown. A partial unique index is refused for a stronger reason than unreadability — UNIQUE … WHERE deleted_at IS NULL does not make the column unique across the table, so taking a column out of it would manufacture a false 1 : 1.
• Found in passing: uniqueness was decided by “UNIQUE” in definition. That says yes to CREATE INDEX ix ON t (unique_id) — a plain index on an ordinarily-named column, reported as a uniqueness guarantee. It is now the keyword, not a substring.
• The DB-graph pane’s mockup bar is removed, not wired. It carried a pill reading literally “tables · FKs” with no numbers in it, and an “Auto-layout” chip styled as an active filter that was a <span> with no handler. The real counts already render one bar lower, computed from the loaded graph, and the layout is a force simulation that is always running — so one was a duplicate and the other was never a mode. Same removal, same reasoning, as the ERD header a few entries ago.
• Eleven node tests on the rule and nineteen Python tests on the data, including the exact old shape: passing indexes must NOT resurrect the guess.

The free half of the verifier was not durable, so a cold pod quietly moved the bill onto your key

• Tier 1 reads _ast/*.json and _code_graph/*.json; only the second one survived a restart. The AST shards were in neither artifact list, so on a fresh Cloud Run pod they simply were not there. Nothing failed and nothing logged: the oracle just got smaller, and every claim it would have settled for zero tokens fell through to the paid critic or landed unverifiable. A silent bill, on the user’s own key, for work that was already done once.
• Fixed in both halves, exactly as the claims sidecar was one commit ago. _ast is now in _ARTIFACT_DIRS (mirrored on every backup, restored by the read path) and in the cold-pod ingest restore, because a run only rewrites the shards of the domains it actually processed while the oracle joins the whole workspace — so a page rewritten in one domain, making a claim about a file in another, would have had nothing to check against.
• It is what makes verifying outside an ingest possible at all. Today verification runs inside the run that wrote the shards, which is the only reason the bug never bit; re-verify-on-demand reads them cold, and would have found nothing.
• Three tests, and one of them is about behaviour rather than a list — an oracle with no shards must return unverifiable for every claim, never unsupported: absence from a positive index is not proof of falsehood, and a durability bug must not be able to turn into an accusation.

Claim verification, part 4: the verdict shows up next to the sentence it judges — and the launch docs stop promising more than it does

• Three lines in the launch and YC docs claimed a “Reviewer” that did not exist and a guarantee nothing could keep — “verifies every claim against the call graph (no hallucinations)”, “validate every claim against the AST so answers can’t hallucinate”, “with citations, no hallucinations”. All three now describe the stage that actually ships: tiered verification, a per-claim verdict, and the evidence behind it. “No hallucinations” is gone everywhere and is not coming back — tagging an unsupported claim reduces hallucination, it does not eliminate it, and that is the strongest honest wording available.
• Markers sit inline, at the claim. A prose verdict marks the paragraph it was extracted from; a symbol or file verdict marks the code span itself, because that claim is about one identifier and not about the sentence carrying it. They are attached through renderer overrides rather than by rewriting the markdown — the shared renderer deliberately runs without raw-HTML support (page bodies are model output, so that escape hatch stays shut), which also means the marker is rendered beside the text and never spliced into it. Clicking one jumps to its evidence.
• Only non-supported claims are marked by default. Four hundred green ticks would bury the three findings worth reading. “Show every verdict” turns the rest on, so nothing is unreachable — it is a default, not a hiding place.
• The evidence panel is the point of the whole feature: every claim, its verdict, the one-line reason, and the file, line and quoted span behind it — paths and line numbers in mono, because they are addresses a reader is meant to go and open. Grouped worst-first. What the run could not check is printed above the findings, not below them: a verifier that goes quiet when it breaks is worse than no verifier.
• No score, no percentage, no ring, anywhere. The page pill reads “2 unsupported of 15 claims”; the panel shows four counts. A “93% verified” badge averages those two claims out of existence, which are the two the reader needed. Same rule as Impact’s per-path facts, and it binds harder here. A page with no record says “Claims not checked” in the quietest style on the pill row — quieter than an unstyled pill — because dressing up an absence of checking would make an unverified page look inspected.
• A red count badge in the page tree, for unsupported only. The other three verdicts live on the page; a badge on every row is a badge nobody reads. It states the number, so colour is never the whole message — the rule the stale badge next to it already follows.
• The matcher is unit-tested on its own (node claimMatch.test.mjs): a marker attached to the wrong sentence is a verdict about something the reader is not looking at, which is worse than no marker. It pins the near-miss that must NOT match, the hard-wrapped paragraph that must, and the dependency claim that has to match by wikilink as well as by wording — deduping on the target otherwise leaves the second bullet naming it unmarked.

Claim verification, part 3: an eighth pipeline stage, and a sidecar that must never read as “clean”

• Verify is a real stage now — step 6 of 8. It sits after the manifests (the pages and the AST shards it reads both exist by then) and before freshness, so a run’s “verified” stamp and its verdicts are written in one pass. The Activity pipeline strip is driven entirely by the stage_total the backend sends, so it grew its eighth card on its own — and the design comp’s long-promised VERIFY card, “re-check every wiki citation”, is now a step that exists rather than one that was drawn.
• It runs by default, not on opt-in. A check nobody turned on is not a check, and the product says it checks every claim. The claim_verify flag defaults ON and is a kill switch, not a gate — the emergency behaviour if the verifier is ever found to be wrong. Because it spends the user’s own key, the cost goes on the event stream: calls and tokens beside the counts, metered under its own kind so the cost dashboard separates verifying the wiki from writing it.
• Verdicts live in wiki/<ns>/_claims.json, not in page frontmatter — the freshness precedent, for its three reasons verbatim: the page-merge path drops unknown frontmatter keys, code-page frontmatter is model-written and validated only as “starts with ---” (a poor place to keep the audit of that same model’s output), and mtime is reset by rehydration. It also means verification never rewrites a page body. A test asserts the bytes are unchanged.
• Every way of losing the sidecar has to read as “not checked”, never “clean”. Corrupt file, missing file, flag off, a stored record with an unrecognised verdict, a stored supported claim whose evidence went missing — all of them drop to nothing rather than defaulting. The API keys are ABSENT rather than empty when the flag is off, because {} would stamp “0 unsupported claims” onto every page of a workspace nobody has ever verified, which reads as a clean bill of health for work that was never done.
• Caught while wiring it: the same durability bug the freshness sidecar hit. A new sidecar in neither artifact list dies on the next pod restart — which here would silently un-verify an entire brain with nothing in any log to say so. It is now mirrored AND restored on the cold-pod ingest path, because the stage read-modify-writes it: an incremental run only re-checks the pages it rewrote, so a save that started from {} would drop every verdict for every page the run happened not to touch. Both halves are pinned by tests.
• Measured on a real 197-page brain: 626 of 2,260 claims settled by the AST for zero tokens, and 26 pages needed no model call at all. What was left batched into 171 calls at ~9.5 claims each. Extraction leans towards including a doubtful span, deliberately: a false inclusion costs a line of prompt, a false exclusion is a claim nobody ever checks.

Claim verification, part 2: the paid tier, and the four ways a checker can lie

• What tier 1 cannot settle now reaches a model — one call per page, not per claim. Prose (“this service handles refunds for cancelled orders”) has no structural handle, so the cheapest model on the user’s own key re-reads the cited source and marks each leftover claim. Batching a page’s claims into a single call over one source read is the difference between ~200 calls and ~1600 on a real repo, and it is the entire reason the free tier runs first.
• Quoted evidence is checked against the file. A supported or partial verdict must arrive with a span that literally appears in the source it was shown. If it does not, the model invented its evidence and the claim drops to unverifiable — a hallucinated quote cannot be laundered into a verified claim by the tool built to catch hallucinations. Locating the span is also where the evidence gets its line number, and the matcher tolerates reflowed whitespace but not invention.
• Truncation cannot become a false accusation. Large files are clipped to fit the prompt, and for a clipped file “I found no support” is a statement about the excerpt. Those unsupported verdicts are demoted to unverifiable — the same doctrine tier 1 applies to gaps in its own index.
• Every way this tier can break lands on unverifiable, and the run still succeeds. No key saved, a timeout, a rate limit, unparseable JSON, an index the model skipped, model resolution itself throwing: none of them produce a verdict, and the stats say what was not checked so the UI can too. Tested one by one, because the tempting failure — marking things supported because the checker fell over — is the worst outcome this feature could have.
• The cost is reported, not hidden. The call path deliberately does not reuse the shared lite-completion helper: that one returns text only, and a feature whose justification is “tier 1 is free so tier 2 is small” has to be able to say what tier 2 spent. Input and output tokens come back with the verdicts and are metered under their own claim_verify kind, so the cost dashboard separates verifying the wiki from writing it. There is also a hard per-run call ceiling — BYOK with no caps is not a licence to spend an unbounded amount of someone else’s money on a monorepo — and when it bites, the skipped claims are reported rather than quietly dropped.

Claim verification, part 1: the AST becomes an oracle, and learns when to say “I cannot check this”

• A citation only ever proved a page had been read. The reliability notes have said so since they were written: “the LLM can cite [[cart-service]] while paraphrasing something that page doesn’t actually say.” Nothing checked the sentence next to the link. A page is now broken into individual claims — the files its frontmatter cites, the symbols it names in backticks, each [[wikilink]] under Dependencies / Used By, each METHOD /path under Public Interface, and each narrative sentence — and every one of them gets a verdict.
• Structural claims are settled for free. The tree-sitter layer and the call graph already hold the answer to “does this file define getMetaDetails” and “does aboutUs/page.js import the file behind [[get-meta-details-service]]”. Tier 1 is a join over shards ingest already wrote — no model call, no key, no tokens — and it carries the evidence with it: the defining file and line, or the literal import statement. On a real 197-page brain it adjudicates every file, symbol, dependency and route claim and leaves only prose for the paid tier.
• The hard part was teaching it to abstain. A first cut reported every React hook in the repo as unsupported. The code graph is a positive index — declared functions, declared classes, resolved call sites — and it never recorded arrow-function components, consts, types or local variables, so a symbol’s absence from it is a gap in the index, not proof the file never mentions it. Those claims now fall through to the model instead. Same correction in four other places: a file absent from the index only means “deleted” if the crawler would have indexed it (README.md, node_modules/ and PNGs are skipped by rule); a route means nothing on a framework the extractor cannot read (it knows NestJS decorators and Go mux, not Next.js file routing); package.json → .eslintrc.json can never have an import edge; and a [[wikilink]] to a page that does not exist has nothing to check against. Each of those is unverifiable, which is a different thing from false.
• An env var, a table, a DTO and a route handler all count as evidence, not just a call site. Checking only calls made the config page of the file that reads FIREBASE_STORAGE_BUCKET report it unsupported.
• A supported verdict cannot be built without evidence. The verdict constructor downgrades it rather than emitting one — a claim marked good with nothing to show is exactly the unfalsifiable output this feature exists to remove. And the roll-up returns counts, never a percentage: a “92% verified” badge averages an unsupported claim away into a number that reads as reassurance (same rule as Impact’s per-path facts).

“…and check every claim” is back on the Ingest headline, because it is now true

• It was removed a few entries ago, and that was right at the time. Nothing verified anything: the “Reviewer pass” toggle beside it advertised a citation re-check that had never been built, and the headline was making the same promise in a larger font. Both came out together.
• The verify stage exists now, so the sentence is restored — an AST oracle for structural claims and a model critic for prose ones, each claim carrying a verdict (supported / partial / unsupported / unverifiable) and the evidence behind it, surfaced on the wiki page itself. It is a stage of the ingest pipeline, which is why the Activity pipeline strip grew a step.
• The comment at the sentence tells the next reader how to check it — where the stage lives, and what to look for on a wiki page if the claim ever looks too good to be true. A promise in the UI should be one hop from the code that keeps it, not a grep away.

Ingest, rebuilt to the design — Activity, and a failed run that reported itself green

• Bug: the run status pill was hard-coded green for every state. A run that FAILED announced itself in exactly the same green as one running happily — the single most status-bearing object in the pane was the one thing that could not report a bad state. It now takes the colour of the state it reports (red failed, green done, grey idle, green live). Fixed regardless of the design, and verified against a failed run.
• The event stream has a header. “Event stream” with a right-aligned “auto-scroll”. The dark log began flush at the card’s top edge with nothing naming it or saying it follows the tail; it is also clipped by the card’s radius now, instead of squaring off its bottom corners.
• The stage sentence moved back beside the percentage. “Stage 2 of 5 · Parallel parse · embed · draft” is what the percentage is a percentage of; it had been displaced below the bar with a file count in its place, so the two halves of one fact sat on opposite sides of the thing they describe. The file count is not lost — it is the Documents row in Job summary, where it reads against the other counts.
• Job summary comes first, Recent jobs second (they were reversed), the split is 1fr/260px rather than 1fr/320px — the side column held the two narrowest cards and was taking a third of the width from the stream, which is the thing with lines to wrap — and the progress bar is 4px fully rounded rather than 6px at radius 4.
• Job summary rows gained hairline separators and a lowercase violet status; Recent-jobs rows became dot + mono name + mono relative time. They had been an icon, a 13px semibold name and a second line naming the kind — three lines of chrome per row in a 260px column, for a list whose question is “which run, and when”. Click-to-select is EXTRA and stays, marking the name in the accent rather than boxing the row.
• The terminal palette went from four colours to five. The two missing ones were the ones that carry meaning on a busy log: a dim line for skipped work (a skip is not a result, and at full brightness it read as one) and cyan for schema findings, which are a different kind of finding from “drafted a page”.
• NOT BUILT: the “Tokens so far” row. No event in the stream carries a token count — the pipeline emits stage / progress / doc_ingested and none has a usage field — and the job document holds no token total either. An invented number in a row labelled EST. is still invented. The EST. styling exists for the day one is emitted.
• The pipeline strip keeps its real 7/2 stages (a deliberate deviation from the design’s fixed five, already agreed) and is driven entirely by the stage_total the backend sends — so when the verify stage takes it from 7 to 8, the strip follows on its own. Only its colours were aligned: inactive cards take the page tone rather than white, so the strip reads as a track with one lit cell.

Ingest, rebuilt to the design — Feed files

• The dropzone says what it does. A 26px violet upload arrow instead of a 34px brain — the glyph on a drop target should name the action, not the product. Dragging over it now lights the border and fill violet; it was blue, which is the secondary accent and appears nowhere else in this pane, so the one moment of feedback in the whole sub-view was off-palette.
• Six format chips, not thirty-two. The full accepted-extension list wrapped to four dense rows of mono chips and buried the two lines above it. The row is a reassurance (“yes, your PDF is fine”), not a specification — and the six are filtered against the real accept list at module load, so the reassurance can never name a type the drop handler would reject. The sentence above them names the same five kinds.
• Batch rows get a leading file glyph tinted by status, so a row reads as one state instead of four independently coloured pieces. Notes and links keep their own glyph — but as an icon on the row, not a character inside the filename, where it was also ending up in the tooltip.
• Status pills lost three signals for one fact. They were mono, bordered, dotted, animated and lowercase; the design has a tinted fill with a capitalised word and nothing else. At 11px mono with a pulsing dot, the pill was the loudest thing on a row whose subject is the filename.
• The note and link cards dropped their icons (the design’s card headers are plain 13.5/600 text — an icon made these two read as nav rows) and their fields sit ON the card in white with a hairline, rather than being cut into it as grey wells.
• The closing line the design has and the app never did: “Everything fed here lands in your personal brain and shows up in Activity as it is read”, with a violet inline link that switches sub-view. It replaces a bordered “How it works” box whose link was rendered in the secondary blue.
• NOT BUILT: the “Category · Auto-detect” select beside the URL field. POST /api/files/url accepts one field, url, and register_url(workspace_id, url) stores no category; there is nothing to send it to and nothing that would read it. Wiring a select into a parameter no endpoint accepts is exactly the defect four controls were just removed for. Building it properly means a real feature — a user-supplied override of the classification the enrichment pass currently derives — not plumbing, so it is reported rather than faked.
• The in-view header is EXTRA and was demoted, not deleted — the design opens this sub-view straight onto the dropzone, because the pane’s H1 is two inches above. It is now a lead line and a <div>, not a second 26px <h1>.

Ingest, rebuilt to the design — Add source

• The three source kinds are rows in one card, not three cards. The design’s active row is a violet 7% tint and nothing else. The app drew three separately bordered cards and ringed the selected one in a 2px violet border with a 3px glow — which made the picker the loudest object on a screen whose actual subject is the form beside it.
• Every kind now says what it is for, always. “Primary sync” / “Docs sites and handbooks” / “Upload an archive”. That sub-line existed on GitHub alone, and only while GitHub was selected — which is exactly when you no longer needed telling. The icon is a bare 17px stroke glyph tinted per kind (GitHub violet, Website cyan, ZIP amber); all three used to sit in the same violet-tinted square, so the glyph carried no information at all.
• BETA is amber, not blue. Blue is the app’s secondary accent and reads as a link; BETA is a caution, and every other caution in the product is amber.
• The repository field is one flush control. Prefix, input and “sample” share a single border with no gaps. It was a padded grey pill with a separately bordered button floating inside it — two objects where the design has one, and the button looked detachable.
• The form card stopped floating. It carried a medium drop shadow, which lifted it off the page hard enough to read as a modal; the design gives it a 1px hairline. And the Start button is flat violet with a flat pressed state, not a gradient with a glow — the pane’s primary action was styled like a promotion.
• Ingestion model reads “Account default (Gemini 3 Flash)”, not the raw model id it was printing at you.
• The footer sentence has both halves — it stopped after “you can leave this page” and never mentioned that private repos need the GitHub app, or that a typical repo takes 2–4 minutes, which is the part that stops someone thinking it has hung.
• The two blocks that replaced the four dead controls were restyled into the design’s toggle rhythm — flat on the card, hairline-divided, 13px above and below — rather than left as the grey inset box they landed in. They were not resurrected as switches; the controls stay gone.
• The rail’s own headline is EXTRA and was demoted, not deleted. The design has no heading there — the pane’s H1 says “Ingest” three inches above it. It is now a lead line rather than a second 21px/800 headline, and it is a <div> rather than a second <h1>, because two H1s on one screen is wrong for a screen reader as well as for the eye. “What you get” likewise stopped being a violet-tinted bordered panel — a third card in a 250px rail that already holds two.

Ingest, rebuilt to the design — the shell

• One measured column instead of three sub-views each inventing their own. The pane is 960px capped and centred with 32/30/48 padding and a 20px rhythm, so the heading, the segmented control, whichever sub-view is open and the Jobs card are spaced by one rule. It was full-bleed at 16px 32px 0: on a wide monitor the form stretched to the window edge, and each sub-view supplied its own vertical spacing, so the three never agreed with each other or with any other pane.
• A persistent Jobs card at the foot of ALL THREE sub-views. It did not exist at pane level at all — you had to be on Activity to learn anything was running. Now “what is my brain doing right now” is answerable while you fill in the form that will add to it.
• The Jobs row is built from what we actually have. The design’s row carries a stage sentence and a percentage, and draws a 4px progress bar from that percentage. Neither exists: GET /api/jobs returns the job document with the events array explicitly removed, and the document has no stage, stage_index, progress or pct field at any point in its life. So the row is dot + name + kind + status word, and the stage slot carries the source kind. No bar — a bar drawn from a status word is a picture of a number nobody measured.
• The segmented control lost its border and its hover. The design’s track is a bare tinted rectangle; the 1px outline made it a fourth card competing with the three real ones below it. And a colour shift on hovering an inactive segment reads as “this one is selected now”, on a control whose only job is to show which one is. The live dot moved to after the label, where it annotates the word instead of bulleting it.
• Every small-caps label in the pane changed typeface. REPOSITORY, BRANCH, INGESTION MODEL, PROCESSING, CONNECTED SOURCES, WHAT YOU GET, JOB SUMMARY, RECENT JOBS were all rendering as JetBrains Mono 10px/700 at 0.2em tracking; the design sets every one as IBM Plex Sans 10.5px/600 at 0.06em. A different family, a heavier weight and triple the tracking — so each section label was shouting a size louder than the design. Checked every consumer of the class first: only this pane uses it.
• Two colours that were being retyped as literals became tokens — the pressed violet used by every button hover and every selected label, and the hairline used inside a card, which is lighter than the card’s own edge. A divider drawn in the edge colour makes one card read as a stack of cards.

The last emoji left the interface — including the ones inside chat messages

• A chat message can carry an icon now, because the emoji in them were not decoration — they were part of the text. 🧠 for a skills reply, ⚠ for an error, 🔒 for a paywall, 📅 for a scheduling nudge: each was a character glued to the front of the message content, so it travelled into the saved transcript, into anything that searched or summarised a thread, and into the model’s view of the conversation. Marking a message is a property of the message, not a prefix on the sentence. Messages carry a kind; the glyph is drawn beside the text in the colour that kind implies, and the content is only what was said.
• Everything else in the app followed: WhatsApp, the mobile chat, the connector grid and detail panes, code review, workspaces, the model picker, the toast stack, the feature tour, the ER diagram, the table node’s key/foreign-key markers, the tab-crash boundary, two-factor enrolment and the sign-in bars.
• The activity feed’s event messages lost their prefixes too. The feed already draws an icon from the event type, so a 🚀 or ❌ typed into the message text was a second, competing marker on the same row — and the two could disagree.
• What stays, and why. The 👍/👎 rating on an answer: those are the affordance, and outline hands read worse. Two dropdown pickers (workspace, database) lost their glyphs entirely rather than gaining drawn ones — a native <option> renders text only, so any icon there is a stray character in the OS font. The backend’s own stage messages are untouched on purpose: the ingest progress heuristic pattern-matches that copy, and changing one without the other would silently break the progress bar.
• The icon table holds only glyphs that are actually rendered. Nine drawn during the sweep turned out to have no caller and were deleted before shipping — a table of unused paths is the same decoration problem in a different file.

Emoji sweep: Onboarding, DB Graph, Billing, GitHub, Settings, Feed, credentials

• The icon table the sidebar already owned grew to cover the rest of the app. Tick, warning, lock, key, mail, phone, user, document, package, database, link, search, globe, calendar, clock, image, video, star, chart, brain, broadcast, rocket, flask, wrench, download, compass — all drawn to the same rule as the rail (24px box, no fill, currentColor, 1.7 stroke). One table, so a lock in Billing and a lock in Onboarding cannot drift apart, and nothing scatters a one-off inline SVG next to it. Where a glyph already existed it is reused rather than redrawn: a lightbulb is the Skills icon, a plug is Connectors, a card is Billing, an open book is Wiki.
• Why it matters beyond taste: an emoji renders in the OS font with its own colour, weight and baseline. A red ❌ on an error line stayed red whatever the theme did; the drawn glyph inherits the line’s colour, so an error mark is red because its line is red and cannot agree by luck and disagree after a change.
• Onboarding — step ticks, the encrypted-key note, both warning states, the rotating tips (which now carry an icon id per tip instead of an emoji baked into the sentence), the live event feed’s row markers, the “wiki is ready” tick, both next-step cards and the three footer buttons. The waving hand after your first name is simply gone.
• DB Graph — the stats line, both view-mode buttons, the fetch button, per-database fetch status (waiting / done / failed), the cached tick, the close button, the primary-key marker in the column table and the unique/ordinary index markers. Two emoji were removed rather than replaced: the database <option> label, because a native dropdown renders text only and a glyph there is a stray character, and the search field’s magnifier, which was inside the placeholder string.
• GitHub, Settings, Feed, the credential form and the Google BYO panel — the installed-on chip, the admin-setup and auto-sync headers, the delivery tick, the repo cards and their star count; the saved-key badges, the Save button’s resting state, the new-API-key banner and both Copy buttons; the drop zone’s brain, “Watch ingestion”, and the note / link cards; the key headers, the delete-row button, the “Connected” state and the saved-field badge; and the account list’s mail glyph, its reconnect warning and the three step-done markers.
• Four were removed rather than redrawn, all for the same reason: they sat inside a string the UI consumes as text — two search-field placeholders, a Slack connection error, and a plan blurb. Text is text; those now say what they mean in words. The Feed’s note and link rows keep their mark by carrying an icon id on the row instead of a character glued to the front of the filename, which was also ending up in the tooltip.
• Billing / checkout — step ticks, the Razorpay row, the pay button in both states, the two “secured” lines, the receipt line, the big confirmation tick, the three next-step cards and the test-plan header. The confirmation tick’s CSS stopped sizing a character with font-size: 50px; the size travels with the icon now and the rule only sets colour.

Four controls on the Ingest form were connected to nothing

• A DEPTH select with no state and no handler, and three switches that flipped a variable nobody read. The submit sent only the model and the individual/bulk mode. Every one of them looked like a decision you were making about your ingest, and none of them was.
• Each was checked against the backend before deciding, and none of the four could be honoured. That is the finding, not an excuse — a control is worth keeping only if something downstream can act on it.
• DEPTH — “full · entire history” / “shallow · last 50 commits”. The clone is hard-coded --depth 1 --filter=blob:none --no-checkout, then chunk-checked-out, so a large repository downloads its source and not its history. Fifty commits are fetched after the clone, blobless, purely to work out who wrote what. So the option offered as the default is something the pipeline is built never to do, and the other is roughly what it always does. Replaced with that sentence.
• Re-ingest on push. Not a property of this run at all — it belongs to the GitHub App installation. The push webhook enqueues an ingest for every linked installation’s default-branch push and consults no preference; the installation document has no field for one. The block now says so and links to the GitHub tab.
• Infer database schema. Runs on every non-web code ingest already, deterministically, with no flag and no token cost for the scan itself. It is also the “map your data model” deliverable this pane’s own headline promises — a switch to turn it off argued with the copy two feet above it. Stated as a fact instead.
• Reviewer pass — “re-checks every citation in the wiki”. Nothing does this. It is unbuilt future work in our own reliability notes, and the code-review engine reviews a GitHub pull request: it needs a PR number and an installation, and never reads the clone. Removed, and so was the same promise in the pane’s headline, which ended “…and check every claim”. Every page does carry citations; nothing re-verifies them, and the copy no longer implies otherwise.
• The switch styles went with them — this pane was their only user, so leaving them would have left a component whose only purpose was three controls that did nothing.

Impact’s LOW / MEDIUM / HIGH badge was a threshold dressed as a verdict

• The rule was: high above 20 transitive nodes or criticality 70, medium above 5, otherwise low. Those numbers are not derived from anything. 21 dependents is not categorically different from 20, and “criticality” is itself a score the graph builder guessed. It rendered as a confident coloured badge at the top of the pane — the most prominent thing on the screen, and the one thing on it no reader could check or argue with.
• This argument is the codebase’s own. The per-path badges were removed for exactly this reason and replaced with facts — hops, dependents, whether the path lands in a test — under a comment saying there is no honest formula and inventing one renders a confident number nobody can check. The headline was the same badge and simply outlived that pass.
• Nothing takes its place in that slot. The five counts directly beneath it — callers, callees, affected files, affected tests, transitive reach — are the facts the verdict was computed from, so restating them in the header would only be the badge’s slot demanding to be filled. In chat, where there are no count cards, the reach number joins the existing counts line and the “● HIGH RISK” label is gone.
• The graph stopped colour-coding the verdict too. The target node was filled green/amber/red by the same classification — a second rendering of it, in colour only, that the legend didn’t even explain (it just said “target”). Every node is now coloured by its role in the diagram, which is what the legend always claimed.
• Removed from the response, not just the UI — the risk field is gone from /api/impact and from the impact MCP tool, whose docstring now says why. A field kept “for compatibility” is a verdict waiting to be rendered again by the next surface. The criticality score stays on the nodes; nothing interprets it any more. The test that pinned the thresholds now pins their absence.

Files fed into a team brain were quietly landing in your personal one

• The intake routes were the last three that did not take a workspace header. /api/files/upload, /api/files/note and /api/files/url registered the document under the caller’s uid and enqueued a job with no namespace. Chat sends the header. So with a team workspace active, the upload chip ran all the way to read and the toast invited you to ask about the file — and the file was in a namespace nothing was querying. The product said it worked; it was not there.
• Fixed on both sides, because either half alone is still broken. The client sends the same headerFor() every other pane uses (from the shared intake module, so the chat composer’s Attach button and the Feed pane cannot diverge — that is why it is shared); the routes resolve the namespace the way every other ingest route does, and pass it to both the registration and the job. Those two have to agree: the connector re-checks that the document belongs to the workspace it is being fetched for, so a mismatch would have turned a silent misfile into a failed ingest.
• The job stays owned by the person. uid is who may watch it — the chip polls the job endpoint as you — and workspace_id is where it writes. Conflating the two is a mistake this codebase has already made once, in the auto-skills path.
• Five tests with namespace ≠ uid, covering the file, the pasted note and the URL, plus the job’s owner, plus the solo case — because ns == uid is the configuration in which all of this passes.

One-click database connect copied personal connection strings into the team brain

• It seeded its list from the merged read and then wrote that list back. The merged read exists to fill a field the workspace document doesn’t define in from users/{uid}, for readers. Auto-connect started from that view, appended the newly detected database, and persisted the result to the workspace document — so a single click copied the caller’s personal, encrypted DSNs into a shared document every member’s reader can see.
• It also minted the exact thing the fill-in is documented as never doing. Its docstring says “strictly read-only — nothing is ever written back, so this can never mint a second copy that then disagrees with the first”. One caller made that false. A read-only migration is only read-only if nothing persists its output.
• Now it seeds from the document it is about to write. That is also the correct dedupe: database_connections is merged whole-list, so a workspace list shadows a stranded personal one rather than concatenating with it — there was never anything here that could duplicate.
• Audited the other three callers of the merged read — the credential form’s GET, the connector grid, and the chat clarify-fallback’s connected-source list. All three are read-only. This was the only one.
• The existing test pinned the bug, so it was rewritten. It asserted only that one connection ended up saved — a length the defect satisfied just as well — under a rationale (“or the legacy connection is duplicated”) that whole-list merging makes impossible. It now asserts what actually matters: no personal DSN in the team document, and the personal document untouched. Dedupe keeps its own test, against the document being written.

Clearing a connector token in Settings brought the old one back

• Every clear was undone by the next read. The save writes to the active workspace’s document; the read fills a missing-or-empty field in from users/{uid}. That fill-in is deliberate — it is what keeps a credential saved before the write moved from vanishing under a connector still using it — but it cannot tell “” from absent. So blanking a token wrote “” to one document, the read treated that as “never saved here”, and refilled it from the personal copy. The form returned 200, re-read, and the old token was back. There was no sequence of actions in the form that could remove the stored copy at all. Emptying the whole database-connection list had the same shape: the deleted connections reappeared.
• A clear now clears both documents — the rule Disconnect already had. The previous pass fixed Disconnect for exactly this reason and its commit message argued the fill-in was safe because disconnect clears both. True, and it was only ever true of Disconnect: this route has its own documented clear path that never went near it. Setting and clearing now deliberately write to different places — a set lands on the workspace document alone (writing a team credential into someone’s personal namespace would be the mirror-image bug), a clear empties both.
• Not a tombstone, and why. A sentinel meaning “deliberately empty” would have to be understood by every reader of these documents — each connector decrypts its own field, not just this route — and any reader that missed it would hand a sentinel to an API as a token. Clearing both needs no new vocabulary and matches behaviour that already exists.
• Five tests, all with namespace ≠ uid, because the personal case is precisely where this bug passes: a clear survives a re-read; both documents end empty; an emptied connection list stays empty; clearing one field leaves an untouched pre-migration credential in another field alone; and a set still writes only the workspace document. All five fail against the previous code.

“Webhook delivery healthy” was asserting something nothing had ever checked

• The green banner’s condition was “the App is installed and has at least one installation”. That is a fact about installation, and installation is the exact half that stays fine while the Webhook URL is wrong, the secret mismatched, the push subscription missing or the dev tunnel down. The one state the banner was there to rule out was the one state it could not see.
• The evidence already existed and nothing read it. The webhook handler stamps last_push_at on the installation the moment a push arrives — written for this banner, with a docstring saying so — and the frontend had zero references to it. The endpoint the panel calls already returned the field verbatim, so no new plumbing was needed; the panel simply was not looking.
• It now says when. “Last push received 4 minutes ago”, exact timestamp on hover, and the account it arrived for. Green means a delivery landed, and nothing else does.
• No delivery on record reads as no delivery on record. Not green, not red: the panel cannot tell “installed five minutes ago and nobody has pushed” from “the webhook is misconfigured”, so it does not pretend to. It names the three things to check and points at the manual ingest button, which does not use the webhook at all.
• Guarded the stamp’s whole round trip — that a fresh installation carries nothing the panel could mistake for evidence, that a push writes a timezone-aware stamp, that the endpoint helper returns it, that a repo re-sync (which rewrites the installation doc on every install and repo-change webhook) does not erase it, and that stamping an installation we have no record of stays a silent no-op, because the stamp describes an ingest that is about to run and must never be the reason it doesn’t.

Chat printed the model’s markdown as literal characters

• The answer was rendered into a white-space: pre-wrap div. Not a styling gap — no markdown was parsed at all. A ```python fence arrived as three backticks and the word python; **bold** kept its asterisks; a table came through as a wall of pipes; headings kept their hashes. For a product whose entire pitch is “answers grounded in your code”, the code was the single thing that rendered worst.
• One renderer now, shared by the Wiki, the desktop chat and the mobile chat. The Wiki already parsed markdown, so a second implementation next to it would have drifted — and the copy that drifts is always the one nobody is looking at. The shared component owns the plugin set and the element map; the Wiki adds the one override it actually needs (the heading id its table of contents scrolls to). Mobile chat had the identical pre-wrap bug and is fixed by the same change.
• Tables, task lists and strikethrough work (GFM), and raw HTML stays off. These strings are model output; the escape hatch that would let one emit a <script> is simply not installed, so embedded HTML renders as the text it is.
• Wide things scroll inside the bubble, not the page. A chat bubble is much narrower than a wiki column, and an 80-column code line or a six-column table will happily set the width of whatever contains it — which would have made the whole conversation pan sideways. Fenced blocks and tables get their own horizontal scroll and a max-width, so the stream itself never scrolls sideways.
• Streaming is left forgiving on purpose. Text arrives a token at a time, so at any moment the source can end mid-fence. The parser closes unterminated constructs at end-of-input, so a half-received block grows into a code block; a “wait for the closing fence” guard would have made the text appear, vanish and reappear on every token.
• Single newlines survive. Plain markdown folds a line break into a space, which would have silently reflowed everything anyone typed with shift+enter. Chat renders with hard breaks, the way every chat product does; the Wiki does not, because a hard-wrapped paragraph in a source file must still read as a paragraph.
• Verified against a real answer — fenced Python, an ordered list, a three-column table, bold, inline code, a blockquote, and an embedded <script>. Nothing executed, no element was injected, the page width did not move, the code block scrolled by itself, and the citations still rendered inside the answer card in order.

Team workspaces: eight more places where the write went to one document and the read came from another

• The previous pass moved connector credentials to the workspace document and fixed one of four readers. The other three kept resolving by uid, and none of it is visible to a solo user — for a personal workspace the namespace is the uid, so every one of these bugs passes. They only appear once a team workspace is active, which is exactly the customer they were built for.
• Disconnect said it worked and it didn’t. It cleared users/{uid} while the live token sat in workspaces/{ns} — so the connector kept authenticating with a credential the UI reported as gone. Fixed first and treated as security-adjacent: a token you believe you revoked and haven’t is worse than no disconnect button at all. Disconnect now clears both documents.
• The rest of the set. The credential form saved a token and re-read blank for ever; the connector grid offered “Connect” for something already connected; the same defect hit the chat’s connected-connector list; one-click DB connect saved a connection that DB Graph and the introspector never look at; DB Graph, the ER diagram, the code graph and the tables browser read one namespace while the ingest wrote another; editing a team wiki page returned 200 and changed nothing (and quietly created a shadow copy in the editor’s personal namespace) while deleting one 404’d; and auto-compiled skills jobs were created owned by the workspace, so Monitor never listed them and opening one returned 403 — the run itself was fine, nobody could see it.
• One rule, applied everywhere: reads and writes resolve the same document. Every credential read now goes through a single helper, so they cannot drift from the writer one at a time again, and the job layer stops conflating who owns this run with which namespace it compiles — two ids that were never interchangeable and now travel separately.
• Removed two more cross-tenant fallbacks. The ER schema directory and the tables browser fell back to a shared wiki/default/ when the caller had nothing of their own — and every workspace’s ingest used to land there, so one tenant was served another’s table names, columns and foreign keys. Two identical fallbacks were removed from DB Graph earlier for exactly this reason; these were the third and fourth. An empty result is the correct answer when you have ingested nothing.
• Nothing already saved disappears. Credentials stored from a team workspace before the writes moved are stranded in users/{uid}, so reads fall back there per field when the workspace document doesn’t define one. It is a read-time migration and stays read-only — writing on read would mint a second copy that then disagrees with the first, which is the bug being fixed. It is safe because disconnect clears both documents, so nothing cleared can be resurrected by the fallback. 31 tests, every one of them with namespace ≠ uid, because a test where they are equal proves nothing here.

Settings said every saved key was “Not set”, because the route behind it had been 500ing for every user since the day it shipped

• GET /api/account/preferences raised NameError on every single request. The handler’s body called _integration_doc(username, workspace_header), but workspace_header was never a parameter of that handler and is not a module global. A previous change added the call to this route while adding the Header(…) parameter to only two other routes. The route had a 0% success rate and nothing reported it.
• The blast radius was entirely silent, because the frontend reads a failed fetch as “no preferences saved”. Settings showed every stored BYOK key as Not set; chat’s model preference never hydrated; the ingest form lost its default model and its Saver/Standard mode; and the “this user already has a key, skip onboarding” signal was dead, so anyone who saved a key in Settings was bounced back into onboarding. Four separate user-visible faults, one root cause, no error message anywhere.
• The route now reads users/{uid} — deliberately not the workspace document. Preferences are per-person: timezone, billing country, GSTIN and email opt-ins are nobody else’s business, and the BYOK keys are consumed by llm_model._load_prefs(uid) on every model call. The PUT and all six readers agree on users/{uid}, and nothing anywhere writes preferences into workspaces/{ns} — so simply adding the missing parameter would have swapped a 500 for a silent read of a document no writer populates, leaving every team-workspace user exactly as broken.
• Fixed the masking that hid it for its entire life. The bare except Exception returned a generic 500, so a programming error was indistinguishable from a Firestore outage. The response stays generic on purpose — Firestore errors sometimes echo stored values, which here are key fragments — but the exception and its traceback now reach the server log. Swept the rest of the file for the same shape: 15 handlers raised a 500 without logging anything, and all 15 now log. No response body and no status code changed.
• A static guard for the bug class, not just the bug. A new test walks every function in enhanciar/ with CPython’s own symtable and fails on any name that is read but is neither a parameter, nor local, nor a module global, nor a builtin. It catches this defect at import time instead of in production, and it immediately found a second one: db_query.firestore_read called safe_error(e) without importing it, so every failure on that path raised NameError instead of returning the error it had carefully constructed. Also fixed.

The activity feed stopped labelling itself with emoji

• Every event marker in the ingest feed is a drawn glyph. 📡 🌍 🧹 🤖 ✅ 🚀 each rendered in the OS font, so they carried their own colour, weight and baseline — a 🚀-marked line sat differently from the line above it and ignored the terminal’s palette entirely, which is the palette that makes an error line red. The replacements inherit currentColor, so a warning glyph is amber because its line is amber.
• The feed title, the completion line and the preview note too. “Ingestion complete” and “Ingestion halted” had a green tick and a red cross baked into the character; they are now drawn and take the colour of the state they report, so they cannot agree with it by luck and disagree after a change.
• Chat’s chrome: the workspace chip, the reasoning-panel header and the Skills-tab link. The 👥 in a mono chip was the one coloured thing in an otherwise monochrome row. The 👍/👎 rating stays as-is on purpose — those are the affordance, and outline hands would read worse.
• Still emoji, and why: the prefixes inside chat message bodies (🧠 for a skills reply, ⚠ for an error, 🔒 for a paywall). Those live inside message content strings, so swapping them means giving a message its own icon field rather than editing text — a change to the message model, not a glyph substitution.

Workforce stops drawing a frame inside the window’s frame

• The rail and the detail are full-bleed in the pane. They sat inside a rounded card — a second border a few pixels inside the app’s own, so the agent rail carried a border on both sides of a 1px gap and the reading column gave up 30px to decoration.
• The ledger shows the five most recent runs and a “Show all N runs” button beside its footnote. An agent with sixty runs pushed the note explaining the ledger — that a failed run still writes an entry, and that the gap is the record — sixty rows down. N is the number of entries actually loaded for that agent, and the button is absent when every run is already on screen.

Three panes finish the design’s smaller list: Skills, Map, ERD

• Skills cards say what kind of skill they are and how long the procedure is. Both come out of the skill file itself — kind from frontmatter, steps counted from the numbered procedure in the body — so a card whose compiler wrote no kind simply has no kind chip rather than a plausible-looking default. The card also names its first source page in mono at the bottom, with the rest on hover: “3 sources” tells you a skill is grounded but not in what, which is the question you ask before trusting a procedure.
• The Map’s cluster legend is a toolbar under the canvas. It used to sit in the right rail above the node detail — so clicking a node replaced it, and the “which clusters am I looking at” control vanished exactly when you were looking at one. Dot, name, mono count, and Clear highlight pinned at the far right so it is in the same place whether something is focused or not.
• ERD gets Show cardinality and AI annotations, both wired to real data. Cardinality is derived, not stored: a foreign key means many rows here point at one row there, and it is labelled 1 : 1 only when the referencing column is the table’s whole primary key or covered by a single-column unique index. A relationship whose column we don’t know gets no marking. AI annotations show the Summary an ingest already wrote for that table — the same prose the Tables pane reads, not a second generation — fetched only when the toggle is on (?annotations=1), because it costs a wiki listing plus a file read per table. A table with no ingested page shows nothing.

Workspaces: the invite field was behind the button you had to find first

• Inviting is why you open a team card, and it was a click away. The email field lived behind a “＋ Invite” toggle in the card header, next to Make active and Delete, where it read as a filter. It now sits at the bottom of every card you own, always visible. No autofocus — the field is permanently mounted, and grabbing focus on render would yank the caret out of whatever you were typing.
• Members are chips in a wrap row. A team of eight was eight full-width rows, which pushed the invite control off the fold on the card that most needs it. Each chip keeps everything the row carried — a 20px coloured-initial avatar, the address, the owner badge, and Remove as a titled × that disables while the request is in flight. The avatar colour is derived from the member’s id, so the same person is the same colour on every card and every reload rather than being decoration that pretends to be data.
• The Active pill is green. Violet is this app’s interactive colour, so an active state rendered in it read as a button you had not pressed yet.
• Card identity is a 28px gradient square, not an emoji. 🏷 and 👥 render in the OS font, so they carried a different weight, colour and baseline from every drawn glyph beside them. Personal-vs-team is not lost with the emoji — the meta row states it in words.

The shell: rail width, selected states, and a wordmark that stopped competing with its own logo

• The sidebar is 206px (was 212), and the selected item’s icon now carries the design’s duotone fill — rgba(28,82,93,0.20) inside the drawn stroke — so the active row reads as filled rather than merely tinted. The fill is opt-in per call site, so the feature tour, which borrows the same icons outside the rail, is unchanged.
• The Ingest segmented control’s selected tab is a violet fill with white text, not a raised white card. A white card on a grey track reads as lifted — a hover or drag affordance — when what it means is selected, which this app says in the accent colour everywhere else.
• The brand name is solid #0E1113. It was the same violet→blue gradient as the logo mark sitting 10px to its left, so the two competed; and gradient-clipped text at 14px renders muddy on a non-retina screen.
• Refresh is a radius-8 button with a drawn icon. It was a 100px pill — this app’s pill shape means chip (scope, status, suggestion), not button — carrying a literal ↻ character, which took the font’s weight and baseline and therefore sat differently from every icon beside it. The label stays.

Attach in the chat composer, and a wider reading column

• Attach feeds the file into the brain — the same multipart POST, the same ingest job and the same per-file status the Feed-files pane runs, now shared in one module so the two surfaces cannot accept different files or enforce different limits. The chip under the composer reports the real job: uploading → queued → reading → read, read from the job record rather than assumed, and a file rejected client-side says why and never leaves the browser.
• It deliberately does not use the query endpoint’s attachment field. That field is only read on the ADK path; production answers every question through the customer’s own key, where it is silently dropped. Wiring the button there would have produced a control that looks like it sends a file and doesn’t — worse than no button.
• The chat column goes from 760px to 920px. At 760 a fenced code block wrapped every other line and the citation footer stacked. The stream, the composer and the two chip rows above it move together, so the left edge of an answer, of the composer and of a suggestion chip stay on one line. Phones are unaffected — the narrow rule already governs there.
• Not built — “All sources”, and why. The design puts an All sources selector beside Attach, but the same design also puts a scope row across the top of the chat listing the workspace and every connected source, and in the comp the selector is a static label with no menu and no data behind it. More decisively, /api/query has no source-filter parameter: a control that narrows retrieval has nothing to narrow it with. It needs a sources field on the query API first; until then the scope row is the honest version of it.

The sidebar icons were drawn a third heavier than the rest of the app

• One number, everywhere it was wrong. The design’s icon rule is 1.7px strokes in currentColor; the sidebar’s NavIcon drew its paths — copied verbatim from the comp — at 2. The rail therefore read heavier than every icon beside it, which is the sort of mismatch you feel before you can name it. Normalised to 1.7 across the nav rail, the source-kind icons, the Settings tab strip, the password-visibility toggle, the payment-method glyphs and the onboarding link icon.
• Not everything with a stroke is an icon. Data visualisations keep their own weights — graph edges, ERD relationship lines and the DB force graph encode meaning in thickness (a foreign key is drawn heavier than a code reference), so flattening them to 1.7 would delete information. The empty-state illustrations and the loading spinner are drawings, not glyphs, and keep theirs too.

The pipeline preview listed five stages, two of which do not exist

• The idle Ingest card promised Scout, Workers, Integrator, Graph, Verify. “Graph” and “Verify” are not stages — nothing in the backend emits them — and four that are (hashes, manifests, freshness, persist) had no card. So the preview said five steps, you started a run, and the header correctly said “Stage 3 of 7”. Same bug as the run header, in the card next to it.
• The list is no longer a frontend array. New GET /api/pipeline/stages serves the real steps, generated from the same tuples stage_meta() numbers its events against — so the Nth card and the header’s stage N are the same thing by construction. A test fails if the component ever grows its own copy again, or if a stage is added without a label.
• It is per pipeline, because the pipelines differ. A repository ingest runs seven steps; a connector pull genuinely runs two (list, manifest). At rest we don’t know which you’re about to start, so the preview shows both with their real counts rather than one shape pretending to fit both.
• The live strip now reads the run instead of guessing at it. Stage states came from keyword-sniffing message text for “graph” and “verif”; they come from the stage_index the backend stamps on every stage event. A stage the run never announced shows as skipped, not done — hashes only runs on an incremental pass and keeps its slot either way. An old job replayed without stage numbers renders no strip rather than five grey cards implying a five-step run.

The waiting placeholder said “thinking…” even with Thinking switched off

• It is a word collision, not a broken toggle. “Enhanciar · thinking…” is the generic waiting-for-the-first-token placeholder and renders for every answer; Thinking is the name of a different feature — the composer toggle and the expandable reasoning panel it fills. A user who switched the toggle off, asked a question and watched the app announce it was thinking reasonably concluded the switch did nothing. The placeholder now reads working…, on both the desktop chat and the mobile one.
• Copy only. The internal thinking / thinkingOpen state keeps its name, which is accurate for what it holds, and the reasoning panel’s own “Thinking” label stays — that one is the feature.

The web chat never learned that “hi” is not a question

• Slack has short-circuited greetings since it shipped; the web chat did not. The shared is_greeting() was wired into the Slack bot and into gap clustering, and into nothing else — so typing “hi” in the app went through retrieval, matched nothing, and came back “The provided context does not contain information to answer your query.” That was the first sentence a new teammate ever saw the product say. /api/query now answers it before the workspace namespace is even resolved, so it touches no retriever, no model and no tokens.
• It records no retrieval-feedback signal. The done event carries an empty signal_id, because a greeting is not a retrieval — there is nothing to thumbs-down and nothing to cluster as a gap. That matches what gap clustering already did on the read side.
• One intro, both surfaces. The reply text moved into greetings.py as a shared constant; Slack and the web chat build from it and differ only in the worked example, because only the example is surface-specific — you cannot @-mention anything in the web composer, and there is no thread to answer in. Two copies of a self-introduction is exactly the drift that module exists to prevent.
• The test that matters is the negative one. “hi, why did the payment retry fail?” must still reach retrieval; a shortcut that swallowed it would silently drop a real question.

Three small things that were in the wrong place, or nowhere

• The Tables filter was across the pane from the list it filters. It sat in the main toolbar on the right while the table rows it narrows are in the left rail, so you typed in one place and watched another change. It now sits above those rows.
• Settings hid the outbound-webhooks card whenever you had none. The card carries the only explanation of what webhooks do here, how deliveries are signed and how retries back off — so the only people who ever read it were the ones who had already found the feature some other way. It renders as soon as the list has loaded, and at zero says how to register one and that the signing secret is returned exactly once.
• Payment history had no invoice number. The row linked to a PDF but showed nothing you could quote at a finance team without opening the attachment first. The number is added as its own column, derived the same way invoice_pdf.py derives it for the document itself, so the row and the PDF cannot disagree. The Method column stays — the design has no such column, but dropping a column that carries real data to match a mockup is not a correction.
• Not done, and why: the design puts a relative timestamp on each Home “Recent sources” row. Nothing in that data path carries one — /api/manifests returns a markdown blob, and the repos sidecar is a name-to-path map — so the column is absent rather than filled with a plausible date. It needs an ingested_at per source first.

The ingest percentage now admits it is an estimate

• The progress figure was presented as a measurement. It is not one: the backend reports stage names, never a completion percentage, so the number is computed in the browser by weighting three phases (scout 15, workers 55, integrator 30). Rendered plain beside a filled bar, it read exactly like a real reading, and a user watching it stall at 55% had no way to know the bar was guessing rather than the job hanging. It now carries a dashed EST. tag, the design’s marker for a figure with no backing field, and a tooltip saying what the pipeline actually reports.
• The marker is scoped to when it is true. A finished or halted run genuinely sits at 100, so the tag disappears at that point rather than casting doubt on a number that is now exact. The percentage also moves to mono, like every other figure in the app.

Chat’s sources were a separate object below the answer

• Citations rendered as a panel stapled under the answer card — its own border, its own background, bottom corners rounded to fake continuity. It read as a second thing rather than as the answer’s evidence, and needed two extra rules to strip the card’s bottom corners depending on whether sources existed. They now sit inside the card above a hairline, so the card keeps all four corners either way and one answer is one object.
• The reference number was a violet tinted rectangle. Violet is the app’s interactive colour, so an index read as a link; and a 4px rectangle inside a 999px pill put two competing corner radii on one 17px object. It is a grey circle now, mono at 10px.
• The answer card was never the card colour. It asked for var(--bg-primary, #fff) — the fallback was written as white but the token resolves to the shell tone #fbfbfc, so the fallback never applied and the card differed from its background by nothing but a 1px border. The stream now sits on the canvas tone and the card is genuinely white.
• Follow-up suggestions were ghost buttons prefixed with a “+”. The plus read as “add” when every label already says what will happen. They are outlined 999px pills, matching every other suggestion chip in the product.
• The composer floated in the message list — same tone as the stream, nothing between them. It gets a hairline top border. And New chat, the one action that starts a conversation, was the quietest thing in the rail: a white bordered row carrying a fullwidth “＋” character that renders at a different size in every font. Filled violet, full width, drawn icon.

Four more panes stopped saying “Loading…” and nothing else

• Actions, Code Reviews and Impact each rendered a bare grey “Loading…” while they fetched, and their own one-line empty hints when they came back with nothing. The hints described the feature — “submit a pull request above” — not what was missing, so a user whose reviews were empty because no API key was saved read a sentence about pull requests and stayed stuck. All three now use the shared pane state: a skeleton with a “you can leave this page” note while loading, and on empty a headline plus a What fills this pane list naming every prerequisite. Code Reviews names all three of repo, saved key and ingested wiki.
• Tables rendered its two-column shell around nothing. With no database connected you got an empty rail beside an empty grid, which reads as a broken pane rather than an unconfigured one. It shows the shared empty state with a Connect a database action instead. It also had no loading state at all — databases starts as an empty array, so every user saw a flash of “nothing here” before the fetch landed, whether or not they had data.
• Recent reviews carried no dates. Two reviews of the same pull request were indistinguishable, and “recent” was unverifiable. Each row now shows a relative time — 3h ago, Yesterday — read from the created_at the job runner already writes on every record. A review saved before that field existed shows no time rather than a fabricated one.
• The Wiki was folding two situations into one message. “No wiki pages yet” and “pick a page to read” came out of the same component with a swapped string, so a workspace that had never ingested anything got the same shape of nudge as one that simply had nothing selected. The first case is now the shared empty state, which says what an ingest needs; the second stays a nudge, because the pane is not empty.
• Errors deliberately keep their old treatment. The design models exactly three pane states — data, loading, empty — and writes no failure copy, so a real error is not dressed in the “nothing here yet” voice. That is a gap in the design, not something to invent around.

An action card now says what kind of finding it is

• Every card led with the tracker chip — Jira, Linear, GitHub — in the same accent violet, so in a queue of twenty a contradiction and a missing document looked identical and you had to open each one to find out which. Cards now carry a coloured GAP / CONFLICT / STALE / OWNER badge, using the finding_kind field added earlier today. Anything filed before that field existed, or whose kind could not be determined honestly, renders no badge rather than a guessed one.
• Impact’s “Who to ask” is a table. It buried its numbers in a sentence per person — “4 commits across 2 affected files” — which reads fine for one row and not at all for six, because nothing lines up and nothing can be compared down a column. Person / Commits / Affected files, numbers right-aligned in mono. The design also specifies a Last touch column; the impact response carries no last-commit date per owner, so that column is absent rather than filled with something plausible.

The activity feed ran backwards, and the pipeline strip was the narrowest thing on screen

• Events rendered newest-first and never scrolled. New lines appeared at the top and pushed the rest down, so the line you were reading moved while you read it — and the run’s order was inverted from the order it actually happened in. It reads oldest-at-top now and follows the tail, the way a log does. It only auto-scrolls when you are already at the bottom: scroll up to read something and it stops yanking you back.
• The run header was nested inside the left column of a 1fr / 320px grid, so the five stage cards were laid out at the terminal’s width — the pipeline strip, the one element that wants horizontal room, was the narrowest thing on the page. It is a full-width row above the split now, and the split collapses to one column under 900px.
• Every recent job said “done”, which tells you nothing about which run you are looking at. They carry relative times — 2d ago, 5d ago — and have all along: created_at and finished_at were already in the payload and simply never rendered. A job with no timestamps falls back to the status word rather than printing “NaN ago”.
• The RUNNING · LIVE pill was violet. Violet is the app’s accent, used on every interactive thing, so the one genuinely status-bearing chip looked like a button. Green, with a green pulse.

The Wiki’s table of contents was decorative

• Every entry was an <a> with no href and no click handler. The rail looked like a table of contents, styled like one, even had an .active rule waiting in the stylesheet — and clicking any line did nothing at all. It is real now: headings get stable ids derived from their text, entries scroll to them, and a scroll listener marks whichever heading last crossed the top of the article column. The id is slugged by one function used on both sides, because deriving it twice is how a contents rail ends up pointing at anchors that do not exist.
• Category headers in the page rail now fold. A workspace with a dozen categories put the page you wanted three screens down an unbroken list; each header carries a caret and its page count.
• Breadcrumbs read as a path. The line said “Title · Notion / concepts” — the page’s own name first and the trail after it, which is the opposite of how a breadcrumb orients you. Now Notion / concepts / Title.
• Status pills, minus the one we cannot back. The design shows three: freshness, a source count, and the source file. Freshness and the source file exist as data; a source count has no field on the page payload, so that pill is absent rather than filled with a plausible number. The row renders only when it has something true to say, and carries the design’s “See blast radius” button through to Impact.

Two “blocked” design elements had cheaper, honester answers

• The design wanted a RISK badge on each dependency path. We did not build one. There is no honest formula: any score would be invented from fan-in or depth and rendered as a confident verdict nobody can check — the same failure as the fabricated counts removed earlier this week. Each path now carries facts instead: how far the change travels, how many things depend on where it lands, and whether it lands in test code. A reader seeing “3 hops · 12 dependents” judges for themselves, and if “risk” is ever defined as a specific rule it becomes a one-line derivation over numbers already on screen.
• Landing in a test is reassurance, not exposure — the same path ending in a payment handler is a different thing entirely — so it is reported as a fact rather than folded into a score. The matcher is anchored on separators: “protest.py” and “contest_engine.py” contain “test”, and a substring match would have labelled real production code as covered.
• Table descriptions turned out to already exist. The plan assumed we would have to generate prose per table — expensive on a database with 800 of them, and a guess about someone else’s schema. But every ingested table already gets a wiki page with an LLM-written Summary; those tokens are spent. The Tables pane showed none of it, so the screen that most needs “what is this table for” displayed only column types. It now reads that page, and shows the database’s own COMMENT above it when the schema’s author wrote one — that beats anything generated. Generating a second description at list time would have been a worse answer bought twice.
• Both degrade quietly. Path facts render only when the backend sent them, so an older response shows the bare chain; a summary lookup that fails returns nothing rather than taking the table’s schema down with it. 5 tests.

“Stage 3 of 7” — counted, not claimed

• Stage information existed only as prose, and the prose had drifted. The monitor echoed whatever the backend wrote — “🔍 Stage 1: Scout analyzing repository…” — because there was no number to render. Worse, the numbering in that prose was wrong: work added later was wedged in as “Stage 1.5” and “Stage 4b” rather than renumbering, and two further steps announced nothing at all. Seven real steps wearing five numbers, two of them invisible.
• Counted as real steps, per pipeline. A repo ingest has seven; a connector pull (Slack, database, Notion) has two. The old display implied a shared five-stage shape for both — so “Stage 2 of 5” on a connector run would have been a made-up denominator on a pipeline that only ever has two phases. The two silent steps now announce themselves, so the count reaches its end instead of stopping at 5 of 7.
• The conditional stage keeps its slot. Hashing only runs on an incremental pass; it holds position 2 rather than shifting everything after it, so a given step has the same number on every run and the monitor’s existing skipped-stage state covers the gap. A stage key the backend does not recognise returns nothing rather than a guess, and the UI prefixes “Stage N of M” only when both numbers are present — so an older job replayed from Firestore still shows its own words instead of “Stage undefined of undefined”.
• A test pins that the two pipelines disagree. If their counts ever match, someone has flattened one into the other’s shape — which is exactly how the “Stage 2 of 5” fiction started. One existing test broke: it guarded step ordering by matching the message prose, so dropping “Stage 2: ” from the text moved its anchor. Re-pointed at the emission rather than its wording. 6 tests.

Pick which tables (or pages, or tickets) to ingest

• A connector ingest was all-or-nothing. A database with 800 tables enriched all 800 on the caller’s own API key, even when they cared about a dozen. filter_id existed but is a substring — “everything under this project” — which cannot express an arbitrary set, and would drag orders_archive along when you asked for orders. The pick is a closed set, matched exactly.
• Every row in “available to ingest” is now selectable, and the button says which it will do: Start ingest with nothing ticked, Ingest 12 selected otherwise, plus a “clear selection” escape. An ambiguous button here spends real money on the wrong scale. Unticking the last box returns to “everything” rather than an empty set, so it can never quietly mean “ingest nothing”.
• A selection never applies to an auto-sync. It describes one manual run; carrying it forward would silently stop refreshing everything else the workspace connected, and nothing in the UI would say so. Capped at 500 ids so a pathological client cannot put an unbounded list into a job document, and a run whose picks have all been renamed away says exactly that rather than “no documents found”. 4 tests.

Five fields the design needed and the backend never sent

• A live wiki-page count during a run. The connector pipeline has emitted one event per page since it shipped; the code pipeline’s Integrator wrote pages silently and reported a total only at the end — so the one number telling you the brain was actually growing was absent for the entire run. It now emits a running count, and the monitor prefers the final figure once it exists.
• The document counter never moved on a code ingest. The two pipelines name the same thing differently — the connector sends {i, total}, the code pipeline sends {processed, total} — and the reducer only read i. So a code ingest showed 0/N throughout unless a message happened to carry a [i/total] marker in its text. Reads both now.
• GitHub could not say “last push received 4 minutes ago” because nothing stored when one arrived. The panel could only assert that pushes would trigger an ingest — a promise rather than evidence that delivery works. Stamped on the webhook, best-effort: a failed stamp must never stop the ingest it describes.
• Every action card led with a violet tracker chip, so a contradiction and a missing document looked identical in the queue. Proposals now carry finding_kind (gap / conflict / stale / owner) — derived from what extractors already say, not asked for. An unrecognised value stays empty rather than being guessed: no badge is better than a confident wrong label on someone’s queue.
• Skill cards had no kind or step count. Steps are counted from the body’s procedure section rather than stored, so the number cannot drift from the document it describes — and only under a Steps/Procedure/How-to heading, because a skill’s Sources list is bullets too and counting those would report a number that means nothing. Workforce’s “started 6 minutes ago” needed no backend work at all: last_run_started has been written on every run since the feature shipped and nothing ever read it. 9 tests.

A job whose process died kept reporting progress forever

• An ingest was running when a new revision deployed. The instance was replaced, the in-memory pipeline died with it, and the job document sat at status: running with a progress bar frozen at 30% — indefinitely. Nothing notices a job whose process is gone, so the UI showed a run that had not existed for minutes.
• A startup sweep existed and skipped it, because it measured the wrong thing. It judged staleness by how long ago a job started: this one had started four minutes earlier, so it looked young and healthy. By the same rule a two-hour run emitting events every few seconds would have been killed for being old. Both backwards. Jobs now carry a last_event_at heartbeat and staleness is judged by silence.
• Fifteen minutes of silence, and resolved on READ as well as at startup. The sweep only fires when the process restarts, but a job can die without one — a hung worker, an instance drained mid-run — so the lie could outlive any number of page loads. The threshold is deliberately generous: Slack’s history endpoint allows roughly one request a minute and a single enrichment takes tens of seconds, so a few minutes of quiet is a slow step, not a corpse. A job with no timestamps at all counts as dead, because a ghost that reports progress forever is worse than one retryable false positive.
• The failure says what happened and what to do: the run stopped because the server restarted, already-ingested pages were kept, run it again to continue. Re-running is cheap — content hashing skips whatever already landed. 7 tests.

Hovering an event-stream line made it unreadable

• The activity feed is the one deliberately dark surface in the app — a #14161a terminal with per-event text colours set inline. Its hover rule used var(--bg-secondary), a near-white, so pointing at a line painted a pale band underneath pale text and the row vanished exactly when you tried to read it. A translucent white lift is the right hover for a dark surface. Two more light-theme values were sitting on that same dark panel: the default row text (near-black, only ever invisible because the inline colours happened to override it) and the agent pill’s light chip background.

A connected Database never appeared under “Connected sources”

• The Ingest rail listed eight connectors from a hardcoded catalog; Database and Confluence were not in it. Both are registered connectors with working ingest paths, so connecting one left that rail empty and the only route to its ingest view was the Connectors page’s Ingest button — which is exactly the step a user has no reason to know exists. files stays out deliberately: that is the Feed files tab, not a source you point an ingest at.
• The rail also never re-read. Same bug as the Connectors grid: fetched once on mount, and the tab stays mounted for the session, so a connector you added mid-session did not show up until a full Refresh. It now listens for the same change event.

A saved database connection stops looking like an empty form

• Saving the list used to require re-typing every connection string. A saved DSN is never sent back to the browser, and the save REPLACED the whole list — so renaming one connection, or deleting another, meant re-entering the DSN of every row you were keeping, and forgetting silently wiped a working connection. A blank DSN on a name we already hold now means “keep the stored one”, carried through still encrypted.
• So the row no longer renders as an empty password box captioned “Saved — re-enter DSN to keep on save”, which read as “this is not connected, type something”. It shows •••••• saved as a fact, with an explicit Replace for the rare case you want a different string. The save button says Save changes rather than “Save & connect” — you are already connected — and a line appears while dirty saying nothing is applied until you save, because the • on a row is a pending edit, not an immediate disconnect.
• The available-to-ingest list rendered every row. Fine for a Notion workspace with 12 pages; a wall for a database with a few thousand tables, pushing the rest of the page out of reach. It now shows 25, states how many are hidden rather than truncating silently, and offers a filter once the list is long enough to need one.

Connector credentials were saved where the connector never looks

• Saving wrote users/{uid} unconditionally; every reader resolved by NAMESPACE. With a team workspace active you could add a database connection, watch the badge turn green, open the connector page and be told “Available to ingest · 0 — nothing from Database is shared with Enhanciar yet”. Both statements were true of different documents: the badge was computed from the user doc, the connector looked in the workspace doc, and the connection sat in the first. Confirmed against Firestore — the DSN was stored, encrypted, and unreachable.
• Same shape as the Slack bug earlier today (uid-scoped write, ns-scoped read) and the connector-listing bug before it. Both integration routes now resolve the workspace doc, and /api/connectors judges configured-ness from that same document, so the badge and the connector cannot disagree.
• No fallback to the personal doc from a team workspace. It would have made the badge green again while the connector still found nothing — which is precisely the disagreement being fixed. Credentials saved in your personal workspace belong to it. A connection added under a team is now added to the team.

The Connectors grid answered from memory

• It fetched /api/connectors once, on mount, and never again. App.jsx keeps a visited tab mounted for the life of the session, so the grid kept showing whatever it saw the first time you opened it. Remove a database and it still read Connected; connect one and the Ingest button did not appear until a full Refresh. Verified against Firestore that the backend was right all along — database_connections was [] and the API correctly reported not-configured. The pane simply never asked again. Every path that changes a connector now announces it, and the grid re-reads.
• Connecting a database and reading its schema are two steps, and only one of them was visible. Going straight to DB Graph after connecting showed “No schema to graph — connect a database”, which sends you back to the thing you just did. It now distinguishes the two cases: nothing connected → go to Connectors; connected but never read → a “Read name →” button right there, with a line saying why reading is separate (it opens your database and walks every table).
• The ⊂ on a connection row removes that one row from the list before you save — it is an edit, not a disconnect. Removing the connector entirely is the red “Remove Database connection” button below.

One palette, five real tokens, and DB Graph stops being styled for a dark app

• Five CSS variables were used but declared nowhere. --success, --danger, --accent-on, --border-strong and --bg-subtle appear across Workforce, Actions, Tables, Billing and the blast-radius graph. Because none existed, every call site silently fell back to its own literal — roughly the right colour today, guaranteed not to follow any future token change, and in two cases the fallback was transparent, which is not a colour anyone chose. Defined as aliases of the primary tokens, so they now track them.
• Three unrelated palettes were living in the codebase at once. A flat-UI set (#e74c3c / #2ecc71 / #f39c12 / #6c5ce7) in Code Reviews, Impact, the graphs, toasts and empty states; a GitHub-dark set (#3fb950 / #d29922 / #f85149 / #58a6ff) in Skills and Feed files — hues tuned for a dark canvas, which read washed out on white. 61 literals swapped for the app’s own red, green, amber and violet. Same roles, one palette.
• DB Graph was built for a dark background. 45 values of the form rgba(255,255,255,0.06) for surfaces and borders, rgba(0,0,0,0.4) for panels, and white text at 20-45% opacity — on #f0f1f3. The footer hint was white at 25% over a light grey canvas, i.e. invisible; the table-detail column headers were barely better. All of it now reads from tokens, and the FK edge uses --accent-amber rather than a one-off orange.
• Page titles were 24px everywhere; the design says 26px. The same inline style triple was copy-pasted as the <h1> in fourteen panes — a de-facto token that was never a token. Bumped in one sweep. It should be an actual class, and that is worth doing next time one of these panes is touched.

DB Graph now uses the databases you actually connected

• There were two database implementations and they did not talk to each other. The real connector — the one ingest uses — reads your saved database_connections, speaks Postgres and MySQL, and decrypts the DSN. The DB Graph pane used a second, weaker path: raw pymysql, MySQL only, credentials retyped into the request body every time, and a hard requirement that a password be present. A saved Postgres connection could not be opened by that pane at all. Verified end to end against a public read-only MySQL: the real connector returns 64 tables with correct foreign keys, which is exactly what the graph draws edges from.
• And the fetch panel listed nothing. It iterated DEFAULT_DBS, a hardcoded empty array — so the one control for getting a schema in offered zero rows. New /api/db/connections lists your saved connections by name (never the DSN — a DSN in a JSON response is a DSN in a browser cache) and /api/db/introspect introspects one by name.
• The serious one: schemas were written to a shared namespace. The old endpoint hardcoded wiki/default/_db_schema for every caller, and /api/db-graph fell back to exactly that folder when a workspace had no graph of its own — so one workspace’s table names, columns and foreign keys were served to any workspace that had connected nothing. The same fallback existed on the per-table schema route. Both fallbacks are gone and the new endpoint writes under the caller’s namespace. An empty graph is the correct answer when you have connected nothing.
• Two field names that never matched. The connector reports row_estimate; the pane read row_count — so row counts rendered as nothing. It also read sample_rows and engine, which the connector does not produce, which is why that sample-rows grid has been permanently empty. Renamed at the boundary. A composite foreign key is now flattened to one entry per column pair rather than dropped.
• A test caught a regression in the error path: the generic “could not run that query” wrapper (which exists so driver errors cannot echo a DSN) was swallowing the actionable “no saved connection named X” message. Resolved separately now. One unreadable table also no longer abandons the other 63. 7 tests.

The chat read like a log file, and the footer sent customers to a build log

• Your own turns were indistinguishable from the agent’s. Both sides rendered as the same left-aligned block with an avatar and a role label, so scrolling back through a long thread meant reading text to work out who said what. User turns are now a right-aligned accent bubble with the avatar and the “You” label dropped — the alignment already carries that information, and repeating it was noise.
• Citations were a stacked list that pushed the answer off screen. An answer grounded in eight files spent more vertical space listing them than saying anything. They are now wrapping numbered pills, so the sources stay one glance away instead of one scroll away.
• Saved conversations showed a title and nothing else. With a dozen threads named after their first question there was no way to tell last week’s from this morning’s. Each row now carries a relative timestamp under the title.
• The context bar said “scope: workspace” without ever saying what is in that scope. It now lists the connected sources as quiet pills next to the scope chips — only connectors whose credentials are actually configured, because an unconfigured connector answers nothing and listing it would overstate what the brain can reach. Nothing renders when there are none, and past five sources the rest collapse into a +N chip so a workspace with a dozen connectors cannot push the model picker off the row.
• The connector status banner hugged the left edge and left the Ingest button stranded mid-row. Reported twice. The button already had margin-left: auto, which does nothing on its own — auto margins absorb free space, and there was none: .gh-status is itself a flex container, so its inner wrapper was a flex item sized to its own content and the row had nothing left to distribute. Giving that wrapper flex: 1 makes it claim the row, and the auto margin finally has something to push against.
• This page was still linked from the landing header and both footers. It is an engineering build log; a customer clicking “Changelog” hoping to learn the product got commit archaeology. Those links now point at the docs guide. The page stays, and stays accurate — it is just no longer the front door.
• Unlinking it did not remove it. firebase.json sets cleanUrls: true, so /features resolved to the file whether or not anything linked to it, and every URL already indexed stayed live. The build now deletes it from the published tree after the copy step, at both / and /enhanciar/; the /features API route is gone, since serving it from the backend would have restored the exact URL we just removed; and it is dropped from the no-cache header pattern. The file stays in frontend/public/ and still gets an entry on every change — including this one. It is our log, not a published page.

The app promised a trial we never grant and a token cap we no longer have

• Onboarding announced “Your 14-day free trial is live”. TRIAL_DAYS defaults to 0 and no deploy sets ENHANCIAR_TRIAL_DAYS, so a new account lands unsubscribed and every LLM route 402s — the trial was never granted to anyone. Pricing, Terms and Refunds all already said, correctly, that there is no free trial; onboarding was the lone outlier, and the first screen a new signup sees. The final step also said “Free tier active”, and there is no free tier.
• Checkout advertised “0 tokens/day”. The backend stopped sending daily_token_cap when the caps came out, and the formatter falls back to zero — so the order summary offered a paying customer nothing per day, and the payment-success page congratulated them with “your daily cap just jumped to 0 tokens”. Ten sites in all, including the plan feature lists, the Settings plan strip, the sandbox plan switcher, and two error messages still telling people to wait until tomorrow for a cap reset that never happens.
• Both are copy, so only a test keeps them true. A new suite greps the built frontend for trial promises and cap figures and fails on either — skipping the trial check if an operator ever sets ENHANCIAR_TRIAL_DAYS, so enabling a real trial does not break the build. It caught one leftover (monthly_token_cap in Settings) that the manual sweep missed, which is rather the point.

User documentation, because this page was never for users

• This changelog was the only thing in the site footer a new customer could click hoping to learn how the product works. It is a build log written for us — it explains why a fix was made, in engineering terms, newest first. Someone trying to find out what the Ingest tab does had nowhere to go. New /docs guide: what Enhanciar is, quick start, BYOK, one section per real connector, the Slack bot, ingest-vs-auto-sync, a tour of every sidebar tab, actions, MCP, workspaces, billing, FAQ.
• Written from the code, not from this page. Every claim was checked against the source — the 15-minute debounce against SLACK_INGEST_DEBOUNCE_SEC, the action list against the executor registry, Gmail being drafts-only against the scope. Where the code and the UI disagreed, the claim was dropped rather than guessed: onboarding advertises a 14-day trial while billing.py defaults TRIAL_DAYS=0, and the payment flow still shows a “daily token cap” field for caps the backend no longer enforces — so prices and trial length point at the Billing tab instead of being restated. Both of those are real inconsistencies worth fixing.
• The footer now reads Documentation / API reference / Changelog. The catalog stays — renamed to what it actually is, and demoted below the guide.

The chat suggests what to do with an answer, instead of always offering a ticket

• Every answer carried a “+ Create ticket from this” button, whether or not the answer implied any work. “What does this repo do?” does not want a Jira ticket, and an answer that genuinely should become one looked identical to one that shouldn’t — so the button taught people to ignore it, which is worse than not having it.
• Now the LITE model decides — the same cheap model the composer’s scheduling detector uses, never the chat model, and only after the stream closes so it cannot delay a single token. It returns at most two suggestions and usually none: most questions are someone learning how the system works, and learning something does not create work.
• It can only suggest what the workspace can actually execute. The menu is built from connected connectors, and any action the model names outside that set is dropped rather than corrected — a button behind a connector you never set up is an ad for a setup flow, and it would fail on click. A test pins that every entry in the catalog has a registered executor.
• Fail-soft throughout. A dead model, a timeout, an unparseable reply, or nothing connected all produce zero suggestions and zero noise. The answer is the product; a suggestion is a nicety, and no part of reading one should be able to break because of it. 13 tests.

“hi” is not a question the brain failed to answer

• In Slack it produced “the provided context does not contain information to answer your query” — true, and a terrible first impression, since a greeting is exactly what a new teammate types first. Answered before any model is resolved, so it costs no tokens and cannot vary by which model the workspace happens to be on. The match is anchored and whole-string: “hi, why did the payment retry fail?” is a real question that opens politely and still goes down the grounded path.
• The same “hi” was also filed as a knowledge gap, so the Ingest tab reported “1 question your brain couldn’t answer” and quoted a greeting. Filtered on read, so rows already stored clear too. The test that matters here is the negative one — a shortcut that swallowed a real question would silently drop it.
• And that panel’s button did nothing. “Connect a source →” called onViewChange('source') — the sub-view the banner is already displayed on. The answer to a knowledge gap is almost always “connect the source that has it”, so it goes to Connectors now. The gap count is also badged on the Ingest nav item, because a panel is only useful if you know it has something in it.

The Slack backfill window moved to the button it governs

• It applies to the first ingest only — so the one moment it matters is the moment you are about to press Start ingest, and it was sitting on the Connectors page, a screen you visit to manage a connection rather than to start a run. Now directly above the button, worded to match it.
• The Ingest button on the connector banner floated mid-row on a wide card, because it relied on the text block’s flex:1 in a container that wraps. Pinned right with margin-left:auto. It already navigated to the Ingest tab with the connector pre-selected; that part was working.
• Which model answers an @mention is now stated on the Slack panel. Two settings share one word: the “Enrichment model” on the Ingest page summarises threads during ingest, while answers use your account default from Settings → Models, with no Slack-specific override. People set the first and wondered why answers didn’t change.

The Slack ingest preview listed raw timestamps instead of threads

• “Available to ingest” showed 1785591344.239279. The Slack connector never set DocRef.title, so the preview fell back to the last segment of the doc id — a Slack message ts. That is the one screen whose job is to tell you what a run will pull before you spend your own key on it, and it was answering with an internal identifier. Now #channel: first line of the thread.
• Deliberately cheaper than the real title. _derive_title renders a proper page title, but it has the full thread and resolved display names — both of which cost API calls, and listing must not pay per thread under Slack’s ~1 request/minute history limit. The preview label uses only what the listing response already carries. A thread with no text (a file share) falls back to the channel, and having neither leaves the caller’s existing fallback untouched.

A team workspace never sent its id with any connector or ingest call

• The symptom: Connectors said Slack was connected and the Ingest page said it was not — the same question answered two ways on two screens. /api/connectors resolved Slack by uid, so any install by that user lit the badge green; ingest resolves by workspace, and the install was stamped to a team. Both are now workspace-scoped, so they cannot disagree.
• The cause was broader than Slack. headerFor() exists precisely to send X-Workspace-Id, and every connector and ingest call omitted it — /documents, /available, /preview, /count, /browse, the connector list, and every ingest entry point (connector, code, GitHub issues, WhatsApp). Only GoogleByoPanel had ever wrapped its fetches in a helper that added it. So with a team workspace active, the backend saw “personal” on all of it.
• The worst case was silent, not loud. A failed listing at least shows an error. An ingest started from a team workspace resolved to the installer’s personal namespace — so it looked up a connector where nothing is connected, and anything that did get pulled would land in a wiki no teammate can read, on the installer’s own key.
• The lint caught the half-done fix. Three files got the header before they got the import; vite build compiled all three clean and no-undef failed them. Exactly the class of error that promotion to error was for.

The header counter said “254 today” and never said of what

• It read 254 / 50,000 today while daily token caps existed. Removing the caps correctly removed the denominator — and left a bare number with no unit, which reads like a count of something you are supposed to recognise. Now “254 tokens today”. The hover text already gave the in/out/calls breakdown; the visible label was the gap.

The whole app was rendering in the wrong typeface

• Every colour already matched the design exactly — accent, all four surfaces, borders, text, radii, shadows, token for token. One token did not: the body font. index.css correctly set --font-sans to IBM Plex Sans, the face index.html actually loads. dh-tabs.css, imported one line later and therefore winning, overrode it to Inter — which is never loaded anywhere. Every browser fell through the stack to -apple-system and rendered the system font, on every screen, while the correct face was fetched on every page load and used by nothing.
• That was the “it still doesn’t look like the design”. Right colours, right layout, wrong letterforms — which reads as "off" without being attributable to anything. The two declarations now match, with a comment saying they must. DbGraph hardcoded 'Inclusive Sans' on its SVG labels too, so its text disagreed with every other label on screen; fixed the same way.
• A trap worth recording: the design project ships a _ds/modernist-…/styles.css token file — red #ec3013, beige surfaces, every radius zero. It is a different design system attached to the project, not this app’s. Porting it wholesale, which was one instruction away from happening, would have turned Enhanciar red and square-cornered. The real values are inline in Enhanciar App.dc.html.

Three surfaces that were shipped switched off

• Settings carried two sections wrapped in {false && …} — an email-notifications block whose toggles persisted to Firestore that nothing read (we send no email), and a beta-features list whose flags gated no code path. Both were written, shipped, and unreachable. Deleted rather than left as a comment promising a someday: the git history holds them if either backend lands.
• Chat’s microphone button had no click handler at all. It looked pressable, was titled “Voice input (coming soon)”, and did nothing. A control that does nothing is worse than an absent one — people click it and conclude the product is broken.
• WhatsApp is hidden from the nav. The pane still carries a SAMPLE DATA badge and a “coming soon” card, so the chats it shows are not the user’s. The component and its routing stay untouched; only the way in is gone, so restoring it is one line once the connector is real.

The Slack panel now says what to type in Slack, and whether you have to keep pressing Ingest

• Nothing on the connected panel mentioned @mentions. The bot’s main feature was documented in the changelog and nowhere the user would look. Someone who connects, invites the bot and then waits for something to happen concludes it is broken. The panel now shows the literal thing to type — /invite @Enhanciar, then @Enhanciar why do we retry payments twice? — and says answers come back in-thread with sources, from the same brain as the Chat tab.
• “Do I have to click Ingest?” had no answer on the page either, and the wrong guess is expensive in both directions: assume it is manual and you press a full re-import repeatedly on your own AI key; assume it is automatic and your first channel never gets read at all. Now stated as three cases — press it once to start (the only time the backfill window matters), after which new Slack activity syncs on its own at most every 15 minutes and pulls only what changed, and press it again only to force a full re-read after inviting the bot to new channels.

Disconnecting Slack now removes the bot from Slack

• Disconnect used to delete our record and tell Slack nothing. The bot stayed in the workspace and in every channel it had been invited to, still looking installed to the team — but we no longer held a token, so it answered nothing. A silent bot in a channel is worse than an absent one: the team keeps @mentioning it and reads the silence as a broken product. Disconnect now calls apps.uninstall, which pulls the app out and revokes the token, before dropping the local record.
• The propagation was one-way and is now two. Removing the app in Slack already reached us — the live auth.test check sees account_inactive and the badge flips within the 5-minute status cache. The reverse direction simply did not exist.
• It fails soft, but honestly. An unreachable Slack, or a deploy with no Slack app configured, never blocks the disconnect: leaving someone pinned to a brain we hold no working token for is worse than a leftover bot they can remove by hand. The response carries uninstalled, and when it is false the toast says so and tells them to remove the app in Slack — reporting a clean “disconnected” would leave that silent bot behind with nothing pointing at it. An app that was already gone (account_inactive / token_revoked / invalid_auth) counts as success, since the desired end state holds and sending the user to remove a bot that is not there is a false alarm. The cached live-status verdict is cleared on the way out. 6 tests.

Design pass wave 2 — Tables, Billing, ERD, Workforce, Ingest

• Five panes rebuilt to the revised design, and the rule was “omit rather than invent”. The mockups are full of plausible sample numbers — 41 tables, “5 of 84,201”, “14 runs / 37 proposals / 31 accepted”, “•••• 4242”, “Stage 2 of 5” — and every one of them is a number a real workspace may not have. Each was computed from the API or dropped. Nothing was hardcoded from a mockup.
• Sample rows have never worked. sample_rows appears nowhere in the backend — the schema endpoint returns columns, indexes, foreign keys, row count, size and engine, and nothing else. That grid has been permanently empty since it shipped while looking like data simply hadn’t loaded. Two more in the same file: the PK/FK badges checked c.is_pk/c.is_fk, fields no producer sets, so they never rendered (real data uses key === 'PRI'); and a non-OK response from the tables endpoint is swallowed into the empty state, so a 402 is indistinguishable from “no tables”.
• Tables gains the column-spec card above the sample grid. The design’s free-text “Notes” column has no backing field, so it is derived from real schema facts instead — → ref_table.ref_column, unique, indexed, default … — and left blank when there is nothing true to say. The row-count pill appears only when row_count exists, marked ~ because MySQL’s TABLE_ROWS is an estimate.
• Billing gains the payment-method card. Primary method is the most recent captured payment sorted by timestamp rather than trusting API order; “Also on file” is the distinct methods actually seen in past payments, and disappears when there is only one. A wallet payment has a name but no last4, so nothing renders ••••undefined. The “Use”, “Add a method” and “Manage in Razorpay” buttons are all omitted — there is no API to set a default instrument and no portal URL we hold, and a button that goes nowhere is worse than no button. Also fixed a pre-existing bug: the payment-history header declared five grid columns to the body’s six, so “Invoice” wrapped to a second line and every header sat one column left of the data it labelled.
• ERD is now the design’s rail + expanded cards + collapsed chips, with a working ⌘K jump, pinning, and computed counts. With nothing pinned it auto-opens the six most-connected tables so the pane is never a wall of chips. Schema grouping has no backing field, so groups derive from the only real attribution available — the repo whose code contributed a relation — falling back to one group named after the database. The interactive canvas is kept behind a Cards / Canvas toggle, along with every extraction control. And its node cards were still hardcoded dark (#1a1c26 card, #e5e7eb text) from when that canvas sat on a dark surface — on the light canvas they read as holes punched in the page.
• Workforce becomes the text list plus Charter / Ledger tabs, with “Ask the council” inline rather than a modal. That move exposed a real hazard: the old modal only rendered Convene after an estimate existed, so “see the cost before you run it” held by accident of layout. Side by side, that accident disappears — so Convene is now explicitly disabled until an estimate is fetched. The estimate reads ≈ Nk tokens · 7 model calls and shows no currency figure: the endpoint returns a token count with no model id, and a dollar number would be invented. “31 accepted” is not rendered at all, because no such count exists anywhere in the API.
• Ingest keeps its three tabs and gains the pipeline strip and terminal event stream. Client-side file rejections used to vanish — an over-size or unsupported file raised a toast and disappeared, so the user never learned why their file didn’t upload. Rejected files now stay in the batch with the reason. The accepted-extension chips render from the ACCEPT_EXT constant itself and the size limit from a single constant, so neither can drift from what the code actually enforces. “Stage 2 of 5” is omitted: different pipelines emit different stage counts (code = 3, connectors = 2), so a fixed “of 5” would be fiction.
• Built by five agents in parallel with strict file ownership — no shared CSS file, no concurrent builds, no commits — then reviewed, lint-checked and built as one change. 0 lint errors, suite green at 1430.

The two states nobody designed: empty and loading

• Every mockup is full of data. A real workspace starts with none, and spends time loading on the way there — so the two states a new user meets first were the two nothing had been drawn for. Shared PaneLoading and PaneEmpty now cover Wiki, Map, Impact, Tables, DB Graph, ERD, Skills, Actions and Code Reviews, with per-pane copy lifted verbatim from the design rather than paraphrased.
• The empty state does real work. Each pane says what fills it — “a read-only connection string, or a repo containing migrations” — so “nothing here” arrives with the reason and the next step instead of leaving you to guess which of twelve connectors was the missing one. A blank rectangle reads as broken; this reads as not-yet.
• Two real bugs fell out of it. The DB Graph’s empty state was rgba(255,255,255,0.3) — white text left over from when that canvas was dark — so on the light canvas “no schema loaded” was invisible, and an empty graph looked exactly like one still loading. The Map had no empty state at all: zero nodes rendered as a blank canvas under a faint “Mapping your galaxy…” that never resolved, which is indistinguishable from a hang.
• Skeletons shimmer on opacity, not a moving gradient — one composited property, so six rows animating at once stay cheap on a slow machine, which is exactly the machine most likely to be sitting on a loading state. Honoured under prefers-reduced-motion: a pulsing wall of six rows is precisely what that preference exists to stop, and the layout still reads as unloaded without the movement.
• Two things deliberately not shipped. The design’s “Explore the sample workspace” button is omitted — there is no sample workspace, and a button that does nothing is worse than no button. And there is still no error state: the design models exactly three (data / loading / empty) with no failure copy, so inventing one would mean inventing a visual language. Panes keep their existing error handling; raised as a design gap instead.
• Also: Skills cards are a fixed 2-up (auto-fill gave three or four columns on a wide screen, each narrower than its own body copy needs).

Design pass, wave 1 — and a new “Who to ask” card

• Impact now answers the question you have next. It tells you what breaks; the immediate follow-up is who to talk to before breaking it. New Who to ask card ranks people by how much git history they have in the affected files, reading the authorship index ingest already builds. No index (shallow clone, non-git source) means an empty list and no card — showing nothing is honest, guessing a name is not. Emails are normalised so one human is one row, and commits sum across files so the person with the most history wins rather than whoever sorts first. 9 tests.
• Wiki articles no longer run the full window width. The centre column was uncapped, so on a wide screen a page stretched edge to edge and the line length became unreadable. Capped at the designed 760px, applied to the children rather than the scroll container so the scrollbar stays on the right edge.
• Chat answers sit in their own card — a long reply now reads as one object instead of running into the next turn, with citations as an attached panel below it. Only the assistant’s: a user’s own line in a matching card would read as a second answer. Citations render as a sibling of the answer body rather than a child, so the two are joined visually without restructuring the markup or depending on :has().
• Actions cards lead with a coloured KIND pill (Jira / Linear / Slack / Gmail draft …) instead of a bare icon, so a queue of twenty is scannable for what each one will do without reading any of them.
• Layout corrections: Impact’s five stat cards align on one row instead of wrapping; the code tree’s Imports and “Used by” sit side by side rather than stacked (stacked, they pushed the rest of the pane below the fold); its stat cards are 4-up not 2×2; the file rail is 250px. Copy: “Impact”, “Billing”, “Monthly usage”, “Enhanciar API keys”.
• DB Graph tables are cards now, not dots. A circle told you a table existed; the card tells you what is in it — name, then its key columns with types, primary keys and foreign keys marked. Keys sort first because they are what the edges connect and what a reader scans for. The .dbg-table styles for exactly this had been sitting in dh-tabs.css unused, rendered by nothing. Drawn as foreignObject inside the zoom/pan group rather than absolutely-positioned divs on top, so cards inherit the transform for free and cannot drift away from their edges mid-drag. Two forces had to move with it: the collision radius is now the card’s half-diagonal (at the old 10px, cards piled into an unreadable stack) and link distance roughly doubled, because edges shorter than the things they connect read as one clump. Databases and code models stay circles — they are landmarks, not schemas, with no columns to show.
• Deliberately not done in this wave, and worth naming rather than quietly skipping: the Cost pane’s per-kind breakdown rows need a by-kind aggregate that storage does not keep (only a 200-event ring buffer), so rendering them would mean labelling last-200 data as a month total — a schema change and backfill, not a UI tweak. The five structural rebuilds (Workforce, ERD, DB Graph, Tables, Map) are each a rewrite rather than a restyle and are a wave of their own.

Token caps are gone — the paywall is a subscription check, not a budget

• Capping tokens protected nobody. Every LLM call in Enhanciar runs on the customer’s own API key, so a daily/monthly token ceiling guarded no budget of ours. All it did was interrupt paying customers spending their own money, and report it as though they had exhausted some allowance we’d granted them — a 429 that read as "try again later" for a state that resets at midnight. Deleted: enforce_token_cap, meter.check_cap, _caps_for, billing.get_caps, and the daily_token_cap/monthly_token_cap fields on every plan.
• But the cap WAS the paywall — which is the part that would have been easy to miss. DEFAULT_PLAN is free with caps of 0, so enforce_token_cap’s 402 was the only thing standing between "signed up" and "full product". Removing it naively would have made Enhanciar free for anyone who created an account. Replaced with an explicit require_active_subscription asking the one question that actually matters: do you have a plan? It reads through effective_plan_id, the resolver that honours the sandbox test-plan override and downgrades expired subscriptions, so a lapsed plan correctly lands back on the gate. Still a 402 — that routes the UI to Billing, where a 403 would read as "not allowed" with no next step.
• The dangerous edit was mechanical, not clever. 23 routes used Depends(enforce_token_cap), which returned the uid and therefore stood in for Depends(current_uid). Deleting it rather than substituting would have turned each route’s username: str into a FastAPI query parameter — unauthenticated and impersonatable by anyone appending ?username=. A test now pins exactly that. The GitHub webhook’s two inline cap checks got the same treatment; the push branch returns 402 rather than 429 because GitHub retries a 429 with backoff, hammering us over a state that will not resolve on its own.
• Usage recording stays; only enforcement went. The Cost dashboard, the header meter, /api/usage/* and the admin Costs page are all built on it, and a BYOK user still wants to see what they spent. The meter is now a meter rather than a budget: no denominators, no progress bars, no ∞ sentinel. One trap on the way — the Cost dashboard used usage.caps as its "real data arrived" marker, so dropping the field from the API would have left it permanently blank; the marker moved to a field that still exists.
• Kept deliberately: per-minute rate limits (they protect our compute, not the customer’s token bill), the daily action-execution cap (a ticket-spam guardrail), seat limits per plan, and the unlimited_quota flag — which is not dead, since it still lifts both of those and is force-enabled on sandbox. Its description no longer claims to bypass a paywall it can no longer reach. 14 new tests; suite at 1357.

Security pass: a cross-tenant page read, SSRF guards, and a billable endpoint nobody could reach

• GitHub webhooks can no longer be replayed. A valid HMAC proves a message came from GitHub; it does not prove we haven’t already handled it, because replayed bytes carry the same valid signature forever. Each replay re-enqueued an ingest on the repo owner’s BYOK key. Slack already bounds this with a 5-minute timestamp window and Razorpay dedupes on event id — GitHub had neither. Now claimed once per X-GitHub-Delivery via the same atomic Firestore create() the Slack mention de-dupe uses. Claimed after signature verification, deliberately: otherwise a forged request could burn the id of a genuine delivery and suppress it, turning a replay guard into a denial-of-service. It fails open — the opposite of the Slack ingest debounce — because a dropped push means the wiki silently goes stale with nothing to point at, while a duplicate costs one redundant ingest the user can see and re-run.
• A failed email lookup used to deny a user access forever. ACL domain: matching resolves a uid to an email, and that lookup was cached for the process lifetime — including its failures. One transient Firebase error stored "no email" permanently, and that user silently stopped seeing documents they were entitled to, with nothing to point at. Failed lookups are now not cached at all (the next check retries), a genuine "this account has no email" still is, and the whole cache gained a 60-second TTL to match the membership cache — because emails do change, and a stale one silently decides access.
• A stranger could read another workspace’s page. When a wiki page wasn’t found in your namespace, the handler scanned every tenant directory and returned the first name match, gated only by the document’s own ACL. But ACLs are inherited from the source system: a Google Drive file shared "anyone at gmail.com" arrives as domain:gmail.com, one shared "anyone with the link" as public:*. Those labels mean "everyone on this team" where they came from; read across a tenant boundary they mean everyone on Earth. Worse, the fallback only fired when you lacked a page of that name — the normal case — so it was the easy path, not the hard one. Fixed in two independent layers: the cross-namespace scan is deleted (a page you can’t see in your own workspace is now a flat 404), and acl.is_visible makes workspace membership a precondition rather than one option among several, so an ACL can only ever narrow access within a workspace and never grant it across one. Neither layer alone is load-bearing. A test that used to assert public:* was "visible to anyone" now asserts the opposite for a non-member — it had encoded the bug.
• No SSRF guards on user-supplied addresses. Three features hand an address to the server to fetch — website ingest, "add this URL as a file", and database connections — and from inside Cloud Run that reaches the metadata service, private VPC ranges and localhost. New enhanciar/net_guard.py resolves the host and refuses if any address it resolves to is private, loopback, link-local or reserved. Three details make that real rather than decorative: it resolves rather than pattern-matching (blocking the string "169.254.169.254" is useless when an attacker can point their own domain at it), it checks every answer (judging the first is a coin flip they get to re-toss), and it re-checks after redirects (a public URL may 302 inward). Crawls re-check every followed link, since each hop is a fresh user-influenced URL. DNS rebinding is explicitly not covered — that needs connect-time pinning — and is documented rather than implied.
• Database errors were a working port scanner. run_sql_read returned the raw driver error, which distinguishes "connection refused" from "not a database" from "timed out" — exactly enough signal to map the internal network one guess at a time. The real error is now logged and the user gets a generic one. Related: kind was validated against a whitelist but never compared to the DSN itself, so {kind:"postgres", dsn:"sqlite:////app/data.db"} was accepted and read local files. The declared kind and the DSN scheme must now agree, and unlisted dialects are refused outright.
• Removed the voice endpoints — they billed us, not the customer. TTS and Whisper ran on the operator’s Google Cloud credentials rather than a BYOK key, with no rate limit and no token cap, so any authenticated user could run them indefinitely on our bill. They were also completely unreachable: the only caller was a hook nothing imported. A billable, unmetered, publicly-reachable surface serving a feature no UI exposed. ~600 lines gone. If voice returns it must be BYOK-funded and rate-limited.
• Found by an adversarial audit of auth, tenancy, secrets, webhooks, the action layer, billing and the frontend. Explicitly verified as correct: all 213 routes authenticated, forged X-Workspace-Id rejected, owner gating consistent, no action executable without approval, BYOK secrets encrypted and masked on every read path, ingest redacting secrets by filename and content, all internal endpoints OIDC-gated, no dangerouslySetInnerHTML anywhere. 25 new tests; suite at 1331.

A chatty Slack channel no longer re-ingests the workspace on every message

• And now it only pulls what changed. The debounce below fixed how often a re-ingest ran; this fixes how much each one does. The shared pipeline has had incremental-sync machinery for a while — a since parameter, a per-connector watermark, a partial-listing guard — and the Slack connector always accepted since. The Slack pipeline simply passed None, one line, which means "give me everything". Slack-event and auto-refresh jobs now carry the last successful watermark, so a new message costs one thread instead of a month of every channel. A human clicking "Ingest now" still gets a full pull, because that is what pressing that button means.
• The subtle part is when NOT to advance the watermark. Slack pages newest-first, and the connector has hard caps (5 history pages, 200 threads per channel) plus an error bail-out — so a truncated walk drops the oldest threads in the window, which are exactly the ones just after the last watermark. Advancing past them would skip them on every future run, permanently and invisibly. The connector now reports truncation via last_list_partial (page cap, thread cap, API error, and an unreachable channel list), and the pipeline withholds the watermark when it is set. Finding nothing, by contrast, does advance it — otherwise every quiet period would re-sweep from the same stale point forever.
• You choose how far the first import reaches — 7 days, 30 days, 3 months or a year, in Settings. Only the initial backfill; everything after is incremental, so it is a one-time cost. Whitelisted rather than free-form on purpose: it is charged to your own LLM key, and Slack's history endpoint allows roughly one request a minute, so "everything, forever" is a bill attached to a job that never finishes. An unset or off-menu value falls back to the connector default rather than ingesting nothing.
• The bug, and why nobody had hit it. Every message event enqueued a re-ingest — and that job takes no since, so it re-swept ~30 days across every connected channel and LLM-enriched each document it touched, on the user’s own key. Per message. The code had been there a long time but was dead: the Events API was switched off at the Slack app, so no event had ever arrived. Turning Events on for the @mention bot brought this to life at the same time, which is exactly the kind of thing that only shows up as a bill.
• Bursts are now coalesced into one sweep per window (15 minutes, SLACK_INGEST_DEBOUNCE_SEC; set 0 to restore per-message). The window is claimed by bucketing time and letting the first message in each bucket win it via the same atomic Firestore create() trick the mention de-dupe uses — the doc id is the window, so exactly one writer can win and there is no read-modify-write race to lose. A message landing either side of a bucket boundary can trigger two sweeps rather than one; that is the deliberate price of not needing a transaction, and two was never the problem.
• It fails closed, unlike the mention de-dupe next to it — deliberately opposite. If Firestore is unavailable the sweep is skipped, because a missed sweep is picked up by the next message or by the nightly auto-refresh job, whereas failing open during an outage is precisely the runaway spend this exists to prevent. The mention de-dupe fails open for the mirror-image reason: there, the cost of failing closed is a user staring at a question that never gets answered.
• Two existing tests caught the behaviour change rather than silently passing, which is what a loop guard suite is for; both now pin the window open so they keep testing the guard and not the debounce. 6 new tests.

One contact address everywhere, because only one mailbox exists

• The site published seven addresses; the account has one mailbox. support@, security@, privacy@, legal@, hello@, billing@ and beta@ appeared across the terms, privacy, refunds, security and API-docs pages, the landing footer, the pricing and payment enterprise CTAs, the beta-features card and the invoice supplier block. The mail account has exactly one mailbox — support@enhanciar.in — and is at its plan cap of 1.
• Nothing was bouncing, but only by accident. A wildcard catch-all (*@enhanciar.in → support@) was quietly delivering all six of the others. That is a fine safety net and a bad contract: it is one toggle away from silently swallowing vulnerability reports and data-deletion requests, and it invites replying from an address the recipient can never usefully reach. Everything user-facing now names the mailbox that actually exists.
• Left alone deliberately: the @enhanciar.in in connectors/base.py, which is an example of ACL domain matching, not a contact address. ENHANCIAR_SUPPLIER_EMAIL keeps its env override; only the fallback changed, and that variable is set nowhere, so invoices now carry support@ too.

Ask the brain in Slack — @mention the bot, get a cited answer in-thread

• Almost all of this already existed. The Slack app, the OAuth install, HMAC-verified webhooks, the Fernet-encrypted per-team bot token and chat.postMessage have all been in production since the action layer shipped. What was missing was narrow: the webhook only ever looked at message events (to enqueue an ingest) and returned early on everything else — so an app_mention, which is not type message, was silently discarded. The new branch sits above that early return, and a test pins the ordering, because if it ever slips below it again every question is dropped with no error anywhere.
• Same pipeline as the web chat, deliberately. Answering calls the exact helpers mcp_server.query calls (_gather_wiki_context → _byok_stream), so the app, MCP and Slack cannot drift into three different answers to the same question. Sources come back as Slack links; markdown is converted to Slack’s mrkdwn dialect (**bold** → *bold*), and a long answer is trimmed with a link to the full one rather than dumped into a channel.
• The 3-second problem. Slack retries any webhook that doesn’t return 2xx within three seconds; a grounded answer takes far longer. The obvious fix — ack, then answer in a background task — is wrong here specifically: the service deploys with --cpu-throttling, so anything still running after the response is written gets starved. The webhook therefore acks immediately and enqueues a Cloud Task to a new OIDC-gated /devhive/internal/slack/answer, which arrives as its own request with a full CPU slice. Cloud Tasks unconfigured (local dev) falls back to running inline.
• Dedupe is load-bearing, not defensive. Slack retries on timeout and on any 5xx of ours, and every retry carries the same event_id. Without an atomic claim, one slow answer becomes three identical posts in the thread and three BYOK bills. Claims use Firestore create() so concurrent retries can’t both win — and fail open if Firestore itself is down, because a broken dedupe store should degrade to "might answer twice", never to "silently never answers".
• Never leaves a mention hanging. A pipeline failure posts the error into the thread instead of dying quietly, and the internal endpoint always returns 200 — a non-2xx would make Cloud Tasks retry and post that same error again. A failing Slack post is swallowed for the same reason: raising would loop over a Slack outage.
• A Slack install now attaches to a workspace, not just a person. The install record only ever stored uid, so a shared team bot could only read the installer’s personal brain — backwards for exactly the customers who want one. installation_set now also stamps workspace_id, resolved at OAuth issue time by the membership-checking _resolve_workspace_ns (so the callback can trust it and nobody’s consent can be attached to a workspace they don’t belong to) — the same pattern the Google install route already used. Two ids travel from the webhook to the worker and they are not interchangeable: ns is which brain to read, uid is whose BYOK keys pay for it, because keys live on the user document and looking one up by a team workspace id finds nothing and turns every answer into "no LLM key on file". The ACL viewer stays the installer, since a Slack identity is not an Enhanciar one. Legacy installs have no workspace_id; they fall back to the personal namespace, which is exactly where they pointed, and are matched by uid only for that workspace — folding them into every workspace the installer belongs to would silently widen what a team brain can read. In-flight Cloud Tasks enqueued by the previous revision carry no ns and fall back the same way rather than being dropped mid-deploy. The catch that would have made all of it inert: the Connect button never sent X-Workspace-Id, so the backend would always have seen "personal" no matter which workspace was active — fixed in both OAuth entry points.
• Connecting Slack to a team workspace is owner-only. The installation is funded by the API key of whoever authorizes it — BYOK keys are Fernet-encrypted per user and only decryptable in that user’s context, so we cannot silently spend the owner’s on someone else’s behalf, and doing so would charge an owner for traffic they never consented to and cannot see. But that leaves a quiet failure: if a rank-and-file member sets it up, the whole channel’s bot dies the day they leave or rotate their key, reporting "no LLM key on file" with nothing pointing at the departed teammate. Requiring the owner makes the funder and the workspace owner the same person, so the failure can’t arise. The 403 explains the funding reason rather than just refusing. Personal workspaces are never gated — you are your own owner — and a test pins that the owner check isn’t even consulted for them.
• Scope and gating. Adds app_mentions:read to the install — without it Slack never delivers the event at all, so existing installs must reconnect or the bot looks silently broken. Behind a new slack_bot flag, default OFF because every mention spends the workspace owner’s BYOK tokens; sandbox forces it on. Answers are grounded in the brain of whoever installed the app — Slack identities are not Enhanciar identities. 25 tests.

Removal notices, and invites you can actually see — in both directions

• Removal was silent too. Taking someone off a workspace sent nothing. From their side the entry simply vanishes from the switcher — and if it was their active workspace, the resolver falls back to personal, so chat and wiki quietly start answering from different data with no explanation. They now get a notice naming who removed them, confirming their own brain and keys are untouched, and saying they’ve been switched back to personal.
• Pending invites are always shown to owners now, empty or not. Hiding the section when empty made the feature undiscoverable and — worse — hid the reason it was empty. Inviting someone who already has an account adds them straight to Members and never creates a pending invite, so owners were left thinking their invite had disappeared. The empty state now says exactly that.
• Both invite lists relaid out. Outgoing rows get the same avatar · identity · badge · action shape as Members, with "waiting for them to sign up with this address" spelled out and Revoke pinned right. Incoming invites now name who invited you and state up front that joining doesn’t share your own data — the question every invitee actually has.

Adding someone who already has an account told them nothing at all

• The gap. An invited address that already has an Enhanciar account skips the invite/token path entirely — the uid resolves, the roster updates, the call returns. No email was sent on that path. So a person could be joined to someone else’s workspace with no signal whatsoever, discoverable only by happening to open the workspace switcher. The pending-invite path (address with no account) always mailed; the direct-add path never did — exactly backwards from what the recipient would expect.
• Now they get a "you were added" email. Separate from the invite mail because there is no token and nothing to accept. It says who added them, that it’s ready now via the workspace switcher, and — explicitly — that their own personal workspace, sources and API keys were not shared, copied or moved. That last line is the first question anyone asks.
• Best-effort, and deliberately so. The member is already on the roster before the mail is attempted, so a mail failure is logged and swallowed rather than surfaced. Otherwise the owner sees an error for an add that actually worked and retries it. Pinned by a test that raises from the mailer and asserts the call still returns.
• Member rows relaid out. Name, email, owner badge and the remove button all sat in one inline flex run, so a long address pushed a destructive control hard against it with no separation. Rows now read avatar · name-over-email · badge · action, with the action pinned right and the identity column truncating instead of shoving.

Team invites: the member cap read the wrong plan, in both directions

• The bug. _enforce_member_cap read the owner's stored plan field directly instead of going through billing.effective_plan_id — the one resolver that both honours the sandbox test-plan override and downgrades expired subscriptions. Reading the raw field got it wrong twice over.
• On sandbox it was too strict. A tester who had switched themselves to Unlimited still hit "The Free (expired) plan includes 1 member" and could not invite anyone. Exercising gated features is the switcher's entire purpose, and the member cap — one of the most obviously gated things in the product — silently ignored it.
• In production it was too loose. A lapsed team subscription was read straight out of the document with no expiry check, so a workspace whose plan had already ended still admitted ten members. That one was quietly giving away paid seats.
• Also fixed: sandbox had no SMTP configuration at all, so invite emails were created and then silently dropped — is_configured() returns False and the send is a no-op. Sandbox now uses the same mail credentials as production, with the sender name marked Enhanciar [sandbox] so a test invite is distinguishable from a real one in the recipient\'s inbox.
• Three regression tests pin the resolver rather than the raw field: unlimited override lifts the cap, an expired paid plan falls back to one seat, and Team stops at ten.

Cost table headers say what the numbers actually are

• Renamed, not rebuilt. The per-message table already existed with the design comp's exact columns; only the wording differed. in / out / spend are now Tokens (in) / Tokens (out) / Spend (est.).
• "(est.)" is deliberate. That figure is derived from published per-token rates, not from the provider's invoice. It was always an estimate; the column now admits it rather than implying a billed amount.
• The comp's "Cache hits" column was left out. Cache savings are tracked as a daily total (already surfaced as "Cache savings today") but not per call — the per-event record carries only at, model, kind, in, out. Adding the column would need the recorder to persist a per-call cache figure, and would only populate going forward. An empty or invented column is worse than no column.

Every emoji-as-icon is gone, connected sources get real brand marks, and Files / GitHub / WhatsApp join the sidebar

• Connected sources had no logos. Settings → Connections listed Slack, Google and GitHub as plain text rows, even though connectorIcons.jsx has carried the real brand marks all along and four other panels already use them — Settings was simply the one surface that never did. Each row now leads with its service's own logo.
• The rest of the emoji went too. Ingest's source tabs (📦 🌐 🔗), its file-kind filters and checkboxes (📄 🖼 🎬 📦), the Google connector rows (✉️ 📄 📅), the feature tour (⚡ 💬 📚 🕸️ 💥 🔍 🔌) and the ingestion-history rows all rendered emoji as UI icons. Brands now use the real mark; generic kinds use a new KindIcon drawn in the same single-stroke style as the nav, so a row mixing a GitHub logo and a "Docs" icon reads as one set. The tour reuses the nav icons directly, keyed by the tab each step points at.
• Caught in review: the ingestion-history rename looked dead — a grep for .icon in that file found only the definition — but the value was destructured and rendered 160 lines further down. Renaming it blind would have silently emptied that glyph on every history row.
• Files, GitHub and WhatsApp are in the sidebar at the owner's request, matching the comp. All three panes already existed and rendered; Files had been hidden as "developer-only, redundant with Wiki/Map", and GitHub and WhatsApp simply had no nav entry to reach them from.

The nav and Settings rails get the design comp's icon set — and the emoji come out

• Settings was rendering emoji as UI icons. The five-tab rail used 👤 🤖 🔌 🔒 ⚙️. Emoji render in the OS colour font, so they ignored the active/inactive text colour entirely, sat on a different optical baseline to their labels, and looked different on every platform. They're now the comp's stroked 24px paths, which inherit currentColor and dim with the label when a tab is inactive.
• All 21 sidebar icons swapped too. The rail imported Phosphor and switched each glyph to weight="duotone" when active. With the Settings rail now drawing the comp's single-stroke icons, that left two icon languages one panel apart. The whole set is now the comp's ICONS table, copied verbatim, rendered through one small NavIcon component; active state comes from the button's own colour rather than a per-icon weight prop. Phosphor is no longer imported here.
• Pane ids deliberately unchanged. The comp calls two panes map and ingest; the app calls them graph and input. The icon keys use the app's names — renaming panes would have churned routing and deep links for a presentation change.

Home gets the right-hand rail from the design comp — and three stat tiles that refuse to make numbers up

• What shipped. Home is now two columns, per the Claude Design comp (Enhanciar App.dc.html): the activation checklist keeps the left, and a new rail on the right carries Recent sources (drawn from the manifests Home already fetches) and Ask a starter question. Above both, a stat row. Collapses back to a single column under 1040px so the rail stacks instead of crushing the checklist.
• The design's stat tiles were demo fiction; ours aren't. The comp mocks up "128 wiki pages / 312 questions answered / 7 stale pages". HomePanel has carried a rule since v1 — nothing here invents numbers — so only tiles with a real source behind them render: wiki pages, questions asked, sources. The Stale pages tile was deliberately dropped: there is no aggregate endpoint for it, and a hardcoded 7 would be a lie rendered in the product. It comes back when the endpoint does.
• Starter questions navigate, they don't prefill. Same as the comp's own buttons. Wiring the question into the composer needs a prompt channel through App → AgentChatV2 that doesn't exist yet; passing an argument onNavigate silently ignores would have looked wired without being wired.
• Worth recording: the comp is a refinement, not a re-theme. Its colours (#1C525D, #0E1113, #E4E1D6, #fbfbfc), its fonts (IBM Plex Sans + JetBrains Mono), its shell and its nav groups are already what the app ships — the comp even notes its brand icons were copied verbatim out of connectorIcons.jsx. So the remaining work across the other 20 panes is per-pane structure, not a design-system migration.

CI now deploys Firebase Hosting too — the half of prod that a green deploy didn't cover

• The gap. enhanciar.in is served by Firebase Hosting, not Cloud Run: Hosting serves every static page and the built SPA bundles itself and only forwards a few prefixes (/devhive/**, /enhanciar/api/**, …) to the Cloud Run service. CI deployed only Cloud Run, so any change to a static page, the landing bundle, or firebase.json's rewrites and headers needed a manual firebase deploy --only hosting on top of the push — which is exactly the kind of step that gets forgotten. Shipping /security proved it: the deploy went green and the URL still 404'd until Hosting was pushed by hand.
• The fix. Three steps appended to the deploy workflow — set up Node, build the Hosting bundle, firebase deploy --only hosting. Auth reuses the existing Workload Identity Federation step (firebase-tools reads Application Default Credentials), so there's no long-lived FIREBASE_TOKEN secret to rotate or leak; the CI service account was granted roles/firebasehosting.admin, which it did not previously hold.
• Production only, and that guard is load-bearing. There is one Hosting site — the default, mapped to enhanciar.in — while sandbox.enhanciar.in is a custom domain on the sandbox Cloud Run service, not a second Hosting site. A sandbox push that deployed Hosting would therefore overwrite prod's static content from an untested branch. The if: github.ref == 'refs/heads/main' on all three steps is the only thing preventing that, and the workflow says so in a comment so nobody relaxes it without giving sandbox its own Hosting target first.

A security page you can actually read, and a model picker that asks your provider instead of guessing

• New /security page. We ask people to connect their codebase, their Slack and sometimes their inbox, and until now the only answer to "what can this thing actually do with my data" was a four-tile band on the landing page. The new page answers it per connector: what each scope reads, and what it categorically cannot do — gmail.compose creates drafts only and does not grant send; Slack has channels:history but deliberately not users:read.email; Drive is read-only; anything that touches the outside world is proposed, approved, then executed exactly once. Plus where data lives (Firestore + bucket in Mumbai, compute in Singapore), how keys are encrypted (Fernet at the application layer, never logged, never readable back), the subprocessor list, and how to delete everything. It also states plainly that we hold no SOC 2 or ISO 27001 today, because a small team's security page earns trust by being legible, not by implying an audit we haven't had. Served at a clean /security URL (Cloud Run route mirroring /privacy, plus the Firebase cache-control entry) and linked from the landing footer.
• Model names are no longer hardcoded. Both model pickers — Settings and the in-chat switcher — were arrays we wrote by hand, which went stale every time a provider shipped or retired a model. The failure was silent and awful: you picked something from our months-old dropdown and got a 404 from the provider on your first ingest. Exactly what happened when Google retired the Gemini 2.5 family for new API projects. New enhanciar/model_catalog.py + GET /api/models/available asks each provider what your key can actually reach — Google's v1beta/models, OpenAI's and Anthropic's /v1/models, and any OpenAI-compatible custom endpoint (Groq, Ollama Cloud, OpenRouter, Mistral, a self-hosted gateway) — and merges the answer over the curated list.
• The curated list is a floor, never a ceiling. A live fetch only ever adds. No keys saved means no network call at all and today's exact dropdown; a provider outage, a network block, or a key without list permission degrades to the same. So the picker can never render empty, which would be a dead surface with no path out of it. Curated labels win on collision, so "OpenAI GPT-4o (BYOK)" doesn't get overwritten by a bare id.
• A bad key now surfaces in Settings, not at ingest time. A 401 from a provider's list endpoint is reported under the picker as "invalid or unauthorized key" — distinguished from "couldn't reach provider" — which is the earliest possible moment we can tell you the key you just pasted is wrong. One provider failing never suppresses another's models.
• Two details that would have bitten later. Custom-endpoint model ids keep their family prefix (groq/llama-4-90b, not llama-4-90b) because _provider_for falls through to Google for anything unrecognised — a bare Groq id would have been sent to Gemini with a Groq key. And the response cache is keyed on a hash of the credential, never the credential itself, so rotating a key invalidates its own entry without us tracking rotations, and no key material sits in the cache dict. 27 tests in tests/test_model_catalog.py.

Freshness phase 2: connector pages go event-stale, staleness gets section-level precision, stale pages can regenerate as a diff you approve — and the Contradiction Ledger arrives

• The identity join. Connector pages now carry doc_id + body_sha frontmatter, and a resolver re-links existing pages to their source documents retroactively (URL first, stored ids second, slug reversal third — and it refuses to guess rather than mark a stranger's page). Found and fixed on the way: GitHub-issues pages wrote no source: at all, making them invisible to the source filter, and action/relation backlinks pointed at un-slugged page names that don't exist on disk.
• The nightly change probe. One incremental listing per connected connector per night — no bodies fetched, no LLM, no tokens — joins changed documents to the pages built from them and marks those stale; a deleted source document tombstones its page ("the source of this page was deleted") instead of leaving it lying confidently around. Confluence and Drive version counters filter no-op touches (label churn, permission edits) so timestamps alone can't cry wolf. The probe keeps its own watermark and can never advance the ingest's — proven at the AST level by a test that reads the code itself. Deletion blind spots fixed in three connectors: Notion archived pages, Drive trashed files, Calendar cancelled events.
• Section-level staleness. When code changes, the ingest now records which symbols moved, and the answer context marks only the sections of a page that mention them — the rest of the page answers unencumbered. Pages with no headings, no symbol data, or nothing matched degrade byte-identically to page-level marking; ## Changelog is excluded (it names every symbol trivially).
• Regenerate as a draft you approve. A stale page's re-verify ask can now carry a full regenerated draft, built at propose time, shown as a before/after diff on the approval card (powered by a new preview endpoint that finally exposes every executor's own render_preview). Approval writes the page, re-indexes it, and clears the badge — with a race guard: if the page changed on disk after the draft was made, the executor refuses rather than clobbering a newer edit. Capped per week (the trust-budget v1) so the bot earns its right to speak.
• The Contradiction Ledger. When two of your own documents disagree, the code arbitrates: checkable claims (timeouts, ports, env defaults, versions, endpoints) are extracted from docs/tickets/mail/chats — the LLM only extracts; the verdict is deterministic — and evaluated against the repo. "README says 30s, the runbook says 60s, prod.yaml says 90s — two docs wrong, one right." Home tab card + one-click scan; one repo-wide grep per scan, not one per claim; agent-generated pages deliberately excluded so summarisation artefacts can't pose as human disagreements.
• Adversarial review caught two severe bugs before ship. (1) The probe's version cache advanced even for documents it couldn't resolve to a page — permanently hiding them from every future probe; versions are now recorded only when the mark actually landed. (2) The probe ran its per-document writes and Firestore reads on the event loop, which would have stalled every concurrent chat request on the instance during a nightly run; all off-loop now, plus an aggregate time budget so an oversized night defers cleanly to tomorrow instead of dying at the request timeout with nothing recorded.

Freshness fast-follow: connector pages join time decay, and re-verify cards become approvable

• Connector pages had no freshness signal at all. Research for phase 2 found the v1 scope note ("connector pages get time decay only") was generous: nothing ever stamped last_verified on a connector page, and a page with no record scores full confidence forever — so a six-month-old Jira page read exactly as trustworthy as one written today. Every pipeline now stamps the page it just wrote (writing is verification — it was rendered from the source seconds ago), keyed on the on-disk slug, flag-gated, and never able to break an ingest.
• Re-verify proposals could not be approved. The Actions approval card demanded a tracker-style title field that a re-verify payload doesn't have, so every "is this page still right?" ask was dead on arrival in the UI. The card now knows the action type (no target to pick — the page is fixed at propose time) and the approve checks only apply to fields an action actually declares.
• Phase 2 planned. A 4-agent research run (code recon + market + per-API change-detection) produced docs/planning/PLAN_FRESHNESS_GAPS.md: the doc_id identity join, a one-request-per-connector nightly change probe, soft tombstones for deleted sources, symbol-scoped partial staleness, and draft-based regeneration with a trust budget.

Freshness, part 2: stale pages are ranked lower, marked in the answer, and badged in the UI

• Ranking penalty, on both retrieval paths. A stale page is demoted by a penalty derived from the same RRF arithmetic as the existing usefulness bonus — capped so it can break a tie between near-equal matches but can never push a genuinely better match down. Critically it is applied on the keyword-only path too, not just in hybrid fusion: the vector index is off by default, so a penalty living only in fusion would have been dead code for most workspaces. A stale page is re-ordered but never dropped from the results — a stale answer carrying a warning beats no answer.
• The answer says it. Stale pages enter the model's context prefixed with a marker naming what changed and when it was last verified, and the prompt instructs the model to repeat that caveat in its answer rather than presenting the content as current fact.
• Visible everywhere it is cited. The wiki page list and page header carry an amber STALE badge; the provenance strip that used to read a hardcoded "Auto-drafted by Enhanciar" now shows "Last verified <date> · <N>d ago" when a record exists. Chat citations badge stale sources amber with a tooltip explaining why. The badge is never colour-only — it carries the word and a title, and renders nothing at all when the flag is off.
• Four bugs caught in adversarial review, before shipping. (1) Only the staleness boolean reached the chat, so every citation tooltip said "hasn't been verified in a while" — even when a source file had changed, which is the opposite of the signal. The reason now travels with it. (2) The prompt promised the model a marker that the context-size budget could have cut, and the new re-ordering makes stale pages more likely to sit at the cut; the instruction now follows the pages whose bytes actually reached the model, not merely the pages selected. (3) The read path resolved the feature flag against the viewer while every other half of the feature resolves it against the workspace, which in a team workspace produced a half-on state that reported every page as fresh. (4) An internal bookkeeping field is stripped from the public API response.
• And the loop closes: stale pages now ask to be fixed. When an ingest finishes, the pages it left stale are queued as "is this still right?" proposals in the approval queue — approve one and it asks in Slack; confirm the answer and the page is marked verified and the badge clears. Approval-first like every other action: nothing is sent without a human saying so. Crucially the volume is small by construction, which is what makes filing them instantly safe: a page this run regenerated was already re-verified and never reaches the ask path, so what gets queued is only the residue regeneration could not repair — not one ask per file in the diff. A sweeping refactor is capped, and the number dropped is reported rather than silently truncated. A completed ask no longer silences a page forever either, since re-verification recurs: a page confirmed correct in March can go stale again in September and deserves its own ask.
• The nightly sweep. A Cloud Scheduler job now does the housekeeping a read cannot: it drops records for pages that no longer exist, and stamps an "age" reason on pages that have quietly aged past the threshold so that anything inspecting a record sees what the ranking already sees. It deliberately files no asks — "a source file changed" earns an interruption, "this page is a year old" does not, and a nightly job queueing those would teach a team to ignore the queue.
• Asks now name the person who wrote it. Ingest builds an authorship index from git history, resolves the top author of the changed files to a workspace member, and addresses the ask to them — a real Slack mention where we know the handle, their name where we don't. The hard part was refusing to guess: repositories are cloned one commit deep, so a naive history read attributes every file to whoever pushed last — verified in a test that builds a real repo where Alice owns the auth code and Bob commits last, and confirms the shallow read blames Bob for Alice's file. So the pass deepens history first, and if that fails for any reason it writes nothing: an unaddressed ask is fine, an ask sent to someone who never touched the code is not. Bot accounts are excluded for the same reason — a lockfile bot would otherwise become the author of half the repo. Identities merge only on an exact email match; no fuzzy name matching, because merging two real people means sending someone questions about work that was never theirs.

Freshness, part 1: knowledge that knows when it has gone out of date — and the incremental-ingest bug found on the way

• Every "incremental" re-ingest was secretly a full one. The per-file sha256 map that decides which files changed was written to local disk and was never mirrored to durable storage. Cloud Run containers are disposable, so the map was gone on every cold start and each re-ingest re-enriched the entire repo — billed to the customer's own BYOK key. The state directory is now backed up and restored with the other sidecars. The restore also had to be wired, not just declared: the ingest worker reaches the pipeline directly from the job runner and never passes through the read-path rehydrate, so the state is now pulled back inside the pipeline itself, immediately before the incremental check that consumes it.
• Branch-aware state. The hash map was keyed by repo only, so switching branches reused the wrong map. Branch is now part of the key, with one-time migration of an existing branch-less file so nobody is forced into a full re-ingest by the upgrade.
• The changed-file diff is now persisted (added / modified / removed, capped, with a timezone-aware timestamp and the commit) instead of being computed and discarded — it is what the staleness join consumes.
• Freshness core. New per-workspace record of when each page was last verified and what invalidated it, with age-based confidence decay whose half-life depends on the category — a Slack thread from March is a snapshot of a moment, an architecture page is not. A page invalidated by a source change is floored low no matter how recently it was touched. Stored as a sidecar rather than in page frontmatter, deliberately: the page-merge path drops unknown frontmatter keys, code-page frontmatter is model-written and unvalidated, and file timestamps are reset by rehydration.
• The causal join. On re-ingest, changed source files are resolved to the wiki pages built from them through the existing file→page reverse index, and those pages are marked unverified; pages regenerated in the same run are marked verified instead, because regeneration is verification. Path matching runs in three tiers (repo-relative, last-two-segments, then basename) because clone paths and recorded paths disagree in practice; an ambiguous basename resolves to nothing rather than to a guess, since a wrong staleness badge costs a real person a pointless "is this still right?" ask.
• Freshness records are durable too. Caught in review: the new sidecar was covered by neither artifact list, so every record would have died on the next pod restart — the same bug as the hash map, and it would have made the whole feature a silent no-op in production. It is now mirrored, and the ingest path restores it before the join, which read-modify-writes it and would otherwise have wiped the history it never loaded.
• Workforce ledger backlink. Proposals filed from an agent run pointed at agent_task/ with no id, because the id was read under a key the writer never set; and the count of actions found was written to the record after it had already been saved, so it reached nobody. The id is now minted before filing and both values land in the single append-only write.
• Scope. This was the plumbing half, behind the freshness flag (default off). Ranking penalties, the "may be out of date" note in answers and the wiki badges shipped in part 2 above; the re-verify action follows. Event-based staleness currently covers code pages; connector pages get age-based decay only, because per-document content hashes do not exist yet — a deliberate cut, recorded as one.

Mobile chat: the clarify session could stick for 24 hours, surviving "New chat"

• The bug. MobileChatApp.jsx froze its session_id for the life of the mount (useState(genSessionId)) and the "＋ New chat" button only reset the message list, never the id. The server keys its pending-clarify document on (uid, session_id) and permits one outstanding round per session, clearing it only when the user's choice comes back or after a 24-hour TTL. Mobile's stream reader handles only text and trace, so it silently drops action_needed and can never echo a clarify_choice — meaning the first clarify round asked on that session was orphaned by construction, and the cap then suppressed every later round for 24 hours across every "new" chat in the tab.
• The fix. The id now lives in a ref and is regenerated by the "New chat" handler, so a new thread always starts a clean clarify session. This mirrors the same fix applied to the desktop chat, where the id is additionally derived from the saved chat id so reopening a thread rejoins its own round rather than orphaning it.
• De-duplicated. genSessionId was copy-pasted in both chat surfaces; it now lives once in frontend/src/api.js with a comment recording the invariant it exists to protect — hold it in a ref, regenerate per thread, never freeze it per mount — so the two surfaces cannot drift again.
• Known and accepted. Mobile still renders no connect/clarify chips; it is a deliberately minimal surface. With a per-thread id the only residual cost is one unconsumed clarify document per mobile thread, which expires on its own.

Launch-blocker: every new BYOK key 404'd because the default model was retired

• The bug. Verified live with a freshly-created Google AI Studio key: gemini-2.5-flash and gemini-2.5-flash-lite both return HTTP 404 — "This model is no longer available to new users", and gemini-2.5-pro returns 429 (no free-tier quota). gemini-3-flash-preview and gemini-3.1-flash-lite return 200. Because our own server key lives in an older, grandfathered GCP project, the app looked healthy to us while every new BYOK customer hit a 404 on their first ingest or first chat message.
• The fix. gemini-3-flash-preview is now the default everywhere a Gemini default was hardcoded (models.py GEMINI_MODEL/FALLBACK_MODEL, llm_call.py, llm_model.resolve_ingest_model, server._resolve_user_model_prefs and the prefs GET, media_analysis, media_vision, workforce), and gemini-3.1-flash-lite is the cheap/lite tier (LITE_MODEL_FOR_PROVIDER['google'], resolve_lite_model's hosted fallback, the wiki-tools model ladders, and the page-writer's ENHANCIAR_PAGEWRITER_MODEL default). The models.py defaults carry a comment with the verified 404/429 matrix so nobody "tidies" them back.
• 2.5 stays selectable, not default. Settings, the chat model picker and the per-run ingestion-model dropdown all list Gemini 3 Flash (recommended) and 3.1 Flash-Lite (cheapest) first, then 2.5 Flash / Flash-Lite / Pro labelled legacy — existing keys only. Deleting them would have broken grandfathered keys that work fine.
• OpenRouter and Mistral added as providers. Both ride the existing OpenAI-compatible custom path: choosing an openrouter/ model auto-fills https://openrouter.ai/api/v1 and a mistral/ model auto-fills https://api.mistral.ai/v1, exactly like the Groq / Ollama Cloud auto-fill, so you only paste the key. Pickers gained openrouter/deepseek/deepseek-chat-v3.1:free (free) and mistral/mistral-small-latest, and the lite-model resolver knows a cheap variant for each. The prefix→provider lists in llm_model.py and server.py were collapsed into one shared CUSTOM_PREFIXES tuple so the two can no longer drift.
• Verified routing. gemini-3* ids still resolve to the google provider (they fall through the gpt-/claude-/custom-prefix checks) and still satisfy the frontend's isGemini batch-eligibility test — both now asserted in tests rather than assumed.
• Tests. tests/test_lite_model.py updated to the new lite id and extended with OpenRouter / Mistral lite variants plus an explicit _provider_for regression guard for gemini-3-flash-preview, gemini-3.1-flash-lite, and the two new prefixes.

Chat remembers the thread, the chips became clickable — and an adversarial review of both

• Action chips are now a UI, not just a wire event (A3). The action_needed line the previous entry added renders under the finished answer as a row of chips with a per-kind lead-in ("Needs live data —" / "Missing a source —" / "Which one?"), the recommended option in violet, and a "Not now" dismissal. Connect PostgreSQL on an auto-connectable database connects it in one POST and re-asks your original question for you; everything else deep-links into the Connectors tab with that connector pre-opened. Unknown future kinds render nothing rather than a dead chip.
• Conversational history — behind its own new chat_history flag. The last 4 turns ride along with each question as a bounded === PRIOR TURNS === block (re-truncated server-side to 4 × 2000 chars; the client is not a trust boundary), and a question too short or too back-referential to retrieve on its own words ("what about refresh tokens?") gets the previous user turn prepended to the retrieval string only — never to the question the model is asked to answer, which would make it answer the previous turn. Default off; sandbox forces it on via ENHANCIAR_FF_FORCE_CHAT_HISTORY=1.
• "Which database?" round-trip (A4.3/A4.4). When several databases are connected and the question doesn't say which, the ambiguity is now detected before schema resolution — previously an ambiguous set introspected nothing, the code-schema fallback swallowed it, and a user with two hand-connected DSNs and no ingested repo was told to "Connect PostgreSQL" for a database they had already connected. The chip lists the connection names; your pick is stored as a pending round (24h TTL, at most one per chain), and the next turn resolves it back into the live query's connection hint plus a USER CLARIFIED: prompt line.
• Fixed: the flag-off guarantee was quietly false. History shipped un-gated, so turn 2 of every thread changed the prompt and swapped the retrieval string even with clarify_chat off. Both are now gated server-side on chat_history (gating the client would not have counted — an old tab keeps sending history either way), and the two dark-launches are independent: each is provably a no-op on its own.
• Fixed: the chat session id was per-tab, not per-thread. The server keys its pending-clarify state on session_id, which the client froze at mount. Consuming the round in one thread silently starved every other thread for 24h, and reopening the first thread and tapping its stale chip resolved against the other thread's options — pointing the live query at the wrong database. The id is now derived per thread (from the chat id once saved, a fresh id for the unsaved first turn) and re-derived on every new/open. The Firestore doc id also carries the caller's uid now, so two scripted clients in a shared workspace can't collide on session_id: "1".
• Fixed: one disambiguation used to kill the feature. The client latched "clarify already used" forever, but the server clears its round the moment a choice is consumed and will legitimately ask about a different ambiguity later. The client dropped those events while the server kept writing pending docs nobody consumed — leaving an orphaned clarify_rounds: 1 and clarify dead for 24h. The latch is gone; the server holds the state, so the server holds the cap.
• Fixed: a chip could abort your live answer. The composer stayed enabled during the auto-connect POST, so a question typed in that window was killed by the chip's own continuation — leaving the message stuck on "streaming…" forever and then persisting it. The continuation now checks a ref (not a stale captured value) before sending, the composer is locked while a chip is working, and the continuation bails out entirely if you switched threads mid-flight instead of dropping the old thread's question into the new one. It also re-asks with an empty history, so the model isn't primed with its own "I don't have a database connected".
• Smaller fixes. An ingest_source chip now opens Connectors, not Ingest (it is only offered for a connector that isn't connected, so the Ingest view failed its /available call on arrival). A stateless API client with no session_id no longer gets an unanswerable clarify chip on every single turn. Network-blip messages are tagged isError so they stop becoming conversational context, and a clarify turn keeps the real question in history instead of a bare Use "prod". Chips no longer render under an error banner. Clicking a chip no longer wipes a half-typed draft. Token metering now counts the history / clarified / detected blocks — for providers that report no usage at all (the custom OpenAI-compatible endpoint) that was up to ~8KB of prompt per turn billed as zero.
• Tests. tests/test_clarify_chat.py grew per-flag control in its harness plus: history flag off ⇒ empty prompt block and an un-expanded retrieval string, on ⇒ both; the two flags proven independent; no clarify event without a session_id and a correct one with it; the chat-state doc id scoped per caller; and the metering estimate growing with the new blocks. tests/test_a5_live_data.py adds the ambiguous-set-with-no-code-schema case (and a guard that the Firestore branch still wins). Frontend invariants (per-thread session id, no clarify latch, guarded continuation, locked composer) are asserted on the source, since the repo has no JS test runner.

Clarify chat — a miss now comes with a one-click way to fix it

• Connect-DB chips on live-data misses. Ask "how many orders yesterday?" with no database connected and the answer used to be a wiki-only guess or a flat "I don't know." The stream now carries an action_needed event built from the databases the ingest scan already detected in your committed code, rendered as a "Connect PostgreSQL" chip. It fires on two hard misses we can see before answering: a live-data question with reason == no_db (from the A5 outcome codes), or retrieval returning nothing at all.
• Connect-source chips when you name something unwired. A question mentioning a catalog connector that isn't connected ("check the Slack thread about pricing") offers to connect it. This one is held back as a soft-miss fallback: it's only emitted after the answer finishes, and only if the answer cited nothing and reads as an "I don't know" — so a question that merely mentions Slack but gets a good grounded answer stays chip-free.
• The model is told what it can't see. A bounded prompt block (max 5 sources, ~300 chars) names the detected-but-unconnected databases and instructs the model to say a source would be needed rather than guess values.
• No drift between chat and the Connectors tab. The suggestion core (_load_detected_sources → per-source suppression) was factored into one _connector_suggestions_for(username, ns) helper now shared by GET /api/connectors/suggestions and the query path, so the chip and the "Suggested" section can never disagree.
• Off by default, byte-identical when off. New clarify_chat catalog flag (default off, sandbox forced on). With the flag off no action_needed event is emitted and the detected-sources prompt block is empty. Scope of that claim: it covers everything clarify_chat gates, and nothing else — conversational history shipped afterwards and rides its own chat_history flag, so "both flags off ⇒ byte-identical" is the accurate statement (see the entry above). The event type is additive — both chat UIs switch on ev.type and ignore unknown types, so older clients simply render nothing. At most one action_needed per stream, ever.
• Tests. Added tests/test_clarify_chat.py (offline): flag-off stream parity, hard-miss ordering (the event precedes the first text chunk), soft-miss gating on citations + the shared IDK regex, the live-data intent classifier, option invariants (≤4, exactly one recommended), and the event key order.

Live database answers now work on any LLM provider — and pick the right DB when several are connected

• NL→SQL is provider-agnostic. The "translate the question into one read-only SELECT" step (_gen_sql_from_question) and its Firestore twin (_gen_collection_from_question) hard-imported google.genai and silently returned nothing without a Google key — so an OpenAI- or Anthropic-only user asking "how many orders yesterday?" got a wiki-only answer even with a database connected. Both now run through llm_model.lite_complete, the same public lite-model hook chat-title generation uses, which resolves the user's own cheapest model across providers (Gemini Flash-Lite / GPT-4o-mini / Claude Haiku / Groq 8B / gpt-oss / custom). The SELECT-only prompt and the read-only validation downstream are unchanged; an empty/NONE completion still means "no query," exactly as before.
• Multi-DB selection. The live-data path used the FIRST connected SQL DSN unconditionally. A new _pick_sql_connection(conns, hint) helper (shared by query_user_db, user_db_schema and resolved_schema via an optional connection_hint) picks by (1) the connection name appearing in the hint, (2) exactly one connection whose name tokens overlap the question, (3) a single SQL connection, and otherwise (4) returns an ambiguous_connection sentinel — with the candidate names — instead of querying the wrong database. With no hint it still returns the first connection, so every existing caller is byte-for-byte unaffected; the chat query path now threads the user's question through as the hint.
• Unambiguous live-data outcome. _maybe_live_data used to return a bare string, so callers couldn't tell "no DB" from "no rows" from "ambiguous target." It now returns (text, reason) with reason ∈ ok / no_db / no_schema / no_sql / not_read_only / no_rows / ambiguous_connection / error. The call site is unchanged in behaviour (it still uses only the text and falls back to the wiki answer); the reason is wired up for the upcoming connect-DB / "which database?" chat chips.
• Tests. Added tests/test_a5_live_data.py (offline): SQL/collection generation via a monkeypatched lite_complete for a no-Google-key user with google.genai poisoned so any import would fail; None on empty/NONE; _pick_sql_connection across all four selection branches; query_user_db picking the right DB from two connected sqlite DSNs and returning the sentinel on ambiguity; and the _maybe_live_data reason mapping. New file plus the db-query, A0 and route-registration suites green.

Three connector fixes — team-workspace DB suggestions, per-source de-dupe, Slack webhook loop guard

• Team workspaces now see detected-DB suggestions. Ingest writes the deterministic database scan (_detected_sources.json) under the active workspace namespace, but GET /api/connectors/suggestions and POST /api/connectors/db/auto-connect both read the personal uid path — so a team brain never got the "we noticed you use Firebase, connect it" nudge and one-click auto-connect found nothing. Both routes now resolve the namespace with the same _resolve_workspace_ns helper the rest of the connector API uses and read through one shared loader.
• Suggestion suppression is per-source, not all-or-nothing. suggestions = [] if db_connected else detected hid every detected source the moment any one database was connected. It now filters per source: a detected entry is hidden only when a live connection actually covers it — SQL entries matched on DSN host + database name (creds/port ignored), Firebase on projectId, with a label-vs-connection-name fallback for secret-needing SQL entries that carry no DSN. Connect Postgres and your detected Firebase is still suggested.
• Slack webhook no longer re-ingests on its own posts. Every message event — including the bot's own messages and edits/deletes Slack echoes back — enqueued a full team re-ingest. The handler now early-returns when the inner event carries a bot_id or a subtype of bot_message / message_changed / message_deleted, before enqueuing; HMAC verification and the url_verification challenge echo are untouched. Genuine user messages still trigger ingest.
• Tests. Added tests/test_a0_fixes.py (offline, fake Firestore): team-namespace resolution surfaces the detected file the old uid path missed; one connected Postgres + one detected Firebase keeps Firebase suggested while suppressing the matching Postgres; and the webhook ignores bot/edit events while still ingesting a real user message. Connector, webhook, route-registration and db suites green.

Sandbox test-plan switcher — test plan-gated features + quotas without paying

• New 🧪 card on Billing (sandbox only). Four segmented buttons — none / solo / team / unlimited — let a tester on the password-gated sandbox impersonate any plan to exercise plan-gated features and token quotas without a real charge. The active tier is highlighted; the card renders only when GET /api/billing/me reports test_plan_switcher: true, so customers never see it.
• Hard-gated to the sandbox. New GET/POST /devhive/api/billing/test-plan endpoints raise 404 unless the deployment carries the ENHANCIAR_TEST_PLAN_SWITCHER=1 marker (added to the sandbox env in .github/workflows/deploy.yml; the sandbox password gate is a fallback signal). Prod never sets it → the endpoint effectively does not exist and get_test_plan always returns None.
• Override beats the forced Unlimited quota. The sandbox pins ENHANCIAR_FF_FORCE_UNLIMITED_QUOTA=1 at the top of the flag chain. Quota resolution (usage._caps_for) now consults the per-user override first, so picking Solo yields 200k/day·5M/mo, Team 5M/day·100M/mo, and none the planless 0-cap paywall — while no pick leaves the forced Unlimited default (and prod) byte-for-byte unchanged. unlimited keeps ∞ and behaves like the best plan (Enterprise) for feature gates.
• Resolution precedence (quota): sandbox test-plan override → unlimited_quota force/flag → real billing plan caps. Plan/feature gating: billing.effective_plan_id() returns the impersonated plan key (none→free, solo→solo, team→team, unlimited→enterprise) and is surfaced as plan in /api/billing/me. Writes users/{uid}.test_plan; switching drops the per-user flag cache and a page refresh re-reads the caps into the header token meter (the UI says so).
• Tests. Added tests/test_test_plan_switcher.py: marker on/off gating (available on sandbox, absent/raises on prod-like env), override round-trip + clear, unknown-value rejection, effective_plan_id mapping, and quota resolution honouring the override incl. beating the FORCE flag — plus the no-override case keeping forced Unlimited. Backend suite + npm run build green.

Workspaces page redesign — delete a workspace, real member names, one clear list

• Delete a team workspace (new). New owner-only DELETE /devhive/api/workspaces/{ws_id}. The personal workspace is never deletable (400); a non-owner gets 403; unknown id 404. Because a team workspace's namespace is ns == ws_id, its brain lives everywhere a personal brain would, so deletion purges the lot: the workspace doc + its members array (every membership vanishes at once) + all pending invites, plus best-effort purge of the brain — on-disk pages under WIKI_ROOT/<ws_id>, the durable GCS copy under <ws_id>/, and the Firestore users/<ws_id> doc + its ingested-content subcollections (wiki_pages, proposed_actions, retrieval_signals, chats, agents, agent_tasks, meetings) — and detaches any Google accounts shared into the workspace (their tokens stay on the owner's personal workspace). Best-effort per step: failures don't abort, they're returned in errors with status partial. The frontend Delete button (on owned team cards only) opens a red type-the-workspace-name confirmation modal spelling out exactly what is lost; if the deleted workspace was active the UI snaps back to Personal.
• No more raw UIDs. The member list showed a bare Firebase UID (e.g. 0wsEO…KFR2 · owner). GET /api/workspaces now resolves each member uid → display name + email server-side (Firebase Auth get_user, falling back to the Firestore profile's display_name) and returns members_detail; the panel renders "Name (you) · owner" with the email beneath, never a uid.
• One clear list, one source of truth. Killed the top "Active workspace" dropdown that duplicated the cards and made people think workspaces were missing. Every workspace — personal and team — is now a uniform card: name, an ACTIVE badge on the active one, labeled chips ("Personal — only you" / "You own this", "Free plan", "👤 N members"), and per-card actions — Make active (inactive cards), ＋ Invite (expands inline, owned team only), Delete (owned team only). The create-workspace row stays. Light design language kept (violet #1C525D on white).
• Tests. Added DELETE /devhive/api/workspaces/{ws_id} to the route-registration check and four workspace tests: delete_workspace removes the doc + invites; the route enforces owner-only / personal-not-deletable / 404; and an owner delete purges membership. frontend build + backend suite green.

Responsive/CSS audit — mobile marketing pages fixed at 375px, desktop hero hardened

• The landing hero graphic broke every phone. The agent-swarm visual is an absolutely-positioned card cluster tuned for a 560px column, and the mobile stylesheet tried to scale a .hv-stage wrapper that doesn't exist (the element is .hero-visual) — so the rule never applied. On a phone the cards squished into ~347px, overlapped each other, clipped their own text (parsing src/api/… cut off), and left a tall band of dead space. The visual is now hidden below 880px and the hero column forced to a single track; the headline + lead carry the hero, as the task permits. No page-level horizontal scroll remains at 375px.
• features.html scrolled sideways on mobile. Long unbreakable tokens in the changelog — inline code like ENHANCIAR_EARLY_ACCESS_PRICE_USD and bare paths in prose such as /api/impact?target=…&depth=… — pushed the document to ~509–647px wide with no way to shrink. Added overflow-wrap: anywhere to code and an inherited overflow-wrap: break-word on body. Page is now exactly 375px wide, zero overflow.
• Desktop hero headline hardened. The italic gradient word you decide. (rendered with background-clip: text) can have its slanted glyph edge clipped by the h1 box or the hero's overflow:hidden; added trailing padding so it never touches the visual column at any width. Tap targets, type scale and grid stacking on the landing were re-verified at 375 / 768 / 1280; the mobile menu button is now 40px. privacy, terms, refunds and benchmarks.html were audited and already passed (their tables/code blocks scroll inside their own wrappers).

Static site moves to Firebase Hosting (CDN) — kills the ~22s cold start

• The problem, measured. enhanciar.in routed through the Cloud Run domain mapping into the FastAPI service, which served everything — including plain static HTML. With min-instances=0 a bare GET / cold-started in 14–26s (median ~22s), and there was no CDN, so every byte came from Singapore. A real visitor waited ~24s for the landing page.
• The fix: put static on Firebase Hosting, proxy only dynamic routes to Cloud Run. Added a hosting block to firebase.json (preserving the existing firestore + storage rules) with rewrites that send /enhanciar/api/**, legacy /devhive/**, and /…/mcp to the enhanciar Cloud Run service (asia-southeast1), and an /enhanciar/** SPA fallback. Hashed assets get an immutable 1-year cache; HTML revalidates. /__/auth/* is now Hosting-native for the project (no backend proxy needed).
• The layout bridge. Vite builds with base: '/enhanciar/', so pages reference /enhanciar/assets/… while the HTML files sit at the dist root — the backend papered over this with request-time URL normalization, which Hosting has no equivalent for. A new idempotent postbuild step (frontend/scripts/build-hosting.mjs, wired into npm run build) assembles frontend/dist-hosting/ whose on-disk shape matches the real URLs: HTML + collateral at the root (clean URLs), a full copy under /enhanciar/ (assets, dh-track.js, favicons, SPA shell), and the root index.html overwritten with the landing page so bare / serves marketing, not the app. The Vite build and the backend's own serving are untouched — Hosting is purely additive.
• Verified on the free URL, DNS untouched. Confirmed the landing, clean URLs (/privacy, /terms, /refunds, robots.txt, sitemap.xml, llms.txt), the SPA at /enhanciar/, SPA deep-route fallback, and immutable asset caching all serve correctly. The DNS cutover to enhanciar.in (add custom domain in Hosting, then remove the Cloud Run domain mapping) is a deliberate later, manual step documented in docs/planning/CUTOVER.md — nothing about production DNS or Cloud Run was changed. Note: Hosting rewrites do not proxy WebSockets, so any /enhanciar/ws feature must reach Cloud Run directly after cutover.

Performance: 5 Firestore reads → 1, one fewer API call on first paint, no double token verify

• The Early Access endpoint read the same Firestore document five times per request. Price, currency, display string and perks each resolved independently, so one /early-access/info response issued five sequential reads of config/early_access — measured at ~250–360 ms of its ~550–650 ms. One cached read (45s TTL) now serves them all; admin writes invalidate it so the panel still feels instant. Verified with a counting fake: 5 reads → 1, and 0 across the next 20 resolutions.
• /api/brand deleted from the landing's first paint. It was a whole Cloud Run round trip for a value the server hardcodes ("Enhanciar"). Brand now rides on the /api/app-open probe the landing already makes, so it costs nothing: 3 API calls on first load → 2. The endpoint stays for older clients, and the landing still defaults to "Enhanciar" so a failed probe never blanks the header (verified with the backend down).
• No Cache-Control on the landing HTML. Browsers heuristic-cache an HTML document with no directive, so after a deploy a stale copy could reference hashed assets that had been purged — a broken page for returning visitors. Now no-cache (always revalidate; ETag still makes that a cheap 304). Hashed assets keep their immutable 1-year caching — only the entry document revalidates.
• The waitlist gate was verifying every token twice. The middleware verified the Firebase ID token, then the route's require_user verified the identical token again — two blocking calls on an async path, on every authenticated request, plus an uncached Firestore invite lookup. The middleware now stashes its verified claims on request.state for require_user to reuse, and the allow/deny verdict is cached per credential for 60s (an invite going live a minute late is fine — feature flags already accept that staleness). The cache is keyed on a SHA-256 of the credential, never the raw token.

Payments visibility + Apple Pay domain verification

• A real purchase was invisible in the admin Billing page — two causes. (1) The page queried a top-level payments collection, but subscription payments are written to users/{uid}/payments, a subcollection — a top-level query matches nothing, so it read "no payment events" even with real data. Now a collection_group query sweeps every user. (2) Early Access Pass purchases were never going to appear there at all: the buyer has no account yet (they're just a waitlist email), so the money is recorded in waitlist_orders. The Billing page now has an Early Access Pass purchases section (passes sold + gross collected + per-order rows) reading that collection.
• Apple Pay domain verification is now servable. Razorpay checks for its verification file at /.well-known/apple-developer-merchantid-domain-association — plain text, no extension, at the domain root. Added a route that serves it from the build (drop the downloaded file in frontend/public/.well-known/; Vite ships it to dist). Caveat worth knowing: Apple Pay and PayPal are international-only on Razorpay — they only appear for non-INR orders. While the pass charges INR, neither will show in checkout however well-verified the domain is; that's a currency consequence, not a configuration bug.

Two bugs the first real payment exposed: double-checkout window, and crediting the list price

• The pay button came back to life while the payment was still being verified. Razorpay fires its ondismiss when the checkout popup closes — including immediately after a successful payment — and that handler cleared the busy flag. Verification takes a few seconds (measured 3.8s), so for that window the buyer saw the modal again with a live "Get the Early Access Pass" button, and a second click started a whole new checkout (the first real test purchase left 3 stray unpaid orders). Payment capture now latches a ref: ondismiss only re-enables the button if no payment was taken, any busy state disables it, and the button reads "Confirming your payment…" while verifying. A failed verification still re-opens it so the buyer can retry. (No money was ever at risk — the server already rejects a second order for an email that holds the pass, confirmed live with a 409.)
• Buyers were credited the LIST price, not what they paid. mark_early_access hardcoded credit_inr = EARLY_ACCESS_INR, so a ₹1 test purchase recorded a ₹1,999 credit toward the first subscription — and any future price change would have had the same effect for real customers. The credit now derives from the amount actually captured (cross-checked against the amount recorded on the order at creation), stored as credit_minor + credit_currency; a USD payment is expressed in rupees via the plan's own USD:INR ratio, so a full-price pass still credits exactly the list price while a $1 test credits ~₹83. Callers that pass no amount fall back to the list price, so nothing legacy changed behaviour.

Early Access Pass: ENHANCIAR_EARLY_ACCESS_PRICE_USD test-price override

• Charge currency is switchable from the admin panel too — because it decides which payment methods exist. UPI, netbanking, wallets and EMI are INR-only rails, so a USD-denominated Razorpay order silently collapses checkout to international cards only — which is exactly what a live checkout showed. The Feature Flags page now has a USD / INR selector next to the price: pick INR to restore every domestic method (foreign cards still work with International Payments enabled) at the cost of showing ₹ to everyone, or stay on USD for clean dollar pricing worldwide. Resolution mirrors the price: Firestore override → ENHANCIAR_EARLY_ACCESS_CURRENCY env → USD. The price box is read in the active currency (so "1" means $1 on USD, ₹1 on INR), and the API now returns a server-rendered price_display string so the modal's symbol always matches the currency Razorpay will actually charge — no more hardcoded "$".
• Set the price live from the admin panel — no redeploy. The Feature Flags page in the local admin panel now has an Early Access Pass price control: type a USD figure → Save, and checkout charges it within seconds (it writes config/early_access.price_usd in Firestore, which the endpoints resolve per request). Drop it to $1 for a real test payment, then Reset to default. Resolution order: admin override → ENHANCIAR_EARLY_ACCESS_PRICE_USD env → solo plan → $24 — one number drives the displayed figure, the Razorpay charge, and the server-side amount check together, so they can't drift.
• Verify now checks the RECORDED order amount, not the live price. Because the price can change at runtime, early-access/verify compares the payment against the amount stored on the order at creation (amount_paise) rather than the current price — so an admin price change between a buyer's order and their payment can't reject a legitimate charge. 2 tests added; full suite green.

Waitlist is now enforced on the backend, not just the SPA; one-branch deploy; cleanup

• Backend waitlist gate (closes the frontend-only bypass). An audit found the waitlist was enforced only by the SPA: because the Firebase web config ships in the public bundle, an un-invited person could authenticate directly, mint a dh_ API key, and hit the whole API + MCP despite waitlist_mode=true. A new middleware in server.py now gates every authenticated call to /api/* and /mcp: when the waitlist is ON and the caller isn't invited/admin it returns 403. It only inspects requests carrying an Authorization header (so public endpoints are untouched), keeps a small allowlist for the endpoints a parked user still needs (waitlist status, account delete/export, flag state), fails open on any resolve error (the route's own auth still applies, so a transient can't lock out a real user), and is a strict no-op when waitlist_mode is off — so the sandbox is unaffected. 6 tests: blocks uninvited key, allows invited, no-op on sandbox, invalid key passes through, no-auth never blocked, exempt/normalise.
• Sandbox stays a real staging gate (branch-based deploy). The deploy workflow keeps its branch → environment mapping so the sandbox branch is a genuine pre-prod test rig: push to sandbox → it deploys devhive-sandbox (sandbox.enhanciar.in, password-gated) at cpu=1/1Gi/max-1 with every feature flag force-ON and the waitlist forced OFF; verify there, then merge to main → prod enhanciar (cpu=2). Prod and sandbox run the same code and differ only by env "keys". (A brief experiment that deployed both services from one branch was reverted — it removed the staging buffer.)
• Cleanup. Deleted the dead WaitlistForm (an inline form left over from the modal refactor, never rendered and not waitlist-aware — a footgun). Made the remaining static landing prose (hero subline, founder note) runtime-aware so the sandbox reads "open the app" instead of pre-launch waitlist copy.

Landing CTAs are waitlist-aware — the sandbox stops pushing "Join the waitlist"

• One build, two behaviours, resolved at runtime. The same landing bundle serves prod (waitlist ON) and the sandbox test rig (waitlist forced OFF), but every CTA hardcoded "Join the waitlist" and Pricing hardcoded WAITLIST_MODE = true — so the sandbox, whose whole point is to test the working app, kept dead-ending users into a waitlist modal. CTAs now read the public /api/app-open probe once on load: waitlist ON → "Join the waitlist" (opens the modal); waitlist OFF → "Open the app" (goes straight to /enhanciar/app), and the pricing tiers show their real "Start now" checkout instead of the waitlist button.
• Centralised, fail-safe. A single PrimaryCta component + useWaitlistActive() hook back every CTA (nav, hero, mobile menu, pricing, the closing band, Actions/Code-review/Demo sections), so there's one source of truth. The default is waitlist ON until the probe resolves, so prod behaviour is byte-identical if the probe is slow or fails; only an explicit waitlist_mode:false flips to app mode. Verified prod still renders "Join the waitlist" with no regression.

Sandbox unlock page no longer leaks /devhive/ in the URL

• Enhanciar-only URLs, everywhere the user can see. The sandbox password form posted to /devhive/api/sandbox/unlock, so after a submit the address bar showed the internal enhanciar prefix. The form action now uses the public /enhanciar/ alias (UNLOCK_ACTION); the existing /enhanciar/* → /devhive/* middleware maps it back to the real route, and the exemption still matches on the normalized path. A test asserts the unlock page contains no enhanciar string for any normal navigation.

Admin panel: a "Platform keys" page that reads the live Cloud Run secrets

• Keep an eye on the keys from the ops panel, not the product. New page in the local Streamlit admin panel (admin/pages/14_Keys.py) that reads the platform secrets straight off the deployed Cloud Run services — both prod and sandbox — via gcloud (the same auth the panel already requires). It lists the Razorpay id/secret/webhook, master encryption key, embedding/vector key, server Gemini fallback, metrics token, sandbox password and early-access currency, side by side for the two environments, showing for each whether it's set, its length, and a SHA-256 fingerprint. A matching fingerprint across prod and sandbox means the same value is set in both.
• Masked by default, reveal on demand. Most secrets are Secret Manager-backed, so by default the page shows the secret reference (you can see it's wired without seeing the value); flipping 👁️ Reveal values fetches the real payload from Secret Manager. This lives in the admin panel — which binds 127.0.0.1 only and loads solely with admin gcloud creds — deliberately not in the customer-facing app, where rendering a live secret would be a leak surface. The page is read-only; rotation still happens in the GCP console.
• (An earlier build put a masked-status card in the in-app Settings → Security page; that was reverted in favour of this ops-panel page.)

Early Access Pass — priority, not instant access; and USD-only billing

• The Pass grants priority in the queue, not an instant unlock. The earlier build auto-admitted any paid holder through gate_allowed the moment they bought — i.e. buying your way straight into shared prod data with no invite. That is reverted: a paid holder is still gated until actually invited, exactly like a free joiner. What the money buys is position — list_entries now floats paid, still-pending holders to the front of the queue (a priority flag rides on each entry), so the admin invites them first. Copy across the waitlist modal, the pricing disclaimer and both FAQ answers was rewritten from "get in right away / refundable before your first sign-in" to "front of the queue, invited first / refundable any time before you're invited."
• Payments are charged in USD, always. The pass used to display "$24" but charge ₹1,999 in INR — an FX surprise at the Razorpay popup. The charge currency and minor-unit amount are now derived from the same solo-plan price the site shows (EARLY_ACCESS_CURRENCY/EARLY_ACCESS_CHARGE_AMOUNT, USD cents by default), pinned to USD on both deployments via ENHANCIAR_EARLY_ACCESS_CURRENCY. The order-create, the server-side signature+amount verification and the info endpoint all read the same pair, so the advertised price can never drift from the charged price. A domestic-only Razorpay account can still fall back to INR via the env override; an unknown currency fails safe to USD rather than to something Razorpay rejects. (Charging USD requires International Payments enabled on the Razorpay account.)
• Modal redesigned into a segmented toggle. The paid Early Access block used to stack below the free path, so the modal scrolled and the "$24" CTA was cut off — with two full-width purple buttons competing for the primary action. It's now a Join free / Early access · $N toggle: only the active path's context and CTA render at once, so each view fits without scrolling and has exactly one primary button. The toggle only appears when the backend reports paid is live; otherwise it degrades to the free path unchanged.
• Tests locked in. The instant-access test was replaced by two that assert the real contract — a paid holder is blocked until invited, and is sorted to the front of list_entries — plus USD-default and INR-fallback currency tests. Full suite green (618).

Graph memory — Phase 5: the retrieval benchmark is published at /enhanciar/benchmarks.html

• Numbers nobody outside the repo can check are just adjectives. Phases 1–4 produced a measured before/after; this phase puts it on a public page — frontend/public/benchmarks.html — with both columns side by side (keyword-only baseline vs query_routing + relation_triples on), the commit they were measured at, and the two commands that regenerate them. Every figure was re-run from scratch before publishing rather than copied out of a plan document: the baseline reproduced byte-identically, and the flags-on run matched the recorded table exactly.
• The limitations section is the longest one on the page, on purpose. It states in plain language that recall@5 (0.96) is near its ceiling because the corpus is 40 pages and retrieval returns 8 — a regression guard, not an achievement; that the run is keyword-only, so the lookup/conceptual vector weights are unmeasured because the vector path never fires; that the Phase-4 usefulness prior contributes exactly zero on a corpus with no usage history, verified rather than assumed; and that we wrote both the fixture wiki and the 60 questions, which is a conflict of interest a reader should weigh.
• No competitor appears anywhere on it. We have not run any other product on this corpus, so there is no comparison to make and the page makes none. It is explicitly labelled as our own regression harness rather than a competitive benchmark, and the honest headline is the modest one: citation precision 0.27 → 0.36, MRR 0.84 → 0.85, recall unchanged.
• The page cannot go stale, which is the whole engineering content of this phase. A published benchmark that silently drifts from its data is worse than no benchmark. tests/test_benchmarks_html.py parses the score table out of the HTML and compares every cell against the committed runs (tests/eval/baseline.json and the new tests/eval/routed.json), failing with the exact cell that disagrees; on top of that it pins a SHA-256 of each run's scoring content, so a change the cell check could miss — a new question type, a shifted n, a re-measurement at a different commit — still fails, and the failure message prints the digest to paste. The clock field is excluded from the hash so an identical re-run doesn't fail for no reason. Both layers were verified by mutating a baseline score and watching them fire.
• Static page, zero backend. No feature flag, no route, no production module touched — it is one file in frontend/public/ served exactly like features.html, plus the sitemap entry. 27 new tests (plus one added to the feature-catalog guard), full suite green (591).

Graph memory — Phase 4: self-improving retrieval (feedback loop + knowledge gaps)

• Retrieval never found out whether it was right. Every question offered the model a set of pages and then forgot the whole exchange. It now records both halves: what retrieval offered, and — by parsing the [[category/name]] handles out of the finished answer — which of those the model actually cited. The gap between those two lists is a free, honest relevance label, generated by normal usage, with no extra LLM call and no one being asked to grade anything.
• The prior is a rate, not a count, and it decays. A page's usefulness is cited ÷ offered, time-decayed with a 30-day half-life. Counting raw citations would just reward pages that retrieval happened to surface often — popularity measuring itself. The rate asks the only question that matters: when we did put this page in front of the model, did the model use it? The half-life means the prior tracks the company as it changes instead of ossifying around whatever was hot at launch.
• The cap is the feature. A usefulness prior that can promote a page above a better lexical or semantic match is a popularity death spiral: popular pages rank higher, so they get cited more, so they rank higher still, and the brain slowly forgets everything unpopular. The bonus is therefore hard-capped at half the RRF gap between rank 1 and rank 2 (1/((60+1)(60+2))/2 ≈ 1.3e-4). Because a page's RRF contribution falls monotonically with rank, the gap to rank 1 only widens further down the list — so the top result is unreachable by popularity alone, from any lower rank, with 50% headroom. Popularity can break a tie and lift a near-miss; it can never win an argument with evidence. That bound is asserted twice: as raw arithmetic on the constants, so changing either one fails loudly, and end-to-end through the real fusion code.
• The plan's own number was wrong, and the test caught it. The implementation plan specified a cap of 0.5/(K+1) ≈ 8.2e-3 and asserted it was smaller than the rank-1→rank-2 gap. It is about 31× larger — that cap would have let a rank-2 page with a good history outrank the best match, which is precisely the failure the cap exists to prevent. The prose was right and the constant was not; it was rederived and the rejected value is now pinned in a test that fails if anyone reintroduces it.
• "Your brain couldn't answer this" is a to-do list, not a metric. Questions that retrieved nothing, produced no answer, or got a 👎 are clustered by token overlap — deterministic, no model call on an interactive route — and surfaced in the Ingest tab as "⚠ 4 questions your brain couldn't answer," each with a Connect a source button two inches away. A knowledge gap is almost always a missing source, so it belongs where you fix it.
• Nothing here can break a chat answer. Recording the outcome runs in the streaming generator's tail, where an exception would swallow the terminal done line and leave the user watching a spinner forever, so every signal write is defensively wrapped and a dead Firestore costs a statistic and nothing else. Signals are stored per workspace under the same namespace as the rest of the app (queries truncated to 500 chars, never logged), and the prior can only re-score pages that already passed the ACL check — it never adds a candidate, so a page you can't see can't be resurrected by being popular with someone else.
• Dark-launched, and measured honestly. Behind the retrieval_feedback flag, default OFF: flag off means zero Firestore reads, zero writes and byte-identical ranking, confirmed by re-running the eval with all six scores at +0.00. With the flag on, the eval is also unchanged — a cold corpus has no usage history, so the prior is empty and contributes exactly nothing. That is the correct result and it is reported as such rather than dressed up: this phase's value shows up after real usage, not on a benchmark. 30 new tests, full suite green (563).

Graph memory — Phase 3: query auto-routing

• Every question used to get the same answer strategy. "Who owns billing?" and "why did we pick Postgres over DynamoDB?" ran the identical keyword-plus-vector fusion and both came back with eight cited pages. Retrieval now classifies the question first — lookup, conceptual, relational, impact or code — and that class sets the fusion weights, whether the typed-relation graph is traversed, and how many pages the answer may cite.
• The real fix was citing fewer pages, not finding more. The recorded baseline said citation precision was 0.27: roughly three of every four cited pages were noise, because retrieval filled its eight-page budget regardless of how many pages the question actually needed. A one-or-two-page answer now gets a three-or-four-page budget; only impact ("what breaks if…") keeps the full eight, because a blast radius genuinely is spread across many pages. Measured on the committed 60-question eval: citation precision 0.27 → 0.36, a 33% relative improvement, with recall@5 unchanged at 0.96 in every bucket.
• Routing re-weights, it never removes. Every route keeps the full candidate list; only the RRF weights, the triple source and the page ceiling change. A misclassification therefore degrades to the previous ranking rather than to a broken answer — and the neutral weights are algebraically the two-term RRF that shipped before, which is what makes "flag off is byte-identical" a property rather than a hope. There is a test that proves the refactored fusion reproduces the old output exactly.
• An honest result on the graph traversal. The plan called for relational questions to weight typed triples at 2.0 and traverse two hops. Built that way first, it hurt: a single triple then outscored the best keyword hit outright, costing 0.06 relational MRR and 0.11 impact MRR. Triples are now a tie-breaker rather than a retriever — weighted to promote a graph-justified page about three rank positions, one hop only — which is worth +0.03 conceptual MRR and +0.02 impact MRR and nothing more. That is the entire measured contribution of traversal to ranking, and it is reported as such.
• Relational questions get their evidence up front. A "why" question now opens its context with a KNOWN RELATIONS block — each line a subject→predicate→object fact, the page it came from, and the exact sentence that states it — so the model answers "why" with a citation instead of a paraphrase of a summary.
• Triples cannot become an ACL bypass. A page that enters the ranking only because a triple pointed at it has not been permission-checked by the keyword pass, so it flows into the same live-file ACL branch vector-only hits already use — one chokepoint, not two — and the traversal pre-filters against the live file as well. Both layers have tests; a restricted page reaches its owner and never a stranger.
• Dark-launched. Behind the query_routing flag, default OFF. Flag off, or any failure in classification or traversal, reproduces today's retrieval exactly — verified by re-running the Phase-1 eval with the flag off and confirming all six scores moved by +0.00. 27 new tests, full suite green (533).

Graph memory — Phase 2: typed relation triples

• The graph knew that two things were related; now it knows how. Until now every edge was untyped and page-level — a [[wikilink]] or an AST import told us A relates to B and nothing more, so "why did we pick Postgres over DynamoDB?" had no structure to traverse. Enrichment now also returns a relations array of subject→predicate→object facts the document actually states, each carrying the exact sentence that supports it. That evidence quote is the point: an LLM-extracted edge is noisier than a link, so every triple can always be made to show its work.
• It costs nothing extra to run. relations is one more field on the enrichment JSON we already send — the same zero-marginal-cost trick action_items shipped with — so there is no second LLM call, no new key, and no change to the BYOK model. Prompt, normalizer, merge-dedupe and the post-write hook follow that existing shape line for line.
• A closed vocabulary, and drift you can see. Twelve predicates (depends_on, owns, decided_by, chosen_over, replaces, blocks, caused_by, documents, implements, mentions, reports_to, part_of). An open vocabulary would make the graph unqueryable, so anything else coerces to mentions — and is logged, not silently discarded, because the only way to review the vocabulary quarterly is to know what the model kept trying to say. Chunked documents dedupe by the (subject, predicate, object) triple, so a fact stated twice is filed once.
• No new infrastructure, and no new way to leak a page. Triples live in the per-workspace _index/triples.json — the directory Impact and vector search already mirror to GCS — so durability, atomic writes and the mtime-keyed cache are inherited from vector_index.py rather than reinvented. ACL is checked at query time against the live file, never a cached permission, and the check fails closed: a permission tightened after extraction takes effect on the very next query, and a triple pointing at a deleted page is dropped as a stale row. There is a test proving a restricted page's triple reaches its owner and never a stranger.
• Additive to the graph, deliberately invisible to Impact. Typed edges join the existing links key in the same shape (plus typed, evidence and source_page), so the Map renderers and every downstream consumer are untouched. They are emitted as soft on purpose: impact.py walks only hard/code edges, so a model's guess about a relationship can never quietly change a blast-radius answer someone is about to ship against.
• Dark-launched and unable to block an ingest. Behind the relation_triples flag, default OFF — with the flag off triples.json is never created. Malformed, missing or junk relations mean zero triples and an ingest that still completes normally; the persist hook swallows and logs exactly like the action-filing path. 28 new tests, full suite green (506), and the Phase-1 eval re-run to confirm all six retrieval scores moved by exactly +0.00 — Phase 2 extracts and stores, and does not touch retrieval until Phase 3 routes to it.

Graph memory — Phase 1: retrieval eval harness + recorded baseline

• You cannot optimize what you cannot measure. The next three phases (typed relation triples, query auto-routing, retrieval feedback) are all optimizations of retrieval, so this phase builds the measuring stick first: scripts/run_retrieval_eval.py runs the real _gather_wiki_context over a committed fixture wiki (tests/eval/corpus/ — 40 pages of docs, Slack-style thread digests, tickets and code entity pages for one invented company) against 60 golden questions (tests/eval/golden.jsonl), and reports recall@5, MRR and citation precision per question type.
• Baseline recorded, and it says something useful. Keyword-only path: overall recall@5 0.96, MRR 0.84, citation precision 0.27. Recall is near its ceiling because the fixture wiki is 40 pages and retrieval returns up to 8 — so recall@5 is a regression guard, not a target. The real headroom is citation precision (three of every four cited pages are noise) and impact-question MRR (0.65, the worst bucket — "what breaks if…" answers are spread across service pages that share no vocabulary with the question). Phases 2–4 will be judged on those two, and that reading is written into PLAN_GRAPH_MEMORY.md so a later phase can't quietly move the goalposts.
• Offline and non-blocking on purpose. The harness never enables the vector flag, so no embedding API is called — it needs no key and no network, and it can't flake. The new retrieval-eval CI job runs on pull requests with continue-on-error and always exits 0: a retrieval regression should be visible on the PR, not a red X that trains people to re-run CI until it goes green.
• Zero production risk. Nothing runs at serving time and no enhanciar module was modified — this phase is new files plus one CI job. The harness copies the corpus into a temp directory and repoints both WIKI_ROOT constants (wiki_tools's and the copy server.py binds at import time), so it can never read or write a real wiki. 7 new tests, including one proving an acl:-restricted fixture page reaches its owner and never a stranger. Full suite green (478).

Action layer — Phase 8: landing page advertises Actions (sandbox only until go-live)

• New "From knowledge to action" section (landing/ActionsSection.jsx): a transcript card morphing into an approval queue with a Jira and a Linear card and one violet Approve CTA. Copy leads with the differentiator — "nothing happens without your approval." Hero lead gained the clause "…and it drafts the tickets you approve"; two FAQ entries added ("Does it act without asking?" → no; "Which tools?" → Jira/Linear + GitHub/Slack/Calendar). llms.txt updated.
• Ships on sandbox with the feature; held off main until the actions flag is turned on for real prod users — otherwise the marketing would advertise a feature prod visitors can't use (the exact overclaim class the July copy pass removed). Kept as its own commit so it's easy to hold back from a prod merge.

Action layer — Phase 7: hardening, MCP tools, runbook

• MCP: read + propose, never approve/execute. Two new MCP tools — list_proposed_actions() and propose_action() — let an external agent see the queue and file proposals, but approve and execute are deliberately not exposed: a human always approves in the app.
• Per-workspace daily action cap (ENHANCIAR_ACTIONS_DAILY_CAP, default 100/day) on executed actions — a guardrail against a runaway loop mass-creating tickets; a 429 tells you to approve the rest tomorrow. Lifted when unlimited_quota is on (sandbox/comped).
• Payload sanitization at store time (sanitize_payload): strips NUL/control bytes and caps string lengths so nothing can smuggle control characters into Jira ADF, Linear/GraphQL, or Slack mrkdwn. Every route already resolves the workspace ACL; secrets never enter previews or audit details.
• Retryable failures: a failed proposal keeps its payload editable — a material edit mints a new dedupe key and returns it to proposed, so a retry is a genuinely new action (no accidental double-create).
• Runbook at docs/actions.md (invariants, status machine, how to add an executor, ops/guardrails). 9 new tests. Full suite green (462).

Action layer — Phase 6: Workforce reports file proposed actions

• Workforce → queue. When a Workforce agent's run report ends with a "## Proposed actions" (or "## Actions") section, its bullet items are filed into the same approval queue as everything else (source="workforce", linked to the run's ledger entry) — the Weekly Brief / Docs Steward can now hand you one-click work, not just prose. Deterministic parse (bold prefix = title, dash = title/description split), no extra LLM call; best-effort so it never turns a good run into a failure.
• New shared filer enhanciar/actions/filing.py (file_items): flag-gated, dedupes against existing active proposals, defaults to the connected tracker, and swallows store errors — the reusable path for any producer of action items.
• Skills execution engine deferred (documented in docs/FUTURE_FEATURES.md): a SKILL.md is a human playbook, not a typed action DSL, so mapping free-text steps to executors reliably needs an intermediate representation — out of scope for v1. 7 new tests. Full suite green.

Action layer: the draft-first executors land (Gmail draft · Notion page · Zendesk internal note)

• Gmail draft (gmail.create_draft): creates a draft and never sends — sending stays a deliberate human click in Gmail. Added the gmail.compose scope (drafts only, not send); accounts linked earlier reconnect once, and a 403 surfaces a clear reconnect message.
• Notion page (notion.create_page): creates a NEW page under a page/database you pick (nothing overwritten); markdown body → paragraph blocks. A 403 explains the integration needs the "Insert content" capability and the parent shared with it.
• Zendesk internal note (zendesk.internal_note): adds a PRIVATE note (public: false) to a ticket — the requester is never emailed; a public reply stays a human action. Closed tickets (422) and role/group limits (403) surface clean messages.
• All three are draft-first by design (the trust posture for email/tickets), capability-gated, and render in the Actions tab. 9 new tests. Full suite green (471). This completes the Phase-5 executor set — Jira, Linear, GitHub, Slack, Calendar, Gmail, Notion, Zendesk.

Action layer — Phase 5: three more executors (GitHub issue · Slack message · Calendar event)

• GitHub issue (github.create_issue): new github_app.create_issue resolves the repo's installation token and POSTs the issue; targets() lists your connected repos. Needs the GitHub App's Issues (Read & Write) permission — existing installs must re-accept; a 403 surfaces a clear "re-accept permissions" message.
• Slack message (slack.post_message): new slack_app.post_message (chat.postMessage) posts to a channel; targets() lists non-archived channels. Added chat:write to the bot's default scopes — existing installs re-OAuth to grant it (a missing scope surfaces a "reconnect Slack" message).
• Calendar event (gcal.create_event): wraps the existing connectors.calendar.create_event so transcript follow-ups ("book a sync next week") queue like everything else instead of firing from the composer; resolves the workspace's Google account the same way schedule_assist does. Calendar write scope was already granted.
• All three are capability-gated (a clean "connect X first" error when unconfigured) and render in the Actions tab with the right icon/target picker. 10 new tests. Full suite green (448). Still to come (draft-first, need write scopes/verification): Gmail draft, Notion page, Zendesk reply.

Action layer — Phase 4: PRD mode (a spec becomes an epic + its stories)

• Doc-type sniff during ingest. A PRD-like document — detected by a PRD-ish title (PRD/spec/requirements/RFC/design doc) or ≥2 PRD-ish section headings (Goals, Requirements, User stories, Scope, Acceptance criteria…) — gets a second-stage LLM call that decomposes it into one epic and its stories, each with its own evidence quote. (Metered like every BYOK call; best-effort — a failure just leaves the flat action-item extraction in place.)
• Filed as a proposal tree. The epic becomes one ActionProposal and each story a child (parent_id → the epic proposal), source="prd". The Actions tab already renders these indented under their epic and approves them as a unit.
• Real epic links on execute. approve-batch creates the epic first, then injects its freshly-created key into each story before creating it — Jira's parent field (epic link) or Linear's parentId — so the tracker hierarchy matches the plan. New parent_key arg on jira.create_issue.
• 10 new tests in tests/test_actions_prd.py (sniff, breakdown normalize/reject, tree filing, Jira epic-link passthrough). Full suite green (438).

Action layer — Phase 3: the approval UI + a chat "Create ticket from this" button

• New Actions tab (frontend/src/components/ActionsPanel.jsx, under Ship). A queue of proposal cards: the tracker icon (Jira/Linear), the editable title + description, the exact evidence quote in mono (per DESIGN.md), and a target picker (project/team) fetched on demand from /api/actions/targets — so the card can't be approved until you've chosen where the ticket lands. Approve is the one violet CTA; Dismiss is a ghost button. "Approve all (N)" with a count confirm. PRD trees render as an indented epic→story group. Post-execute the card flips to its created state with a mono deep link (ENG-142 ↗). Designed empty / loading / error states; it polls only while something is mid-create.
• Chat entry point. Every finished agent answer gets an explicit "+ Create ticket from this" affordance (AgentChatV2) that files a pre-filled proposal (source="chat") and toasts a "Review" shortcut to the Actions tab. No auto-detection in v1 — an explicit button, zero false positives.
• Flag-gated end to end. The sidebar item only appears once /api/feature-flags/state resolves actions truthy, so prod (flag off) never shows a tab that would 404; the sandbox (flag forced on) shows it. New api.js helpers (actList/actPropose/actApprove/actDismiss/actEdit/actApproveBatch/actTargets). Frontend build green.

Action layer — Phase 2: ingest extracts action items (transcripts/PRDs → review queue)

• One more field in the same enrichment call — zero extra LLM cost. generic_pipeline._enrich_document already LLM-reads every ingested document; its JSON schema now also returns action_items: [{title, description, owner_hint, due_hint, evidence_quote, suggested_target}]. The map-reduce chunk path merges + dedupes them by title exactly like decisions.
• Ingest = remember + propose. When the actions flag is on and the source is docs-like (files/notes/PRDs, Notion, Drive, Confluence), each action item becomes an ActionProposal (source="ingest") linked back to its wiki page, with the evidence quote attached and the target tracker defaulting to whichever of Jira/Linear the workspace has connected. The job result gains actions_found and the stream emits an actions event so the UI can show "N action items found — review".
• Dedupe against reality. An item whose title matches an already-queued proposal is filed visible but dismissed ("likely already tracked") rather than re-proposed, so a re-ingest doesn't spam the queue.
• Never blocks ingestion. The whole extraction+filing path is best-effort: flag off ⇒ zero proposals; malformed LLM JSON ⇒ zero items; a Firestore/store error ⇒ swallowed — the ingest always completes and writes its pages regardless. 9 new tests in tests/test_actions_ingest.py. Full suite green (423).

Action layer — Phase 1: Jira + Linear create-issue executors (approve → real ticket)

• Two real executors. enhanciar/actions/jira_actions.py and linear_actions.py are thin ActionExecutor adapters: targets() lists the pickable destinations (Jira projects / Linear teams), render_preview() shows the exact field-by-field payload the tracker will receive, and execute() creates the artifact and returns its external id + deep link.
• Connectors grew a write path reusing their existing per-workspace credentials. Jira: create_issue (POST /rest/api/3/issue) + list_projects + a _markdown_to_adf converter — the inverse of the connector's ADF→markdown reader (headings, bullet/ordered lists, fenced code, bold/italic/code/links; everything else degrades to plain text). Linear: create_issue (GraphQL issueCreate, description passes through as markdown) + list_teams, with parentId support for epic→story trees.
• Capability-gated: an executor's targets/execute raise a clean "connect Jira/Linear first" error when the workspace has no credentials — surfaced by GET /api/actions/targets so the UI can prompt the connection instead of failing mid-approve.
• 15 new tests (tests/test_actions_jira.py, tests/test_actions_linear.py): mocked HTTP/GraphQL, ADF round-trip, missing-creds errors, executor validation + result shape, targets. Full suite green.

Action layer — Phase 0: proposal queue + executor registry + REST surface (behind the actions flag)

• New package enhanciar/actions/. base.py defines the ActionProposal shape (workspace, action_type, editable payload, source, source_doc_id, evidence, parent_id for PRD trees, dedupe_key, status, result/error) and the ActionExecutor protocol; __init__.py is a lazy string-keyed executor registry (same pattern as connectors); store.py does Firestore CRUD on users/{workspace}/proposed_actions/{id}.
• The two hard invariants live in the store, not the callers. Dedupe uniqueness — a non-terminal proposal blocks a dedupe-equal twin (a dismissed/failed one doesn't), so the same action can't be queued twice. Idempotent execution — mark_executing is a transactional approved → executing compare-and-set, so a retried or raced executor can never move the same proposal to executing twice (the "Early Access duplicate-charge" bug class, pre-empted). Illegal status transitions raise instead of silently passing.
• REST surface (server.py), all gated by the actions flag (404 when off), rate-limited and audited: GET /api/actions (filter by status/source), POST /api/actions/propose, PUT /api/actions/{id} (edit payload pre-approval), POST /api/actions/{id}/approve (approve_only or approve+execute), POST /api/actions/{id}/dismiss, POST /api/actions/approve-batch (PRD trees — parents before children), GET /api/actions/targets (per-executor destinations, surfacing capability gating). Execute fans out action.executed/action.failed to outbound webhooks. New flag actions in the catalog (default off); new action.execute rate-limit bucket.
• 22 new tests (tests/test_actions_store.py — transitions, dedupe collision + terminal exemption, transactional double-execute guard, edit/retry; tests/test_actions_routes.py — flag-off 404, propose/list/dismiss/edit, duplicate 409). Full suite green.

Sandbox = full test rig: every feature forced on, quotas + rate limit lifted (prod unchanged)

• Per-deployment env, declared in deploy.yml. The deploy workflow now computes a different env set per branch: main → prod (gated + capped as today); sandbox → an internal test rig with every user-facing feature flag force-ON via ENHANCIAR_FF_FORCE_* (verbose traces, graph keyboard nav, vector search, PDF/DOCX uploads, MCP card, workforce, code review, signups) and the waitlist forced OFF. Uses the force-override tier (checked before the shared Firestore global), so none of this touches prod. verify_plan is deliberately NOT forced — it exposes a real ₹10 Razorpay charge path and the sandbox shares prod data.
• No ingestion/LLM quota on sandbox. ENHANCIAR_FF_FORCE_UNLIMITED_QUOTA=1 lifts the daily AND monthly token caps at every enforcement point (usage._caps_for short-circuits to ∞ before the free-plan 0/0 paywall), so unpaid test accounts can ingest and chat freely. ENHANCIAR_REQUIRE_VERIFIED_EMAIL=0 lets test accounts in without a real inbox.
• Rate limit follows the quota. New unlimited tier in ratelimit.py: any user with unlimited_quota (i.e. everyone on the password-gated sandbox) bypasses the per-minute request bucket, so heavy end-to-end testing never trips a 429. Prod is unaffected — only genuinely comped users have the flag there. 3 new tests in tests/test_ratelimit_unlimited.py; full suite green.

Feature flags: deployment force-override + fail-closed waitlist default (sandbox can open without opening prod)

• New precedence tier in feature_flags.is_enabled: ENHANCIAR_FF_FORCE_<FLAG>. Checked right after the kill switch and before per-user / the shared Firestore global / the plain env var. The waitlist gate is a single Firestore doc read by BOTH the prod and sandbox Cloud Run services, and the global sat above every env var — so the sandbox was gated whenever prod was, with no way to override per-deployment. This force tier lets deployment identity out-vote shared-database config: the sandbox runs with ENHANCIAR_FF_FORCE_WAITLIST_MODE=0 (waitlist OFF, so you can actually use the app to test) while prod stays gated by the same shared global. The kill switch still beats the force override — it's the emergency off.
• Fail-closed default: waitlist_mode's code default flipped False → True. The only thing keeping prod gated is that one Firestore doc; if it were ever deleted, the site would silently open. Now the safe default is "gated," and the sandbox opens itself explicitly via its force env var. No prod behavior change (prod is gated by the global either way).
• 14 new tests in tests/test_feature_flags.py (force beats global/env/per-user, kill switch beats force, fail-closed default, value coercion); full suite green (374 tests).

Sandbox: password-gated preview at sandbox.enhanciar.in

• New module enhanciar/sandbox_gate.py + middleware in server.py. The open sandbox deployment (devhive-sandbox Cloud Run, mapped to sandbox.enhanciar.in) shares PROD Firestore/GCS and runs with the waitlist off, so it must not be world-open. Every browser-facing request now requires a shared access password before anything loads.
• Cookie gate, not HTTP Basic Auth — deliberately. The SPA authenticates its own /api calls with Authorization: Bearer <firebase-token> (frontend/src/firebase.js). A Basic-Auth challenge lives in the same header, so the browser's stored Basic credentials get dropped the moment JS sets a Bearer header — every API call would 401. A signed cookie (HMAC-SHA256(key=password), stateless across instances) rides alongside the Bearer header untouched. Unlocking shows a self-contained violet unlock page; a correct password sets an HttpOnly/Secure/SameSite=Lax cookie and redirects back.
• Machine endpoints bypass the gate — Cloud Run health probes, the OIDC-signed Cloud Tasks / Scheduler worker (/devhive/internal/*), and signature-verified inbound webhooks (GitHub / Slack / Razorpay) never carry the cookie and enforce their own auth. Browser navigations get the HTML unlock page; XHR gets a bare 401 JSON so the SPA's fetch() sees an error instead of parsing HTML. ?next= is sanitized against open-redirects.
• Off in production by construction. The gate is live iff ENHANCIAR_SANDBOX_PASSWORD is set on the deployment — prod never sets it, so the whole block is a strict no-op there (no environment-name coupling to get wrong). Sandbox responses also carry X-Robots-Tag: noindex, nofollow so the open twin can't outrank or duplicate enhanciar.in in search. 29 tests in tests/test_sandbox_gate.py (token forgery/rotation, exemption matrix, alias normalization, open-redirect defense, plus a real-server subprocess integration run); full suite green (360 tests).

Internal refactor: modularized LLM helpers and job runners

• Extracted the BYOK LLM-completion helpers (_call_llm, _litellm_completion, _gemini_completion, _parse_skill_json) from enhanciar/skills.py into a new enhanciar/llm_call.py; skills.py re-exports them for compatibility.
• Split enhanciar/jobs.py: job bookkeeping (create/get/status/events/subscribe, review store, executor singleton) stays in jobs.py; the job-execution runners (_run_job and the per-source pipelines, connector cursors, auto-skills debounce) moved to a new enhanciar/job_runners.py.
• No user-facing behavior change — pure relocation; full test suite green.

Connector-sync bug sweep: six incremental-sync correctness fixes

• Sync watermark no longer advances past unlisted documents. generic_pipeline.py now checks the connector's last_list_partial flag after listing: when a listing stopped early (rate limit / page cap — Zendesk sets this), the run's synced_at watermark is withheld so the next incremental run resumes from the same point instead of silently skipping everything the capped run never listed. Zendesk's full-backfill path also now marks itself partial when it hits its page cap, not just on a 429.
• Jira & Confluence incremental filters could skip a day of changes. JQL/CQL date-times are interpreted in the site/user's timezone, but we formatted the UTC watermark verbatim — on sites in timezones behind UTC, issues/pages updated between the two clocks were skipped forever. The updated >= / lastmodified >= stamps now subtract a one-day safety margin (re-listing is idempotent; skipping is not).
• Confluence pagination stopped after one page on clamped limits. The "short page = last page" check compared against our requested page size, but Confluence's search endpoints can clamp limit lower — now paginates on the API's own _links.next signal.
• Gmail incremental query was day-granular and timezone-skewed. after:YYYY/MM/DD is interpreted in the mailbox's local timezone; the watermark is now passed as exact epoch seconds (after:<unix>).
• Calendar incremental sync missed new/edited events. since was used as timeMin — an event start-time filter — so a meeting created today for next week was invisible until the window crawled up to it, and edits to past events were never re-ingested. Incremental runs now keep the full ±30-day window and filter with updatedMin (a modification-time filter) instead.
• MySQL ingest crashed on MySQL 8. _list_tables_mysql indexed result rows with lowercase keys, but MySQL 8's data-dictionary information_schema returns uppercase column names regardless of the SELECT's case — every MySQL 8 database ingest died with KeyError: 'table_schema'. Now uses the same case-tolerant lookup the table-introspection helper already had.

Removed the demo-data feature entirely

• The admin-controlled demo-data mode is gone. Deleted the sample dataset (demo_data.py), the internal DemoConnector and its registry entry, the POST /api/demo/ingest route, the demo-aware branch on GET /api/connectors (no more demo: true / all-connectors-connected), the demo entry in the generic job sources, and the demo_data feature flag from the admin catalog. Connector status now always reflects real credentials only.
• Frontend follows: the Ingest rail no longer treats demo mode as "everything connected", and the Monitor no longer special-cases demo jobs. WhatsApp sample content is now reachable only via the explicit WHATSAPP_DEMO_MODE=on env opt-in (the per-user flag hook was removed with the flag).
• The "Demo-data mode (admin-controlled)" row was removed from the feature catalog below; older changelog entries about building it remain as history.

Three frontend bug fixes: chat stream token loss, mid-stream chat-switch corruption, silent subscription→one-time downgrade

• Chat streaming dropped tokens split across network chunks. AgentChatV2.jsx parsed the /api/query NDJSON stream with a per-read chunk.split('\n') and no carry-over buffer, so any JSON event whose bytes straddled a TCP chunk boundary failed JSON.parse on both halves and was silently skipped — words/sentences went missing from long answers, and a split error event showed the user nothing. Now uses the same trailing-partial-line buffer idiom as DbGraph.jsx / the ingestion SSE reader (buffer += chunk, split, keep the last partial line for the next read), with a final flush on stream end.
• Switching chats mid-stream corrupted and persisted the wrong conversation. send() aborted any prior in-flight stream, but the sidebar's openChat and "New chat" (newChat) did not — so a still-running answer kept appending tokens into "the last agent message" of the newly opened thread, and the turn-finish persist effect then saved that polluted array under the wrong chat id. Both handlers now call abortRef.current?.abort() before switching threads, same as send().
• Checkout silently downgraded a subscription to a one-time order on backend errors. PaymentFlow.jsx's startCheckout caught subscription-endpoint failures with an inverted string match (!e.message?.includes('Subscription HTTP')): a backend 5xx without a JSON detail was swallowed and fell through to the one-time /order path — the user authorized a 30-day one-shot instead of the auto-renewing mandate they picked, with no indication — while genuine network errors (which the comment claimed should fall through) were re-thrown. Rewritten to branch on the actual HTTP status: only a 400 ("no Razorpay Plan ID configured") falls back to the one-time path; every other failure (5xx, network) surfaces as the "Could not open checkout" error.

Hybrid vector search — Phase 1 + 2 (index build + query-time fusion), behind a flag default-off

• New module enhanciar/vector_index.py. Chunks wiki pages at heading boundaries (~512 tokens, frontmatter kept on chunk 0 only, fenced-code-aware so a # inside a code block never gets treated as a heading), embeds server-side with one Gemini model (gemini-embedding-001, 768-dim, L2-renormalized — MRL-truncated vectors aren't pre-normalized), and stores a per-workspace vectors.npy + chunks.json manifest under the existing wiki/<uid>/_index/ directory — the same one impact.py already reads and wiki_durability already mirrors to GCS, so this gets durability for free with zero new mirroring code. Write-to-temp + os.replace + a per-uid lock means a query never reads a half-written index.
• Embed-on-write, two hooks (not one). upsert_page is only the user-edit path — the four ingest pipelines write via write_wiki_page directly, with bulk durability afterward. So: a fast single-page hook after the user-edit endpoint's upsert_page call, plus a content-hash-diffed reindex_workspace reconcile inserted into the post-ingest durability block in jobs.py (between the wiki backup and the artifact mirror, so the fresh index rides the same GCS backup). Both idempotent — unchanged content makes zero embedding API calls. A third call site reindexes after a connector is disconnected, since delete_pages_for_source removes files directly and bypasses the per-page delete hook.
• Query-time hybrid retrieval. _gather_wiki_context in server.py keeps its exact signature and return shape — so all six call sites (chat, REST API v1, MCP query/search_wiki, workforce, code review) get hybrid retrieval with zero edits elsewhere. Internally it now runs the existing IDF keyword scorer (extracted verbatim as _keyword_rank_pages) alongside a vector-similarity search when the vector_search flag is on and the workspace has ≥50 pages, and fuses the two ranked lists via Reciprocal Rank Fusion (k=60). Context is now assembled from the best-scored chunks of a vector-winning page instead of the whole page body — fixes the exact "one 20KB page eats the whole context budget" waste the old whole-page approach had.
• Security: ACL is enforced on vector hits too, against the live file, not a cached permission. The vector index itself is built without ACL filtering (checking every page's ACL at embed time would mean re-checking it again at query time anyway). So any page that enters the fused ranking only via the vector list is re-read from disk and passed through the same acl.is_page_visible check the keyword path already uses, before its content can reach chat context — an ACL tightened after indexing takes effect on the very next query, and a page deleted since indexing is silently dropped rather than erroring.
• Fails safe at every layer. No embed key configured, an embedding API error, a missing/corrupt index file, or the workspace being under the page-count threshold — every one of these falls back to the pure-keyword result, never errors the query. This is the defined degraded mode, not a bug.
• Gated by the vector_search feature flag (already existed, previously dormant/unwired) — default off. New self-serve POST /devhive/api/wiki/reindex-vectors endpoint for manual backfill/retry, same shape as the existing /wiki/backup. 26 new tests in tests/test_vector_index.py (chunking edge cases, idempotent re-embed, deletion/orphan-pruning, cache eviction, RRF ordering, ACL-on-vector-hits, and the full fallback ladder) — full existing suite (324 tests) still green.
• Before this is useful in prod: no server GOOGLE_API_KEY (or ENHANCIAR_EMBED_API_KEY) is currently set on Cloud Run — without one, every embed call silently no-ops and every workspace stays on pure keyword search regardless of the flag. Rollout is phased: this lands and can soak inert (flag off); Phase 2's dark-launch is a per-user flag override on a few internal/friendly workspaces; Phase 3 is flipping the catalog default to True once verified. See PLAN_VECTOR_RAG.md for the full design doc and phase breakdown.

Confluence confirmed shipped — status flipped P → S, restored on landing

• The prior pass had softened every Confluence mention on the landing page ("shipping soon") because the catalog flagged it status: P. Confirmed with the product owner it's actually live — flipped the catalog entry to status: S and restored Confluence in the Features "Sources" card, the ingest FAQ answer, and the landing.html FAQPage JSON-LD. WhatsApp stays "shipping soon" (still genuinely unconfirmed).
• Open question, not resolved here: Notion, Linear, Jira, Zendesk and the Databases connector are also flagged status: P in this catalog, yet all five are already marketed as fully live throughout the landing page (IngestViz, FAQ, Sources card) without any hedge — and nobody had flagged that before this pass. So in this catalog's actual usage, P does not appear to mean "don't market it," just "not yet battle-hardened internally." Left as-is since only Confluence's status was explicitly confirmed; worth a deliberate pass to reconcile what P vs S should mean for connectors specifically.

Landing page: broadened beyond engineering-only framing

• Positioning fix. Hero, Problem, Features and the crawlable SEO snapshot all illustrated the product exclusively with code examples ("blast radius," callers/callees, oauth.py:74), even though the ingestion side already spans Slack, Gmail, Notion, tickets and connected databases. Verified two things in code before writing copy — no invented claims: (1) enhanciar/impact.py's compute_impact walks graph.json links across the whole knowledge graph, not just the code graph, so impact analysis genuinely traces docs/entities/concepts, not only functions; (2) enhanciar/db_query.py executes real natural-language-driven, read-only SQL against a connected database, so "what's driving this month's revenue" is a real, working query path.
• Hero re-titled "Know what breaks before you decide" (was "…before you ship" — generalizes the verb beyond code deploys); lead paragraph and a hero-trust stat now name docs/data/deals alongside code.
• Problem section's illustrative question and silo chips now span engineering, sales and revenue-data examples, not only "how does auth work?".
• Features section header, the Impact-analysis card, and the cross-source "why" card (plus its chat example, which now pairs a code Q&A with a lost-deal Q&A) all broadened to make clear the graph covers any connected source, not code exclusively. Added a visible "Also works on: pricing docs · policies · support macros · deal notes" line under the Impact visual.
• FAQ gained a new first entry, "Is this only for engineering teams?", answered directly (no — product/sales/support/ops all work the same way). Mirrored into the landing.html FAQPage JSON-LD.
• Steps header "From git push to wiki…" → "From any source to a queryable brain…". Footer tagline and the bot-crawlable static snapshot in landing.html (h1, intro, bullets) updated to match — including meta/OG/Twitter descriptions and the Organization/SoftwareApplication JSON-LD, all previously said "codebase" specifically.
• The interactive live Demo (runs against the public karpathy/micrograd repo) and the Steps/CodeReview illustrative mockups remain code-flavored — rebuilding a second live demo backed by non-code sample data is a larger project, not a copy fix, and is called out here rather than silently left as an unstated gap.

Landing page: competitor-informed copy pass across every section

• Accuracy fix — Confluence overstated as live. The Features "Sources" card, the "Which sources can it ingest?" FAQ answer, and the landing.html JSON-LD FAQ all listed Confluence as an ingestible source today; the connector catalog has it at status: P (not yet proven with real users). All three now read "Confluence & WhatsApp shipping soon" instead. The IngestViz chip list was already correct.
• Hero re-weighted toward the actual differentiator. Competitor research (Unblocked, Glean, Guru, Onyx) found "cross-source / knows why" is contested territory — Unblocked's entire pitch is built on it. Blast-radius/impact analysis is not contested by any researched competitor. Headline "The affordable brain that knows why" → "Know your blast radius before you ship"; eyebrow, lead paragraph and one hero-trust stat (now "$0 · inference markup") re-ordered to lead with impact analysis and pricing, not the "why" hook. Footer tagline and the static SEO/bot-crawlable snapshot in landing.html updated to match (anti-cloaking: that block must mirror what users see).
• Metrics band sharpened. Two of four stats ("Cited", "12+ sources") were restated features, not numbers — weak next to competitors' quantified proof (Unblocked's 48%/83%, Glean's 110hrs, Onyx's 64% win-rate). Replaced with the two honest numbers Enhanciar actually wins on: $19 flat vs ~$50/seat at incumbents, and 1 graph grounding every answer/review/impact-trace.
• Security section reordered. "Permission-aware answers" (ACL enforcement at query time) promoted to first point — Glean leads its entire pitch on exactly this capability, and it was previously buried third.
• Pricing / legal consistency. Added an explicit "subscriptions auto-renew each cycle until cancelled; no free trial" line next to the currency note, so the pricing section can't drift out of sync with the just-updated Terms/Refunds pages the way "Cancel any time" alone risked.
• Sources listed once more: LogoStrip connector row now includes Calendar (shipped, was omitted).
• Full section-by-section review (competitor research: Unblocked, Glean, Guru, Swimm, Onyx) is in the session record; a comparison-strip section (Enhanciar vs. per-seat incumbents) and the Problem/Quote pain-beat resequencing were identified as good next candidates but not shipped in this pass.

Landing now targets solo developers and teams (not teams only)

• Headline de-narrowed — "The affordable team brain that knows why" → "The affordable brain that knows why" (H1 + footer tagline). SEO/OG/schema title "Company Brain for engineering teams" → "for developers and teams" (adds the "developers" keyword).
• Inclusive copy pass across the page: hero eyebrow "team-priced" → "solo & team"; lead adds "solo from $19/mo"; trust stat "Team-priced" → "Solo or team"; Problem "Your team's context" → "Your context" with a solo/future-self line; Security "Built for teams…" → "Built for code you can't afford to leak"; differentiator + FAQ now say "developers and teams" / "solo devs and small teams"; final CTA "What does your company already know?" → "…your codebase…". The $19 Solo tier already existed; the copy now reflects it.

Early Access Pass re-scoped: perks, not a queue-skip

• No longer instant/priority access. Paying for the Pass used to invite the buyer immediately and jump them to the front of the queue (position: 0). It no longer changes their queue position or status at all — a payer joins (or stays in) the exact same waitlist as a free signup and is invited in the same batch order.
• Discount changed from lifetime to 1 year. early_access_discount_expires_at is stamped at purchase and enforced at the actual checkout/subscription-creation step (razorpay_billing.create_subscription) via a new shared billing.early_access_discount_pct() helper — not just in copy. The ₹ credit toward the first subscription and the roadmap vote have no expiry.
• Price now tracks the solo plan. The Pass costs the solo plan's monthly price (billing.PLANS["solo"]["price_inr_monthly"]) instead of a separately hardcoded number, so the two can never drift apart.
• Duplicate-charge bug fixed. POST /api/waitlist/early-access/order now rejects (409) a second order for an email that already holds Early Access — previously nothing stopped the same email from paying twice for no additional benefit.
• New confirmation email replacing the old "You're in now" welcome — explicitly says the buyer is still on the waitlist and will be invited in the same batch order, listing only the credit/discount/vote perks.
• Updated: waitlist modal, landing hero subhead and FAQ copy (all previously said "skip the line" / "in immediately" / "lifetime 10% discount").

Rebrand: purge every visible "Enhanciar" → "Enhanciar"

• Removed the old "Enhanciar" brand name from everywhere it could reach a human: the agent system prompts (scout/worker/integrator/query — the chatbot could have called itself "Enhanciar"), the knowledge doc served to AI crawlers, outbound webhook headers (X-Enhanciar-* → X-Enhanciar-*), the crawler user-agent (EnhanciarBot → EnhanciarBot), the orphan brain3d page, and all docstrings/comments. The /api/brand endpoint now always returns "Enhanciar" and the dead brand_enhanciar sandbox-brand flag was removed.
• Left untouched (internal identifiers users never see): the Python package path enhanciar/ and /devhive/api routes (already aliased to /enhanciar/), DEVHIVE_* env-var names, and the Firebase/GCP project id devhive-2d0c7 (that's the real cloud project — it can't be renamed without migrating clouds).

Waitlist: stop showing the queue number + mock social-proof popups

• Joining no longer surfaces a position number — the modal success, the confirmation email (subject + body), and the in-app "you're on the list" gate all drop the "#N". Positions are still recorded server-side for the admin export; they're just never shown to joiners.
• The bottom-left social-proof toast now runs in a mock mode while real signups are sparse: randomized, anonymous "Someone just joined the waitlist just now / 5 min ago" popups on a 10–15s cadence (no fabricated names/cities/counts). One flag (MOCK_SOCIAL_PROOF) switches it back to the real /api/waitlist/recent feed.

Waitlist modal + paid Early Access Pass

• Every "Join the waitlist" CTA now opens a redesigned modal (nav, hero, pricing tiers, CTA band, code-review, demo) instead of an inline form — brand header, one email field, two actions, a highlighted Early Access card, and a polished success state.
• Free path — join the queue, invited in batches.
• Paid path — Early Access Pass, ₹1,999 one-time via Razorpay. Works before the payer has an account (the app is sealed): the order is keyed to their email, signature-verified server-side, then the email is invited immediately with the fee credited to their first subscription, a lifetime 10% discount, a roadmap vote, and a full-refund-before-use promise. A welcome email is sent on success.
• The 10% discount is fully wired into real billing — no manual setup. On first sign-in the entitlement is copied onto the user's billing record (surfaced in /api/billing/me). When they subscribe, the server lazily mints a 10%-off Razorpay plan variant (Razorpay has no offer-creation API, and fixed-price recurring plans can't be discounted at runtime — a discounted plan is the only API-driven way), caches its id in config/ea_discount_plans, and routes the subscription to it. Falls back to full price on any error so a sale is never blocked.
• Endpoints: GET /api/waitlist/early-access/info, POST …/order, POST …/verify. Orders persisted to waitlist_orders; the paid section only renders when Razorpay is configured. Both paths dual-fire analytics (early_access_click / early_access_paid).

App sealed to the public — invite-only, no sign-in route

• Hard "closed" gate. While the waitlist_mode flag is on, every app route (/login, /app, mobile) renders a full-screen "Enhanciar is in early access — join the waitlist" screen before any auth, with no Google sign-in button at all. The SPA decides this from the new public GET /api/app-open (fails closed, so a flaky read never exposes sign-in).
• waitlist_mode is now a first-class feature flag (added to the catalog, admin-toggleable) and has been armed in production. Flip it off from the admin Feature Flags panel to reopen public sign-up.
• Founder bypass: visit any app URL with ?founder=1 once — it persists in localStorage and restores the normal sign-in flow so you can get in and test. Obscurity-only: the real protection is the backend per-user waitlist gate, which still parks anyone not marked invited even if they bypass.

Landing: honest quotes, waitlist funnel analytics, social-proof toast

• Fabricated testimonials removed — the three invented customer quotes ("Mira K., Foundry Labs"…) are replaced with real, attributable quotes about the problem (HN on Confluence rot, HN on hallucinating AI wikis, martinfowler.com on agent context), each linking to its source. Pre-launch honesty that survives HN scrutiny.
• Waitlist funnel tracking — the form fires waitlist_click (submit pressed) and waitlist_join (server accepted) through the existing dh-track pipeline; the admin analytics funnel now reports page_view → waitlist_click → waitlist_join with conversion rates.
• Social-proof toast — bottom-left toast cycling REAL recent joins from the new PII-free public GET /api/waitlist/recent (60s server cache): "Someone joined the waitlist 5 min ago — #12 in line". No fabricated names/places, dismissable, respects prefers-reduced-motion, silent when the list is empty.
• Sign-in removed from the landing entirely — nav, mobile drawer, CTA band and footer all show only "Join the waitlist"; invited users enter via the link in their invite email (or /login directly).
• Pricing CTAs waitlist-aware — paid tiers now scroll to the waitlist form instead of opening a Razorpay checkout that would dead-end at the invite gate; prices stay fully visible.
• Hero reassurance microcopy ("One email when your invite is ready. No drip campaign.") and footer tagline aligned with the live positioning.
• GA4 on the landing — the marketing page reports to the dedicated enhanciar-67009 property (G-88V2VYNLBQ), kept separate from the in-app devhive-2d0c7 property; the waitlist form dual-fires waitlist_click/waitlist_join to GA alongside dh-track. First-party dh-track/Firestore stays the source of truth (dev audiences ad-block GA heavily); GA adds the Realtime view, channels and geography for free.
• P1 overclaims fixed — the proof-stat band no longer says "inference billed by us", "100% of answers cited to the source line", or "0 secrets reach main" (all refutable). Now: "$0 our markup on inference", "Cited — or it says it doesn't know", "100% of PRs secret-scanned before approval".
• P2 conversion content added — a founder note (solo Bengaluru builder, anti-$60K-enterprise framing), a 6-question FAQ (training/BYOK cost/sources/citations/access/data-exit) with matching FAQPage JSON-LD for AI-citation/GEO, and a price-anchor line under the pricing header (incumbents ~$50/user/mo + 100-seat min vs $19 self-serve).

Pre-launch waitlist + invite gate

• Waitlist capture on the landing page — hero and bottom-CTA email forms post to the new public POST /api/waitlist (per-IP throttled, idempotent by email). Joiners get a position-numbered confirmation email via the existing SMTP sender; entries live in a Firestore waitlist collection with source/referrer attribution.
• Invite gate on the app — while the waitlist_mode feature flag is on (ENHANCIAR_FF_WAITLIST_MODE=1), signing in without an invite parks you on a calm "you're on the list" screen (desktop + mobile). Rollout = flip the entry's status to invited (admin endpoint POST /api/admin/waitlist/invite also sends the invite email) — no deploy. Admins always pass; the status probe fails open so a flaky read never locks a real user out.
• Landing CTAs updated — "Get started"/"Open the app" become "Join the waitlist"/"Sign in" everywhere, including the static SEO shell.

Ingest panel remembers itself across tab switches

• Switching tabs no longer refetches the Drive listing. Tab panels are code-split and unmount on every switch, so the connector preview, the exact file count, and your browse-modal pages + selections were refetched/wiped every time you came back. They're now kept in a 5-minute session cache that survives unmounts (cleared on workspace switch) — return to Ingest and everything, including ticked files, is exactly where you left it.

SEO/GEO overhaul: AI crawlers can finally read the site

• Prerendered landing content — the homepage body was an empty React shell without JavaScript, invisible to GPTBot/ClaudeBot/Perplexity/CCBot (and slow for Google's first pass). The full product story (what it does, connectors, pricing) now ships as static HTML inside #root; React replaces it on mount so browsers see the app unchanged.
• /llms.txt added — the AI-crawler site summary convention; canonical plain-text description of Enhanciar.
• Sitemap fixed — dead /api-docs (404) removed, real lastmod dates.
• HEAD requests fixed — FastAPI's @app.get doesn't auto-answer HEAD; crawlers got 405 on every public page. Stacked @app.head on /, /privacy, /terms, robots, sitemap, llms.txt.
• og:image 983KB → 74KB (PNG→JPEG) — link previews unfurl ~13× faster.
• App Check off the marketing pages — its failing reCAPTCHA exchange was shipping 382KB gzip of dead JS + console errors to every anonymous visitor; it now initializes only on app pages.
• Schema touch-ups — Organization.logo now a square icon (was the wide hero banner), stale commented verification placeholder removed.

Drive browser: filters get a real loading state

• Switching a filter (or typing a search) now clears the stale list instantly and shows a spinner ("Searching your whole Drive…") while the server-side Drive query runs — before, the old rows sat frozen for a second or two and the swap looked broken. Rapid filter clicks now supersede the in-flight request instead of being ignored.

Drive browser: real filters + honest labels (no more "All · 100")

• Server-side filters in the file browser. The kind chips (📄🖼🎬📦) and a new filename search now query your entire Drive via the Drive API — picking "Videos" or typing a name escapes the newest-first wall (e.g. one bulk-download folder dominating every page) instead of only filtering the pages you happened to load.
• Labels stopped lying. The preview chip that read "All · 100" (which implied your Drive has 100 files) now reads "Newest 100 — a peek at your newest files; Browse & choose searches all 5,585". The ingest confirm's counts are likewise labeled as newest-100 samples, with your true total alongside.

Drive browser: see your real file count, pick exactly what to ingest

• Exact count, not "100+". The ingest panel now shows your true Drive total (folders/trash excluded, counted live via the Drive API, capped at 20k+).
• Browse & choose files → opens a paginated Drive browser — 60 files per page, newest first, rolling across every connected account — with per-file checkboxes, 📁 folder paths, select-all-loaded, and Load more pagination. Ingest N selected sends exactly those files to the pipeline (no listing, no kind filter — your picks win), with the media-model choice inline when images/videos are selected.

Drive ingest: the 100-file cap is gone — pick your pull size

• Why you only ever saw ~100 files: the Drive connector's first full ingest carried a hard v1 cap of 100 files ("keeps demos quick") — a real Drive with thousands of files silently truncated. The ceiling is now 1,000 per run (env-tunable via ENHANCIAR_GDRIVE_FIRSTRUN_CAP), and the ingest confirm dialog gains a "Files to pull this run" selector (100 / 250 / 500 / 1000, newest first — re-run to reach older files). The preview stays a fast 100-row peek by design; the ingest no longer shares its limit.

Drive ingest v2: confirm before ingesting, pick kinds, and Gemini watches your videos

• No more blind ingest. Start ingest on Drive now opens a confirm dialog with the type breakdown (📄 docs · 🖼 images · 🎬 videos · 📦 other, with counts) and checkboxes — untick anything you don't want pulled. The selection filters server-side, not just the preview.
• Videos + images are actually ingested now. Honest before/after: they used to be silently skipped ("no extractable text"). Opt in and each one is downloaded (size-capped), sent to the Gemini Files API on your own key, watched/viewed, and the analysis (summary, scenes with timestamps, spoken content, on-screen text) becomes the wiki page. You pick the model (2.5 Flash / Flash-Lite / Pro); hard caps keep cost bounded — 10 media files per run, 15 MB/video, 8 MB/image, ~₹1–3 per minute of video.
• Map: Drive gets its own filter chip. The knowledge Map's filter-by-source chips existed, but Google-pipeline pages never declared their source and fell into the "wiki" bucket. Pages now carry source: gdrive/gmail/gcal (+ drive_path), so after your next ingest you can isolate the Drive constellation — and its interconnections — with one chip.

Drive ingest keeps your folder structure

• Every Drive file now carries its folder path (📁 Projects/Purplle / release.apk) instead of flattening your whole Drive into one anonymous pile. The preview shows the path per row, and ingested wiki pages record it (drive_path metadata + a location line the summary model sees) — so search and summaries know where a file lives. Resolution is memoized per listing (one lookup per unique folder, not per file); "My Drive" root is omitted and failures degrade to the flat name, never a broken listing.

Fix: brand mark invisible on gradient chips (chat avatar & co.)

• The Enhanciar mark in the chat agent avatar was purple-on-purple — the logo rendered in its default brand purple on the purple gradient chip, leaving a barely-visible smudge. It now uses its white onDark variant there, and an audit fixed the same miss in five more gradient spots: the thinking indicator, onboarding + payment headers, and both mobile brand marks.

Scheduling chips: one combined chip + mixed messages answer both halves

• One chip instead of two. The separate time chip next to the booking button read as two controls; it's now a single 📅 test meeting · Tue 1:00 PM → chip — what you see is exactly what gets booked.
• Mixed messages work. "Schedule a meet to discuss the company and tell me what the company is about" now does both: the booking confirm fires first, and the detector extracts the leftover question and ships it to the Query Agent right after — the second half is never swallowed.

Chat scheduling: Enter now books the meeting (not a wiki question)

• Pressing Enter/Ask while a booking chip is live now opens the booking confirm instead of sending "schedule a meet tomorrow 1pm" to the wiki-grounded Query Agent — which has no calendar tools and could only reply "the context does not contain the answer". Cancelling the confirm dismisses the chips, so a second Enter reaches the agent as normal text (the escape hatch when you really meant to ask something). When the requested time is busy, Enter nudges you to the suggested free-slot chips instead of the dead-end answer. A successful booking also clears the composer.

Cost dashboard survives deploys + workspace switcher in the top bar

• Fix: Cost & quota reset to zeros after every deploy. The token meter stored usage in a file on the container's local disk — which Cloud Run throws away on every deploy or scale-to-zero, so the dashboard forgot your spend the moment the instance recycled. Usage now mirrors to Firestore synchronously on every LLM call (per-day + per-month + per-model + recent calls) and a cold instance rehydrates the meter from Firestore on first read — same durability pattern as the wiki. (The old fire-and-forget mirror thread also couldn't be trusted under request-based CPU billing.) Historic month totals recover from the old mirror; the daily chart fills in from today.
• Workspace switcher in the top bar. The active workspace (🧠 Personal / 👥 team) is now a dropdown next to the token meter — switching there is the same as "Make active" on the Workspaces page, and Chat/Wiki/Ingest follow instantly. No more digging into Account → Workspaces to flip brains.

Deploys ~3× faster: build in CI with layer cache + uv, ship by image

• The container now builds inside GitHub Actions (docker buildx, cache-from/to: type=gha) and Cloud Run deploys the pushed image — replacing gcloud run deploy --source, whose ephemeral Cloud Build workers reinstalled npm + pip from scratch on every one-line change (~6.5–7 min/deploy). With warm caches the dependency layers are reused, so typical deploys land in ~2–2.5 min.
• pip install → uv pip install in the Dockerfile (5–10× faster resolution) so even cold builds shrink. Images push to the same Artifact Registry repo, already governed by the keep-10/delete-30d cleanup policy.
• Hygiene: store-vision/, avatar-studio/, graphify-out/ gitignored so a manual --source deploy can never tar 2.5 GB of local working dirs into the upload.

Fix: Chat tab crashed ("l is not a function") after a Chrome update

• Newer Chrome makes scrollIntoView() return a Promise (scroll-completion spec). Our auto-scroll effect used a concise arrow — useEffect(() => ref.current?.scrollIntoView(…), [messages]) — which returned that Promise, so React stored it as the effect's cleanup and crashed the whole Chat tab ("TypeError: … is not a function") the moment the conversation updated. No deploy broke this — the browser changed underneath us. Fixed by bracing the effect body (nothing returned); audited every other concise-arrow effect in the app (the rest correctly return unsubscribe functions). Diagnosed by source-mapping the production stack + capturing the React component stack live in the browser.

Ingest preview: a peek, not a dump — plus Drive type filters

• The "Available to ingest" list now shows the first 8 items with a "+ N more — Start ingest pulls all of them" footer, instead of scrolling 100 rows of your inbox at you. Applies to every connector preview (Gmail, Drive, Notion, …).
• Google Drive preview gets type chips — All · Docs · Images · Videos · Other, with counts — powered by the file MIME type now carried through the connector's listing (DocRef.mime → /connectors/gdrive/available). Preview-only: the chips filter what you're looking at, never what gets ingested.

Ingest rail now shows Gmail + Google Drive

• Connected Google sources appear under "Connected sources" on the Ingest page. The rail's catalog still carried a stale "hidden until CASA audit" exclusion from before the BYO-OAuth-client model shipped — so a connected Gmail/Drive showed on the Connectors tab but not on Ingest. Added both (clicking opens the pull-preview + Start ingest panel). Google Calendar stays deliberately absent — it's answered live in chat, never ingested. Also hid the per-run "Enrichment model" picker for Gmail/Drive, whose ingest routes always use the account-default model.

Cloud Run bill ≈₹150/day → ~₹0: request-based billing + Cloud Tasks ingest

• Root cause: since Jun 28 the prod service ran with --no-cpu-throttling (2 always-on vCPUs billed whenever an instance is awake) — added so background in-process ingests wouldn't stall. Internet bots (robots.txt, WordPress scans, /.git/config probes) hit the public URL in ~19 of 24 hours, each knock keeping the instance billing ~15 idle minutes — ≈₹150/day serving nobody.
• Fix, part 1 — ingest moved into requests: switched the job executor to Cloud Tasks (queue was already provisioned): kicking off an ingest now enqueues a task that calls the OIDC-gated /internal/run-job worker, so the pipeline runs inside a request and CPU throttling can't stall it. Added a retry guard so a re-dispatched task never re-runs (and re-bills LLM tokens for) a job that already finished.
• Fix, part 2 — request-based billing: deploy now uses --cpu-throttling (+ --timeout=1800 to match the task dispatch deadline). CPU is paid only while serving; bot hits cost fractions of a paisa and fall inside the always-free tier. Idle-month Cloud Run cost: ~₹0.
• Invite emails made throttle-proof: the team-invite email used a fire-and-forget thread that request-based billing could starve mid-send; it now completes inside the inviting request (send_workspace_invite_and_wait).

Chat: instant sidebar thread + typed-in smart titles

• New threads appear in the sidebar the instant you hit send — optimistically, using your first line as a provisional title — instead of only showing up after the answer finished and saved. Once the turn saves, the lite-model smart title types itself in character-by-character (ChatGPT/Claude-style). The answer body was already real token-streaming; the title is a whole server-generated string, so its reveal is a client-side animation.

OAuth redirects now live on /enhanciar/ in production + final branding cleanup

• Google + Slack OAuth now round-trip on /enhanciar/ in prod. After registering the new redirect URI in the Google BYO client and the Slack app (old /devhive/… kept as fallback), the Cloud Run env vars GOOGLE_OAUTH_REDIRECT_URI and SLACK_REDIRECT_URI were flipped to /enhanciar/… — zero-downtime. The connector setup guide now shows the branded callback URL.
• Last user-facing "enhanciar" strings rebranded: the wiki-export download (enhanciar-<uid>.zip), the invoice PDF (enhanciar-invoice-*.pdf), and the metrics endpoint named in the knowledge doc (/enhanciar/metrics). Internal route decorators and the DEVHIVE_* env/token names stay as-is (never surfaced to users; the alias serves the branded paths).

Google connect is now bring-your-own-client only (no silent shared fallback)

• A workspace must add its own Google OAuth client before connecting. The backend used to silently fall back to Enhanciar's shared OAuth client when a workspace hadn't set up its own — but that shared client isn't CASA-verified for the sensitive Gmail/Drive scopes, so routing real users through it risked Google flagging or suspending it. The /api/google/install and OAuth-callback routes now gate on a new can_connect() check (own client required). Token refresh for already-connected accounts is deliberately untouched — that path keeps its shared fallback, so no existing connection breaks. Escape hatch: GOOGLE_ALLOW_SHARED_CLIENT=1 re-enables the fallback (local dev / a fully-verified client). The Connect button was already disabled without BYO; this closes the direct-API path too.

Branded URLs: /devhive/ → /enhanciar/ everywhere users see them

• User-facing URLs now say /enhanciar/. The legacy internal prefix /devhive/ no longer appears in anything a user (or third party) sees: frontend API calls (billing, impact), the Google/Slack OAuth redirect-URI defaults, Stripe checkout/portal return URLs, the CSP report-uri, and the process-map "compile skills" hint. The enhanciar_alias middleware already rewrites /enhanciar/* → /devhive/* internally, so both prefixes keep working — old links, bookmarks and the OAuth redirect URIs registered in Google/Slack stay valid. Production OAuth redirects have since been flipped to /enhanciar/… on Cloud Run (Google + Slack), with the old /devhive/… URIs kept registered as a fallback.

Google setup Step 4: paste all scopes at once

• One paste instead of five hunts. The Google connector guide's Step 4 · Add the data access (scopes) now includes a "Paste all scopes at once" copy field — the full scope URLs, comma-joined, ready for the Manually add scopes box in Google's "Add or remove scopes" dialog (paste → Add to table → Update). The per-scope chips stay for reference.

Calendar connector: dropped the ingest UI — it's live-only now

• Google Calendar no longer shows an "Ingest" option. Since chat answers calendar questions from a live fetch and the composer books meetings in real time, ingesting events into the wiki was redundant (and could go stale). The Calendar connector now just connects — granting the calendar access the live features use — and shows a short "answered live in chat" note instead of the sync preview / "Ingest →" button. Gmail and Drive still ingest as before.

Ask your calendar in chat — live, never stale

• Chat answers calendar questions in real time. Ask "what's on my calendar today?", "when's my next meeting?", or "am I free tomorrow afternoon?" and the answer is grounded in a live fetch of your Google Calendar (next 7 days) — never an ingested/stale copy. It mirrors the live-database path: a keyword gate spots the calendar question, the server fetches your events fresh (read-only) and injects them — with your calendar's timezone and the current time — into the answer context. So calendar ingestion is genuinely optional now: connect Google and just ask.

Faster app load: code-split the tab panels (−62% initial JS)

• The app paints far faster now. Every tab panel (chat, wiki, knowledge graph, DB graph, ER diagram, code tree, tables, connectors, settings, billing, workforce…) used to ship in one ~1.3 MB JS bundle the browser had to parse before showing anything — so "Loading Enhanciar…" lingered, especially on mobile. Each heavy panel is now code-split (React.lazy + a Suspense boundary in TabErrorBoundary) and loads its own small chunk only when you first open that tab. Initial JS to parse dropped ~1.29 MB → ~495 KB (gzip 372 KB → 151 KB); the biggest offender — the ER-diagram panel (68 KB gzip) — now loads only on that tab.
• Connectors show your Google Cloud project. The Google connector's "Connected accounts" now shows the project # (parsed from your OAuth client ID), with the full client ID on hover — so you can see which GCP project the connection runs under. (Google doesn't expose the friendly project name via OAuth.)

Meeting scheduler in chat: teammate availability + one-click booking

• The scheduling chip now books. Type "book a 30-min sync at 2pm with Ekta" and the composer resolves Ekta from your connected teammates, parses the time (lite LLM, in your timezone), then checks her calendar and books it on yours with an emailed invite — chips fill in live as you type: 📅 → 2:00 PM → ✓ Ekta free / ● Ekta busy.
• Conflict → open slots. If a teammate is busy at the requested time, the assistant computes slots that work for everyone that day and shows them as one-click chips (1:00 PM · 3:30 PM) — click one to book it. Availability uses Google freeBusy (busy/free blocks only, never event details) via each teammate's own token, so it only works for people who've connected their Google account to the workspace.
• LLM parses, tools execute. One lite-LLM call does the language understanding (who + when + title → member emails + RFC3339); the freeBusy check, slot-finding and event-create are deterministic server tools (LLMs are unreliable at time arithmetic) — so the whole parse→check round-trip is ~1-2s and feels live, with no flaky agent loop.
• New: calendar.events scope (sensitive → still no CASA; existing accounts reconnect once to grant it), free_busy / create_event / find_free_slots tools, a enhanciar.schedule_assist orchestrator, and POST /api/calendar/schedule (books only your own calendar, rate-limited, confirm-before-send).

Lite-model background tasks: smart chat titles + real-time scheduling detection

• Two fast/cheap models added to the picker: Anthropic Claude Haiku 4.5 (BYOK) and Ollama Cloud · gpt-oss 20B (free) — the missing lite tiers for those providers. Both route through the existing claude-* / ollama-* prefix logic; no backend change needed.
• Background work always uses the lightest model for your provider. New resolve_lite_model() maps each provider to its cheapest/fastest tier (Gemini Flash-Lite / GPT-4o-mini / Claude Haiku 4.5 / Groq 8B / gpt-oss 20B), independent of the (possibly heavy) model you picked for chat replies — so a title or a keystroke-detection never spends Opus/480B tokens. Falls back to a hosted lite model when you have no BYOK key. The Google path disables thinking (thinking_budget=0) for the biggest latency win; every path is token-capped and fail-soft.
• Smart auto chat titles. A new thread gets a 3–6 word Title-Case name from the lite model on first save (same language as your message), replacing the truncated first line — with the slice-80 as a fallback and a guard so save-per-turn never clobbers the good title.
• Real-time scheduling detection in the composer. As you type, an instant local regex shows a calendar chip the moment it sees "book a meeting / schedule a call / add to calendar"; a debounced (~500 ms), abortable lite-model call then parses the date/time + event title into chips above the box. New POST /api/compose/detect (rate-limited 20/min, fail-soft). Actually creating the event via the Calendar connector is the next step (TODO left in place).

Team workspaces, part 2: teammate invites + several people's Google accounts

• Invite teammates by email. Adding a member who already has an account adds them instantly; a new email gets a pending invite (single-use token, 7-day expiry) they accept after signing up — gated on a verified email that matches the invited address, so a leaked link alone can't join. Owners see pending invites (with revoke); invitees get an "Invitations for you" accept banner. Plan-gated by max_members.
• Connect several people's Google accounts into one brain. Each teammate runs their own consent; their account attaches to the shared workspace (a workspace_ids array) while tokens stay owned by them. The connectors iterate every member's account, so a team brain pulls everyone's Gmail / Calendar / Drive. The OAuth state carries a server-verified workspace id — a victim's consent can't be redirected into an attacker's workspace.
• One shared OAuth client for the whole team (optional). Instead of every member creating their own GCP project, an owner can set ONE client at the workspace level — teammates then just click Connect. Tokens record which client minted them (oauth_client_ref) so refresh uses the same one. The personal path is byte-identical to before.
• Email stays private — with an opt-in to share. A teammate's Gmail is readable only by them by default; a per-account "Share with team" toggle flips it to workspace-visible. Calendar & Drive are always shared. Team ingests show a "readable by all N members" confirm, and an owner can detach a teammate's account (they keep it personally).
• New: workspace_invites collection + accept/revoke routes, /api/google/accounts/{sub}/share, and workspace-aware /api/google/*. 22 new tests (invite email-match / single-use / expiry, multi-account merge + dedup, share-flag ACL, creds routing).

Team workspaces, part 1: per-source privacy + shared-brain ingest

• Email is private; calendar and everything else is shared. New per-source ACL policy for shared team brains: a teammate's Gmail is readable only by the person who connected it (owner-private), while Calendar, Drive, code, tickets, docs and chat are workspace-visible to every member. Enforced at query time in enhanciar.acl.
• De-frozen ACLs — invited teammates see existing pages. Connectors used to stamp the current member list onto every page at ingest time, so anyone added after an ingest saw an empty brain. Shared sources now emit an empty ACL (= workspace-visible), so membership changes take effect immediately, no re-stamping.
• Workspace-aware ingest. Every connector ingest route now honors the active X-Workspace-Id: Gmail / Calendar / Drive / Jira / Notion / Linear / Zendesk / Confluence / Slack / Files / Database can ingest into a shared team brain, funded by the triggering member's own credentials (creds-uid decoupled from the wiki namespace). GitHub-code / web ingest stays personal for now (that pipeline meters LLM tokens by namespace — a deferred split).
• Plan gating on invites. Adding a workspace member now enforces the owner's current plan's max_members (Solo 1 · Team 10 · Enterprise ∞) with a clear 402 — no more sharing one flat-priced brain with a whole team.

Google Calendar connector — meetings & events in the brain

• New Google Calendar connector (gcal). Rides the same bring-your-own-OAuth Google client as Gmail/Drive — one added scope, calendar.readonly (a sensitive scope, so it needs no CASA: Calendar isn't on Google's restricted list). Each event becomes one searchable, cited wiki page — when, where, organizer, attendees + RSVPs, join link, and the description. Recurring series are expanded into individual instances; cancelled events are skipped.
• Symmetric time window. Calendar is the one Google source where the future matters most, so the ±N days control pulls events from N days back and N days ahead (default ±30, up to 100) — last month's decisions and next month's agenda in one sync. New /api/ingest/gcal route + a "gcal" branch in run_google_pipeline, mirroring Gmail/Drive (days/max_items bounded server-side).
• Wired end-to-end. New connector card + calendar glyph; the BYO panel now serves Gmail/Drive/Calendar off one component (per-source nouns); a new calendar wiki category; monitor + wiki-explorer labels; and a CALENDAR_EVENT document type. 11 new pure-function tests (event→markdown, all-day vs timed, attendees/RSVP, recurring-instance doc_id round-trip, chunking).

Gmail/Drive: working "Ingest →", day/count filters, collapsing setup

• "Ingest →" now actually starts the sync. It used to bounce you to the Ingest page — which doesn't list Gmail/Drive — so nothing happened. It now calls the dedicated /api/ingest/gmail (or gdrive) route directly and points you to Ingest → Activity to watch.
• Choose how much to pull. New per-ingest controls on the Gmail/Drive panel: last N days and max N emails/files (blank = the default last-30-days, up-to-100). Threaded route → job → pipeline: days becomes a since cutoff, max_items caps the batch (both bounded server-side).
• Setup collapses once you're done. Steps 2 (credentials) and 3 (connect) now fold to "done ✓ · Show" once saved/connected — like Step 1 — so a connected panel is just your account, the preview, and Ingest.

Gmail/Drive "what will be ingested" preview + copy audit (wave 3)

• See exactly what the first sync will pull, before you run it. The Gmail/Drive connector panel now shows a live preview — real subjects (Gmail) and filenames (Drive) — of the threads/files the first sync would ingest, with the count and the 30-day / 100-item first-run scope spelled out. Backed by the read-only /api/connectors/{source}/available endpoint; Gmail/Drive list_documents now carry a preview title (thread snippet / filename).
• Copy audit wave 3. De-jargoned the ingest flow ("Cloud Tasks · cap-aware", "same-origin BFS", "embed", "AST parsing", "Verifier agent" → plain language), renamed the ingest "API mode" to Processing: Standard / Saver, and corrected the MCP setup snippets for Cursor (Tools & Integrations) and Claude Desktop (Connectors + the mcp-remote bridge for header keys).

Copy audit — jargon, contradictions, ghost buttons & stale setup guides (waves 1–2)

• Ghost buttons fixed. The "one more step" callout after connecting Notion/Slack told users to "hit Refresh, then ⚡ Ingest now" — neither button exists; the real one is Ingest →. Corrected.
• Operator error hidden from chat. A Vertex-AI IAM error (with a raw gcloud services enable… command) could surface in Chat to end users who have no GCP project — replaced with a plain "temporarily unavailable, try again" message.
• Encryption claim made consistent. Onboarding said keys were "AES-GCM"-encrypted while the landing page said "Fernet" — both now just say "encrypted" (no library name, no contradiction).
• Onboarding contradiction fixed. One line said "no key = no ingest," another said "ingest doesn't need a key." Now consistent: connecting sources is free; ingesting + chat need a model key.
• Stale landing claims corrected. "GitHub + Slack live, more coming / Jira, Notion, Linear next" now reflects reality — every connector is live.
• Pricing self-contradiction + nonexistent tabs. Code-review "flat per-seat" (vs pricing's "not per-seat") → "included in your flat plan"; "Sources tab"/"Feed tab" → the real Connectors and Ingest → Feed files.
• Setup guides re-verified against the providers' real consoles. Notion (it's an "integration" + "Internal Integration Secret," not a "connection"; link → notion.so/my-integrations), Zendesk (Apps & integrations → APIs → Zendesk API), Linear (Settings → Security & access → New API key), and Atlassian (tokens now require an expiry date). Also de-jargoned the ingest description, the database connection-string form, the WhatsApp sync button, and GitHub's "instance" copy.

Google connectors — reconnect handling + Internal-first setup guide

• Expired Google tokens now prompt a clean reconnect instead of failing silently. OAuth apps kept in Google's "Testing" publishing status have their refresh tokens revoked after ~7 days — so a personal-Gmail BYO connector would quietly stop syncing. google_app.get_fresh_access_token now detects the invalid_grant (revoked/expired) case, flags the account needs_reconnect, and raises a clear GoogleReconnectRequired with a fix-it message; a successful refresh clears the flag. The Gmail/Drive panel shows a ⚠ reconnect needed badge and a Reconnect Google → button on the affected account. 3 tests.
• Setup guide now recommends Internal-first. The BYO-OAuth guide leads with Internal (for Google Workspace orgs — no CASA, no review, connections never expire) and falls back to External + Testing only for personal Gmail, honestly noting the ~7-day reconnect. Labels updated to match Google's revamped "Google Auth Platform" console.
• Step 1 link fix. It pointed at /projectcreate (forcing a brand-new project); it now opens the console home so you can select an existing project from the top project-picker or create one.
• Guide corrected to the real console + de-jargoned. Rewrote the Google steps to match today's Google Auth Platform exactly — Audience (who can connect), Data Access (scopes — they're not on the old "consent screen," which is why users found no scope option), Clients (create the client with the redirect URI). Removed internal jargon ("CASA", "no review", console-naming trivia) that shouldn't ever be in end-user copy.

New — image & video capture (vision AI)

• Upload an image or short video → the brain reads it. The Feed/Upload panel now accepts images (png/jpg/webp/heic…) and short video (mp4/mov/webm…) alongside documents. A new media_vision module sends the bytes to the workspace's Gemini model (native image + video, inline within the 15 MB cap) and turns them into markdown: description + verbatim OCR for images, summary + transcript + on-screen text for video. That text flows through the normal enrich → wiki → graph → chat pipeline, so a screenshot or recorded demo becomes cited, searchable knowledge. Hooked into files.fetch(); falls back to a clear placeholder (never fails the ingest) if no vision model is configured. This is the ToS-clean version of "save a post to the brain" — the user supplies the media, we never scrape. 3 tests.

New connector — Confluence

• Confluence Cloud pages. A new ConfluenceConnector (the audit's #1 requested source) ingests every space/page the credentials can see: Confluence storage-format XHTML → markdown via a stdlib parser (headings, lists, links, emphasis; <ac:…> macros degrade to text), CQL-driven incremental sync, cross-links to Jira/GitHub/Linear/Notion, and the standard list→fetch→enrich→wiki path. It reuses the same Atlassian API token as Jira (confluence_site / confluence_email / confluence_api_token, encrypted at rest), with its own connector card, credential form and setup guide. Wired end-to-end (registry, generic sources, ingest routes, cred fields). 4 tests.

Audit follow-ups — Drive extraction, error states, dead-code removal

• Google Drive now extracts PDF & Word content instead of storing placeholders. gdrive._fetch_content returned _[PDF file — extraction deferred]_ as the page body for every PDF/Office file — silent content loss. It now downloads the bytes and runs the SAME pypdf / python-docx extractors the Files connector uses; files with no extractable text (images, spreadsheets, legacy .doc) are skipped rather than materialized as empty/placeholder pages.
• payment.captured webhook no longer defaults to the legacy 5M-cap "pro" plan. On an orphan capture (no order notes, no pending_plan) it now infers the tier AND period from the amount actually paid (annual → 365 days, not a flat 30), falling back to the cheapest real paid tier — never over-granting, never denying a paying user.
• Tables page shows an error instead of a blank screen. TablesBrowserV2 parsed error responses as JSON, so a 402/5xx rendered a silent empty "no databases" state; it now surfaces a real message (and a subscribe hint on 402).
• Chat stream aborts on unmount. AgentChatV2's SSE reader had no AbortController — a tab-switch mid-answer left the fetch running and writing into a backgrounded component. It now aborts on unmount / new send.
• Removed the dead demo branch from ConnectorDetailPanel. An unreachable-but-live demo path (SAMPLE DATA badge, "Ingest sample data" button, and 9 slugify-themed sample arrays) was a footgun that could leak canned strings to a paying user if ever re-enabled. Deleted the prop, every branch, and the sample data.
• WhatsApp is now an explicit "coming soon" card. Real WhatsApp needs the whatsapp-web.js sidecar deployed (a separate always-on service — deferred for launch). Rather than looking connectable, the card is badged coming soon, muted, moved to the end of the grid, and its CTA reads "Coming soon".

Pre-launch audit fixes — paywall & revenue integrity

• Landing/Settings subscribers were paying but staying paywalled. The intent=subscribe resume flow (App.jsx) and the landing pricing grid (Pricing.jsx) opened Razorpay Checkout with a success handler that just redirected to /app?billing=success — it never called /api/billing/razorpay/verify-subscription, so activation depended entirely on the async subscription.charged webhook. A customer coming from the marketing page could pay and land fully gated. Both handlers now verify the first charge synchronously (like the in-app PaymentFlow) and fall back to the webhook only if verify can't confirm.
• Code Review bypassed the paywall. POST /api/code-reviews/submit-pr was gated by require_user only (no enforce_token_cap), so a free/expired user could run unlimited LLM PR reviews for free. Added the cap dependency like every other LLM route.
• Token caps now fail CLOSED. On a transient billing/Firestore error, usage._caps_for fell back to the generous env-default caps (200k/day) — handing any user, including free/expired, a paid-tier quota and silently punching a hole in the hard paywall. It now returns (0, 0) on error (402 until billing is readable again).
• Subscriptions no longer grant access before the first charge. billing._ACTIVE_STATUSES included Razorpay's authenticated/created (mandate set up, not yet charged); with a future charge_at written as current_period_end, a user got paid caps before paying. Removed both — access now waits for a real active charge.

Connector polish: no more sample data + user-facing copy

• WhatsApp no longer leaks sample data in prod. whatsapp_app.demo_mode() auto-returned True whenever no WHATSAPP_SIDECAR_URL was set — so a production deploy (no sidecar) served the fake "nanoid maintainers / OSS Triage / Release Crew" chats, badged "SAMPLE DATA", to real paying users. Removed the auto-fallback: demo content now requires an explicit opt-in (WHATSAPP_DEMO_MODE=on or the admin demo_data flag). With neither, WhatsApp reports configured:false and shows an honest "coming soon" state instead of fake chats.
• Dev-facing connector copy rewritten for end users. The Gmail/Drive panel no longer mentions "restricted scopes", "CASA audit" or "to keep it free" — it now leads with the user benefit (your email/files stay under a Google project you own and control). The WhatsApp "sidecar not configured / set WHATSAPP_SIDECAR_URL … see README" message became a clean "coming soon", and the Gmail/Drive connector cards now read "connect securely with your own Google account".

CRITICAL: paywall was inert — `unlimited_quota` defaulted ON

• The paid product was effectively free. The unlimited_quota feature flag defaulted to True, and prod had no override — so usage._caps_for returned unlimited for everyone, enforce_token_cap never 402'd, and the entire no-free-tier paywall (free plan caps = 0) did nothing. Flipped the default to OFF: caps now enforce, so unsubscribed users are actually gated. Use unlimited_quota per-user to comp yourself for testing, never globally.
• ₹10 verify plan (flagged). Added a hidden verify plan (₹10) + a verify_plan admin flag. Turn the flag ON → a "Verify (₹10 test)" tier appears in Billing so you can run a REAL end-to-end payment and confirm money → active plan → paywall lifts; turn it OFF so customers never see it. Uses the one-time order path by default (no Razorpay Plan ID needed); set RAZORPAY_PLAN_ID_VERIFY_MONTHLY to also exercise the subscription path.

Launch-readiness: subscription sync-verify + payment-flow fixes

• Subscriptions now activate synchronously (no more "paid but paywalled"). The recurring path used to rely entirely on the async subscription.charged webhook — a delayed/misconfigured webhook left a paying user gated. Added verify_subscription_signature + confirm_subscription (razorpay_billing.py) and POST /api/billing/razorpay/verify-subscription: the client verifies the first charge on checkout success and the plan flips immediately (idempotent with the webhook; payment records merge by payment_id). Frontend also polls /api/billing/me as a fallback before declaring success.
• Checkout copy fixed: the dead "terms of service" link now points at /terms + /refunds, and the false "one-time 30-day pass — no recurring charge" line is replaced with honest auto-renew/cancel-anytime copy.
• Solo rate limit: the paid Solo tier was missing from ratelimit._PLAN_LIMITS and falling to the free 30/min default — now 180/min like Pro.
• Admin analytics deny-by-default: /api/admin/analytics failed OPEN when ENHANCIAR_ADMIN_UIDS was unset (any authed user could read cross-tenant funnels) — now 403s unless the caller is explicitly allowlisted.

Security hardening batch (from the review)

• F2 · connector secrets encrypted at rest. notion_token, linear_api_key, jira_api_token, zendesk_api_token and database_connections[].dsn (which embeds DB user:password) were stored in Firestore plaintext — now Fernet-encrypted on write (set_account_integrations) and decrypted on read in every connector (notion/linear/jira/zendesk/database + db_query). decrypt() passes legacy plaintext through, so existing rows keep working. 6 tests.
• F4 · CSP now enforced. Prod was sending Content-Security-Policy-Report-Only (zero enforcement). Default flipped to enforced Content-Security-Policy; instant revert via ENHANCIAR_CSP_REPORT_ONLY=1. (Dropping unsafe-inline/unsafe-eval via nonces is a tracked follow-up — needs an auth/payment test pass.)
• F6 · /api/demo/ingest now cap-gated (enforce_token_cap) like every other ingest route.
• Bug · OAuth state consumption is now atomic. google_app.consume_state read-then-deleted non-transactionally (a state-replay race); now a Firestore transaction makes each CSRF state token truly single-use.
• Admin-only fixes (local tooling): wipe.py now enumerates collections live (was a stale hardcoded list that left OAuth/Slack tokens + chat PII behind), and the Google-accounts loader no longer surfaces encrypted token blobs. Suite 223 green.

Security: close paywall bypass on /api/overview/regenerate

• A security review found that POST /api/overview/regenerate was gated only by current_uid, not enforce_token_cap — so a free/over-cap user could run LLM overview synthesis for free (unmetered), and with provider=google + no BYOK key it fell through to the operator-paid Vertex path. Now gated by enforce_token_cap + enforce_rate_limit like every other LLM route, so it 402s for unsubscribed users.

Durable per-user LLM usage (admin cost visibility)

• Usage now mirrored to Firestore. The token meter (enhanciar/usage.py) only wrote per-user counters to wiki/_usage/<uid>.json on Cloud Run's ephemeral disk — reset every deploy, unreadable cross-tenant, so the admin's per-user cost view always showed 0. meter.record() now also mirrors into a durable Firestore usage/{uid} doc (running totals + by_month + by_model, via atomic Increment). Fire-and-forget on a daemon thread so it never adds request latency or breaks metering; toggle with ENHANCIAR_USAGE_FIRESTORE (on by default). Covered by 3 tests (tests/test_usage_mirror.py). The admin Costs page reads it to show real per-model cost per user (BYOK tokens counted as user consumption, distinct from server-paid Vertex).

No free tier: value actions gated behind a paid subscription

• Trial disabled → hard paywall. New signups used to get a 14-day free trial of Solo (TRIAL_DAYS=14). Since Enhanciar offers no free tier, the default is now TRIAL_DAYS=0 — new users land on the free record (all caps 0). The existing token-cap gate (auth.enforce_token_cap) already returns a 402 when caps are 0, so ingestion and chat are blocked until the user subscribes. (An operator can still enable a trial via ENHANCIAR_TRIAL_DAYS.)
• "Subscribe to start" → Billing. Anyone can sign up and browse the app; the moment they try a gated value action (ask a question or start an ingest), the 402 now routes them to the Billing tab instead of a dead-end error. Wired in the chat path (AgentChatV2), the connector-ingest path (InputPortalV2), and the GitHub/website ingest path (App.jsx). Settings + Billing stay reachable throughout.

Removed the free tier from billing + removed demo data from Connectors

• No free tier. The billing overview no longer shows the ₹0 “Free/forever” plan anywhere. A user with no subscription now sees “No active plan” with a “Subscribe — {tier} →” CTA, and the plan grid lists only paid tiers (Pro / Team / Enterprise). Enhanciar is a paid product. (Note: the backend still uses a free caps record as the pre-subscription fallback — display only was removed; say the word to also revoke unpaid access.)
• Demo data gone from Connectors. Removed the “Ingest demo data” button and the demo mode from the Connectors tab (ConnectorsPanel): connectors now reflect only real connection status, never sample data. Dropped the demo state, ingestDemo, and the unused Sparkle import.

Gmail + Google Drive connectors, live again — via your own OAuth client (no CASA)

• Un-hid Gmail/Drive (previously hidden behind Google's restricted-scope CASA audit). Instead of one shared Enhanciar OAuth client that would need a ~$500–$4,500/yr CASA assessment, each workspace now brings its own Google OAuth client, kept in Testing (≤100 users) or Internal mode — both exempt from Google verification + CASA.
• Per-workspace OAuth resolution. google_app._resolve_client(uid) uses the workspace's own client if set, else the shared env client; authorize/exchange/refresh all thread the uid so per-tenant clients (and their refresh tokens) work. Creds stored on users/{uid} (client_id plain, client_secret Fernet-encrypted). New endpoints: GET/PUT/DELETE /api/google/oauth-credentials; install/callback/accounts now gate on is_configured_for_uid.
• In-app setup guide. New GoogleByoPanel walks the user through a 6-step Google Cloud setup (enable APIs → consent screen Testing/Internal → scopes → create client → copy the exact redirect URI → paste creds), then runs the normal consent flow against their client. Reference doc at docs/google-byo-oauth.md.
• 9 new unit tests (tests/test_google_byo.py): cred encryption round-trip, BYO-vs-env resolution, per-uid gating, authorize_url uses the BYO client. Verified the panel UI in an isolated browser preview.

Billing tab redesigned into a proper overview (+ clear upgrade path)

• Fixed the "weird" billing page. The Billing tab rendered a full-screen checkout wizard (.flow, height:100dvh; overflow:hidden) with its own brand header + "back to app" — nested inside the app that already has sidebar/tab chrome, so it double-stacked headers and forced a 100vh block inside a tab. It also always opened on a "You've outgrown the free tier" marketing hero, even for paid users.
• New in-tab Billing overview (BillingOverview in PaymentFlow.jsx): a Current plan card (name, price, Active/Free badge, renewal or "access until" date, token caps + GitHub installs), a Change plan / Upgrade grid (current tier marked, next tier up tagged "recommended"), and the payment history — all rendered like the Settings tab (.settings-shell/.bill-section), no full-screen takeover.
• Clear upgrade path. A prominent "Upgrade to {next tier} →" button on the current-plan card, plus per-card Upgrade/Downgrade actions that flow into the existing Razorpay checkout (Review → pay → confirmation, unchanged). Paid users also get a Cancel plan action. Verified in an isolated browser preview for both free and paid states.

Daily connector auto-refresh (opt-in, incremental)

• Opt-in daily sync. New per-workspace Daily auto-refresh toggle in Settings (default OFF). When on, a scheduled job re-syncs connected connectors (Notion/Linear/Jira/Zendesk/DB) once a day. Off by default because it spends the workspace's own BYOK tokens — GitHub already re-syncs on push separately.
• Actually incremental (new). The generic pipeline previously always re-fetched everything (since=None). Added a per-source watermark (users/{uid}.connector_cursors.{source}): run_generic_pipeline now threads a since, connectors list only docs changed after it, and the watermark advances on every successful ingest (manual too, so the first auto-sync is already incremental). Daily cost is proportional to what changed, not the whole workspace.
• Secured endpoint. POST /devhive/internal/connector-sync-due reuses the existing Cloud Tasks OIDC gate (require_cloud_tasks_oidc) — Cloud Scheduler hits it daily with an OIDC token; it finds opted-in workspaces, enumerates connected sources, and enqueues one incremental job each. A workspace with no LLM key just fails its jobs fast — no key is ever consumed silently.
• Cloud Scheduler wiring documented in docs/cloud-tasks-setup.md (§9). Covered by 6 tests (tests/test_auto_refresh.py): source enumeration, since threading, cursor round-trip, incremental vs manual job paths. Full suite 205 green.

Retrieval: entity router index, entity-scored search, abstention + recency (no embeddings)

• Robust entities in the router index. The enrichment LLM already extracts entities per doc; they were buried in body text. Now they're normalized at write time (_router_entities: drop generic nouns like “user/api/database”, drop the connector's own name, dedupe, cap 6) and promoted to entities: frontmatter. generate_manifest shows ≤3 per router line and builds an inverted Entity Index (proper noun → pages), skipping non-discriminative entities that appear on >½ the corpus.
• Entity-scored search. search_wiki now scores the entities: frontmatter at weight 6 (same as tags), so a named question (“Razorpay”, a person, a service) routes straight to the right page instead of relying on a weak body match — the single highest-leverage retrieval change.
• Abstention floor. With synonym expansion something always scores >0, tempting hallucinated answers. A top score below 4 (only weak content/synonym hits) now emits a LOW CONFIDENCE banner instructing the agent to say “not in the knowledge base” rather than guess.
• Recency tiebreaker. For time-sensitive sources (tickets/chats/mail), a newer page wins over an older one at equal relevance (via updated:), so the current ticket beats a stale one.
• Knowledge-graph-for-retrieval — decided against (for now). Devil's-advocated: the pretty graphify-out/ graph is 100% code (AST) with zero connector docs, so it structurally can't retrieve Slack/Jira/Notion; the runtime graph's edges are 95% shared-token “related” edges that return the same pages as keyword search. Not Obsidian-value at our scale (dozens of docs + ~1M ctx). Kept the summary+entity manifest routing as the spine; graph community_id re-rank deferred as optional.
• Covered by 7 new unit tests (tests/test_router_index.py); full suite 199 green.

Onboarding email: removed false “14-day trial” + hidden connectors

• The welcome email claimed a “14-day free trial … no card needed” in 4 places — Enhanciar has no trial (it's a paid BYOK product; the landing copy was already fixed, the email was missed). Replaced with honest BYOK copy: inference runs on your own key, billed at cost, never marked up.
• Also stopped advertising the hidden Gmail/Drive connectors (restricted Google scopes) — step 1 now lists what actually works: GitHub, Notion, Slack, Jira, Linear, or a database.

Correction: connector ingest DOES use the LLM · router index for connector docs

• Fixed wrong copy. An earlier note claimed connector ingest was “raw, no LLM, no cost.” That was wrong — the generic pipeline runs a compulsory per-document enrichment pass (summary · key points · entities) by default (ENHANCIAR_ENRICH_INGEST=1), which uses your model and costs tokens (no key ⇒ the run fails fast). The Ingest panel now says so, and the enrichment-model picker is restored (per-run override plumbed through /api/ingest/<source>). Also fixed the stale endpoint comment that caused the confusion.
• Router index for retrieval. The chat router leaned on _manifest.md, which only listed code entities/concepts — connector pages (Notion/Slack/Jira) were counted but never named or summarized, and it read the wrong frontmatter key (sources: vs the connectors’ source:). generate_manifest now reads both keys and emits a “Connector Documents” section listing each connector page + a one-line summary (from the enrichment). This is the no-embeddings retrieval win: the summaries already existed; now they’re indexed so questions route to the right source/pages.

Connectors ingest from the Ingest tab (source panel + Manage-connection link)

• Ingest connectors like GitHub/Website. Connected connectors now select as a source in Ingest → Add source. The panel shows what will be pulled, a Start ingest button, and a Manage connection → link. The connector page is now connection info + management; its “Ingest →” button just takes you to the Ingest tab with the source pre-selected.
• Honest about the LLM. Connector ingest is fetch-and-render — no LLM, no token cost, instant (stated right in the panel). So there’s deliberately no model/Individual-Bulk control there — those would do nothing. Model + Bulk stay on code/website ingest, where the LLM actually works. (Raw pages are still fully searchable in Chat; they just skip the code-style entity graph.)
• A11y pass (via the Vercel Web Interface Guidelines skill): secret/DSN inputs get spellCheck=off/autoComplete=off/aria-labels, disclosure toggles get aria-expanded, icon buttons get aria-labels, async previews get aria-live.

Connector page: progressive disclosure, page previews, direct deep-links

• Key box collapses once connected. The “Manage your key” section is hidden behind a “🔑 Manage key · change key” expander when a connector is already connected — the page leads with the useful stuff (status, what’s available, Ingest now), not a credential form you rarely touch.
• Preview a page before ingesting. Each item in “Available to ingest” is now clickable — it expands inline to show the document’s actual content (new read-only GET /api/connectors/<source>/preview), so you can eyeball a Notion page before pulling it in.
• Direct deep-link. Clicking a source under the Ingest page’s “Connected sources” now opens that connector’s detail page directly, instead of dumping you on the grid.

Prominent “share your pages with the integration” callout (the #1 Notion gotcha)

• Saving a Notion token isn’t enough — Notion only exposes pages you explicitly connect to the integration (••• → Connections → Enhanciar). Miss it and the ingest silently pulls 0. Now, when a connector is connected but nothing’s available yet, the page shows an amber step-by-step callout spelling out exactly what to do — for Notion (connect each page) and Slack (invite the bot). No more “it says connected but nothing happens.”

Connector page: prominent “Ingest now” + “Remove connection” (deletes its data)

• Ingest is now the obvious action. “⚡ Ingest now” moved out of the buried key-management box into the connected status banner as the primary button (with “View N in Wiki” beside it once pages exist). The lower box is now just “Manage your key.”
• Remove connection — and its data. New “Remove <connector> connection” button clears the saved credentials AND deletes every page ingested from that source (Wiki/Map/Chat), then regenerates the manifest. It warns first with the exact page count (“deletes the 12 pages ingested from Notion — can’t be undone”). New POST /api/connectors/<source>/remove + wiki_tools.delete_pages_for_source; covers API-key connectors, Database, Slack and WhatsApp. 3 tests.

Hidden Gmail + Google Drive connectors (pending Google verification)

• Gmail and Drive use restricted Google scopes (gmail.readonly, drive.readonly) that can’t be opened to the public until a full Google verification + CASA security audit clears. Rather than show connectors that access_denied for everyone but a handful of test users, they’re hidden from the Connectors grid and the Ingest rail. One-line revert (a hidden flag) once verification lands.

OAuth connectors: “Connect” actually starts sign-in; no operator button

• Gmail / Drive / Slack “Connect” now works. It used to jump to the Ingest tab; it now starts the provider’s consent flow directly (fetches the authorize URL and redirects). Button reads Connect Google → / Connect Slack →.
• Removed the confusing second button. The operator-only “Open Google Cloud credentials” / “Open Slack API” link is gone from the end-user view — that setup is admin-only and is now a small “self-hosting only” note. End users just click Connect and grant consent.
• Guides for these are trimmed to two steps (“Connect → pick account”), with a “≈ 30 sec” badge.

Connector page: preview what will be ingested · no dead “View in Wiki”

• See what will be pulled before ingesting. When a connector is connected but nothing’s ingested yet, the page now lists the pages available to ingest (live from the source) with a note “these will be pulled when you click Ingest now.” New GET /api/connectors/<source>/available lists documents read-only (no fetch/ingest); DocRef gained an optional title, populated for Notion from its search results.
• “View pages in Wiki →” only shows when there are pages. It used to appear even at 0 ingested and dump you on an empty Wiki. Now it shows the count (“View 12 pages in Wiki →”) only when pages exist; otherwise the banner just points to “⚡ Ingest now.”

Settings is now tabbed with a left-rail index

• Settings was one long scroll of ~12 sections. It’s now a left-side index with five tabs — Account, Models & API, Connections, Security, Data & danger — showing one group at a time. No more scrolling to hunt for a setting.

Save buttons now reflect saved state (no more “Connect” on a saved key)

• Connector key form. The button was always “✓ Connect” even with a key already saved. Now it’s state-aware: Connect X (disabled until you type) → ✓ Connected (disabled, nothing to change) → Update X key (only when you type a new value). Same for the Database “Save & connect” button.
• Settings API keys. The “Save preferences” button stayed live even when nothing changed. Now it’s disabled until you edit a key or the base URL, reads ✓ Saved when clean, and a hint clarifies the model choice saves automatically.

Per-connector document list — “here are your N Notion pages”

• See what each connector pulled in. A connected connector’s page now lists the actual pages ingested from it (title, type, and an “open ↗” link to the source), with a live count — not just a jump to the whole Wiki.
• Backend. New GET /api/connectors/<source>/documents scans the workspace wiki for pages tagged source: <name> in frontmatter (already written by the connector pipeline) and returns them, workspace-aware and cold-pod-safe. Helper list_pages_for_source in wiki_tools; 2 new tests.
• Empty state nudges “Run ⚡ Ingest now to pull your pages.”

Connector keys live on the connector page · cleaner connected state

• Enter the key on the connector itself. The Notion / Linear / Jira / Zendesk / Database credential form now renders inline on each connector’s page (new ConnectorCredentialForm) — no more bouncing to Settings. Settings shows a short “moved to Connectors →” pointer instead.
• Once connected, the how-to disappears. The setup guide only shows before you connect; after that the page switches to a manage/ingest view with a “View pages in Wiki →” action and a “Manage your key” panel (update or disconnect).
• Fixed the black status chip. The status badge is now green when connected and a light neutral pill otherwise (it was a leftover dark GitHub-panel style).

Connector setup guides — clearer steps, fixed buttons, current Notion flow

• Notion how-to matches Notion’s new UI. Notion renamed “integrations” → “connections”; the guide now walks the real flow (New connection → name it → Access token auth → Create connection → copy the ntn_ token) and links to notion.so/developers/connections.
• Fixed the two-button confusion. “Connect →” used to jump to the Ingest tab and the guide said “paste into the field above” — but the token field lives in Settings. The primary button is now “Add key in Settings →” and routes to the actual field; the “Open <service>” link is now a secondary/ghost button so there’s one clear primary action.
• Every step is now “bold action + plain where-to-click hint,” with a friendly intro and a “≈ N min” badge. Applied across Notion, Linear, Jira, Zendesk and Database; Slack reframed so end-users see connect→authorize→invite-bot with the app-creation steps moved to an operator note.

Land on Home after login · per-run ingestion model · Individual vs Bulk (Gemini Batch) mode

• Login lands on Home. A genuine sign-in (signed-out → signed-in) now routes to the Home tab; a plain refresh still restores your last tab, and deep links (post-GitHub-install, billing) still win.
• Pick the ingestion model per run. The Add-source form has an Ingestion model dropdown (defaults to your account model, override just for this run) — Gemini Flash/Flash-Lite/Pro, Ollama, Groq, OpenAI, Anthropic. Backend threads a model override through /api/ingest → job → resolve_ingest_model(uid, override).
• Individual vs Bulk API to cut cost. New API mode control: Individual = today's live, full-price, fastest path; Bulk = the page-generation stage goes through Gemini's Batch API for ~50% of the token cost. Batch is async, so we poll the job and emit a real progress bar (batch_progress events: done/total + state) rather than token streaming. Gemini-only; other models auto-fall-back to individual. New enhanciar/gemini_batch.py (submit inline requests, poll batches.get, order-preserving results, per-item failures → null). Choose it per-run in the form or set a default in Settings → Models.
• Tests: tests/test_gemini_batch.py (6 — ordering, progress, per-item failure, padding, Gemini-gating). All prior suites green.

Secret-safe ingest + live Firestore proven on a real repo (trekngo)

• Credential dumps are never ingested. A repo that commits a Firebase Admin service-account key or a .env used to have that key material read into the wiki (the AST extractor previews the first 500 chars of every .json). New guard in repo_tools.py (_is_secret_filename / _redact_secret_content) applied across both file-reading paths (read_files_in_directory, read_single_file) and the AST extractor (ast_tools.py): *firebase-adminsdk*.json, *service-account*.json, .env (but not .env.example), *.pem/.p12, id_rsa are skipped, and any file whose content carries a -----BEGIN PRIVATE KEY----- / "type":"service_account" fingerprint is redacted. Verified: zero key material in the wiki after a full ingest.
• Real Firebase projectId, not Vercel's. extract_firebase_config used to grab the first literal projectId in the repo — which is often .vercel/project.json's prj_… id. It now derives the id from the unambiguous authDomain/storageBucket, skips Vercel prj_ ids, and reads the browser-public NEXT_PUBLIC_/VITE_/REACT_APP_ Firebase env vars (public by design) when the config is wired through process.env. On trekngo it now resolves trekngo-new + the public web apiKey.
• Collection names normalized. Workers sometimes label a collection "Firestore: Trek Cards"; _clean_collection_name strips that so the REST read hits the real id, and file-shaped mislabels (trekDataFallback.json) are dropped from the schema.
• End-to-end proof. Local ingest of the trekngo Next.js app: 12 workers, 200 wiki pages, hybrid detection found 12 Firestore collections (TrekCards, Blogs, Orders, All Homestays, …) read from code. A live firestore_query against the detected project returns real rows (TrekCards → name, price, difficulty, slug, …). 3 new tests lock the extractor + normalizer (9 in tests/test_db_merge.py).

Hybrid DB extraction — workers read the schema out of your code, so the brain can query Firestore live

• LLM + deterministic, merged. The regex detector (deps, config files, connection strings) is now the floor; each ingestion worker also emits a data_sources block (DB type, connection hint, env-vars, and the schema — collections/tables + fields — read straight from the code it's analysing). merge_detected() in enhanciar/db_detect.py enriches matching types with that schema, adds LLM-only types, and never duplicates or clobbers regex data. Security: the worker captures connection metadata only — it's instructed to never copy a private key, service-account JSON, password, or API secret; it refers to them by env-var/file name.
• Code-derived schema powers live queries. code_schema()/resolved_schema() in enhanciar/db_query.py union the fields the workers found and store them in _detected_sources.json. This is the only way to know Firestore collections/fields (Firestore has no live introspection), so the query agent finally knows what it can ask for.
• Firestore live path. For a connected Firebase project the query agent now picks a collection from the question + code schema (a cheap flash-lite step) and reads it via the public Firestore REST API using the committed projectId/apiKey — read-only, no service account. SQL DSNs (Postgres/MySQL) keep the SELECT path. Not-connected still short-circuits to the wiki-only answer.
• Tested. 6 new mocked tests (tests/test_db_merge.py): regex floor preserved, LLM enriches matching type with schema, LLM-only type added, no duplicate types, worker data_sources block parsed, code-schema fallback when no live DSN, and the Firestore path uses the config (not SQL). All prior suites still green (db_query 5, dedup 9, uiSpec 8).

Live-data query tool — the brain queries your connected database on demand

• Read-only live queries. New enhanciar/db_query.py: when a database is connected (Settings → Database, stored as database_connections), the Query Agent fetches live rows relevant to the question and prepends them to the answer context — so "show me winter treks" reflects current data, not just the wiki summary. Strictly read-only: a guard refuses INSERT/UPDATE/DELETE/DROP/stacked statements; every query gets a LIMIT.
• The small agent picks the query. A cheap gemini-2.5-flash-lite step translates the question + the live DB schema into one SELECT (or NONE) — gated behind a connected DB, so it never runs or costs anything otherwise.
• Graceful fallback. No DB connected → the whole path short-circuits and the answer comes from the wiki exactly as before (verified). Covered by 5 mocked tests (tests/test_db_query.py: read-only guard, SELECT rows, write refused, LIMIT enforced, schema introspection). Live end-to-end (“winter treks → cards”) activates once you paste a DSN in Settings; combines with Generative UI to render the rows as a card grid/table.

Generative UI — chat answers can render components (cards, tables, charts)

• The query agent picks the component. When an answer is better shown as a component, it appends one fenced ```ui JSON block (type: card_grid / table / stat_row / bar_chart) — same LLM call, no extra request, so no added cost. Wired into both query paths (BYOK stream + server-Gemini) via a shared _GENERATIVE_UI_PROMPT.
• Declarative + safe rendering. New frontend/src/components/GenerativeUI.jsx + pure parser uiSpec.js: the frontend extracts the block, strips it from the prose, and renders a typed React component (no model-authored HTML). Falls back to plain markdown when there's no block or it's malformed. Wired into desktop + mobile chat.
• Verified end-to-end: “list the trekngo website pages as cards” renders a real card grid with the raw JSON hidden. Parser covered by 8 passing unit tests (uiSpec.test.mjs).

Auto-detect databases in ingested code → connector suggestions + nav badge

• DB detection at ingest. New enhanciar/db_detect.py deterministically scans an ingested repo (package manifests, config files like firebase.json/prisma/schema.prisma, connection strings, ORM/driver imports) and identifies the databases it uses — Firebase, Postgres, MySQL, MongoDB, Supabase, Prisma, Redis, SQLite, DynamoDB. Saved to wiki/{uid}/_detected_sources.json during the pipeline (skipped for web scrapes). Verified: correctly flags Firebase in the trekngo repo from its deps + firebase.json/.firebaserc.
• Connector suggestions. New GET /api/connectors/suggestions returns detected-but-unconnected DBs. The Connectors page shows a "Detected in your ingested code — connect to query it live" banner with each DB + its evidence + a Connect button; the Connectors sidebar item shows a notification badge with the count. This is the bridge to real-time data: connect the DB the code already uses, then the brain can query it live.
• Auto-connect from the code (no manual DSN). Detection now extracts the connection, not just the type: the committed Firebase web config (projectId/apiKey — public by design) and any credentialed connection string hard-coded in the repo (postgres://user:pass@…, DATABASE_URL=…). Those show a one-click "Connect (auto)" that saves the connection (POST /api/connectors/db/auto-connect); databases whose secret is (correctly) gitignored show "Add credentials". Firestore reads use the config via REST. So for repos that carry their own creds, live queries work with zero typing.
• Files hidden from the primary nav (developer-only raw file tree; redundant with Wiki/Map for the team-knowledge use case).

Ingest UX: overall progress bar, Ingestion History, roomier Map

• Overall progress bar on the Activity/monitor — a single weighted bar (scout 15% · workers 55% · integrator 30%) with a live Processing X/Y files · N% label and green/red end states, above the event feed.
• Ingestion History — the old "Recent ingests" panel is now a readable history of every source you've fed in, with an icon + clean label + kind (🌐 trekngo.com · Website, 📦 owner/repo · GitHub repo, 🔗 Skills/connectors) and status; robust to the old mislabeled jobs (detects web: sources regardless of stored source_type). Raised the fetch window 8 → 25 so older sources still show.
• Map spread out — stronger node repulsion (‑30 → ‑95), longer links (40 → 70), more collision padding, and a wider community ring (300 → 440) so the galaxy breathes instead of clumping into one dense ball.

Ingestion cost controls (Gemini spend was 98% of the cloud bill)

• Thinking disabled by default. Gemini 2.5 Flash bills reasoning tokens as (expensive) output. Ingestion tasks — structured JSON extraction from AST facts, reformatting facts into a fixed page template — are deterministic and don't need chain-of-thought, so get_generation_config() now sets thinking_budget=0 (override with ENHANCIAR_THINKING_BUDGET).
• Page-writer downshifted to Flash-Lite. Writing one wiki page from given entity JSON is mechanical and is the bulk of ingest LLM calls, so the page-writer now uses gemini-2.5-flash-lite by default on Gemini (override ENHANCIAR_PAGEWRITER_MODEL; BYOK non-Gemini models are left untouched). Extraction/scout still use full Flash.
• Combined with the disjoint-scoping fix (fewer workers + ~135 fewer page-gens per repo), a full repo ingest is now dramatically cheaper. Batch API (‑50%) was considered and rejected — it makes ingests take hours, unsuitable for the interactive flow.

Root-cause fix: eliminate duplicate extraction at the source (disjoint domain file-scoping)

• The deeper cause of duplicates: the Scout routinely emits overlapping domain paths — three domains at /src/Containers, another at /src, etc. The AST pre-pass parsed each domain's whole directory, so a parent-path domain and its children all parsed the same files, and every worker independently extracted the same entities. Cross-domain dedup then cleaned up the mess after the fact.
• Fix — parse each file exactly once. The existing most-specific-path-wins partition (_domain_file_sets) is now actually enforced: extract_ast_facts_for_directory takes an include_files allow-list scoped to the domain's exclusive file set, and a domain whose files were all claimed by a deeper/first-seen sibling is skipped entirely (no wasted LLM call, no hallucinated entities). The worker prompt gained a matching “only these files” scope note.
• Measured on the same repo: raw extracted pages dropped 244 → 92 and duplicates-to-merge dropped 117 → 3; true primary-file duplication reached 0 (axios.js/reducer.js/StateProvider.js each a single page). Also faster + cheaper — 3 redundant workers skipped and ~135 fewer page-generations. Covered by fixture tests for the disjoint partition + AST scoping.

Fix duplicate wiki pages: cross-domain entity dedup by file path

• Bug: the Scout sometimes assigned the same directory to two domains (e.g. core-frontend-logic and ui-components-pages both got /src); each worker extracted the same files under slightly different names, so the Integrator wrote them under different slugs — reducer.js and StateProvider.js ended up as 4 pages each, firebase.js/axios.js/utils.js/index.js as 3 each (129 entities where ~60–70 were distinct).
• Fix: Stage 3 now pools extracted items across all domains and dedups entities by repo-relative file path (clone-prefix …___<branch>/ stripped) before any page is generated. Colliding entities merge deterministically: longest details wins, list fields (dependencies, aliases, keywords, …) are unioned. src/index.js vs functions/index.js correctly stay separate; concepts/flows dedup by slug; web-scrape items are unaffected.
• Basename-disambiguation key: workers emit paths inconsistently — partial (axios.js), absolute (/var/.../src/axios.js), or import-style (../../firebase). A pre-pass learns which basenames appear in more than one directory: unambiguous ones key on the basename (so bare axios.js ≡ src/axios.js merge to one page), while a basename in multiple dirs keeps its directory (so the three real index.js files — src/, functions/, url-alphabet/ — stay separate). Import-refs fall back to slug keys. Result, verified live: true primary-file duplication went from 33+ → 12 → 2 across refinements (reducer.js ×4→1, StateProvider.js ×4→1, axios.js ×3→1); the remaining “2” are legitimately-distinct files. Merge ratios climbed each run: 244→127 (merged 117).
• Also saves LLM calls — duplicate pages are no longer generated at all. Covered by 9 unit tests in tests/test_dedup.py. Page-gen concurrency lowered to a gentler default 3 (ENHANCIAR_PAGEGEN_CONCURRENCY) so the parallel write burst doesn't trip free-tier BYOK keys into rate/quota blocks.
• Fail loudly + resumable: a mid-run API failure (e.g. a Gemini 403/quota block) used to be swallowed as a warning — the job reported “complete” with a partial brain and cleared its checkpoints. Now the Integrator/Workers halt on any failure, surface the real error (job status → failed with the message), and preserve the worker checkpoints so re-running the same ingest resumes instead of redoing the expensive extraction.

Ingestion reliability: fix truncated scout/worker output + robust JSON parsing + content-gen integrator

• Root-cause fix — output truncation. max_output_tokens had been lowered 32K→8K as a Groq free-tier workaround. But Gemini 2.5 Flash is a thinking model — reasoning tokens draw from that same budget, so on real repos the scout's domain-plan JSON and large worker extractions were cut off mid-string (Unterminated string), collapsing ingests into a single full-repo fallback domain / 0-page domains. Restored to 32K via ENHANCIAR_MAX_OUTPUT_TOKENS (env-overridable). Diagnosed from real job-event scout outputs: 916c/1327c truncated vs 2.3–3.5K clean.
• Integrator is now content-generation, not one long tool-call conversation. Each wiki page is generated in a fresh, short context (no accumulating history) and written to disk in Python — fixes weak free-tier models degrading/stalling across a long domain, and pages now generate in parallel (bounded) instead of sequentially.
• Robust JSON extraction for scout + worker output: brace-matching span + json.loads(strict=False) to tolerate literal newlines/tabs in string values, so a stray control char no longer drops a whole domain.
• Web ingests now labelled website in the jobs panel (were mislabelled github_code — the ingest endpoint never set source_type for web: sources).
• GitHub connector works on localhost for one-time ingest when the App credentials are present — installations + clone are outbound GitHub API calls; only push-triggered auto-sync needs a public webhook. Verified end-to-end: connector-driven ingest of a repo into a brain that already held a website, producing one merged knowledge base.

Free Ollama Cloud models for ingestion (bigger free budget than Groq)

• Added Ollama Cloud · gpt-oss 120B and Qwen3-Coder 480B to the Active-model picker (Settings). Both are OpenAI-compatible via the same custom-endpoint path; selecting one auto-fills the base URL https://ollama.com/v1, so you only paste a free key from ollama.com/settings/keys (no credit card). Chosen because they are strong tool-callers — unlike Groq's Llama, which frequently errored with "Failed to call a function" during the agentic ingestion loop.
• Why over Groq: Groq's free tier is a hard 100k tokens/day cap that a single multi-source ingest exhausts. Ollama Cloud's free tier is GPU-time based (session windows reset ~5h, weekly caps) with no daily token cliff, so full repo+website ingests actually complete.
• Concurrency control decoupled from the TPM limiter. New ENHANCIAR_LLM_CONCURRENCY env caps parallel workers independently of the token/min throttle — set to 1 for Ollama Cloud (free = 1 concurrent model) without invoking the prompt-trimming machinery those big-context models don't need. The earlier ENHANCIAR_LLM_TPM sliding-window token limiter (for Groq's 12k tokens/min) remains available and off by default so production Gemini is untouched.

Free Groq models selectable for ingestion (no more burning paid Gemini tokens)

• Added Groq · Llama 3.3 70B and Llama 3.1 8B to the Active-model picker (Settings). Groq's free tier (no credit card, OpenAI-compatible) now powers the multi-agent ingestion pipeline — the backend already supported it via the custom-endpoint path; this exposes it in the UI and auto-fills the Groq base URL (https://api.groq.com/openai/v1) when a Groq model is chosen, so you only paste the free key. Timely because Google cut the Gemini free tier 50–92% in Dec 2025.

Map source filter: merged nodes light up under every source they came from

• The graph now carries sources_all per node, and the Galaxy Map gained source-filter chips (Github / Web / Slack…). Selecting one dims everything except nodes that source contributed to — and a brain-merged entity (e.g. Payment Box Component from both github and the website) stays lit under both chips. The node detail panel lists all a node's sources with a "· merged" marker.

Brain-like multi-source merge: one wiki page enriched by every source (no more silent overwrite)

• Ingesting the same entity from two sources (e.g. a GitHub repo and the live website) used to silently overwrite one page with the other — real data loss. Now write_wiki_page merges them into a single memory: unified frontmatter (all sources + file_paths, an enh_sources list) and per-source attributed sections. Re-syncing one source replaces only its own slice (idempotent), so no duplication. A same-source update still overwrites in place; merge failures fall back safely and never break an ingest.

Fix — Files tab: human-readable file details instead of empty "—" cards

• The file detail panel read fields (symbols/loc/in_edges/out_edges) the code-graph never returns, so every stat showed a dash. It now derives real facts from the graph's edges (import relationships) and file_tree (functions/classes, language): a plain-English one-liner, Defines / Language / Imports / Used-by cards, a "What's inside" symbol list, and clickable Imports / Used-by file links. Tree emoji swapped for Phosphor file/caret icons.

Fix — Map node click: rich info for every node, no more "couldn't load" error

• Clicking a file node (e.g. App.js) used to fetch a wiki page that doesn't exist — the encoded slash in ids like file::functions/index.js hit the SPA fallback (HTML, not JSON) and showed a red error. Now file nodes skip the fetch and show their real graph metadata: connections, module, repo, criticality and file paths, with an "Open in Files" action.
• Entity/concept/flow nodes keep their full wiki page (Summary, Purpose, Overview) and now also show the fast-facts block above it. Non-JSON responses are treated as "no page yet" instead of an error.

Map is now Galaxy-only with cluster legend, node info drawer, micro-animations

• Galaxy is THE Map: the Galaxy | Constellation | Force toggle is gone — the Map tab is the Galaxy view only (the Constellation canvas lives on in the Workforce tab; the 1.1k-line legacy force view is deleted).
• Stronger clustering: per-community anchor forces pull same-cluster nodes toward centroids on a ring, and within-cluster links pull harder than bridges — clusters now visibly clump while staying organic.
• Micro-animations: gentle per-node ambient drift (±1.5px sinusoidal), hover radius easing to 1.3x over 120ms, and a very slow whole-galaxy rotation (~0.1°/s) that pauses on interaction and while the drawer is open. All motion respects prefers-reduced-motion and pauses when the tab is hidden.
• Info-rich page: a slim stats strip ("161 pages · 405 links · 8 clusters") replaces the pill row, and a right-side panel shows totals + a cluster legend — click a legend row to zoom the camera to that cluster and dim the rest.
• Node click → real info: clicking a node slides in a detail drawer (160ms ease) that fetches the node's wiki page, renders the title, a category chip and the page markdown (no raw UID chips anywhere), with an "Open in Wiki" button; nodes without a page get an honest "No wiki page for this node yet."

Galaxy view: Obsidian-style light-theme knowledge map (new default)

• New Galaxy view on the Map tab — a canvas-rendered force-directed galaxy of the whole brain: every node as a community-colored dot with organic starburst clustering, hairline edges, and Obsidian-style labels that fade in on hover/zoom. Light theme per DESIGN.md. Toggle is now Galaxy | Constellation | Force with Galaxy the default.

AI Workforce v1 (flagged): charter agents + run ledger + Ask the council, and the last emoji leave the chrome

• New Workforce tab (feature flag workforce, default ON): your agents as hubs on the shared night-sky constellation, their runs as chain stars (done runs ring in the agent's accent). Empty state = papercraft robots + a "Seed your first two agents" CTA that creates Docs Steward (reviews recent wiki pages, flags stale + duplicate entities — e.g. 'App Component' vs 'app-main-component' — and drafts merge suggestions) and Weekly Brief (what changed in the brain this week, as a shareable brief).
• Agent drawer: editable charter (mission / agenda / constraints, saved via PUT /api/workforce/agents/:id), append-only run ledger with rendered markdown reports and honest outcome_notes (never fake metric deltas), and a "Run now" button — one bounded BYOK model step per run, no cron.
• Ask the council: 3 personas answer independently → each reviews the others anonymized (A/B/C) → chairman synthesis with [[category/name]] citations. Stage outputs stored as subcollection docs; a rough token estimate is shown before you convene. New /api/workforce/* endpoints (agents, seed, run, ledger, meetings, council), all flag-gated.
• Emoji sweep, wiki + chat: Wiki sidebar rows now use per-category Phosphor icons (entities→Cube, concepts→Lightbulb, flows→FlowArrow, services→Gear, infra→Database), source chips and Edit/Save buttons drop their emoji; Chat's "Suggest skills"/"My skills" chips get Brain/BookOpen icons and the raw-UID scope chip now reads "workspace" (uid kept in the tooltip).

Constellation Map: the knowledge graph as a night sky, plus chat suggested prompts

• New Constellation view on the Map tab (default): a dark night-sky canvas (#0c0d10) with a drifting particle core ("the brain"), your graph communities as color-accented hubs on a radial ring, and their top members fanning outward as constellation chains ("+N more" expander per cluster). Click a hub to zoom into its cluster (giant ghosted watermark behind), ‹ › carousel cycles clusters, double-click resets. Deterministic layout (no live force sim) + d3-zoom on a single <g> for 60fps panning. Empty brains get a designed telescope empty-state with an "Ingest a source" CTA.
• Constellation | Force toggle: the legacy D3 force view is one click away and unchanged; the choice persists.
• Chat empty state: a fresh conversation now offers 4 suggested-prompt cards (product overview, auth, recent changes, risky code) — click to ask.
• Fix — chat banner layout shift: the "AI Code Review" callout now paints at a fixed height from the first frame, so the chat pane no longer jumps after load.
• Emoji sweep: Skills, Impact and Connectors panels swap the last emoji glyphs in buttons/headers for Phosphor icons per the design contract.

App redesign phase 1: grouped sidebar, Home tab, real deep links, brand illustrations

• New IA: the 9-tab top nav + "More" overflow is now a grouped left sidebar (Home · Chat · Knowledge · Data · Sources · Ship · Account) with Phosphor duotone icons — zero emoji in the chrome. 10 dead V1 components deleted.
• New Home tab: greeting + brain status ("80 wiki pages, ready to answer") + an activation checklist (ingest → first question → connect a source) with CTAs.
• Real per-tab URLs: /app/graph, /app/wiki etc. — deep-linkable, refresh keeps your place. IBM Plex Sans replaces Inter.
• Brand assets generated with Higgsfield (Nano Banana, hex-locked to #1C525D, papercraft style): landing/OG hero, Map empty-state (telescope), Workforce empty-state (robots) — in frontend/public/assets/. OG share image now uses the papercraft hero.

Routing & redirect fixes: connectors land back where you left, no more base-path 404s

• Connector OAuth redirects fixed: GitHub, Slack and Google callbacks now return to the app via a base-path-aware _spa_redirect() helper (ENHANCIAR_SPA_BASE, default /enhanciar) instead of a bare /app. Combined with new last-tab persistence, connecting a source lands you back on the Connectors tab, not Chat.
• SPA stopped stripping its own base path: the route normalizer rewrote /enhanciar/… to bare /app//login, breaking refresh and deep links in dev. New appPath()/stripBase() helpers in api.js; all 7 replaceState sites fixed.
• Landing links fixed + false trial copy removed: Sign in/Get started now point at /enhanciar/login; every "14-day trial" claim replaced with honest BYOK copy (there is no trial).
• Tab survives refresh: active tab persists in sessionStorage (real per-tab URLs land with the upcoming IA restructure).
• Fix — infinite "Loading skills…": a StrictMode-unsafe aliveRef pattern silently dropped every fetch result after the dev double-mount; fixed in SkillsPanel, AgentChatV2 and UploadPanel.
• Dev parity: Vite proxy now forwards /devhive/api/* (Impact, billing) so those panels work on localhost; connector setup copy shows branded /enhanciar/api/… URLs (both prefixes served).

Website connector rebuilt Firecrawl-style: real markdown, sitemap crawling, JS rendering

• Rewrote enhanciar/web_scraper.py as a Python port of the open-source Firecrawl pipeline (we cloned and analyzed the actual source). Same public interface (scrape_to_directory), completely new internals; the Scrapling dependency is gone.
• Real markdown out: pages now convert to structured markdown (headings, lists, tables, absolute links) via Firecrawl's exact main-content rules — its 42-selector noise-removal list with the #main force-keep escape hatch, srcset/lazy-load image resolution, and its post-processing (skip-to-content link removal, base64 image stripping). Because the ingest chunker splits on markdown headings, scraped pages now chunk semantically instead of by 4000-char windows.
• Sitemap-seeded crawling + robots.txt: the crawl seeds from robots.txt Sitemap: entries and /sitemap.xml (index recursion, gzip, lenient XML parsing for real-world broken sitemaps), then BFS-extends with on-page links using Firecrawl's filter order (protocol → depth → extension blocklist → same-origin with www-stripping → fragment rules → robots.txt). Cross-host entry redirects (apex → www) rebase the crawl like Firecrawl's originUrl rewrite.
• JS-rendered pages now work: Firecrawl's waterfall rule ported — if main content is empty on a 2xx response, the page escalates to headless Chromium (Playwright, waitUntil: load, ad-domain blocking) before accepting nav-only fallback text. Verified live: trekngo.com's client-rendered /treks grid now yields all trek cards; the old scraper got nav + footer only.
• Richer frontmatter: each page records url, title, description, language, og:site_name, published/modified time, favicon, status code and scrape timestamp — YAML-safe quoted.

Stop re-cloning needlessly: SHA-skip on re-ingest + no-clone Overview rebuild

• Skip the clone when nothing changed: a re-ingest now first runs git ls-remote (one cheap network call, no clone) and compares the remote commit SHA to the last-ingested SHA (stored in the incremental state). If they match, it skips the clone entirely — "No new commits, brain already current." Big saving for webhook re-ingests / repeated syncs that previously re-cloned just to discover nothing moved. New remote_head_sha() in repo_tools.py; save_state now records head_sha.
• No-clone Overview rebuild: the product Overview only needs the stored graph.json + one LLM call — it never needed the source. New POST /api/wiki/overview/regenerate rebuilds it from the existing brain (no clone, no re-ingest), using the user's BYOK key. generate_overview() now accepts an explicit key for serving-time calls.

The brain now knows WHAT a project is — auto product Overview + CPU-throttling fix

• Product Overview page (NEW): ingest now synthesises a plain-English product-overview page from the extracted entities — leading with the product type and domain (e.g. "Trek n Go is a trek/tour-booking website that …") instead of only code structure. New generate_overview() in wiki_tools.py, run at the end of ingest (and cheaply on incremental re-ingests). The chat agent is told to read it first for "what is this / what does it do / overview" questions, so the brain answers the obvious question well.
• Fix — ingests no longer stall (CPU throttling): Cloud Run's default throttles CPU to request time, but ingests run as background tasks — so large ingests (the integrator's many LLM calls over minutes) crawled and stalled, producing brains with code-file nodes but zero wiki pages. Set --no-cpu-throttling (applied live and added to deploy.yml so it sticks). Ingests now complete and generate their entity/concept/flow pages, so chat actually has content to answer from.

Chat history persistence — conversations survive refresh + a real thread list

• Bug: chats lived only in memory, so a refresh wiped them and the sidebar was a "coming soon" placeholder.
• Fix: durable per-user threads in Firestore (users/{uid}/conversations/{id}) via new GET /api/chats, GET /api/chats/{id}, POST /api/chats/save, DELETE /api/chats/{id}. The Chat sidebar now lists your past conversations (click to reopen), "＋ New chat" starts a fresh thread, each turn auto-saves, titles come from the first question, and the last-open thread is restored on refresh (via localStorage + Firestore). Threads are trimmed to the last 100 turns to stay under Firestore's 1 MB doc cap.

Blast-radius graph: fix overlapping node labels

• Node labels are now truncated to each box's actual width (mono ≈ 6.8px/char) so text can't overflow or overlap neighbours, and the affected-files band is capped at 6 for breathing room. Applies in the Impact tab and the inline chat graph.

Visual blast-radius in chat + live connector read-through (Jira/Linear/Slack)

• Blast-radius graph inline in Chat: ask "what breaks if I change src/App.js?" and the agent now appends a [[impact:<target>]] marker that the chat replaces with a live visual blast-radius graph (new ChatImpactGraph.jsx → /api/impact → BlastRadiusGraph) plus a risk/counts header — not just a text list.
• Live connector read-through (NEW): a live_search(source, query) agent tool that hits the live Jira / Linear / Slack API for the CURRENT state (the wiki is a snapshot). The agent calls it only for freshness-sensitive asks ("current status of PROJ-12", "latest on…"), reusing each connector's stored credentials, and labels results "🔴 Live from …". Jira = JQL/key lookup, Linear = GraphQL issue search, Slack = message search (needs a user token with search:read; otherwise falls back to the snapshot). New enhanciar/tools/live_connectors.py, wired into the query agent.

Impact: pick the target from a dropdown (+ chat already answers blast-radius)

• Target picker: the 💥 Impact box is now a searchable dropdown of every analyzable file / function / entity in the brain (new GET /api/impact/targets + impact.list_targets), instead of free text you had to remember. A "⌨ type a target manually" toggle keeps free entry for power users.
• Chat blast-radius: confirmed the chat agent already routes "what breaks if I change X?" to its blast_radius / callers_of / callees_of tools — so you can ask in plain language and get callers/dependencies (as text). Visual graph-in-chat is a possible follow-up.

Ingest activity feed: human-readable progress + more robust domain-plan parsing

• Readable logs: progress events used to dump raw JSON ({"type":"progress","data":{"total":117,…}}) because they carry no message. The feed now renders them as plain sentences — e.g. "Parsing files — 64/117 (55%)", "Parsed all 117 files" — and never shows raw JSON for any event.
• "Could not parse Scout's domain plan" warning: harmless (it falls back to treating the repo as one domain, which is fine for a single-tree repo), but it fired too often. The parser now also extracts the outermost {…} object when the model wraps its JSON in prose, so multi-domain plans are used more reliably and the warning is rarer.

Fix: re-sync a GitHub App installation after account delete + recreate

• Bug: deleting an Enhanciar account purges the github_installations mapping, but the App stays installed on GitHub. A recreated account then showed "0 repos / Connect" and clicking install hit GitHub's "already installed" wall with no way back.
• Fix: new POST /api/github/installations/resync lists the App's installations (App-JWT) and re-links any orphaned one (no owner) to the current user — never one already owned by another active account, so it can't hijack a connection. New github_app.list_app_installations + a "↻ re-sync" button on the GitHub connector (shown when you have 0 installations).