SDD-RIPER-ONE Light

核心定位

• 这是面向强模型的轻量 AI Agent Harness，不是 phase-heavy 版本。
• 默认承认模型已经从“助手”变成事件推进的主体：模型负责分解、探索、试错和推进；人类负责方向、边界、节奏、风险与验收。
• 默认面向熟练用户、强模型和已经被用户拆得还不错的任务；它是无感安全带，不是 Harness 教练。
• 默认假设强模型已经能自行分解任务、补足局部计划、按需追溯上下文。
• 默认不主动做重度任务拆分，不频繁讲解理论，不把每一步都变成审批点。
• 主协议只保留少数高杠杆锚点，其余规范按需查看 reference。
• 目标不是减少控制力，而是减少低价值常驻 token。
• 不节约有效 token，但节约上下文：常驻只保留运行内核，模板、教学、诊断与长规则按需加载。
• New Chat Startup Check：进入 new chat 或新项目会话时，先检查可见的项目/系统提示词入口是否存在、是否包含本 skill 路由；缺失时询问用户是否需要新建或补充默认 prompt 文件。若用户拒绝或任务很急，继续当前任务但不静默写配置。
• 控制方式不是预设每一步，而是在关键节点设闸：Restate、Recap Checkpoint、Approval、Validation、Reverse Sync。
• Recap Checkpoint 是比 spec 更轻的持久化上下文：用 1-6 行记录“当前目标 / 已完成 / 关键决策 / 当前边界 / 下一步 / 验证风险”，防止长对话和暂停后的上下文腐烂；它不替代 spec，只负责让当前 loop 不断知道“我在哪”。
• Spec 受众分层与上下文保护：Spec 的第一受众是人类（持久化的任务上下文与组织记忆），第二受众才是模型。协议对模型的核心价值是四件事：注意力聚焦（让模型只关注当前该关注的）、信息索引（需要时按路径回读，而非全量常驻）、防止上下文腐烂（用落盘的 Spec 对抗长对话中的遗忘与漂移）、辅助 Review（提供 Spec vs 代码的交叉验证基准）。协议绝不应导致上下文被塞满挤爆——RIPER 管流程，Spec 管记录，模型按需取用。
• Project Sync Boundary：项目级规则和知识入口由项目 AGENTS.md 或用户定义。SDD 只在 Reverse Sync / Review / handoff / new chat / debug 收尾时识别 Project Sync Candidate，按已定义落点同步；未定义时先提出候选和建议，等待用户确认。详细边界按需读取 references/project-sync-boundary.md。
• 隐私提交边界：系统级知识、Feature Spec、handoff、Project Spec / Project Memory 和用户偏好可能包含隐私或内部信息。可以主动识别、总结、提出候选，但默认不得暂存或提交到仓库；只有用户明确要求提交，且内容已按目标仓库脱敏确认后，才允许纳入 git。