;
+ children?: ReactNode;
+}) {
+ return (
+
+ );
+}
diff --git a/docs/architecture.md b/docs/architecture.md
index deafecf..ac8d4fc 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -382,7 +382,7 @@ Practice turns the graph into problem sets the learner reasons through out loud.
**The jobs pattern — registry, not JobRecords.** Practice runs are NOT Workbench jobs: no `JobStore` records, no steer messages, nothing ever wakes the teacher — a practice run isn't chat-scoped (a set outlives its birth session and has no lesson to re-enter; its result is itself, persisted in its own store and read by its own page). What it shares with the Workbench is the observability surface: a `globalThis` run registry (the module-instance idiom — `__lhPracticeRuns`) with PER-PROBLEM ROWS (owner ruling, 2026-09-29 — matching the extraction per-chunk pattern): `setId:partition` while the partitioner runs ("Partitioning — title"), then one `setId:gen:problemId` per problem ("queued"→"generating", label "Problem i/N — title"), and one `setId:grade:problemId` per graded answer ("queued"→"grading", "Grading i/N — title") — each row its OWN abort controller and its OWN usage accumulation; the row key IS the feed id (the dock dup-key law) and the abort target. ABORT ROUTES BY ROW SHAPE: a gen-row abort kills THAT problem only (siblings continue; the set still settles `ready` with one errored problem), a partition-row abort ends the whole run, a grade-row abort drops that grade (answer kept — one attempt, the problem stays done); set-level abort (delete) composes from row aborts plus the synchronous persisted marks. Model calls — partitioner included — run under the SHARED background-LLM semaphore (`bg-llm-semaphore.ts`): one process-wide pool of 3 permits for ALL background LLM jobs, extraction chunks included (total background LLM concurrency bounded at 3, whoever calls). A boot sweep marks orphaned `partitioning`/`generating` sets as `error "Interrupted (server restarted)"` — once per process, and only when the set's `updatedAt` heartbeat is >120s stale (a live run's 30s FILE watchdog keeps the heartbeat fresh even across dev's per-worker processes — the registry is not shared between them; the guard trio closed a live-stamping bug from the first live test) — the job runner's crash-honesty at set grain. Store writes serialize behind a per-set mutex; the pipeline is the sole writer of `data/practice`.
-**API + UI.** Creation is GRAPH-DOMAIN, not chat-domain (owner ruling 2026-09-29: "problem sets always take in nodes — graph objects"): `POST /api/practice/sets` takes `{nodeIds, params, title?, note?}` ONLY — no chatId, no clusterId; the UI resolves a picked cluster to its member node ids and passes the cluster's label as the title. The `note` is the learner's optional free-form creation input (owner, same evening: more learner control, no other purpose): trimmed, capped at 2000 characters, persisted on the set, and carried to the partitioner and every generator as `THE LEARNER'S NOTE` — an additional input the agents WEIGH but are never obliged to follow (the doctrine pins the stance: it never moves a problem off its rung or out of its band, and the partition laws always win). `GET /api/graph/clusters` serves the picker: the birth-session partition itself (`birthSessionPartition`, same ordering — size desc, ties by id) — EVERY group regardless of size (owner ruling, same evening: MIN_CLUSTER_SIZE is a hull-drawing rule; practice availability must not inherit a visual threshold), each as `{key, kind: "chat"|"notes", label, nodeIds, nodeCount}`; a cluster whose naming record is gone keeps `label: null` — honest, never guessed. 202 `{id}` with generation fire-and-forget; 400 empty selection (empty intersection with live nodes — the vanished-nodes edge) / bad params; 503 model/key refusal. `GET /api/practice/sets` · `GET/DELETE /api/practice/sets/[id]` (delete aborts live runs first) · `POST /api/practice/sets/[id]/answers` (202; 409 when not ready; 400 re-answering a submitted problem — one attempt). Surfaces: `/practice` (the list — the chat-pattern top bar with the sidebar reopen toggle and the New action at the right edge, status/counts rows, delete confirm, the new-set dialog with the named-level controls (a 5-detent ladder slider, a 3-detent cue slider, a Theory|Application toggle — each showing the level's name + definition), the cluster picker, and the optional free-form note textarea (typing-only). The SECOND creation entry (owner redesign, same evening): the graph view's **chain table** — a `Chains` button in the graph chrome (empty graph: hidden) opens a FULL-BLEED table overlay (absolute inside the graph area; the blur + translucent background IS the surface, no inner card; its own top bar carries the info + the close button, `lh-no-drag` so home's window-drag mask never eats it; Esc or X dismiss). The hierarchy is three levels, one click each: CLUSTER (the birth session — a chat or a notes file; a chain lives where its CONCLUSION was born) → REASONING CHAIN → PROPOSITION STATEMENTS — expanding a chain reveals its members' statement text directly (names live in the chain line, never twice; a singleton reveals its one statement in a single click); everything starts collapsed. The table look (owner ruling: "it should really resemble a table"): drawn hairline row + column lines, sortable column headers on Name + Created (click toggles asc/desc; the size column is text, not a control; default Name A→Z). In the chain line every proposition name is a faint-outlined CHIP with the → a clearly separated connector between chips — a lonely chip reads as a standalone proposition (the "(no premises)" annotation is dead in the visible UI; it survives only as the row's aria-label); icons: clusters FolderIcon (open-folder when expanded), chains WaypointsIcon, propositions chip-only; chevrons rotate with expansion. Selection is checkboxes on whole clusters, chains, or single propositions — a flat node-id set (a node in several chains is one selection) — accumulated in a FLOATING BOTTOM BAR (the Google-Photos pattern: appears only when something is selected, never shifts the table layout) showing the agents' ACTUAL input (`chainsForSelection` over the selection: a premise picked without its conclusion counts as the singleton it becomes) as `N propositions → M chains`, with Clear and **Generate problem set** (the one action for now — the bar is a neutral action slot), which opens the SAME creation dialog in **custom mode**: no cluster picker — a selection summary (the derived shape + the dated default title the pipeline will stamp) — posting `{nodeIds, params, note}` with no title. A fuzzy search (names, aliases, statements) filters chains grouped + auto-expanded under their clusters (non-matching clusters hide; the collapsed view returns on clear). NO understanding-levels column (explicitly not built). The overlay is read-only toward the graph and `/practice/[id]` (the exam page — the chat-pattern top bar, a levels + status line, numbered problems, markdown statements with math healing at the display seam, a textarea + focus-gated dictation bar per problem with its OWN Submit button — one attempt per problem, instant solution/rubric reveal, the score landing live). Entry: the sidebar's Practice nav row.
+**API + UI.** Creation is GRAPH-DOMAIN, not chat-domain (owner ruling 2026-09-29: "problem sets always take in nodes — graph objects"): `POST /api/practice/sets` takes `{nodeIds, params, title?, note?}` ONLY — no chatId, no clusterId; the UI resolves a picked cluster to its member node ids and passes the cluster's label as the title. The `note` is the learner's optional free-form creation input (owner, same evening: more learner control, no other purpose): trimmed, capped at 2000 characters, persisted on the set, and carried to the partitioner and every generator as `THE LEARNER'S NOTE` — an additional input the agents WEIGH but are never obliged to follow (the doctrine pins the stance: it never moves a problem off its rung or out of its band, and the partition laws always win). `GET /api/graph/clusters` serves the picker: the birth-session partition itself (`birthSessionPartition`, same ordering — size desc, ties by id) — EVERY group regardless of size (owner ruling, same evening: MIN_CLUSTER_SIZE is a hull-drawing rule; practice availability must not inherit a visual threshold), each as `{key, kind: "chat"|"notes", label, nodeIds, nodeCount}`; a cluster whose naming record is gone keeps `label: null` — honest, never guessed. 202 `{id}` with generation fire-and-forget; 400 empty selection (empty intersection with live nodes — the vanished-nodes edge) / bad params; 503 model/key refusal. `GET /api/practice/sets` · `GET/DELETE /api/practice/sets/[id]` (delete aborts live runs first) · `POST /api/practice/sets/[id]/answers` (202; 409 when not ready; 400 re-answering a submitted problem — one attempt). Surfaces: `/practice` (the list — THE shared **TopBar** (`components/top-bar.tsx`, standardization ruling 2026-09-29: one element, every surface — h-15 matching the sidebar's wordmark band, `lh-drag` with `lh-no-drag` carve-outs on interactive children, `select-none` so drags never highlight, the SidebarToggle reopen with its Electron traffic-light gutter, `px-3` + one border line; chat's rename mode passes `drag={false}` — the one escape hatch) with the New action at the right edge, status/counts rows, delete confirm, the new-set dialog with the named-level controls (a 5-detent ladder slider, a 3-detent cue slider, a Theory|Application toggle — each showing the level's name + definition), the cluster picker, and the optional free-form note textarea (typing-only). The SECOND creation entry (owner redesign, same evening): the graph view's **chain table** — a `Chains` button in the graph chrome (empty graph: hidden) opens a FULL-BLEED table overlay (absolute inside the graph area; the blur + translucent background IS the surface, no inner card; the top bar is THE shared TopBar — the standard title size and drag mechanics, the sidebar reopen, and the close X at the right edge, so home's window-drag mask never eats it (the overlay covers home's floating header while open, and the TopBar's own toggle is the reopen path); Esc or X dismiss). The hierarchy is three levels, one click each: CLUSTER (the birth session — a chat or a notes file; a chain lives where its CONCLUSION was born) → REASONING CHAIN → PROPOSITION STATEMENTS — expanding a chain reveals its members' statement text directly (names live in the chain line, never twice; a singleton reveals its one statement in a single click); everything starts collapsed. The table look (owner refinements, evening round 2): PROMINENT indentation carries the hierarchy (chains deep under their folder, statements deepest) and the ONLY lines left are the horizontal separators between cluster groups — per-row lines and the vertical column hairlines are gone ("anything else is better without them"); statement rows are PLAIN (the derivation already lives in the chain line — no conclusion marker). ALL THREE columns sort (owner: "consistency is key") — Name (A→Z default), Props (largest-first), Created (newest-first) — click toggles asc/desc, ordering both cluster rows and chains within; a SMALL chevron marks the active header. In the chain line every proposition name is a faint-outlined CHIP with the → a clearly separated connector between chips — a lonely chip reads as a standalone proposition (the "(no premises)" annotation is dead in the visible UI; it survives only as the row's aria-label); icons: clusters FolderIcon (open-folder when expanded), chains WaypointsIcon, propositions chip-only; chevrons rotate with expansion. Selection is checkboxes on whole clusters, chains, or single propositions — a flat node-id set (a node in several chains is one selection) — accumulated in a FLOATING BOTTOM BAR (the Google-Photos pattern: appears only when something is selected, never shifts the table layout) showing the agents' ACTUAL input (`chainsForSelection` over the selection: a premise picked without its conclusion counts as the singleton it becomes) as `N propositions → M chains`, with Clear and **Generate problem set** (the one action for now — the bar is a neutral action slot), which opens the SAME creation dialog in **custom mode**: no cluster picker — a selection summary (the derived shape + the dated default title the pipeline will stamp) — posting `{nodeIds, params, note}` with no title. A fuzzy search (names, aliases, statements) filters chains grouped + auto-expanded under their clusters (non-matching clusters hide; the collapsed view returns on clear). NO understanding-levels column (explicitly not built). The overlay is read-only toward the graph and `/practice/[id]` (the exam page — the shared TopBar, a levels + status line, numbered problems, markdown statements with math healing at the display seam, a textarea + focus-gated dictation bar per problem with its OWN Submit button — one attempt per problem, instant solution/rubric reveal, the score landing live). Entry: the sidebar's Practice nav row.
**Model wiring.** Three roles — `partitioner`, `problemGenerator`, `grader` — all pinned to the **strong** slot (quality-critical, one settings edit from cheap) and in `BACKGROUND_MODEL_ROLES` (per-role overrides). The stage agents are single-submit loops on the shared `runSubmitAgent` seam (`submit-agent.ts`, extracted from extraction for exactly this): a `validate` hook turns a bad submit into a tool-input error the model retries against, within `maxTurns 4`; exhaustion fails the stage honestly (the set says so, the chains re-run cleanly on a new set).
@@ -469,7 +469,7 @@ All deterministic, no network: engines are injected (pi-ai's **faux provider**
1. **Pure core units** — merger via real adapters, derivation, coverage, question grading, plan tree, phases, clusters, layout, tool-parts, prices, fuzzy search.
2. **Server flows** — `handleChatRequest` driven end-to-end with scripted faux engines: persistence, liveness, steer claiming, the wake pipeline (409 retry, quiz deferral, idempotency), crash recovery, the data-dir seam (including a fresh child process).
3. **Sub-agent loops** — researcher/demo-builder/visual-maker with fake headless APIs; the extraction pipeline end-to-end (audit drops, failure-checkpoints-nothing, single-flight, abort); the practice pipeline end-to-end (partition echo/coverage retries, failure isolation, semaphore width, abort mid-generation, grading, boot sweep).
-4. **Render tests** — transcript, cards, docks, composer, sidebar, coverage, stats, practice surfaces (creation dialog both modes, chain table, list, exam states) via React server-side rendering (`renderToStaticMarkup`), no DOM library.
+4. **Render tests** — transcript, cards, docks, composer, sidebar, coverage, stats, practice surfaces (creation dialog both modes, chain table incl. the shared-TopBar + lines-law pins, list, exam states) via React server-side rendering (`renderToStaticMarkup`), no DOM library.
Gates on every change: `tsc` clean, all tests, `eslint` clean, `next build` clean.
diff --git a/tests/render-chain-table.test.tsx b/tests/render-chain-table.test.tsx
index 0e53f8a..dbe54a2 100644
--- a/tests/render-chain-table.test.tsx
+++ b/tests/render-chain-table.test.tsx
@@ -7,9 +7,16 @@
* directly — names live in the line, never twice), proposition CHIPS +
* → connectors (a lonely chip = a standalone proposition; the "(no
* premises)" annotation is dead), rotating chevrons, folder/waypoints
- * icons, hairline table lines, sortable Name + Created headers, a
- * floating bottom selection bar that never shifts layout, and a fuzzy
- * search that auto-expands matching clusters.
+ * icons, a floating bottom selection bar that never shifts layout, and
+ * a fuzzy search that auto-expands matching clusters.
+ *
+ * ROUND 2 (owner refinements, 2026-09-29 late): the top bar is THE
+ * shared TopBar (h-15, lh-drag + select-none, sidebar reopen, standard
+ * title size); PROMINENT indentation carries the hierarchy — the ONLY
+ * lines left are the separators between cluster groups (vertical column
+ * hairlines and per-row lines are gone); statement rows are PLAIN (no
+ * conclusion marker); ALL THREE columns sort (Props too — consistency)
+ * with a SMALL chevron on the active header.
*/
import React from "react";
@@ -115,6 +122,29 @@ describe("ChainTableBody — clusters (the outermost layer)", () => {
});
});
+describe("ChainTableBody — THE shared TopBar + the lines law (owner, round 2)", () => {
+ it("the body renders the standardized top bar: h-15, lh-drag, select-none, standard title size, close X", () => {
+ const html = render();
+ assert.ok(html.includes("lh-drag"), "the window-drag band");
+ assert.ok(html.includes("select-none"), "dragging never highlights the title");
+ assert.ok(html.includes("h-15"), "the standard height");
+ assert.ok(html.includes('font-title text-3xl tracking-tight">Chains<'), "the standard title size");
+ assert.ok(html.includes('data-testid="chain-table-close"'), "the close X");
+ assert.ok(html.includes('data-testid="chain-table-search"'), "the search input");
+ });
+
+ it("the ONLY lines are the separators between cluster groups — no per-row or vertical lines", () => {
+ const html = render({ expandedClusters: new Set(["chat1"]) });
+ // group wrappers: every group but the last carries the separator
+ const sep = html.split("border-b border-border/60").length - 1;
+ assert.ok(sep >= 2, "separators between groups");
+ // chain rows themselves carry NO border — their entire class list is
+ // the indent law (pl-11 under the cluster folder, owner round 2); the
+ // chip outlines' border-border/70 is an outline, not a row line
+ assert.ok(html.includes('class="flex items-center gap-1 py-1 pl-11 pr-3"'), "the chain row: indent, no border");
+ });
+});
+
describe("ChainTableBody — chain rows (chips + connectors)", () => {
it("names render as outlined chips with → connectors BETWEEN them", () => {
const html = render({ expandedClusters: new Set(["chat1"]) });
@@ -143,7 +173,7 @@ describe("ChainTableBody — chain rows (chips + connectors)", () => {
assert.ok(html.includes('aria-label="Premise one, Premise two → Conclusion"'));
});
- it("expanding a chain reveals member STATEMENTS directly — names never twice, conclusion marked", () => {
+ it("expanding a chain reveals member STATEMENTS directly — PLAIN rows, no conclusion marker (owner, round 2)", () => {
const html = render({
expandedClusters: new Set(["chat1"]),
expandedChains: new Set(["c1"]),
@@ -151,20 +181,26 @@ describe("ChainTableBody — chain rows (chips + connectors)", () => {
assert.ok(html.includes('data-testid="prop-row-a"'), "premise statement row");
assert.ok(html.includes("Statement A."), "the statement text, one click deep");
assert.ok(html.includes("Statement C."), "the conclusion statement");
- assert.ok(html.includes('data-testid="prop-conclusion-c1"'), "the conclusion marker");
- // premise rows carry no conclusion marker
- const aRow = html.split('data-testid="prop-row-a"')[1]?.split('data-testid="prop-row-')[0] ?? "";
- assert.ok(!aRow.includes("prop-conclusion"), "premises unmarked");
+ // owner ruling: the derivation is already encoded in the chain line —
+ // no conclusion marker down here
+ assert.ok(!html.includes("prop-conclusion"), "no conclusion marker anywhere");
+ // statements indent DEEPEST (pl-[4.75rem]); chains pl-11 under clusters
+ assert.ok(html.includes("pl-[4.75rem]"), "the deepest indent");
+ assert.ok(html.includes("pl-11"), "the chain indent");
});
});
describe("ChainTableBody — the sortable table headers", () => {
- it("Name + Created are sort controls with aria-sort; Props is plain text", () => {
+ it("ALL THREE columns are sort controls with aria-sort (owner: consistency is key)", () => {
const html = render();
assert.ok(html.includes('data-testid="sort-name"'));
+ assert.ok(html.includes('data-testid="sort-props"'));
assert.ok(html.includes('data-testid="sort-created"'));
assert.ok(html.includes('aria-sort="ascending"'), "default name A→Z");
- assert.ok(!html.includes('data-testid="sort-props"'), "size is text, not a control");
+ // the small chevron (size-3 lucide) marks the ACTIVE header only —
+ // no giant text triangles (owner, round 2)
+ assert.ok(html.includes('lucide-chevron-up size-3'), "small up chevron on active name");
+ assert.ok(html.includes('lucide-chevron-down') === false, "no down chevron while ascending");
});
it("descending state shows on the active header only", () => {
@@ -172,6 +208,20 @@ describe("ChainTableBody — the sortable table headers", () => {
assert.ok(html.includes('data-testid="sort-created"'));
assert.ok(html.includes('aria-sort="descending"'));
assert.ok(html.includes('aria-sort="none"'), "the inactive column");
+ assert.ok(html.includes('lucide-chevron-down size-3'), "small down chevron");
+ });
+
+ it("Props sort orders cluster rows AND chains within (largest-first by default)", () => {
+ const html = render({ sort: { col: "props", dir: 1 }, expandedClusters: new Set(["chat1"]) }); // ascending: smallest first
+ const unlabeled = html.indexOf("cluster-group-\0unlabeled");
+ const notes = html.indexOf('data-testid="cluster-group-notes1"');
+ const chat = html.indexOf('data-testid="cluster-group-chat1"');
+ assert.ok(unlabeled > 0 && notes > 0 && chat > 0, "all three groups render");
+ assert.ok(unlabeled < notes && notes < chat, "1 < 2 < 4 member ids ascending");
+ // within chat1: the singleton (1) sorts before the three-member chain
+ const soloRow = html.indexOf('data-testid="chain-row-solo"');
+ const c1Row = html.indexOf('data-testid="chain-row-c1"');
+ assert.ok(soloRow > 0 && c1Row > 0 && soloRow < c1Row, "chain sizes ascending within the cluster");
});
});