Handoff Log

Append-only, newest entry on top. Each entry: timestamp, agent, what was just done, current state, explicit next steps. Read this before touching the code if you're picking this up cold.

---

2026-08-27T07:53:57.409Z — Codex

Work finished: Completed live performance audit across all routes; no code changes made

Current state: Warm routes are generally 50-200ms, but cold navigation stalls recur on 20-30s cache expiry: remote host snapshots cost 2.4-2.9s, Playtopia facts ~2.2s, Q-Kit facts ~4.3s, first project sidebar refresh ~3.4s. No loading.tsx boundaries; cache does not deduplicate in-flight work; TODO and disk scans traverse multi-GB trees

Verification: Three-pass public timing sweep across primary routes; cold sweep across all 19 project slugs; all server/planning routes checked; direct SSH snapshot/facts timings; direct filesystem scan timings; host resource pressure checked and normal

Next step: Recommended fix pass: deduplicate in-flight cache work, decouple/sidebar-cache remote snapshots for minutes not 30s, remove deep scans from click path, add route loading states, and stop or constrain automatic prefetch of expensive project details

2026-08-27T07:48:59.079Z — Codex

Work started: Profile perceived and server-side load times across every live Control Room route

2026-08-27T07:43:38.532Z — Codex

Work finished: Deployed and committed handoff readiness auditing as 4cf5301

Current state: recent-commit is removed from global standards; handoff-ready is required for every tracked project including vendored records; project computed facts show log/state/continuity

Verification: lint 0 errors (one existing warning); local and Docker production builds passed; live control-room, audiobookshelf, and standards pages returned 200; handoff facts rendered; handoff-ready present; recent-commit absent; container healthy

Next step: No work pending; future standards design can distinguish durable readiness checks from informational activity metrics using this same principle

2026-08-27T07:42:22.318Z — Codex

Checkpoint: Replaced recent-commit with required handoff-ready standard and added handoff log/state/continuity rows to computed facts

Current state: Lint and production build pass; not deployed yet

Verification: npm run lint: 0 errors, one existing proxy warning; npm run build: passed

Next step: Deploy Control Room only, verify live standards column and per-project computed facts

2026-08-27T07:40:51.307Z — Codex

Work started: Replace recent-commit standard with handoff readiness and expose handoff controls in computed facts and standards views

2026-08-27T07:34:50.584Z — Codex

Work finished: Deployed cross-agent handoff controls and committed application changes as db0d950

Current state: Live control-room container is healthy; all tracked projects initialized; no application work remains

Verification: handoff doctor passed; CLI start/checkpoint/status passed; lint 0 errors (one existing warning); local and Docker production builds passed; four live routes returned HTTP 200; active indicator rendered

Next step: On the next real project task, the incoming agent reads HANDOFF.yml/HANDOFF.md and starts a new checkpoint session; design broader engineering and agent-principle standards in a separate future pass

2026-08-27T07:32:54.022Z — Codex

Checkpoint: Built atomic handoff CLI, initialized every tracked project, added active/stale UI, and fixed Dockerode externalization so production build succeeds

Current state: Lint passes with one pre-existing proxy warning; production build succeeds; deployment not yet performed

Verification: handoff doctor passed; start/status CLI passed; npm run lint has 0 errors; npm run build passed

Next step: Deploy only the control-room compose service, then smoke-test live pages and handoff state

2026-08-27T07:31:18.619Z — Codex

Work started: Implement cross-agent handoff hardening: atomic checkpoint CLI, active/stale UI, and project-wide initialization

2026-08-27T17:00Z — Claude

User confirmed (2 machines) last round's n/a-with-explanation for podusa/gp-forms/ sportsball-coach-podusa was NOT what they wanted — they want real checking, not a clearer n/a. Built it.

Item 1 (real remote facts/standards): extended the SAME least-privilege discovery key's forced command (control-room-ro.sh, no authorized_keys change) with a second mode — an exact path allowlist (/opt/gp-forms, /opt/podusa, /opt/sportsball-coach) via $SSH_ORIGINAL_COMMAND triggers file-presence + basic git facts instead of resource stats; legacy callers unaffected. Re-verified the full lockdown afterward — arbitrary commands, pty, port-forwarding all still correctly rejected, plus a new injection-string test (/opt/podusa; cat /etc/shadow as one literal value, rejected). New lib/checks/target.ts is the one shared place both facts.ts and registry.ts now resolve local/remote/none from — they used to each have their own host === "caspar" check and could drift, which is exactly what caused problem #2 below.

Verified real data, cross-checked against raw SSH output before trusting the app: podusa — repo/remote present (pass), has CLAUDE.md (pass), no SPEC.md (fail), last real commit 2026-03-25 so recent-commit fails; gp-forms — repo/remote present, no CLAUDE.md/SPEC.md, commit ~43 days old so fails; sportsball-coach-podusa — genuinely not a git repo (fail), with remote-present/recent-commit correctly n/a as a result of that, not a false negative.

Found mid-task: [slug]/page.tsx's own facts-availability gate (factsAvailable) was STILL hardcoded to host === "caspar" even after the registry was fixed — so the Standards matrix showed real data while the Computed Facts panel right next to it kept forcing every row to n/a. Renamed to checksAvailable, wired to the shared resolveCheckTarget(). Also renamed CheckList's hasLocalPath prop to hasAccess — the old name was itself part of what invited this exact bug to recur.

