背景

2026-09-15 摸排现状：站点同时存在两棵同版本 Dioxus 组件树（CSR wasm 树 + SSR 侧车树）、三个 Markdown 渲染器（C++ / pulldown-cmark / 手写）， enhance_article_html 手抄两份且已经漂移——GFM 表格包裹只加了 SSR 一份， 侧车挂掉走 CSR 兜底时，表格文章当前是破的。继续在“SSR 还是 CSR“里二选一， 就必须放弃另一轨的能力；而不加治理地双轨并行，漂移只会越来越多。

选项

• 纯 SSR（或纯 SSG）。 首屏与 SEO 最优，但后台编辑器等重交互页被迫写 vanilla JS，wasm 投资作废，桌面/移动壳轨道无家可归。
• 纯 CSR SPA。 交互最顺，但首屏依赖框架 JS、SEO 与弱网体验倒退， 与空间轴已拿到的毫秒级首绘直接冲突。
• 中立契约层 + 双端派生（采纳）。 把 DTO、Markdown 管线、路由轨道等 中立逻辑下沉到 zjchina-core（纯 Rust、可编译 wasm32），SSR 与 CSR 两棵树 从同一真源渲染；Content 轨 SSR 直出零水合，App 轨才用 wasm。

证据

• 摸排事实是真实漂移：三个渲染器、两份 enhance、CSR 表格破（LET_TIME_SEE §3， 2026-09-15）——不是想象中的问题。
• 后续兑付持续验证该结构：路由表三轨道单一真源（routes.rs）、Markdown 单一 管线（zjchina-core::markdown）双端共用，漂移由编译期与测试锁拦截。
• SSR 侧车可独立降级到 CSR 薄壳：线上实测 X-ZJ-Tier: ssr，侧车故障不宕站。

拍板

拍板者 zj：不选 SSR 或 CSR，选中立契约层；新增“双端共用“逻辑前先问 “碰 web-sys 或 axum 吗”，碰就不许进 core。AI 协作者参与摸排与方案对比。 日期：2026-09-15（2026-09-24 补录）。