keel-planlisted

# /keel-plan — build and maintain the phase map When: at bootstrap right after the tailoring (rules.md §0), whenever the user asks for a plan or a re-plan, or when scope changes enough that the DAG no longer matches reality. `PLAN.md` is the strategic view; `TASKS.md` stays the tactical board — never duplicate checkboxes across them. 1. **Propose.** From the user's goal derive phases + sub-phases, each with: id (`p1`, `p1_2` — lowercase `[a-z0-9_]`), a **gate** (verifiable done-when, same spirit as TASKS.md), `after` dependencies (siblings with no mutual `after` may run in parallel), and — on a multi-user project — an `owner` (the person's `git config user.name`; blank = anyone). Ask who owns what when parallel branches are assigned to different people; only the owner advances an owned phase (`/keel-autopilot` stops at a foreign one). Single-user projects leave `owner` blank. **Multi-user governance:** when the project declares itself multi-user, ASK who the PROJECT owner (founder) is — never assume it's whoever is bootstrapping — and write their `git config user.name` as the single line of **`.claude/project-owner`**. That file arms the `owner-guard` hook (governance files — PLAN/rules/CLAUDE/architecture/ADR/.claude — become owner-only; non-owner `git push` to main blocked) and the session role line. Assignments (`@name` tags in TASKS, the `owner` column here) are then the OWNER's call; sprint deadlines ride the TASKS item as `due: YYYY-MM