c_48edc893c5b0b5b1c7

Side B introduces a substantial, coherent new feature (a generic form-template hole-filling system plus a unified POST /ui action dispatcher wired into forum pages and routing), with tests and clear documentation, representing real lasting architecture. Side A is a trivial one-line whitespace/formatting tweak to a template string with no functional impact.

Commit A is a one-line cosmetic nit removing a leading " · " from a views meta span. Commit B adds lasting architecture: a form_template hole-filling system, HtmlUiAction types, a unified POST /ui handler, shared run_* web_post helpers, and progressive UI expand slots for new-thread forms.

Side B adds substantial new functionality and architecture: it introduces a unified POST /ui endpoint with typed HtmlUiAction parsing, reusable form-template substitution, shared web-post helper functions, new routing, and UI support for expanding thread forms with permission checks. Side A is a minor cosmetic change that removes the leading separator before the view count (`" · "`), improving presentation but not adding comparable lasting capability.

Both are substantial, but B fixes a real correctness/design issue (persisting full Reddit API payloads via the event log for replay instead of only a derived view, removing implicit auto-fetch on navigation, adding configurable API bases and dotenv support) plus includes an integration test with a mock server and fixtures. A adds a reasonable new `/ui` dispatch abstraction and form-template mechanism, but it's mostly plumbing/refactor without new tested behavior or bugfixes, and its own tests are limited to unit-level template parsing rather than end-to-end verification.

B delivers lasting domain design: event-sourced EntityImported with full JSON payloads, raw+derived entity state, explicit user fetch (removing auto-fetch on browse), configurable API bases, and a mock integration test. A is solid UI plumbing (form_template holes, POST /ui mux, shared run_* web_post helpers, expand-new-thread morphs) but is mostly endpoint consolidation and progressive form disclosure versus B’s data-model and fetch correctness changes.

Side B introduces a durable architectural improvement by persisting full imported Reddit payloads as a new `EntityImported` event, replaying them into state, separating raw payloads from derived views, and replacing automatic fetches with explicit user-triggered imports. Side A adds a substantial new `/ui` endpoint with JSON-template form handling and refactors web-post logic for reuse, but much of its change is plumbing for browser UI dispatch, whereas Side B extends the project's persistence model, replay behavior, and import workflow with accompanying tests.

Side B introduces a substantial, reusable architecture (a generic form-template/hole-filling system plus a unified `/ui` HTML action endpoint) that refactors duplicated POST handlers into shared functions and adds meaningful new tests, delivering lasting design value. Side A is a smaller, focused refactor (Deque→List/Vec with query-time capping) that fixes a real inefficiency but has much narrower scope and impact than B's endpoint/template infrastructure.

B adds lasting UI architecture: a tested form_template hole-fill layer, HtmlUiAction + parse path, POST /ui dispatch, and shared web_post runners, enabling progressive form expansion rather than only refactoring existing endpoints. A is a sound but narrower storage cleanup (Deque→List/Vec, drop write-time trim_recent_votes, cap on read + one test) that simplifies projections without introducing comparable new capability.

Side B adds a substantial new UI command infrastructure: a unified `POST /ui` endpoint, typed `HtmlUiAction` parsing from JSON form templates with `$form` substitution, reusable web-post handlers, new routing, and tests, enabling broader browser interactions with shared server logic. Side A refactors recent-vote storage from a deque to an append-only list with query-time capping and removes write-time trimming, which is a meaningful storage design change, but its scope is narrower than the new reusable UI architecture introduced in Side B.

Side B introduces a substantial new architectural mechanism—a generic form-template/RPC system (form_template.rs, ui_action.rs, ui_html.rs) with tests, unifying disparate POST handlers into a single /ui endpoint—which is broader infrastructure with lasting reuse value. Side A adds a genuinely useful but narrower feature (pool-scoped voting) that is well-integrated but smaller in scope and reuses B's own ui_html.rs machinery (built atop it), making B foundational and A incremental.

B introduces lasting UI architecture: the form_template hole-filler, typed HtmlUiAction + unified POST /ui dispatch, and shared web_post runners—infrastructure reused by later features. A is a solid, scoped product feature (pool-constrained pair picking and nav) but builds on that stack rather than setting a comparable foundation.

