{title}

[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_642":643,"_644":645},"routes/_app.x.$handle.$name",{"_98":97,"_31":43,"_106":88,"_26":107,"_13":14,"_108":-5,"_11":109,"_110":111,"_112":113,"_114":115,"_116":117,"_20":-5,"_118":-5,"_119":-5,"_120":24,"_121":122,"_123":57,"_124":-5,"_125":-5,"_126":127},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_41":42,"_31":43,"_36":44,"_45":-5,"_46":24,"_47":48,"_49":48,"_50":51,"_52":-5,"_18":53,"_54":55,"_56":57,"_58":-5,"_59":-5,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":-5,"_71":72,"_73":72,"_74":75,"_76":75,"_77":75,"_78":72,"_79":72,"_80":81,"_82":83,"_84":85,"_86":24},"version",247,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":-7,"_23":24,"_25":24,"_26":27,"_28":27},"file",{"_29":30,"_31":32,"_33":20,"_34":35,"_36":37,"_38":14,"_39":40,"_23":24},"previous","deleted",false,"deletedHere","path","docs/issues/github-style-ui/issues/01-shared-top-bar.md","latestPath","fileId","b3a02c82-7fb7-11f1-9b8e-1607ee4eb77e","name","01-shared-top-bar.md","fileType","content","# 01 — Shared top bar in the layout\n\n**What to build:** On every page, a slim shared top bar replaces per-page\nnavigation. It shows two tabs — Issues and Labels — with the current surface\nactive, the signed-in user's handle and avatar on the right, and the existing\nauth affordance: a log in link when signed out (wherever a login location\nexists), log out when signed in, and neither when the tracker is mounted under\nan ungated router. In routed mode the bar is the only chrome the tracker adds.\nPer-page back links and duplicate New issue / Labels buttons come out in favor\nof the bar as each page is restyled.\n\n**Blocked by:** None — can start immediately.\n\n**Status:** ready-for-agent\n\n- [ ] Every page renders the top bar with Issues and Labels tabs linking to\n their surfaces\n- [ ] The tab for the current surface is visibly active\n- [ ] Signed out with an available login: the bar shows a log in link; signed\n in: it shows the user handle and a log out control\n- [ ] Under an ungated routed mount, the bar shows neither log in nor log out\n- [ ] Internal links respect the mount prefix in routed mode and are prefix-free\n standalone\n- [ ] No route, store, API, or schema change; existing tests still pass\n","createdAt",["D",1784056239433],"branchVersion","branchId","b6817ee5-03f4-41f2-901e-1bb2efa16e9e","id","abe99189-4851-4aab-ae08-280f66283cac","val-issue-tracker",["D",1783563523910],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","Per-val issue tracker — import into any val for scoped issues","imageUrl","5d1042a9-7b0b-499d-8a72-3a8ac7a4e185","pinnedFileId","d1d90306-7b3c-11f1-b527-1607ee4eb77e","pinPreview",true,"pinMigrated","screenshotVersion","likeCount",0,"orgId","5f80108f-7ca4-4327-b77b-089dbe4b5a82","tursoName","abe9918948514aabae08280f66283cac","tursoHostname","abe9918948514aabae08280f66283cac-val-town.aws-us-east-2.turso.io","tursoMeasuredAt",["D",1789525245864],"pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_98":97,"_105":101},"org",{"_98":97,"_99":-5,"_100":101,"_18":53,"_102":103,"_104":24},"branch",{"_13":87,"_31":88,"_41":40,"_89":42,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":43,"_96":97},"isOwned",369,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","nbbaier","handle","displayName","avatar","https://secure.gravatar.com/avatar/0129a541b7b3574e92c4afd06c5e32da&d=identicon","tier","pro","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_41":42,"_31":43,"_36":637,"_45":-5,"_46":24,"_47":48,"_49":48,"_50":51,"_52":-5,"_18":53,"_54":55,"_56":57,"_58":-5,"_59":-5,"_60":61,"_62":63,"_64":65,"_66":67,"_68":638,"_70":-5,"_71":72,"_73":72,"_74":75,"_76":75,"_77":75,"_78":72,"_79":72,"_80":639,"_82":640,"_84":641,"_86":24},"tree",[319,341,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366],"files",[319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366],"counts",{"_309":61,"_310":198,"_311":61,"_312":313,"_314":315},"contents",[128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_41":303,"_31":304,"_29":305,"_152":-5,"_39":40,"_38":306,"_154":57,"_36":307,"_13":61,"_33":301,"_34":-5,"_23":24,"_159":-5,"_26":308},{"_41":296,"_31":297,"_29":298,"_152":-5,"_39":40,"_38":299,"_154":57,"_36":300,"_13":61,"_33":301,"_34":-5,"_23":24,"_159":-5,"_26":302},{"_41":289,"_31":290,"_29":291,"_152":-5,"_39":40,"_38":292,"_154":57,"_36":293,"_13":61,"_33":20,"_34":294,"_23":24,"_159":-5,"_26":295},{"_41":283,"_31":284,"_29":285,"_152":-5,"_39":40,"_38":286,"_154":24,"_36":287,"_13":198,"_33":20,"_34":281,"_23":24,"_159":-5,"_26":288},{"_41":276,"_31":277,"_29":278,"_152":-5,"_39":40,"_38":279,"_154":24,"_36":280,"_13":198,"_33":20,"_34":281,"_23":24,"_159":-5,"_26":282},{"_41":269,"_31":270,"_29":271,"_152":-5,"_39":40,"_38":272,"_154":57,"_36":273,"_13":190,"_33":20,"_34":274,"_23":24,"_159":-5,"_26":275},{"_41":261,"_31":262,"_29":263,"_152":-5,"_39":40,"_38":264,"_154":24,"_36":265,"_13":266,"_33":20,"_34":267,"_23":24,"_159":-5,"_26":268},{"_41":254,"_31":255,"_29":256,"_152":-5,"_39":40,"_38":257,"_154":24,"_36":258,"_13":190,"_33":157,"_34":259,"_23":24,"_159":-5,"_26":260},{"_41":247,"_31":248,"_29":249,"_152":-5,"_39":40,"_38":250,"_154":24,"_36":251,"_13":190,"_33":157,"_34":252,"_23":24,"_159":-5,"_26":253},{"_41":239,"_31":240,"_29":241,"_152":-5,"_39":40,"_38":242,"_154":24,"_36":243,"_13":244,"_33":157,"_34":245,"_23":24,"_159":-5,"_26":246},{"_41":231,"_31":232,"_29":233,"_152":-5,"_39":40,"_38":234,"_154":24,"_36":235,"_13":236,"_33":157,"_34":237,"_23":24,"_159":-5,"_26":238},{"_41":223,"_31":224,"_29":225,"_152":-5,"_39":40,"_38":226,"_154":24,"_36":227,"_13":228,"_33":157,"_34":229,"_23":24,"_159":-5,"_26":230},{"_41":215,"_31":216,"_29":217,"_152":-5,"_39":40,"_38":218,"_154":24,"_36":219,"_13":220,"_33":157,"_34":221,"_23":24,"_159":-5,"_26":222},{"_41":208,"_31":209,"_29":210,"_152":-5,"_39":40,"_38":211,"_154":24,"_36":212,"_13":166,"_33":157,"_34":213,"_23":24,"_159":-5,"_26":214},{"_41":201,"_31":202,"_29":203,"_152":-5,"_39":40,"_38":204,"_154":24,"_36":205,"_13":190,"_33":20,"_34":206,"_23":24,"_159":-5,"_26":207},{"_41":193,"_31":194,"_29":195,"_152":-5,"_39":40,"_38":196,"_154":24,"_36":197,"_13":198,"_33":157,"_34":199,"_23":24,"_159":-5,"_26":200},{"_41":185,"_31":186,"_29":187,"_152":-5,"_39":40,"_38":188,"_154":24,"_36":189,"_13":190,"_33":157,"_34":191,"_23":24,"_159":-5,"_26":192},{"_41":177,"_31":178,"_29":55,"_152":-5,"_39":40,"_38":179,"_154":57,"_36":180,"_13":181,"_33":182,"_34":183,"_23":24,"_159":-5,"_26":184},{"_41":169,"_31":170,"_29":171,"_152":-5,"_39":40,"_38":172,"_154":57,"_36":173,"_13":174,"_33":157,"_34":175,"_23":24,"_159":-5,"_26":176},{"_41":161,"_31":162,"_29":163,"_152":-5,"_39":40,"_38":164,"_154":57,"_36":165,"_13":166,"_33":157,"_34":167,"_23":24,"_159":-5,"_26":168},{"_41":149,"_31":150,"_29":151,"_152":-5,"_39":40,"_38":153,"_154":24,"_36":155,"_13":156,"_33":157,"_34":158,"_23":24,"_159":-5,"_26":160},"7c7afc6c-49e2-481f-a1d4-4bfd3e2bee74","ui.tsx","fca19e20-7b48-11f1-8cf9-1607ee4eb77e","parentId",233,"latest",["D",1784052698700],32,"script","/** @jsxImportSource npm:hono@4.6.14/jsx */\nimport type { FC, PropsWithChildren } from \"npm:hono@4.6.14/jsx\";\nimport type { IssueStatus, Label, StateReason } from \"./db.ts\";\n\nexport const FIELD =\n \"bg-[#1f232c] border border-[#2a2f3a] rounded-md min-h-10 px-3.5 text-sm font-medium text-[#e6e9ef] focus:outline-none focus:border-[#6ea8fe]\";\nconst BUTTON =\n \"inline-flex items-center gap-1.5 rounded-md min-h-10 px-3.5 text-sm font-medium cursor-pointer no-underline\";\nconst VARIANTS = {\n solid: \"bg-[#3d7bf0] border border-[#3d7bf0] text-white hover:brightness-110\",\n ghost:\n \"bg-transparent border border-[#3d7bf0] text-[#e6e9ef] hover:brightness-110\",\n danger:\n \"bg-transparent border border-[#f06e7b] text-[#f06e7b] hover:bg-[#f06e7b] hover:text-white\",\n} as const;\n\nexport const STATUS_LABELS: Record = {\n open: \"Open\",\n closed: \"Closed\",\n};\nexport const STATE_REASON_LABELS: Record, string> = {\n completed: \"Completed\",\n not_planned: \"Not planned\",\n duplicate: \"Duplicate\",\n reopened: \"Reopened\",\n};\n\nexport const Card: FC> = ({\n children,\n class: cls,\n}) => (\n \n {children}\n \n);\n\nexport const Button: FC<\n PropsWithChildren<{\n variant?: keyof typeof VARIANTS;\n href?: string;\n type?: \"button\" | \"submit\";\n class?: string;\n name?: string;\n value?: string;\n }>\n> = ({\n variant = \"solid\",\n href,\n type = \"button\",\n class: cls,\n name,\n value,\n children,\n}) => {\n const classes = `${BUTTON} ${VARIANTS[variant]} ${cls ?? \"\"}`;\n return href\n ? (\n \n {children}\n \n )\n : (\n \n );\n};\n\nexport const Select: FC<\n PropsWithChildren<{ name: string; id?: string; class?: string }>\n> = ({ name, id, class: cls, children }) => (\n \n);\n\nexport const Banner: FC<{ kind: \"ok\" | \"err\"; msg: string }> = ({\n kind,\n msg,\n}) => (\n \n {msg}\n \n);\n\nexport const StatusBadge: FC<{ status: IssueStatus; reason?: StateReason }> = ({\n status,\n reason,\n}) => (\n \n {STATUS_LABELS[status]}\n {reason ? ` · ${STATE_REASON_LABELS[reason]}` : \"\"}\n \n);\n\nexport const LabelTag: FC<{ label: Label }> = ({ label }) => (\n \n {label.name}\n \n);\n","label",[150],"06a3a637-e081-4666-a2b1-479fa57ef458","test_sqlite.ts","2bb2ce86-7c0d-11f1-9a68-1607ee4eb77e",220,["D",1784052697980],3,"import { DatabaseSync } from \"node:sqlite\";\n\nexport interface TestResultSet {\n columns: string[];\n rows: Record[];\n rowsAffected: number;\n lastInsertRowid: bigint | undefined;\n}\n\nexport function createTestSqlite() {\n const database = new DatabaseSync(\":memory:\");\n database.exec(\"PRAGMA foreign_keys = ON\");\n\n const execute = (\n statement: string | { sql: string; args?: unknown[] },\n ): Promise => {\n try {\n const sql = typeof statement === \"string\" ? statement : statement.sql;\n const args = typeof statement === \"string\" ? [] : (statement.args ?? []);\n const prepared = database.prepare(sql);\n if (/^\\s*(SELECT|PRAGMA|WITH)\\b/i.test(sql)) {\n const rows = prepared.all(...(args as never[])) as Record<\n string,\n unknown\n >[];\n return Promise.resolve({\n columns: rows[0] ? Object.keys(rows[0]) : [],\n rows,\n rowsAffected: 0,\n lastInsertRowid: undefined,\n });\n }\n const result = prepared.run(...(args as never[]));\n return Promise.resolve({\n columns: [],\n rows: [],\n rowsAffected: Number(result.changes),\n lastInsertRowid: BigInt(result.lastInsertRowid),\n });\n } catch (error) {\n return Promise.reject(error);\n }\n };\n\n return {\n database,\n execute,\n /**\n * Mirror the libsql `transaction(\"write\")` contract on top of node:sqlite:\n * `BEGIN IMMEDIATE` opens an exclusive write transaction, statements run\n * sequentially on the single in-memory connection, and `commit`/`rollback`\n * close it. This is the same atomic-write contract `db.ts` drives in\n * production, so the store tests exercise the real transaction path.\n */\n transaction(_mode?: \"write\" | \"read\" | \"deferred\") {\n database.exec(\"BEGIN IMMEDIATE\");\n let settled = false;\n const finish = (verb: \"COMMIT\" | \"ROLLBACK\") => {\n if (settled) return Promise.resolve();\n settled = true;\n database.exec(verb);\n return Promise.resolve();\n };\n return Promise.resolve({\n execute,\n commit: () => finish(\"COMMIT\"),\n rollback: () => finish(\"ROLLBACK\"),\n });\n },\n };\n}\n",[162],"8d2480e3-0dfc-4ba9-ba40-4da9d6b62915","mod.ts","d1e3fc5c-7b3c-11f1-af1c-1607ee4eb77e",224,["D",1784052697990],13,"export { default, issueTracker, type IssueTrackerOptions } from \"./app.tsx\";\n",[170],"b7ee6e4d-e03e-49f9-b6a3-e9b3852a593e","main.ts",214,["D",1783790091112],11,"http","import { issueTracker } from \"./mod.ts\";\n\n/**\n * This val's own issue tracker — manages THIS val's scoped SQLite database.\n *\n * To add issues to a DIFFERENT val, import the tracker into that val:\n *\n * import { issueTracker } from \"https://esm.town/v/nbbaier/val-issue-tracker/mod.ts\";\n * export default issueTracker({ owner: [\"nbbaier\"] });\n *\n * Because scoped SQLite is bound to the running val, the imported tracker\n * reads/writes the host val's database automatically — no per-val config needed.\n */\nexport default issueTracker({});\n",[178],"56e2c869-afc1-4bc5-81d4-50446959c70f","layout.tsx","fd6015ee-7b48-11f1-bafe-1607ee4eb77e",230,["D",1784052698432],4,"/** @jsxImportSource npm:hono@4.6.14/jsx */\nimport type { FC, PropsWithChildren } from \"npm:hono@4.6.14/jsx\";\n\nexport const Layout: FC<\n PropsWithChildren<{\n title: string;\n user?: string | null;\n auth?: boolean;\n /** Mount prefix for internal links; \"\" standalone. /auth/* stays\n * origin-level in both modes, so those links never take it. */\n base?: string;\n }>\n> = ({ title, user, auth = true, base = \"\", children }) => (\n \n \n \n \n {title}\n \n \n\n",[],[297,458],"0624324c-15a1-4656-b4f5-0e2e312f15c2","flow.svg","b35d6c26-7fb7-11f1-851e-1607ee4eb77e",241,["D",1784056238995],"\n",[],[297,466],["D",1784056238376],[342,343,344,345,346,347],[297],"a7d6b8dd-1925-4e52-8b1a-7519e5abc73e","issue-tracker-valtown.md","4e874dca-7be4-11f1-973a-1607ee4eb77e",199,["D",1783711960586],2,"# Issue tracker: val-issue-tracker (JSON API)\n\nUse the tracker's JSON API for agent and script operations; do not scrape HTML.\n\n**Tracker URL**: `` (for example `https://username-myval.web.val.run`)\n\n**Auth**: reads are public. Writes require\n`Authorization: Bearer `. Each write may include `actor`,\na Val Town handle; omitted actors default to `agent`. Actor provenance is stored\nonly in the append-only events log.\n\n## Response shapes\n\nEvery response is JSON. Successful responses are either a single object, an\narray, or a small acknowledgement object (`{\"deleted\": id}` /\n`{\"updated\": id}`); error responses always have the shape:\n\n```json\n{ \"error\": \"human-readable message\" }\n```\n\n### Label\n\n```ts\n{\n id: number;\n name: string;\n color: string; // six lowercase hex characters, no leading \"#\"\n created_at: number; // ms since epoch\n updated_at: number;\n}\n```\n\n### IssueReference\n\nThe compact shape used inside `blockers` and `blocks`.\n\n```ts\n{\n id: number;\n title: string;\n status: \"open\" | \"closed\";\n state_reason: \"completed\" | \"not_planned\" | \"duplicate\" | \"reopened\" | null;\n}\n```\n\n### Issue\n\n```ts\n{\n id: number;\n title: string;\n body: string; // markdown, verbatim (not trimmed)\n status: \"open\" | \"closed\";\n state_reason: \"completed\" | \"not_planned\" | \"duplicate\" | \"reopened\" | null;\n created_at: number;\n updated_at: number; // last activity: own edits, comments, or association changes\n creator: string | null; // Val Town handle, derived from the issue's creation event\n labels: Label[];\n assignees: string[]; // Val Town handles, no \"@\" prefix\n blockers: IssueReference[];\n blocks: IssueReference[];\n blocked: boolean; // true iff at least one blocker is still \"open\"\n}\n```\n\n`GET /api/issues/:id` returns an `Issue` plus a `comments` field\n(`comments: Comment[]`); no other endpoint includes `comments`.\n\n### Comment\n\n```ts\n{\n id: number;\n issue_id: number;\n body: string; // markdown, verbatim\n created_at: number;\n updated_at: number;\n author: string | null; // Val Town handle, derived from the comment's creation event\n}\n```\n\n### Event\n\n```ts\n{\n id: number;\n event_type:\n | \"issue.created\" | \"issue.updated\" | \"issue.deleted\"\n | \"comment.created\" | \"comment.updated\" | \"comment.deleted\"\n | \"label.created\" | \"label.updated\" | \"label.deleted\";\n entity_id: number; // the issue/comment/label id the event is about\n actor: string;\n data: unknown; // grammar below\n event_timestamp: number;\n}\n```\n\n`GET /api/issues/:id/events` returns `Event[]` in append order.\n\n## Event data grammar\n\nEvents are the source of truth for provenance and history; live tables hold only\ncurrent state.\n\n- **Boundary events (`*.created`, `*.deleted`) snapshot full state.** The `data`\n field is the entity's complete state at that moment — a hard-deleted row\n leaves a full tombstone:\n - `issue.created` / `issue.deleted` data:\n `{id, title, body, status, state_reason, created_at, updated_at}`\n - `comment.created` / `comment.deleted` data:\n `{id, issue_id, body, created_at, updated_at}` (no `author` — that is always\n derived from the surrounding event, never stored in the payload)\n - `label.created` / `label.deleted` data:\n `{id, name, color, created_at, updated_at}`\n- **`*.updated` events carry a single field delta:**\n `{update_target, from, to}`.\n - For `issue.updated`, `update_target` is one of `title`, `body`, `status`,\n `state_reason`, `label`, `assignee`, `blocks`, `blocked_by`. Associations\n (`label`, `assignee`, `blocks`, `blocked_by`) use **`null ↔ value`**\n (`from: null` = added, `to: null` = removed). A block edge writes exactly\n one event, on the acting issue (the one named in the endpoint path).\n - For `comment.updated`, `update_target` is `\"body\"`.\n - For `label.updated`, `update_target` is `\"name\"` or `\"color\"`.\n - One event per changed field: closing an issue with a new reason emits two\n `issue.updated` events (`status` and `state_reason`), sharing one actor and\n timestamp.\n\n## Status codes\n\n| Status | Meaning |\n| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `200` | Read succeeded, or a mutation applied and the endpoint returns the resulting state. |\n| `201` | An issue, comment, or label was created. |\n| `400` | The request is malformed: invalid `:id`, invalid `status` filter, invalid close `reason`, invalid label `color`, a missing required scalar field (`title`; `name`/`color`; comment `body`), or a collection field (`label_ids`, `add`, `remove`, `assignees`) that isn't shaped as required — see below. |\n| `401` | A write was attempted with a missing or incorrect bearer token. |\n| `403` | A write was attempted but `ISSUE_TRACKER_API_KEY` isn't configured, so writes are disabled entirely. |\n| `404` | The issue, comment, or label named by `:id` — or referenced by an ID inside `label_ids`/`add`/`remove` — does not exist. |\n| `409` | The write conflicts with an existing invariant: a blocking edge would create a cycle (including a self-edge), or a label `name` collides with an existing label. |\n\n## Strict collection validation\n\n`label_ids`, and the `add`/`remove` fields on the labels and blocks/blocked-by\nendpoints, are validated as a whole, not filtered element by element:\n\n- **Absent** — treated as an empty operation (no IDs added or removed).\n- **Present** — must be an array where every element is a positive integer\n (`Number.isInteger(x) && x > 0`). Any other shape (not an array, a\n non-integer, zero, a negative number, a string, etc.) rejects the entire\n request with `400`; nothing is applied.\n- Each ID that passes shape validation must still reference an existing label or\n issue, or the request fails with `404`.\n\n`assignees`, and the `add`/`remove` fields on the assignees endpoint, follow the\nsame absent-is-empty / present-is-all-or-nothing rule, but for handles:\n\n- **Present** — must be an array of non-empty strings after trimming and\n stripping a leading `@`. Any other shape rejects the request with `400`.\n- Handles are not entities (no lookup table), so there is no `404` for an\n unrecognized assignee — any well-shaped handle is accepted.\n\n## Endpoints\n\n| Method and path | Body / query | Success |\n| --------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |\n| `GET /api/issues` | `?status=open\\|closed&label=&assignee=&search=` | `200` `Issue[]`. `400` if `status` is present and not `open`/`closed`. |\n| `POST /api/issues` | `{title, body?, label_ids?: number[], assignees?: string[], actor?}` | `201` `Issue`. `400` missing `title` or malformed `label_ids`/`assignees`. `404` if a `label_ids` entry doesn't exist. |\n| `GET /api/issues/:id` | — | `200` `Issue & {comments: Comment[]}`. `400` invalid id. `404` missing issue. |\n| `PATCH /api/issues/:id` | `{title?, body?, actor?}` | `200` updated `Issue`. `400` invalid id. `404` missing issue. |\n| `DELETE /api/issues/:id` | `{actor?}` | `200` `{deleted: id}`. `400` invalid id. `404` missing issue. |\n| `POST /api/issues/:id/close` | `{reason?: \"completed\" \\| \"not_planned\" \\| \"duplicate\", comment?, actor?}` | `200` updated `Issue`; reason defaults to `completed`. `400` invalid id/reason. `404` missing issue. |\n| `POST /api/issues/:id/reopen` | `{actor?}` | `200` updated `Issue` with `state_reason: \"reopened\"`. `400` invalid id. `404` missing issue. |\n| `POST /api/issues/:id/labels` | `{add?: number[], remove?: number[], actor?}` | `200` updated `Issue`. `400` invalid id or malformed `add`/`remove`. `404` missing issue or a missing label id. |\n| `POST /api/issues/:id/assignees` | `{add?: string[], remove?: string[], actor?}` | `200` updated `Issue`. `400` invalid id or malformed `add`/`remove`. `404` missing issue. |\n| `POST /api/issues/:id/blocks` | `{add?: number[], remove?: number[], actor?}` | `200` updated `Issue`. `400` invalid id or malformed `add`/`remove`. `404` missing issue or referenced issue id. `409` cycle or self-edge. |\n| `POST /api/issues/:id/blocked-by` | `{add?: number[], remove?: number[], actor?}` | Same as `/blocks`, opposite edge direction. |\n| `POST /api/issues/:id/comments` | `{body, actor?}` | `201` `Comment`. `400` invalid id or missing `body`. `404` missing issue. |\n| `PATCH /api/comments/:id` | `{body, actor?}` | `200` `{updated: id}`. `400` invalid id or missing `body`. `404` missing comment. |\n| `DELETE /api/comments/:id` | `{actor?}` | `200` `{deleted: id}`. `400` invalid id. `404` missing comment. |\n| `GET /api/issues/:id/events` | — | `200` `Event[]` in append order. `400` invalid id. `404` missing issue. |\n| `GET /api/labels` | — | `200` `Label[]`. |\n| `POST /api/labels` | `{name, color, actor?}` | `201` `Label` (`color` is hex, with or without `#`). `400` missing `name`/`color` or invalid `color`. `409` `name` already in use. |\n| `PATCH /api/labels/:id` | `{name?, color?, actor?}` | `200` updated `Label`. `400` invalid id or `color`. `404` missing label. `409` renaming to an in-use `name`. |\n| `DELETE /api/labels/:id` | `{actor?}` | `200` `{deleted: id}`. `400` invalid id. `404` missing label. |\n\nAll write routes additionally return `401` for a missing/incorrect bearer token,\nand `403` if `ISSUE_TRACKER_API_KEY` is unset — checked before any body or id\nvalidation.\n\n## Triage labels\n\nLabels are curated entities, not free-text arrays. Before applying workflow\nlabels such as `needs-triage`, create each one once with `POST /api/labels`,\nretain its ID, then send that ID to the issue-label endpoint. The product's\nfresh-install defaults are `bug`, `enhancement`, `documentation`, `question`,\nand `duplicate`.\n\n## curl examples\n\n```bash\nTRACKER=https://your-handle-your-val.web.val.run\nKEY=...\n\n# Discover label IDs\ncurl -s \"$TRACKER/api/labels\"\n\n# Create with curated labels and multiple assignees\ncurl -s -X POST \"$TRACKER/api/issues\" \\\n -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n -d '{\"title\":\"Fix flaky test\",\"body\":\"Observed in CI\",\"label_ids\":[1],\"assignees\":[\"alice\"],\"actor\":\"alice\"}'\n\n# Close as deliberately not planned\ncurl -s -X POST \"$TRACKER/api/issues/12/close\" \\\n -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n -d '{\"reason\":\"not_planned\",\"comment\":\"Superseded by #15.\",\"actor\":\"alice\"}'\n\n# Reopen\ncurl -s -X POST \"$TRACKER/api/issues/12/reopen\" \\\n -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n -d '{\"actor\":\"alice\"}'\n\n# Declare that #12 blocks #15\ncurl -s -X POST \"$TRACKER/api/issues/12/blocks\" \\\n -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n -d '{\"add\":[15],\"actor\":\"alice\"}'\n```\n",[],[304,477],"209f927c-480f-4f66-8f57-ecc131f50714","backlog.md","eea1bf8a-7bf2-11f1-975e-1607ee4eb77e",173,["D",1783653142692],"# Backlog — deferred wants\n\nThings wanted eventually, not now. Not commitments; parking lot.\n\n- **Clickable user handles.** Wherever a user handle is displayed (creator,\n comment author, assignee), render it as a link to that user's Val Town\n profile. Purely a rendering concern — the data model just stores the handle.\n (See [[User]] in CONTEXT.md.)\n- **Markdown rendering.** Issue bodies and comment bodies are stored as\n markdown; rendering them to HTML is a later concern.\n",[],[304,486],"0f39a161-6c79-4dab-9fbc-d3a2a3ec0bc0","tickets.md","eeb0130a-7bf2-11f1-8022-1607ee4eb77e","ee67d8e2-7bf2-11f1-b0f6-1607ee4eb77e",175,["D",1783653142898],"# Tickets: Richer data model for val-issue-tracker\n\nTracer-bullet tickets implementing the richer data model. Source spec:\n`docs/issues/richer-data-model/PRD.md`. Governed by `CONTEXT.md` + ADRs\n0001–0004.\n\nAll tickets are `ready-for-agent` — agent-grabbable by construction.\n\n## Implementation checklist\n\n- [x] Ticket 1 — core schema reshape and issue lifecycle\n- [x] Ticket 2 — append-only events and lifecycle provenance\n- [x] Ticket 3 — labels, assignees, blocking, comments, events, and touch rules\n- [x] Ticket 4 — idempotent old-schema migration\n- [x] Ticket 5 — final JSON API convention, consumer cleanup, and verification\n\nWork the **frontier**: any ticket whose blockers are all done. Order here is\ndependency order (blockers first): 1 → 2 → 3 → then 4 and 5 in parallel.\n\n> Migration caveat: tickets 1–3 are correct against _fresh_ databases. The ~3\n> existing deployments are only safe to run once ticket 4 (migration) lands,\n> since `initSchema` runs against live data every request. Deploy the set at the\n> end.\n\n## 1. Core schema reshape + issue lifecycle\n\nStatus: ready-for-agent\n\n**What to build:** Fresh-install issue schema on the new model — priority\nremoved entirely; `status` collapses to `open`/`closed`; a nullable\n`state_reason` (`completed`/`not_planned`/`duplicate`/`reopened`) guarded by a\n`CHECK` constraint against status; the issue body field renamed from\n`description` to `body`. The create / close / reopen operations auto-manage\n`state_reason` (create → null; close → chosen reason, default `completed`;\nreopen → `reopened`). The JSON API and HTML UI are reconciled to the new `Issue`\nshape, and the schema knowledge those two consumers currently duplicate\n(status/priority constants, label parse/serialize) is pulled into the\ndata-access layer as a prefactor so later tickets change one place. No migration\nof existing data in this ticket. _Demoable: create an issue, close it as\nnot_planned, reopen it — through both the API and the UI._\n\n**Blocked by:** None — can start immediately.\n\n## 2. Events log foundation + issue lifecycle events\n\nStatus: ready-for-agent\n\n**What to build:** The single append-only events table (`id`, `event_type`,\n`entity_id`, `actor`, `data`, `event_timestamp`) and the emit helper, wired into\nthe issue lifecycle from ticket 1. `*.created` and `*.deleted` carry full state\nsnapshots; `*.updated` carries `{ update_target, from, to }`. One event per\nchanged field, so closing emits two events (`status` and `state_reason`) sharing\nan actor and timestamp. _Demoable: close an issue and observe two events with\nthe acting handle and correct payloads._\n\n**Blocked by:** 1\n\n## 3. Associations: labels + assignees + blocking\n\nStatus: ready-for-agent\n\n**What to build:** All three issue relationships, end-to-end (schema +\noperations + API\n\n- UI + events + touch rule):\n\n* **Labels** — a curated Label entity (`name`, `color`), applied via a bare\n issue↔label join; a default set (`bug`, `enhancement`, `documentation`,\n `question`, `duplicate`) seeded exactly once at table creation and never\n re-seeded; apply/remove; label rename/recolour/delete (deleting an in-use\n label cascades its join rows away).\n* **Assignees** — a set of Val Town users via a bare issue↔handle join;\n add/remove; an \"assigned to me\" query.\n* **Blocking** — a directed `blocker → blocked` edge stored once; insert\n rejected if the target can already reach the source (strict DAG — self,\n reciprocal, and longer cycles all refused); remove; \"blocked\" derived (blocked\n while any blocker is still open) and never stored, and never gating close.\n\nEvery mutation emits its events — label ops as `label.*` plus `issue.updated`\nwith `update_target: label` using `null ↔ value`; assignee and block changes as\n`issue.updated` with `update_target` ∈ {assignee, blocks, blocked_by},\n`null ↔ value`; a block edge writes one event on the acting issue. Every\nassociation change also touches the parent issue's `updated_at`.\n\n_(Largest ticket — if it overflows a single context window at execution time,\nsplit back into labels / assignees / blocking, each blocked by 1 and 2.)_\n\n**Blocked by:** 1, 2\n\n## 4. Migration for existing deployments\n\nStatus: ready-for-agent\n\n**What to build:** One idempotent migration routine (living in the schema-init\npath, safe to run every request) that brings the ~3 existing deployments onto\nthe final schema: remap any `in_progress` issue to `open`; drop priority; expose\nthe old `description` as `body`; lift each existing JSON `labels` array into the\nLabel entities and issue↔label join (creating labels as needed); move any\nexisting single `assignee` into the assignee join; and backfill a synthetic\n`*.created` event (and any required state) for existing rows so no entity is\nleft without provenance. Running it twice is a no-op.\n\n**Blocked by:** 1, 2, 3\n\n## 5. Rewrite JSON API convention doc + final cleanup\n\nStatus: ready-for-agent\n\n**What to build:** Rewrite `docs/issue-tracker-valtown.md` to the new schema and\nendpoint surface (no priority, two statuses, `state_reason` on close/reopen, and\nthe label / assignee / block operations), replacing the outdated convention it\ndocuments today. Remove any remaining old-schema constants or dead code paths in\nthe consumers. Done last so the doc describes the final API exactly once.\n\n**Blocked by:** 3\n",[],[304,502,503,494],"issues","richer-data-model","1da2fc19-c168-4db0-ace9-4a383b4d3b42","certification.md","1d471d5a-7c96-11f1-a281-1607ee4eb77e",195,["D",1783711960231],"# Certification: richer-data-model remediation pass\n\nDate: 2026-07-10 Verdict: **certified complete** (independent recertification\naudit)\n\nAfter the five implementation tickets in `tickets.md` landed, a remediation pass\nran as five one-shot agent prompts (formerly in `agent-prompts/`, deleted after\nthis certification). What each fixed:\n\n1. **SQLite transaction contract** — `db.ts` drives every multi-statement write\n through `client.transaction(\"write\")` with explicit commit/rollback, never\n top-level `batch()`. The resolved adapter\n (`npm:@tursodatabase/serverless@1.2.3/compat`) was read at source and its\n top-level `batch()` confirmed broken for this purpose: it ignores the mode\n argument and drops bound args. Proven by tests: a batch-throwing client,\n forced mid-transaction failure rollback, and entity-ID (not event-ID) return\n values.\n2. **Comment UI** — the comment edit control is a `

