dira decision memory for AI coding agents
$dira whydec-0031
int-0002Zero-ceremony operation — one binary, no server, no daemonactive 2026-07-29
int-0003Replace the tool pile — kazi + dira + a subset of skills is the whole stackactive 2026-07-30
dec-0010A public read-only ledger renderer is the growth engine, and ships before the paid appsaccepted 2026-07-30
dec-0012Surfaces are server-rendered Go templates and static output — no SPA, no dira-operated hostaccepted 2026-07-30
dec-0031Mirror kazi's Astro + GitHub Pages site architecture for dira.sire.runaccepted 2026-08-14
✗ A bespoke framework or a dira-operated hosting servicekazi already proved the Astro + Tailwind + GitHub Pages + Playwright pipeline at kazi.sire.run (kazi ADR-0018): a static build, a custom domain via public/CNAME, a README-to-site coherence gate, and Playwright smoke tests.
✗ No public site — dira ui on localhost is the only rendered surfacedec-0010 already decided a public read-only renderer is the growth engine, specifically because dira ui alone leaves the project structurally invisible to a stranger with no link to land on.
int-0002Zero-ceremony operation — one binary, no server, no daemon
int-0003Replace the tool pile — kazi + dira + a subset of skills is the whole stack
dec-0010A public read-only ledger renderer is the growth engine, and ships before the paid apps
dec-0012Surfaces are server-rendered Go templates and static output — no SPA, no dira-operated host
dec-0031Mirror kazi's Astro + GitHub Pages site architecture for dira.sire.run
✗A bespoke framework or a dira-operated hosting service
✗No public site — dira ui on localhost is the only rendered surface
dec-0031 ◆ accepted 2026-08-14

Arising from dec-0010 — A public read-only ledger renderer is the growth engine, and ships before the paid apps

Mirror kazi's Astro + GitHub Pages site architecture for dira.sire.run

dira needs a public artifact a stranger can land on (dec-0010, note-0001's stranger path) without contradicting the static-output, no-hosted-tier constraint (dec-0012). kazi already solved this exact problem for kazi.sire.run: Astro + Tailwind static build, GitHub Pages via public/CNAME, a README <-> site coherence gate so the two surfaces cannot drift, and Playwright smoke tests gating every PR. docs/plan/website.md scopes the mirror: the site consumes dira's own `dira ui` output for its centerpiece (the /why pages, snapshotting dec-0001) rather than reimplementing a renderer, and the deploy job stays workflow_dispatch-only behind a pages-live environment until the founder wires DNS and activates it (docs/growth/site-activation.md).

Alternatives on record — 2

✗A bespoke framework or a dira-operated hosting servicerefused kazi already proved the Astro + Tailwind + GitHub Pages + Playwright pipeline at kazi.sire.run (kazi ADR-0018): a static build, a custom domain via public/CNAME, a README-to-site coherence gate, and Playwright smoke tests.

Reinventing that stack for dira would cost real setup time and, worse, risk a dira-operated host — which dec-0012 already rules out. Mirroring proven infrastructure is strictly cheaper than novelty here.

revisit ifkazi's site stack is itself replaced or found to have a structural flaw dira would inherit

✗No public site — dira ui on localhost is the only rendered surfacerefused dec-0010 already decided a public read-only renderer is the growth engine, specifically because dira ui alone leaves the project structurally invisible to a stranger with no link to land on.

Not building the site would re-litigate a settled decision.

Every decision in this repo is recorded like this one.

Keep your own →