[Feature]: Move bug workflow artifacts to a configurable docs/speckit/bugs root through staged migration

Aberta
  • Algo errado?
#5,038 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github, python
Domínio
developer-experience, tooling

Direção de pesquisa

Start with extensions/bug/README.md and trace how the assess, fix, and test stages select BUG_DIR, read and write reports, and check prerequisites. The issue calls for coordinated changes across extension instructions, configuration, migration, hooks, documentation, and tests; first map those entry points and existing configuration conventions. Done means the staged rollout and acceptance criteria are covered, including legacy compatibility, custom roots, migration conflicts, and workflow continuity.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

triage-out-of-scope

Problem and rationale

The bundled bug extension stores authored bug reports under .specify/bugs/<slug>/, mixing workflow evidence with tooling/configuration.

Align with github/spec-kit#5037 (https://github.com/github/spec-kit/issues/5037): keep tooling/configuration in .specify/ and authored workflow artifacts under a clearly owned documentation hierarchy. Bug artifacts remain distinct from SDD and idea-assessment artifacts. Parallel assessment tracking: github/spec-kit#5039 (https://github.com/github/spec-kit/issues/5039).

Proposed solution

Introduce explicit opt-in to a configurable bug artifact root, defaulting in the new layout to:

docs/speckit/bugs/<slug>/
  assessment.md
  fix.md
  test.md

The bug extension owns selection and migration; core must not acquire bug-specific knowledge merely to enforce a directory convention. Support an environment root override, provisionally SPECIFY_BUGS_DIR, subject to existing configuration conventions. Define project-level layout selection and environment/project/default precedence so absent environment variables do not redirect ongoing workflows. Do not automatically persist transient overrides. Relative roots resolve against the Spec Kit project root.

Apply one resolved root consistently across assess/fix/test, slug uniqueness, prerequisites, reads/writes, hook context (BUG_DIR), and completion/handoff references. Preserve recorded paths and ongoing workflow selection rather than silently rebasing them under changed configuration.

Migration is explicit and preserves authored content. Competing copies of the same slug must cause an actionable conflict, not arbitrary selection, merging, overwriting, or duplicate workflows. Preserve existing stage semantics, source-editing restrictions, overwrite confirmation, and applicable path-safety guarantees.

Four-stage rollout

  1. Opt-in: Support unified/custom roots while retaining .specify/bugs/ defaults for non-opted-in projects.
  2. Deprecation warnings: Warn on the legacy root with actionable migration guidance, without moving files or changing behavior.
  3. Default flip with legacy opt-out: Default new adoption to docs/speckit/bugs/; preserve explicit legacy compatibility for existing projects and in-progress bugs.
  4. Removal: Retire legacy-root support after an adequate announced transition period. Detect unmigrated workflows and provide migration errors rather than missing-report errors or duplicate artifact creation.

Do not assign specific release versions. Consecutive PRs are not a compatibility window; allow release/adoption time. The extension can progress independently of core and assessment rollouts.

Acceptance criteria

  • Initial opt-in preserves legacy defaults unless explicitly selected.
  • Opted-in defaults use docs/speckit/bugs/<slug>/; an environment override can relocate the root.
  • Selection, persistence, precedence, existing-project detection, and project-relative path resolution are explicit across commands.
  • Invalid configuration produces actionable errors rather than silent fallback.
  • Assess/fix/test, prerequisites, slug collision checks, hooks, and report references use the same selected root.
  • Existing reports, recorded paths, and in-progress stage selection remain coherent across upgrades/configuration changes.
  • Migration is explicit and preserves content; duplicate slugs across roots are surfaced without silent precedence or overwrites.
  • Existing stage semantics, source-code editing restrictions, overwrite protection, and applicable path-safety guarantees remain intact.
  • Warnings do not change behavior; default flip retains documented legacy opt-out; removal reports clear migration errors.
  • Positive and negative coverage demonstrates legacy compatibility, opt-in/custom roots, absent overrides, invalid roots, collisions, and workflow continuity.
  • Extension instructions, documentation, examples, hook guidance, and directly related references are updated together.
  • The staged transition allows adequate announced adoption time without committing to specific versions.

Alternatives and scope

Keeping .specify/bugs/ avoids migration but leaves authored evidence mixed with tooling. Implementing extension paths in core or adding a shared parent-directory variable introduces unnecessary coupling. Environment-only selection and automatic moves risk broken ongoing work and duplicates.

This is a separate tracking issue, not an expansion of the core SDD implementation or an all-stages PR. The existing contract is documented in extensions/bug/README.md, including the three artifact names and hook reuse of BUG_DIR. All agents are affected.

Replaces the mistakenly filed fork issue https://github.com/mnriem/spec-kit/issues/59, with the user's authorization.

AI disclosure

Drafted and filed on behalf of @mnriem using GitHub Copilot App, powered by GPT-6.1 Sol (gpt-6.1-sol), in human-supervised interactive mode. The agent inspected the bundled README and drafted the rationale, rollout, and acceptance criteria from the user-approved discussion. The user authorized upstream filing. Reasoning-effort setting was not available to report. No implementation changes were made.

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.