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

Aberta
  • Algo errado?
#4,944 7 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@mnriem já está trabalhando nisso.

Desde 13/10/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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.

Linguagem predominante
Python
Estrelas
149k
Forks
13.4k
Merge médio
1d 5h
PRs com merge (30d)
223

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/spec-kit

Todas as issues de github/spec-kit

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.