pdd-map
Map reads your repository and writes a Product Model of what the product already does.
Use it once, when you adopt pdd-kit in a repository that has code, and
again only for an area the model doesn't cover yet or that you no longer trust.
It is not a daily step: to check that the model is still current, use
pdd-verify.
/pdd-map
/pdd-map billing
The first maps the whole repository; the second maps one area and what it needs.
What you get
- Numbered questions, each with a recommendation. The code says what happens, not what the product means, so map asks what inspection can't settle: which surfaces are supported Interfaces, whether a family of things is one Entity or several, where a Scenario ends and an edge case begins, and the product's own name for each thing. It asks in rounds and waits for your answers.
- The proposed change. Every resource it would add, change or remove, what it left unmapped, and what it couldn't establish, before anything is written.
- Files written after you approve, only inside
product-model/. A first run creates the whole folder, including the model's README (product-model/README.md). - Lint, fixed until clean.
- A report: what is mapped, what is not, the limitations, and the lint result.
How it reads the code
Map starts at the entry points (routes, commands, handlers) and follows each one through to what it stores and what the person sees. Tests and docs are leads; it confirms every claim in the implementation. Then it sweeps four times:
| Sweep | Looks for | Becomes |
|---|---|---|
| Verbs | What people and systems can do | Capabilities, each with Scenarios for its cases |
| Nouns | Each thing the product keeps | Its States, the Steps that move it between them, and the Screens that show it |
| Permissions | Every authorization check: a role, an owner, a threshold | A grant on a Business Rule; an operation refused to everyone is permits: [] |
| Hand-offs | Places where the product carries a person from one Capability into the next | A Journey |
A state nothing moves a thing into, or a thing nothing changes, becomes a question for you, never a guess.
Flags, settings, plans and A/B tests are classified by What selects: a Variation only when they switch between complete supported forms; otherwise a condition, a separate Scenario, or a condition on who may.
Map attaches what it actually read as References (the code
it traced, and any PRD or spec that states the behavior) as a record of where a
claim came from, not proof. In a repository using a spec-driven tool, it records
those folders in config.yaml.
Related
pdd-ideate: decide what should change next.pdd-verify: check the model and code still agree.- Start from your repository