Activity

1. stn1slv commented on Oct 13, 2026

   

   stn1slv

   on Oct 13, 2026

   Contributor

   More actions

   Thanks for opening this and for pointing at reconcile. I just released v1.3.0, which follows the boundary described here and in #4940. Below is how it answers the assessment questions for the flow-back row. I can't speak for the other two models.

   Post-delivery operations. It takes a plain-language gap report for one feature per run. It amends the spec.md and plan.md entries the drift reaches (FRs, scenarios, edge cases, entities, success criteria, assumptions, plan sections), adds a dated revision note to each changed file, and appends remediation tasks to tasks.md for work the drift leaves open. It reads the shipped code only to resolve file paths for those tasks. Requirements come from the gap report, never from code.

   Approval. Before any edit, every run asks which drift items the team approves reconciling into the artifacts. An item left out is written nowhere, and the report recommends /speckit.converge for it. "Approve none" writes nothing. A gap report that says "approved" still gets the question. The approved items go on an Approved: line in the revision note.

   Traceability and preservation.

   • IDs are never reused or renumbered. New ones follow the file's own convention and width.
   • Tasks marked [X] are never edited, and tasks from earlier runs are never deleted.
   • Entries marked RETIRED, SUPERSEDED by [ID] or CANCELLED, and bugfix strike-throughs, are never revived. The amendment goes to the live entry.
   • An item that conflicts with a constitution MUST rule is withheld, whatever the approval says.
   • Each run carries a [Sync: slug] key, so re-running the same report changes nothing. A re-run changes an earlier entry only where the new report changes what it says.

   Hand-back to delivery. It never touches application code and never writes into a ## Phase N: Convergence section. New work becomes ordinary tasks, and the report's next step is /speckit.implement followed by /speckit.converge. Convergence is still established by the unchanged delivery loop, against the updated artifacts.

   The four "must not" points. It doesn't treat accepted code as convergence, since it sends you to converge. It doesn't suppress converge findings, since it never edits a Convergence phase. It is opt-in by install, and when the constitution names flow-forward or living spec, it says the in-place amendment doesn't match. It doesn't authorize code changes; it only appends tasks.

   Extension rather than docs or a preset. The work depends on reading each file's own ID scheme, section names and markers, and applying the rules above the same way every time. That is hard to get from documentation alone. A preset would mean overriding core commands, which is the boundary this issue wants to keep.

   Known gaps (all recorded in the repo): a same-slug re-run with a narrower approval isn't defined yet, a run that only writes tasks keeps its approval in the printed report only, and every run is now interactive. I test behaviour by running the prompt against a fixture project full of deliberate traps, with the expectations committed before each round. The latest rounds are in tests/fixture/BASELINE-v1.3.0.md.

   Ownership. I'm happy to keep maintaining it as a community extension. If the assessment recommends a first-party flow-back extension, I'm also fine with it being used as a starting point.

   ---

   AI disclosure: drafted with Claude Code (Claude Opus 5.5) at my request in an interactive, human-supervised session, and reviewed by me before posting. The agent also helped prepare the v1.3.0 release referenced above.
2. mnriem

   self-assigned this

   on Oct 13, 2026
3. mnriem

   added

   feature-assessRun the Spec Kit idea-assessment pipeline on this feature requestRun the Spec Kit idea-assessment pipeline on this feature request

   triage-can-waitVerdict: valid and in-scope but deprioritized; held behind the evidence gateVerdict: valid and in-scope but deprioritized; held behind the evidence gate

   on Oct 13, 2026
4. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — opt-in-persistence-flows · Stage 1/5: Intake

   Idea Intake: Opt-in persistence extensions for three artifact models

   • Slug: opt-in-persistence-flows
   • Created: 2026-10-13T16:15:33Z
   • Source: Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944 (labeled feature-assess)
   • Type: exploration

   Idea (as captured)

   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.

   Explore whether separately selectable extensions can support flow-back, flow-forward, and flow-always (“Living”) persistence choices without adding persistence-specific behavior to the core delivery commands. The assessment should establish which operations benefit from automation and whether each model warrants an extension rather than documentation or a preset.

   The issue defines candidate responsibilities for each model, asks about concrete operations, safeguards, hand-back to the unchanged delivery process, and ownership, and explicitly excludes changing converge's authority, introducing a mandatory strategy, or committing to three first-party extensions before assessment. A maintainer comment adds evidence about the community reconcile extension (v1.3.0) for flow-back and identifies known gaps, while noting that it does not cover the other two models.

   Restated

   Assess whether the three post-delivery artifact persistence models need independently useful automation, and if so whether each should be delivered as documentation, a preset, or an opt-in extension. Preserve the shared delivery loop and keep persistence operations from implicitly authorizing application-code changes.

   Origin & Context

   • Raised by: mnriem (issue author; collaborator)
   • Trigger: An exploration request following documented persistence models, the declined core flow-back proposal ([Feature]: Core flow-back step for drift where the code is ahead of the spec #4940), and the documentation clarification tracked by Clarify delivery versus post-delivery spec persistence #4943.

   First-Glance Unknowns

   • [NEEDS CLARIFICATION: What concrete post-delivery operations and artifact mutations are required for flow-forward and flow-always beyond the currently documented conventions?]
   • [NEEDS CLARIFICATION: Which teams or users have observed demand for each model, and what usage or support evidence exists?]
   • [NEEDS CLARIFICATION: What independent behavior would justify three extensions rather than documentation, presets, or one shared mechanism?]
   • [NEEDS CLARIFICATION: What approval, traceability, preservation, and hand-back safeguards are required for each model?]
   • [NEEDS CLARIFICATION: What evidence would justify first-party ownership over community maintenance?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4944 · copilot · gpt52codex · 4.84 AIC · ⌖ 0.75 AIC · ⊞ 24.3K · ◷
5. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — opt-in-persistence-flows · Stage 3/5: Problem

   Problem Definition: Opt-in persistence extensions for three artifact models

   • Slug: opt-in-persistence-flows
   • Created: 2026-10-13T16:15:33Z
   • Inputs used: intake.md and research.md

   Problem Statement

   Teams that retain Spec Kit artifacts after delivery must maintain the relationship between intended behavior, implementation decisions, historical records, and future changes, but the appropriate maintenance work differs across flow-back, flow-forward, and living-spec models. Today the repository provides neutral conventions and a shared delivery loop, while concrete operation-level needs and demand for automation remain insufficiently established, creating risk of drift, fragmented history, lost rationale, or boundary violations.

   Affected Users & Stakeholders

   • Users: Teams using Spec Kit who retain and evolve feature artifacts — they must decide how post-delivery changes are recorded and how later implementation work remains explicit.
   • Users: Teams using flow-back maintenance — they may manually reconcile accepted discoveries and need to avoid silent divergence or unsafe edits. [source: docs/concepts/spec-persistence.md; https://github.com/stn1slv/spec-kit-reconcile]
   • Stakeholders: Spec Kit maintainers — they decide whether any behavior belongs in core, a preset, or an extension and whether first-party maintenance is justified.
   • Stakeholders: Community extension maintainers — they may already provide model-specific automation and could face duplication or migration costs. [source: Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944]
   • Stakeholders: Contributors and reviewers — they need traceability, preservation, and an unambiguous hand-back to the unchanged delivery process.
   • [NEEDS CLARIFICATION: Identify representative teams, project sizes, and actual users of flow-forward and living-spec models.]

   Goals

   • Establish concrete, model-specific post-delivery operations and boundaries for all three persistence models.
   • Determine whether the problem is better addressed by conventions/documentation, presets, or independently useful optional tooling.
   • Preserve explicit intent, approval, traceability, historical artifacts, and implementation rationale where each model requires them.
   • Ensure any subsequent implementation work remains in the shared delivery and convergence process.
   • Ground ownership and maintenance decisions in observed demand and evidence rather than the existence of a proposed direction.

   Non-Goals

   • Changing or replacing the shared specify -> plan -> tasks -> implement -> converge delivery process.
   • Changing converge's authority or append-only contract.
   • Making any persistence model mandatory or default.
   • Implicitly authorizing application-code changes through artifact maintenance.
   • Committing to three first-party extensions before the assessment establishes distinct need.
   • Reopening the declined core flow-back behavior in [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 or delaying the documentation clarification in Clarify delivery versus post-delivery spec persistence #4943.

   Success Metrics

   • A reviewed assessment maps each model to concrete operations, boundaries, safeguards, and a recommended delivery mechanism; baseline: not yet recorded.
   • For each model, reviewers can distinguish artifact maintenance from subsequent implementation work without treating persistence updates as convergence; baseline: qualitative, current evidence shows this boundary needed clarification in Clarify delivery versus post-delivery spec persistence #4943.
   • Any recommended automation has documented positive and negative cases for approval, preservation, traceability, and hand-back; baseline: unknown.
   • Evidence is collected for demand, adoption, maintenance cost, and ownership before a first-party recommendation; baseline: no telemetry, support volume, or adoption data identified.
   • [NEEDS CLARIFICATION: Set numeric thresholds for adoption, time saved, error reduction, or maintenance burden that would justify an extension.]

   Cost of Inaction

   Teams will continue using documentation and manual conventions, or community tooling, with uneven safeguards and uncertain model fit. Flow-back users may duplicate existing community functionality, while flow-forward and living-spec users may improvise incompatible practices; meanwhile, unclear boundaries could reintroduce the delivery/persistence confusion that #4943 was created to address. The magnitude and urgency of these costs are not measured.

   Open Questions

   • [NEEDS CLARIFICATION: What concrete post-delivery operations, inputs, outputs, and artifact changes are required for flow-forward and living spec?]
   • [NEEDS CLARIFICATION: What observed demand or usage exists for each model, especially beyond the flow-back maintainer's report?]
   • [NEEDS CLARIFICATION: What minimum safeguards and positive/negative acceptance tests must any automation satisfy?]
   • [NEEDS CLARIFICATION: Which operations are adequately addressed by documentation or presets, and which require an extension?]
   • [NEEDS CLARIFICATION: What ownership capacity and evidence would justify first-party support over community maintenance?]
   • [NEEDS CLARIFICATION: What measurable thresholds define success and justify ongoing maintenance?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4944 · copilot · gpt52codex · 4.84 AIC · ⌖ 0.75 AIC · ⊞ 24.3K · ◷
6. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — opt-in-persistence-flows · Stage 2/5: Research

   Idea Research: Opt-in persistence extensions for three artifact models

   • Slug: opt-in-persistence-flows
   • Created: 2026-10-13T16:15:33Z
   • Evidence confidence (overall): medium

   Users & Demand

   • The issue author explicitly requests assessment of post-delivery maintenance operations, safeguards, delivery mechanisms, and ownership for all three models; this is stated demand, not usage data. [source: Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944] (confidence: medium)
   • A maintainer of the community reconcile extension reports a concrete flow-back workflow: a plain-language gap report, explicit approval before edits, amendments to affected spec.md/plan.md entries, and remediation tasks for unresolved work. This is direct maintainer evidence for one model, not evidence of broad adoption. [source: https://github.com/Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944#issuecomment-6148222539] (confidence: medium)
   • No support-ticket volume, interviews, telemetry, adoption counts, or comparative demand for flow-forward or flow-always is present in the supplied issue or repository evidence. [NEEDS CLARIFICATION: collect observed user demand and usage evidence by model.] (confidence: high)

   Prior Art

   • The repository documents flow-back, flow-forward, and living-spec models as team choices after the shared specify -> plan -> tasks -> implement -> converge process; none is required or default. [source: docs/concepts/spec-persistence.md] (confidence: high)
   • The core workflow intentionally has no dedicated artifact-reconciliation command; analyze reports inconsistencies and converge only appends remaining work to tasks.md. Extensions may provide commands or hooks without changing core responsibilities. [source: docs/concepts/spec-persistence.md] (confidence: high)
   • The community reconcile extension is existing flow-back prior art. Its README describes bounded inputs, explicit approval, preservation of completed and retired entries, idempotent sync keys, constitution checks, and routing back through implement/converge. It is evidence that a flow-back extension is technically plausible, not proof that it should become first-party or that the other models need extensions. [source: https://github.com/stn1slv/spec-kit-reconcile] (confidence: high)
   • Issue [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 proposed a core flow-back step and was closed as not planned. Its stated reason for consideration was a gap between converge findings and manual artifact maintenance; the outcome is evidence against moving this behavior into core, while leaving opt-in community tooling as a separate question. [source: [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940] (confidence: high)
   • Issue Clarify delivery versus post-delivery spec persistence #4943 clarified that persistence models are not alternative delivery workflows and that the common delivery/completeness process remains unchanged; it was completed via PR docs: clarify delivery versus post-delivery spec persistence #4945. [source: Clarify delivery versus post-delivery spec persistence #4943] (confidence: high)

   Market & Context

   • Teams can currently use documented conventions and manually maintain artifacts after delivery; the repository explicitly frames persistence as a team convention and recommends documenting the choice in a constitution or onboarding material. [source: docs/concepts/spec-persistence.md] (confidence: high)
   • The documented trade-offs are materially different: flow-back risks silent divergence, flow-forward risks duplicate or fragmented context, and living spec risks losing implementation rationale when derived artifacts are regenerated. [source: docs/concepts/spec-persistence.md] (confidence: high)
   • An external SDD overview cited by the repository supports the broader relevance of specification persistence but does not establish demand for Spec Kit extensions. [source: (martinfowler.com/redacted) fetched: no, host not on safe list] (confidence: medium)

   Data & Constraints

   • Persistence extensions must not replace or alter the shared delivery process, make a strategy mandatory/default, suppress unresolved converge findings, or treat artifact acceptance as authorization for application-code changes. [source: Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944] (confidence: high)
   • Later changes requiring implementation must return to shared delivery and converge against explicit intended artifacts. [source: docs/concepts/spec-persistence.md] (confidence: high)
   • Community flow-back safeguards include no edits to completed tasks, no revival of retired/superseded/cancelled entries, explicit approvals, and constitution conflict handling. [source: https://github.com/stn1slv/spec-kit-reconcile] (confidence: high)
   • No repository metric establishes feature-directory counts, persistence-model usage, reconciliation runs, or maintenance failures. [NEEDS CLARIFICATION: identify measurable success thresholds and representative fixtures.] (confidence: high)

   Evidence Against the Idea

   • The core documentation already supports all three models as conventions, so an extension could add maintenance burden without solving a demonstrated high-volume problem. [source: docs/concepts/spec-persistence.md] (confidence: medium)
   • Existing flow-back community tooling may make a new first-party extension duplicative. [source: https://github.com/stn1slv/spec-kit-reconcile] (confidence: high)
   • Flow-forward and flow-always may be primarily policy, naming, linking, or regeneration conventions rather than distinct automated behaviors. [ASSUMPTION] (confidence: low)
   • Automation could blur the delivery/persistence boundary or create conflicting sources of truth if safeguards are underspecified. [source: Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944; docs/concepts/spec-persistence.md] (confidence: high)

   Gaps & Open Questions

   • [NEEDS CLARIFICATION: Which concrete post-delivery operations, inputs, outputs, and artifact changes are required for flow-forward and living spec?]
   • [NEEDS CLARIFICATION: Are the three models independently useful in actual projects, and is there evidence of users selecting each?]
   • [NEEDS CLARIFICATION: What minimum safeguards and positive/negative acceptance tests must every persistence extension satisfy?]
   • [NEEDS CLARIFICATION: When is documentation sufficient, when is a preset appropriate, and what behavior specifically requires an extension?]
   • [NEEDS CLARIFICATION: What maintenance and ownership capacity exists for first-party support?]

   Sources

   • Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944 (host: github.com, policy: allowlisted)
   • [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 (host: github.com, policy: allowlisted)
   • Clarify delivery versus post-delivery spec persistence #4943 (host: github.com, policy: allowlisted)
   • Explore opt-in persistence extensions for flow-back, flow-forward, and flow-always (“Living”) #4944 (comment) (host: github.com, policy: allowlisted)
   • https://github.com/stn1slv/spec-kit-reconcile (host: github.com, policy: allowlisted)
   • docs/concepts/spec-persistence.md (host: repository, policy: not applicable)
   • (martinfowler.com/redacted) (host: martinfowler.com, policy: auto-refused — host not on safe list; repository citation only, not fetched)

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4944 · copilot · gpt52codex · 4.84 AIC · ⌖ 0.75 AIC · ⊞ 24.3K · ◷
7. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — opt-in-persistence-flows · Stage 4/5: Concept

   Concept: Opt-in persistence extensions for three artifact models

   • Slug: opt-in-persistence-flows
   • Created: 2026-10-13T16:15:33Z
   • Recommended option: Documentation-first, community-backed pilots

   Options

   Option A — Documentation-first, community-backed pilots

   +- Sketch: Keep the core delivery loop and persistence guidance neutral, define model-specific responsibilities and safeguards in documentation, and evaluate or improve community extensions where concrete automation already exists. Treat flow-back as the first pilot because reconcile supplies prior art, while requiring evidence and a separately scoped concept before pursuing automation for flow-forward or living spec.
   +- Appetite: small
   +- Trade-offs: Minimizes duplication, first-party maintenance, and boundary risk while making the three choices clearer. It may leave manual work in place and does not immediately provide automation for teams that need it. Its success depends on obtaining real demand and operation-level evidence.
   +- Rabbit holes: Turning documentation into an implicit protocol; trying to standardize every community extension; allowing a flow-back pilot to expand into converge or core amendment behavior.

   Option B — One shared opt-in persistence toolkit

   +- Sketch: Offer one optional toolkit with separately selected model behaviors, shared approval and preservation expectations, and model-specific user experiences. Teams choose a persistence mode without changing core delivery, and each mode routes subsequent implementation back through the standard process.
   +- Appetite: medium
   +- Trade-offs: Could reduce duplicated safeguards and offer a coherent user experience across models. It risks a large abstraction before the operations are understood, couples distinct workflows, and could become a de facto required framework or a new source of truth.
   +- Rabbit holes: Designing a universal artifact mutation language; reconciling incompatible history and regeneration semantics; supporting every template and preset; accidentally changing core command authority.

   Option C — Three independently maintained first-party extensions

   +- Sketch: Build separate opt-in extensions for flow-back, flow-forward, and living spec, each with a clearly bounded responsibility and explicit hand-back to the shared delivery loop. Teams choose a persistence mode without changing core delivery, and each mode routes subsequent implementation back through the standard process.
   +- Appetite: large
   +- Trade-offs: Maximizes model-specific fit and independent adoption, but creates the highest development, testing, documentation, compatibility, and ownership burden. It avoids forcing one abstraction but has no demonstrated demand yet for two of the three extensions and may duplicate existing community flow-back work.
   +- Rabbit holes: Three separate protocols for IDs, approvals, links, archival, and rationale; long-term support across agents and presets; migration from community tools; treating package separation as proof of distinct user value.

   Recommendation

   Recommend Option A as the smallest reversible step. It directly addresses the immediate boundary and clarity goals, leverages existing flow-back prior art, and avoids committing to behavior that the available evidence does not justify. Before any first-party extension is proposed, collect model-specific demand, define operation-level acceptance and preservation rules, and measure whether documentation/manual practice or community tooling fails the success bar.

   Out of Scope (for the recommended option)

   • Changes to specify, plan, tasks, implement, or converge, including converge authority and append-only behavior.
   • A mandatory or default persistence model.
   • A shared persistence framework or universal artifact mutation protocol.
   • Building three first-party extensions or replacing the existing community reconcile extension.
   • Implicit application-code changes, automatic acceptance of implementation as intent, or suppression of unresolved delivery findings.
   • Detailed command syntax, APIs, data models, templates, or implementation tasks.

   Assumptions to Validate

   • Teams can understand and apply the three models from precise documentation without a core command change.
   • The flow-back community extension is sufficiently maintained and bounded to serve as a meaningful prior-art pilot.
   • Flow-forward and living spec have distinct, recurring operations that are not adequately served by documentation or conventions; this is currently unverified.
   • Explicit approval, preservation, traceability, and hand-back rules are acceptable to users across models.
   • Evidence can be collected before deciding on first-party ownership and ongoing maintenance.

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4944 · copilot · gpt52codex · 4.84 AIC · ⌖ 0.75 AIC · ⊞ 24.3K · ◷
8. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — opt-in-persistence-flows · Stage 5/5: Decision — verdict needs-clarification

   Pipeline note: the Stage 2 research comment was queued after the Stage 3 problem comment due execution sequencing; the artifact content and stage labels are intact.

   Decision: Opt-in persistence extensions for three artifact models

   • Slug: opt-in-persistence-flows
   • Decided: 2026-10-13T16:15:33Z
   • Verdict: needs-clarification
   • Artifacts reviewed: intake.md | research.md | problem.md | concept.md

   Scorecard

   Criterion	Rating	Justification
   Problem validity	adequate	The repository documents real trade-offs in artifact persistence and the issue identifies a concrete boundary problem, but the scale and frequency of user pain are not measured.
   Evidence strength	weak	Evidence is strong for documented models and one community flow-back implementation, but there is no observed demand, adoption, or operation-level evidence for flow-forward or living spec.
   Value vs. inaction	adequate	Clearer boundaries and safeguards could reduce drift, fragmentation, and duplication, but the cost of continuing with conventions/community tooling is unknown.
   Feasibility / appetite	adequate	A documentation-first, community-backed pilot is a small, reversible concept; a shared toolkit or three first-party extensions would carry materially higher uncertainty and cost.
   Strategic fit	adequate	The concept preserves the unchanged delivery loop and optionality requested by the issue; first-party ownership fit is not established.
   Risk posture	adequate	Boundary, approval, preservation, and duplication risks are identified, but mitigation requirements and negative tests are not yet validated across all models.

   Verdict & Rationale

   Needs clarification. The problem is plausible and a small documentation-first option is shaped, but the evidence-strength gate for go is not met: demand and concrete operations are documented only for flow-back, while flow-forward and living spec remain largely unverified. Do not hand off to /speckit-specify until the blocking questions below are answered and the research/shape artifacts are revisited. This is not a kill: the issue may be worth pursuing after evidence improves.

   If needs-clarification

   • Blocking questions:
     • [NEEDS CLARIFICATION: Which concrete post-delivery operations, inputs, outputs, and artifact changes are required for flow-forward and living spec?]
     • [NEEDS CLARIFICATION: What observed users, adoption, support requests, or project evidence demonstrate demand for each model?]
     • [NEEDS CLARIFICATION: What measurable thresholds define success and justify an extension or first-party ownership over documentation/community tooling?]
     • [NEEDS CLARIFICATION: What approval, preservation, traceability, and hand-back rules have positive and negative acceptance evidence for each model?]
     • [NEEDS CLARIFICATION: Is the existing community flow-back extension adequate, complementary, or a duplication risk for any first-party work?]
       +- Revisit stage: research, then shape

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4944 · copilot · gpt52codex · 4.84 AIC · ⌖ 0.75 AIC · ⊞ 24.3K · ◷
9. github-actions

   added

   feature-needs-clarificationFeature assessment verdict: needs clarificationFeature assessment verdict: needs clarification

   on Oct 13, 2026
10. stn1slv commented on Oct 13, 2026

    

    stn1slv

    on Oct 13, 2026

    Contributor

    More actions

    A correction to my comment above. I wrote that under a flow-forward or living-spec constitution "it says the in-place amendment doesn't match". That was accurate for v1.3.0 but read like a guard, and it wasn't one: v1.3.0 still amended the completed artifacts and only reported the mismatch afterwards, which doesn't fit "the project's governance" in #4948.

    v1.3.1 changes that. When the constitution says the project uses flow-forward, the run writes nothing, asks nothing and recommends a new feature directory. Living spec and an unstated model reconcile normally, with no default model assumed. It also names any open converge task written against an entry it amends, first in the Next Step, so implement doesn't carry out work against the old intent.

    One more precision: "re-running the same report changes nothing" is what the prompt instructs and what the fixture checks, not a guarantee. One fixture run broke it during this release cycle and a rule was added to fix it. The baseline files in the repo list which cases ran against which commit.

    AI disclosure: drafted with Claude Code (Claude Opus 5.5, session-default reasoning settings) at my request in an interactive, human-supervised session, and reviewed by me before posting.