c_a337088f57f0a2958e

Side B makes concrete, working improvements: it upgrades the dev fixture script to use cargo-watch for live-reload, persist fixture data across runs (rebase/reuse summary), prefer a stable port, and clean up UI markup in forum.rs — all directly usable, testable code changes. Side A is purely a planning document (PLAN.md) with no code changes; while it may guide future work, it has no immediate functional impact and its value depends entirely on future execution, making B's tangible, working tooling improvement more durable/immediately valuable.

A adds a concrete, phased storage/architecture plan (JSONL as source of truth, durable RocksDB projections, RAM bounded to hot scopes, write/read/startup paths) that defines lasting product direction under the 256MB constraint. B only improves local DX (cargo-watch fixture, persistent fixture-data/, preferred port) plus a small room-page markup trim—useful iteration friction reduction, but not fundamental system design.

Side B makes functional improvements to the developer workflow by switching the fixture runner to cargo-watch with persistent fixture data, adding preferred-port selection with fallback, reusing seeded data across runs, extending server startup timeouts, and updating supporting utilities. Side A is an extensive design document describing a future storage architecture and implementation plan, but it does not change project behavior or implement the proposed design.

Side B performs a substantial, coherent refactor that moves path/URL logic into a shared slug-types crate with type-safe newtypes (GardenItemUrl, ForumThreadUrl, TildeOntologyPath), reducing duplication and making the wire format correct-by-construction across server modules and RPC responses, backed by preserved/expanded tests. Side A is a smaller dev-tooling improvement (fixture persistence via cargo-watch) plus an unrelated, undocumented removal of room page headers, offering less durable architectural value than B's cross-cutting type-safety refactor.

B centralizes path canonicalization and wire URL construction into slug-types (GardenItemUrl, ForumThreadUrl, TildeOntologyPath), typing API/RPC fields and removing ad-hoc string helpers—lasting core design. A mainly improves local fixture DX (cargo-watch, persistent fixture-data/, preferred port 8080) plus a small room-page HTML cleanup, valuable for iteration but not structural.

Side B performs a substantial architectural refactor by moving canonical path normalization and URL construction into a shared `slug_types::paths` module, replacing ad hoc string helpers with strongly typed `GardenItemUrl`, `ForumThreadUrl`, and related types across the API and shared data structures. Side A mainly improves the local development workflow by switching the fixture runner to `cargo watch` with persistent fixture data and preferred ports, which is useful but primarily affects developer iteration rather than the project's long-term design.

Side A is a clean, self-contained refactor that removes ~200 lines of duplicated HTTP/OAuth/test-harness boilerplate across four test files into shared `test.common`/`test.oauth` helpers, improving maintainability without touching production code. Side B improves the dev fixture script (cargo-watch, persistent data dir) but bundles in an unrelated and unexplained removal of room heading/breadcrumb markup in `server/src/html/forum.rs`, which looks like an accidental regression to production HTML mixed into a 'dev script' commit.

A consolidates duplicated HTTP/OAuth helpers, assert/ANSI harness, cargo-build, and server-env setup out of auth/grants/integration into shared common/oauth modules (including multi-user mock Google and complete-registration!), which is lasting test architecture across the suite. B improves one local fixture workflow (cargo-watch, persistent fixture-data/, preferred port 8080) plus a small room_page HTML trim—valuable DX, but narrower and less foundational than A’s dedup.

Side A extracts duplicated test infrastructure into shared utilities (`test.common` and `test.oauth`), introducing reusable helpers such as `run-cargo-build-release!`, `slug-server-env`, `complete-registration!`, shared assertions, configurable mock OAuth users, and consistent HTTP timeouts while updating multiple test suites to use them. Side B mainly improves the local development fixture workflow (cargo-watch, persistent fixture data, preferred port) and removes a small piece of room-page UI, which is useful but has a narrower, less foundational impact on the project's long-term maintainability.

Side B is a small, coherent, working change: it improves the dev fixture script to use cargo-watch with a persistent data dir and preferred port, and removes redundant UI markup, all integrated into the actual codebase. Side A is a disorganized dump of stray untracked files (many pasted with shell prompts like 'tommy@Tommys-Laptop...cat file' baked into the diff), placed at repo root rather than proper module paths, indicating this is not a real integrated commit but leftover scratch content of dubious lasting value.

