You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
48 lines
2.2 KiB
Markdown
48 lines
2.2 KiB
Markdown
+++
|
|
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. |