建议: `lifecycle: status` — 将记录更改状态记录为数据,而不是目录位置(实验性)

建议:`生命周期:状态'——将变化状态记录为数据,而不是目录位置(实验性)

执行: 第1684号 —— 工作演示,包含真实的git历史,钩子和CI:https://GitHub.com/ixxie/openspec-status-demo

这是一项包含若干可分离的设计决定的提案。 他们被编号在下面,所以他们中的任何一个都可以单独与他们争论,接受,或者拒绝——几个是我期望会输的,我说过的.

□ 问题

我们希望CI执行这一改变实际上被存档,因为如果没有执行`Specs/'悄悄地从运出的现实中漂出——有人把一个改变合并起来,忘记了存档步骤,活的Specs悄悄地停止描述这个系统. 但是,我们想要主张的财产被一个公开公关的整个生命设计所侵犯:变化是在“改变/”中进行的,没有存档,正是因为它还没有完成。

因此"无所不包"的CI检查是红色的,因为它的休息状态——从第一次承诺到最后一次,每个PR上都是红色的,作为正常的工作条件. 这是公关工作流程中的噪音。

只剩下坏的选择:

1. ** 发射一条人人立即学会忽视的永久红色管道——比没有大门更糟糕,因为它也掩盖了真正的失败。
2. ** 贴出一份直到最后才被玩弄的阻塞手动作业**。 戴不同帽子的同一种永久-红色问题:整个审查的管道设计不全. GitLab没有批准活动(GitLab-org/GitLab#375908,CI MERGE REQULED APROVED'在管道存在之前得到评估),以及重置-核准-on-push ' 使明显的工作失效。
3. 使用一个保持评论评论的机器人作为屏蔽条件,所以在没有红色管道(在GitLab上,通过全讨论-解析合并条件)的情况下得到检查. 这就是我们现在要做的。 它的工作,但执行 住在CI以外的一个机器人, 它必须模拟生命周期本身。
4. ** 早期在公关内存档,** 使支票通过——此时审查反馈使折叠无效,没有`无存档'支持([#1332] (https://GitHub.com/Frecission-AI/OpenSpec/issues/1332)的类:重存档不是无存档)。 即使有一个,它是一个奇怪的工作流程。

这些都不是CI问题,这就是为什么没有一个CI解决方案. 原因是archive'在一个命令中从事两个无关的工作:**状态过渡**(宣布已发送更改)和**文本合并**(将三角洲合并为specs/')。 将过渡编码为目录移动将合并焊接到公关生命周期的一瞬间——在一个有审查的团队中,这一瞬间并不存在. 小组-工作流程docs提供了两项公约,并说“选一并一致”,这是成本的选择,而不是答案。

修正的条件是以更改本身的索赔为条件: . . . . . . .