TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with frontmatter carrying id, status, created date and order, and the prose body copied across verbatim. TODO.md becomes a generated index (bun run todo:index). Dates: where an item's prose stated one it is used; otherwise its old section's; otherwise 2026-08-20, floored at the day before the split rather than invented. date_source records which. Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is the identity, frontmatter is the machine's half and the body is the owner's. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.2 KiB
1.2 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| plugin-system/emailaccounts-is-created-by-the-platform-for | `email_accounts/` is created by the PLATFORM for every account, and should be the plugin's job | plugin-system | open | 2026-08-18 | section | 2 |
email_accounts/ is created by the PLATFORM for every account, and should be the plugin's job.
USER_DIRS in data-path.ts pre-creates it at 0700 for every user, whether or not the email plugin
is installed — so a core install provisions a directory named for a plugin it does not have.
Ownership should invert: the plugin provisions its own storage, in all three moments —
- on plugin install, for accounts that already exist;
- on user provisioning, for accounts created afterwards;
- lazily, the first time a provisioned user opens the plugin, so a machine that missed either of the above still heals itself.
The third is the one that makes the other two non-critical, and it belongs in the email sidecar rather than in the platform's account handler.
This is entangled with the email_db leak below — core reads that directory today, so the plugin
cannot become its sole owner until that is resolved too. Do them together.