Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”)

未关闭
  • 哪里不对？
#4,944 7 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@mnriem 已经在做这个了。

开始于 2026年10月13日。

评估

这个 Issue 还没有评估数据。

描述

feature-assess feature-needs-clarification triage-can-wait

Problem

Spec Kit describes three artifact persistence models, but leaves their maintenance operations to teams and community tooling.

The shared delivery process should remain unchanged: specify, plan, tasks, implement, and converge until the agreed feature is complete. After delivery, teams need to decide how completed specifications, plans, and task records persist and evolve.

We should explore whether separately selectable extensions can support those choices without adding persistence-specific behavior to the core delivery commands.

Proposed direction

Assess three opt-in persistence extensions:

Extension Persistence model Responsibility to explore
Flow-back Accepted discoveries flow back into retained artifacts Reconcile explicitly approved decisions across specifications, plans, and task records.
Flow-forward Completed artifacts remain historical records Preserve completed feature directories and establish traceable links to subsequent features that extend or supersede them.
Flow-always (“Living”) The specification remains a maintained contract Update the authoritative specification and refresh derived artifacts while preserving important implementation rationale.

These are candidate responsibilities, not settled command or package designs. The assessment should establish which operations benefit from automation and whether each model warrants an extension rather than documentation or a preset.

Architectural boundary

Persistence extensions operate on the lifecycle of delivered feature artifacts. They do not replace or alter the shared delivery process.

A persistence operation that establishes new intended behavior requiring implementation must feed that work into the normal delivery loop. It must not:

  • Treat acceptance of existing code as proof of convergence while the intended artifacts still disagree.
  • Suppress unresolved delivery findings to accommodate a persistence model.
  • Make one persistence strategy the required or default behavior.
  • Turn a persistence update into implicit authorization for application-code changes.

The assessment must distinguish artifact maintenance from delivering a subsequent change.

Existing work

The community reconcile extension already provides flow-back-related automation and is listed in Spec Kit’s community catalog. Evaluate that existing work before proposing duplicate functionality or a replacement.

github/spec-kit#4940 proposed connecting reconciliation to converge and adding a core amendment step. That request was declined because it crossed the delivery/persistence boundary. This proposal explores separate opt-in persistence extensions instead; it does not reopen that requested core behavior.

github/spec-kit#4943 tracks clarification of the existing documentation. This feature assessment is separate and must not delay that clarification.

Assessment questions

  • What concrete post-delivery operations does each model need?
  • Which operations require an extension, and which are adequately addressed by conventions, documentation, or presets?
  • Are three separate extensions justified by distinct behavior and independently useful workflows?
  • What approval, traceability, and artifact-preservation safeguards does each require?
  • How does each strategy hand subsequent implementation work back to the unchanged delivery process?
  • Should any resulting extensions remain community-maintained or become first-party, and what evidence would justify first-party ownership?

Acceptance criteria for the assessment

  • Define the responsibilities and boundaries of all three persistence flows.
  • Identify concrete use cases and expected artifact changes for each.
  • Evaluate existing community functionality without assuming it must be replaced.
  • Recommend an appropriate delivery mechanism for each model: documentation, preset, or extension.
  • Demonstrate that proposed persistence behavior leaves core delivery semantics unchanged.
  • Document approval and preservation rules, including treatment of completed tasks and historical artifacts.
  • Recommend ownership and maintenance scope based on evidence.
  • Identify any implementation proposals that require separate approval.

Out of scope

Changing converge’s authority or append-only contract, introducing a mandatory persistence strategy, or committing to three new first-party extensions before the assessment is complete.

AI disclosure

Drafted with GitHub Copilot, powered by GPT-6.1 Sol, in an interactive session for maintainer review. AI assistance covered proposal framing and issue drafting.

主要语言
Python
星标
149k
派生
13.4k
平均合并
1 天 5 小时
30 天内合并 PR
223

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/spec-kit 的其他 Issue

查看 github/spec-kit 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。