` 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,502,503,505],"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,502,503,513],"09a12ef3-b79f-45bc-b0d7-6c7e712da8e8","ee584d8c-7bf2-11f1-8d5b-1607ee4eb77e",138,["D",1783641873720],[336,337,338],[304,502,503],"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,502,535,502,527],"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,502,535,502,537],"bd2cae51-e953-4f60-9c68-79fd0ab0dbbc",["D",1784056239433],[],[304,502,535,502,32],"f9ae41d9-43f3-4d72-ac25-e5ff303e87ef","b3107e7a-7fb7-11f1-b594-1607ee4eb77e",238,["D",1784056238688],[332,333,334],[304,502,535,502],"2acc39c9-ac03-40d5-a465-a4e0762786f6",237,["D",1784056238504],[331],[304,502,535],"087701f2-85c7-4143-bf9c-c982c16aabc3",137,["D",1783641873603],[330,335],[304,502],"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,573,565],"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,573,575],"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,573,583],"8a26a61d-d596-4a29-9050-a96215f95442",136,["D",1783641873401],[326,327,328],[304,573],"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,604,596],"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,604,606],"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,604,614],"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,604,622],"12a719bc-c079-4db1-bbdb-e6251ba56110",135,["D",1783641873285],[321,322,323,324],[304,604],["D",1783635592340],[320,325,329,339,340],[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":675,"_676":677,"_678":679,"_680":24,"_681":24,"_682":24,"_683":57,"_684":-5,"_685":-7,"_686":-7,"_687":61,"_688":24,"_689":24,"_690":-5,"_691":24,"_692":24,"_693":24,"_694":-5},"ENV",{"_646":647,"_648":649,"_650":88,"_651":652,"_653":654,"_655":656,"_657":658,"_659":660,"_661":662,"_663":664,"_665":666,"_667":668,"_669":670,"_671":672,"_673":674},"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 · v247