{title}

` that round-trips\n   multiline markdown through the real Hono form routes; bodies render as\n   escaped JSX text with `whitespace-pre-wrap` (no HTML rendering). Control\n   visibility fixed via a maintainer-only `canModerateComments` prop on\n   `IssueDetailPage`: maintainers and the comment author see edit/delete\n   controls; a non-author issue creator does not. Server-side checks remain the\n   enforcement layer and the UI mirrors them exactly.\n3. **API/docs parity** — strict all-or-nothing validation for collection fields\n   (`label_ids`/`add`/`remove`/`assignees`: absent = empty operation,\n   present-but-malformed = 400); 400 for an invalid `status` filter; 404\n   existence guards on every mutation route; a small typed `HttpError`\n   (400/404/409) in `db.ts` replacing the old map-everything-to-409 handler;\n   `docs/issue-tracker-valtown.md` rewritten with complete response shapes, the\n   event-data grammar, the `{\"error\": \"...\"}` convention, a status-code table,\n   and exact per-route responses matching `api.ts` route-by-route.\n4. **Check policy** — Biome (tab-indented) is the canonical formatter, not\n   `deno fmt`; `.vt/` and `.claude/` excluded via `biome.json` `files.includes`;\n   canonical commands are the `deno.json` tasks `fmt` / `lint` / `typecheck` /\n   `test` / `check` (aggregate), documented in `README.md` and all passing.\n5. **Recertification** — independent audit rebuilt the requirement matrix for\n   all five tickets against the PRD, re-ran all checks (21/21 tests), compared\n   every API route against the convention doc (18 route/status combinations),\n   and repeated the stale-schema scan: no live use of priority, `in_progress`,\n   `description`, JSON-label storage, single-assignee storage, `*_by` columns,\n   or a stored comment `author` column (`Comment.author` is derived from\n   `comment.created` events via JOIN, per ADR 0003/0004). The only old- schema\n   references are the migration reader in `db.ts` and legacy-fixture SQL in\n   `db_test.ts`, by design.\n\n## Caveats\n\n- Nothing was deployed. The adapter-contract proof is static (reading the\n  resolved dependency's source), not a live round-trip against Val Town's scoped\n  SQLite. Live proof requires deploying and exercising one transactional write.\n- Known cosmetic quirk, out of scope: the HTML app's `onError` in `app.tsx`\n  renders every thrown error as a banner with HTTP status 409, including 404\n  `HttpError`s from the store. HTML routes check existence before mutating, so\n  it rarely triggers.\n",[],[304,497,498,500],"85c72af1-cc92-4979-a7a5-bac2e38e7689","PRD.md","eebd1596-7bf2-11f1-ab8e-1607ee4eb77e",174,["D",1783653142818],"# Spec: Richer data model for val-issue-tracker\n\nStatus: ready-for-agent\n\n> Synthesised from a grilling + domain-modeling session. Vocabulary follows\n> `CONTEXT.md`; decisions are governed by ADRs 0001–0004. This is a breaking\n> schema change to the tracker's own data model, plus the migration to get the\n> ~3 existing deployments onto it.\n\n## Problem Statement\n\nThe tracker's current data model carries fields the maintainer doesn't use and\ncan't represent the relationships they actually want. Priority is dead weight.\nStatus has a middle `in_progress` state that isn't wanted, yet there's no way to\nsay _why_ something was closed (done vs. abandoned). Labels are a JSON-array\nstring matched with `LIKE`, so they can't have colour, be renamed in one place,\nor be queried cleanly. There's no way to express that one issue blocks another.\nThere is no history: once a label is removed or an assignee dropped, the fact\nthat it was ever there is gone, and there's no record of who changed what. The\nmaintainer wants a GitHub-flavoured model that captures these relationships and\na full audit trail.\n\n## Solution\n\nReshape the tracker's schema to mirror GitHub's issue model where it earns its\nkeep, and add first-class structure for the things the maintainer actually uses:\n\n- Drop priority entirely and collapse status to `open` / `closed`, with a\n  nullable `state_reason` (`completed` / `not_planned` / `duplicate` /\n  `reopened`) carrying the nuance — so \"closed as done\" and \"closed as not\n  planned\" are distinguishable.\n- Promote labels from a JSON string to curated **Label** entities (name +\n  colour), applied to issues through a join, seeded with a small default set on\n  first install.\n- Make assignees a _set_ of Val Town users via a join, instead of a single\n  string.\n- Add directed **blocking relationships** between issues, kept as a strict DAG,\n  with \"blocked\" derived (an issue is blocked while any blocker is still open).\n- Record every change in a single append-only **events** log — the source of\n  truth for provenance (\"who did what, when\") and full state history, from which\n  auditability is derived. Live tables hold only current state.\n- Treat issue and comment bodies as markdown (a rendering contract; no storage\n  change).\n\nIdentity throughout is the Val Town handle — there is no local users table.\n\n## User Stories\n\n1. As a maintainer, I want priority removed from issues, so that the model\n   reflects that I never triage by priority.\n2. As a maintainer, I want status to be exactly `open` or `closed`, so that\n   there is no unwanted intermediate state to maintain.\n3. As a maintainer, I want to close an issue as `completed`, so that I can\n   record that the work was actually done.\n4. As a maintainer, I want to close an issue as `not_planned`, so that I can\n   record that I abandoned it rather than finished it.\n5. As a maintainer, I want to close an issue as `duplicate`, so that I can\n   record that it was already tracked elsewhere.\n6. As a maintainer, I want reopening an issue to mark its reason as `reopened`,\n   so that a reopened issue is distinguishable from one that was never closed.\n7. As a maintainer, I want the system to refuse an incoherent status/reason pair\n   (e.g. open + completed), so that the data can never represent an impossible\n   state.\n8. As a maintainer, I want `state_reason` to be set automatically by the\n   close/reopen/create actions, so that I can't forget to keep it consistent\n   with status.\n9. As a maintainer, I want labels to be real entities with names and colours, so\n   that I can see and manage a consistent taxonomy.\n10. As a maintainer, I want to apply an existing label to an issue by picking\n    it, so that typos can't spawn phantom labels.\n11. As a maintainer, I want to remove a label from an issue, so that the tag set\n    stays accurate.\n12. As a maintainer, I want a fresh install to come with a default set of labels\n    (`bug`, `enhancement`, `documentation`, `question`, `duplicate`), so that\n    the tracker is usable immediately.\n13. As a maintainer, I want labels I delete to stay deleted across restarts, so\n    that the default set doesn't resurrect itself on the next request.\n14. As a maintainer, I want to delete a label that is currently applied to\n    issues, so that retiring a tag just removes it everywhere.\n15. As a maintainer, I want to rename or recolour a label in one place, so that\n    every issue carrying it updates at once.\n16. As a maintainer, I want an issue to have zero or more assignees, so that\n    more than one Val Town user can own it.\n17. As a maintainer, I want to add and remove assignees on an issue, so that\n    ownership can change over time.\n18. As a maintainer, I want to ask \"what is assigned to me?\", so that I can find\n    my work without scanning every issue.\n19. As a maintainer, I want to declare that one issue blocks another, so that I\n    can express dependencies.\n20. As a maintainer, I want to view an issue's blockers and the issues it\n    blocks, so that I understand its dependency context from either direction.\n21. As a maintainer, I want an issue to show as blocked while any of its\n    blockers is still open, so that blocked-ness is always accurate without my\n    maintaining a flag.\n22. As a maintainer, I want closing a blocker to automatically unblock its\n    dependents, so that the state stays correct for free.\n23. As a maintainer, I want to still be able to close a blocked issue, so that\n    being blocked is informational and never traps me.\n24. As a maintainer, I want the system to reject an issue blocking itself, so\n    that nonsensical edges can't exist.\n25. As a maintainer, I want the system to reject any edge that would create a\n    cycle (direct or longer), so that the dependency graph stays a coherent DAG.\n26. As a maintainer, I want to remove a blocking relationship, so that I can\n    correct a dependency I no longer want.\n27. As a maintainer, I want issue and comment bodies treated as markdown, so\n    that formatting is preserved for later rendering.\n28. As a maintainer, I want to edit an issue's title and body, so that I can\n    correct or refine it after creation.\n29. As a maintainer, I want to edit a comment, so that I can fix mistakes in my\n    notes.\n30. As a maintainer, I want to delete a comment, so that I can remove notes that\n    no longer belong.\n31. As an auditor, I want every create, update, and delete recorded as an event\n    with the actor and timestamp, so that I can reconstruct who changed what and\n    when.\n32. As an auditor, I want each field change recorded with its before and after\n    value, so that I can see the full history of an issue's state.\n33. As an auditor, I want label applications, assignments, and block edges\n    recorded as events, so that removals are visible even though the\n    current-state row is gone.\n34. As an auditor, I want a deleted entity's final state captured in its\n    deletion event, so that a hard delete still leaves a complete record of what\n    was lost.\n35. As an auditor, I want a created entity's initial state captured in its\n    creation event, so that history can be replayed forward from a\n    self-contained starting point.\n36. As an auditor, I want to reconstruct an entity's state at any past point, so\n    that I can answer \"what did this look like last week?\".\n37. As a host-val developer, I want the tracker to keep using prefixed table\n    names in my scoped database, so that it never collides with my own tables.\n38. As a host-val developer, I want a friendly sequential issue number, so that\n    I can refer to issues as `#N` without an extra opaque id.\n39. As an existing deployment owner, I want my current issues migrated onto the\n    new schema, so that I lose no data when upgrading.\n40. As an existing deployment owner, I want any `in_progress` issue moved to\n    `open` during migration, so that no issue is stranded in a removed state.\n41. As an existing deployment owner, I want my current JSON labels lifted into\n    the new label and join tables, so that existing tags survive the change.\n42. As an existing deployment owner, I want existing rows to get a synthetic\n    creation event on migration, so that no entity is left with no provenance.\n43. As an agent, I want the JSON API to reflect the new schema (no priority, two\n    statuses, `state_reason`, label/assignee/block operations), so that\n    non-interactive callers drive the new model correctly.\n44. As an agent, I want the API convention doc updated to the new schema, so\n    that I'm not working from the outdated contract.\n45. As a maintainer, I want any change to an issue's labels, assignees, blocks,\n    or comments to bump the issue's `updated_at`, so that \"last activity\"\n    sorting reflects all activity, not just edits to the issue's own fields.\n\n## Implementation Decisions\n\n**Modules.** The single seam of change is the data-access layer (`db.ts`):\ntypes, schema creation/migration, and all query functions. The Hono JSON API and\nthe HTML UI are consumers that will be updated to match — both currently\nduplicate schema knowledge (status/priority constants, label parse/serialize)\nthat must be reconciled to the new model. The library's public entry point and\ntable-prefixing convention are unchanged.\n\n**Removed fields.** Priority is removed entirely (column, type, filters,\ncreate/update paths) — faithful to GitHub, which has no first-class priority.\nThe `in_progress` status is removed.\n\n**Status + state_reason.** `status` is `open` | `closed`. A nullable\n`state_reason` holds `completed` / `not_planned` / `duplicate` (with `closed`)\nor `reopened` (with `open`), or `null`. It is auto-managed: create → `null`;\nclose → chosen reason (`completed` default); reopen → `reopened`. A `CHECK`\nconstraint enforces the valid pairings so an incoherent row is impossible. (ADR\ncontext: mirrors GitHub; \"not planned\" is not a third state.)\n\n**Body.** The issue's `description` is renamed to `body` so Issue and Comment\nshare one term, matching GitHub. Bodies remain `TEXT`; markdown is a rendering\ncontract, not a storage change.\n\n**Labels (ADR 0001).** A **Label** is a curated entity: `id`, unique `name`,\n`color`. Applied via an issue↔label join (bare tuple), cascade-deleting both\nsides; deleting an in-use label is allowed and simply removes the join rows. A\ndefault set (`bug`, `enhancement`, `documentation`, `question`, `duplicate`) is\nseeded **exactly once, at the moment the labels table is first created**, never\nre-seeded — so user deletions survive. Labels are editable (rename/recolour in\none place).\n\n**Assignees.** Multi-valued set of Val Town users, stored as a bare\nissue↔user-handle join tuple. No local users table; identity is the handle.\nSupports \"assigned to me\" queries in both directions.\n\n**Blocking (ADR 0002).** A directed edge `blocker → blocked`, stored once with a\nunique pair constraint and cascade on issue delete. \"Blocks\" and \"blocked by\"\nare the same edge read from opposite ends. The graph is a **strict DAG**: on\ninsert, reject if the target can already reach the source (reachability check\nvia recursive query), which covers self-edges, direct reciprocals, and longer\ncycles alike — deliberately stricter than GitHub. \"Blocked\" is **derived, never\nstored**: an issue is blocked iff any blocker is still `open`; blocked-ness is\ninformational and does not prevent closing.\n\n**Audit + provenance (ADR 0003 as amended, ADR 0004).** Entities (Issue,\nComment, Label) keep only `created_at` + `updated_at` columns (for hot-path\nlisting / \"last activity\" sorting). There are **no `*_by` columns anywhere**;\nactor/provenance lives solely in the events log. Link rows carry no audit\ncolumns. Every entity is editable, including comments (the old comment `author`\ncolumn is gone; the author is derived from the `comment.created` event).\n\n**Events log (ADR 0004).** One append-only, polymorphic table with roughly this\nshape:\n\n| column            | meaning                                                                                 |\n| ----------------- | --------------------------------------------------------------------------------------- |\n| `id`              | ordering key                                                                            |\n| `event_type`      | `<entity>.<verb>`, entity ∈ {issue, comment, label}, verb ∈ {created, updated, deleted} |\n| `entity_id`       | id of the affected entity                                                               |\n| `actor`           | Val Town handle that performed the change                                               |\n| `data`            | JSON payload (shape depends on verb)                                                    |\n| `event_timestamp` | when it happened                                                                        |\n\nGrammar — _boundary events snapshot, updates carry deltas_:\n\n- `*.created` → full initial-state snapshot.\n- `*.deleted` → full final-state snapshot (entities are hard-deleted; the event\n  is the tombstone — soft-delete was considered and rejected).\n- `*.updated` → `{ update_target, from, to }`.\n- Associations (label apply/remove, assign/unassign, block add/remove) are\n  modelled as `issue.updated` events with `update_target` ∈ {`label`,\n  `assignee`, `blocks`, `blocked_by`} and `from`/`to` using **`null ↔ value`**\n  (null→X = added, X→null = removed). No separate verb or link entity type.\n- One event per changed field: closing emits two events (`status` and\n  `state_reason`) sharing one actor and timestamp; a \"closed as not planned\"\n  timeline line is a read-time grouping by (actor, timestamp).\n- A block edge writes **one** event, on the acting issue; the reverse \"blocked\n  by\" view is derived by querying events whose `to` references the issue.\n\n**Identity / numbering.** Issues keep the autoincrement `id` as their friendly\n`#N` — no separate opaque id, since a single scoped database per host makes `id`\na clean per-tracker counter and there are no PRs competing for the sequence.\n\n**Touch rule.** Mutating an issue's labels, assignees, block edges, or comments\nbumps that issue's `updated_at` (in addition to emitting an event).\n\n**Migration.** This is a breaking change against ~3 existing deployments (this\nval + two test vals). Migration must: rename `description` → `body`; drop\n`priority`; remap any `in_progress` issue to `open`; lift each existing JSON\n`labels` array into the new label entities (creating labels as needed) and\nissue↔label join rows; move any existing single `assignee` into the assignee\njoin; and backfill a synthetic `*.created` event (and any needed state) for\nexisting rows so nothing is left provenance-less. Migration runs within the\nexisting idempotent schema-init path and must be safe to run repeatedly.\n\n**API + docs.** The JSON API is updated to the new model: no `priority`, two\nstatuses, `state_reason` on close/reopen, and label / assignee / block\noperations. The convention doc `docs/issue-tracker-valtown.md` is rewritten to\nthe new schema (it currently documents the old one) as part of this work.\n\n## Testing Decisions\n\n**Seam.** A single new seam: the exported functions of the data-access layer\n(`db.ts`). There is no existing test suite, so this is the first — no prior art\nto mirror; establish the pattern here. Tests run against a scoped SQLite\ndatabase and exercise the exported functions directly, with no HTTP or UI in the\nloop.\n\n**What makes a good test here.** Assert _external behaviour_ of the data layer —\nthe observable outcomes of calling its functions — not internal implementation\n(not specific SQL, indexes, or private helpers). A good test states a domain\nrule and checks it holds.\n\n**Behaviours to cover:**\n\n- Status/reason: create leaves reason null; each close reason sets status closed\n  with the right reason; reopen sets `reopened`; the `CHECK` constraint rejects\n  an incoherent pair.\n- Labels: default set seeded on first creation; deletions survive a re-init\n  (seed-once); applying/removing labels; deleting an in-use label removes its\n  join rows.\n- Assignees: add/remove; \"assigned to me\" returns the right issues.\n- Blocking: self-edge rejected; direct reciprocal rejected; longer cycle\n  rejected; a valid edge accepted; \"blocked\" derived from open blockers; closing\n  a blocker unblocks dependents; a blocked issue can still be closed.\n- Events: create/update/delete emit events with correct type, actor, and payload\n  grammar (created/deleted snapshots, update deltas, association `null ↔ value`,\n  one-event-per- field on close, single event on block add); deleted-entity\n  snapshot is complete.\n- Touch: association and comment changes bump the parent issue's `updated_at`.\n- Migration: from a seeded old-schema database, `in_progress` → `open`, JSON\n  labels lifted into tables, `description` readable as `body`, and existing rows\n  gain creation events; running migration twice is a no-op.\n\n## Out of Scope\n\n- Rendering markdown to HTML, and rendering the events log as a UI activity\n  timeline (data supports both; presentation is deferred — see\n  `docs/backlog.md`).\n- Turning user handles into clickable profile links (backlog).\n- Reintroducing priority or an `in_progress` state in any form.\n- A local users table or any identity beyond the Val Town handle.\n- Soft delete / restore (explicitly rejected in favour of hard delete +\n  tombstone event).\n- Retention or pruning of the append-only events log.\n- Topological \"what should I work on next\" ordering (the strict DAG keeps the\n  door open for it later, but it is not built here).\n- Black-box tests at the HTTP/API layer (single `db.ts` seam only, by decision).\n\n## Further Notes\n\n- Governing decisions live in ADRs 0001–0004 and the glossary in `CONTEXT.md`;\n  use that vocabulary in issue titles, tests, and code.\n- Deferred wants are tracked in `docs/backlog.md`.\n- The stale `docs/issue-tracker-valtown.md` is intentionally left untouched\n  until this work rewrites it, so nothing points agents at the new schema before\n  it exists.\n",[],[304,497,498,508],"09a12ef3-b79f-45bc-b0d7-6c7e712da8e8","ee584d8c-7bf2-11f1-8d5b-1607ee4eb77e",138,["D",1783641873720],[335,336,337],[304,497,498],"bd25824a-46f8-4203-963a-29d26806be4f","07-labels-page.md","b3803c74-7fb7-11f1-bc45-1607ee4eb77e","b3318a70-7fb7-11f1-bc45-1607ee4eb77e",244,["D",1784056239217],"# 07 — Labels page\n\n**What to build:** The labels page becomes GitHub-like. A search input filters\nlabels by name server-side via a query parameter. Each label renders as a row\nshowing its chip, hex color, and open-issue count (computed with a join at\nrender time — no schema change). A maintainer-only New label button expands an\ninline create row with a live-preview chip, a name field, and a color field with\na swatch, posting to the existing create-label route. Each row has an overflow\ndisclosure containing edit-in-place and delete; the visible open-issue count\nmakes the delete cascade (the label vanishing from that many issues) a visible\nconsequence. Label deletion behavior is unchanged.\n\n**Blocked by:** 01\n\n**Status:** ready-for-agent\n\n- [ ] A search input filters the label list by name (server-side)\n- [ ] Each row shows the label chip, its hex color, and its open-issue count\n- [ ] A maintainer sees New label, which expands an inline create row with a\n      live-preview chip, name, and color-with-swatch, and creating a label works\n      via the existing route\n- [ ] Edit-in-place and delete live behind each row's overflow disclosure\n- [ ] A non-maintainer sees the list and counts but no create/edit/delete\n      controls\n- [ ] No route, store, API, or schema change\n",[],[304,497,530,497,522],"github-style-ui","22f54fea-60d3-4192-a45c-7ddf6e7882b5","04-issue-detail-reading-shell.md","b38c5cca-7fb7-11f1-9940-1607ee4eb77e",245,["D",1784056239307],"# 04 — Issue detail: reading shell + lifecycle composer footer\n\n**What to build:** The issue detail page becomes a two-column reading surface.\nThe header shows the title with its number, a filled Open (or Closed) pill, a\nBlocked pill when an open blocker exists, and a pencil linking to the edit page.\nThe body renders as the first comment card — author, opened relative time, an\nedited marker when edited, and a role badge when the author is a maintainer —\nfollowed by the comment thread as cards (each with author and time; a closed\nissue shows its close reason, a reopened issue shows the reopened state). The\nthread ends in a composer whose footer carries the lifecycle action: Close issue\nwith a reason chooser (completed default, not planned, duplicate) for an open\nissue, or Reopen for a closed one, beside the Comment button. Viewers get a\nread-only notice instead of the composer.\n\n**Blocked by:** 01\n\n**Status:** ready-for-agent\n\n- [ ] The header shows title + number, a filled Open/Closed pill, a Blocked pill\n      when applicable, and an edit pencil\n- [ ] The body appears as the first comment card with author, opened time, an\n      edited marker when edited, and a maintainer badge when applicable\n- [ ] Comments render as cards; a closed issue shows its close reason and a\n      reopened issue shows the reopened state\n- [ ] A manager sees Close-with-reason (open) or Reopen (closed) in the composer\n      footer, and closing/reopening still works via the existing routes\n- [ ] A viewer sees a read-only notice and no composer\n- [ ] No route, store, API, or schema change\n",[],[304,497,530,497,532],"f9ae41d9-43f3-4d72-ac25-e5ff303e87ef","b3107e7a-7fb7-11f1-b594-1607ee4eb77e",238,["D",1784056238688],[332,333],[304,497,530,497],"2acc39c9-ac03-40d5-a465-a4e0762786f6",237,["D",1784056238504],[331],[304,497,530],"087701f2-85c7-4143-bf9c-c982c16aabc3",137,["D",1783641873603],[330,334],[304,497],"333d9aaa-e7b2-4eb4-b3d6-a187292833b3","triage-labels.md","ee979b04-7bf2-11f1-ab8e-1607ee4eb77e","ee3720da-7bf2-11f1-8964-1607ee4eb77e",170,["D",1783653142340],"# Triage Labels\n\nThe skills speak in terms of five canonical triage roles. This file maps those\nroles to the actual label strings used in this repo's issue tracker.\n\n| Label in mattpocock/skills | Label in our tracker | Meaning                                  |\n| -------------------------- | -------------------- | ---------------------------------------- |\n| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |\n| `needs-info`               | `needs-info`         | Waiting on reporter for more information |\n| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |\n| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |\n| `wontfix`                  | `wontfix`            | Will not be actioned                     |\n\nWhen a skill mentions a role (e.g. \"apply the AFK-ready triage label\"), use the\ncorresponding label string from this table.\n\n> Note: these five are the **skills' workflow** labels applied to `docs/issues/`\n> tickets. They are a different axis from the issue-tracker _product's_ labels\n> (`bug`, `enhancement`, `documentation`, `question`, `duplicate`) defined in\n> `CONTEXT.md`. Don't conflate the two.\n\nEdit the right-hand column to match whatever vocabulary you actually use.\n",[],[304,564,556],"agents","82f10ed3-774a-43fd-9359-15b8c0e73a99","issue-tracker.md","eea668c8-7bf2-11f1-8b8f-1607ee4eb77e",171,["D",1783653142513],"# Issue tracker: Local Markdown\n\nIssues and PRDs for this repo live as markdown files in `docs/issues/`.\n\n## Conventions\n\n- One feature per directory: `docs/issues/<feature-slug>/`\n- The PRD is `docs/issues/<feature-slug>/PRD.md`\n- Implementation issues are `docs/issues/<feature-slug>/issues/<NN>-<slug>.md`,\n  numbered from `01`\n- Triage state is recorded as a `Status:` line near the top of each issue file\n  (see `triage-labels.md` for the role strings)\n- Comments and conversation history append to the bottom of the file under a\n  `## Comments` heading\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a new file under `docs/issues/<feature-slug>/` (creating the directory if\nneeded).\n\n## When a skill says \"fetch the relevant ticket\"\n\nRead the file at the referenced path. The user will normally pass the path or\nthe issue number directly.\n\n## Wayfinding operations\n\nUsed by `/wayfinder`. The **map** is a file with one **child** file per ticket.\n\n- **Map**: `docs/issues/<effort>/map.md` — the Notes / Decisions-so-far / Fog\n  body.\n- **Child ticket**: `docs/issues/<effort>/issues/NN-<slug>.md`, numbered from\n  `01`, with the question in the body. A `Type:` line records the ticket type\n  (`research`/`prototype`/`grilling`/`task`); a `Status:` line records\n  `claimed`/`resolved`.\n- **Blocking**: a `Blocked by: NN, NN` line near the top. A ticket is unblocked\n  when every file it lists is `resolved`.\n- **Frontier**: scan `docs/issues/<effort>/issues/` for files that are open,\n  unblocked, and unclaimed; first by number wins.\n- **Claim**: set `Status: claimed` and save before any work.\n- **Resolve**: append the answer under an `## Answer` heading, set\n  `Status: resolved`, then append a context pointer (gist + link) to the map's\n  Decisions-so-far in `map.md`.\n",[],[304,564,566],"761446ff-c75d-4331-83d4-ae4f43707105","domain.md","ee8a62a4-7bf2-11f1-9482-1607ee4eb77e",169,["D",1783653142230],"# Domain Docs\n\nHow the engineering skills should consume this repo's domain documentation when\nexploring the codebase.\n\n## Before exploring, read these\n\n- **`CONTEXT.md`** at the repo root, or\n- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one\n  `CONTEXT.md` per context. Read each one relevant to the topic.\n- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In\n  multi-context repos, also check `src/<context>/docs/adr/` for context-scoped\n  decisions.\n\nIf any of these files don't exist, **proceed silently**. Don't flag their\nabsence; don't suggest creating them upfront. The `/domain-modeling` skill\n(reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates\nthem lazily when terms or decisions actually get resolved.\n\n## File structure\n\nThis repo is **single-context**: one root `CONTEXT.md` + `docs/adr/`.\n\n```\n/\n├── CONTEXT.md\n├── docs/adr/\n│   ├── 0001-seed-default-labels-once.md\n│   ├── 0002-blocking-graph-integrity.md\n│   ├── 0003-audit-columns-and-editability.md\n│   └── 0004-append-only-events-log.md\n└── ...\n```\n\n(For reference, a multi-context repo would instead have a `CONTEXT-MAP.md` at\nthe root pointing at per-context `CONTEXT.md` files under `src/<context>/`, each\nwith its own `docs/adr/`.)\n\n## Use the glossary's vocabulary\n\nWhen your output names a domain concept (in an issue title, a refactor proposal,\na hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift\nto synonyms the glossary explicitly avoids.\n\nIf the concept you need isn't in the glossary yet, that's a signal — either\nyou're inventing language the project doesn't use (reconsider) or there's a real\ngap (note it for `/domain-modeling`).\n\n## Flag ADR conflicts\n\nIf your output contradicts an existing ADR, surface it explicitly rather than\nsilently overriding:\n\n> _Contradicts ADR-0002 (blocking graph is a strict DAG) — but worth reopening\n> because…_\n",[],[304,564,574],"8a26a61d-d596-4a29-9050-a96215f95442",136,["D",1783641873401],[326,327,328],[304,564],"31c02dd3-aedd-4960-bc34-e9b9c5426093","0004-append-only-events-log.md","ee7eb5c6-7bf2-11f1-8930-1607ee4eb77e","ee2551f2-7bf2-11f1-a4f1-1607ee4eb77e",168,["D",1783653142026],"# 0004 — Single append-only events log as source of truth for history\n\n## Status\n\nAccepted\n\n## Context\n\nAudit columns (ADR 0003) record only the _last_ writer of a row — they cannot\nanswer \"what happened to this issue over time,\" and crucially cannot recover\ninformation that a mutation _removed_ (a label unapplied, an assignee dropped, a\nblock edge deleted). We want both an audit trail and full state history, and\noptionally a GitHub-style activity timeline later.\n\n## Decision\n\nAdd one append-only, polymorphic table:\n\n```\nissue_tracker_events(\n  id              INTEGER PK,\n  event_type      TEXT,      -- \"<entity>.<verb>\"\n  entity_id       INTEGER,   -- id of the issue/comment/label\n  actor           TEXT,      -- Val Town handle who did it\n  data            TEXT,      -- JSON, shape depends on verb\n  event_timestamp INTEGER\n)\n```\n\n- **Entities**: `issue`, `comment`, `label`. **Verbs**: `created`, `updated`,\n  `deleted`.\n- **Grammar** — _boundary events snapshot, updates carry deltas_:\n  - `*.created` → full initial-state snapshot in `data`.\n  - `*.deleted` → full final-state snapshot in `data` (entities are\n    **hard-deleted**; the event is the tombstone — see ADR 0003 amendment /\n    soft-delete rejected).\n  - `*.updated` → `{ update_target, from, to }`.\n- **Associations have no entity type of their own.** Applying/removing a label,\n  assigning/unassigning a user, and adding/removing a block edge are modelled as\n  `issue.updated` events with `update_target` ∈ {`label`, `assignee`, `blocks`,\n  `blocked_by`} and `from`/`to` using **`null ↔ value`** (null→X = added, X→null\n  = removed). This reuses the scalar-edit grammar; no new verb, no link entity\n  type.\n- **One event per changed field.** Closing emits two events (`status`\n  open→closed and `state_reason` null→reason) sharing one\n  `actor`/`event_timestamp`; reopen likewise. Rendering \"closed as not planned\"\n  as a single timeline line is a read-time grouping by (actor, timestamp).\n- **Block edges write one event, on the acting issue** (ADR 0002 / Q17); the\n  reverse \"blocked by\" view is derived by querying events whose `to` references\n  the issue.\n\n## Consequences\n\n- The log is the single source of truth for provenance and history; live tables\n  hold only current state. Every entity create/update/delete and every\n  association change **must** emit an event, or provenance is lost.\n- Full state at any past time is reconstructable: start from the `created`\n  snapshot, replay `updated` deltas forward.\n- Removals are captured (the whole point) — a `label_removed`-style fact\n  survives as an `issue.updated` with `to: null`, and deleted entities leave a\n  snapshot tombstone.\n- Whether the log is surfaced in the UI (activity timeline) is deferred; the\n  data supports it either way. Auditability is derived, not a stored view.\n- The table grows unboundedly (append-only); pruning/retention is a future\n  concern.\n",[],[304,595,587],"adr","26aa1419-2852-4924-b2b1-f3eb9e4adc9e","0003-audit-columns-and-editability.md","ee76ee18-7bf2-11f1-8022-1607ee4eb77e",166,["D",1783653141647],"# 0003 — Audit columns and universal editability\n\n## Status\n\nAccepted — **partially superseded by ADR 0004** (see amendment at end). The\n_editability_ decision stands in full; the `*_by` columns and the link\ncreation-pair were removed once the events log (ADR 0004) became the source of\ntruth for provenance.\n\n## Context\n\nWe want to know who created and last changed every piece of user-authored data,\nand we want a uniform convention rather than ad-hoc timestamps per table. Today\nit is inconsistent: issues have `created_by`/`created_at`/`updated_at` but no\n`updated_by`; comments have only `author` + `created_at` and no edit operation\nat all.\n\n## Decision\n\nTwo rules, applied across the whole schema:\n\n1. **Entities carry all four audit columns**: `created_at`, `created_by`,\n   `updated_at`, `updated_by`. Entities are the things a user authors and can\n   later change — **Issue**, **Comment**, **Label**. Consequently, _every entity\n   is editable_ (there is an update operation for each), including comments.\n   `created_by`/`updated_by` hold Val Town handles.\n\n2. **Join / link rows carry only the creation pair**: `created_at` +\n   `created_by` (surfaced with intent-revealing names, e.g.\n   `assigned_at`/`assigned_by` on assignees, `linked_at`/`linked_by` on block\n   edges). Links are immutable — a user _adds_ or _removes_ them, never _edits_\n   one — so `updated_at`/`updated_by` would be meaningless.\n\nNaming: the Comment's `author` column is renamed **`created_by`** so the\nconvention is uniform (the author _is_ the creator).\n\n## Consequences\n\n- Comment editing becomes a real, supported operation (mirrors GitHub).\n- Every table's provenance is queryable in a uniform way; no per-table special\n  cases.\n- `updated_at` combines with the \"touch\" rule (see CONTEXT.md): association\n  changes bump the parent issue's `updated_at` too.\n- Slightly more columns and write-path bookkeeping everywhere — accepted for the\n  auditability and uniformity it buys.\n\n## Amendment (superseded in part by ADR 0004)\n\nOnce the append-only events log (ADR 0004) was adopted, it became the source of\ntruth for _who_ did _what_ and _when_. That makes the `*_by` columns redundant —\nactor is derivable as the latest event for an entity. We therefore revised this\ndecision:\n\n- **Entities keep only `created_at` + `updated_at`** as denormalized columns —\n  they drive hot-path listing and \"last activity\" sorting, which would otherwise\n  require a `MAX(event_timestamp)` aggregate over the log on every render.\n- **`created_by` / `updated_by` columns are dropped.** The actor is derived from\n  the events log, which is already loaded on the only screen that needs it (an\n  entity's detail/timeline view).\n- **Link rows carry no audit columns at all** — assignees and block edges become\n  bare relationship tuples; their provenance lives entirely in events.\n\nWhat stands unchanged from the original decision: **every entity (Issue,\nComment, Label) is editable**, including comments, and the Comment's old\n`author` column is gone (its creator is derived from the `comment.created`\nevent).\n",[],[304,595,597],"bf1eb092-9651-471a-b7da-df0287561a70","0002-blocking-graph-integrity.md","eedbe340-7bf2-11f1-a9f4-1607ee4eb77e",183,["D",1783653141615],"# 0002 — Blocking graph is a strict DAG (reject all cycles)\n\n## Status\n\nAccepted\n\n## Context\n\nIssues can block each other, forming a directed graph stored as edges in\n`issue_tracker_issue_blocks(blocker_id, blocked_id)` (edge direction: blocker →\nblocked). Such a graph can contain degenerate or cyclic edges:\n\n- **Self-edge** — A blocks A.\n- **Direct reciprocal** — A blocks B and B blocks A.\n- **Longer cycle** — A blocks B, B blocks C, C blocks A.\n\nGitHub, empirically, rejects self-edges and direct reciprocals but _allows_\nlonger cycles like A→B→C→A (verified against its GraphQL `blockedBy`/`blocking`\nAPI). We deliberately do **not** follow GitHub here.\n\n## Decision\n\nEnforce a strict DAG — reject **any** edge that would create a cycle. All three\ncases above collapse into one rule, checked on insert of edge\n`blocker → blocked`:\n\n> Reject if `blocked` can already reach `blocker` by following block-edges —\n> i.e. a path `blocked → … → blocker` already exists (a self-edge is the\n> degenerate `blocked == blocker` case).\n\nImplemented as a reachability query (SQLite `WITH RECURSIVE`) run in the\ndatabase on each insert. `UNIQUE(blocker_id, blocked_id)` additionally prevents\nduplicate edges.\n\n## Rationale\n\nA cycle in a dependency graph is logically incoherent: a loop of issues that can\nnever be satisfied in dependency order. Keeping the graph a strict DAG also\npreserves the option to add topological \"what's workable now\" ordering later\nwithout retrofitting cycle detection.\n\n## Consequences\n\n- Every edge insert pays for one reachability traversal. For a\n  personal/small-team tracker's graph size this is negligible, and it runs\n  entirely in SQLite.\n- The block graph is guaranteed acyclic, so downstream features may safely\n  assume a topological order exists.\n- This is stricter than GitHub; anyone porting expectations from GitHub should\n  know that A→B→C→A is refused here.\n",[],[304,595,605],"610774cf-6c90-4bf8-91cb-2b82abfa3ecc","0001-seed-default-labels-once.md","ee84afa8-7bf2-11f1-8022-1607ee4eb77e",167,["D",1783653141936],"# 0001 — Seed default labels once, at table creation only\n\n## Status\n\nAccepted\n\n## Context\n\nThe tracker is a drop-in library: `initSchema()` is idempotent and runs on\n**every request** to guarantee the host val's tables exist. We also want to ship\na curated set of default labels (`bug`, `enhancement`, `documentation`,\n`question`, `duplicate`), and labels are user-deletable.\n\nThese two facts collide. If defaults are inserted \"when missing\" inside the\nper-request `initSchema()`, then any default a user deliberately deletes will\nreappear on the very next request — deletion would be impossible for default\nlabels.\n\n## Decision\n\nSeed the default labels **exactly once, in the branch that creates the\n`issue_tracker_labels` table** (i.e. only when it did not previously exist).\nOnce the table exists, `initSchema()` never touches label _rows_ again. After\ncreation the label set belongs entirely to the user: deletes and edits are\npermanent.\n\n## Consequences\n\n- Default labels behave like a starting kit, not enforced state — users can\n  prune or rename any of them and the changes stick.\n- The \"table was just created\" signal must be detected explicitly (e.g. check\n  existence before `CREATE TABLE`, or seed only when a freshly created table is\n  empty on first creation), since `CREATE TABLE IF NOT EXISTS` alone doesn't\n  tell us whether it already had data.\n- A host that wants the defaults back after deleting them must re-add them\n  manually; there is intentionally no auto-heal.\n",[],[304,595,613],"12a719bc-c079-4db1-bbdb-e6251ba56110",135,["D",1783641873285],[321,322,323,324],[304,595],["D",1783635592340],[320,325,329,338,339],[304],["D",1783563523910],["D",1789525245864],{"_98":97,"_105":101},{"_98":97,"_99":-5,"_100":101,"_18":53,"_102":103,"_104":24},{"_13":87,"_31":88,"_41":40,"_89":42,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":43,"_96":97},"ctx",{"_80":-5,"_125":666,"_667":668,"_669":670,"_671":24,"_672":24,"_673":24,"_674":57,"_675":-5,"_676":-7,"_677":-7,"_678":61,"_679":24,"_680":24,"_681":-5,"_682":24,"_683":24,"_684":24,"_685":-5},"ENV",{"_637":638,"_639":640,"_641":88,"_642":643,"_644":645,"_646":647,"_648":649,"_650":651,"_652":653,"_654":655,"_656":657,"_658":659,"_660":661,"_662":663,"_664":665},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]
</article></body></html>

Diff · v246