diraArising from int-0003 — Replace the tool pile — kazi + dira + a subset of skills is the whole stack
A public read-only ledger renderer is the growth engine, and ships before the paid apps
Any **public** `.dira/` ledger can be rendered as a browsable why-graph by a read-only web surface. This is dira's distribution mechanism, and it is promoted ahead of the paid apps in the roadmap.
**Serving mechanism, added 2026-07-30 (`dec-0012`):** `dira render` emits static HTML the user deploys themselves. This entry originally settled *that* the renderer ships and stores nothing, but never said what serves it — a gap the E6 planner caught. There is no dira-operated host, so cst-0004 holds by construction.
**Why this is the growth engine.** dira has three structural growth problems, all of them consequences of decisions that are correct on their own terms:
| Problem | Root | Answer | |---|---|---| | Invisible by design | int-0001's "you never open a file" | the ledger renders — every adopting repo becomes a linkable artifact | | Delayed value | the payoff is week 12 benefiting from week 1 | lead with retrospective import, not prospective logging | | Fatal empty state | a fresh ledger has nothing to say | `dira init` must never produce an empty ledger |
The loop the renderer closes is architecturally free, because the ledger is *already* committed to git (dec-0002) and GitHub is *already* the sync layer (dec-0005):
``` point dira at a repo → decision graph + contradiction report in 60s (day-1 value) → hooks keep it current at zero effort (retention) → the ledger is committed, public in OSS repos (artifact) → it renders as a why-graph a stranger can read (distribution) → they want it for their own repo (acquisition) ```
**This does not violate cst-0004, and the distinction must be stated wherever the renderer is mentioned.** That constraint forbids dira *requiring* a network service to function. The renderer is strictly additive and strictly read-only: it stores nothing, owns no user data, requires no account to view, and the CLI behaves identically whether it exists or not. If it disappeared tomorrow, no user loses a capability. An audience that checks this claim will check it, so the honesty has to be structural rather than reassuring.
**Two consequences that bind other work.**
1. **qst-0003 is promoted from a deferred risk to a launch blocker.** The import path is the acquisition moment: pointing dira at an existing repo and getting back a real graph plus the contradictions already in it. If import yields entries with empty `alternatives` arrays, the first impression is an empty shell at exactly the moment a user decides whether this is real. The quality of ADR/history import is now a growth variable, not a convenience. 2. **`dira init` may never produce an empty ledger.** Import and interview are the product's first experience, not setup that precedes it.
**The honest limit.** This buys compounding organic distribution, not virality. There is no invite mechanic, no social graph, and no k-factor in a single-player developer tool. Published artifacts inside a fast-growing ecosystem compound; they do not go viral. Internal targets and copy should both say so — see [`.agents/product-marketing.md`](../../.agents/product-marketing.md) §7.
Alternatives on record — 4
✗Keep every surface local — `dira ui` on localhost and nothing hosted, everrefused It leaves dira structurally invisible.
The product's core promise is that you never open a file, which also means there is nothing to screenshot, nothing to link to, and no page for a stranger to land on. A tool with no artifact has no organic distribution, and a solo maintainer has no other kind. The purest reading of the no-servers principle would win the argument and lose the product.
revisit ifsome other distribution surface emerges that does not require rendering
✗Build the paid apps first and let them carry the storyrefused Inverts the funnel.
The apps are bought by people who already use dira; they cannot create the awareness that produces those people. Monetizing before there is an audience optimizes the wrong end.
✗A hosted service that stores ledgers for usersrefused Violates cst-0004 outright and destroys the strongest claim dira can make to this audience — that its data never touches our servers.
The renderer must read what is already public in the user's own repo and store nothing.
✗Rely on GitHub's own markdown rendering of `.dira/entries/`refused Free, and genuinely the fallback — the files are readable markdown by design (dec-0002).
But a folder of 40 frontmatter-topped files renders as a file list, not a why-graph. The edges, the supersession chains, and the derived status are exactly what makes the ledger worth looking at, and GitHub shows none of them.
revisit ifnever as the primary surface; it remains the permanent no-JavaScript floor