vibed/nbd/.beans/nbd-n2xz--investigate-user-configurable-type-and-status-stri.md

title	status	type	priority	created_at	updated_at
Investigate: user-configurable type and status strings with lifecycle phases	draft	task	low	2026-03-10T23:30:29Z	2026-03-10T23:30:29Z

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:

[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.