Collaboration via passthrough relay — a removed substrate pattern
fix(patterns): add dated Correction callouts to 9 of 12 patterns/ articles — deleted collab feature, fabricated deployment example, os-console web-metaphor mismatch, stale infobox/navbox claims, GIS UX naming, model-tier misattribution, kernel-hardcoding claim, and a SOC-3-relevant zero-JS claim contradicted by real code; 3 verified clean
@@ -23,6 +23,8 @@ cites: ## The pattern in one paragraph **Correction (2026-08-02):** the real-time collaboration feature described below was **deleted from the codebase** — `app-mediakit-knowledge` commit `48562316` ("collab deleted"), 2026-06-04, less than a month after this article's own `last_edited` date. `collab.rs`, the `--enable-collab` flag, the Yjs route, and the client bundle are all gone; `ARCHITECTURE.md` and `CLAUDE.md` both state plainly "real-time collab removed." The repo's own internal outbox history shows this was already noticed and never fixed: commit `16f4a052` flagged "collab article stale (C4)," and a later commit marked that flag "actioned" without the article ever being corrected. This article should describe a removed, historical pattern (or be archived per this repo's `.archive/` convention), not a live one. **Flagged, not resolved.** The passthrough relay pattern inverts the normal assumption about where a collaborative editing server sits in the authority chain: the relay holds no document state, so the canonical git tree remains the sole authoritative record of every topic's content at every point in time. Concurrent editors connect over WebSocket to a `tokio::sync::broadcast` channel keyed by slug — one broadcast room per document — and the server's only job is to forward Yjs CRDT update messages between those clients. The server neither decodes nor stores the document state those messages encode. The sole persistence boundary in the entire system is the `POST /edit/{slug}` atomic-write path: when an editor saves, the client serialises its local Yjs document to Markdown, sends it over HTTP, and the server atomically renames the new file into place on disk — the same operation as a single-author save. ## Why a passthrough relay rather than a CRDT server