Move the to-do list from NOTES.md to a kandown board

Each note is a task in tasks/ with the owner's words under ## Context; the board rules are in .kandown/kandown_work.md and docs/kandown.md explains how kandown works here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 00:44:22 -04:00
parent aadcbc6efb
commit e0525c1cfb
28 changed files with 579 additions and 58 deletions
@@ -5,3 +5,6 @@ __pycache__/
 node_modules/
 .DS_Store
 .venv/
 # kandown web app: one 6.5 MB file that `kandown init` / `kandown update` regenerate
 .kandown/kandown.html
@@ -0,0 +1,9 @@
 daemon.json
 daemon.lock
 .undo/
 # Local extension state. Which extensions you enabled and which you trusted is a
 # per-machine decision, and a committed copy is ignored at load time anyway
 # (see docs/EXTENSIONS.md).
 extensions/enabled.json
 extensions/trust.json
@@ -0,0 +1,56 @@
 # Kandown
 File-based kanban for this project. Zero install, zero backend, plain markdown on disk.
 ## Layout
 ```
 .kandown/             # config, web UI, workflows, skills
 ├── kandown.html      # single-file web app — open this in your browser
 ├── kandown.json      # project preferences, columns, appearance
 ├── kandown_work.md   # optional project agent instructions
 ├── workflows/        # optional local workflow packages
 ├── skills/           # optional local Markdown skill packages
 └── README.md         # this file
 tasks/                # source of truth — one .md file per task
 ├── t1.md
 ├── t2.md
 └── archive/          # archived tasks live here
 ```
 ## Usage
 1. Open `.kandown/kandown.html` in Chrome, Edge, Brave or Opera (File System Access API required)
 2. Click **Select folder** and pick the **project root** (the parent of `.kandown/`), then grant read/write permission
 3. That's it
 The app remembers the last 10 projects you've opened — no need to re-select the folder each time.
 ## Settings
 Open Settings from the app header to tune this project. Board columns are stored in `.kandown/kandown.json` at `board.columns`. Each task chooses a column with its frontmatter `status`.
 ## Editing without the app
 Everything is plain markdown. Edit files directly in your IDE, Obsidian, or vim. Click **Reload** in the app (or press `R`) to see changes.
 The task editor includes a markdown-backed subtask checklist. Add steps with **Add subtask**, press **Enter** to insert another step, and expand a step to edit its description or report. Changes are saved back to the task file automatically.
 ## For AI agents
 Run `kandown work` for the current agent protocol and live board context. Each task file in `tasks/` is its own source of truth. Moving a task means editing its frontmatter `status`.
 ## Keyboard shortcuts
 | Key | Action |
 |---|---|
 | `⌘K` / `Ctrl+K` | Command palette |
 | `⌘1` / `Ctrl+1` | Board view |
 | `⌘2` / `Ctrl+2` | List view |
 | `N` | New task |
 | `R` | Reload |
 | `/` | Focus search |
 | `Esc` | Close drawer / palette |
 | `⌘S` | Save current task |
 | `⌘⌫` | Delete task (with confirmation) |