Item 2: Caspar's own disk stat was "0.0 / 0.0 GB" while remote hosts (more moving parts) showed real numbers — backwards, and a real bug: this container is Alpine/ BusyBox, and BusyBox's df has no --output= flag at all (silently prints its own help text instead of erroring; the parser's zero-fallback swallowed that quietly). Remote hosts use real GNU coreutils, so they never hit this. Fixed with a BusyBox- compatible df -B1 -P + awk reorder producing the identical 4-field shape the shared parser already expects. Caspar now shows 163.2/501.8 GB.

Item 3: profiled real pages (curl TTFB vs total, not guessed). Overview's existing streaming genuinely works (TTFB fast, total slower as stats stream in) — but computeHealth() wasn't inside that boundary and now does real remote SSH checks (this round's item 1 work), so split it into its own HealthStatTiles Suspense boundary. Bigger find: /projects was a real, measured bottleneck — TTFB equaled total (~2.3s, fully blocking), because the shared layout blocked the ENTIRE route including whichever project's detail content was actually being viewed, not just the sidebar list. Split the container-status fetch into ProjectSidebarListShell behind its own <Suspense> (skeleton fallback) so the detail panel never waits on it. Measured, not assumed: cold cache, fresh container — /projects TTFB dropped 2.37s → 0.18s; /projects/podusa//projects/gp-forms both render in ~0.15–0.23s total now. Also parallelized the detail page's standards evaluation (was a sequential await after facts) into the same Promise.all.

State: committed, deployed, verified live throughout. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected. Nothing pending from this round — /standards and /servers were profiled and found fast in practice (not restructured further); flag for later if that changes under real cold-cache load.

---

2026-08-27T16:32Z — Claude

Item 1 (podusa/gp-forms/sportsball-coach-podusa standards "not being checked"): got the real ground truth before touching anything, per the instruction. Fetched fresh, cache-busted copies of both /standards and each project's own detail page — all three currently render 5/5 clean n/a on the central matrix AND the per-project Standards card, WITH the explanatory note already present ("Checks that need local file/git access read as n/a..."). Checked the user's LXC-vs-VM theory specifically: confirmed podusa-prod and gp-forms-prod share kernel 5.15.152-1-pve (consistent with LXC on a shared Proxmox host), but this is NOT mechanistically relevant — registry.ts's standards checks never attempt to reach these hosts at all (Caspar-path-only by design), so container vs LXC vs VM makes zero difference to this specific code path. Could not reproduce the reported problem on the current deployed state — did not apply either of the two candidate fixes since neither's actual conditions were met. Most likely explanation: this was observed either from a stale browser cache before the previous round's deploy fully propagated, or is about a different panel entirely (Computed Facts / Host & Containers sit right next to Standards on the same page and could be conflated). Flagging honestly rather than inventing a fix for something not observed — if it recurs, get a specific screenshot/URL next time so the exact panel and state can be pinned down.

Item 2 (Servers page, real bug): every host card was showing Caspar's own container count (70) — /servers (was /infra) fetched Caspar's containers/disk ONCE and reused the same numbers for every card, a leftover from before the per-host SSH snapshot mechanism existed (the per-host detail pages already used it correctly; this overview page never got updated). Fixed by fetching each host's own snapshot in parallel, same mechanism as everywhere else. Verified live: Caspar=70, lighthouse=4, gp-forms-prod=4, podusa-prod=15 — four distinct real counts.

Route renamed /infra -> /servers for real (path, not just the sidebar label), with redirects for both /infra and /infra/:host so old links don't 404. Bonus: fixed top-bar.tsx's breadcrumbs while in there — a stale dead /notes entry and missing /planning/[id]//planning/notes handling (fell through to a generic crumb before).

Observed, not fixed (out of scope for what was asked): a transient SSH hiccup to a remote host gets cached as an empty result for the full 30s TTL — watched this happen live (gp-forms-prod showed 0 containers once, then 4 immediately after on the very next request). Self-healing, but worth a real fix if it causes visible flicker later — cached() in ttl-cache.ts memoizes whatever a function returns including its own failure fallback, doesn't special-case "this was actually a failure, don't freeze it."

State: committed (e3b1afc), deployed, verified live. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected throughout.

---

2026-08-27T16:20Z — Claude

3 items, all tested against the real live site.

Cards — 2 explicit lines now (name+badges / tags), not crammed onto one.

Tags — audited all 19 tracked projects' tags directly (not just the named examples). Removed generic/categorization words (self-hosted, games, monitoring, media, personal-site, infra, dashboard, microservices, promo, admin-cms, not-compose-managed) and x-hakt-style self-referential tags; kept genuine framework/language/datastore tags. needs_review is now a real project.yml boolean + its own amber indicator icon (list card + detail header), no longer a tag pill.

Standards — vendored flag: new vendored: true on project.yml, and evaluateCheck() in registry.ts now short-circuits to n/a for ANY check type on a vendored project, rather than relying on individual checks happening to degrade correctly. Marked audiobookshelf, jellyfin, AND lighthouse-metrics (Uptime Kuma + Umami

• Caddy — also third-party, not something built here) after auditing all 19 for other candidates. Added tooltips + a "(vendored)" label so it's visually obvious why a row is all n/a.

Standards — podusa bug, honest result: traced the full path end to end — podusa's YAML parses cleanly, registry.ts's checks never touch SSH/remote hosts at all (pure Caspar-path-only, already correctly n/a), live curl tests against both /standards and /projects/podusa rendered clean with no errors in the container logs, several times, under fresh cache-busted requests. Could not reproduce a live failure in the standards evaluation path itself this session. Did find and fix one real regression while tracing: getContainersForProject() (built two rounds ago) had no top-level try/catch, and both its callers had silently lost the .catch(() => []) discipline the pre-refactor code used to have — an SSH hiccup to any remote host could plausibly propagate as an unhandled rejection instead of degrading to n/a. Added the backstop inside the function itself so every caller gets it automatically, without needing to remember. This is the most plausible explanation for an intermittent failure, but I'm flagging clearly that I didn't directly observe the original bug firing — if it recurs, the next thing to check is timing/timeouts under real load (podusa's SSH round- trip varied 1.6s–5.6s across 3 back-to-back attempts in this session), not the evaluation logic itself, which is now doubly defended.

State: committed (85260e3), deployed, verified live. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected throughout.

---

2026-08-27T16:05Z — Claude

Big one: Planning rebuilt as a fully separate data model from Projects, per the user's explicit architecture call — it was previously just filtering project.yml by stage: idea|designing, so anything in Planning also incorrectly showed up in Projects. Now: data/planning/<ID>/task.yml + NOTES.md, own status lifecycle (idea/planning/ready/graduated), auto-incrementing IDs (IDEA-1, IDEA-2...) with dotted sub-task ids (IDEA-3.1) under a parent. Graduation cross-links both ways (task.yml.graduated_project <-> new project.yml.planning_task field) — the actual project-scaffolding action stays conversational/by-hand, only the structural link is built.

project.yml's stage field dropped idea/designing entirely — Planning fully owns that lifecycle now, a project record should only ever describe something real. Migrated the one project at stage: idea ("example-idea") into IDEA-1, deleted its project.yml. This incidentally resolves the rename/slug bug reported against it — it shouldn't have existed as a project record at all, so there's nothing left to exhibit that bug. Verified against the real live site (not dev mode — kept the standing gotcha in mind all three times this round): Projects (19, was 20) and Standards show zero trace of example-idea; Overview's stage stat correctly shows no idea/designing.

Notes retired as a top-level nav item, folded into /planning/notes alongside a new "note"-type freeform task bucket (vs "idea") for things never meant to graduate. The preserved Cool websites bookmarks and the inbox editor moved there unchanged.

Deliberate scope call, flagging for whoever's next: Planning is a plain grouped-list page + separate /planning/[id] detail page — NOT a master-detail split view like Projects. Given a real new data model + status lifecycle + cross-linking was already a lot for one round, this kept it achievable. Revisit if the UX ends up wanting the split-panel treatment.

Not deeply interactively tested: the create/status-update/notes-save Server Actions (createIdea, updatePlanningStatus, savePlanningNotes, setGraduatedProject) — same limitation as last round's task-board actions, Server Actions aren't easily curl-able. They reuse the exact same patterns already proven working for projects (renameProject/updateProjectStatus/saveProjectOverview), just not click-tested in a real browser this round.

State: committed, deployed, verified live via curl (cache-busted, per the standing lesson about stale first-requests after redeploy). hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected throughout.

---

2026-08-27T15:35Z — Claude

Bug fix, root-caused per the user's report (gp-forms showing container status "down" while genuinely up, facts/standards not populating): confirmed exactly the hypothesis given — meta.host === "caspar" was hardcoded in both projects/[slug]/page.tsx and projects/layout.tsx to gate whether ANY live container data got fetched, predating last round's per-host SSH lookups built for the Servers pages. Any project on lighthouse/gp-forms-prod/podusa-prod always resolved to "down" regardless of reality.

Added lib/infra/project-host.ts — routes through the same getHost() + getLocalSnapshot()/getRemoteSnapshot() mechanism the Servers pages already use, with a small alias map (caspar -> dragonfly, since project.yml's host: field predates hosts.yml's id scheme and every other host id already matches exactly). Both the detail page and list layout now use this instead of a Caspar-only listContainers() call.

Facts/standards: confirmed these were already degrading gracefully (n/a rows, no crash) — genuinely Caspar-only since no remote filesystem access exists, which is a real scope limit, not a bug. Split the previously-conflated liveMonitored variable into two (factsAvailable for local fs access vs containersLiveMonitored for container polling) since after this fix they're no longer the same thing for remote hosts, and added a one-line explainer so n/a reads as a known limitation instead of looking broken.

Verified against the real live site, not dev mode (per the standing gotcha from the last two rounds — kept front of mind, no repeat this time): gp-forms/lighthouse-metrics/ podusa/sportsball-coach-podusa (all remote, all genuinely running) now show up correctly in both the detail header and the sidebar list; sportsball-coach (Caspar, genuinely stopped) still correctly shows down — confirms no regression on Caspar-hosted projects. One false alarm along the way worth noting for whoever reads this next: my first verification pass got a stale cached RSC response showing the old "down" value immediately after redeploy — a fresh cache-busted request showed the fix was actually correct all along. Don't trust the very first post-deploy request if it contradicts the code; re-fetch clean before concluding something's still broken.

State: committed (851e97e), deployed, verified live. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected. Nothing pending from this round.

---

2026-08-27T15:20Z — Claude

What was done: Projects list page follow-up feedback — compacted project-list-item (tighter padding/font-size, tags moved inline next to the name instead of their own line), grouped the list into status sections (Live/Development/Paused/Abandoned, in that order — the exact set already in use, confirmed by checking every project.yml's status: field directly rather than guessing), and added Projects sub-nav items matching the existing Servers/Standards pattern, each filtering via ?status=.

Mechanism note: layouts in the App Router don't receive searchParams (only pages do), but the project list lives in the shared layout so it persists across /projects and /projects/[slug]. Solved by moving the grouping/filtering into a new client component (project-sidebar-list.tsx) that reads ?status= via useSearchParams() itself — which in turn requires wrapping Sidebar in Suspense (Next.js build requirement for any component calling that hook).

Real mistake caught again this round, same class as last time: local npm run dev reads the repo's own data/ folder (19 stale projects, missing sportsball-coach- podusa entirely) while the live site reads the real bind-mounted control-room-data/ (20 projects). Dev-mode testing looked complete but was silently validating against stale data. Caught it by noticing the Live-status count was 11 instead of the expected 12 and cross-checking file counts in both directories, rather than trusting a clean dev smoke test. This is now the second time this exact class of mistake has happened (same root cause as the hosts.yml issue from the servers-page round) — worth explicitly remembering: dev-mode testing in this repo only validates code/mechanism correctness, never data completeness. Always do the final verification pass against the real control-room-data mount / the live deployed site, not dev mode.

Verified against real production data (not dev mode) after that catch: all 20 projects render, all 4 section headers appear unfiltered, each of the 4 status filters shows only its own section with the correct count (Live: 12, confirmed).

State: committed (3b7cf6a), deployed, verified live. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected. Nothing pending from this round.

---

2026-08-26T12:15Z — Claude

Note on continuity: picked this up as a fresh session, coordinating directly rather than through the usual fork-and-report pattern (the previous fork became unresumable mid-task). Read this file's prior entries + git log to reconstruct state before touching anything, same as the last fresh-pickup did — worked cleanly.

What was done: added per-server sub-nav pages under Servers (Caspar, Lighthouse, gp-forms-prod, podusa-prod, Melchior), each showing real specs (kernel, cores), live resource usage (memory, disk, load average), and a per-project CPU/memory breakdown for whatever's actually running there.

How the data gets there:

• Caspar: no SSH needed, runs the same fixed read-only command sequence locally (src/lib/infra/local.ts) since Control Room lives on this host.
• lighthouse / gp-forms-prod / podusa-prod: the existing least-privilege discovery SSH key's forced command was extended from bare docker ps to a small fixed script (/usr/local/bin/control-room-ro.sh on each host — uname, nproc, free, df, loadavg, docker ps, docker stats, in that order, section-tagged). Re-verified the lockdown after this change, properly (not just re-checked the config): arbitrary commands still ignored (forced command always runs instead), pty requests still rejected, port-forwarding still rejected on lighthouse/gp-forms-prod entirely and on podusa/machinazero everywhere except the one permitted jump destination — confirmed the last one specifically by relaying a real SSH banner through the permitted tunnel (proves it actually works) and confirming zero bytes through every disallowed attempt (proves rejection isn't just "the local listener never opened").
• src/lib/infra/remote.ts (replaces the old remote-docker.ts) parses the section- tagged script output; local.ts shares the exact same parser for Caspar's own data so both paths produce one common shape.

Real mistake caught before calling this done: hosts.yml exists in TWO places — the repo's data/infra/hosts.yml (used only by local npm run dev) and the actual bind-mounted ~/unified-services/control-room-data/infra/hosts.yml that the deployed container reads from (DATA_DIR=/app/data). First pass only updated the repo copy, which made dev-mode testing look perfect while the live site kept showing the old live_monitored: false / no ssh_alias data — silently serving stale reference-only pages instead of the new live ones. Caught this by diffing what the live site actually rendered against what dev mode showed, not by assuming a successful dev test meant deployment was correct. Updated both control-room-data/infra/hosts.yml (the real one) and data.example/infra/hosts.yml (the git-tracked reference copy) to match.

State: committed (1bb767d), deployed, verified live on all 5 host pages (real numbers on Caspar/lighthouse/gp-forms-prod/podusa-prod, correct "not monitorable" stub on Melchior), sidebar sub-nav confirmed present. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected throughout.

Nothing pending from this round.

---

2026-08-26T11:52Z — Claude (fresh fork, prior session's transcript was lost)

What was just done, all verified live and committed (ea8c653):

1. Sportsball-coach split. User confirmed podusa-prod's copy is the real live one, Caspar's is an old superseded dev copy. Created a new tracked record sportsball-coach-podusa (host: podusa-prod, status: Live) and updated the existing sportsball-coach record (host: caspar, status: Abandoned) — both records cross-reference each other in their notes so either one found alone makes the relationship obvious.
2. Themed scrollbars. Added a .themed-scrollbar utility in globals.css (thin, uses var(--border)/var(--muted-foreground) so it tracks the theme automatically) and applied it to the Projects list column (src/app/projects/layout.tsx) and the detail panel (src/components/detail-panel.tsx).
3. AI Handoff page — root cause was NOT "wrong component." It was already using MarkdownRenderer correctly. The actual bug: that component's only mode was prose-sm max-w-none — right for short dashboard cards (SPEC/STATUS snippets, network-map, cool-links), wrong for a 122-line long-form article stretched to the full app-shell width with no line-length cap. Added a variant prop ("compact" default, unchanged everywhere else; "article" = base text size + max-w-3xl mx-auto for readable line length) and switched only the ai-handoff page to it. Also added the missing sidebar sub-nav item (Standards now expands to show "AI Handoff" when active) — the /standards page link to it already existed from the previous round, only the sidebar entry was actually missing.

State: all four items from the user's last message are done and verified against the live site (curl'd the actual pages, checked rendered class names, confirmed container health). hugo-x-hakt/docker-compose.phase4.yml confirmed unaffected throughout.

Next steps / nothing outstanding from this round. Worth knowing: I picked this up as a totally fresh fork because the prior session's transcript became unresumable — this HANDOFF.md file (plus git log) was the only thing that let me reconstruct state correctly. Exactly the failure mode this convention exists for.

---

2026-08-26T07:09Z — Claude

What was just done: Finished the remaining 2 items from the entry below, shipped everything from this round.

Item 2 — imported 4 more discovered projects as real tracked records (metadata only, zero containers touched, all confirmed pre-existing state): jellyfin (Caspar, not compose-managed — its own container has zero labels, drifted from ~/jellyfin-server/docker-compose.yml), lighthouse-metrics (the metrics compose project on the lighthouse — Caddy/Umami/Uptime Kuma), gp-forms (gp-forms-prod — only gp-forms-api is actually compose-labeled; the other 3 containers were included based on shared mount paths + the preserved network-map doc, flagged explicitly as inferred rather than confirmed), podusa (podusa-prod's full 13-container stack — noted that minio/redis/db/prometheus were reporting healthcheck "unhealthy" at import time, and flagged a genuinely interesting find: podusa-prod runs its own separate, apparently-live sportsball-coach compose project, distinct from the already-tracked sportsball-coach record which is host:caspar and shown exited — added a note to that existing record rather than creating a new one, since reconciling which is "real" wasn't in scope here).

Item 4 — new /standards/ai-handoff page, linked from the main Standards page. Content lives at data/docs/ai-handoff.md (plain markdown, matching the project's own philosophy — this page documents that philosophy, so it seemed right to practice it) covering all 7 topics requested, written as real prose from firsthand build details, not a bullet-dump.

Also went back and improved item 3 further after re-measuring: the 5-minute cache fixed repeated cold hits, but the very first visit after a cache-empty state (server restart, or just the first visit in 5+ minutes) still took ~9-12s end to end — bad if it's the visit that actually happens. Root problem: Overview's "Unregistered found" stat was blocking the ENTIRE page's render on the slow cross-host SSH discovery call. Fixed properly with a React Suspense streaming boundary — UnregisteredStatTile is now its own async component wrapped in <Suspense>, so the rest of Overview (title, project counts, health stats) renders immediately (measured: time-to-first-byte dropped from ~9-12s to ~2s on a cold cache) while just that one stat tile shows a skeleton placeholder until the SSH checks resolve. This is a materially different fix than "just cache it longer" — worth knowing if the same "one slow computed value blocking a whole page" shape shows up again elsewhere.

State: all 4 items from this round done, tested, live, committed. Verified live: q-kit/sbm now show the correct red "down" container badge with no conflicting green dot; all 4 new projects present via /api/projects; Overview loads fast; the AI Handoff page renders with real content. hugo-x-hakt / docker-compose.phase4.yml hash confirmed unaffected throughout.

Nothing pending from this round, other than things flagged as out-of-scope-but-worth-knowing above (the podusa-prod sportsball-coach duplicate; gp-forms's non-api containers being inferred rather than confirmed by labels).

---

2026-08-26T06:57Z — Claude

What was just done (2 of 4 items, tested, not yet committed/deployed):

Item 1 — real bug, root-caused (not a re-patch). User reported q-kit/sbm/etc. showing green when their containers are genuinely stopped. Traced the ACTUAL values end to end rather than re-checking the color table: the container-status badge itself was already correct on both the detail page and the compact list card (confirmed "down"/red directly in the rendered HTML for q-kit and sbm). The real culprit was HealthDot — a third status signal (standards- compliance "healthy/attention/unknown", a completely different concept from container liveness) that was still rendering on project-list-item.tsx's compact cards from before the "consolidate to 2 statuses" task two rounds ago — that task removed the stage badge but never removed this. q-kit/sbm have clean git hygiene (passing required standards checks), so their dot showed green "healthy" right next to a correctly-red "down" container badge — two green/red signals answering different questions, reasonably read as a bug. Removed HealthDot from both project-list-item.tsx and project-card.tsx (Planning's cards) entirely, deleted the now-fully-unused health-dot.tsx component. Standards-health as a concept still exists — Overview's stat tiles, the Standards page — just not ambiently duplicated on every card. Bonus: this also removed a redundant computeHealth pass (git checks for every Caspar project) that ran on every single /projects navigation for a dot that's now gone — helps item 3 too.

Item 3 — root cause found and fixed. Measured real timings across all 6 top-level nav pages: everything was under 150ms except / (Overview) at ~9.2 seconds. Overview's "Unregistered found" stat calls discoverGroups(), which fans out to the 3 cross-host SSH checks added two rounds ago. Those already had a TTL cache, but only 30s — short enough that most real visits still hit it cold and paid the full multi-host SSH round-trip (including the 2-hop jump to gp-forms-prod) synchronously. Extended that cache to 5 minutes — discovery data (does a compose project exist on another host) isn't time-sensitive the way container health is, so a much longer window is the right tradeoff. Not yet re-measured after this fix — next step.

Not yet done:

• Item 2 (fully import jellyfin, lighthouse's metrics stack, gp-forms-api, podusa's podusa stack as real project.yml records — metadata only, same as the original 12) — starting next.
• Item 4 (new Standards → "AI Handoff" documentation sub-page) — after item 2.
• Re-measure Overview's timing after the cache-TTL fix to confirm it actually resolved (expected to, based on the root-cause analysis, but not yet proven with real numbers this round).
• Not committed, not deployed.

---

2026-08-26T06:41Z — Claude

What was just done: Finished and shipped the least-privilege SSH key work from the entry below. New dedicated ed25519 keypair (~/control-room-keys/id_discovery on Caspar, never reused from any existing key), appended — additive only, nothing removed/modified — to authorized_keys on all three targets with forced commands:

• lighthouse and gp-forms-prod (the actual target, 192.168.6.180): restrict,command="docker ps -a --format '{{json .}}'" — no shell, no pty, no forwarding, nothing but that one command.
• Real complication found mid-task: machinazero-prod and podusa-prod are two SSH aliases for the same physical machine (confirmed via matching authorized_keys md5sum) — gp-forms-prod is reached by jumping through this same box. First pass accidentally appended two separate, conflicting entries for the same key to one file (a direct-command one and a jump-only one) — since OpenSSH applies only the first matching line for a given key, this would have silently broken the jump path. Caught it before deploying anything, removed both (grep -v on the unique key comment, verified count back to the original 2 pre-existing lines), and replaced with one correct combined line: restrict,port-forwarding,permitopen="192.168.6.180:22",command="docker ps -a --format '{{json .}}'" — handles both "run docker ps when used directly" and "tunnel to gp-forms-prod when used as a jump", with the tunnel capability scoped to that one destination:port only.

Verified lockdown explicitly, on all three targets, before wiring into the app:

• Arbitrary command (whoami; cat /etc/shadow; rm -rf /) — ignored, forced command ran instead.
• -tt (pty request) — rejected ("PTY allocation request failed").
• Port-forwarding to anything other than the one permitted destination — rejected ("administratively prohibited"), confirmed on both lighthouse (no exception at all) and the podusa/machinazero box (exception scoped correctly — forwarding to 192.168.6.180:22 works, forwarding elsewhere on that same box does not).

New minimal ~/control-room-keys/config (absolute IdentityFile paths, no tilde — sidesteps the passwd-home-dir quirk from the last entry entirely for this new config) with 4 Host blocks (discovery-lighthouse, discovery-jump, discovery-gpforms, discovery-podusa) plus UserKnownHostsFile /dev/null globally (the mount is read-only, so it can't persist known_hosts — avoids a harmless-but-noisy permission-denied warning on every connection). docker-compose.control-room.yml's broad ~/.ssh mount is gone, replaced with this narrow directory; also added a mount for ~/jellyfin-server (needed for the Jellyfin discovery fix from the entry below) rather than broadening to all of /home/thrax, which would have re-exposed real SSH keys and undone the whole point of this change.

Confirmed after deploy, from inside the actual running container: /home/thrax/.ssh no longer exists at all (old mount genuinely gone); docker.sock and /app/data writes still work (unaffected by the mount change); all three discovery hosts reachable via the new restricted keys with clean output (no warnings). Live on control.x-hakt.com/projects: gp-forms-prod, lighthouse, podusa-prod, and Jellyfin all show up correctly.

State: all 3 items from the entry below are done, tested, live, committed. hugo-x-hakt / docker-compose.phase4.yml hash confirmed unaffected throughout. Cleaned up scratch files in /tmp on Caspar. Left a backup copy of podusa's pre-fix authorized_keys at ~/.ssh/authorized_keys.bak-controlroom on that host (from the conflicting-entry cleanup) — harmless, hasn't been removed, could be deleted once someone's confirmed they don't want it.

Nothing pending from this round.

---

2026-08-26T06:34Z — Claude

What was just done (2 of 3 new items, tested in dev, not yet committed/deployed):

1. Jellyfin discovery fix. Root cause wasn't "wrong folder scanned" — jellyfin's running container has ZERO compose labels at all (started outside docker compose, drifted from its own ~/jellyfin-server/docker-compose.yml), same situation as matchngacha-x-hakt. Generalized discovery.ts: scanComposeFiles() now scans ~/unified-services/*.yml (as before, for build-context disambiguation) plus one level into every other home-directory subfolder, building a container_name -> folder map from the files themselves — so a container with no live compose labels can still be matched back to its compose file's folder by name. Verified locally: Jellyfin now shows up under Unregistered. Not yet deployed — the container doesn't have ~/jellyfin-server mounted yet; needs a compose volume addition. Deliberately did NOT just mount all of /home/thrax broadly (that would defeat the whole point of item 3 below by re-exposing ~/.ssh read-only) — plan is to add a narrow ~/jellyfin-server mount alongside whatever item 3 lands on, in the same compose edit pass, to minimize rebuild/redeploy cycles.
2. Status colors centralized — new lib/status-colors.ts (up=green, down=red, attention=yellow, unknown=grey), applied across health-dot, container-status-badge, docker-status-table, project-containers, host-card, topology-diagram, stat-tile, standards-matrix, check-list. Found and fixed a real pre-existing bug in the process: HealthDot's "attention" state was rendering red, not yellow — same color as "down", which is exactly the confusion this task was about.

Not yet done — item 3, the real production-infra change, starting now: Replacing the broad ~/.ssh mount with dedicated least-privilege discovery keys. Plan: one new ed25519 keypair (not reusing any existing key), appended (never replacing) to authorized_keys on all three hosts with a forced command restricted to docker ps -a --format '{{json .}}'. Complication found while planning: gp-forms-prod is reached via a jump host (machinazero-prod / syd.machinazero.com), so the new key also needs a restricted entry on the jump host itself — restrict,port-forwarding,permitopen="192.168.6.180:22",command="echo restricted" (allows ONLY tunneling to the one target, no shell/arbitrary commands even on the jump host) — plus the normal restrict,command="docker ps..." entry on gp-forms-prod itself and on lighthouse/podusa-prod directly. Nothing has been added to any remote host yet as of this entry — about to start. Will verify old broad access still works untouched, new key works for discovery, AND new key is explicitly confirmed rejected for anything beyond the forced command before touching the container's mount config at all.

---

2026-08-26T06:15Z — Claude

What was just done: Finished and shipped the 7-item round from the entry below. All 7 tested in dev, committed, deployed, verified live. One real bug found and fixed during deployment (not present in dev-mode testing, since dev runs directly on Caspar's host, not containerized): cross-host SSH discovery worked when tested via plain ssh from Caspar's shell, but failed inside the actual container with "Could not resolve hostname" — root cause was that node:alpine's built-in uid 1000 user ("node") is registered in /etc/passwd with home /home/node, and OpenSSH resolves ~ (both for the config file's own default path and for IdentityFile ~/.ssh/... lines inside it) via that passwd entry, not the $HOME env var — so both the config lookup and the identity file path were silently wrong. Fixed at the root with a sed on /etc/passwd in the Dockerfile so uid 1000's registered home matches where we actually mount the keys (/home/thrax), plus kept an explicit -F flag in remote-docker.ts as a second line of defense. Confirmed working end-to-end from inside the real deployed container (all three hosts respond) and live on control.x-hakt.com/projects (discovery shows real results from gp-forms-prod, lighthouse, and podusa-prod).

Also confirmed live: playtopia detail page load dropped from ~25s to ~4s on a cold cache (and much faster once warm) — the grep-based rewrite + TTL caching from the entry below holds up under the real container, not just dev mode.

State: everything in the previous entry's 7-item list is now done, tested, and live. hugo-x-hakt and docker-compose.phase4.yml's hash confirmed unaffected throughout.

Nothing pending from this round. Next open items are whatever the user raises next, or the items already flagged as deferred/uncertain in earlier entries (SSH key least-privilege follow-up for discovery; the podusa-prod reachability was flaky mid-session — came back on its own, nothing done about it either way).

---

2026-08-26T06:05Z — Claude

What was just done: New round of user feedback (7 items) mid-session. Progress so far, all type-checked clean but not yet tested end-to-end, committed, or deployed:

1. Removed the stage badge from the Projects list cards and detail-page header (it stays internal, used only by the Planning page's filter) — done, in project-list-item.tsx and [slug]/page.tsx.
2. Cross-host discovery extended to lighthouse + gp-forms-prod + podusa-prod. Checked SSH access first, as instructed — Caspar's ~/.ssh/config already has working aliases (nebula-lighthouse, gpforms-prod, podusa-prod). Tested non-interactively: nebula-lighthouse and gpforms-prod both work; podusa-prod times out at the network level (host unreachable via its nebula IP right now — NOT a credentials problem, nothing to fix on our end). New lib/infra/remote-docker.ts (SSH docker ps -a --format json, parsed), discovery.ts extended to poll all three and merge with Caspar's local scan, tagging each group with its host. Compose file now mounts Caspar's ~/.ssh read-only into the container and runs the container as uid 1000 (not the image's default 1001) so the mounted keys are actually readable — flagged a real security tradeoff in the compose file's own comment: these are root-capable keys to two other production hosts; this container only ever runs read-only docker ps over them, but the credential itself isn't scoped down, so a future compromise of this container would mean compromise of those hosts too. Not fixed, just flagged — a dedicated least-privilege key would be the right follow-up, not something to do silently as part of this task.
3. Slide-in animation for the detail panel — new components/detail-panel.tsx, keyed on pathname so it replays on every navigation, using tw-animate-css (already a dependency, no new library added).
4. Independent scroll per column — projects/layout.tsx now uses a fixed h-[calc(100vh-5.75rem)] container with both the list and detail panel independently overflow-y-auto, instead of the previous sticky + shared-scroll approach.
5. Breadcrumbs are now real <Link>s (top-bar.tsx rewritten) — all segments except the current/last one.
6. Investigated load times — this was a real, confirmed bug, not just perception. /projects/playtopia was taking ~25 seconds. Root cause: countTodoFixme in lib/checks/filesystem.ts did a hand-rolled recursive walk that readFile'd every matching file one at a time in JS, sequentially, no concurrency — fine for a small project, disastrous for a 19-service monorepo (2279 matching files, confirmed by direct measurement). Rewrote it to shell out to grep -rEoh instead (the right tool for "search file contents across a tree"), and added a small generic TTL-cache utility (lib/util/ttl-cache.ts) applied to: countTodoFixme, diskUsageBytes (both 30s), getGitFacts (20s — this also fixes a real duplication: the git-repo-present and git-remote-present standards checks were each independently calling getGitFacts, doubling every git subprocess spawn for every project on every /projects navigation), local listContainers (5s), and listRemoteContainers (30s, since it's an SSH round-trip). Not yet re-measured after this fix — that's the very next thing to do.
7. "Status" tab renamed to "Overview", now editable — new saveProjectOverview action (writes STATUS.md directly) and ProjectOverviewEditor component, reusing the same textarea-plus-save-button pattern as the Notes inbox editor. Wired into [slug]/page.tsx; the tab always shows now (even with no STATUS.md yet), since every project should have a prose description.

Not yet done:

• Re-measure /projects/playtopia and a few others after the caching/grep fix, to confirm it actually resolved the slowness (expected to, based on the root-cause analysis, but not yet proven with real numbers).
• Haven't re-tested any of items 1–7 against a running dev server since these edits — typecheck is clean but that's it so far.
• Not committed, not deployed.
• Haven't verified the new SSH-based discovery actually surfaces anything real from lighthouse/ gp-forms-prod once wired into a running server (confirmed access works via raw ssh calls from Caspar's shell, but haven't yet run it through the app's own container-mount + uid-1000 setup end-to-end).

Next steps: re-seed dev data if needed, start npm run dev, work through testing each of the 7 items (especially re-timing playtopia/q-kit, and confirming discovery finds the metrics group on lighthouse + gp-forms-api on gp-forms-prod), then commit, deploy via docker compose -f docker-compose.control-room.yml up -d --build control-room (note: this round's compose changes — new volume mount, user:, extra group_add entry — mean this build needs the full up/recreate, not just an image rebuild), verify live, append a new entry here.

---

2026-08-26T05:36Z — Claude

What was just done: Resolved the "open bug" flagged in the entry directly below (q-kit/sbm showing container-status up when it should be down). It was a false alarm from my own ad-hoc verification regex, not a real app bug — confirmed via /api/docker/containers directly (q-kit: 0 up/22 down, sbm: 0 up/5 down → majority-vote correctly yields down) and via precise byte-offset inspection of the actual rendered HTML (q-kit's detail page genuinely shows the down badge). Also confirmed the master-detail link-swap is correct: viewing a project's own detail page, that project's own sidebar card link becomes /projects (retract), not a self-link — verified directly on /projects/sbm. No code changes from this entry. Built the HANDOFF.md feature itself in between (data layer read support, HandoffLog panel on project detail, AGENTS.md convention, this file's own existence). Not yet committed or deployed — that's still next. Continuing immediately per the plan in the entry below; not re-writing it, just correcting the one open item.

---

2026-08-26T05:31Z — Claude

What was just done: Implementing the master-detail /projects layout + dual status badges (user request, mid-task when this entry was written). Was cut off by a session limit once already during this same feature; this file is being created specifically so that can't cause lost context again.

Decisions already made (don't re-litigate):

• Routing mechanism for master-detail: a shared Next.js layout, not parallel/intercepting routes. src/app/projects/layout.tsx renders the compact project list (left column, ~18rem fixed width) and {children} (right column, flex-1). src/app/projects/page.tsx (bare /projects) renders an empty-state placeholder + the discovery "unregistered" section as children. src/app/projects/[slug]/page.tsx (unchanged route, already existed) renders the full detail as children. This means direct-link and click-to-expand both go through the exact same render path automatically — no special-casing needed.
• Expand/retract/switch logic lives in src/components/project-list-item.tsx (client component): compares usePathname() against its own /projects/[slug] href. If already open, the Link's href becomes /projects (retract); otherwise it's the detail href (expand or switch directly, no two-click close-then-open needed). This is genuinely just plain Next <Link> — no custom client-side routing.
• status field on project.yml is a plain string, not z.enum — deliberately, so adding a new status value later is a data change, not a code change. Known values (Live/Development/ Paused/Abandoned) get styled badges (project-status-badge.tsx); unknown values still render, just with a neutral fallback style.
• Container status is computed, never stored: lib/checks/container-status.ts, majority vote across getContainerRefs(meta) vs live Docker state. A container ref with no live match counts as "down", not excluded — silence isn't evidence of running.

State as of this entry — done:

• Schema (schema.ts, types.ts, projects.ts normalize) has status.
• lib/checks/container-status.ts, project-status-badge.tsx, container-status-badge.tsx, project-list-item.tsx all written.
• src/app/projects/layout.tsx (new), page.tsx (rewritten to placeholder + unregistered-only), [slug]/page.tsx (header now has ContainerStatusBadge + a new inline ProjectStatusEditor select for editing status) — all written.
• renameProject/updateProjectStatus actions in lib/actions/projects.ts.
• Backfilled status on all 15 existing project.yml records (both data.example/ and the real control-room-data/ on Caspar) — see each record's own notes: for ones I was genuinely unsure about (q-kit, rhythmmech-x-hakt, sbm, sportsball-coach, x-hakt-escape all marked Paused but flagged as could-be-Abandoned since every container's been exited 5+ weeks; playtopia-gamification-service marked Development but flagged since the container is actually healthy/running — the uncertainty is about purpose, not liveness; matchngacha-x-hakt marked Paused not Abandoned since we only stopped it, didn't decommission it).
• npx tsc --noEmit clean as of this entry.
• Local dev (npm run dev -p 3010 on Caspar) smoke-tested: bare /projects returns 200 with all 15 list items and no detail expanded and no card highlighted; direct /projects/x-hakt returns 200 with the list still present, detail expanded, and exactly x-hakt's card highlighted. All 15 status values confirmed correct via /api/projects.

State as of this entry — NOT done / in progress:

• Open bug, not yet root-caused: spot-checking container-status (up/down) just showed q-kit and sbm as up, but both have the majority of their containers exited per docker ps -a (q-kit: ~all 22 exited; sbm: all 5 exited) — the majority-vote should yield down for these. Need to check computeContainerStatus / getContainerRefs for a bug before trusting this feature. This is the very next thing to investigate.
• Have not yet deployed to production (no docker compose ... up -d --build control-room run this round) — everything so far is only verified against local npm run dev.
• Have not yet committed to git (working tree has uncommitted changes across schema/lib/ component/page files plus the 15 backfilled project.ymls).
• Haven't done a literal click-driven browser test of the retract/switch behavior (no browser tool available) — verified structurally via direct-URL SSR output for two states instead. If picking this up fresh, that structural verification is probably sufficient, but flagging the gap.

Next steps for whoever picks this up:

1. Debug the q-kit/sbm container-status "up" bug (likely in computeContainerStatus or how containers: refs are being matched against live container names — check for a stale/duplicate container with the same name still reporting running, or a logic inversion).
2. Once fixed, re-verify container-status across a few more known-down projects (rhythmmech-x-hakt, x-hakt-escape, sportsball-coach) and a known-up one (x-hakt, playtopia).
3. rm -rf .next data && npx next typegen && npm run init-data (re-seed dev data with anything changed), full npx tsc --noEmit pass.
4. git add -A && git commit (this repo's convention: one commit per logical batch of work, see git log for message style), then deploy: cd ~/unified-services && docker compose -f docker-compose.control-room.yml up -d --build control-room.
5. Verify live at https://control.x-hakt.com/projects — same checks as the local dev pass above, plus confirm hugo-x-hakt and the docker-compose.phase4.yml hash are untouched (standing verification habit for every deploy in this project, see STATUS.md history / earlier handoffs once they exist).
6. Append a new entry to this file once done — don't overwrite this one.

Also part of this same task batch (already reported to the user in a prior turn, before this entry existed — not re-describing in full here): Servers rename (Infra→Servers nav), 12 discovered projects imported as tracked records, matchngacha-x-hakt stopped (docker stop only), an exited-container health-parsing bug fixed. All of that is already committed (see git log) and live — only the master-detail/status-badge work in this entry is uncommitted/undeployed.