Side B introduces a reusable browser UI command infrastructure: a new `/ui` endpoint, `HtmlUiAction` parsing with JSON template hole substitution, shared `run_*` handlers for existing web actions, and routing/module integration. Side A delivers a useful feature by adding pool-scoped voting (`pool` query handling, next-pair navigation, and UI links), but it is a targeted capability layered on existing code, whereas Side B establishes broader architectural support that can be reused by future browser interactions.

Side A adds a coherent, well-documented new subsystem (form_template holes, ui_action parsing, /ui endpoint) with tests and refactors web_post handlers into reusable functions without breaking existing behavior—net positive, additive architecture. Side B rips out a large complex (if messy) autocomplete parser and replaces it with a simpler paste-and-go flow, which is a reasonable simplification but deletes substantial existing functionality/tests (including a Playwright race test) and is more of a scope reduction than a durable feature addition; net value is more mixed/negative in terms of preserved capability.

Side A adds lasting architectural value: a reusable form_template hole-filler, typed HtmlUiAction + POST /ui dispatcher, and progressive disclosure of new-thread forms, with shared run_* helpers so existing web posts stay correct. Side B correctly kills an unreliable ~2k-line keystroke graph for a simple paste-and-go parse/redirect, but that is largely subtracting failed experiment rather than installing comparable new design surface.

Side A introduces a substantial new UI action architecture: a unified POST /ui endpoint with typed HtmlUiAction parsing, JSON form-template substitution, reusable web-post handlers, and integration for expanding thread forms while preserving permission checks. Side B mainly removes a complex autocomplete system in favor of a simpler paste-and-go URL parser and redirect, which simplifies behavior but also deletes large amounts of functionality rather than adding broadly reusable infrastructure.

Side A ships a complete, tested feature (pairwise vote-compare page with a principled next-pair/bridge-selection algorithm in pair.rs), fixes a real correctness bug in ItemId normalization (from_storage) that ripples through reducer/reddit import, and improves test infra (extracted mock-reddit support, new Clojure e2e test) — all backed by unit and integration tests. Side B mainly stands up generic plumbing (form_template holes, ui_action enum, /ui route) for existing forum actions, which is useful scaffolding but smaller in scope and lower-stakes than A's working feature plus bugfix.

A ships lasting product design: bridge-aware pair selection in pair.rs with tests, the /vote compare page and post-vote morph path, plus ItemId::from_storage canonicalization used in Reddit import and votes. B is valuable plumbing (form_template holes, HtmlUiAction, POST /ui wrappers and expand-form morphs) but mostly routing/refactor of existing ingest/redact flows rather than new core behavior.

Side A delivers substantial end-user functionality and infrastructure: it adds a full pairwise voting page, intelligent pair selection based on connected components, in-place UI morphing after votes, ID normalization via `ItemId::from_storage`, and corresponding integration/tests. Side B mainly introduces a generic `/ui` endpoint and form-template mechanism, refactors existing web-post handlers for reuse, and adds lazy expansion of new-thread forms; while useful architectural work, it is less directly impactful than the new voting workflow and correctness improvements in Side A.

Commit B is a coherent, tested architectural overhaul: it introduces a unified batch RPC protocol (types, server dispatch, CLI rewiring), separates rooms from forum threads with a real capability model, and updates all integration/unit tests and the grants sandbox test to match — a foundational change that many future features can build on. Commit A adds a useful but narrower feature (a templated `__rpc__` hole-filling mechanism and a single `/ui` endpoint for HTML actions) with good docs/tests, but it's a smaller, more localized addition compared to B's system-wide redesign of the API surface and permission model.

B re-architects the core model (rooms vs forum threads, ScopeId::Room, Ingest room_id/thread_tag) and replaces scattered REST handlers with a unified RPC batch surface plus CLI/tests, which is lasting platform design. A adds a useful POST /ui form-template and progressive thread-form morphing, but it is a UI convenience layered on existing web endpoints rather than structural backend change.

Side B introduces a unified batched RPC API (`/api/v0/rpc`), migrates the CLI to it, refactors validation into shared modules, and restructures the core data model from thread-centric to room/scope-aware (`room_id`, `thread_tag`, scoped reducer state). These are foundational architectural changes affecting server, client, events, reducer, types, and tests, whereas Side A primarily adds a new `/ui` endpoint with HTML UI actions, form-template handling, and reuses existing web-post logic to support progressive browser interactions.

