feat: operator notifications, dependency editing on the edit page, and a measured memory baseline

[fclairamb]

Five specs from specs/todos/, implemented sequentially on a batch branch, each gated by an independent completeness audit before being archived. Three of the five needed at least one fix round, and the audits caught two real defects the implementers had reported as done.

No database migration — the fix below is a reader change, and existing rows are readable as-is.

What changed for the user

Check credentials can be decrypted by every process, not just the one that generated the key. An organization's data encryption key is stored wrapped as {"value": …} but was read back raw, so the process that generated the key kept working from its in-memory cache while every other process — each checks worker, and the API itself after its next restart — failed with unknown envelope version. The user-facing advice was "re-save the check's credentials", which cannot help and, after an API restart, stops working entirely because the API can no longer decrypt to merge the update. The reader now accepts the wrapped shape as well as the two legacy ones, a freshly generated key is read back and verified before it is cached so a storage-shape regression fails the first encrypt loudly, and an organization-key failure is now reported as its own cause instead of blaming the check's credentials. Nothing needs rotating or re-entering; the wrapped key was intact all along.

Two corrections to the original diagnosis came out of the work, both verified against git history: the wrapping has been there since the first commit rather than since v0.22.0, so cold key loads have been broken since the key store shipped in May — and the remediation SQL the spec proposed would have made things worse, because rewriting the row to a bare string breaks the parameter reader outright. Both are now flagged in the archived spec and documented.

Operators can be paged when a support message arrives or someone signs up. Neither event could reach a human in real time: an inbound support message produced one email to the instance mailbox, and a signup produced nothing beyond an optional analytics event. A new Notifications tab under Server lets a super admin choose which super admins hear about which of those events, delivered over the notification routes each recipient already set up — email, Telegram, a Slack DM, web push or SMS. The page is built around how this feature fails quietly: a recipient with no route is flagged in amber next to their name, a subscriber who has lost super-admin status keeps a visible row explaining why they are skipped, and "Send me a test" reports how many routes actually carried the notice rather than a bare success. Bursts fold the way the support mailbox mirror already folds them, and the email mirror is unchanged.

Check dependencies are edited where every other attribute is edited. The detail page — the view surface for a check — was the only place you could add, retype or delete a dependency, while the edit page offered a weaker editor that could only add and remove parents and hard-coded every new edge to "hard" with no description. The detail page is now read-only with an Edit link, and the edit form carries the whole editor: kind, description, inline staging until Save, and cycle prevention both in the picker and on submit. Both lists also got a real row design, registered in the design reference as a reusable pattern.

The "Getting started" checklist reads like something to finish. It gained depth and a gradient accent, a real progress bar, a single highlighted "next up" step, numbered badges that turn into filled ticks, and a celebratory all-set state. The strikethrough is gone — five struck-through rows looked like a wall of deletions rather than a finished list. Every animation respects prefers-reduced-motion, which is a new convention for the dashboard and is documented as one.

Under the hood

Memory can now be measured instead of eyeballed. /api/mgmt/memory reports a real Linux breakdown (process, smaps, cgroup v2, Go runtime classes, and the off-heap figure the runbook asked for), and a new membench harness runs the shipped container shape with a warm-up, a sampling window and repeated runs, so a change is judged against its own noise floor rather than a single snapshot. Two of the spec's own premises did not survive contact with the measurements, and the runbook says so: the SQLite driver in the shipped binary is modernc, not mattn, so the driver the build reported was wrong (now fixed) and the off-heap rule rested on it; and idle memory reads ~149 MiB at 45 seconds but ~23–31 MiB at five minutes, so the 60-second warm-up the spec proposed would have measured the startup burst as steady state.

Of the seven reduction candidates, two shipped, two were measured and rejected, one was closed by inspection, and the rest are recorded as not attempted with what it would take. The candidate that streams embedded assets instead of copying each one onto the heap is honest about not clearing an RSS gate — the harness cannot resolve it — and ships on an allocation measurement instead.

Verification

The full dash0 Playwright suite was run as a batch-level gate rather than per-spec, which caught two cross-spec selector collisions introduced by the new Edit link. Four failures remained; all four were A/B'd against origin/main in isolated worktrees and reproduce there, so none is introduced by this branch. Two are not product failures at all — they only appear when the E2E server is started without the environment variables CI sets. The other two are pre-existing defects now written up as their own specs: an ipVersion clear-to-Auto bug, and an unbounded connection pool against the embedded Postgres server.

Added since this branch was first opened

The unbounded embedded-Postgres pool mentioned above is no longer just a filed spec — it is fixed here.

NewEmbedded opened its sql.DB with database/sql's unbounded default against a server it
itself pins at max_connections=10 (7 usable after superuser reservations), so a 50-goroutine
test asked for ~50 backends and everything past the 7th got a hard 53300 sorry, too many clients already. It is now bounded in the constructor via the same applyPoolLimits the
non-embedded path uses, and the three suites that each hand-rolled their own
SetMaxOpenConns workaround no longer need to.

One correction worth calling out, because the spec got it wrong: the spec concluded this was
purely a test-infrastructure bug on the grounds that NewEmbedded is test-only. It is not.
postgres-embedded is a real, user-selectable SP_DATABASE_TYPE reached from main.go's
openDB and runMigrations and from internal/app/server.go, so before this change an
operator running embedded Postgres would hit those same hard 53300 errors under modest
concurrency. The fix is unchanged — bounding the client turns the errors into queueing — but it
is a product fix as well as a test fix, and the archived spec now carries an amendment saying
so rather than leaving the false premise on the record.

The guard is proven by a positive control, not just a green run: with the bound removed both
concurrency tests fail again with the original 53300, and the Postgres log shows dozens of
simultaneous rejections, so the contention is still genuinely concurrent.

🤖 Generated with Claude Code