cc-os/openspec/specs/issue-backlog/spec.md

72 lines
3.9 KiB
Markdown
Raw Normal View History

# issue-backlog
## ADDED Requirements
### Requirement: Tracker key grammar excludes Planka
The `.cc-os/config` `tracker` key SHALL accept exactly `forgejo:<owner>/<repo>`,
`github:<owner>/<repo>`, or `repo:<path>`. `config-write` and the os-status
`tracker-configured` check SHALL reject any other value, including `planka:<board>`, with a
one-line error naming ADR-0042 and pointing to `/os-backlog:route`; rejection SHALL never
block or fail a session (fail-soft).
#### Scenario: Legacy planka tracker value encountered
- **WHEN** a config containing `tracker=planka:cc-os` is read by config-write validation or
the os-status check
- **THEN** the value is rejected with a one-line message citing ADR-0042 and suggesting
`/os-backlog:route`, and the session continues normally
#### Scenario: Valid git tracker accepted
- **WHEN** `config-write` is invoked with `tracker=forgejo:jared/cc-os`
- **THEN** the key is written, other config keys and comments are preserved, and the
project index is upserted
### Requirement: Capture files a labeled issue on the configured tracker
`/os-backlog:capture` SHALL create an issue on the project's configured tracker (via `tea`
for forgejo, `gh` for github, an issue file for `repo:`) carrying a priority label (P0P3)
when known and no state labels; capture SHALL never apply the `next` label. When no tracker
key is configured in a git project, capture SHALL suggest `/os-backlog:route` once and
otherwise degrade to reporting what it could not do.
#### Scenario: Mid-session capture on a Forgejo-tracked project
- **WHEN** deferred work surfaces in a project with `tracker=forgejo:jared/cc-os`
- **THEN** a new open issue is created on that repo via `tea` with the title, a body noting
the originating context, and any known priority label — and nothing else
#### Scenario: Capture with no tracker configured
- **WHEN** capture is invoked in a git project whose config has no tracker key
- **THEN** no issue is created; the skill suggests `/os-backlog:route` once and exits
without error
### Requirement: Listing is pull-only over issues
`/os-backlog:list` SHALL query the configured tracker's open issues (title, number, labels,
assignee) and present them grouped by state (next / waiting / review / other open). It
SHALL run only on explicit user request; no hook or skill SHALL inject issue lists into a
session unasked.
#### Scenario: User asks what's on the backlog
- **WHEN** the user explicitly asks what is on the backlog or what's next
- **THEN** open issues from the configured tracker are listed grouped by state labels, with
`next`-labeled issues shown first
### Requirement: Cross-project filing targets the other project's tracker
WHEN work belonging to a different project surfaces, the system SHALL resolve that
project's tracker via the global project index (`os-backlog projects`) and file a labeled
issue there using the Discoverer template, rather than editing the other project or filing
locally. Priority/autonomy labeling of the filed issue remains the receiving project's job.
#### Scenario: Discovered defect in another indexed project
- **WHEN** a session in project A finds a bug belonging to indexed project B
- **THEN** an issue is created on B's configured tracker with the Discoverer template, no
autonomy or priority labels are applied by A, and no local copy is kept
### Requirement: One tracker holds both state and specs
A project SHALL have exactly one configured tracker destination; durable specs
(tracer-bullet slices from /to-tickets, PRDs) and task-state items are issues on that same
tracker. The system SHALL NOT create pointer artifacts on a second tracking surface.
#### Scenario: /to-tickets publishes a slice chain
- **WHEN** /to-tickets publishes tracer-bullet slices for a project with a configured git
tracker
- **THEN** the slices become issues on that tracker and no pointer card or secondary
tracking artifact is created anywhere