@@ -0,0 +1,74 @@
 {
  "version": 1,
  "preferred": "claude",
  "cascade": {
    "unassignedBehavior": "skip",
    "sameSessionChain": false
  },
  "agents": [
    {
      "id": "claude",
      "name": "Claude Code",
      "bin": "claude",
      "interactive": true,
      "description": "Anthropic Claude (interactive session)",
      "aliases": ["claude", "claudecode", "anthropic", "claudeai"]
    },
    {
      "id": "codex",
      "name": "OpenAI Codex",
      "bin": "codex",
      "interactive": true,
      "description": "OpenAI Codex CLI",
      "aliases": ["codex", "openaicodex"]
    },
    {
      "id": "gemini",
      "name": "Gemini CLI",
      "bin": "gemini",
      "interactive": true,
      "description": "Google Gemini CLI",
      "aliases": ["gemini", "geminicli", "googlegemini"]
    },
    {
      "id": "goose",
      "name": "Goose",
      "bin": "goose",
      "interactive": false,
      "description": "Block open-source AI agent",
      "aliases": ["goose", "blockgoose"]
    },
    {
      "id": "aider",
      "name": "Aider",
      "bin": "aider",
      "interactive": true,
      "description": "Git-aware AI pair programmer",
      "aliases": ["aider"]
    },
    {
      "id": "opencode",
      "name": "OpenCode",
      "bin": "opencode",
      "interactive": true,
      "description": "SST AI coding TUI",
      "aliases": ["opencode", "sstopencode"]
    },
    {
      "id": "cursor",
      "name": "Cursor",
      "bin": "cursor",
      "interactive": true,
      "description": "Cursor IDE (opens project; paste prompt)",
      "aliases": ["cursor"]
    },
    {
      "id": "pi",
      "name": "Pi",
      "bin": "pi",
      "interactive": true,
      "description": "Earendil Works pi coding agent",
      "aliases": ["pi", "piearendil", "picodingagent"]
    }
  ]
 }
@@ -0,0 +1,87 @@
 {
  "ui": {
    "language": "en",
    "theme": "auto",
    "skin": "kandown",
    "font": "inter"
  },
  "agent": {
    "suggestFollowUp": false,
    "maxSuggestions": 3,
    "workOutput": {
      "detailMode": "complete",
      "boardDigest": {
        "showColumnCounts": true,
        "showTasks": true,
        "showPriority": true,
        "showAssignee": true,
        "showBlockedBy": true,
        "showNextActionable": true
      }
    }
  },
  "workflow": {
    "active": "kandown-standard",
    "skills": [],
    "trackingCadence": "balanced"
  },
  "board": {
    "columns": [
      "Backlog",
      "Todo",
      "In Progress",
      "Review",
      "Done"
    ],
    "defaultPriority": "P3",
    "defaultOwnerType": "human",
    "stackDefaultState": "collapsed",
    "columnMeta": {
      "Backlog": {
        "role": "backlog",
        "instructions": "Capture unscheduled work here. Keep enough context to decide whether it belongs in this workflow."
      },
      "Todo": {
        "role": "ready",
        "instructions": "Only move work here when its required inputs, acceptance criteria, dependencies, and approvals are ready."
      },
      "In Progress": {
        "role": "active",
        "instructions": "Execute the current workflow phase, update the checklist as work happens, and record blockers immediately."
      },
      "Review": {
        "role": "review",
        "instructions": "Finished work waits here for the owner to check in the game. Only the owner moves it to Done; if it isn't fixed, the owner moves it back with feedback."
      },
      "Done": {
        "role": "terminal",
        "instructions": "Only accept work whose criteria and required review are satisfied. Preserve the completion report and evidence."
      }
    },
    "columnColors": {
      "done": "yellow"
    }
  },
  "tui": {
    "defaultView": "list",
    "showDetailPane": true,
    "listSort": "status"
  },
  "fields": {
    "priority": true,
    "assignee": false,
    "tags": true,
    "dueDate": false,
    "ownerType": false,
    "tools": false
  },
  "notifications": {
    "browser": false,
    "sound": false,
    "soundId": "soft",
    "statusChanges": true,
    "taskEdits": true,
    "subtaskCompletions": true,
    "editDebounceMs": 2000
  }
 }