B introduces a coherent room-route encoding abstraction (room_route_segment/room_id_from_route_segment), consistently applies it across server routes, tests, and Clojure fixtures, and adds real URL-normalization logic (YouTube canonicalization, query sorting) with substantial unit tests, delivering concrete bugfixes/consistency improvements. A adds a new UI action/template system which is architecturally interesting but is more speculative plumbing (new form-template DSL, ui_html endpoint) without the breadth of test coverage or demonstrated end-to-end correctness that B shows across many call sites.

A adds lasting architecture: form-template hole fill, HtmlUiAction parsing, a unified POST /ui handler, and shared run_* web-post paths plus progressive new-thread UI—new capability with tests. B’s room URL collapse to /r/{short}{slug} and route churn is mostly mechanical; its real upside (room_route helpers and HTTP identity/YouTube normalization) is narrower than A’s UI command surface.

Side A adds substantial new infrastructure: a new `/ui` endpoint with `HtmlUiAction` parsing, JSON form-template substitution (`form_template.rs`), reusable web-post handlers, and UI expansion flows for thread forms, introducing a reusable browser UI command architecture. Side B is largely a refactor that centralizes room URL encoding/decoding (`room_route_segment`/`room_id_from_route_segment`) and updates routes plus some URL normalization utilities, which improves consistency but is narrower in scope and mostly restructures existing behavior.

Side A ships a complete, well-scoped feature (RoomList RPC + CLI + types) with integration tests that explicitly verify per-user grant isolation, giving clear lasting value and confidence in correctness. Side B ('progress') introduces a speculative and fairly complex new abstraction (form-template hole-filling, a generic /ui JSON-in-hidden-field dispatch) whose own doc comments flag it as a potential authorization footgun, and the vague commit message signals unfinished, exploratory work rather than a settled design contribution.

B introduces a lasting UI architecture (form_template hole substitution, HtmlUiAction enum, unified POST /ui handler) plus shared runners extracted from web_post and on-demand thread-form expansion, whereas A only adds one straightforward RoomList RPC/CLI path and its isolation tests.

Side A adds a complete user-facing capability: a new RoomList RPC, CLI `room list` subcommand, shared request/response types, server implementation that filters rooms by authenticated grants, and integration tests verifying per-user isolation and grant behavior. Side B is primarily architectural refactoring to introduce a `/ui` dispatch path, shared web handler helpers, and form-template infrastructure, but it does not deliver a comparably complete, validated feature and lacks end-to-end coverage in this patch.

B fixes a real bug (imported children mis-wired into the tree causing wrong parent attachment and unranked labels showing raw ids instead of titles) and updates integration tests to verify the fix, delivering concrete correctness value. A is a large but purely additive/refactoring scaffold (new /ui endpoint, template substitution system) with no bugfix, adding complexity without demonstrated necessity or bug resolution.

A adds lasting UI architecture: a tested form-template/hole filler, HtmlUiAction parsing, a unified POST /ui dispatcher, and progressive new-thread expand morphs with shared web_post runners. B is a real but narrower fix (Reddit children attach via apply_entity_under_parent without ensure_path side effects, title labels in unranked lists, test updates) and does not outweigh that foundational design.

Side B fixes concrete functional issues in Reddit imports by replacing the simple `link_child` path with `apply_entity_under_parent`, which imports entity data while avoiding incorrect `ensure_path` nesting of `/comments/...` segments. It also improves the ranking UI by showing imported child titles instead of raw IDs and adds integration tests covering children fetches, SSE morphs, and the corrected import behavior; Side A is a substantial architectural addition for a unified `/ui` endpoint, but much of it is infrastructure and refactoring rather than an immediately verified bug fix.

A implements a coherent, well-reasoned syntax change (explanation-first votes, title-first items) with a real parser rewrite, updated error messages, and exhaustive updates across docs, fixtures, unit tests, and browser tests to keep everything consistent and correct. B adds a generic JSON-template-with-holes UI plumbing layer (form_template.rs, ui_action.rs) that is more speculative infrastructure—useful for reducing duplication but introduces indirection and an explicitly acknowledged security caveat, and its vague 'progress' commit message reflects a less finished, less validated change than A's deliberate, tested DSL redesign.

A lands a real product/language design change: votes become explanation-first and items stay path-then-body, with a genuine parser rewrite (block-prefixed votes, pending blocks, rejection of legacy trailing explanations) plus matching docs and call sites. B adds useful browser infrastructure (form_template holes, HtmlUiAction, unified POST /ui, shared web_post runners) but is more plumbing/UX wiring than a lasting core semantic shift.

