# 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 (P0–P3)
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