@@ -0,0 +1,27 @@
 ## Deepgrain Foundry: working the board
 The board is the owner's to-do list. `docs/kandown.md` explains how kandown works here.
 - **Work on tasks only when the owner asks** ("do the next task", "do t8"). Don't pick up work
  on your own.
 - **Kinds of task.**
  - **Todo**: things to build or fix.
  - **Backlog, tagged `discussion`**: give options with trade-offs and a recommendation, in
    chat, and write nothing in code until the owner decides. Then record the decision.
  - **Backlog, tagged `idea`**: ideas for later. Leave them alone unless asked.
  - Questions get answers.
 - **Keep the owner's words.** Never rewrite or tidy the owner's text in `## Context`, and don't
  rename tasks the owner made. Add what you learn as `## Subtasks` with `report:` lines, or in
  the `report` field.
 - **When a task is finished**, move it to **Review** (that is "done, please check") and set the
  `report` field: what changed, and how to check it in the game. Never move a task to Done:
  the owner does that after checking it. If the owner moves it back with feedback, keep the
  feedback and work from it.
 - **Log your work.** Add an entry at the top of `docs/agent-log.md` with the date, the task id
  and title, what changed, the files touched, the tests run, and anything left open.
 - **Record decisions.** When the owner decides something about the design, add it to the
  decisions list in `docs/DESIGN.md` with the date and the reason they gave.
 - **Commit task files with the work** they describe. The owner may be editing tasks too: stage
  only the task files you changed.
 - **New tasks the owner asks for**: `kandown create "title" --to Todo` (add `-t discussion` or
  `-t idea` for Backlog), then put the owner's words under `## Context`.
@@ -11,7 +11,8 @@ The owner (the user) directs the work and is the real playtester. You build, tes
 ## Start of every session
-1. Read `NOTES.md`. It is the user's to-do inbox (see "Working from NOTES.md" below).
+1. Run `kandown work`. It prints the user's task board and the rules for working it (see
   "Working from the task board" below).
 2. Read `docs/PROJECT_MAP.md` before searching the code. It says where everything lives. Its
   index lists every top-level function and variable by file.
 3. Before changing how the game plays, read the relevant part of `docs/DESIGN.md`. Many choices
@@ -39,24 +40,21 @@ These rules matter more than speed.
  ask first. If the choice is small or easy to undo, take the sensible reading, say which one you
  took, and carry on.
