{title}

[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_441":442,"_443":444},"routes/_app.x.$handle.$name",{"_99":98,"_32":44,"_107":89,"_26":108,"_13":14,"_109":-5,"_11":110,"_111":112,"_113":114,"_115":116,"_117":118,"_20":-5,"_119":-5,"_120":-5,"_121":24,"_122":123,"_124":58,"_125":-5,"_126":-5,"_127":128},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_42":43,"_32":44,"_37":45,"_46":-5,"_47":24,"_48":49,"_50":49,"_51":52,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70,"_71":-5,"_72":73,"_74":73,"_75":76,"_77":76,"_78":76,"_79":73,"_80":73,"_81":82,"_83":84,"_85":86,"_87":24},"version",148,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":-7,"_23":24,"_25":24,"_26":27,"_28":29},"file",{"_30":31,"_32":33,"_34":20,"_35":36,"_37":38,"_39":14,"_40":41,"_23":24},"previous","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, or\nbe queried cleanly. There's no way to express that one issue blocks another. There\nis no history: once a label is removed or an assignee dropped, the fact that it was\never there is gone, and there's no record of who changed what. The maintainer wants\na GitHub-flavoured model that captures these relationships and a full audit trail.\n\n## Solution\n\nReshape the tracker's schema to mirror GitHub's issue model where it earns its keep,\nand add first-class structure for the things the maintainer actually uses:\n\n- Drop priority entirely and collapse status to `open` / `closed`, with a nullable\n `state_reason` (`completed` / `not_planned` / `duplicate` / `reopened`) carrying the\n nuance — so \"closed as done\" and \"closed as not planned\" are distinguishable.\n- Promote labels from a JSON string to curated **Label** entities (name + colour),\n applied to issues through a join, seeded with a small default set on first install.\n- Make assignees a *set* of Val Town users via a join, instead of a single string.\n- Add directed **blocking relationships** between issues, kept as a strict DAG, with\n \"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 truth for\n provenance (\"who did what, when\") and full state history, from which auditability is\n derived. Live tables hold only current state.\n- Treat issue and comment bodies as markdown (a rendering contract; no storage 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 reflects that I never triage by priority.\n2. As a maintainer, I want status to be exactly `open` or `closed`, so that there is no unwanted intermediate state to maintain.\n3. As a maintainer, I want to close an issue as `completed`, so that I can record that the work was actually done.\n4. As a maintainer, I want to close an issue as `not_planned`, so that I can 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 record that it was already tracked elsewhere.\n6. As a maintainer, I want reopening an issue to mark its reason as `reopened`, 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 (e.g. open + completed), so that the data can never represent an impossible state.\n8. As a maintainer, I want `state_reason` to be set automatically by the close/reopen/create actions, so that I can't forget to keep it consistent with status.\n9. As a maintainer, I want labels to be real entities with names and colours, so 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 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 stays accurate.\n12. As a maintainer, I want a fresh install to come with a default set of labels (`bug`, `enhancement`, `documentation`, `question`, `duplicate`), so that the tracker is usable immediately.\n13. As a maintainer, I want labels I delete to stay deleted across restarts, so 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 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 every issue carrying it updates at once.\n16. As a maintainer, I want an issue to have zero or more assignees, so that 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 ownership can change over time.\n18. As a maintainer, I want to ask \"what is assigned to me?\", so that I can find my work without scanning every issue.\n19. As a maintainer, I want to declare that one issue blocks another, so that I can express dependencies.\n20. As a maintainer, I want to view an issue's blockers and the issues it 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 blockers is still open, so that blocked-ness is always accurate without my maintaining a flag.\n22. As a maintainer, I want closing a blocker to automatically unblock its 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 being blocked is informational and never traps me.\n24. As a maintainer, I want the system to reject an issue blocking itself, so that nonsensical edges can't exist.\n25. As a maintainer, I want the system to reject any edge that would create a 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 correct a dependency I no longer want.\n27. As a maintainer, I want issue and comment bodies treated as markdown, so 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 correct or refine it after creation.\n29. As a maintainer, I want to edit a comment, so that I can fix mistakes in my notes.\n30. As a maintainer, I want to delete a comment, so that I can remove notes that no longer belong.\n31. As an auditor, I want every create, update, and delete recorded as an event with the actor and timestamp, so that I can reconstruct who changed what and when.\n32. As an auditor, I want each field change recorded with its before and after 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 recorded as events, so that removals are visible even though the current-state row is gone.\n34. As an auditor, I want a deleted entity's final state captured in its deletion event, so that a hard delete still leaves a complete record of what was lost.\n35. As an auditor, I want a created entity's initial state captured in its creation event, so that history can be replayed forward from a self-contained starting point.\n36. As an auditor, I want to reconstruct an entity's state at any past point, so 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 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 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 new schema, so that I lose no data when upgrading.\n40. As an existing deployment owner, I want any `in_progress` issue moved to `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 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 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 statuses, `state_reason`, label/assignee/block operations), so that non-interactive callers drive the new model correctly.\n44. As an agent, I want the API convention doc updated to the new schema, so that I'm not working from the outdated contract.\n45. As a maintainer, I want any change to an issue's labels, assignees, blocks, or comments to bump the issue's `updated_at`, so that \"last activity\" 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`): types,\nschema creation/migration, and all query functions. The Hono JSON API and the HTML UI\nare consumers that will be updated to match — both currently duplicate schema knowledge\n(status/priority constants, label parse/serialize) that must be reconciled to the new\nmodel. The library's public entry point and table-prefixing convention are unchanged.\n\n**Removed fields.** Priority is removed entirely (column, type, filters, create/update\npaths) — faithful to GitHub, which has no first-class priority. The `in_progress` status\nis removed.\n\n**Status + state_reason.** `status` is `open` | `closed`. A nullable `state_reason`\nholds `completed` / `not_planned` / `duplicate` (with `closed`) or `reopened` (with\n`open`), or `null`. It is auto-managed: create → `null`; close → chosen reason\n(`completed` default); reopen → `reopened`. A `CHECK` constraint enforces the valid\npairings so an incoherent row is impossible. (ADR context: mirrors GitHub; \"not planned\"\nis not a third state.)\n\n**Body.** The issue's `description` is renamed to `body` so Issue and Comment share one\nterm, matching GitHub. Bodies remain `TEXT`; markdown is a rendering contract, not a\nstorage change.\n\n**Labels (ADR 0001).** A **Label** is a curated entity: `id`, unique `name`, `color`.\nApplied via an issue↔label join (bare tuple), cascade-deleting both sides; deleting an\nin-use label is allowed and simply removes the join rows. A default set (`bug`,\n`enhancement`, `documentation`, `question`, `duplicate`) is seeded **exactly once, at\nthe moment the labels table is first created**, never re-seeded — so user deletions\nsurvive. Labels are editable (rename/recolour in one place).\n\n**Assignees.** Multi-valued set of Val Town users, stored as a bare issue↔user-handle\njoin tuple. No local users table; identity is the handle. Supports \"assigned to me\"\nqueries in both directions.\n\n**Blocking (ADR 0002).** A directed edge `blocker → blocked`, stored once with a unique\npair constraint and cascade on issue delete. \"Blocks\" and \"blocked by\" are the same edge\nread from opposite ends. The graph is a **strict DAG**: on insert, reject if the target\ncan already reach the source (reachability check via recursive query), which covers\nself-edges, direct reciprocals, and longer cycles alike — deliberately stricter than\nGitHub. \"Blocked\" is **derived, never stored**: an issue is blocked iff any blocker is\nstill `open`; blocked-ness is informational and does not prevent closing.\n\n**Audit + provenance (ADR 0003 as amended, ADR 0004).** Entities (Issue, Comment, Label)\nkeep only `created_at` + `updated_at` columns (for hot-path listing / \"last activity\"\nsorting). There are **no `*_by` columns anywhere**; actor/provenance lives solely in the\nevents log. Link rows carry no audit columns. Every entity is editable, including\ncomments (the old comment `author` column is gone; the author is derived from the\n`comment.created` event).\n\n**Events log (ADR 0004).** One append-only, polymorphic table with roughly this shape:\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- `*.created` → full initial-state snapshot.\n- `*.deleted` → full final-state snapshot (entities are hard-deleted; the event 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 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). No separate verb or link entity type.\n- One event per changed field: closing emits two events (`status` and `state_reason`)\n sharing one actor and timestamp; a \"closed as not planned\" timeline line is a\n read-time grouping by (actor, timestamp).\n- A block edge writes **one** event, on the acting issue; the reverse \"blocked by\" view\n is derived by querying events whose `to` references the issue.\n\n**Identity / numbering.** Issues keep the autoincrement `id` as their friendly `#N` —\nno separate opaque id, since a single scoped database per host makes `id` a clean\nper-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 bumps\nthat issue's `updated_at` (in addition to emitting an event).\n\n**Migration.** This is a breaking change against ~3 existing deployments (this val + two\ntest vals). Migration must: rename `description` → `body`; drop `priority`; remap any\n`in_progress` issue to `open`; lift each existing JSON `labels` array into the new label\nentities (creating labels as needed) and issue↔label join rows; move any existing single\n`assignee` into the assignee join; and backfill a synthetic `*.created` event (and any\nneeded state) for existing rows so nothing is left provenance-less. Migration runs within\nthe existing 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 statuses,\n`state_reason` on close/reopen, and label / assignee / block operations. The convention\ndoc `docs/issue-tracker-valtown.md` is rewritten to the new schema (it currently\ndocuments 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 (`db.ts`).\nThere is no existing test suite, so this is the first — no prior art to mirror; establish\nthe pattern here. Tests run against a scoped SQLite database and exercise the exported\nfunctions directly, with no HTTP or UI in the loop.\n\n**What makes a good test here.** Assert *external behaviour* of the data layer — the\nobservable outcomes of calling its functions — not internal implementation (not specific\nSQL, indexes, or private helpers). A good test states a domain rule and checks it holds.\n\n**Behaviours to cover:**\n- Status/reason: create leaves reason null; each close reason sets status closed with the\n right reason; reopen sets `reopened`; the `CHECK` constraint rejects an incoherent pair.\n- Labels: default set seeded on first creation; deletions survive a re-init (seed-once);\n applying/removing labels; deleting an in-use label removes its join rows.\n- Assignees: add/remove; \"assigned to me\" returns the right issues.\n- Blocking: self-edge rejected; direct reciprocal rejected; longer cycle rejected; a valid\n edge accepted; \"blocked\" derived from open blockers; closing a blocker unblocks\n dependents; a blocked issue can still be closed.\n- Events: create/update/delete emit events with correct type, actor, and payload grammar\n (created/deleted snapshots, update deltas, association `null ↔ value`, one-event-per-\n field on close, single event on block add); deleted-entity 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 labels lifted\n into tables, `description` readable as `body`, and existing rows gain creation events;\n 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 timeline\n (data supports both; presentation is deferred — see `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 + 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 door open\n 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`; use that\n 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 until this\n work rewrites it, so nothing points agents at the new schema before it exists.\n","createdAt",["D",1783641874216],"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",{"_99":98,"_106":102},"org",{"_99":98,"_100":-5,"_101":102,"_18":54,"_103":104,"_105":24},"branch",{"_13":88,"_32":89,"_42":41,"_90":43,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":44,"_97":98},"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",{"_42":43,"_32":44,"_37":436,"_46":-5,"_47":24,"_48":49,"_50":49,"_51":52,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68,"_69":437,"_71":-5,"_72":73,"_74":73,"_75":76,"_77":76,"_78":76,"_79":73,"_80":73,"_81":438,"_83":439,"_85":440,"_87":24},"tree",[261,276,277,278,279,280,281,282,283,284,285,286,287,288],"files",[261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288],"counts",{"_250":62,"_251":252,"_253":62,"_254":255,"_256":257},"contents",[129,130,131,132,133,134,135,136,137,138,139,140,141,142],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_42":243,"_32":244,"_30":245,"_146":-5,"_40":41,"_39":246,"_148":58,"_37":247,"_13":62,"_34":248,"_35":-5,"_23":24,"_153":-5,"_26":249},{"_42":236,"_32":237,"_30":238,"_146":-5,"_40":41,"_39":239,"_148":58,"_37":240,"_13":62,"_34":20,"_35":241,"_23":24,"_153":-5,"_26":242},{"_42":229,"_32":230,"_30":231,"_146":-5,"_40":41,"_39":232,"_148":24,"_37":233,"_13":62,"_34":20,"_35":234,"_23":24,"_153":-5,"_26":235},{"_42":221,"_32":222,"_30":223,"_146":-5,"_40":41,"_39":224,"_148":24,"_37":225,"_13":226,"_34":20,"_35":227,"_23":24,"_153":-5,"_26":228},{"_42":214,"_32":215,"_30":216,"_146":-5,"_40":41,"_39":217,"_148":24,"_37":218,"_13":62,"_34":151,"_35":219,"_23":24,"_153":-5,"_26":220},{"_42":207,"_32":208,"_30":209,"_146":-5,"_40":41,"_39":210,"_148":24,"_37":211,"_13":166,"_34":151,"_35":212,"_23":24,"_153":-5,"_26":213},{"_42":200,"_32":201,"_30":202,"_146":-5,"_40":41,"_39":203,"_148":24,"_37":204,"_13":62,"_34":20,"_35":205,"_23":24,"_153":-5,"_26":206},{"_42":192,"_32":193,"_30":194,"_146":-5,"_40":41,"_39":195,"_148":24,"_37":196,"_13":197,"_34":151,"_35":198,"_23":24,"_153":-5,"_26":199},{"_42":185,"_32":186,"_30":187,"_146":-5,"_40":41,"_39":188,"_148":24,"_37":189,"_13":175,"_34":151,"_35":190,"_23":24,"_153":-5,"_26":191},{"_42":178,"_32":179,"_30":180,"_146":-5,"_40":41,"_39":181,"_148":24,"_37":182,"_13":62,"_34":20,"_35":183,"_23":24,"_153":-5,"_26":184},{"_42":170,"_32":171,"_30":172,"_146":-5,"_40":41,"_39":173,"_148":24,"_37":174,"_13":175,"_34":151,"_35":176,"_23":24,"_153":-5,"_26":177},{"_42":162,"_32":163,"_30":56,"_146":-5,"_40":41,"_39":164,"_148":24,"_37":165,"_13":166,"_34":167,"_35":168,"_23":24,"_153":-5,"_26":169},{"_42":155,"_32":156,"_30":157,"_146":-5,"_40":41,"_39":150,"_148":24,"_37":158,"_13":159,"_34":151,"_35":160,"_23":24,"_153":-5,"_26":161},{"_42":143,"_32":144,"_30":145,"_146":-5,"_40":41,"_39":147,"_148":24,"_37":149,"_13":150,"_34":151,"_35":152,"_23":24,"_153":-5,"_26":154},"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",[144],"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",[156],"436eb8dd-247c-49b2-828b-efc41b7321e8","main.ts",63,["D",1783571917437],7,"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({});\n",[163],"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 · v148