Repository documentation

Deck authoring prompt

Create a visual, evidence-led Google Slides presentation for Literate-AI that serves product, program, engineering, and executive audiences through one cumulative narrative.

Remove audience-specific sections and repeated restatements of the same lifecycle claim. Let product results, shown artifacts, and operating consequences carry the story. Make the deck aspirational and investment-oriented: on the 1.1 scheduler, shared-cache, Debian-package, native-acceptance, worktree-placement, repair, cross-host worker, Mix, and forge foundation, 1.3 adds reviewed original-source first binding, target-bound Python source projection, FreeBSD worker and target foundations, native SDK tree custody, and retained execution hardening. Complete FreeBSD platform admission, Windows ARM64 realization, production DAG/LAN-cache qualification, remote package custody, and remaining retained-project native acceptance stay outside the completed claims.

Carry mechanism with every claim. The audience must be able to reconstruct how the system works, not only that its authors believe it works. Show the durable authority itself—a real specification excerpt beside its generated interface, a real execution plan, a real receipt. Explain the identities a generation key binds and deliberately refuses to bind, the invalidation blast radius that follows, the layered provider-before-consumer scheduling, the exact predicate under which generated source may be reused, what happens when a gate fails, and what never crosses the model-egress boundary. Group these as a labeled technical sequence.

Keep hero-image slides that carry only a headline and a paragraph to a clear minority. They punctuate the argument; they are not the argument.

Use only current Literate-AI implementation evidence. Show the real sample applications, arbitrary Component DAG, exact CLI surface, and parallel cross-platform fan-out. Do not use a specification-only successor project as product implementation evidence.

For the 1.3.0 edition, keep the implemented 1.2, 1.1, and 1.0 operator/release boundaries, 0.9 multi-entrypoint lifecycle, durable frontend/API/collector/cache portfolio, platform-owned configuration paths, and tuple-specific native installation SBOMs visible. Add executable release closure: contribution sweeps, document-pair preflight, and Standard lifecycle rebind. Add the implemented doctor/status/onboard front door, explicit brownfield authority stages, and release-candidate-wheel golden path. Keep private endpoints and credentials out of every artifact, and distinguish configured worker inventory from passing evidence. Keep the 1.1 scheduler/cache, real local Debian package, native CLI, native gRPC, and worktree-placement slices, and add the implemented 1.3 original-source binding, target-bound Python projection, FreeBSD identity, SDK tree-custody, and retained-execution slices. Do not claim complete FreeBSD platform admission, Windows ARM64 realization, production command/SSH DAG composition, real LAN cache qualification, remote native-package custody, or complete retained-project native acceptance as shipped, and do not call the 1.3 candidate published before the release and independent published verification succeed.

Include a clearly titled Release Policy section in the release-engineering sequence. State that main remains writable for ordinary work in Free and Pre-release states; Pre-release targets major.minor and permits green RC tags only on exact main; the cut release line is locked down. Only README Release Engineers merge release-line pull requests or create/publish major/minor releases. Strict/loose patch authority is per-project; loose grants listed writers only a reason-bearing, trunk-first break-glass patch. Show Literate-AI-Release: major.minor or Literate-AI-Release: none, merged/dead markers, and dry-run-first GC after worktree/PR inspection. Distinguish LitAI command enforcement from forge protection: forge settings should mirror the policy, but do not claim they are live. Preserve 26 slides by revising the existing release slide.

The narrative should progress from the scaling problem to durable intent, rapid implementation breadth, real end-to-end samples, the application-foundry destination, the technical control model, governed Component composition, cross-platform proof, the CLI, the next hardening horizon, compounding reuse, and a concrete investment decision.

Author speaker notes for every slide stating its supporting authority and its recorded limits. The deck is forwarded without narration.

Foundational framing: readable specification is durable authority; generated source is a candidate; guarded build, tests, execution, independent acceptance, and evidence receipts establish promotion. Do not invent ROI statistics, do not present roadmap outcomes as already shipped, and do not present a design intent as a measured result.