Work log: Diktura - April 3, 2026

What shipped today

The session started with Phase 3 (roadmap) and ended with a fundamentally different product vision.

On the engineering side, the entire roadmap feature was built from scratch in three tickets: kanban-style list page grouped by status (#90), detail page with inline editing (#91), and public widget voting API with GET and POST endpoints (#92). That closed out the Rails port — Diktura now has feature parity across feedback, changelog, broadcasts, app users, roadmap, and voting. All of it backed by the same vertical-slice pattern: server components, server actions with auth checks, loading skeletons, and tests.

A scout run found and filed five issues. Four were fixed in the same session: unbounded roadmap query capped at 200 items (#93), 16 changelog server action tests filling the last test gap (#94), responsive kanban grid that was hardcoded to 4 columns (#95), and loading skeletons for 5 dashboard pages that were showing blank during data fetches (#96). The fifth (rate limiting on widget APIs) was backlogged — it’s a pre-deployment concern but not blocking.

The landing page got replaced — the dev scaffold (“Eidos Port” phases) became a real SaaS marketing page with nav, hero, feature cards, CTA, and footer (#98). The roadmap link was added to the authenticated nav (#99). And the login page went from a placeholder to a working Supabase auth flow with sign-in, sign-up, forgot password, and email callback (#100).

The biggest shift was product vision. Paul clarified that Diktura isn’t “feedback + roadmap + changelog” — it’s everything that touches a user. Support, KB, inbound email, inbound SMS, newsletter, Sentry errors, PostHog analytics — all attached to one customer identity across multiple apps. CRM delegated to Brevo. PRODUCT.md was rewritten to reflect this.

Infrastructure: the Railway engine was fixed. The DATABASE_URL env var was missing, and once set, the direct Supabase host was IPv6-only (unreachable from Railway). The fix was using the Supabase connection pooler at aws-1-us-east-2.pooler.supabase.com — not aws-0 as the docs suggest. Engine is now running and polling.

Completed

• #90 — Roadmap list page and server actions (9 tests)
• #91 — Roadmap detail page with inline editing
• #92 — Widget roadmap voting API (14 tests)
• #93 — Roadmap list page fetches all items without pagination
• #94 — Add tests for changelog server actions (16 tests)
• #95 — Roadmap kanban grid breaks on mobile
• #96 — Missing loading states on 5 dashboard pages
• #98 — Public website (SaaS landing page)
• #99 — Add roadmap link to app nav
• #100 — Implement Supabase auth sign-in flow

Carry-over

• #101 — Link Next.js frontend to Vercel (ready-for-prep, filed during session)
• #97 — Rate limiting on widget APIs (backlogged)

Risks

• diktura.io still not deployed. New stack is feature-complete and auth works locally, but no Vercel deployment yet. #101 is the next step.
• Railway pooler URL is non-obvious. The Supabase pooler host for Ohio projects is aws-1-us-east-2, not the aws-0-us-east-1 that docs and auto-detection suggest. Documented in this work log but not in DECISIONS.md — should be added if it comes up again.
• No integration tests. All 83 tests are unit tests with mocked Supabase. First real deployment = first real test against production data.

Flags and watch-outs

• The SUPABASE_SERVICE_ROLE_KEY and feedback_widget_token migration both need to be in place before widget endpoints work in production.
• Dev server port changed from 3001 to 3007 in package.json.
• PRODUCT.md was substantially rewritten — the “port” framing is gone, replaced with “unified customer interaction platform.”
• Railway engine is live and polling on production Supabase via pooler connection.

Next session

1. Deploy to Vercel (#101) — link the project, set env vars, push. This is the last barrier to a live product.
2. Test auth flow against real Supabase — sign up, confirm email, sign in, access dashboard. Needs to work end-to-end.
3. Update ROADMAP.md — the phase structure needs rethinking now that the vision expanded. Phases 1-4 are done. Phase 5 (cutover) needs to include Vercel deployment. New phases needed for support, KB, inbound channels.
4. Consider support/tickets as next feature — PRODUCT.md lists it as the highest-leverage next build. Needs a data model and decomposition issue.