# Plan — __APP_NAME__

> **The active plan — durable working memory across agent sessions.**
> A new session reads only this file (or calls the MCP `project_state` tool) to
> learn where work stopped and how to continue. Update it **as you go**, never
> only at the end — sessions get cut off without warning.
>
> Protocol: MCP `plan_template` · Architecture: [`big-picture.md`](big-picture.md) · Bugs & ideas: [`backlog.md`](backlog.md)

| Field | Value |
| --- | --- |
| Status | `none` <!-- none / in-progress / blocked / review / done --> |
| Objective | _one sentence — what "done" looks like_ |
| Branch | `main` |
| Board card | _(optional)_ `#<issue>` — see the `github-projects` skill |
| Written against | ai-builder `__AI_BUILDER_VERSION__` · korm-js `__KORM_VERSION__` · twreact-ui `__TWREACT_VERSION__` |
| Started | `__GENERATED_AT__` |

---

## Resume here

<!-- resume:start -->
**No active plan.** Before writing any code: call MCP `project_state`, then
`plan_template`, then fill in this file and agree the objective with the user.
Do not start a feature without a plan.
<!-- resume:end -->

<!--
  Keep the block above under 12 lines and REWRITE IT AT EVERY TASK TRANSITION
  (todo→doing, doing→done, doing→blocked). It must always answer, in this order:

    1. Doing now — the one task in flight, by id from the checklist below
    2. Next      — the single next concrete action, as a command or file+change
    3. Touched   — files changed since the last commit
    4. Verify    — the exact command that proves it works
    5. Watch out — the trap the next session would otherwise fall into

  This block is the whole point of the file. Everything else is context.
-->

---

## Tasks

<!-- status: todo | doing | blocked | done — exactly ONE task may be `doing` -->

| # | Task | Status | Verify with |
| --- | --- | --- | --- |
| T1 | _e.g. add an `invoices` module to `modules.config.js`_ | `todo` | `npm run seed:rbac` |

---

## Decisions

<!--
  Append-only. A decision recorded here is binding for later sessions.
  If one contradicts the SOP (MCP `build_rules`), the SOP wins — say so here.
  Reversing a decision means adding a superseding row, not editing the old one.
-->

| # | Decision | Why | Alternatives rejected |
| --- | --- | --- | --- |
| D1 | | | |

---

## Open questions / blocked

<!--
  Never guess an answer to fill a gap. Ask the user with clickable options
  (hard rule #8) and record the answer as a Decision above.
-->

| # | Question | Blocking | Asked? |
| --- | --- | --- | --- |
| Q1 | | | no |

---

## Verification log

<!-- Append one row per REAL gate (test run, boot, build). Never per file edit. -->

| When | What ran | Result |
| --- | --- | --- |

---

## Archive

When `Status` reaches `done`: move this file to
`tracking/plans/YYYY-MM-DD-<slug>.md`, recreate it from the skeleton with
`Status: none`, and in the **same change** fold anything durable into
[`big-picture.md`](big-picture.md) and anything unfixed into
[`backlog.md`](backlog.md). Keep this file under ~200 lines.