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

Offen
  • Stimmt etwas nicht?
#4,944 7 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mnriem arbeitet bereits daran.

Seit 13.10.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
149k
Forks
13.4k
Ø Merge
1 T. 5 Std.
Gemergte PRs (30 T.)
223

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/spec-kit

Alle Issues in github/spec-kit

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.