+++
title = "Investigate: user-configurable type and status strings with lifecycle phases"
priority = 3
status = "backlog"
ticket_type = "task"
dependencies = []
+++
## Problem

`type` and `status` are currently hard-coded Rust enums. Users cannot add custom values (e.g., `status = "review"` or `type = "spike"`) without modifying the codebase. But certain status values (`done`, `archived`, `closed`) have special semantics (excluded from `list`/`ready`/`next`; counted as resolved for deps). Making these extensible requires a design that lets users declare which values are "pre-work", "in-work", and "post-work".

## Design questions

### Lifecycle phases (proposed)

Instead of hard-coding which statuses are excluded, introduce a three-phase model:

| Phase | Examples | Behaviour |
|---|---|---|
| `pre` | `triage`, `backlog` | Excluded from `list`, `ready`, `next`. Not resolved. |
| `during` | `todo`, `in_progress`, `review` | Included in `list`, `ready`, `next`. Not resolved. |
| `post` | `done`, `archived`, `closed` | Excluded from `list`, `ready`, `next`. Counted as resolved. |

Users would configure phases in `.nbd/config.toml`:

```toml
[nbd.status]
pre    = ["triage", "backlog"]
during = ["todo", "in_progress", "review", "qa"]
post   = ["done", "archived", "closed"]
default = "triage"
```

### Type extensibility

Allow `type` to be any string. Keep built-in types (`project`, `feature`, `task`, `bug`) but do not reject unknown values; validate only that the string is non-empty.

## Questions to answer

1. Is TOML config the right place for lifecycle phase definitions, or should there be a separate schema file?
2. How does serialisation/deserialisation change? `Status` can no longer be an enum if it is user-defined.
3. What is the migration path for existing tickets serialised with the current enum values?
4. Are there cases where a single status should belong to multiple phases (e.g., `review` might be both `during` and gating some post-processing)?
5. What is the minimum viable change? Could we start by making status a `String` internally while keeping the built-in values and their semantics, then layer config-driven phases on top?

## Expected output

Create one or more follow-up tickets with a concrete implementation plan and migration strategy.