Главная Обзор Помощь
Вход
clanker
/
clanker-saddle
1
0
Ответвить 0
Файлы Задачи 0 Запросы на слияние 0 Вики
Дерево: 98bd6e30b9
Ветки Метки
clanker-saddle
/
docs
/
ux-notes.md

ux-notes.md 31 KB
История Исходник

ClankerSaddle web UI — structural layout critique

This is an opinions document about structure, not looks: the theme, colours and typography stay as they are. "Structure" here means page hierarchy (what leads a page, what folds away), information order, navigation between pages, where forms live, and density. Every claim below was read out of the templates in src/pages/ on the goal branch (after the SSE and HTML-escaping fixes landed), so the wireframes describe the app as it ships today.

How the app is built (why the recommendations look the way they do)

  • Every page is a Statum template compiled by statum-mkpstm: stm-text / stm-if / stm-for / stm-attribute / stm-markdown bind server state, stm-action submits sealed actions, and the page refreshes in place. The shared chrome lives in main.html: a header nav (Dashboard, Projects, Tasks, Goals, Saddles, Rules, Users, then the user cluster), one <main>, a footer.
  • The whole app renders inside a single 64rem column (body { max-width: 64rem } in app.css). There are exactly two layout primitives beyond that: .cards (an auto-fill card grid) and .grid-2 (the task page's 50/50 status/mandate grid, stacking below 40rem). No page uses a persistent two-column layout, a sticky sub-nav, or a sidebar.
  • task_log.html is the only page whose body is built by client JavaScript (createElement/textContent, filters, search, paging, SSE). Everything else is server-rendered bindings.
  • details/summary is the app's only progressive-disclosure device, and it is doing a lot of work it was not meant for (see the "expander fatigue" section).

Two capabilities notes used throughout:

  • stm-attribute can set any attribute (stm-attribute.href, .class, .value, .data-* already appear), so a section can be collapsed by binding hidden or a data-collapsed class to state, without client JS.
  • Client JS is not exotic: task_log.html, tasks.html (window.taskRowVisible + window.setTaskFilter) and goal_detail.html (window.goalSetFilter) already run page scripts that cooperate with statum's render cycle. A "sticky sub-nav that highlights the section in view" is a scroll listener plus one class toggle — the pattern already exists on this codebase.

The five structural themes

  1. Attention is buried under equal-weight sections. The detail pages are one long scroll of cards that all look equally important. The one thing a human must do (answer a block, review a plan) sits in card 2 or 3 of 11, between the status card and the plan history. Nothing in the page's shape says "act here".
  2. Reference material competes with action. Rules, capabilities, sessions, briefs, plan revision history — genuinely useful, read maybe once — render at the same weight and in the same column as the action surface, so a page visit for "approve the plan" scrolls past everything else.
  3. Expander fatigue. Every create and edit surface hides behind a <details> expander: New task, New goal, New project, New rule, New user, New capability, Register saddle, Edit task, Link a project, SSH key, Git identity, Edit rule, answered blocks, plan revisions, progress history. Disclosure is the right instinct for history; it is the wrong instinct for primary actions, where it inverts affordance (the most important button on the page is the least visible control).
  4. No "where am I". No breadcrumbs anywhere. "Back" is a manual anchor each page draws by hand ("← Goals", "All tasks", "All projects"), inconsistently placed (goal page: above the h2; task page: a context line under the h2 carrying project + enqueue chain). Cross-links exist (task→project, task→goal, goal→project) but the reverse links (project→its goals, task→its sessions' logs) are partial, so navigation is a one-way tree.
  5. Density mismatch. A five-word status line and a 400-word completion report both get a full-width card in the same column; the tasks table carries eight columns of which three are reference (goal, project, capabilities) that most visits do not need.

Page-by-page

1. Home / dashboard (home.html)

What it's for. The "is anything on fire / does anything need me" page: push bell, queue and saddle metrics, pinned needs-a-human blocks, active tasks with latest progress, saddle cards, recent activity.

Structural problem. The page opens with a full-width card whose entire content is one button pair ("Enable notifications — be told when an agent asks a question…"). Then two metric cards (Queue, Saddles). Only then comes the section the page exists for: "Needs a human". On a fresh install the attention content is below the fold; on a busy day the pinned cards — the actionable items — are squeezed between metrics above and two more full sections below (Saddles, Activity), so comparing a block against the task it came from means scrolling past a saddle grid.

Recommendations.

  • A. Move "Needs a human" to the top (S, low risk). Keep the bell but demote it: it is a settings action, not news. It can become a compact strip beside the metric cards, or move to the header's user cluster entirely (arguably where a notification preference belongs).
  • B. Put the metrics in a right-hand rail next to the attention column (M, low risk). One .grid-2-style row: left 2/3 pinned blocks + active tasks, right 1/3 Queue/Saddles metrics, the bell strip, and "Saddles" as a compact status list rather than cards.

  • C. Fold Activity under a collapsed expander with a "new since your last visit" count (S, low risk), or cap it at ~8 rows with "view all" — it is the page's only pure-read section.

    BEFORE (linear)                 AFTER (attention-first + rail)
+----------------------------+  +----------------------------+
| [Enable notifications ...] |  | NEEDS A HUMAN (3)          |
+----------------------------+  |  [block] [block] [block]   |
| [Queue]      [Saddles]     |  | ACTIVE TASKS               |
+----------------------------+  |  ...table...               |
| NEEDS A HUMAN (3)          |  +------------+---------------+
|  [block] [block] [block]   |  | Queue      | bell (compact)|
+----------------------------+  | Saddles    | saddle list   |
| ACTIVE TASKS               |  +------------+---------------+
|  ...table...               |  | ACTIVITY (collapsed, 3 new)|
+----------------------------+  +----------------------------+
| SADDLES (cards)            |
+----------------------------+
| ACTIVITY (full table)      |
+----------------------------+

statum notes. A and C need nothing new. B needs one CSS grid row plus the existing card markup; stm-if already gates the pinned section on dashboard.pinned.length.

2. Tasks list (tasks.html)

What it's for. The queue: find a task, judge the queue's shape, create a task.

Structural problems.

  • The create form is the page's only primary action and it is a collapsed expander above the table. New users' first act is to hunt for the form.
  • Eight columns (#, Title, Status, Mode, Goal, Priority, Project, Capabilities), three of which (Goal, Project, Capabilities) are reference attributes. On the 64rem column this is dense, and Priority is usually "5" noise.
  • The three filters (Status, Project, Goal) are bare <select>s with an inline hint ("— filters apply instantly") — functional but undiscoverable as filters: they read as form fields. They also carry no counts, so you cannot see the queue's shape without filtering.
  • The list has no server-side limit (TaskService.list_tasks returns every task newest-first) and terminal tasks accumulate forever. Done tasks from months ago share the page with the thing you came for.
  • It duplicates the create form that project detail doesn't have (project detail links back here instead — the reverse direction is a dead end).

Recommendations.

  • A. Default the list to "open work" (S, low risk): a draft/queued/assigned/working/blocked default with an explicit "show done/failed (N)" toggle. The filters exist already; this is a default-value change plus a chip.
  • B. Replace the three selects with faceted status chips + one "Project / Goal" select (M, low risk, client JS exists): the goal-detail page already has exactly this pattern (a goal-strip of status buttons with counts). Port it here and the two pages stop feeling like different apps.
  • C. Drop Mode / Priority / Capabilities to a per-row hover/expand or merge into one "meta" cell (S, low risk); keep the row scannable as # title — status — project.

  • D. Give "New task" a real button (S, low risk) — see the expander-fatigue section: an always-visible + New task button that opens the same form inline.

    BEFORE                              AFTER
+------------------------------+    +------------------------------+
| [New task >]  (collapsed)    |    | Tasks        [+ New task]    |
+------------------------------+    +------------------------------+
| Status[v] Project[v] Goal[v] |    | (draft 2)(queued 5)(working 3)|
|  — filters apply instantly   |    | (blocked 1)(done 214)        |
+------------------------------+    | Project/Goal [all v]  search |
| # | Title | St | Mode | Goal |    +------------------------------+
| Pri | Proj | Caps             |    | #  Title           Status    |
| ...8 columns...               |    | 42 Fix the SSE feed working  |
+------------------------------+    | 41 Escape entities  blocked  |
                                | ...project folded into title |
                                +------------------------------+

statum notes. B is the client-side taskRowVisible filter with counts derived from tasks.tasks (already shipped to the client) — no server change. A could also be server-side (default status filter in the entrypoint) if the "all" count needs to stay cheap.

3. Task detail (task_detail.html)

What it's for. The human's control surface for one task: watch progress, answer blocks, read the completion report, comment, tweak rules/capabilities, inspect sessions.

Structural problem. Thirteen h3 sections in one 64rem column, half of them full-width cards, in this order: Progress → Status card / Goal card / Mandate card (the one .grid-2 on the page) → Completion report → Edit task expander → Blocks → Comments → Rules → Required capabilities → Sessions. The page's actual verb — answer the block, approve the review — is the sixth thing you scroll to, and it sits between an edit expander and the comments thread. Meanwhile the Status card (five muted metadata lines plus buttons) takes half a screen width while the Mandate — the single most useful read — gets the other half at the same visual weight as "Created 3 days ago".

Recommendations.

  • A. Two zones: "Act" then "Understand" (M, medium risk). Zone 1 (top, full width): Progress line, Blocks (open ones first, full weight), Completion report. Zone 2: the status/mandate grid, comments, then a reference cluster.
  • B. An anchored sub-nav strip under the page title (Progress · Blocks · Report · Comments · Rules · Sessions) that scroll-jumps and highlights — a dozen lines of client JS over data-section ids. This is the cheap version of "restructure the page": it keeps the DOM order but gives the reader a map and a one-click path.
  • C. Cluster the low-traffic reference sections (Rules, Required capabilities, Sessions) into one "Configuration & history" region — either a single card with internal h4s or one collapsed expander with a summary line ("2 rules · 1 capability · 3 sessions").

  • D. The Sessions table's "Event log" link is the page's only per-session affordance and it is a link in a table row — surface it once at the top level ("View event log" beside Progress) since it is per-task, not per-session, anyway.

    BEFORE (13 sections, one column)   AFTER (Act / Understand / Reference)
+------------------------------+   +------------------------------+
| Progress                     |   | Progress        [Event log]  |
+------------------------------+   +------------------------------+
| Status | Goal | Mandate      |   | BLOCKS (1 open)              |
+------------------------------+   |  [question card + answer]    |
| Completion report            |   +------------------------------+
+------------------------------+   | COMPLETION REPORT            |
| [Edit task >]                |   +------------------------------+
+------------------------------+   | Status | Mandate    | Goal   |
| BLOCKS (1 open)   <- the verb|   +------------------------------+
+------------------------------+   | Comments                     |
| Comments                     |   +------------------------------+
+------------------------------+   | Configuration & history  (2) |
| Rules                        |   |  rules - caps - sessions     |
+------------------------------+   +------------------------------+
| Required capabilities        |
+------------------------------+   (sub-nav strip pinned under
| Sessions                     |    the title: Progress / Blocks /
+------------------------------+    Report / Comments / Config)

statum notes. B and C need no new patterns (stm-if, anchors, existing client-JS style). A is a re-ordering of existing cards; the risk is only that regulars re-learn where things are, so ship it with the sub-nav.

4. Task event log (task_log.html)

What it's for. The live transcript of one task: turn cards, commands, results, comments, transitions, usage — the forensic view when something went wrong.

Structural problems.

  • It is structurally unlike every other page (client-rendered feed in a 72vh scroller), which is fine for a transcript — but its toolbar (5 filter buttons + search) sits inside the card above the feed, so it scrolls away. For the page where you spend the most time scrolled deep, the controls should be pinned.
  • "Load older events" is a button above the feed — correct, since older history grows upward, but nothing indicates how much history remains or that the feed is a window onto a longer ledger.
  • There is no way back to the task's blocks/comments surface except the "Task page" text link at the top — the two pages are one investigation flow split across a page boundary, and the log opens in a new tab from the task page, which severs even the back button.
  • The feed and the task page's Progress/Sessions duplicate a job: "what has the agent been doing".

Recommendations.

  • A. Sticky toolbar (S, low risk): position: sticky; top: 0 on .log-toolbar inside the scroller, so filters/search survive deep scrolling. Add a "paused / live" affordance to the bottom-stick behaviour (the feed already knows whether it is pinned; expose it as a "jump to latest" button when not).
  • B. Context header, not a link farm (S): the page opens with "← Tasks" then "Event log" then "Task page · the unified event ledger…". Replace with a single header row: task id + title + status badge (the data is already in task_log), a back-chevron to the task, and the window note ("showing most recent 30") folded into the load-older control ("Load older events — 412 more").

  • C. Consider the log a tab of the task page rather than a separate URL (L, medium risk — a decision more than a build): either mount the feed component under a ?view=log tab on /tasks/{id} or keep the URL but add a persistent task-context strip so both pages share their sub-nav. This is the single highest-leverage navigation fix in the app: today the natural investigation loop (task → log → task) costs a tab and a reload.

    BEFORE                            AFTER
+----------------------------+    +----------------------------+
| <- Tasks                   |    | <- Task #42 "Fix SSE" [wg] |
| Event log                  |    +----------------------------+
| Task page - unified ledger |    | [cmds][res][cmts][tr][use] |
+----------------------------+    | [search____________] live  |
| [Show: cmds res cmts ...]  |    +----------------------------+
| [search]                   |    | ^ Load older (412 more)    |
+----------------------------+    +----------------------------+
| [Load older events]        |    |  14:02 turn 51             |
+----------------------------+    |  ...feed (sticky filters)  |
| 14:02 turn 51              |    |                            |
| ...feed scrolls...         |    |              [jump to end] |
+----------------------------+    +----------------------------+

statum notes. A and B are pure client CSS/markup inside the page that already owns its rendering. C needs either the feed lifted into a fragment included by the task page (partials already exist — see progress_feed.html, goal-branches) or a shared context strip; both are proven patterns.

5. Goal detail (goal_detail.html)

What it's for. The supervision surface for one goal: status and lifecycle actions, agent progress, plan review, block answering, the task fan-out table, the brief, rules, narrative, comments.

Structural problem. Eleven sequential cards — Status, Agent progress, Goal agent blocks, Completion review, Plan, Tasks, Initial brief, Involved projects, Rules, Supervision narrative, Comments, (Goal agent runs) — in one column, all at the same weight. The good news is the order is already attention-first (blocks and the pending plan review sit above tasks and brief — the comments in the template say so). The problem is depth and differentiation: to check "has the plan been approved yet?" you scroll past status, progress, blocks, and completion review, then find the Plan card whose content is a collapsed expander ("Approved plan & revisions (N)"). The Tasks card embeds a 6-column table with its own client-side status-filter strip — a second, different filtering UI on the same site (see tasks list). Reference cards (Rules, Involved projects) sit between the action surface and Comments, so a conversation with the agent is a long scroll from the question you are answering.

Recommendations.

  • A. Make the page's state legible in one line (S, low risk): a compact "goal strip" at the top — status badge, the one open item ("1 question waiting · plan revision 2 pending"), and the primary lifecycle button (Start / Pause / Retry). The Status card keeps the detail (branches, compare, saddle, timestamps) but the reader gets the verdict without parsing it.
  • B. Two-column attention-first layout on wide screens (M, medium risk): left column = Status, Agent progress, Blocks, Plan review, Completion review, Comments (everything a human acts on); right column = Tasks, Initial brief, Involved projects, Rules, Supervision narrative, Runs (everything a human consults). The single 64rem column is the core reason this page reads as "12 cards in a trenchcoat"; splitting the reading column from the acting column fixes it without touching the theme.
  • C. Sub-nav strip as per task detail (Status · Blocks · Plan · Tasks · Brief · Narrative · Comments) — pairs well with B, and makes B optional if you want the smaller change first.

  • D. Unify the tasks-filtering pattern with the tasks list (the goal page's goal-strip is the better UI — port it up to /tasks, not the other way).

    BEFORE (11 cards, 1 column)        AFTER (act | consult)
+----------------------------+    +--------------+---------------+
| Status                     |    | ACT          | CONSULT       |
+----------------------------+    | Status (cmpct)| Tasks        |
| Agent progress             |    | Progress      |  (filter     |
+----------------------------+    | BLOCKS (1)    |   strip)     |
| Goal agent blocks          |    | Plan review   | Initial brief|
+----------------------------+    | Completion    | Projects     |
| Completion review          |    | Comments      | Rules        |
+----------------------------+    |               | Narrative    |
| Plan (usually collapsed)   |    |               | Runs         |
+----------------------------+    +--------------+---------------+
| Tasks (own filter strip)   |
+----------------------------+    sub-nav: Status / Blocks / Plan /
| Initial brief              |    Tasks / Brief / Narrative / Comments
+----------------------------+
| Involved projects          |
+----------------------------+
| Rules / Narrative /        |
| Comments / Runs            |
+----------------------------+

statum notes. A is stm-if + expression text over data the entrypoint already publishes (open_blocks, plan_pending_block). B is one CSS grid + card re-parenting; the risk is mobile (stack Act-then-Consult, which the existing 40rem breakpoint pattern already handles). C is the same client JS as task detail.

6. Saddles (saddles.html)

What it's for. Fleet health and configuration: per-saddle status, current work, SSH keys, git identity, capabilities; the capability tag catalogue at the bottom.

Structural problems.

  • The card grid is right for this page, but each card is a long stack of paragraphs (status, work, health line, token, SSH key expander, git identity expander, capability chips, add-capability form, Refresh/Remove buttons). "What is this saddle doing?" — the question you ask daily — is the second of nine blocks, and the admin machinery (keys, identity) crowds it.
  • The Capabilities section at the bottom is a different modality (table) bolted under a card grid; it reads like a second page appended to the first.
  • Health is expressed as three separate text fragments (health badge, daemon state, up X, contacted Y ago) instead of one verdict.

Recommendations.

  • A. Split each card into a "now" head and an "admin" tail (S, low risk): head = name, status badge, health verdict (one line), current work; tail (already-expanders, keep them) = key, identity, capabilities, token, actions. Visual anchor: the head is the card's first ~3 lines; everything else folds.
  • B. Surface "unhealthy" at the top of the page (S): if any saddle is offline/stale/fenced, one summary line above the grid ("1 of 3 saddles stale — dispatcher may be starved"), linking to the card. The dashboard's idle-count metric does not currently tell you this.

  • C. Keep the capabilities table but visually separate it (S) — its own h2-level section ("Routing tags") rather than an h3 after the grid, so the page reads as two deliberate sections.

    BEFORE (one 9-block card)          AFTER (now head / admin tail)
+--------------------------+      +--------------------------+
| saddle-1                 |      | saddle-1        [busy]   |
| [busy] localhost:7100    |      | healthy - up 3d - 12s ago|
| Supervising goal: X      |      | Supervising goal X (2h)  |
|  since 2h                |      +--------------------------+
| [healthy] daemon idle ...|      | [Keys & admin v]         |
| API token: ...           |      |   key / identity / caps /|
| [SSH public key v]       |      |   token / refresh/remove |
| [Git identity v]         |      +--------------------------+
| Capabilities: [gpu] [x]  |
| [Add capability v]       |
| [Refresh] [Remove]       |
+--------------------------+

statum notes. All three are markup re-orders inside existing patterns (stm-if, details, badges); B is an expression over saddles.saddles the page already iterates.

Shorter notes

Projects list (projects.html) and project detail

  • List: table is fine; "New project" is the expander problem again (give it a button). The Git URL column is long noise — truncate with the branch column into one "repo" cell.
  • Detail: "Details" and "Edit" as two side-by-side cards is odd — the Edit card is a form for exactly what Details displays. Make Details the read view with an in-place Edit toggle (the data-long-form in-place editor pattern from task/goal briefs already exists in main.html and is a better fit here), freeing the second column for "Tasks in this project".
  • Project detail has no create-task surface and links out to /tasks; with a ?project= pre-fill that becomes a flow instead of a detour. It also lists tasks but not the project's goals — the reverse cross-link gap.

Goals list (goals.html)

  • Same expander-pattern note for "New goal". The brief is a required 6-row textarea — the goal's most important field — hiding behind a collapsed summary; fine once expanded, invisible until then.
  • The Tasks column packs four counts into one muted string ("2 draft / 5 queued / 3 running / 14 done") — unreadable; four tiny badges (the goal-strip chip pattern again) or just "19 tasks, 3 running" would carry more signal per pixel.
  • No status filter on the list at all, unlike tasks — the same chip strip would fix both consistency and scanning.

Rules (rules.html)

  • Each rule is a full-width card with body, then an Edit expander and a bare Delete button outside the expander — a destructive action more prominent than the edit one. Invert: Edit as the in-place editor pattern, Delete inside a "danger" expander or behind the existing confirm alone but visually secondary.
  • No list of where a rule is attached (projects/tasks using it) — the page says rules attach on project/task pages but you cannot see the blast radius of a delete from here. A reference list, not a theme change.

Users (users.html) and profile

  • Users: admin-only, table plus expander create form — acceptable, lowest traffic in the app. Same "New user" button note applies.
  • Profile: fine structurally; the change-password form could sit in a card for consistency, and this is the natural home for the notification preference currently occupying the dashboard's first card.

Login

  • No structural complaints: inline error handling, focused field, narrow form. Good.

Expander fatigue — the cross-cutting fix

Counted across the app, <details> currently serves three distinct jobs with one widget:

  1. History folding (progress history, answered blocks, plan revisions, submitted markdown) — this is the right tool; keep it.
  2. Primary create forms (new task, goal, project, rule, user, capability, register saddle) — wrong tool: it hides the page's main action. Replace with a persistent button (+ New task) that opens the form inline (a data-* toggle + hidden, exactly the data-long-form / data-lf-toggle pattern in main.html), or render the form directly on low-traffic pages where there is room (rules, projects).
  3. Admin/config editing (SSH key, git identity, edit task, edit rule) — defensible, but prefer the in-place editor (read view + Edit toggle) where the form is short, because it shows the current values in place instead of a cold empty form.

Rule of thumb proposed: history folds, actions surface.

Navigation — the cross-cutting fix

  • Breadcrumbs on detail pages (S): Dashboard / Tasks / #42 (or Goals / #7 🎯), replacing the hand-drawn "← Goals" / "All tasks" anchors that each page currently invents. One shared partial (pstm-fragment already powers progress-feed, goal-branches) makes it consistent for free.
  • Reverse links: project detail lists its tasks but not its goals; task detail's sessions link out to the log but the log links back only to the task. The dashboard's cross-links are the model to copy: pinned blocks deep-link to the exact task or goal, and saddle cards link to the saddle's current work.
  • The log-in-a-new-tab decision (see event log, C) is the one navigation break that costs the most; everything else is polish.

Quick wins (a day or less each)

  1. Dashboard re-order: Needs-a-human first, bell compacted (S).
  2. Faceted status chips with counts on /tasks, defaulting to open work (M but a port of existing goal-strip code).
  3. Breadcrumb partial across detail pages (S).
  4. + New … buttons replacing create-form expanders (S, per page).
  5. Sticky toolbar + jump-to-latest on the event log (S).
  6. Task detail: cluster Rules + Capabilities + Sessions into one collapsed "Configuration & history" region (S).
  7. Goal page: one-line state strip above the Status card (S).
  8. Saddles: card head/tail split + fleet health summary line (S).
  9. Goals list: readable task-count badges + status chips (S).

Structural bets (multi-day)

  1. Act / Consult two-column layout for goal detail (and optionally task detail) — the biggest single improvement to the app's most-used deep pages; needs a responsive fallback.
  2. Anchor sub-nav on the two detail pages (Progress · Blocks · Plan · …) with in-view highlighting — a new (small) client-side pattern, ~a day including polish.
  3. Task page ↔ event log unification: shared context strip or a tabbed task page (Overview | Log), turning two URLs and a new tab into one investigation flow.
  4. Saved views / URL state for the tasks list (filters in the query string, shareable "my blocked tasks" views) — needs the entrypoint to read the query string or a small client state sync; the current client-side filtering deliberately exists because statum's fetch doesn't carry the page query string, so this is the one item that brushes against that limitation.
  5. Cross-entity "work" stream: one feed joining task progress, goal narrative and event-log highlights, replacing three different feeds with different row grammars (activity table, narrative card, event log). Large; only worth it if the dashboard stays the daily driver.

Capability appendix — what needs what

Already possible with today's statum.js patterns (stm-for, stm-if, stm-attribute, stm-markdown, details, pstm-fragment partials, per-page client JS as in task_log / tasks / goal_detail):

  • Every quick win above (1–9): chips, breadcrumbs, buttons, sticky toolbar, clustering, strips, head/tail cards.
  • The Act/Consult two-column layouts: pure CSS grid + re-parenting existing cards; stm-if gates each card's visibility already.
  • In-place editors replacing expanders: the data-long-form machinery in main.html is generic — reuse it for project edit and rule edit.

Needs a new (small) pattern or a server change:

  • Sub-nav with in-view highlight: a scroll listener + class toggle; no statum change, but it is a new client-side idiom for server-rendered pages (only task_log carries this much JS today).
  • URL-state filters / saved views on /tasks: either the entrypoint learns the query string (server change; the template comment in tasks.html says the statum entrypoint fetch does not carry it) or the client owns filter state in location.hash.
  • Task↔log unification: fragment-include of a client-rendered component inside a server-rendered page, or a shared context strip; both are compositions of existing pieces but need real design care around the SSE lifecycle on tab switches.