Add teaching Python agent CLI with Poetry and CI

docs/06-verification-and-quality.md

@@ -0,0 +1,92 @@
+# 06. 验证与质量保证需求文档
+
+## 1. 为什么“做完”不等于“完成”
+
+在 AI 编程产品里，最大的风险之一是：模型会把“代码改了”误当成“任务完成了”。
+
+因此，这个产品必须把“验证”设计成一个独立能力，而不是可有可无的附属步骤。
+
+## 2. 验证系统的产品目标
+
+1. 独立检查实现是否真的可用
+2. 防止只读代码就宣称完成
+3. 防止 happy path 偏见
+4. 让验证结果带证据而不是口头判断
+
+## 3. 验证 Agent 的需求
+
+### 3.1 独立角色
+验证角色需要与实施角色分离，避免实现者偏见。
+
+### 3.2 默认心智模型
+验证角色的工作不是“帮实现找理由通过”，而是主动尝试发现问题。
+
+### 3.3 必须禁止的行为
+验证角色不能：
+- 修改项目文件
+- 安装依赖
+- 用写操作掩盖问题
+
+### 3.4 必须支持的检查类型
+- build
+- test suite
+- lint / type-check
+- 接口调用验证
+- UI 自动化验证
+- CLI 输入输出验证
+- migration 验证
+- adversarial probe
+
+## 4. 输出格式需求
+
+验证结果必须满足：
+- 有检查项标题
+- 有实际执行命令
+- 有真实输出
+- 有 PASS / FAIL / PARTIAL 结果
+- 最后有统一 verdict
+
+## 5. 为什么需要 adversarial probe
+
+只验证 happy path 会导致大量问题漏检。因此系统要要求验证阶段主动尝试：
+- 边界输入
+- 并发场景
+- 空输入 / 非法输入
+- 重复请求
+- 不存在资源引用
+
+## 6. 为什么验证必须可追溯
+
+如果验证没有命令和输出，用户无法判断：
+- 到底测没测
+- 测了什么
+- 失败在哪
+
+因此，质量系统必须要求“证据化验证”。
+
+## 7. 质量保证不只是测试
+
+这套产品的质量保证包括：
+- 提示词中对诚实汇报的要求
+- 验证角色的独立存在
+- 执行链的日志与 transcript
+- 失败可追踪
+- 结果可复盘
+
+## 8. 伪代码表达
+
+```python
+class VerificationRunner:
+    def verify(self, task, changed_files, context):
+        checks = build_verification_plan(task, changed_files)
+        results = []
+        for check in checks:
+            cmd = check.command
+            output = run(cmd)
+            results.append(evaluate(output, check.expectation))
+        return summarize_verdict(results)
+```
+
+## 9. 产品经理视角下的总需求句
+
+> 产品必须把验证设计成独立、对抗性、证据化的质量系统：它不依赖实施者自我声明，而是通过命令、输出与统一 verdict 来证明任务是否真正完成。