[Feature]: First-party bugfix and assess bundles with bundled workflows

Đang mở
#4,495 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
cli, documentation, tooling

Hướng nghiên cứu

Bắt đầu với các lớp workflow và bundle hiện có, đặc biệt là workflows/speckit/, workflows/catalog.json, bundles/catalog.community.json và các bài kiểm thử xác thực bundle và workflow. Đọc workflows/README.md và docs/reference/bundles.md, sau đó theo dõi việc thêm/xóa bundle và quá trình phân giải catalog builtin://default. Hoàn thành nghĩa là cả workflow và bundle đều được xác thực, cài đặt và xóa cùng nhau mà không có thay đổi ngoài dự kiến, kiểm tra tính nhất quán của catalog đạt yêu cầu, và các tài liệu được yêu cầu đã được cập nhật.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature-go triage-nice-to-have
Problem Statement

Spec Kit ships exactly one out-of-the-box workflow: the SDD cycle (speckit, auto-installed at init). The bug and assess extensions provide multi-step pipelines (assess → fix → test, and intake → research → define → shape → decide) that are ideal workflow candidates, but they can only be driven by manually invoking each command — with no gates, persisted state, or workflow resume. There is no orchestrated bug-fixing or idea-assessment path in stock Spec Kit.

Discussed and agreed in #4461: the fix follows the existing layering — workflows live in the workflow layer, bundles are the composition layer. No new contribution types.

Proposed Solution

Two first-party bundles, each pairing its extension with a bundled workflow:

  1. Bundled workflows (parallel to workflows/speckit/):

    • workflows/bugfix/workflow.yml (id bugfix): speckit.bug.assess → gate "review the assessment before any code change" (reject aborts) → speckit.bug.fix → speckit.bug.test; inputs: report, slug
    • workflows/assess/workflow.yml (id assess): intake → research → define → shape → decide → gate on the verdict (stops there; the /speckit.specify handoff stays manual); inputs: idea, slug
    • Both registered in workflows/catalog.json and packaged with the CLI (core_pack) like speckit — nothing is auto-installed at init; the extensions stay opt-in, installation happens via bundle add.
  2. First-party bundles:

    • bundles/bugfix/ — bundle.yml composing the bug extension + bugfix workflow (pinned versions, role developer)
    • bundles/assess/ — bundle.yml composing the assess extension + assess workflow
    • bundles/catalog.json listing both (repo-shipped first-party counterpart to catalog.community.json, verified: true)
  3. First-party bundle catalog wiring: the reserved builtin://default catalog (currently empty) resolves entries from bundles/catalog.json — online from the repo, offline from the packaged snapshot (mirroring the community catalog pattern). Without this, specify bundle add bugfix cannot resolve by id.

specify bundle add bugfix then installs the extension and its orchestrated pipeline in one step; bundle update/remove provide the lifecycle coupling.

Alternatives Considered
  • Extension-owned workflows via provides.workflows in extension.yml (rejected in #4461: duplicates the bundle layer inside the extension layer).
  • git / agent-context extension workflows — deliberately excluded: git runs via lifecycle hooks, agent-context is a single hook-driven command, not a multi-step flow.
  • Only registering the workflows in workflows/catalog.json without bundles — would leave the extension↔workflow coupling to the user and defeat the agreed composition layer.
Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

Not applicable

Use Cases
  1. A user hits a bug and wants a guided, resumable pipeline: assess → human gate before any code change → fix → test, instead of invoking three commands in the right order by hand.
  2. A team wants idea triage before SDD: run the assess pipeline with a review gate at the verdict, then hand surviving ideas to /speckit.specify manually.
Acceptance Criteria
  • validate_workflow passes for both new workflow YAMLs; steps/gates/inputs match the schema in workflows/README.md
  • workflows/catalog.json entries match the bundled YAMLs' ids/versions/urls; contract test mirrors test_wheel_bundled_presets.py for bundled workflows
  • specify bundle validate bundles/bugfix --offline (and assess) passes with zero unresolved references
  • specify bundle add bugfix in a fresh project installs the bug extension and registers the bugfix workflow (workflow info/run works: assess → gate → fix → test)
  • specify bundle remove bugfix uninstalls both contributed components; independently-installed components are never removed (no collateral removals, FR-022)
  • Both bundles' catalog pins match the shipped extension/workflow versions; automated consistency test
  • Docs updated: docs/reference/bundles.md (first-party bundles + bundles/catalog.json), workflows/README.md (layout), bundle READMEs
  • Existing behavior unchanged: speckit workflow auto-install, extension add/remove, and community catalogs behave identically before/after
Additional Context
  • Discussion: #4461 (maintainer-approved shape: two first-party bundles composing existing pieces, bug/assess command surfaces unchanged)
  • Related discussion #4415 for the acceptance-criteria-first workflow
  • Out of scope (follow-up): fully offline bundle install --offline. Today the bundle manifest itself always resolves via its catalog download_url, and workflow add has no bundled-asset fallback — both would need packaged first-party bundle artifacts. Tracked separately once this feature lands.
  • Open point for the PR: hosting of the bundle artifacts referenced by the bundles/catalog.json download_urls (e.g. CI-built release assets), to be decided during implementation.
Ngôn ngữ chính
Python
Star
138k
Fork
12.4k
Merge trung bình
3 ngày 6 giờ
Pull request đã merge (30 ngày)
136

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của github/spec-kit

Tất cả issue của github/spec-kit

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.