Open questions

?For reviewer

val-issue-tracker · Wireframes

Val Issue Tracker — app design

Low-fi structure pass over the tracker's four pages (edit issue mirrors the create form),\n restyled after the GitHub Issues interface per review: a slim top bar (Issues · Labels) on\n every screen, token search + stacked rows on the list, a metadata sidebar with per-section\n gears on detail, and a Write/Preview editor on create. Red dashed marks are the annotation\n layer, not proposed UI.

\n 5 wireframes\n Desktop 1280×800\n Lo-fi · monochrome\n Click any wireframe to zoom\n

\n\n \n

Flow

Screen flow

\n Solid arrows are navigation; labelled arrows note the trigger. Every mutating action\n on the detail page (close, reopen, label, assign, block, comment) POSTs and redirects back to the same page.

flow.svg1280×640

\n $\"Screen$ \n

\n\n \n

Screen 1 · Home

1.Issue list · `/`

\n GitHub-style landing page: slim top bar, a token search bar with the New issue\n button, and a list panel with Open/Closed tabs and stacked issue rows sorted by last activity.

\n issue-list.svg1280×800 · desktop

\n $\"Issue$ \n

Annotations

1 — Slim top bar replaces the sidebar: Issues and Labels tabs (active underlined), avatar and handle on the right. One shared Layout component across all screens; embeds compactly in host vals. Personal views (assigned/created by me) stay deferred.
2 — Token search bar replacing the separate filter fields: parse status: / assignee: tokens plus free text into the existing listIssues filters.
3 — Open/Closed tabs with count pills, replacing both the metric tiles and the status dropdown. Fits the strict two-state model.
4 — Label chips under each title carry the triage signal (ready-for-agent etc.) without a dedicated column.
5 — \"Blocked\" pill sits in the meta line before the issue number, as in GitHub.

\n Why this changes: adopts the GitHub list anatomy from review feedback.\n Stacked rows give titles a full line, make labels visible for triage scanning, and the\n token search collapses three filter controls into one input.

\n \n \n

\n\n \n

Screen 2 · Core

2.Issue detail · `/issue/:id`

\n GitHub-style detail under the shared top bar: title with number and edit pencil, a filled\n Open pill, the issue body as the first comment card, then the thread and composer; management\n lives in a right sidebar of hairline-divided sections, each with a gear.

\n issue-detail.svg1280×800 · desktop

\n $\"Issue$ \n

Annotations

1 — Filled Open pill (with state icon) plus outlined Blocked pill; the pencil beside the title goes to /issue/:id/edit.
2 — The body renders as the first comment card, with an Owner/role badge and \"edited\" provenance drawn from the events log.
3 — Sidebar sections (Assignees, Labels, Relationships, Delete) each with a gear that reveals the add/remove controls, instead of always-visible forms.
4 — \"Close issue\" with a reason chooser sits in the composer footer, GitHub-style: completed (default), not planned, duplicate. Reopen swaps in when closed.
5 — Relationships shows both edge directions with each blocker's open/closed state; adding an edge is rejected if it would create a cycle.

\n Why this changes: matches the GitHub issue view from review feedback.\n Reading and managing separate cleanly, and gear-reveals keep the sidebar quiet until you\n need to change something. Note the gear interaction needs a little client-side JS (or\n <details> disclosure) in an app that is currently zero-JS forms.

\n \n \n

\n\n \n

Screen 3 · Create

3.New issue · `/new`

\n GitHub-style \"Create new issue\": title and a Write/Preview markdown editor in the main\n column, assignees and labels in the right sidebar. The edit page (/issue/:id/edit)\n mirrors this with only title + body.

\n issue-new.svg1280×800 · desktop

\n $\"New$ \n

Annotations

1 — Write/Preview tabs on the description editor. Preview is marked roadmap: it activates once markdown rendering lands, and until then only Write shows.
2 — Assignees and labels move to a sidebar with gear-pickers; labels stay a curated set (picking, never typing). Handles remain unvalidated, noted in the sidebar.
3 — \"Create more\" checkbox for batch entry: on submit, redirect back to /new instead of the new issue.

\n Why this changes: matches the GitHub create screen from review feedback.\n The main column stays focused on writing; metadata moves out of the critical path.

\n \n \n

\n\n \n

Screen 4 · Admin

4.Labels · `/labels`

\n GitHub-style label management, shown with the inline create row expanded: New label\n reveals a form above the list (preview chip, name, color + swatch), and the panel lists one row\n per label with chip, hex color, open-issue count, and an overflow menu. Viewers see the list read-only.

\n labels.svg1280×800 · desktop

\n $\"Labels$ \n

Annotations

1 — Label creation, answered inline: \"New label\" (maintainer-only) expands this create row with a live preview chip, name input, and color input with swatch. It maps directly onto the existing POST /labels (name + color). Descriptions dropped per review.
2 — Open-issue count per label (one join query); clicking it filters the issue list to that label.
3 — Overflow menu holds edit (in-place row) and delete, gated to maintainers.

\n Why this changes: matches the GitHub labels screen from review feedback.\n Creation stays on this page rather than a separate screen, and the count makes delete's\n cascade visible before the click.

\n \n \n

\n\n \n

For reviewer

Open questions

JavaScript budget: The app is currently zero-JS server-rendered forms. Gear-pickers, token search highlighting, and Write/Preview tabs all want some client-side behavior. How much JS is acceptable, or should these degrade to <details> disclosures and plain form posts?
Token search: Parse status:/assignee: tokens server-side into the existing filters, or keep separate query params and just style one input?
Mobile: The tracker is server-rendered and embeddable; do we need dedicated 375px wireframes, or is a single responsive column acceptable?

\n\n

\n Wireframes follow the wireframe skill house style: black on white, 1.5pt strokes, 8px grid, type sizes 12/14/20/28. Red dashed annotations are the call-out layer only and not part of the proposed UI.\n

= {\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

Flow

Screens

Open questions

Screen flow

1.Issue list · /

Annotations

2.Issue detail · /issue/:id

Annotations

3.New issue · /new

Annotations

4.Labels · /labels

Annotations

Open questions

1.Issue list · `/`

2.Issue detail · `/issue/:id`

3.New issue · `/new`

4.Labels · `/labels`

Diff · v239