DOCUMENTATION
从“我要理解什么”进入文档，而不是从目录树开始。
ZUAEF Docs 面向想要理解、复现、扩展或检查系统的人。建议先从你要回答的问题进入。
公开 Proof 文档应写清 prerequisites、环境假设、预期证据、pass/fail 条件和已知限制，不暴露私密凭据，也不伪造 one-click reproduction。
文档路径
1
FDE Agent 心智模型
Observe → Diagnose → Decide → Act → Verify → Continue / Stop先理解中央工作循环：
- Outcome Ownership
- Model vs Host Responsibility
- 为什么一次 Run 只由一个 Agent 对结果负责
- 什么场景应该继续使用 Deterministic Workflow
2
Field Interfaces
理解外部对话如何进入 Runtime。
- Telegram Surface
- Identity / Allowlist
- Session Binding
- Conversation ID
- Case Binding
- Normal Presentation vs External Delivery
3
Business Case 与 Context
理解 Agent 如何知道自己正在处理哪个业务现场。
- Case Identity
- Situation State
- Durable Business Belief
- Trajectory Separation
- Operator Correction
- Bounded Context Projection
4
Capabilities 与 Progressive Disclosure
理解业务功能如何进入 Agent，而不是一开始全部暴露。
- Available / Authorized / Loaded / Invoked
- Profile Composition
- Deferred Toolset
- Writing
- Budget
- WordPress
- Research / Knowledge
- Upstream Primitives
5
Side Effects 与 Approval
理解什么动作真正需要人类控制。
- Observe / Local Write / External Write / Destructive
- Native Approval
- PausedRun
- Resume / Deny
- Visible Outbound Content
- 为什么 Authoring 本身不是 External Effect
6
Artifacts、Steps 与 Receipts
理解什么才算执行证据。
- Persisted Artifact
- Step Event
- Tool-effect Fact
- Large Tool-result Spill
- Run Receipt
- Completion vs Model Self-report
7
Agent Console
从人的视角检查一次 Run。
- Run List
- Run Projection
- Trajectory
- Inspector
- Artifact Bar
- SSE Invalidation / Live-follow
- Stable Historical Inspection
8
Field Proofs
复现架构宣称支持的关键边界。
- Telegram → WordPress
- Case-bound Continuity
- Writing Context Delivery
- Deterministic Budget Vertical Slice
- Approval / Continuation
不要第一步就“把所有 Capability 都装上”。
选择一个你可以明确描述的真实任务：
- 真实 Input
- 真实 Business Context
- 一到两个真正有用的 Capability
- 明确 Success Condition
- 如果存在 External Effect，明确 Boundary
- 能够核验完成的 Evidence
然后真正跑一次，再看模型实际做了什么。Memory、Search、Sub-agent、更多 Context Machinery，都应该在第一轮出现真实 Failure 后再增加。
新业务域？Compose 它，不要 Fork Agent Loop。
增加 Domain 时：
- 1确定性计算继续保持确定性
- 2只暴露 Domain 真正需要模型决定的 Action
- 3分类 Side Effect
- 4定义 Success Evidence
- 5不需要首轮可见的 Capability 设为 Deferred
- 6通过同一套 Run / Receipt / Approval Semantics 测试
如果一个新 Feature 必须依赖“再造一套 Orchestration Runtime”才能存在，先质疑设计。
Docs 跟随可执行行为。
当文档与当前运行仓库冲突：
- 1.Executable Runtime Behavior 优先
- 2.Current Proof Code / Tests 其次
- 3.Current Architecture / Spec 再次
- 4.旧网站与旧 Blog 默认属于历史材料，除非重新核验
所有 Legacy Page 都必须显式标注。
描述早期多 Agent 设计的旧文档页面保留在 Legacy Research 标识之下。它们记录的是早期设计阶段，不代表当前 ZUAEF 架构。