Side A implements a substantive DSL redesign by changing the parser to support leading explanation blocks for votes, enforcing item-body placement, updating UI generation, validation, documentation, fixtures, and adding parser tests that reject legacy syntax and malformed inputs. Side B adds a useful browser UI dispatch layer (`POST /ui`), form-template infrastructure, and refactors shared handlers, but it is largely architectural plumbing for the web interface rather than a project-wide language and parsing change.

Side A ships a real, non-trivial architectural feature (a unified POST /ui endpoint with a generic form-template hole-filling mechanism, wired into the router and shared with existing web_post handlers, plus tests), directly improving the production HTML app. Side B adds a useful but purely dev-tooling side binary (sorterc) for offline DSL compile/lint, valuable for developer workflow but not part of the core product runtime, and largely reuses existing server logic rather than introducing new core capability.

A lands lasting product architecture: a reusable form_template hole-fill layer, HtmlUiAction parsing, a unified POST /ui handler, and shared run_* web_post paths that change how browser UI commands work. B adds a useful offline sorterc/compile-scan dev binary, but it is workspace-only tooling around existing server logic rather than core runtime design.

Side B introduces a reusable offline tooling layer (`server::offline`) plus a new `sorterc` workspace binary that reuses the server's parser, validator, reducer, and ranking code to compile `.sorter` files and diagnose `events.jsonl`, with tests and documented CLI workflows. Side A adds a useful `/ui` endpoint, HTML UI action framework, JSON form templating, and refactors web-post handlers for reuse, but its impact is primarily on browser interaction, whereas Side B creates broadly reusable developer infrastructure for validation, replay, and diagnostics that is likely to provide longer-term maintenance value.

B delivers a complete, testable feature (Reddit import) with real production concerns handled—OAuth token refresh, rate-limit/backoff, dedup/caching, and comprehensive unit tests for URL mapping and JSON parsing—replacing a previous stub. A is a solid refactor (unified /ui endpoint with $form-hole JSON templating) that reduces duplication and adds tests, but it's mostly indirection/plumbing rather than new capability, and its generic templating mechanism adds complexity whose long-term payoff is less certain than B's concrete, working integration.

A adds a lasting UI protocol: form_template hole-filling, HtmlUiAction, and a unified POST /ui handler that reuses extracted web_post runners and lazy-expands new-thread forms—core product architecture with tests. B implements a solid Reddit broker (OAuth, rate limits, parse/map, background worker) replacing stubs, but it is an external integration plus minor noise (.env gitignore, todo), so it trails A’s foundational design impact.

Side A introduces a new generalized HTML UI action system with a single `/ui` endpoint, reusable `run_*` handlers extracted from existing web post logic, and a JSON form-template mechanism (`$form` substitution) backed by tests. Side B adds a substantial Reddit background fetcher with OAuth, rate limiting, and parsing, but much of it is infrastructure tied to an external integration, whereas Side A delivers a reusable architectural improvement that consolidates browser UI handling and reduces duplication across the project.

Side A introduces a well-structured, reusable mechanism (form_template + ui_action) that unifies browser-only actions behind a single endpoint, refactors web_post handlers into shared run_* helpers cleanly, and includes solid unit tests for the templating logic. Side B adds a useful but narrower feature (Reddit-specific rendering) with reasonable tests, but is more domain-specific and less architecturally generalizable than A's infrastructure work.

A adds lasting architecture: a reusable form-template/`__rpc__` hole system, typed `HtmlUiAction`, a unified `POST /ui` handler, and shared runner extraction in `web_post`, plus progressive expand-for-new-thread UI. B is solid but narrower product polish (Reddit thumb/image/link fields, `render/reddit` cards, CSS, one fixture test) that builds on an existing importer rather than a general UI command path.

Side A introduces a new browser UI command architecture with a unified POST /ui endpoint, typed HtmlUiAction parsing from JSON templates with form-hole substitution, reusable web-post handlers, and supporting tests, creating reusable infrastructure beyond a single feature. Side B adds valuable Reddit-specific rendering (thumbnails, full images, link extraction, new metadata fields, and tests), but its impact is narrower and primarily enhances one content type rather than establishing a broader interaction framework.

