bubbles-scope-workflow-runtime
Operate Bubbles scope artifacts correctly during planning, implementation, testing, and validation. Use when creating a new scope, deciding between single-file and per-scope-directory layout, writing a Test Plan, choosing DoD shape, picking the next scope to work, or honoring scope isolation during multi-scope work.
- License 许可
- MIT
- 最近更新
- 2026-11-07
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- bubbles-scope-workflow-runtime
- description
- Operate Bubbles scope artifacts correctly during planning, implementation, testing, and validation. Use when creating a new scope, deciding between single-file and per-scope-directory layout, writing a Test Plan, choosing DoD shape, picking the next scope to work, or honoring scope isolation during multi-scope work.
03 SKILL.md 正文
Bubbles Scope Workflow Runtime
Goal
Use the scope layout, DoD shape, dependency declarations, and isolation rules the framework expects, so every scope's evidence and status changes survive state-transition-guard.sh and artifact-lint.sh.
When to use
- Creating or revising
specs/<NNN>/scopes.md - Splitting a feature into per-scope directories
- Picking the next scope to execute (DAG-based work selection)
- Writing the Test Plan table for a scope
- Choosing between single-file and tiered DoD format
v4.1.0 scope-kind taxonomy
Scopes may declare an optional Scope-Kind: header to opt out of E2E enforcement when the scope legitimately does not produce live-runtime evidence:
## Scope 3 — Cosign signature verification
Status: Done (completed_owned)
Scope-Kind: deploy-pointer
Lockdown-FRs: [FR-020]
Valid kinds (default runtime-behavior): runtime-behavior, contract-only, deploy-pointer, ci-config, docs-only, bootstrap. Only runtime-behavior enforces the 3-row E2E DoD/Test-Plan requirement (G008A). See docs/v4.1.0-delivered-pending-activation.md for the full taxonomy + lockdown tag patterns + evidence-by-reference anchor convention.
Layout decision
| Scope count | Layout |
|---|---|
| ≤ 5 scopes | Single specs/<NNN>/scopes.md with all scopes inline |
| 6+ scopes | specs/<NNN>/scopes/_index.md + per-scope directory specs/<NNN>/scopes/NN-name/scope.md (one report.md per scope optional) |
Required scope sections (every scope)
- Status —
Not Started/In Progress/Done/Blocked - Depends On — list of scope IDs this scope blocks on (DAG, no cycles)
- Gherkin scenarios — Given/When/Then per acceptance criterion
- Implementation plan — short ordered list of steps; vertical slice preferred over horizontal layer batches
- Test Plan table — one row per test that will execute, with file path, category (from Canonical Test Taxonomy), description, command, live-system Yes/No
- Definition of Done — Tiered Format — Core Items (one bullet per scope-specific outcome) + Build Quality Gate (one grouped bullet covering lint/format/warnings/artifact-lint/docs)
Test Plan ↔ DoD parity (NON-NEGOTIABLE)
Test Plan row count MUST equal DoD test-related item count. The framework's lint rejects scopes where they diverge.
Stress tests when latency SLAs present (G026)
If the scope's Gherkin or design defines a latency target (< X ms, p95 < Y, throughput target), the Test Plan MUST include a stress row and the DoD MUST include a corresponding stress evidence item.
Scope isolation (per-scope-directory mode)
- Each scope only edits its own
scopes/NN-name/files plus its owned source/test files. - A scope MUST NOT silently amend another scope's DoD, scenarios, or status. Surface the gap via the orchestrator.
DAG-based pickup
When picking the next scope:
- List scopes whose
Status: Not StartedAND everyDepends OnisDone. - From that ready set, prefer the smallest, most foundational scope.
- Never start work on a scope while a higher-priority pre-existing bug remains in the same feature folder (warn-then-proceed only with explicit acknowledgment).
Pre-existing bug awareness
Before starting new scope work in specs/<feature>/, scan specs/<feature>/bugs/*/state.json for status: in_progress|not_started|blocked. Surface findings to the orchestrator.
DoD anti-patterns
- ❌ "All tests passing" as a single catch-all DoD item — split per category
- ❌ "Audit clean" as a catch-all on top of Build Quality Gate — duplicate
- ❌ Pre-checking DoD items
[x]at scope creation — every[x]must come from real execution - ❌ DoD items without inline evidence reference
Authoritative modules
agents/bubbles_shared/scope-workflow.md— workflow phases + status ceilingagents/bubbles_shared/scope-templates.md— scope.md canonical templateagents/bubbles_shared/artifact-lifecycle.md— feature/bug artifact lifecycleagents/bubbles_shared/planning-core.md— Test Plan shape + test-plan.json handoffagents/bubbles_shared/state-gates.md— status integritybubbles/scripts/artifact-lint.sh— template/section presence enforcement
04 同仓库更多 Skills
smackerel-trace-capture
Wire Smackerel's concrete validate-plane stack into the framework trace-driven defect-discovery method. Use when running live-category tests (integration/e2e/e2e-ui/stress) against the ephemeral test stack; capturing SLO or trace evidence; hunting latency/error/perf bugs from spans; querying the test-stack Jaeger or Prometheus; or touching `.specify/runtime/observability`. Concrete smackerel endpoints + the exact `capture-slo.sh` command; do NOT duplicate `bubbles-observability-adapter` — this only adds the wiring.
smackerel-no-defaults
Enforce Smackerel's NO-DEFAULTS / fail-loud SST policy. Use when editing config, Docker Compose, deploy adapters, docs, instructions, skills, env handling, host bind addresses, or any runtime value that could be hidden by fallback syntax.
bubbles-workflow-mode-resolution
Resolve a Bubbles workflow mode against `bubbles/workflows.yaml`, including template inheritance, status ceilings, gate wiring, and decision policy. Use when picking a mode for a request, when a guard reports a mode-related failure, or when extending workflows.yaml with a new mode or template. Covers natural-language intent routing and the workflow registry consistency rules.
bubbles-workflow-execution-loops
Run per-round synchronous workflow execution loops correctly. Use when orchestrating a multi-round workflow, dispatching specialist subagents, handling round-based remediation, or interpreting a workflow mode's execution policy. Covers authorized direct execution, dispatch-and-wait, batch-then-summarize prohibition, and mapped-mode execution.
bubbles-vscode-agent-constraints
Design agents that fit the VS Code Copilot Chat runtime instead of fighting it. Use when authoring or editing any `*.agent.md`; when adding `tools:`, `agents:`, `handoffs:`, `model:`, `user-invocable:`, or `disable-model-invocation:` frontmatter; when designing an orchestrator that dispatches specialists; when a design implies agent-calls-agent-calls-agent chaining; when a subagent dispatch silently no-ops or an agent cannot be selected in the dropdown; or when writing a governance rule about delegation that the runtime cannot actually enforce. Prevents multi-level-subagent designs, prose-only dispatch laws, and frontmatter/body contradictions.
bubbles-upkeep-cadence
How to schedule, dispatch, and record recurring operational upkeep tasks (backup, restore-drill, BCDR-drill, patch-cycle, secret-rotation, flag-cleanup, compliance-sweep). Use when authoring or modifying `config/upkeep-calendar.yaml`, when investigating a missed task, when reading the upkeep ledger, or when adding a new task type.