Activity

1. 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
2. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — clarify-delivery-persistence · Stage 1/5: Intake

   Idea Intake: Clarify delivery versus post-delivery spec persistence

   • Slug: clarify-delivery-persistence
   • Created: 2026-10-13T13:28:46Z
   • Source: Clarify delivery versus post-delivery spec persistence #4943 (labeled feature-assess)
   • Type: improvement

   Idea (as captured)

   The persistence documentation blurs the boundary between the shared feature delivery process and the team's subsequent artifact persistence strategy. Clarify this boundary in docs/concepts/spec-persistence.md and docs/guides/evolving-specs.md. Revise or contextualize wording about edits during implementation and resuming implementation so that discovery timing is not confused with the post-delivery persistence strategy. Clearly separate the common delivery loop from each model's artifact maintenance guidance.

   Acceptance criteria: both pages distinguish shared feature delivery from post-delivery artifact persistence; all three models retain the same delivery/completeness process; flow-back wording does not imply that converge accepts code as a replacement source of intent or requires a new core amendment command; subsequent implementation changes remain tied to explicit intended artifacts; guidance stays neutral and does not make a model the default.

   Scope: documentation only. No command/template behavior changes, new core amendment command, retirement-marker protocol, or changes to converge's authority or append-only contract.

   Restated

   Update the two persistence-guidance pages so readers can distinguish the shared specify-to-converge delivery loop from team-owned choices about maintaining artifacts after delivery. Preserve neutral treatment of flow-forward, living spec, and flow-back, and avoid implying that a core amendment command or a code-approved shortcut is required.

   Origin & Context

   • Raised by: mnriem, collaborator, in Clarify delivery versus post-delivery spec persistence #4943
   • Trigger: Follow-up documentation clarification requested after [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 was closed as not planned; the maintainer response identified ambiguity in the current wording.

   First-Glance Unknowns

   • [NEEDS CLARIFICATION: Which exact wording changes and examples best clarify the boundary without duplicating the delivery documentation?]
   • [NEEDS CLARIFICATION: Should the pages include an optional link to community persistence tooling, and if so, what neutral framing is appropriate?]
   • [NEEDS CLARIFICATION: Are there additional persistence-related pages that use the same ambiguous framing and should be checked for consistency?]

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

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — clarify-delivery-persistence · Stage 2/5: Research

   Idea Research: Clarify delivery versus post-delivery spec persistence

   • Slug: clarify-delivery-persistence
   • Created: 2026-10-13T13:28:46Z
   • Evidence confidence (overall): high

   Users & Demand

   • The request is raised by a repository collaborator as a focused follow-up to a maintainer response that explicitly welcomed a documentation clarification — [source: Clarify delivery versus post-delivery spec persistence #4943; [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 comment 6146476860] (confidence: high, cited).
   • The directly affected users are readers of the persistence concept and evolving-specs guide who may interpret model-specific maintenance guidance as alternate delivery workflows — [source: docs/concepts/spec-persistence.md; docs/guides/evolving-specs.md] (confidence: high, cited).
   • No usage telemetry, support-ticket volume, interview data, or evidence of how often the ambiguity causes mistakes is included — [NEEDS CLARIFICATION: observed frequency and impact of reader confusion] (confidence: low, cited gap).

   Prior Art

   • The current concept page explicitly says the models are team conventions, that none is the default, and that Spec Kit does not force one maintenance strategy; however, its Flow-Back section describes edits during implementation without first separating that maintenance choice from delivery — [source: docs/concepts/spec-persistence.md] (confidence: high, cited).
   • The current guide presents a common sequence for flow-forward and living spec, while its Flow-Back sequence discusses artifact reconciliation and continuing implementation; this creates the ambiguity the issue identifies — [source: docs/guides/evolving-specs.md] (confidence: high, cited).
   • The maintainer response to the related core feature request states that delivery is the same across persistence models, converge remains an assessment against documented intent, and a core amendment command is not planned; it welcomes a focused documentation PR — [source: [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940 comment 6146476860] (confidence: high, cited).
   • The related proposal mentions community reconcile and intent extensions, but the requested issue explicitly does not require community-tooling links; their suitability and maintenance status are not independently assessed here — [source: [Feature]: Core flow-back step for drift where the code is ahead of the spec #4940] (confidence: medium, cited).

   Market & Context

   • The alternative to changing the pages is leaving readers to infer the distinction from separate sections; the documented cost is possible confusion about whether persistence models are alternate workflows or imply missing core automation — [source: Clarify delivery versus post-delivery spec persistence #4943] (confidence: high, cited).
   • This is repository documentation rather than a market-facing product capability; no external market data is relevant to the narrow request — [ASSUMPTION] (confidence: medium).

   Data & Constraints

   • Scope is documentation only, with no command, template, converge-authority, append-only, or core amendment behavior changes — [source: Clarify delivery versus post-delivery spec persistence #4943] (confidence: high, cited).
   • The two named pages currently contain the relevant model descriptions and delivery sequences; the repository also contains broader workflow documentation, so consistency outside those pages remains an open check — [source: docs/concepts/spec-persistence.md; docs/guides/evolving-specs.md] (confidence: high, cited).
   • No quantitative baseline or acceptance-test requirement is supplied; success must be judged against the stated documentation acceptance criteria — [NEEDS CLARIFICATION: whether documentation lint/link checks cover the distinction] (confidence: medium, cited gap).

   Evidence Against the Idea

   • The pages already state several safeguards, including that no persistence model is required or default and that flow-back requires reconciliation; a wording-only change may yield limited additional value if readers are not actually confused — [source: docs/concepts/spec-persistence.md; docs/guides/evolving-specs.md] (confidence: medium, cited).
   • The issue provides no observed examples of misimplementation caused by the ambiguity, so the magnitude of the problem is not measured — [NEEDS CLARIFICATION: concrete reader or contributor incidents] (confidence: high, cited gap).
   • Broadening the change to other documentation or adding links to community tooling could reintroduce the workflow/persistence confusion that this issue seeks to remove — [source: Clarify delivery versus post-delivery spec persistence #4943] (confidence: medium, cited).

   Gaps & Open Questions

   • [NEEDS CLARIFICATION: What measurable or reviewable signal will establish that readers now distinguish delivery from persistence?]
   • [NEEDS CLARIFICATION: Should related pages beyond the two named files be searched and updated, or only checked for contradictions?]
   • [NEEDS CLARIFICATION: Is a short shared delivery-loop statement preferable in both pages, or should one page link to the other?]

   Sources

   • github/spec-kit#4943 (host: github.com, policy: allowlisted)
   • github/spec-kit#4940 (host: github.com, policy: allowlisted)
   • docs/concepts/spec-persistence.md (repository source)
   • docs/guides/evolving-specs.md (repository source)

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

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Feature assessment — clarify-delivery-persistence · Stage 3/5: Problem

   Problem Definition: Clarify delivery versus post-delivery spec persistence

   • Slug: clarify-delivery-persistence
   • Created: 2026-10-13T13:28:46Z
   • Inputs used: intake.md and research.md

   Problem Statement

   Readers of Spec Kit's persistence documentation can confuse the shared feature-delivery process with the later, team-owned choice of how artifacts are maintained. The ambiguity matters now because the documentation follow-up to #4940 needs to clarify that all persistence models still rely on explicit intended artifacts and the same delivery/completeness loop.

   Affected Users & Stakeholders

   • Users: Spec Kit adopters and contributors reading the persistence concept and evolving-specs guide — they may infer alternate workflows, a missing core reconciliation step, or permission to treat accepted code as a substitute for documented intent.
   • Stakeholders: Spec Kit maintainers — they need the documentation to reflect the intended authority and neutral persistence-model guidance stated in the related issue response.
   • Stakeholders: Community extension authors and users — they may be affected if core documentation implies that optional persistence tooling is required or endorsed as part of delivery.

   Goals

   • Readers can distinguish the common specify → plan → tasks → implement → converge process from post-delivery artifact persistence choices.
   • Each of the three persistence models is described as a neutral maintenance convention while retaining the same delivery/completeness expectations.
   • Flow-back wording does not imply that converge replaces documented intent, that a core amendment command is required, or that a persistence model is the default.

   Non-Goals

   • No command, template, workflow, or converge-authority behavior changes.
   • No core amendment command, retirement-marker protocol, or changes to converge's append-only contract.
   • No requirement to adopt a persistence model or add community-tooling links.
   • No implementation of documentation changes beyond the two named pages unless a separate inconsistency is explicitly confirmed.

   Success Metrics

   • Both named pages explicitly distinguish delivery from post-delivery persistence, verified by maintainer/documentation review (baseline: distinction is currently implicit or inconsistent).
   • A review of the pages finds all three models using the same delivery/completeness framing and no wording that treats flow-back as a missing core delivery step (baseline: unknown; qualitative).
   • No source-code or command behavior changes are present in the resulting change (baseline: documentation-only scope).
   • [NEEDS CLARIFICATION: Whether documentation tests or link checks provide an automated baseline for this wording change.]

   Cost of Inaction

   Readers may continue to treat persistence models as alternate delivery workflows or infer that a core reconciliation command is missing. That can create avoidable questions about converge's authority and encourage documentation or process changes outside the intended scope, although the frequency and severity of this confusion are not measured.

   Open Questions

   • [NEEDS CLARIFICATION: Which exact wording and examples best clarify the boundary without duplicating broader delivery documentation?]
   • [NEEDS CLARIFICATION: Should related pages beyond the two named files be checked or updated for the same ambiguity?]
   • [NEEDS CLARIFICATION: Is a shared delivery-loop statement in both pages preferable to a cross-link?]
   • [NEEDS CLARIFICATION: What review signal will establish that readers now distinguish delivery from persistence?]

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4943 · copilot · gpt52codex · 4.09 AIC · ⌖ 0.677 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 — clarify-delivery-persistence · Stage 4/5: Concept

   Concept: Clarify delivery versus post-delivery spec persistence

   • Slug: clarify-delivery-persistence
   • Created: 2026-10-13T13:28:46Z
   • Recommended option: Option A — Focused boundary clarification

   Options

   Option A — Focused boundary clarification

   +- Sketch: Revise the two named pages so each first states the shared delivery/completeness loop, then describes the three persistence models as post-delivery maintenance choices. Tighten Flow-Back language to distinguish accepted discoveries from delivery acceptance, while preserving neutral model descriptions and the documentation-only boundary.
   +- Appetite: small
   +- Trade-offs: Directly addresses the documented ambiguity with the least change and keeps scope reviewable; it may not resolve similar wording elsewhere and provides no measured evidence of reader impact.
   +- Rabbit holes: Expanding into a repository-wide terminology rewrite, adding community-tooling links, or changing converge guidance.

   Option B — Documentation consistency pass

   +- Sketch: Perform the focused clarification plus a search of related workflow and persistence pages, updating any page that presents model-specific maintenance as a delivery sequence. Publish a consistent cross-reference to the shared delivery process.
   +- Appetite: medium
   +- Trade-offs: Better consistency and lower risk of leaving a contradictory page behind; increases review surface and could broaden a narrowly scoped issue without evidence that other pages are affected.
   +- Rabbit holes: Reworking general workflow documentation, changing command documentation, or introducing a new canonical glossary.

   Option C — Do nothing

   +- Sketch: Retain the current pages and rely on the existing statements that no model is required or default, plus maintainer clarification in the related issue.
   +- Appetite: small
   +- Trade-offs: No implementation or review cost; leaves the identified ambiguity in place and keeps readers dependent on inference or issue history.
   +- Rabbit holes: Future ad hoc clarifications, inconsistent contributor explanations, or pressure for a core command to resolve a documentation problem.

   Recommendation

   Recommend Option A. It directly targets the two pages named in the request, fits the documentation-only appetite, and can be reviewed against the stated qualitative metrics: explicit separation of delivery and persistence, consistent treatment of all three models, and no implication that converge accepts code as intent. Option B should be considered only if the repository search finds concrete contradictions beyond the named pages.

   Out of Scope (for the recommended option)

   +- Command, template, workflow, or converge-authority behavior changes.
   +- A core amendment command, retirement-marker protocol, or changes to converge's append-only contract.
   +- Choosing, requiring, or defaulting any persistence model.
   +- Adding or endorsing community-tooling links.
   +- A repository-wide documentation rewrite unless a directly contradictory page is confirmed.

   Assumptions to Validate

   +- The two named pages are the primary sources of the ambiguity.
   +- Maintainers prefer a concise shared delivery-loop framing rather than duplicating extensive workflow guidance.
   +- Documentation review can verify the acceptance criteria even without quantitative reader telemetry.
   +- No additional policy or terminology in the project constitution conflicts with the proposed neutral clarification.

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4943 · copilot · gpt52codex · 4.09 AIC · ⌖ 0.677 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 — clarify-delivery-persistence · Stage 5/5: Decision — verdict go

   Decision: Clarify delivery versus post-delivery spec persistence

   • Slug: clarify-delivery-persistence
   • Decided: 2026-10-13T13:28:46Z
   • Verdict: go
   • Artifacts reviewed: intake.md | research.md | problem.md | concept.md

   Scorecard

   Criterion	Rating	Justification
   Problem validity	adequate	The two named pages contain wording that can blur delivery and persistence, and the maintainer response to the related request confirms the ambiguity is worth correcting; the frequency of confusion is not measured.
   Evidence strength	adequate	The issue, related maintainer response, and current repository pages directly support the scope and problem, although there is no telemetry or incident count.
   Value vs. inaction	adequate	A small documentation change can reduce inference about alternate workflows and missing core automation at low cost; the magnitude of avoided confusion is unknown.
   Feasibility / appetite	strong	A focused documentation-only clarification is a small, bounded option with clear non-goals and reviewable acceptance criteria.
   Strategic fit	adequate	The change reinforces the repository's documented workflow and neutral persistence-model guidance; no conflicting constitution rule was found in the assessment evidence.
   Risk posture	adequate	Scope, authority, and neutrality risks are explicitly bounded, but consistency with other documentation and the best review signal remain open questions.

   Verdict & Rationale

   Go. The problem is sufficiently valid, the evidence is adequate rather than speculative, and Option A provides a small, credible way to improve clarity without changing commands or converge behavior. The remaining unknowns are suitable for specification and documentation review, not blockers to assessing the focused change.

   If go — Handoff to /speckit-specify

   • Problem: Readers can confuse the shared specify-to-converge delivery process with post-delivery choices for maintaining feature artifacts.
   • Chosen approach: Option A — Focused boundary clarification in docs/concepts/spec-persistence.md and docs/guides/evolving-specs.md.
   • In scope / out of scope: Make the delivery/persistence distinction explicit, preserve the same delivery loop for all three models, and tighten Flow-Back wording; exclude commands, templates, converge authority, amendment behavior, model defaults, community-tooling links, and unrelated docs changes.
   • Success metrics: Both pages explicitly separate delivery from persistence; all models retain the same completeness framing; no wording implies code approval substitutes for documented intent or that a core amendment command is required; scope remains documentation-only.
   • Carried-forward open questions: Check for directly contradictory wording in related pages; choose concise shared-loop wording versus cross-linking; define the review signal for reader clarity; validate no constitution terminology conflicts.

   Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4943 · copilot · gpt52codex · 4.09 AIC · ⌖ 0.677 AIC · ⊞ 24.3K · ◷
7. github-actions

   added

   feature-goFeature assessment verdict: go — ready to hand off to /speckit.specifyFeature assessment verdict: go — ready to hand off to /speckit.specify

   on Oct 13, 2026
8. mnriem

   closed this as completedin #4945on Oct 13, 2026