Side A introduces the core architecture (form_template substitution system, HtmlUiAction enum, parse_html_ui_from_form, and the new POST /ui endpoint) that subsequent features—including Side B's own commit—depend on and reuse; it's foundational, well-documented, and covered by templating unit tests. Side B is a solid, well-tested feature addition (copy-to-clipboard for garden rankings) but it's a narrow extension built entirely on the infrastructure Side A created, contributing less lasting architectural value even though its test coverage (unit/integration/browser) is thorough.

A introduces the lasting POST /ui architecture: form_template hole-filling, HtmlUiAction parsing, the ui_html dispatcher, shared run_* web_post helpers, and routing—foundational design reused project-wide. B only adds one feature (CopyGardenRank + markdown clipboard JS and buttons) on top of that already-existing stack, so its value is narrower and dependent.

Side A introduces a substantial new UI architecture: a generic POST /ui endpoint, a typed HtmlUiAction system with JSON template/hole substitution, reusable web-post handlers, routing, and tests, enabling multiple browser UI actions through a shared mechanism. Side B is a well-implemented feature built on that infrastructure, adding a garden-ranking copy action, markdown formatting, UI controls, and integration tests, but it is an incremental capability rather than foundational project design.

Side A introduces a clean, well-tested, reusable form_template/ui_action abstraction (with substitution unit tests) and refactors web_post handlers into shared run_* functions cleanly used by both /post and /ui, reducing duplication. Side B does deliver real functional room/auth features but also includes an unrelated speculative AI-chat 'plan2.md' document (pure noise) and duplicates large chunks of forum.rs logic across public/room variants without much abstraction, making it noisier and less maintainable despite being larger.

Side B delivers the foundational room web UI: session cookies and optional_principal auth, /login|/logout, ThreadNav, room_page/room_thread_* routes with ACL checks, compose/new-thread forms, and home wiring—core lasting product surface. Side A is a solid follow-on (form_template $form holes, HtmlUiAction, shared run_* helpers, progressive + morph via POST /ui) but assumes and refines that earlier surface rather than establishing it.

Side A adds a reusable UI action architecture: a new `/ui` endpoint, `HtmlUiAction` parsing with JSON form-template substitution, shared `run_*` web handlers, and a `form_template` module with tests. Side B delivers substantial browser login, room routing, and cookie-based posting, but it also includes a large planning document and broad UI wiring; the more modular abstractions in A (shared handler extraction and generic form-template parsing) are likely to provide longer-term reuse across future UI features.

Side B is a small, well-justified bugfix: it closes a real correctness gap (zero-ratio votes silently coerced to 1:1, no upper bound) and consistently enforces the invariant across DSL parser, HTTP handler, and reducer, backed by targeted unit/integration tests. Side A is a larger scaffolding commit (new form-template/ui_action machinery) that adds real infrastructure but is mid-progress ('progress' commit message), more speculative/generic, and lacks the same tight problem/fix correspondence.

A adds lasting foundation: form_template hole-fill, HtmlUiAction + POST /ui, shared run_* web_post paths, and expand-in-place new-thread UI—architecture later commits build on. B is a correct but narrow multi-layer vote-ratio guard (≥1, ≤100) with tests; valuable domain tighteness, but smaller scope than A’s design surface.

Side A introduces a substantial new UI architecture: a unified POST /ui endpoint, the HtmlUiAction command model with JSON template parsing and form-hole substitution, reusable web action handlers, and integration into routing and forum rendering. Side B is a valuable correctness fix that consistently enforces vote-ratio bounds (both sides >=1 and <=100) across the parser, UI handler, reducer, and tests, but it is a comparatively localized validation change rather than a broad, reusable capability.

B performs a genuine architectural improvement: moving path/URL logic into slug-types as typed newtypes (GardenItemUrl, ForumThreadUrl, TildeOntologyPath), eliminating stringly-typed helpers and duplicated normalization code across server and shared types, with preserved tests. A adds a new /ui endpoint and a JSON-template form-filling mechanism, which is useful but introduces more speculative complexity (a new DSL-like templating system with security caveats) without clear necessity or broad reuse yet. B's refactor reduces duplication and strengthens type safety across the whole API surface, providing more durable value than A's single new feature endpoint.

A adds lasting UI architecture: form_template hole-filling, HtmlUiAction, and a unified POST /ui handler that shares web_post run_* paths and enables lazy new-thread morphs—not mere churn. B is valuable (path types moved into slug-types with GardenItemUrl/ForumThreadUrl), but it largely relocates and retypes existing string helpers rather than introducing comparable new product capability.

