the-custodian/.claude/rules/workplan-convention.md
codex ffad21146f
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 3s
Python Tests / pytest (push) Successful in 26s
Canonize work-record flavor and residual default-exclusion.
STATE-WP-0092-T01: flavor is a closed bucket on workplans and tasks;
residuals are a flavor, not a kind, and are omitted from default open
views until demand or risk promotes them. depends_on is the workplan
frontmatter edge.
2026-09-14 15:28:58 +02:00

2.9 KiB

Workplan Convention (ADR-001)

File location: workplans/CUST-WP-NNNN-<slug>.md ID prefix: CUST-WP-

Work items originate as files in this repo before being registered in the hub.

Canonical workplan frontmatter statuses are: proposed, ready, active, blocked, backlog, finished, archived. Use proposed for a newly drafted plan, ready after review against current repo state, and finished when implementation is complete. stalled and needs_review are derived health labels, not stored statuses.

Optional frontmatter (STATE-WP-0092):

flavor: planning | implementation | refactoring | extension | residual
depends_on:
  - STATE-WP-0092

Unset flavor is not residual. Do not implement flavor: residual unless demand or risk has promoted it to another flavor. depends_on lists blocker workplan ids; that is the field C-20 indexes.

Closed workplans may be moved to workplans/archived/ with a completion-date prefix: YYMMDD-CUST-WP-NNNN-<slug>.md. The frontmatter id remains unchanged; the prefix is only for quick visual reference.

Small opportunistic tasks discovered during another session use Ad Hoc Tasks: workplans/ADHOC-YYYY-MM-DD.md, workplan slug adhoc-YYYY-MM-DD, and task ids ADHOC-YYYY-MM-DD-T01, T02, etc. Use adhocs only for low-risk work completed directly. Promote anything requiring analysis, design, approval, dependencies, or multiple planned phases into a normal workplan.

Ecosystem todos from other agents arrive as [repo:the-custodian] hub tasks — visible at session start. Pick one up by creating the workplan file, committing, and running statehub fix-consistency — C-06 registers the workplan in the hub. Never register by hand with create_workplan (legacy MCP alias: create_workstream).

Task blocks use this shape:

id: CUST-WP-NNNN-T01
status: wait | todo | progress | done | cancel
priority: high | medium | low
state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit

Status progression is todoprogressdone; use wait for waiting or blocked work and cancel for stopped work.

Workplan frontmatter carries state_hub_workstream_id — a legacy field name kept for compatibility; it holds the hub workplan UUID and is written by fix-consistency. Do not edit or rename it.

Legacy terminology (compatibility footnote)

Workplan is the fleet term — see the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md. Workplan is legacy only: some API routes (/workstreams/), params (workstream_id), MCP aliases (create_workstream), and the frontmatter field above remain until STATE-WP-0069 retires them via legacy-meter. Treat those identifiers as workplan IDs. Prefer GET /workplans/ and workplan_id in new examples and scripts.