`oxmpl` - planning

#oxmpl #rust #software

This directory holds the management side of OxMPL planning: the backlog parking lot, the sprint narrative files, and the inbound issue queue. It lives in the personal vault (not the public repo). The technical docs stay in the repo: domain vocabulary in the root CONTEXT.md, decisions in docs/planning/adr/.

The repo's docs/BACKLOG.md is retired — this vault is its successor. Nothing here is bulk-imported into sprints; committed work comes only from what the product owner actually agrees to.

TaskNotes query note: tag filters need the contains operator — is matches nothing for tags (verified 2026-09-22). Status queries with is work fine.

Ticket system of record: TaskNotes

Epics, stories, and their statuses live in TaskNotes (Obsidian task notes in this vault), not in markdown tables. Everything OxMPL-related carries the oxmpl tag and belongs to the superproject project [[oxmpl - A Rust-based Motion Planning Library]] — both tasks and the vault pages here.

Concept	Where it lives
Superproject	The vault page `[[`oxmpl `- A Rust-based Motion Planning Library]]` — epics belong to it via `projects`
Epic (`E1`, `E2`, …)	A TaskNotes task in the superproject's project list: tags #oxmpl, #oxmpl/epic; goal + story list in `details` + a section in `oxmpl` - roadmap
Story (`S1.1`, …)	A TaskNotes task in its epic's project list (`projects: ["[[<epic note>]]"]`, not the superproject directly): tags #oxmpl, #oxmpl/epic, #oxmpl/story/size-S #oxmpl/story/size-M #oxmpl/story/size-L, and #oxmpl/sprint/NNN once committed. Title = ID + title; `details` = intent, acceptance criteria checklist, tasks checklist
Task	Checklist items inside the story's `details` — never separate task files
Sprint (`sprint-001`, …)	A tag on committed stories + one narrative page in `oxmpl` - sprints
Status	TaskNotes task status (`open	in-progress	done`) — no duplicated status tables anywhere

Rules carried over from the old conventions:

One story = one coherent, demoable slice.
No story enters a sprint without acceptance criteria in its TaskNotes details.
Mid-sprint scope changes are written down in the sprint page with what was swapped and why — see Mid-sprint scope changes below.
Superseded or dropped tickets get status cancelled (never done) with a one-line note at the top of details naming the successor ticket or backlog entry, and their sprint tag removed (first used for E2, 2026-10-08).
Provisional sprint pages (frontmatter sprint-status: provisional) may be scaffolded ahead to keep a release visible. They are plans, not commitments: stories get the sprint tag only at that sprint's planning. Session bootstrap ignores provisional pages when finding the current sprint unless their dates include today and the previous sprint's retro is written.
Sprint commitment is sized to side-project availability. At planning the owner states realistic availability for the sprint; the PM fits the commitment to it (sprint-001 retro).

Mid-sprint scope changes

Adopted at the sprint-001 retro. When work uncovers new scope, the PM classifies it in the same turn and recommends one action; the owner decides.

Finding	Recommended action
Inside the story's acceptance criteria / same code, small	Fold in — note it in the story details + progress log
A separate demoable slice, size S, sprint has room	New story in this sprint — log it; swap out equal size if capacity is tight
Size M+, or threatens the sprint goal or end date	Replan sitting — PM proposes restructured tickets (split / swap / defer); owner confirms before any change
Not needed for the sprint goal	Backlog, with reason and revisit condition

Also trigger a replan sitting when things folded into one story add up to roughly one size-S story.

Files here

oxmpl - backlog — parking lot for deliberately deferred work, with reasons and revisit conditions
oxmpl - roadmap — epic overview: goals, story lists, links into TaskNotes; narrative, statuses live in TaskNotes
oxmpl - sprints — one file per sprint: goal, commitment, progress log, retro
issues/ — inbound issue queue for the matt-pocock skills; conventions in the repo's docs/agents/issue-tracker.md

Workflow

Inbound — issues/specs land in issues/ (triaged by the triage skill per the repo's docs/agents/).
Release/scope planning — the senior-engineer persona (/persona senior-engineer) agrees technical scope and sequencing.
Structure into sprints — the project-manager persona (/persona project-manager) creates epics/stories in TaskNotes and proposes a sprint commitment; on confirmation, writes the sprint page and tags the stories.
Work — the owner executes; progress reports go to the PM persona, which updates TaskNotes statuses and appends to the sprint progress log.
Review — at sprint end the PM walks the committed tickets (TaskNotes query by sprint tag) and writes the retro in the sprint page.

Every PM session opens with a board reconstruction — current sprint derived from the sprint pages (dates, or lowest number without a retro), statuses from TaskNotes queries — before any question is asked. The persona prompt holds only the procedure, never the state; TaskNotes is the status of record and wins over any narrative.