One artifact, four moves.

The Extreme-BDD loop

1. Write a scenario

   Add a @pending scenario to the appropriate bdd/features/<file>.feature. Required tags: one priority (@p1, @p2, or @p3), plus the actor line As a <Profile> where <Profile> exists in docs/USER_PROFILES.md.

2. Open the board

   Run python3 scripts/board_server.py and visit http://127.0.0.1:8844/. The board reads your working tree, so the new scenario shows up before you commit. Drag it across columns to set lifecycle state in bdd/BOARD_STATE.json.

3. Mirror to Radicle issues

   Run python3 scripts/sync_bdd_issues.py --apply. The script opens or edits a Radicle issue for each @pending scenario, applies bdd and p1/p2/p3 labels, and writes the scenario → issue mapping to bdd/ISSUE_MAP.json.

4. Implement & promote

   Implement the scenario, remove @pending, run the targeted BDD harness, and gossip the change via rad sync. The board reflects the change immediately; collaborators see it after their next sync.

The two surfaces, the one mirror

Why @pending is the unit of work

@pending means “this scenario describes desired behavior that is not yet implemented.” Removing the tag is the explicit, auditable promotion event from “backlog” to “done”. There is no half-state. The BDD runner skips @pending scenarios, so the suite is always green on what has shipped and silent on what has not.

Lifecycle projection (protocol 1.11+)

• Non-pending BDD alone does not prove a card is Done.
• Current passing PMCI/local test evidence can project a non-pending scenario to Done.
• Current failing evidence projects a scenario back to Testing even when board state persisted it in Done.
• Passing evidence for an older commit is stale and cannot close the current card.
• bdd/BOARD_STATE.json remains ordering, timestamp, and explicit-override metadata; the server returns a derived cards[].columnId without rewriting the file.