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

オープン
  • 何か問題がありますか？
#4,944 コメント 7 件 リアクション 0 件 担当者 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時間
マージ済み PR（30日）
223

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/spec-kit のほかの issue

github/spec-kit の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。