[dashboards] open-brain-dashboard-next: type Thought.id as string for UUID

[tswicegood]

Contribution Type

• Dashboard (/dashboards)

What does this do?

Fixes a navigation bug: every Browse → Detail click in the dashboard 404'd because app/thoughts/[id]/page.tsx:29 ran parseInt(id, 10) on the URL param, but the upstream thoughts.id column is UUID. UUIDs parse to NaN, the isNaN guard fired, and the page returned 404. Confirmed live before this change; confirmed fixed after.

This is the dashboard-side counterpart to the type mismatch I documented as Known Limitation #1 in PR #239 (the REST gateway). The gateway has been UUID-native the whole time — c.req.param("id") flows straight to .eq("id", id) and Supabase coerces it correctly. The dashboard's Thought.id: number was the side that needed fixing.

Purely a type-correctness change. Vercel deploys benefit equally — no runtime behavior change beyond Detail navigation now working.

Changes

• lib/types.ts — Thought.id, Reflection.thought_id, DuplicatePair.thought_id_a/_b, AddToBrainResult.thought_id → string
• lib/api.ts — fetchThought, updateThought, deleteThought, fetchReflections parameter types; CaptureResult.thought_id and updateThought response shape
• app/thoughts/[id]/page.tsx — drop parseInt/isNaN, pass route param straight through
• components/ConnectionsPanel.tsx, ReflectionComposer.tsx — prop types
• components/Kanban{Board,Card,CardModal,Column}.tsx — every thoughtId in handler signatures, plus the active.id as string cast in handleDragEnd
• app/audit/page.tsx — bulk-select Set<number> → Set<string>
• API proxy routes (audit/delete, duplicates/resolve, kanban/{delete,update}) — typeof checks and id array element types

What stays as number

• IngestionJob.id, IngestionJob.job_id, IngestionItem.{id,job_id}, AddToBrainResult.job_id — the ingestion tables are BIGSERIAL, not UUID
• Reflection.id — would be reflections-table PK; no schema for that table ships in the repo yet (Known Limitation Add non-dev contribution path, contributor ladder, and CONTRIBUTORS.md #3 from [integrations] open-brain-rest — Cloudflare Worker REST gateway for the Next.js dashboard #239)
• All numeric scalars (importance, confidence, count)

Tested end-to-end

Live deploy on Cloudflare Workers (REST gateway from #239 backed by my Open Brain Supabase):

• ✅ Browse → click thought → Detail page loads with full content
• ✅ Edit thought (content / type / importance), save, refresh persists
• ✅ Connections panel renders, links navigate to working Detail pages
• ✅ Workflow/Kanban drag-and-drop, priority dot, modal save
• ✅ Audit page bulk-select
• ✅ Add to Brain quick capture
• ✅ No NaN console errors, no type-coercion runtime errors

Requirements

None — pure TypeScript / control-flow change. No new dependencies. tsc --noEmit passes; OpenNext build passes.

Checklist

• I've read CONTRIBUTING.md
• No credentials, API keys, or secrets are included
• I tested this on my own Open Brain instance (live Cloudflare Workers deploy, exercised the affected pages)

[tswicegood]

@alanshurafa — wanted to flag something puzzling in case you have context that'd help, since you originally landed this dashboard:

The dashboard's lib/types.ts has Thought.id: number (with uuid?: string as a separate optional field), and app/thoughts/[id]/page.tsx:29 runs parseInt(id, 10) on the route param. But the canonical thoughts.id column in docs/01-getting-started.md:67-72 is uuid default gen_random_uuid() primary key. UUIDs parse to NaN, the isNaN guard fires, and Detail navigation 404s. From git log, this shape has been there since the dashboard's initial commit (a082d26).

What I can't tell from the code alone is how it got that way — whether id/uuid were intended for two different purposes, whether there was a different backend in mind that returned numeric ids, or something else. The uuid?: string field next to id: number looks intentional rather than accidental, which is what makes me unsure.

If you've got context on the original intent, I'd love to hear it before this lands — happy to revise the approach. If the change as-is is fine, no action needed.

[alanshurafa]

Thanks for flagging this carefully. No hidden intent the id: number + separate uuid?: string shape was a holdover from an earlier prototype against a different schema, not a deliberate two purpose design. By the time the dashboard landed, the canonical column was already UUID; the types just never got reconciled, and Detail navigation apparently never got clicked through on a real instance before merge.

Your fix is the right shape id: string everywhere except the genuinely numeric BIGSERIAL ingestion fields, which matches what's actually in the DB. Please land it as is.