-## Working from NOTES.md
+## Working from the task board
-`NOTES.md` belongs to the user. They add notes at any time and ask you to work on them ("do the
+The user's to-do list is a kandown board: one Markdown file per task in `tasks/`. **Read
-notes", "do the belt note"). Work on notes only when asked.
+`docs/kandown.md` before using it**: it says how the board works here, which commands are safe
 (never run `kandown <command> --help`: it runs the command), and what a task file looks like.
 The rules for working the board are in `.kandown/kandown_work.md`, and `kandown work` prints
 them. In short:
- **Kinds of note.**
+- Work on tasks only when asked. Todo tasks are built; Backlog tasks tagged `discussion` get
-  - Tasks ("add...", "make...", "fix...") are built.
+  options with trade-offs and a recommendation, and nothing is built until the user decides.
-  - Discussion notes ("let's think about...", "brainstorm...", "what can we do about...",
+- Never reword the user's words in a task's `## Context`. Add your notes as subtasks with
-    "let's talk about...") get options with trade-offs and a recommendation. Do not build them
+  `report:` lines, or in the `report` field.
-    until the user decides.
+- When a task is finished, move it to **Review** with a `report` saying what changed and how to
-  - Questions get answers.
+  check it in the game. Only the user moves tasks to Done.
- **Keep the user's wording.** Never rewrite or tidy a note. If you need to add context, add a
+- **Log your work.** Add an entry at the top of `docs/agent-log.md` with the date, the task,
  sub-bullet that starts with `(agent)`.
 - **When a task is finished**, move the note, word for word, into the "Done, please check"
  section at the bottom. Under it, add an `(agent)` sub-bullet saying what changed and how to
  check it in the game. Do not delete it: the user deletes it after checking. If the user says
  it is not fixed, move it back up and add their feedback as a sub-bullet.
 - **Log your work.** Add an entry at the top of `docs/agent-log.md` with the date, the note,
  what changed, the files touched, the tests run, and anything left open.
 - **Record decisions.** When the user decides something about the design, add it to the
  decisions list in `docs/DESIGN.md` with the date and the reason they gave.
@@ -178,3 +176,5 @@ screenshots and the pitfalls. The essentials:
 - Never commit secrets: tokens, passwords, or keys.
 - Work happens one agent at a time. If running several agents side by side is set up later,
  this section will say how they coordinate.
 This project uses Kandown. Before task work, run `kandown work` and follow its output. <!-- kandown:agent-ref -->
@@ -5,5 +5,6 @@
 - To look at a screenshot, open the PNG with the Read tool. Do this every time you change
  anything drawn, and before you call it done.
 - Use WebSearch and WebFetch for anything outside this repository, per the honesty rules above.
- Keep `docs/agent-log.md`, `NOTES.md` and `docs/PROJECT_MAP.md` current, as described above.
+- Keep `docs/agent-log.md`, the task files in `tasks/` and `docs/PROJECT_MAP.md` current, as
  described above.
  They are how the next session, yours or another agent's, picks up the work.
@@ -1,35 +0,0 @@
 # Notes
 The owner's to-do list for the game. Add notes anywhere in the lists below. Agents work on
 them when asked; AGENTS.md says how. Finished items go to "Done, please check" at the bottom
 and stay there until the owner has checked them in the game and deleted them.
 ## To do
 - stacking ingots is a little odd, they dont stack neatly. so putting them all in the same place means it will get full but have lots of air space. what can we do about this? WHat in real life might be the solution for storing ingots?
 - lets think about how best to design the factory products. basics are normal smelting ore, refining, etc. but the actual export products could be like real construction materials. materials that a real construction site might need.
 - the world still seems quite small. i dont know if thats because the bot moves so fast, the bot can mine too fast, or the grains should be smaller... i would like to make the worl seem huge to the player and give them loads of resources to mine for a long game. as is, you could mine all the resources from the map pretty quickly and end up having to start a new world and new game as a result. or maybe there is some other solution that i havent thought of yet. need to brainstorm this.
 - there is a sound effect that seems to happen randomly but constantly. sounds like a circuit breaker flipping on or off or something. maybe like a ruller snapping on a desk. what is it? its not new ive just been ignoring it. actually it may be a part of the background music. but it seems out of place. not sure if its the music or not. it folows the player wherever it goes. but maybe the sound effects are not local?
 - for buildings that need a material selection, lets make a new material selection menu
 - lets rework the vacuum/blower tool. the selecting, ticking, etc of the items for filtering and otherwise. its a little confusing and difficult to understand. lets ocme up with a simpler ui/ux, intuitive while still containing the same core functions like filtering what you pickup and drop and allowing pickup/drop all or filtered.
 - the silo art looks the same for both pixelated graphiocs and smooth.
 ## Future features and ideas
 - we can add more exotic/sci-fi ish ores and materials for more late game.
 - add more world generation options in new world creation and some presetsa Presets like different planet environments and all. Trees, water, dirt, all that could look different too.
 - lets talk about upgrades to the res drill. currently we have a bit mold. but that doesnt really make sense for the res drill. lets redesign the whole upgrades functionality anyway.
 ## Done, please check
 - instead of full description on to left for build menu, mouse hover reviels a new info popup. organize the popup look so its nice and easy to read the information.
  - (agent) Hover a tile in the build menu for a popup: icon and name, cost (red if you can't afford it), size, the full description, how to place it, and the build keys. The top-left card is hidden while the build tool is out; what it showed about the selected piece (material or direction · R, filter settings · F, Replace · Ctrl, ghosts waiting, messages like "Nothing built here to pick.") is now a row under the tiles. On a gamepad the popup shows for the selected tile. Copy, cut and paste still use the top-left card.
 - dont need the short description in the build menu if we have a hover info popup.
  - (agent) Removed: the line under the tiles is now the selected piece's status row instead.
 - i have noticed that belts with a big pile on top only move the grains on the top of the stack. the belt should move the whole stack. if this is an issue for performance, maybe a nice solution is to stall the belt when there is too much on it. then the player must build in a way to control the flow to that belt. update: i found that its because when there is a screw tube at the end of the belt, it stops the lower grains and only the ones at the top move. the screw tube shouldnt block them, it should suck them in.
  - (agent) Written after version 24, which already tried to fix this: carryColumn in src/sim/conveyors.js moves the whole stack, up to 96 grains deep. A one-off headless check of a tall heap moving together passed then (it was not kept as a suite test), so the real game must differ from that check somehow. Reproduce it in the game first (tools/shot.py, or play it), then add a suite test that fails, then fix.
  - (agent) Found it: when the front of the line backs up (your tube taking less than the belt brings, or a wall), the bottom grains were blocked but the ones above them still had air ahead, so the top slid forward over a stuck bottom forever. Now a column on a belt moves as a unit: if a grain can't move, nothing above it moves either, so a backed-up heap stands still (the belt slips under it) and is fed into the tube from its front, bottom layers included. A free-running belt still carries the whole heap. To check: blow a heap of two materials onto a belt that ends in an up tube and watch the bottom material go into the tube too. tools/scenes/belt-heap.js sets up the same thing for screenshots.
 - copper bars go into the furnace. also they shouldnt require the player to press F to collect. instead it should automatically eject ingots below and the player can have a belt there.
  - (agent) Bars now drop out of the bottom of an ingot mold by themselves as soon as they set, never up into the furnace. Leave one open block under the mold and put a belt below that: the bars land on it and ride off (a belt touching the mold's underside counts as blocked). If there is no room, the bars wait in the mold and a message says so once. The bit of metal too short for a bar stays in the trough for the next firing. F on the mold is now optional upkeep: it empties the trough, chips off slag and rakes the furnace grate. To check: run a furnace over a mold with a belt a block below.
@@ -61,7 +61,8 @@ The source is small JavaScript files with no dependencies or bundler:
 ## Documents
 - `AGENTS.md` / `CLAUDE.md`: how coding agents work on this project.
- `NOTES.md`: the to-do list.
+- `tasks/`: the to-do list, a [kandown](https://kandown.dev) board (`kandown` opens it; see
  `docs/kandown.md`).
 - `docs/PROJECT_MAP.md`: where everything is.
 - `docs/DESIGN.md`: what the game is meant to be, and the decisions made.
 - `docs/TESTING.md`: tests, screenshots and pitfalls.
@@ -18,7 +18,7 @@ decides something new, add it under "Decisions" with the date.
 - **Copy and paste of builds.** Pasting places ghosts that the bot builds from the bag.
 - **Tool upgrades are earned in a satisfying, not tedious way**, not bought with arbitrary
  credits. So far that means casting them: a drill bit in a Bit mold, a bigger bag in a Tank mold.
-  The owner wants the whole upgrade system redesigned (see NOTES.md).
+  The owner wants the whole upgrade system redesigned (task t14).
 - **A hovering bot that flies freely.** A limited bag that can be upgraded.
 - **An economy instead of a rocket or other final goal.**
  - Sell materials at the trade dock; refined goods and alloys pay more.
@@ -165,7 +165,8 @@ above, including:
  refiners until none is left. The owner's reason: it is less profitable than making glass, so
  players will do it only when they need more ore rather than more money.
 - The project moved from a claude.ai artifact to local development with coding agents. It is
-  built from small files, with `NOTES.md` as the owner's to-do inbox.
+  built from small files, with `NOTES.md` as the owner's to-do inbox (since 2026-10-24, a
  kandown board in `tasks/`).
 - **Replace is held G, not Ctrl.** The owner hit the browser's Ctrl+W (close tab) and Ctrl+D
  (bookmark) while replacing and flying with WASD, and the game ignored WASD while Ctrl was held.
@@ -200,9 +201,14 @@ above, including:
  list loads, renames and deletes them, and a new or imported world never overwrites another. An
  old single save becomes 'World 1'. The owner asked for multiple saves.
 **2026-10-24:**
 - **The to-do list is a kandown board.** `NOTES.md` became one task file per note in
  `tasks/` (Todo for tasks, Backlog for discussions and ideas, Review for "done, please check").
  The owner wanted a task tool built for AI agents.
 ## Ideas not built yet
 - **Concrete**, as a stronger wall material from rubble.
 - **Upgrade ideas for the drill**: an amplifier, a tuning fork, harmonics. Also a Grav pick
  upgrade tool and mining charges. See `docs/systems/dig-tools.md`.
- The owner's ideas for later are in the "Future features and ideas" section of `NOTES.md`.
+- The owner's ideas for later are tasks tagged `idea` in the Backlog of the task board.
@@ -9,7 +9,7 @@ top part by hand when the structure changes.
 ```
 AGENTS.md, CLAUDE.md  instructions for coding agents
-NOTES.md              the owner's to-do inbox
+tasks/, .kandown/     the owner's to-do list: a kandown board (docs/kandown.md)
 build.py              joins src/ into dist/index.html (one self-contained page)
 src/manifest.json     the build order: simulation files, then browser files
 src/shell.html        page markup (HUD, menus, dialogs); CSS and JS are put in at the markers
@@ -4,6 +4,32 @@ What agents have done, newest first. Add an entry for every piece of work: the d
 note or request it was for, what changed, the files touched, the tests run, and anything left
 open or not verified. Keep each entry short; the git history has the details.
 ## 2026-10-24: the to-do list moved from NOTES.md to a kandown board (Claude Code)
 Request: initialize kandown (https://kandown.dev, 0.52.0) for the project, move all the notes
 into it, and document how it works.
 - Practised first in a scratch folder: `init --no-open` starts no daemon and makes no sample tasks
  when `tasks/` exists; `create` prints only the id and names the file `<id>_<slug>.md`; a
  multi-line `report: |` block is read (checked in kandown's parser) and `doctor` accepts it;
  `list --json` doesn't include `report`; project instructions in `.kandown/kandown_work.md`
  appear in `kandown work` (~1,100 tokens).
 - A mistake on the way: `kandown init --help` ran `init` in the vault (it ignores `--help`) and
  started a daemon there. Stopped it, and removed the vault's earlier kandown test files as the
  owner asked. `docs/kandown.md` warns about it.
 - `kandown init --no-open` in the repo. `.kandown/kandown.json`: default columns, Review's
  instructions say only the owner moves work to Done, tags and priority shown. `.gitignore`:
  `.kandown/kandown.html` (6.5 MB, regenerated).
 - 14 notes became tasks t1-t14 (Todo: 6 tasks; Backlog: 5 tagged `discussion`, 3 tagged
  `idea`), each with the owner's note word for word under `## Context` (checked by script: 14 of
  14). `kandown doctor` is clean.
 - `.kandown/kandown_work.md` holds the board rules (from AGENTS.md's old NOTES section);
  `docs/kandown.md` explains how kandown works here. `AGENTS.md` (session start, a new "Working
  from the task board" section linking both), `CLAUDE.md`, `README.md`, `docs/PROJECT_MAP.md`,
  `docs/DESIGN.md` (decision). `NOTES.md` removed.
 - `kandown list` and `kandown doctor` checked inside Codex's sandbox: they work.
 - Open: the web board (`kandown`) wasn't opened here; the owner uses it.
 ## 2026-10-24: several worlds, with a Worlds list (Claude Code, with Codex)
 Note: "support multiple saves". The owner chose a world list.
@@ -0,0 +1,103 @@
 # kandown: the task board
 The owner's to-do list is a [kandown](https://kandown.dev) board: one Markdown file per task in
 `tasks/`, with settings in `.kandown/`. It replaced `NOTES.md` on 2026-10-24. This page records
 how it works here, as checked on kandown 0.52.0. The full upstream documentation is one file at
 https://kandown.dev/llms-full.txt (any docs page also works with `.md` added to its URL).
 ## Start of a session
 ```sh
 kandown work           # the rules, our project instructions and the board, as Markdown (~1,900 tokens
                       # with 14 tasks)
 kandown work t8        # the same, focused on one task
 ```
 Our project rules are in `.kandown/kandown_work.md`; `kandown work` includes them under
 "Project Instructions". `AGENTS.md` ends with the one-line pointer `kandown init` added; keep it.
 ## Columns
 | Column | Role | What goes here |
 |---|---|---|
 | Backlog | backlog | Discussion notes (tag `discussion`) and ideas for later (tag `idea`) |
 | Todo | ready | The owner's tasks |
 | In Progress | active | What an agent is working on now |
 | Review | review | Finished work waiting for the owner to check in the game ("done, please check") |
 | Done | terminal | Checked by the owner. Only the owner moves tasks here |
 ## Commands
 Task commands work offline and print data only on stdout (messages go to stderr), so they are
 safe to capture. Set `KANDOWN_NO_UPDATE=1` in scripts.
 ```sh
 kandown list                         # the board as a table; --json for data (no report field in it)
 kandown show t8                      # one task file as it is on disk
 ID=$(kandown create "Title" --to Todo -t discussion)   # prints only the new id, e.g. t15
 kandown move t8 "In Progress"        # quote column names with spaces; "archived" archives
 kandown doctor                       # checks kandown.json and every task's frontmatter
 kandown                              # the owner's board: web page plus terminal UI (starts a daemon)
 kandown daemon stop                  # stop that daemon
 ```
 - **`--help` is not safe.** `kandown init --help` ignored the flag and ran `init` in the current
  folder, which also started a daemon. Use `kandown help` or the docs, never `<command> --help`.
 - `kandown init` starts the web daemon unless given `--no-open`. With an existing empty `tasks/`
  it created no sample tasks.
 - `kandown create` names the file from the id and the title: `tasks/t8_fog_war_unexplored.md`.
  Find it with `tasks/<id>_*.md`; don't rename it.
 - `kandown create` has no body option: write the body into the file after creating it.
 - `depends_on` blocks a move to Done until the listed tasks are done.
 ## A task file
 ```markdown
 ---
 id: t8
 title: Fog of war for unexplored areas
 status: Review
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 tags: [discussion]
 report: |
  (agent) What changed, in a few lines.
  To check: how the owner sees it in the game.
 ---
 ## Context
 - The owner's note, word for word.
 ## Subtasks
 - [x] A step
  report: What actually happened.
 ```
 - Only `id`, `title` and `status` are required. Unknown keys are kept.
 - **`report`** is the completion summary the board shows prominently. A multi-line `report: |`
  block works (kandown's parser reads block scalars); `kandown doctor` accepts it.
 - `## Context` holds why the task exists: here, the owner's own words. `## Subtasks` is a
  checklist whose items can carry a `report:` line.
 - Editing files directly is supported; the board notices changes. Run `kandown doctor` after.
 ## Files
 | Path | Committed | What it is |
 |---|---|---|
 | `tasks/*.md`, `tasks/archive/` | yes | The tasks; the folder is the whole state, no index |
 | `.kandown/kandown.json` | yes | Columns, column instructions, workflow, which fields show |
 | `.kandown/kandown_work.md` | yes | Our project rules for agents |
 | `.kandown/agents.json`, `README.md`, `.gitignore` | yes | Written by `kandown init` |
 | `.kandown/kandown.html` | no (`.gitignore`) | The 6.5 MB web app; `kandown init` / `kandown update` rebuild it |
 | `.kandown/daemon.json` | no (`.kandown/.gitignore`) | The running daemon's port and access token |
 ## Codex and kandown
 `kandown list` and `kandown doctor` were checked inside Codex's `workspace-write` sandbox and
 work; the other task commands also only read and write files in the repo. Not checked under
 Codex: the web daemon (`kandown`
 with no command), which serves a page on a local port. Codex's `workspace-write` sandbox blocks
 network sockets (it is why headless Chrome crashed under Codex until runs passed
 `-c sandbox_workspace_write.network_access=true`).
@@ -0,0 +1,11 @@
 ---
 id: t10
 title: World name box for a new world
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 ---
 ## Context
 - add world name edit box to new world.
@@ -0,0 +1,12 @@
 ---
 id: t11
 title: Welcome and first milestone shown again on an older world
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 tags: [bug]
 ---
 ## Context
 - when making a new world then going back to tile and selecting a previously created world. the bottom right welcome and first milestone messages are still shown after loading the older world where you have already completed those.
@@ -0,0 +1,12 @@
 ---
 id: t12
 title: Exotic and sci-fi ores for late game
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 tags: [idea]
 ---
 ## Context
 - we can add more exotic/sci-fi ish ores and materials for more late game.
@@ -0,0 +1,12 @@
 ---
 id: t13
 title: World generation options and planet presets
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 tags: [idea]
 ---
 ## Context
 - add more world generation options in new world creation and some presetsa Presets like different planet environments and all. Trees, water, dirt, all that could look different too.
@@ -0,0 +1,12 @@
 ---
 id: t14
 title: Redesign drill upgrades
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 tags: [idea]
 ---
 ## Context
 - lets talk about upgrades to the res drill. currently we have a bit mold. but that doesnt really make sense for the res drill. lets redesign the whole upgrades functionality anyway.
@@ -0,0 +1,12 @@
 ---
 id: t1
 title: Ingot stacking and storage
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 tags: [discussion]
 ---
 ## Context
 - stacking ingots is a little odd, they dont stack neatly. so putting them all in the same place means it will get full but have lots of air space. what can we do about this? WHat in real life might be the solution for storing ingots?
@@ -0,0 +1,12 @@
 ---
 id: t2
 title: Export products as construction materials
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 tags: [discussion]
 ---
 ## Context
 - lets think about how best to design the factory products. basics are normal smelting ore, refining, etc. but the actual export products could be like real construction materials. materials that a real construction site might need.
@@ -0,0 +1,12 @@
 ---
 id: t3
 title: World feels small; resources run out
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 tags: [discussion]
 ---
 ## Context
 - the world still seems quite small. i dont know if thats because the bot moves so fast, the bot can mine too fast, or the grains should be smaller... i would like to make the worl seem huge to the player and give them loads of resources to mine for a long game. as is, you could mine all the resources from the map pretty quickly and end up having to start a new world and new game as a result. or maybe there is some other solution that i havent thought of yet. need to brainstorm this.
@@ -0,0 +1,12 @@
 ---
 id: t4
 title: Hopper blocks instead of fixed-size hoppers
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 tags: [discussion]
 ---
 ## Context
 - instead of buildings like the refiner which have a fixed size hopper, just make a block the same size as a wall tile that looks like grinding wheels where the user can place multiple side by side to create a wide hopper. the same thing should be done for the other buildings like that.
@@ -0,0 +1,11 @@
 ---
 id: t5
 title: Material selection menu
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 ---
 ## Context
 - for buildings that need a material selection, lets make a new material selection menu
@@ -0,0 +1,12 @@
 ---
 id: t6
 title: Rework the vacuum/blower tool
 status: Backlog
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 tags: [discussion]
 ---
 ## Context
 - lets rework the vacuum/blower tool. the selecting, ticking, etc of the items for filtering and otherwise. its a little confusing and difficult to understand. lets ocme up with a simpler ui/ux, intuitive while still containing the same core functions like filtering what you pickup and drop and allowing pickup/drop all or filtered.
@@ -0,0 +1,11 @@
 ---
 id: t7
 title: Option to turn off smooth pan following the mouse
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 ---
 ## Context
 - the smooth pan following the mouse should be an option in options. i personally dont like it much.
@@ -0,0 +1,11 @@
 ---
 id: t8
 title: Fog of war for unexplored areas
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:45Z
 ---
 ## Context
 - There should be a 'fog of war' for unexplored areas.
@@ -0,0 +1,11 @@
 ---
 id: t9
 title: Script to run the local server for testing
 status: Todo
 created: 2026-10-24
 updated: 2026-10-24T04:41:46Z
 ---
 ## Context
 - i need a script to run the local server for testing.