Side A lands core lasting domain machinery (rank-centrality with the #146 star-topology fix and tests, event reducer for scopes/rooms/ingests/votes, HTML form $form templates + ui_action parsing, vote-compare page, and a large tested URL parser graph), while B only polishes the fixture DX (cargo-watch, persistent fixture-data/, preferred port 8080) plus a small room page markup trim.

Side A introduces substantial project functionality: core ranking and reducer logic, a parser with extensive tests, UI action/form templating, voting pages, browser plumbing, and supporting test scripts, all of which define lasting behavior. Although it contains some accidental pasted terminal output and planning notes, it establishes major reusable infrastructure, whereas Side B mainly improves the developer workflow by making the fixture environment persistent, using cargo-watch, preferring port 8080, and making small UI/test utility adjustments.

Side A delivers a substantive dev-tooling improvement: persistent fixture data, cargo-watch integration, port-preference logic, and summary rebasing, which meaningfully improves developer iteration workflow. Side B is a small, cosmetic UI simplification (removing a toggle button, tweaking placeholder text) that is fine but far less impactful and somewhat reduces functionality (hides the collapsible toggle) without clear justification.

A materially improves lasting dev workflow: cargo-watch live reload, persistent fixture-data with reuse/rebase, preferred port 8080, longer health wait, and supporting helpers/gitignore—versus B’s small form tidy that mainly drops the toggle/labels and trims RPC metadata/placeholders with little durable design impact.

Side A substantially improves the developer workflow by replacing the one-shot release build with a persistent cargo-watch setup, adding reusable fixture-data with summary rebasing, preferred-port selection, and reuse of seeded data, making local iteration faster and more durable. Side B is primarily a UI cleanup that removes the toggle and labels from the public thread form and changes placeholder/button text, with little evidence of a lasting functional improvement.

Side B delivers a working, tested improvement to the dev fixture workflow (cargo-watch integration, persistent fixture-data, port reuse, summary rebasing) plus a small real cleanup in forum.rs, all functional and immediately useful. Side A is purely a planning document (plan.md) plus a thin, mostly-unused RouteContext wrapper that still delegates to the old CanonicalItemUrl/ThreadNav internals—no actual migration or bugfix, just scaffolding and prose that may become stale.

A lands lasting architecture: a concrete RouteContext API (item_href, thread/garden/room URLs, ThreadNav interop) plus a phased ItemId migration plan that defines how identity and hrefs should evolve. B mainly improves local DX (cargo-watch fixture, persistent fixture-data/, preferred port) and removes a bit of room-page UI chrome—useful, but not structural product design.

Side B makes functional improvements to the development workflow by adding a persistent `fixture-data/` setup, reusing seeded data across runs, preferring a stable port with fallback, launching via `cargo watch`, and extending server startup handling, all of which directly improve ongoing developer iteration. Side A mostly introduces a large planning document plus a thin `RouteContext` wrapper around `ThreadNav` with re-exports, which establishes direction but contributes relatively little executable behavior beyond API scaffolding.

Side B fixes a real deadlock bug (RwLock guard held across nested read/write locks in RoomCreate/RoomGrant), adds a regression test for room creation, and hardens test infra against pipe-buffer deadlocks and hanging HTTP calls with timeouts — concrete, lasting correctness fixes. Side A is a dev-experience improvement (cargo-watch fixture persistence) that's useful but lower-stakes, and it also silently removes room header UI (title/room-id/garden link) without explanation, which is a behavioral regression rather than pure improvement.

B fixes a real tokio RwLock deadlock in RoomCreate/RoomGrant by dropping read guards before nested lock acquires, plus an integration test and test harness fixes (log-pipe deadlock, HTTP timeouts, auth username assertions). A only improves local DX (cargo-watch fixture, persistent fixture-data, port preference) and a small UI trim—useful but not production-correctness.

Side B fixes a substantive concurrency bug by ensuring `tokio::sync::RwLock` read guards are dropped before nested `read().await`/`write().await` calls in RPC handlers, preventing deadlocks, and adds an integration test covering private room creation. Side A mainly improves the local development fixture workflow (persistent fixture data, `cargo watch`, preferred port selection) and makes minor UI/test-support changes, which are useful but less fundamental to the project's long-term correctness.

Side B delivers a coherent, integrated improvement to the dev workflow (cargo-watch reload, persistent fixture-data with reused seed summary, smarter port picking) that plugs cleanly into existing tooling. Side A adds infra files (Dockerfile, fly.toml, deps.edn) plus event_log.rs/views.rs dropped at the repo root outside any src tree, suggesting orphaned/unintegrated scaffolding rather than a wired-in feature.

A adds lasting core runtime and ops pieces (EventLog JSONL append/load, ViewStore with async flush, multi-stage Dockerfile, fly.toml mounts/health checks), which the product and deploy path depend on. B improves local DX (cargo-watch fixture, persistent fixture-data/, prefer-8080) plus a small forum HTML trim—useful iteration polish, but not comparable foundational design.

Side A adds substantial project infrastructure and core functionality: a production Dockerfile and Fly.io deployment config, a reusable EventLog module that appends and reloads JSONL events with error handling and corrupt-line tolerance, and a persistent ViewStore that loads and atomically flushes view counts. Side B mainly improves the local development workflow by making the walkthrough fixture persistent with cargo-watch, preferred ports, and fixture reuse, plus a small UI cleanup, which is useful but has a narrower long-term impact on the project's architecture.

Commit A fixes actual product logic (sibling nav grouping so each unranked sibling is its own group) with a targeted test verifying the behavior, directly affecting user-facing rendering correctness. Commit B is a dev-tooling improvement to the fixture script (persistent data dir, cargo-watch) plus an unrelated removal of room header markup in forum.rs that looks like accidental regression/noise, making it less clearly a net positive for lasting product value.

A fixes sibling nav grouping so each unranked isolate is its own group (with an updated doc comment and a focused regression test), which is lasting product behavior. B mainly improves local DX (cargo-watch, persistent fixture-data, preferred port) plus a small forum markup trim—useful but not core domain logic.

Side A changes the sibling navigation behavior so each unranked sibling becomes its own navigation group instead of all unranked siblings being merged together, matching the documented ranking model, and adds a targeted regression test to lock in that behavior. Side B substantially improves the local development fixture workflow with persistent data, cargo-watch integration, preferred port selection, and summary reuse, but those changes primarily affect developer iteration rather than core product behavior.

A delivers a focused, working feature improvement (grouped CLI panel, hover-to-copy, JS-injection safety assert) with corresponding CSS updates in both themes, and is self-contained. B's dev-script improvement (cargo-watch, persistent fixture dir) has real value for local dev, but it bundles in an unrelated and unexplained removal of room header markup (title, room id, garden link) in forum.rs, which looks like an accidental regression riding along with an otherwise tooling-only commit.

A lands a lasting user-facing design: multi-command cli_panel with row click-to-copy, JS single-quote safety asserts, and dual-theme CSS, consolidating three separate panels on room pages. B improves local DX (cargo-watch, persistent fixture-data, preferred port) plus a small room_page markup trim, valuable for iteration but not shipped product surface.

Side B substantially improves the developer workflow by replacing the release-build fixture with a persistent `cargo watch`-based environment, adding preferred-port selection, reusable seeded data (`fixture-data/`), summary rebasing, and longer health waits, making iterative development faster and more reliable. Side A improves the CLI panel UI by grouping commands, enabling click-to-copy rows, and adding assertions to prevent unsafe JavaScript embedding, but those changes are primarily presentation and defensive checks rather than a broader workflow improvement.

Side B adds a focused, meaningful test verifying the rank-centrality algorithm correctly recovers order from a random spanning-tree of votes, adding real regression coverage for core ranking logic. Side A's commit, while improving dev tooling (persistent fixture data, cargo-watch), also silently removes UI elements from the room page unrelated to its stated purpose, mixing dev-script improvements with an unexplained regression.

B adds a focused regression test of core rank-centrality behavior (26-item spanning tree with perfect strength ratios recovers true order), which permanently guards product-critical ranking logic. A improves local DX (cargo-watch fixture, persistent fixture-data/, preferred port) and trims redundant room-page markup, but that is peripheral tooling rather than lasting correctness of the main system.

Side A substantially improves the developer workflow by replacing a one-shot release build with a persistent cargo-watch server, reusing seeded fixture data across runs, preferring a stable port with fallback, and rebasing saved URLs so the fixture remains usable after restarts. Side B adds a useful regression test for rank centrality on a random spanning-tree input, but it only increases test coverage and does not change the project's runtime behavior or architecture.

Side A adds a small, well-tested user-facing feature (surfacing connectivity stats in CLI pair output) with clear unit tests verifying formatting logic, directly improving the product. Side B is a dev-tooling improvement (cargo-watch based fixture script) that's useful for iteration speed but also includes an unrelated, unexplained removal of room header markup in forum.rs, making it more mixed-purpose and riskier.

A adds a real user-facing CLI feature: formatting and showing existing connectivity stats (density, components, comparisons-to-connect) on pair suggestions, with focused unit tests—lasting product value for voters. B improves local DX (cargo-watch fixture, persistent fixture-data/, preferred port) plus a small room-page markup trim, which helps iteration but does not change core product behavior as directly.

Side A adds a user-facing capability by exposing existing connectivity statistics in the CLI, including graph density, connected-component status, and comparisons needed to connect the graph, and it includes focused unit tests covering connected and disconnected cases. Side B mainly improves the local development fixture workflow (cargo-watch, persistent fixture data, preferred ports) with a small UI cleanup, which is useful for contributors but has less lasting impact on the project's core functionality.

B removes actual dead/redundant defensive code in a core reducer path with a clear rationale and updates the corresponding test to match new correct behavior, a small precise correctness/clarity fix. A is a larger dev-tooling refactor that improves local iteration but also removes room title/breadcrumb UI text seemingly unrelated to the stated purpose, making it more diffuse and less clearly net-positive.

A turns the walkthrough fixture into a lasting dev loop (cargo-watch reload, persistent fixture-data/, preferred port 8080, reuse/rebase of seeded summary) plus a small room-page cleanup—substantive ongoing DX. B only deletes a dead zero-ratio early-return and retunes one test; useful hygiene, but far less project impact than the fixture redesign.

Side A substantially improves the developer workflow by replacing a rebuild-based fixture runner with a persistent cargo-watch setup, reusing seeded fixture data across runs, preferring a stable port with fallback, and adding supporting utilities such as port selection and summary rebasing. Side B only removes a redundant zero-ratio guard in the reducer and updates a test to reflect existing validation and edge-skipping behavior, which is a small cleanup with limited lasting impact.

B delivers a substantive dev-workflow improvement (cargo-watch integration, persistent fixture data with reuse/rebasing logic, preferred-port fallback) that meaningfully improves developer iteration speed, though it bundles in an unrelated/likely unintentional HTML removal from forum.rs. A is a clean, minimal, well-justified config simplification (kaocha auto-discovery) that reduces future maintenance friction but is much smaller in scope and impact.

A replaces brittle hand-enumerated kaocha suites with a single ^test\\..+ auto-discovery pattern, so new test namespaces run in CI and TEST.sh without further config edits—a small, lasting test-infra design fix. B improves local DX (cargo-watch, persistent fixture-data/, preferred port) and drops a bit of redundant room_page markup, but that value is mostly ergonomic tooling rather than project-wide correctness.

Side B adds durable developer infrastructure: the walkthrough fixture now uses persistent `fixture-data/`, prefers a stable port with fallback via `pick-port-prefer`, runs through `cargo watch`, reuses seeded data when available, and updates URLs when reloading, substantially improving iterative development. Side A simplifies Kaocha configuration by replacing manually enumerated test namespaces with a single auto-discovered `^test\..+` suite, reducing maintenance and ensuring new tests run automatically, but its scope is narrower than the broader workflow improvements in Side B.

Side B is a genuine structural refactor extracting forum.rs logic into focused submodules (nav, ingest, new_thread, room_members, access) with clear separation of concerns, improving long-term maintainability. Side A is a dev-tooling improvement (persistent fixture data, cargo-watch) that's useful but more ephemeral/local-workflow-focused, and even includes an unrelated regression removing room title/breadcrumb markup from forum.rs without explanation.

B’s split of forum into focused modules (nav, ingest, access, room_members, new_thread) plus shared new-thread compose logic is a lasting structural improvement to core server UI code, whereas A mainly upgrades the fixture/dev workflow (cargo-watch, persistent fixture-data/, preferred port) and a small room_page markup trim. B’s modularization outranks A’s useful but narrower tooling changes; the added sample-fixture helper is incidental.

Side A substantially improves the developer workflow by replacing a release-build fixture with a persistent `cargo watch`-based server, adding preferred-port selection, reusing seeded `fixture-data/`, rebasing saved URLs, and extending health-check timeouts for reliable iteration. Side B is largely a structural refactor that moves forum code into new modules and inlines small helper functions without changing behavior, with the only notable functional addition being a macOS-specific `sample-fixture` profiling script.

A moves ~1800-line legacy/parser.rs into server/src/ (with parser_action.rs + parser_render.rs), wires parse_reddit_url into ui_html.rs/home, adds the persistent #parser-panel + JS tab/DB-suggestion handling, and updates tests/integration/*.rs. These are concrete, shipped functionality and clean module boundaries. B only tweaks bb.edn, walkthrough_fixture.clj and .gitignore for cargo-watch + fixture-data/; that improves local iteration but changes no production paths or design.