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

Abierto
  • ¿Algo no está bien?
#4,944 7 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@mnriem ya está trabajando en esto.

Desde el 13/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
Python
Estrellas
149k
Forks
13.4k
Merge medio
1 d 5 h
PR fusionados (30 d)
223

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/spec-kit

Todos los issues de github/spec-kit

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.