{title}

[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_476":477,"_478":479},"routes/_app.x.$handle.$name",{"_100":99,"_33":45,"_108":90,"_27":109,"_13":14,"_110":-5,"_11":111,"_112":113,"_114":115,"_116":117,"_118":119,"_20":-5,"_120":-5,"_121":-5,"_122":25,"_123":124,"_125":59,"_126":-5,"_127":-5,"_128":129},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_43":44,"_33":45,"_38":46,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":-5,"_73":74,"_75":74,"_76":77,"_78":77,"_79":77,"_80":74,"_81":74,"_82":83,"_84":85,"_86":87,"_88":25},"version",158,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":25,"_27":28,"_29":30},"file",{"_31":32,"_33":34,"_35":20,"_36":37,"_38":39,"_40":14,"_41":42,"_24":25},"previous",{"_31":32,"_33":34,"_35":20,"_36":37},"deleted",false,"deletedHere","path","docs/issues/richer-data-model/PRD.md","latestPath","docs/issues/richer-data-model/spec.md","fileId","eebd1596-7bf2-11f1-ab8e-1607ee4eb77e","name","PRD.md","fileType","content","# 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 ∈ {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.","createdAt",["D",1783650557226],"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",{"_100":99,"_107":103},"org",{"_100":99,"_101":-5,"_102":103,"_18":55,"_104":105,"_106":25},"branch",{"_13":89,"_33":90,"_43":42,"_91":44,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":45,"_98":99},"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",{"_43":44,"_33":45,"_38":471,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69,"_70":472,"_72":-5,"_73":74,"_75":74,"_76":77,"_78":77,"_79":77,"_80":74,"_81":74,"_82":473,"_84":474,"_86":475,"_88":25},"tree",[279,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309],"files",[279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309],"counts",{"_268":63,"_269":270,"_271":63,"_272":273,"_274":275},"contents",[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_43":261,"_33":262,"_31":263,"_149":-5,"_41":42,"_40":264,"_151":59,"_38":265,"_13":63,"_35":266,"_36":-5,"_24":25,"_156":-5,"_27":267},{"_43":254,"_33":255,"_31":256,"_149":-5,"_41":42,"_40":257,"_151":59,"_38":258,"_13":63,"_35":20,"_36":259,"_24":25,"_156":-5,"_27":260},{"_43":248,"_33":249,"_31":250,"_149":-5,"_41":42,"_40":251,"_151":25,"_38":252,"_13":63,"_35":20,"_36":246,"_24":25,"_156":-5,"_27":253},{"_43":241,"_33":242,"_31":243,"_149":-5,"_41":42,"_40":244,"_151":25,"_38":245,"_13":63,"_35":20,"_36":246,"_24":25,"_156":-5,"_27":247},{"_43":234,"_33":235,"_31":236,"_149":-5,"_41":42,"_40":237,"_151":25,"_38":238,"_13":63,"_35":20,"_36":239,"_24":25,"_156":-5,"_27":240},{"_43":226,"_33":227,"_31":228,"_149":-5,"_41":42,"_40":229,"_151":25,"_38":230,"_13":231,"_35":20,"_36":232,"_24":25,"_156":-5,"_27":233},{"_43":219,"_33":220,"_31":221,"_149":-5,"_41":42,"_40":222,"_151":25,"_38":223,"_13":63,"_35":154,"_36":224,"_24":25,"_156":-5,"_27":225},{"_43":211,"_33":212,"_31":213,"_149":-5,"_41":42,"_40":214,"_151":25,"_38":215,"_13":216,"_35":154,"_36":217,"_24":25,"_156":-5,"_27":218},{"_43":204,"_33":205,"_31":206,"_149":-5,"_41":42,"_40":207,"_151":25,"_38":208,"_13":63,"_35":20,"_36":209,"_24":25,"_156":-5,"_27":210},{"_43":196,"_33":197,"_31":198,"_149":-5,"_41":42,"_40":199,"_151":25,"_38":200,"_13":201,"_35":154,"_36":202,"_24":25,"_156":-5,"_27":203},{"_43":188,"_33":189,"_31":190,"_149":-5,"_41":42,"_40":191,"_151":25,"_38":192,"_13":193,"_35":154,"_36":194,"_24":25,"_156":-5,"_27":195},{"_43":181,"_33":182,"_31":183,"_149":-5,"_41":42,"_40":184,"_151":25,"_38":185,"_13":63,"_35":20,"_36":186,"_24":25,"_156":-5,"_27":187},{"_43":173,"_33":174,"_31":175,"_149":-5,"_41":42,"_40":176,"_151":25,"_38":177,"_13":178,"_35":154,"_36":179,"_24":25,"_156":-5,"_27":180},{"_43":165,"_33":166,"_31":57,"_149":-5,"_41":42,"_40":167,"_151":25,"_38":168,"_13":169,"_35":170,"_36":171,"_24":25,"_156":-5,"_27":172},{"_43":158,"_33":159,"_31":160,"_149":-5,"_41":42,"_40":153,"_151":25,"_38":161,"_13":162,"_35":154,"_36":163,"_24":25,"_156":-5,"_27":164},{"_43":146,"_33":147,"_31":148,"_149":-5,"_41":42,"_40":150,"_151":25,"_38":152,"_13":153,"_35":154,"_36":155,"_24":25,"_156":-5,"_27":157},"2e20d1fd-693a-4de7-9d91-071f7adc7b7a","ui.tsx","fca19e20-7b48-11f1-8cf9-1607ee4eb77e","parentId",122,"latest",["D",1783574778713],30,"script","/** @jsxImportSource npm:hono@4.6.14/jsx */\nimport type { FC, PropsWithChildren } from \"npm:hono@4.6.14/jsx\";\nimport type { IssuePriority, IssueStatus } from \"./db.ts\";\n\n// ---------------------------------------------------------------------------\n// Design tokens\n// ---------------------------------------------------------------------------\n\nexport const FIELD =\n\t\"bg-[#1f232c] border border-[#2a2f3a] rounded-md h-10 pl-3.5 pr-10 text-sm leading-none font-medium text-[#e6e9ef] focus:outline-none focus:border-[#6ea8fe] appearance-none\";\n\n// text-sm/leading-none/appearance-none pin font metrics and native chrome\n// explicitly — \n\t);\n};\n\n// A \n\t\t{/* right-[13px] centers the 16px chevron box within FIELD's 40px right\n\t\t\tpadding: (40 - 16) / 2 = 12px from the inner edge, + 1px because the\n\t\t\toffset is measured from the outer border edge = 13px. This equalizes\n\t\t\tthe text→chevron gap with the chevron→edge gap. */}\n\t\t\n\t\t\t\n\t\t\n\t\n);\n\nexport const Banner: FC<{ kind: \"ok\" | \"err\"; msg: string }> = ({\n\tkind,\n\tmsg,\n}) => (\n\t\n\t\t{msg}\n\t\n);\n\nexport const StatusBadge: FC<{ status: IssueStatus }> = ({ status }) => (\n\t\n\t\t{STATUS_LABELS[status]}\n\t\n);\n\nexport const PriorityBadge: FC<{ priority: IssuePriority }> = ({\n\tpriority,\n}) => (\n\t\n\t\t{PRIORITY_LABELS[priority]}\n\t\n);\n\nexport const LabelTag: FC<{ label: string }> = ({ label }) => (\n\t\n\t\t{label}\n\t\n);\n","label",[147],"cd8a9ea8-1579-4629-9a43-c9a3525477d5","mod.ts","d1e3fc5c-7b3c-11f1-af1c-1607ee4eb77e",["D",1783568883064],11,"export {\n\tcreateIssueTracker,\n\tdefault,\n\ttype IssueTrackerOptions,\n} from \"./app.tsx\";\n",[159],"9e03307b-2c34-410f-9821-d89c7b4234b4","main.ts",155,["D",1783650443882],9,"http","import { createIssueTracker } 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 { createIssueTracker } from \"https://esm.town/v/nbbaier/val-issue-tracker/mod.ts\";\n * export default createIssueTracker({ 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 createIssueTracker({});",[166],"17e2256d-d27b-4705-aa51-8a95e016e3e4","layout.tsx","fd6015ee-7b48-11f1-bafe-1607ee4eb77e",107,["D",1783574315459],2,"/** @jsxImportSource npm:hono@4.6.14/jsx */\nimport type { FC, PropsWithChildren } from \"npm:hono@4.6.14/jsx\";\n\nexport const Layout: FC<\n\tPropsWithChildren<{\n\t\ttitle: string;\n\t\tuser?: string | null;\n\t\tauth?: boolean;\n\t}>\n> = ({ title, user, auth = true, children }) => (\n\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\t{title}\n\t\t\t

Diff · v158