Correct the diff-engine backend story, and review the rest against source Diff Engines had it backwards. It said StreamSequenceMatcher was the only engine on the commit path and the Cython Myers matchers existed only for benchmarking. matchers.py resolves dmp_cython -> ses_cython -> stream at import, and ACTIVE_BACKEND is dmp_cython wherever the extensions built: the Cython matcher is the default and StreamSequenceMatcher is the fallback. A reader following the old page would have looked in the wrong place for both correctness and performance questions. The same claim was duplicated in Source Code Map, which grepping the corrected phrases turned up. The page also presented three different measurements as one story: an unsourced "15-26x", the parser page's regex-vs-no_regex number, and that page's estimate for a Cython parser port that was never done. Replaced with a benchmark run recorded with its parameters. Wiki Backend Design still described the in-place tail rewrite as how commits work, which its storage comparison rests on. Annotated in place rather than rewritten, since the measurements behind it are unaffected -- the benchmark scripts run on BytesIO -- but the "filesystem is native" reasoning now fits the Large Object adapter better than the filesystem. Adds a flowchart of the commit write path, where the two backends diverge and only one of them overwrites live data, and the two design pages to the English Home, which had only the Korean one.
Re-measure 5-1 after fixing commit()'s return value The old numbers came from a run where commit() returned the whole serialized stream on in-memory instances, so the benchmark stored a stream copy in the version column and made design B look heavier than it is. Design B is flat, as expected; retract the "B gets slower than A" claim. The conclusion that a single BLOB column suffices at wiki scale is unchanged.
Lead Wiki-Backend-Design with the empirical conclusion, not the pre-benchmark theory Sections 4 and 6 still framed "one BLOB column per page" as structurally inferior to per-revision row normalization, even though the §5 benchmarks showed the opposite: column storage is fine at normal wiki scale (fsync dominates, waste ratio ~1.08x) and row normalization measured slower. Reorder and rewrite so the actual finding leads instead of the leftover theoretical concern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LatyexR95wdY5YvefRKmys
Add full wiki: system overview, source map, storage format, diff engines, CLI tools Bilingual pages (Korean + -en English counterparts) covering the core architecture, plus the Wiki-Backend-Design notes moved over from the main repository's docs/. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LatyexR95wdY5YvefRKmys