Side B centralizes canonical path normalization and room-aware URL generation into the shared `slug_types::paths` module, replacing scattered string helpers with typed `GardenItemUrl`, `ForumThreadUrl`, and related types across RPCs and API responses. This is a broad architectural improvement that reduces duplication and strengthens type safety, whereas Side A primarily adds a new `/ui` endpoint, HTML UI action parsing, and refactors existing web-post handlers for reuse to support browser interactions.

Side B is a small, correct bugfix that closes a real state-corruption issue (ghost items and falsely-marked voted pairs) and updates the test to verify the fix, providing clear lasting value. Side A adds a large new subsystem (form templating, __rpc__ JSON holes, /ui endpoint) which is more architecturally ambitious but unproven, more speculative, and much larger surface area for bugs without corresponding test coverage of the new endpoint's integration behavior.

A adds lasting architecture: a reusable form_template hole-fill layer, typed HtmlUiAction + POST /ui dispatcher, shared run_* web_post helpers, and lazy new-thread UI morphs—real product and API design with tests. B is a correct, high-leverage reducer bugfix (zero-ratio early-return before ensure_item/voted_pairs) with an updated test, but it is a narrow localized correctness patch versus A’s broader durable surface.

Side B fixes a real correctness bug by moving the zero-ratio guard before any side effects in the reducer, preventing ghost items and incorrectly recorded voted pairs, and updates the test to verify no state is registered. Side A introduces a substantial new `/ui` endpoint, form templating, and UI action infrastructure, but it is primarily new feature work and refactoring rather than addressing a demonstrated correctness issue with lasting integrity impact.

Side B fixes a real performance/correctness problem in the sorterc scan (avoiding full log replay with centrality computation), adds richer error reporting (full parse_error text), a genuinely useful --ingest replay-and-compile feature, updates docs to match, and includes new tests validating the fix. Side A adds a sizable new speculative subsystem (form templating with $form holes, a unified /ui endpoint) that duplicates existing routes' functionality and even flags its own security caveat, with the commit message itself just 'progress', making it feel more exploratory than a finished, load-bearing improvement.

A adds lasting product architecture: a reusable form_template hole-fill layer, typed HtmlUiAction parsing, and a unified POST /ui handler that also refactors web_post into shared run_* paths and lazy-expands new-thread UI. B is valuable but narrower—fast parse-only scan, richer parse_error surfaces, and compile --ingest—solid sorterc DX/perf fixes without changing the core server product surface as deeply.

Side A introduces a new `/ui` endpoint with `HtmlUiAction` parsing, a reusable JSON form-template mechanism (`form_template.rs`), and refactors existing web-post handlers into shared functions so multiple UI actions can reuse the same logic. Side B meaningfully improves offline tooling by making log scans faster, exposing detailed parse errors, and adding `compile --ingest`, but those changes primarily enhance developer workflows rather than extending the application's core architecture and browser interaction model.

Both are substantial infra additions, but B fixes a real correctness/UX issue (fetch_entity returning immediately without waiting for the actual reddit fetch, replaced with a proper SSE stream with fetching/complete/error states and oneshot completion signaling), adds meaningful observability (tracing::debug throughout reddit worker), and updates the integration test to verify actual behavior end-to-end. A is a solid new feature (POST /ui plumbing and form templating) but is more scaffolding/wiring without fixing a functional gap, and B's SSE mechanism is the more durable, correctness-improving design.

A introduces lasting core design: form_template hole-filling, typed HtmlUiAction, a unified POST /ui dispatcher, and shared run_* web_post paths, plus the expandable new-thread UI—reusable infrastructure with tests. B’s SSE fetch pipeline and oneshot FetchJobResult are real improvements to one flow, but much of the diff is logging, module moves, lockfile/deps, and trimmed tests rather than broader foundational value.

Side A introduces a substantial new browser UI command architecture: a unified POST /ui endpoint, structured HtmlUiAction parsing with JSON form templates, reusable web-post handlers, and lazy expansion of new-thread forms with permission checks. Side B adds useful SSE-based entity fetch streaming and refactors fetch UI into its own module, but much of the patch is infrastructure, logging, and code movement around an existing fetch feature, making its lasting architectural impact somewhat smaller.