GitHub Spec Kit：从 constitution 走到可验证实现
Spec Kit 把规格驱动开发组织为连续阶段：项目原则先约束决策，feature specification 说明要解决什么，plan 负责技术路线，tasks 形成执行顺序，implement 产生改动，质量门禁再检查产物是否收敛。每个阶段都有自己的输入和退出条件。
初始化会生成项目流程，不只是一个命令
specify init 按选择的 agent 在仓库中建立命令、模板、脚本和 .specify 资产。初始化前确认官方来源、CLI 版本、目标 agent 与工作目录；初始化后只审查生成 diff，不立即让代理实现功能。
specify --version
specify init . --ai codex
git status --short
git diff -- .specify实际参数以当前官方 quick start 为准。生成物会影响代理行为和 shell 执行，应像构建脚本一样审查。升级 CLI 时先在样板仓库比较模板，不对业务仓库直接覆盖。
constitution 固定不能随功能摇摆的原则
constitution 记录代码质量、测试、安全、用户体验、性能和治理等项目级原则。它不是某个 feature 的需求，也不应包含待实现代码。官方流程把 constitution 的 scope 与实现意图分开，避免一次“更新原则”顺手修改应用文件。
.specify/
├── memory/constitution.md
├── templates/
└── scripts/
specs/
└── 001-session-expiry/原则必须能影响 plan 与 review，例如要求测试先行、禁止长期密钥、规定兼容窗口。空洞口号只会增加上下文。constitution 变更由更高权限评审，并说明迁移影响；feature 作者不能为了让当前方案通过而临时放宽原则。
specify 与 clarify 负责行为边界
/speckit.specify 从自然语言生成 feature spec，重点是用户结果、场景、需求和成功标准，而不是预选框架。明显歧义进入 clarify；未解决的问题不能直接推给 plan。正向场景、拒绝场景和非目标应同时出现。
/speckit.specify 为登录会话增加可配置的空闲过期
/speckit.clarify 明确管理员策略、现有会话与多设备边界规格评审检查每个 requirement 是否可测试、术语是否唯一、跨系统依赖是否明确。AI 生成的“完整”格式不能代替产品决策。大型 feature 应拆成独立 spec 或 roadmap，不让单次上下文吞下整个产品。
plan 与 tasks 把决策变成可恢复执行
plan 选择技术栈、架构、数据迁移和风险控制，并回查 constitution。tasks 按依赖拆成能单独验证的动作；每个任务指向文件或能力、验证命令和完成证据。若 plan 暴露需求缺口，应回到 specify/clarify 修复源头，而不是在 tasks 中偷偷补需求。
/speckit.plan 使用现有会话存储，加入版本化空闲过期字段
/speckit.tasks 先写失败测试，再迁移 schema，最后接入配置与文档
/speckit.analyze 检查 spec、plan 与 tasks 的冲突和缺口analyze 是一致性门禁，不是代码验证。任务执行前保存干净 Git 基线；并行任务只在文件与状态边界独立时展开，避免多个代理同时修改同一事实源。
implement 仍然受 diff、测试与审查约束
/speckit.implement 消费已批准产物执行任务，但 shell、网络、凭据和写入权限继续最小化。每个小节点查看 diff、运行目标测试并保留失败输出，不能等所有任务结束才发现方向错误。
git diff --check
npm test -- session-expiry
npm run typecheck
git status --short反向实验让过期策略失效或传入非法配置，确认测试会拒绝。测试、spec 与实现不能由同一代理结论互相证明；人类评审者检查风险、数据迁移、权限与用户结果。converge 或 verify 类门禁用于发现规格、计划、任务和实现的剩余差异，不代表无需代码审查。
权限、扩展与工作流自动化扩大执行面
Spec Kit 可通过命令、preset、extension 或自动工作流扩展。扩展可能读取仓库、执行 shell、访问网络或写入 GitHub，因此安装来源、版本、权限和卸载路径要单独审查。工作流表达式进入 shell 时还要防止未转义输入成为命令。
规格文件可能含内部路线、架构和客户需求，发送给外部模型前遵循数据政策。secret 不进入 constitution/spec/plan，CI 使用短期凭据。运行日志保存动作与结果，不无条件保存完整对话。流程成本按 feature 数、阶段重跑、模型调用、评审时间和生成文档体积观察。
回滚与退出以普通 Git 资产为底线
阶段产物发生错误时，回到拥有该问题的阶段修复：需求问题回 specify/clarify，技术问题回 plan，顺序问题重建 tasks，实现问题回滚代码。不要直接修改后续文件让表面一致。模板升级失败则恢复 CLI 版本和生成提交，再跑固定样板。
停用 Spec Kit 前盘点开放 feature，保存 constitution、spec、plan、tasks 和验证记录为普通 Git 文件，删除 agent 命令与自动化后确认项目仍能构建测试。新电脑恢复时重新安装锁定 CLI、检查生成脚本，再用一条小 feature 跑通 specify→plan→tasks→implement 的正反证据链。