new(context-v, issues): jot the three post-v1 debts — liveness/error surfacing, the deferred TDD floor, and the missing component library

Three journey-log issues filed before the next arc, tagged per the
operator's triage: Usability+Error (dead-feeling clicks with five
indistinguishable causes and no everything-is-fine view), Oversight
(zero automated tests despite TDD being the natural fit for
iterate-until-green agentic work — the prove-scripts are proto-tests
pointing the way), and Oversight+Usability (fourteen remotes of
improvised UI with at least six near-duplicate organs inventoried,
bounded by the no-cross-app-dependency rule but with the intra-repo
packages/shared-ui path open).

Each file captures symptom, what exists today, candidate directions,
and open questions — deliberately jotted, not decided. The three
cross-reference each other where they interlock (tests guard pre-ship
vs liveness guards runtime; extract-components-without-tests risk).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014zrFkWSVgTkoQyiobdBjrd

Author: mpstaton

context-v/issues/Live-Not-Live-Indicator-Tooling-And-Cross-Service-Error-Surfacing.md

@@ -0,0 +1,87 @@
+---
+title: "Live/not-live indicator tooling — parts of the UI feel dead, and there's no single view that says whether everything is actually working"
+lede: "Clicking a Flow, a button, a chip sometimes does nothing, and the operator can't tell whether the remote is down, the service is down, the capability errored silently, or the click genuinely did nothing. The app needs liveness indicators in the chrome and at least one everything-is-fine view — plus error logging that actually surfaces across services and frontends."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Usability
+  - Error
+  - Augment-It
+  - Observability
+  - Liveness
+  - Error-Surfacing
+  - Shell
+status: Open · Jotted
+---
+
+# Live/not-live indicator tooling + cross-service error surfacing
+
+## The symptom
+
+Using the application, some options feel **"dead"** — clicking a Flow in the
+popdown, clicking a button, firing an action sometimes produces nothing
+visible. No spinner, no error, no state change. The operator is left
+guessing which of at least five different failures it was:
+
+1. The federated remote isn't running (dev server down on its port) — the
+   shell mounts nothing or errors quietly.
+2. The remote mounted but its WebSocket to workspace-service is
+   `closed`/`error` — every `workspace.invoke` dies.
+3. The capability crossed the wire but the backing service (or NATS, or
+   SurrealDB) is down/erroring — reply times out or comes back `ok:false`
+   into a code path that doesn't render it.
+4. The click worked and the write landed, but nothing on-screen refreshed.
+5. The click genuinely does nothing yet (an unwired affordance).
+
+All five present identically to the operator: a dead click.
+
+## What we already have (scattered, insufficient)
+
+- Per-remote WS status pills (`status-open/closed/error` chrome in each
+  app's header) — but only for the workspace socket, only per-remote, and
+  easy to miss.
+- Per-widget localized error text (AdditiveList, ResultRow, etc.) — good
+  where it exists, but only covers errors that make it back as `ok:false`.
+- Service-side JSON logs (`docker compose logs`) — invisible unless you go
+  terminal-side.
+- The known gotcha that the shell's DevTools console scrubs
+  Module-Federation cross-origin errors to `'Script error.'` (README §Get
+  started) — so even the console lies about remote failures.
+
+## What "fixed" plausibly looks like (directions, not decisions)
+
+- **A liveness view** — one surface (a shell page, a header popover, or a
+  didi-chat verb) showing green/red per: each federated remote's
+  `remoteEntry.js` reachability, workspace WS, NATS, each service
+  (heartbeat subject or `<service>.ping.requested`), SurrealDB reachability,
+  SearXNG. "Is everything fine?" should be one glance, not six terminals.
+- **Chrome-level indicators** — the shell header already knows the WS
+  state; it could aggregate remote-mount failures and show a single
+  degraded-state badge instead of remotes failing silently into blank
+  slots.
+- **Error surfacing pipeline** — capability failures (`ok:false`, timeouts)
+  should land somewhere visible by default (toast layer? a shell-owned
+  error rail? at minimum a dev-mode on-screen log), not just in whichever
+  component thought to render them.
+- **Dead-click insurance** — every wired affordance gives immediate
+  feedback (busy state within ~100ms) so "no reaction" reliably means
+  "not wired or broken," never "working silently."
+
+## Open questions
+
+- [ ] Heartbeat convention: per-service `*.ping.requested` subjects, or a
+  single workspace-service aggregator that checks its dependencies?
+- [ ] Where does the liveness view live — a shell surface, a remote of its
+  own, or a didi chat verb (`/status`)?
+- [ ] Does error surfacing ride the existing WS broadcast machinery
+  (an `error.raised` frame) or stay client-local?
+- [ ] Relationship to [[No-Test-Coverage-TDD-Deferred-Despite-Agentic-Fit]]
+  — tests catch regressions before ship; liveness tooling catches
+  environment/runtime failure after ship. Both attack "feels dead," neither
+  substitutes for the other.

context-v/issues/No-Component-Library-UI-Improvised-Not-Component-Based.md

@@ -0,0 +1,97 @@
+---
+title: "No component library — the UI is improvised per-remote instead of component-based, and it's starting to show"
+lede: "For expediency, agents have improvised working UI in each remote — and it worked, fourteen remotes' worth. But the bill is arriving: the UI is getting visually funky, near-identical widgets exist in parallel dialects (status pills, additive lists, candidate pickers, chip palettes), and a ton of code is almost certainly redundant. Time to decide what Component-Based Architecture means under this repo's copy-don't-depend rules."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Oversight
+  - Usability
+  - Augment-It
+  - Component-Library
+  - Design-System
+  - Microfrontends
+status: Open · Jotted
+---
+
+# No component library — improvised UI across fourteen remotes
+
+## The admission
+
+Every remote's UI was improvised by agents under ship pressure. Each app
+namespaces its CSS (`.rc-*`, `.pdr-*`, `.ow-*`, `.saa-*`, …) and re-invents
+the same organs locally. It worked — fourteen shipped remotes prove it —
+but the compounding costs are now visible:
+
+- **The UI is getting funky.** Sibling remotes solve the same problem with
+  slightly different visuals and behaviors; the app reads as a collection
+  of sessions, not a product.
+- **Redundancy.** Known near-duplicates, off the top of a scan:
+  - WS status pill + client badge header (every remote, copied N times)
+  - Additive URL list with ➕ form (org-workbench's `AdditiveList`;
+    affiliation-rating-resolver's four lists; person-enrichment's
+    `LinkList`)
+  - Candidate pickers with score + match_reason (record-db-resolver,
+    person-db-resolver, org-workbench's `AddPersonInline` gate)
+  - Connector/provider chip palettes (pack-runner, response-reviewer,
+    search-and-add)
+  - Debounced autocomplete (person-enrichment org picker, person-db-resolver,
+    org-workbench `OrgSearch`)
+  - Result/source rows with one-click action (response-reviewer,
+    strategy-curator `SourceList`, search-and-add `ResultRow`)
+- **Agent drift amplifies it.** Each new remote copies whichever sibling
+  the session happened to read, forking dialects further.
+
+## The constraint that shapes any fix
+
+Two standing rules bound the solution space:
+
+1. **No shared runtime dependency across the three ai-labs apps**
+   (augment-it / dididecks / memopop) — patterns travel knots-style
+   (blueprint + copy-from), never as a package across apps.
+2. **Within augment-it**, a shared package is allowed and precedented —
+   `packages/shared-ui` already exists (ConfidencePill, ToggleHeader) and
+   `packages/theme` proves the intra-repo-package path works across
+   federation (imported per-remote at build time, no shared federation
+   runtime).
+
+So the real question is *intra-repo*: grow `packages/shared-ui` into a real
+component library, or codify components as copy-templates with a canonical
+source per organ? (Or the hybrid: primitives in shared-ui, composites as
+copy-templates.)
+
+## Directions worth weighing (not decided)
+
+- **Inventory first.** A one-session audit producing the canonical list of
+  duplicated organs (the six above + whatever the sweep finds), each with
+  its "best current implementation" named — that's the component library's
+  table of contents regardless of packaging choice.
+- **DESIGN.md + tokens discipline.** The funkiness is partly visual drift;
+  `packages/theme` tokens exist but per-remote CSS re-hardcodes fallbacks
+  and spacing ad hoc. A DESIGN.md contract (per the maintain-design-md
+  practice) would give agents the palette of *moves*, not just colors.
+- **Migration is incremental by construction** — remotes are federated, so
+  each can adopt shared components one at a time; no big-bang.
+- **New-code rule candidate:** before writing a new widget, check the
+  inventory; extend-or-adopt beats improvise. (Belongs in CLAUDE.md and
+  the loop doc's plan-authoring step once the inventory exists.)
+
+## Open questions
+
+- [ ] `packages/shared-ui` as the home (build-time import per remote), vs
+  copy-template canon, vs hybrid — what's the deciding criterion?
+  (Leaning hybrid: primitives shared, flow-specific composites copied.)
+- [ ] Does Svelte 5 + module federation put any real constraint on sharing
+  components (each remote owns its Svelte runtime — components compile
+  per-remote, so likely fine — verify once with a real widget).
+- [ ] Sequence relative to [[No-Test-Coverage-TDD-Deferred-Despite-Agentic-Fit]]:
+  extracting components without tests risks silent regressions across
+  fourteen remotes; tests-then-extract or extract-with-tests-per-organ?
+- [ ] Relationship to the usability pass the v1 milestone named — the
+  component inventory and the usability iteration probably want to be the
+  same sweep.

context-v/issues/No-Test-Coverage-TDD-Deferred-Despite-Agentic-Fit.md

@@ -0,0 +1,91 @@
+---
+title: "No test coverage — TDD keeps getting deferred, despite being exactly the right fit for agentic development"
+lede: "Huge amounts of code get written, refactored, and rebuilt by agents with zero automated tests guarding key functionality. TDD is unusually well-suited to this codebase's working style — agents iterate until green, and tests are the durable spec of 'still works' across rewrites — but we've procrastinated it. Needs: pick the test environment for this stack, then climb incrementally to full coverage and full passing."
+date_created: 2026-07-24
+date_modified: 2026-07-24
+authors:
+  - Michael Staton
+augmented_with:
+  - Claude Code on Claude Fable 5
+semantic_version: 0.0.0.1
+tags:
+  - Issue
+  - Oversight
+  - Augment-It
+  - Testing
+  - TDD
+  - Agentic-Development
+status: Open · Jotted
+---
+
+# No test coverage — the deferred TDD debt
+
+## The admission
+
+We have been procrastinating TDD for expediency. The current verification
+culture is real but ad-hoc: typechecks, builds, one-off NATS proof scripts
+(`scripts/prove-*.mjs`), and manual walk-throughs. What's missing is the
+regression floor — when an agent rewrites a service or refactors a remote,
+nothing automatically asserts that the key functionality still works.
+
+## Why this matters MORE here, not less
+
+Two properties of agentic development make tests unusually high-leverage:
+
+1. **Volume and churn.** Agents write and rewrite at a rate where "a human
+   remembers what this touched" stops being real. Tests are the only
+   memory that runs.
+2. **The iterate-until-green loop.** Agents are natively good at "run
+   tests, fix, repeat until passing" — a failing test suite is a better
+   agent prompt than most prose. TDD converts agent effort from
+   plausible-looking code into converging code.
+
+The existing prove-scripts (Phase-1 acceptance style) are proto-tests —
+they already demonstrated the value (7/7 green as a standing regression
+across five phases). The gap is that they're bespoke, uncounted, and not
+run automatically.
+
+## Scope of the decision (not yet made)
+
+- **Test environment for this stack.** Candidates to evaluate against the
+  real shape (Svelte 5 runes + rsbuild federation remotes; TS services
+  over NATS; SurrealDB canonical layer):
+  - **Vitest** — the default gravity for TS/Svelte unit + service tests.
+  - **Svelte-component testing** — vitest + @testing-library/svelte, or
+    accept svelte-check as the floor and test components thinly.
+  - **Service/integration tier** — spin NATS (already in compose) and test
+    handlers request/reply style; the prove-scripts show the pattern.
+  - **Browser/E2E tier** — Playwright; overlaps deliberately with the
+    browser-drive rung (anchor-root blueprint
+    `Browser-Drive-Verification-For-Agent-Sessions.md`) — decide whether
+    E2E specs and browser-drives are one artifact or two.
+- **Where tests live** — per-package `*.test.ts` with a turbo `test` task
+  is the obvious shape; confirm.
+- **The canonical-layer problem** — service tests that touch SurrealDB
+  need either a disposable local instance, a test namespace, or
+  mocked-db seams. The no-test-entities-in-shared-canonical rule is
+  already standing; tests must honor it structurally.
+
+## The incremental path (sketch)
+
+1. Choose the environment (one decision doc).
+2. Wire the harness + turbo task + CI job so `pnpm test` exists and is
+   green-by-vacuous.
+3. Convert the existing prove-scripts into real tests (they're already
+   assertions with known-good fixtures).
+4. New-code rule going forward: capabilities ship with tests (the loop doc
+   `context-v/loops/Loop-through-Spec-Write-Plans-Implement-Test-Changelog-Commit.md`
+   gains a rung).
+5. Backfill by subsystem, highest-churn first (resolver service, workspace
+   capabilities router, social-search dispatch).
+
+## Open questions
+
+- [ ] One runner for everything vs. unit (vitest) + E2E (playwright) split?
+- [ ] CI: tests on every push to `rebuild/turbo-rsbuild`, or pre-push hook
+  locally first while the suite is small?
+- [ ] Coverage target semantics — "full coverage" as literal % or as
+  "every capability + every flow's happy path asserted"? (Leaning the
+  latter; % chasing on UI code is low-yield.)
+- [ ] Relationship to [[Live-Not-Live-Indicator-Tooling-And-Cross-Service-Error-Surfacing]] —
+  tests guard pre-ship, liveness guards runtime; both needed.