Ticket graphs

SHELVED (feasibility proven; blocked on sandbox toolchain, not design). Goal: run congruency (PHP+SQLite CMS) fully in-browser via php-wasm -> a click-and-run GitHub-Pages showcase. PROVEN: - php-wasm runs PHP 8.4 in-env (seanmorris build booted clean + fast). - App runtime is WASM-safe: only PDO sqlite + session_start; NO process spawning (the exec() are $db->exec SQL). - @php-wasm (WordPress Playground) bundles pdo_sqlite; ~600KB app + 184KB seed -> tiny bundle. BLOCKER (environment tooling): - Sandbox npm is 9.2.0 but @php-wasm needs npm >= 10.1 -> incomplete installs (only php_7_2.wasm landed, not 8.4). - @php-wasm/node 3.1.44: PHPLoader.processId init bug. 3.0.1: no bug but hangs loading a present wasm in node. - seanmorris build boots clean but has NO sqlite. RESUME PATH (pick one): 1) Get npm>=10 / newer node image -> @php-wasm sqlite build most likely just works, NO app change. 2) Driver-swap (the robust, toolchain-independent answer): DataConnection.php (the ONE db seam) routes SQL to sql.js (SQLite-in-WASM, JS) via the php-wasm PHP<->JS asyncify bridge; everything above DataConnection is unchanged. seed.sql + state/manifest.json are already bundle-ready; db_verify --manifest works with no git. Two-target model: server (deploy.py) = the admin device (shared/persistent); WASM (Pages) = showcase/preservation (per-visitor/ephemeral). Complementary, from one codebase.

— browse congruency source (forge-parked tree)