The .mm/ Data Model

Everything is Markdown or JSON in .mm/. No database. Any editor can read it.

Directory.mm/
- product/roadmap.md — phases and milestones
- Directoryspecs/2026-09-21-my-spec/ — one folder per spec
  - spec.md — goal, requirements, tasks
- Directoryissues/ — bugs, one file each
  - …
- Directorynotes/ — decisions and context
  - …
- Directorytasks/ — quick tasks not tied to a spec
  - …
- docs/, ideas/ — reference docs and captured ideas

Specs

A spec is the unit of work. spec.md holds everything:

---
title: My spec
status: backlog
parent: first-release        # the roadmap milestone it serves
depends_on: [2026-09-01-other-spec]
---

## Requirements
- R1: Users can export notes as PDF

## Tasks
#### Backlog
- [ ] T1: Add the export button (R1)

Requirements carry stable IDs (R1, R2…). Every task must cite one — or (R0) for scaffolding — or it’s rejected.
depends_on sets build order. parent ties the spec to a roadmap milestone.

Lifecycle

Status	Meaning
`brief`	An idea with an `intent:`, not yet shaped into requirements and tasks
`backlog`	Shaped — ready to start
`in-review`	All tasks ticked, not yet verified
`done`	Passed `/mm:verify-spec` (or a person overrode it)

Ticking every box doesn’t make a spec done — only verification does.

Everything else

Entity	Where	Notes
Issue	`issues/`	Severity + status; listed on `issues.md`
Note	`notes/`	Decisions and context, dated
Quick task	`tasks/`	One-off work outside a spec
Recorded line	a spec’s `## Recorded`	What agents learned, with provenance