Finding
Four Read-path design priors verified against theatron's current scope (a Dioxus/Blitz desktop UI plus a local agent server). All four survived adversarial re-verification of their cited path:line; none propose taking a dependency or carrying code — each names a design shape to reimplement from scratch if and when its trigger condition holds. All four are adopt-later; none apply to theatron as it stands today (self-branded tokens, loopback-only server, no persistent chat-stream reconnect surface, no visual-checkpoint mechanism), so this issue's job is to record the shapes and their triggers, not to schedule work now.
Candidate table
| Repo |
Licence |
Extract for |
Disqualifiers |
| cathrynlavery/diagram-design |
MIT (bundles Tabler Icons MIT + Simple Icons CC0) |
Design-token inference shape — confidence label per value, hard quality gate before proposing, provenance receipt (skills/diagram-design/references/onboarding.md:105-150) |
Solves external-brand/site-skin onboarding; theatron's tokens are fleet-declared, not scraped, so the mechanism has no current consumer |
| HKUDS/CLI-Anything |
Apache-2.0 |
Checkpoint protocol shape — immutable snapshot + mutable live head + append-only trajectory + compact status call (cli-anything-plugin/preview_bundle.py:70-89,171-223,329-359,405-468; docs/PREVIEW_PROTOCOL.md:72-89) |
Single-machine/single-operator scoped, no multi-viewer story; theatron has no visual-checkpoint mechanism to attach it to, and text/code continuity is already covered by PR/issue/git-log |
| agegr/pi-web@2a6e537 (shallow clone) |
MIT |
Local-server request-authorization layering — DNS-rebind + CSRF, no token (lib/request-security.ts:76-112; lib/web-auth.ts:9-45); monotonic run-id staleness guard for streaming reconciliation (hooks/useAgentSession.ts:813-988) |
Node Fetch-API / timingSafeEqual and a React-hook implementation, neither portable to Rust/axum or Dioxus state directly; only applies once theatron's server binds beyond loopback or its chat UI supports reconnect |
Patterns
P1 — Design-token extraction with mandatory contrast gate and provenance receipt
What: style tokens inferred from an external source get a per-value confidence label (high/medium), pass a hardcoded quality gate before being proposed (AA contrast ≥4.5:1, accent-must-be-most-saturated, pure-white-paper substitution), and are never written without a user-approved diff plus a fidelity receipt naming exactly what was sampled and which values are exact vs. fallback.
Evidence: skills/diagram-design/references/onboarding.md:105-150
Verdict: adopt-later — when theatron (or any fleet UI) needs to derive its palette from an external, uncontrolled source instead of an internally-declared token file.
Disqualifiers: solves a problem the fleet doesn't have today — fleet UIs use fleet-declared tokens, not scraped branding. The receipt/confidence/gate shape is the transferable part, not the CSS-scraping mechanism.
P2 — Preview bundle protocol: content-addressed snapshot + mutable head + append-only trajectory
What: a checkpoint protocol for long-running build/generation work splits state into three objects — an immutable, fingerprint-cached bundle directory (skip re-render on unchanged source), a mutable session.json live head, and an append-only trajectory log — plus a cheap compact-summary status call so a caller never replays the whole trajectory to see where things stand.
Evidence: cli-anything-plugin/preview_bundle.py:70-89 (build_cache_key), :171-223 (prepare_bundle cache-hit short-circuit), :405-468 (append_live_trajectory), :329-359 (summarize_trajectory); rationale at docs/PREVIEW_PROTOCOL.md:72-89
Verdict: adopt-later — when theatron's UI build pipeline gains a visual-regression or incremental-render preview mechanism (a screenshot/render bundle per commit) that a caller needs to inspect without replaying history.
Disqualifiers: filesystem-local, single-operator scoped, no multi-viewer story the fleet's cross-box collab would need. Also redundant with the PR/issue/git-log continuity model already covering text/code work — it only earns its place where the checkpoint is genuinely visual/binary and text logs don't suffice.
P3 — Layered local-server request authorization (DNS-rebind + CSRF, no token)
What: two independent request-authorization layers ahead of auth — a Host-header allowlist (loopback, literal IP, or configured hostname) that defeats DNS rebinding, then a Sec-Fetch-Site/Origin check applied only when a browser actually sent those headers (so CLI/curl clients pass through). Basic Auth credentials compare via SHA-256 hash plus timingSafeEqual, not raw string compare.
Evidence: lib/request-security.ts:76-112; lib/web-auth.ts:9-45
Verdict: adopt-later — when theatron's local server binds to anything beyond pure 127.0.0.1 loopback (LAN/tailnet reachability).
Disqualifiers: built on Node's Fetch-API Request/Headers and node:crypto.timingSafeEqual; a Rust port needs axum/hyper's HeaderMap and the subtle crate — no code copies. Dead weight while the server stays loopback-only, its current default posture.
P4 — Monotonic run-id guard against stale streaming reconciliation
What: every prompt submission is stamped with an incrementing run id; every async completion path (SSE, polling fallback, visibilitychange/online-triggered reconciliation) re-checks the current run id before applying its result and discards itself if a newer prompt has started since — the guard against a late-arriving stale response resurrecting an already-finished turn's UI state.
Evidence: hooks/useAgentSession.ts:813-988
Verdict: adopt-later — when theatron's chat UI supports reconnect-after-backgrounding or retried reconciliation polling against a live streaming session.
Disqualifiers: pure client-side correctness pattern, no security content, no portable code (a React hook plus refs) — only the design decision transfers: stamp every async completion with the run id it belongs to and let each self-reject if stale.
Why this matters
None of these four apply to theatron today, and re-deriving any of them from a cold search costs real time — a search table with recorded verdicts and disqualifiers means the next search isn't run a second time at full cost. Each pattern here has a stated, checkable trigger condition, so the right time to revisit is decidable without re-reading the source repos.
Desired correction
Record this candidate table, with its four verdicts and triggers, on theatron's kanon-side planning surface. No implementation work is proposed by this issue — every verdict is adopt-later and none of the four triggers currently hold. When a future change to theatron's scope makes one of them true (an external-branding consumer, a visual-checkpoint mechanism, a non-loopback server bind, or a reconnect-capable chat stream), it is picked up from this table rather than re-searched.
Done when: the four patterns and their triggers are present in theatron's kanon-side planning surface, and this issue is closed with a pointer to that location.
Provenance
Design priors only — Read path per basanos/standards/PRIOR-ART.md. Nothing here is copied; each pattern is a from-scratch reimplementation if and when adopted. Source repos and licences: cathrynlavery/diagram-design (MIT); HKUDS/CLI-Anything (Apache-2.0); agegr/pi-web@2a6e537, shallow clone (MIT). All four patterns were re-verified against their cited path:line by an adversarial verifier that refuted 23% of all candidates surveyed across this search; none of the four carried a correction.
Finding
Four Read-path design priors verified against theatron's current scope (a Dioxus/Blitz desktop UI plus a local agent server). All four survived adversarial re-verification of their cited path:line; none propose taking a dependency or carrying code — each names a design shape to reimplement from scratch if and when its trigger condition holds. All four are
adopt-later; none apply to theatron as it stands today (self-branded tokens, loopback-only server, no persistent chat-stream reconnect surface, no visual-checkpoint mechanism), so this issue's job is to record the shapes and their triggers, not to schedule work now.Candidate table
skills/diagram-design/references/onboarding.md:105-150)cli-anything-plugin/preview_bundle.py:70-89,171-223,329-359,405-468;docs/PREVIEW_PROTOCOL.md:72-89)lib/request-security.ts:76-112;lib/web-auth.ts:9-45); monotonic run-id staleness guard for streaming reconciliation (hooks/useAgentSession.ts:813-988)timingSafeEqualand a React-hook implementation, neither portable to Rust/axum or Dioxus state directly; only applies once theatron's server binds beyond loopback or its chat UI supports reconnectPatterns
P1 — Design-token extraction with mandatory contrast gate and provenance receipt
What: style tokens inferred from an external source get a per-value confidence label (high/medium), pass a hardcoded quality gate before being proposed (AA contrast ≥4.5:1, accent-must-be-most-saturated, pure-white-paper substitution), and are never written without a user-approved diff plus a fidelity receipt naming exactly what was sampled and which values are exact vs. fallback.
Evidence:
skills/diagram-design/references/onboarding.md:105-150Verdict: adopt-later — when theatron (or any fleet UI) needs to derive its palette from an external, uncontrolled source instead of an internally-declared token file.
Disqualifiers: solves a problem the fleet doesn't have today — fleet UIs use fleet-declared tokens, not scraped branding. The receipt/confidence/gate shape is the transferable part, not the CSS-scraping mechanism.
P2 — Preview bundle protocol: content-addressed snapshot + mutable head + append-only trajectory
What: a checkpoint protocol for long-running build/generation work splits state into three objects — an immutable, fingerprint-cached bundle directory (skip re-render on unchanged source), a mutable
session.jsonlive head, and an append-only trajectory log — plus a cheap compact-summary status call so a caller never replays the whole trajectory to see where things stand.Evidence:
cli-anything-plugin/preview_bundle.py:70-89(build_cache_key),:171-223(prepare_bundle cache-hit short-circuit),:405-468(append_live_trajectory),:329-359(summarize_trajectory); rationale atdocs/PREVIEW_PROTOCOL.md:72-89Verdict: adopt-later — when theatron's UI build pipeline gains a visual-regression or incremental-render preview mechanism (a screenshot/render bundle per commit) that a caller needs to inspect without replaying history.
Disqualifiers: filesystem-local, single-operator scoped, no multi-viewer story the fleet's cross-box collab would need. Also redundant with the PR/issue/git-log continuity model already covering text/code work — it only earns its place where the checkpoint is genuinely visual/binary and text logs don't suffice.
P3 — Layered local-server request authorization (DNS-rebind + CSRF, no token)
What: two independent request-authorization layers ahead of auth — a Host-header allowlist (loopback, literal IP, or configured hostname) that defeats DNS rebinding, then a
Sec-Fetch-Site/Origin check applied only when a browser actually sent those headers (so CLI/curl clients pass through). Basic Auth credentials compare via SHA-256 hash plustimingSafeEqual, not raw string compare.Evidence:
lib/request-security.ts:76-112;lib/web-auth.ts:9-45Verdict: adopt-later — when theatron's local server binds to anything beyond pure 127.0.0.1 loopback (LAN/tailnet reachability).
Disqualifiers: built on Node's Fetch-API
Request/Headersandnode:crypto.timingSafeEqual; a Rust port needs axum/hyper'sHeaderMapand thesubtlecrate — no code copies. Dead weight while the server stays loopback-only, its current default posture.P4 — Monotonic run-id guard against stale streaming reconciliation
What: every prompt submission is stamped with an incrementing run id; every async completion path (SSE, polling fallback, visibilitychange/online-triggered reconciliation) re-checks the current run id before applying its result and discards itself if a newer prompt has started since — the guard against a late-arriving stale response resurrecting an already-finished turn's UI state.
Evidence:
hooks/useAgentSession.ts:813-988Verdict: adopt-later — when theatron's chat UI supports reconnect-after-backgrounding or retried reconciliation polling against a live streaming session.
Disqualifiers: pure client-side correctness pattern, no security content, no portable code (a React hook plus refs) — only the design decision transfers: stamp every async completion with the run id it belongs to and let each self-reject if stale.
Why this matters
None of these four apply to theatron today, and re-deriving any of them from a cold search costs real time — a search table with recorded verdicts and disqualifiers means the next search isn't run a second time at full cost. Each pattern here has a stated, checkable trigger condition, so the right time to revisit is decidable without re-reading the source repos.
Desired correction
Record this candidate table, with its four verdicts and triggers, on theatron's kanon-side planning surface. No implementation work is proposed by this issue — every verdict is
adopt-laterand none of the four triggers currently hold. When a future change to theatron's scope makes one of them true (an external-branding consumer, a visual-checkpoint mechanism, a non-loopback server bind, or a reconnect-capable chat stream), it is picked up from this table rather than re-searched.Done when: the four patterns and their triggers are present in theatron's kanon-side planning surface, and this issue is closed with a pointer to that location.
Provenance
Design priors only — Read path per
basanos/standards/PRIOR-ART.md. Nothing here is copied; each pattern is a from-scratch reimplementation if and when adopted. Source repos and licences: cathrynlavery/diagram-design (MIT); HKUDS/CLI-Anything (Apache-2.0); agegr/pi-web@2a6e537, shallow clone (MIT). All four patterns were re-verified against their cited path:line by an adversarial verifier that refuted 23% of all candidates surveyed across this search; none of the four carried a correction.