Student developer focused on reliable software systems, reproducible engineering, and clearly bounded experiments. I build business systems, examine their reliability limits, turn the acceptance method into tooling, and study the framework mechanisms underneath them.

精确里程碑、冻结基线与当前任务由各项目仓库的 README / Release 维护；本页只描述稳定的项目角色，避免复制状态后发生漂移。工程范围已经闭环，不一定等于作品在我心中已经停止生长。

The engineering thread is intentional:

complete business systems
→ distributed reliability and failure boundaries
→ reproducible evidence and deterministic verdicts
→ framework mechanisms rebuilt from first principles

These projects were developed through AI-assisted solo engineering. I own problem definition, architecture, acceptance contracts, failure analysis, release decisions and freeze boundaries; models and agents assist with implementation, review and repeatable execution. Public repository creation dates reflect publication or restructuring, not necessarily project inception.

• PlainJournalPro - reference architecture for a future multi-merchant evolution; explicitly not presented as implemented software.
• FlowKernel - long-term research planning for lifecycle-aware, continuity-preserving resource scheduling; implementation has not started.

• Preserve MiniSpringBoot's frozen multi-instance and failure-contract evidence without extending its stated boundary.
• Preserve VeriTrail's deterministic verdict authority while keeping the bounded Starter and Authoring Skill reproducible.
• Keep PlainJournal's M0-M8 reference baseline stable; visual work may evolve separately without changing business facts.
• Keep public claims, CI, Releases and concise evidence entry points aligned across maintained repositories.
• Keep FlowKernel and PlainJournalPro visibly planned until executable evidence changes their status.

Detailed architecture decisions, test evidence, and release artifacts live in each project repository.

一个人不需要复制一整套组织，但必须补齐环境认知、工程施工和公共验证三种职责：

看清机器
→ 把项目做成
→ 让公共证据链也成立

1. 单机工程环境全景认知法 - 开工前先认识硬件、系统、工具链、中间件、网络、项目拓扑与资源停止线；PlainJournal 的本地开发网络与 Windows 故障边界是其中一份实战手册。
2. 硅谷中国特色改良版_拖鞋（妥协）版单兵工程法 - 压扁组织，保留需求、架构、实现、验收、发布与冻结；妥协的是单人协调成本，不是工程质量。
3. 单兵工程公共验证闭环法 - 把本地测试、干净环境、平台依赖、GitHub Actions 触发器、PR 提交归属和公开证据入口闭合起来。

• 从对话记忆到工程记忆：Fresh Checkout 三阶段独立复验 - 三个串行、相互隔离的 Codex 角色只依靠公开 GitHub 资产完成发现、修复与再审：首轮 F1 的 4 项问题全部闭环，新 HEAD 又独立暴露 3 项残余维护问题。它为“上下文应沉淀为工程记忆”提供可复核的工程证据，但不宣称学术证明或零缺陷。

这三篇文章分别讨论能力生产、事实资格与验收方法。它们来自同一段连续工程实践，但不互相代替：

第一篇解释“能力如何共同产生”；第二篇解释“未知为什么必须被保护”；第三篇解释“如何把原则变成工程事实”。它们不是学术论文，也不把单一使用者的纵向案例包装成普遍规律。

需要网页内概念检索或沿链接复核时，可使用两份配套导读：《保护零》导读与《对抗性工程验收》导读。导读不是 PDF 正文的缩写替代品。

• 一个人的大厂 - 当一个人把部门、角色、会议和流程全部复制给自己，唯一没有出现的东西可能就是项目进度。