Project Guidance Sources ​

当前版本不再提供独立的 project guidance compiler workflow，也不再生成专门的 baseline artifacts。项目规范仍然存在，但 source of truth 回到仓库内可审计、可提交、可维护的文档和代码事实。

规范从哪里来 ​

来源适合承载
AGENTS.md / CLAUDE.md宿主入口规则、语言策略、source/runtime 边界、workflow 入口治理
目录级 AGENTS.md / CLAUDE.md子目录或子项目的局部约定
docs/contracts/**schema、artifact、workflow、provider 和 downstream consumer contract
README.md / README.zh-CN.md用户可见能力、安装路径和主流程
测试与 fixtures可执行行为约束、边界样例和回归保护
.spec-first/config/**本机 runtime setup、required MCP、helper 和 provider opt-in facts
docs/solutions/**已验证解法、复盘和长期工程知识

使用方式 ​

text
先读 AGENTS.md / CLAUDE.md
  |
  v
读取 README、docs/contracts、已有 plan / task / solution
  |
  v
必要时读取 provider evidence 和 bounded source evidence
  |
  v
LLM 在当前 workflow 中判断哪些约束适用

脚本负责准备确定性事实，例如文件路径、schema、hash、provider readiness 和测试结果。LLM 负责把这些事实解释成当前任务的约束、风险和取舍。

对不同 workflow 的影响 ​

Workflow当前做法
spec-plan从 requirements、repo docs、contracts、provider evidence 和相邻实现中提取约束，不读取独立 baseline artifacts
spec-work执行时遵循计划、AGENTS/CLAUDE、测试和现有代码模式；provider evidence stale 时补 direct reads
spec-code-review继续使用 project-standards reviewer，但它审查的是 AGENTS.md / CLAUDE.md 与项目已有规则，不依赖单独 baseline 目录
spec-compound把已验证经验写入 docs/solutions/**，而不是写回 generated baseline
spec-runtime-setup只准备 runtime、MCP/helper 和 provider readiness，不负责生成项目规范

迁移建议 ​

  • 如果团队以前把 confirmed 规范放在 generated baseline 目录中，请把仍有效的内容迁移到 AGENTS.md、CLAUDE.md、docs/contracts/** 或 docs/solutions/**。
  • 如果规范只是某次任务的候选结论，不要提升为硬约束；把它保留在对应 requirements、plan、review finding 或 solution doc 中。
  • 如果需要团队级共享规范，优先以普通文档或 package source 形式维护，再由当前 workflow 读取和解释。

阅读下一步 ​