Repository documentation

Factual claim ledger

1.3.0 edition publication (2026-10-24)

The stable Google Workspace pair was updated in place from exact source revision eb5b82bfa2b03f042c9f2b65dfccfa5184bccd26. Export-back verified 26 slides, 26 notes pages, and 73 narrative headings. The release-bound receipt identity is sha256:e38fd2edbfab5be38eeb4c73369cae735a9eea640989ee4b858bd717d08a831a. Both resources expose the NVIDIA-domain reader grant plus their owner only; legacy anonymous-reader grants were removed before publication.

This is the major/minor document-pair regeneration required before the 1.3.0 cut. It preserves the published 1.2 foundation and records landed framework slices from the current public main: reviewed original-source first binding, target-bound Python source projection, FreeBSD worker/target identities, native SDK tree and package-topology custody, and retained execution hardening. Exact-main CI run 40063151931 passed at c345e652b91863e72526f25f8e31a03ec34bec01 before this regeneration.

The 1.3 contribution sweep deliberately defers unfinished work rather than promoting partial evidence. Bounded native Windows diagnostics, observation cost, ACL preflight, and fixture repairs move to 1.3.1. Complete FreeBSD admission, Windows ARM64 host realization, remote native packaging, production action-DAG/LAN-cache qualification, and broader retained-project contracts move to 1.4. The document pair does not claim those outcomes, does not claim the v1.3.0 tag exists, and does not grant release authority. Both stable Google Workspace resources retain the 1.2.0 edition until the explicit account-bound publication and export-back verification succeed.

Current authority used for the 1.3 summary includes CHANGELOG.md, docs/roadmap/active-work.md, literate.release.json, the merged pull requests from v1.2.0..c345e652, and the machine-readable contribution dispositions on milestones 1.3.1 and 1.4.

1.2.0 edition (2026-10-11)

This is the major/minor document-pair regeneration required before the 1.2.0 cut. v1.1.0 is published. The repository still declares 1.1.0 while the 1.2 line is prepared (src/literate_ai/version.py); this edition describes implemented candidate authority and evidence recorded under CHANGELOG.md's Unreleased section, not a claim that tag v1.2.0 has already been published. Both local members are regenerated and verified together. The stable Google Workspace resources retain the 1.1.0 edition until the explicit account-bound in-place update and export-back verification complete.

Counts re-verified against current authority for this edition:

• The Makefile RELEASE_GATES list is 15 names: public-export-check now runs second, after repository-layout-check (#55). Previous ledger value: 14.
• Six build-system Flavors (flavors/build-*): Bazel, GNU Make, CMake, Cargo, Mix, and repo-man. build-mix is new in 1.2. Previous ledger value: five.
• Package providers remain nine (flavors/package-*: pip, Conan, apt, Homebrew, WinGet, Chocolatey, Cargo, npm, ZIP). Hex is not a package-provider Flavor: build-mix contributes a hex toolchain constraint (flavors/build-mix/hex.json, Hex >=2.5,<3), and Hex packages are checksum-pinned dependency inputs that Mix acquisition admits, not an output packaging format.
• Language Flavors remain nine and OS families remain three.

Implemented and safe to cite, in addition to the 1.1.0 and historical ledger below:

• litai rebuild runs bounded candidate repair: a retryable build or generated-test rejection requests up to two fresh replacement candidates, each in its own durable attempt chained to the rejected one, and the rebuild result's repair field reports the replacements that ran. The repair prompt carries only a bounded, sanitized failure fact (_safe_diagnostic), never a raw excerpt. Authority: src/literate_ai/adapters/candidate_repair.py, src/literate_ai/contracts/executable_components/candidate_repair.py, src/literate_ai/cli/rebuild.py.
• The conformance sample runner records a bounded (4096-byte tail), redacted diagnostic_excerpt for rejected generated candidates — builder output for build rejections, generated expected/observed values for generated-test mismatches — in retained evidence and in the next attempt's repair feedback. Authority: tests/conformance/support/sample_runner.py, tests/smoke/test_candidate_rejection_diagnostics.py.
• Cross-host action workers: when BUILD, TEST, EXECUTE and FINALIZE all run on admitted workers, litai rebuild derives locked toolchain identities, commands and native dependencies from the worker, so the controller needs none of the project's tools. python -m literate_ai.standard_receiver is a reference action receiver for portable single-Component Make/Python Standard projects. FINALIZE grants are checked in the receiver's parent and child. Production worker grant provisioning and complete CLI rebuild qualification remain pending. Authority: src/literate_ai/standard_receiver.py, docs/architecture/component-execution-plans.md.
• The build-mix Flavor and mix-build-system skill build native Elixir Mix applications and libraries. The source BOM pins each Hex package's exact version, checksums and requirements (ranges refused); the native lock must equal those pins before anything compiles; extracted dependencies are replaced by verified archive bytes. Mix builds are local-only in 1.2; worker-built Mix intents are refused. Authority: flavors/build-mix/, skills/specification-to-source/mix-build-system/.
• Forge issues and PRs/MRs are the default tracker and agent-coordination channel (ADR 0050, docs/decisions/0050-forge-issues-and-reviews-are-the-default-tracker.md); Gerrit or another tracker is an override. Landing passes the policy target branch. litai prompt translate recognizes the generic external envelope (--external-envelope / LITAI_EXTERNAL_TASK_ID, schema literate-ai/prompt-task@2; src/literate_ai/application/prompt_routing.py).
• Release operations require an explicit SemVer policy (literate.release.json version_scheme: semver). When the policy declares qualification, litai release check defaults to a tiered target: each platform × action cell is covered by the leftmost tier that can run it — the host running the coding CLI, then one workers.json worker per remaining platform, then CI — and litai release qualify records exact-HEAD coverage. Authority: docs/architecture/project-releases.md, src/literate_ai/project_releases.py.
• Remote live gates still require opencode but no longer require OPENAI_API_KEY; OpenCode resolves the pinned provider's credentials from its own configuration (ADR 0017 amendment, 2026-10-09).
• litai project validate and Flavor catalog loading discover the project skill catalog once per operation instead of once per Component and Flavor, removing most of the filesystem metadata calls that made Windows gates slow.
• The 1.2 onboarding film, Settle the Argument. Before CI. (11:52), is published in the repository at media/courses/sam-meets-literate-ai/ with a verifying integrity receipt; remote workers and the learning loop are labelled walkthroughs.

Still must not be claimed:

• That v1.2.0 is published before release publication and independent verify-published succeed.
• That the stable Google Workspace pair contains this edition before explicit account-bound publication and export-back verification succeed.
• Clean three-way update merging and reviewed resolution application (issue #2; deferred to 1.3 — in 1.2, --review-conflicts is plan-only and update --apply preserves conflicts by default).
• Production action-DAG dispatch or multi-worker shared LAN-cache qualification (issue #4; deferred to 1.3 — 1.2 ships the scheduler and cache foundation).
• Worker-built Mix, Hex as a package-provider Flavor, production FINALIZE grant provisioning, remote native-package custody, or GitLab release-gate dispatch.
• Invented productivity, cost, quality, throughput, or ROI percentages.

1.1.0 edition (2026-10-04)

This is the major/minor document-pair regeneration required before the 1.1.0 cut, the first release from the public jordanhubbard/literate-ai repository. The private repository's last published tag was v1.0.1; the work drafted there as the 1.1 and 1.2 programs ships together as 1.1.0. This edition describes implemented candidate authority and evidence, not a claim that tag v1.1.0 has already been published. Both local members are regenerated and verified together. The stable Google Workspace resources retain the prior edition until the explicit account-bound in-place update and export-back verification complete.

Implemented and safe to cite, in addition to the 1.1 and historical ledger below:

• Exact lifecycle actions form a deterministic dependency DAG. Newly ready work can overlap across bounded, capability-matched worker slots; descendant failure is isolated and recovery rejects a changed route. Production command/SSH composition remains follow-on work.
• Provider-neutral local and HTTPS/WebDAV cache authority projects to Bazel and sccache without embedding credentials. Package, container, and test objects are immutable and byte-rehashed before reuse. Real LAN warm-cache qualification and complete production lifecycle composition remain open.
• package-apt projects deterministic Debian metadata, paths and modes, binds and rechecks dpkg-deb, constructs reproducible .deb bytes on compatible Linux hosts, and independently inspects the returned archive. Remote native-package construction from a non-Linux controller remains explicitly deferred.
• Native CLI Components have first-class taxonomy and verifier-owned package-custodied argv, binary stream, exit-status, and filesystem assertions. Complete synthetic validation/lock/build/test/receipt qualification remains deferred.
• Native gRPC acceptance binds descriptor closure, reflection, all four RPC cardinalities, remaining lifecycle deadline, raw evidence, status/detail refusal, and child shutdown through the optional pinned runtime.
• Framework-created worktrees derive one repository-owned .worktrees/ location from Git common-directory custody and reserve names atomically. Exhaustive legacy discovery, resumable audit journals, and evidence-preserving removal remain deferred.

Still must not be claimed:

• That v1.2.0 is published before release publication and independent verify-published succeed.
• That the stable Google Workspace pair contains this edition before explicit account-bound publication and export-back verification succeed.
• Complete production command/SSH DAG composition, measured LAN compiler-cache hits, remote native-package custody, complete native-CLI lifecycle qualification, or audited legacy-worktree removal.
• That cache presence alone authorizes reuse, or that generated/native outputs bypass exact identity, independent verification, and receipt gates.
• Invented productivity, cost, quality, throughput, or ROI percentages.

1.1.0 edition (2026-09-15)

This is the major/minor document-pair regeneration required before the 1.1.0 cut. v1.0.1 is published. The repository declares 1.1.0 while that tag is still a candidate; this edition describes implemented authority and candidate evidence, not a claim that tag v1.1.0 has already been published. Both local members are regenerated and verified together. The stable Google Workspace resources still carry the prior 0.10.0 edition until the explicit account-bound in-place update and export-back verification complete.

Implemented and safe to cite, in addition to the 1.0 and historical ledger below:

• Native SDK dependencies can be locked, acquired, built, inspected, admitted, prepared for Standard consumers, retained in relocatable packages, represented in resolved SBOMs, and rechecked at command/runtime boundaries. Runtime consumers can compare exact SDK snapshot and target identities without transcribing opaque hashes.
• Generated C++ static and shared library products carry explicit header, link, runtime, ABI and target closures. Real Bazel fixtures and independent compiled consumers exercise retained products across macOS, Linux and Windows-specific import-library handling; Conan payload restoration verifies exact declared bytes.
• Retained Cargo work preserves provider/importer authority, local and remote qualification archives, source and tool custody, reviewed gate order, test inventory, native dependency observations and rollback boundaries. Public admission now requires an independently reviewed retirement declaration, verifies the source root is already absent, executes the complete attributed consumer suite and emits a canonical receipt without deleting source implicitly.
• Independent Gitlink roots have explicit retained lifecycle planning and sequential execution with pin checks, dependency order, logs, process-tree cancellation, product hashes and resumable input validation. Recovery staging retains before-state after application is armed; coherent refresh commit/rollback remains open.
• Component worker-routing and artifact-custody primitives bind the exact plan, lock, catalog, worker, target and Flavor selection. Handoffs include only direct accepted predecessor exports and verify source and destination bytes. Standard DAG dispatch, authenticated result admission and complete cancellation/recovery are not claimed.
• A selected non-local retained receipt runs through the configured POSIX SSH worker. The coordinator stages a bounded deterministic runtime archive, binds its size and digest to the request, validates identity-bound remote phases and records the actual remote platform. Full remote evidence-bundle import and external workspace-link custody remain open.

Still must not be claimed:

• That v1.1.0 is published before release publication and independent verify-published succeed.
• That the stable Google Workspace pair contains this edition before explicit account-bound publication and export-back verification succeed.
• That the complete Component DAG is dispatched across workers, or that remote retained-receipt evidence has full coordinator custody.
• That retained Cargo import has complete public admission or may retire original source authority.
• That production containment backends or native application-package construction for apt, Homebrew, WinGet, or Chocolatey are shipped.
• Invented productivity, cost, quality, throughput, or ROI percentages.

0.10.0 edition (2026-09-04)

This is the major/minor document-pair regeneration required before the 0.10.0 cut. v0.9.0 is already published. The repository declares 0.10.0 while that tag is still a candidate; this edition describes implemented authority and candidate evidence, not a claim that tag v0.10.0 has already been published. Both local members are regenerated and verified together. The Google Workspace resources were updated in place for an earlier 0.10.0 revision on 2026-09-04 and export-back verified; this exact operator-adoption candidate awaits its source-bound in-place refresh.

Implemented and safe to cite, in addition to the 0.9.0 ledger below:

• Release class is derived from published history. Plans bind required collateral, including this terminal document pair for major and minor cuts. Publication preflight names one explicit active gcloud account and both stable resource capabilities before either mutation. A contribution sweep inventories open issues, reviews, unmerged branches, and worktrees; tracker dispositions and exact-head branch-lifecycle markers survive into the next cycle. Authority: docs/decisions/0034-continuous-evidence-bound-release-closure.md, literate.release.json, and src/literate_ai/project_releases.py.
• An explicit plan/apply Standard lifecycle rebind advances a project distribution pin to one reviewed non-editable installed distribution after an intentional wheel upgrade. Authority: GitHub #309 and src/literate_ai Standard lifecycle binding adapters.
• Reusable ancestor defects are searched and filed or linked in the owning upstream tracker before implementation, with sanitized fail-closed proposals and explicit external-write authorization. Authority: GitHub #308.
• Generated Makefiles emit the exact quoted language-tool expansion the generated-source validator already required. Authority: GitHub #310.
• Converted projects keep project-owned Component workflow, routing, and skill inputs across framework-template retirement; genuinely missing inputs still fail atomically. Authority: GitHub #306.
• Conversion source membership is separate from post-build artifact observation. Authority: GitHub #305.
• Conversion-aware starter documentation is rendered through one initialization/update helper. Authority: GitHub #283.
• Direct pytest profiling and xdist workers do not write interpreter bytecode into the authored checkout. Authority: GitHub #312.
• Published GitHub releases must be stable, carry non-empty notes, and expose a non-empty version-matching wheel. Branch-lifecycle markers remain durable after the matching tracker issue closes.
• Operator adoption is implemented through project-independent litai doctor, composed litai status, and content-identified litai onboard create|adopt plans that require acknowledgement before calling the existing mutators. Adopted trees record fail-closed wrapped → retained → drafted → qualified state; original source remains release authority until current regenerative qualification. The installed-wheel gate proves create through a validated hello project and adopt through an explicit retained receipt. Authority: ADR 0035 and the operator-adoption public and installed-wheel tests.

Still must not be claimed:

• That v0.10.0 is published before release publication and independent verify-published succeed.
• That the implemented operator-adoption candidate is shipped before v0.10.0 publication and independent published verification succeed.
• That production containment backends are shipped; the live generation path still requires explicit host-execution authorization.
• Native application-package construction for apt, Homebrew, WinGet, or Chocolatey; the host-prerequisite installer uses those package managers but is a distinct contract from building application packages.
• Invented productivity, cost, quality, throughput, or ROI percentages.

0.9.0 edition (2026-09-03)

This ledger records the 0.9.0 regeneration. Tag v0.9.0 published on 2026-09-04; the Google Workspace pair was not updated in that cut and remains the previous edition until the 0.10.0 publication. Implemented 0.9.0 claims remain safe to cite:

Implemented and safe to cite, in addition to the historical ledger below:

• A multi-entrypoint Component now carries every deployment unit through one multi-output build, attributed TEST and EXECUTE evidence, artifact export, package dispatch, independent acceptance, receipts, and CycloneDX evidence. Single-entrypoint contracts remain unchanged. Authority: docs/decisions/0026-multi-entrypoint-deployment-units.md, src/literate_ai/adapters/standard_project.py, and src/literate_ai/adapters/lifecycle/standard_local.py.
• The durable split-service portfolio composes browser frontend, read-only API, single-writer collector, and SQLite snapshot-cache Components through public capabilities and two independently executable Standard roots. Its verifier proves coherent publication, failure rollback, retry exhaustion, one-winner leasing, expired-lease recovery, idempotence, and reader restart without an upstream request. Authority: docs/decisions/0027-durable-split-service-pattern.md, samples/_harness/durable-split-service/portfolio.json, and tests/conformance/support/durable_split_service.py.
• Agent-skill taxonomy is owned by one executable catalog, deterministic connector work is implemented in Python application services, and host/user paths flow through injectable platform policy. Durable private configuration resolves to $HOME/.config/literate-ai on Linux and macOS (honoring XDG_CONFIG_HOME) and Roaming AppData on Windows; litai config migrate provides an explicit, dry-run-first 0.8.x migration. Authority: ADRs 0030 and 0031, src/literate_ai/application/agent_skill_catalog.py, and src/literate_ai/adapters/user_paths.py.
• make install selects one strict CycloneDX 1.7 prerequisite SBOM by OS, CPU, and accelerator coordinate, verifies the tuple's native package manager, asks once before installing missing packages, and fails with the supported inventory for an unknown tuple. make uninstall removes only manifest-owned Literate AI runtime paths and never removes native dependencies or durable user data. Authority: ADRs 0032 and 0033, flavors/os-base/toolchain.cdx.json, flavors/*/host-toolchain.cdx.json, flavors/os-*/host-install/, src/literate_ai/adapters/host_install.py, and src/literate_ai/adapters/host_uninstall.py.
• The sample harness catalogs 26 behavior applications. The configured private inventory has six workers spanning macOS ARM64, Windows 11 CPU/GPU, Ubuntu 24.04 CPU/GPU, and Ubuntu 26.04 CPU. This is inventory evidence only: it does not claim the full Cartesian product or a private Windows release run before those exact receipts exist.
• Current litai adds deterministic design, config, work, document, and prompt surfaces alongside the established lifecycle, package, release, worker, graph, and source-to-specification commands. These adapters do not turn deterministic local mechanics into model work.

Still must not be claimed (0.9.0 limits; the published tag does not retract them):

• That the 0.9.0 Google Workspace pair was published; it remained local while v0.9.0 shipped. The 0.10.0 edition is the recovery cut.
• That every catalog/worker combination has been qualified, or that private Windows worker evidence exists before unattended SSH and the exact run pass.
• That production containment backends are shipped; the live generation path still requires explicit host-execution authorization.
• Native application-package construction for apt, Homebrew, WinGet, or Chocolatey; the host-prerequisite installer uses those package managers but is a distinct contract from building application packages.
• Invented productivity, cost, quality, throughput, or ROI percentages.

Release Policy source refresh (2026-08-30, regeneration pending)

This source-only refresh documents the newly mandated Release Policy and project configuration. main is always writable for ordinary new work in Free and Pre-release states. Pre-release binds one major.minor target; litai release rc creates an annotated RC only from exact green main. Once release/<major>.<minor>.x is cut, the line is locked down. Only exact README Release Engineer logins may merge release-line pull requests, mutate release state, create RCs, or create/publish major/minor releases.

repository_policy.patch_authority is strict or loose. Strict reserves patches to Release Engineers. Loose permits a configured writers login to use reason-bearing break-glass only for a trunk-first commit; it grants no RC or major/minor authority. Every pull request carries exactly one Literate-AI-Release: major.minor or Literate-AI-Release: none line. Peer-work terminal markers are exact-head merged or reason-bearing dead records; dry-run-first GC rechecks open PRs, worktrees, ancestry, protected branches, marker currency, and clean state before explicitly authorized safe deletion.

Project-varying repository defaults are centralized under repository_policy in literate.project.json: default_branch, main_state, pre_release_version, default_component, sample_component_roots, work_queue, remote, merge_method, pull_request_labels, release_engineer_source, patch_authority, writers, and branch_gc_minimum_age_days. literate.release.json remains artifact release policy. Authority: src/literate_ai/contracts/projects.py, src/literate_ai/projects.py, src/literate_ai/project_releases.py, src/literate_ai/application/project_tracker.py, and src/literate_ai/adapters/peer_work.py.

This is command-level enforcement. Forge branch protection should mirror it, but no live forge configuration is claimed. The deck/narrative specifications and builders are updated while preserving 26 slides. Local PPTX/DOCX regeneration and Google publication were not requested and remain pending; checked-in binaries and published resources are unchanged.

0.8.0 edition (2026-08-28)

This is the major/minor document-pair regeneration required before the 0.8.0 cut. main is 0.8.0 Unreleased. This edition describes current implementation. It does not claim remaining 0.8.0 product work as shipped: Flavor directory rename (FLAVOR-005), TEST-CACHE-001 designed pin/dispatch, ADR 0010 dotted-alias close, or --target local worker-fleet fan-out.

Implemented and safe to cite, in addition to the 0.7.1 edition ledger below:

• Win32 Job Objects bind remaining in-package timeout spawn sites so late grandchildren die with the parent. Standalone worker scripts stay stdlib-only and keep validated taskkill (src/literate_ai/adapters/_processes.py callers; PROC-KILL-001 remaining sites).
• Agents own patch content on the current release/<major>.<minor>.x line; humans own when the next minor or major is cut (skills/agent/release-project/SKILL.md, docs/architecture/project-releases.md).
• Each published changelog section links to that version's README.md at the matching git tag. litai release prepare inserts the link when a GitHub provider is configured. Headings stay unlinked so prepare/notes extraction still match ^## {version}(?:\\s|$).
• After Google Slides import, the 0.8.0 overview is read and improved so text boxes do not overlap and workflow slides stay picture-led (DOC-DECK-003).

Still must not be claimed:

• That v0.8.0 is a published distribution tag.
• --target local fan-out across a configured private worker fleet.
• Native apt, Homebrew, WinGet, or Chocolatey construction.
• Invented productivity, cost, quality, or ROI percentages.

0.7.1 edition catch-up (2026-08-27)

0.7.0 was a minor cut and therefore qualified for a full manager/engineering overview regeneration. That refresh was skipped. 0.7.1 is the catch-up edition for the line: the pair is regenerated and published against the 0.7.1 implementation state, labeled as the 0.7.1 edition, without retagging v0.7.1. Later patch cuts on 0.7.x keep README citations on this edition. The next full regeneration is the next major or minor (0.8.0, 0.9.0, 1.0.0, 1.1.0, …). Authority: docs/architecture/project-releases.md and skills/agent/release-project/SKILL.md.

Implemented on the 0.7.1 line and safe to cite:

• Trunk-based cuts: litai release prepare creates release/<major>.<minor>.x when the plan records release_line.create: true. check and publish refuse the default_branch checkout and refuse a per-patch name such as release/0.7.0 (src/literate_ai/project_releases.py, RELEASE-BRANCHING-002).
• Public-API-first tests: contract and component tests prefer the supported CLI and Python APIs; method-level tests remain only for isolated logic (CONTRIBUTING.md, TEST-PUBLIC-001).
• Paginated Component-lock reviews: a genuine large semantic diff is reviewed in bounded pages and replaced atomically (docs/decisions/0020-paginated-component-lock-review.md, src/literate_ai/adapters/component_lock_reviews.py).
• v0.7.1 was published from release/0.7.x via litai release check --target github. That GitHub Actions run substitutes for a local make release-check; it is not evidence that --target local worker fan-out was qualified.
• POSIX host-bootstrap search uses HOME from the discovered environment, not Path.home(). Component-lock review tests bind BUILD_DIR/OBJ_DIR to the temp project so they do not adopt an xdist worker's unmarked cache dirs.

Still must not be claimed:

• --target local fan-out across a configured private worker fleet, or that every worker in such a fleet has passed for 0.7.0 or 0.7.1.
• Native apt, Homebrew, WinGet, or Chocolatey construction. Planning those providers remains live; construction remains open.
• Invented productivity, cost, quality, or ROI percentages.
• That the published Slides copy is current until this edition's import is verified.

Release-check gates: the Makefile RELEASE_GATES list is 15 names as of 1.2.0 (public-export-check added after repository-layout-check; it was 14 through 1.1.0). There is no codegraph-ready gate. An earlier 26-slide local rebuild drew 15 abbreviated chips including codegraph; that drawing is stale relative to current authority.

The live Flavor surface (counts measure catalog area, not maturity or Cartesian qualification), re-verified against flavors/ for 1.2.0: nine language Flavors (Python 3.11+, C++17, Rust 2021, JavaScript with Node.js 20+, TypeScript, Swift with Apple/Linux/Windows toolchain realizations, Go, Zig, and Elixir with Erlang/OTP 27+); six build-system Flavors (Bazel, GNU Make, CMake, Cargo, Mix, repo-man); three OS families (macOS, Linux, Windows); nine package providers (pip, Conan, apt, Homebrew, WinGet, Chocolatey, Cargo, npm, ZIP). Hex is a build-mix toolchain constraint and pinned dependency input, not a package provider. Native construction remains pip wheels and Conan cache archives, plus the local Debian path recorded in the 1.1.0 edition.

The narrative member is realized locally with python-docx (build_narrative.py). The Codex documents plugin remains unavailable under the organizational spend cap and is not a hidden requirement of this package.

Release evidence closure (2026-08-26)

The 0.7.0 release path now closes over its own execution evidence. The release root, each gate, each host or worker dialog, each sample variant, and each phase records a node in the append-only ledger implemented by src/literate_ai/evidence_ledger.py, src/literate_ai/project_releases.py, and src/literate_ai/step_harness.py. Nodes carry the pins and output pointers for their own stage; child processes inherit the run through LITAI_EVIDENCE_RUN and LITAI_EVIDENCE_PARENT. The public litai release evidence explain, index, show, and prune commands are the bounded inspection and retention surface. The ledger indexes and points to evidence; it does not authorize a build or accept a release.

Failure custody retains sample scratch, installed workspaces, transcripts, and diagnostics on failed steps and reports their absolute paths, while successful steps still clean up. This specifically closes the v0.5.2 host-E2E failure mode in which the failing sample's scratch disappeared with the run that produced it. Sample scratch remains outside the checkout; evidence custody points to that external directory rather than relocating a host build under _build/evidence/.

The single-host legacy-local path is complete without a worker fleet. Fan-out and provider paths that cannot run are recorded as explicit skipped or unavailable nodes with reasons, and a fan-out without a configured fleet reports authoritative: false.

Codex-independent rebuild realizes the release-engineering pillar (2026-08-19)

Regenerated the presentation member from the updated deck-specification.md (26 slides, including the "Release engineering" sequence added 2026-08-18 below) using a new build_deck.py / python-pptx build path, replacing the retired build_deck.mjs / @oai/artifact-tool path.

The prior path was blocked on two independent problems, not one: the organizational Codex spend cap for the openai-primary-runtime provider (still live — reverified with a direct codex exec probe this session, which failed immediately with "You hit your spend cap set by the owner of your workspace"), and, separately, @oai/artifact-tool itself is not resolvable at all in this environment — it is not published to public npm and regenerate.sh's own plugin-detection (setup_artifact_tool_workspace.mjs) no longer finds a matching installed plugin version. Neither problem is specific to this package; both are Codex-runtime availability, not a defect in the specification, the build logic, or the acceptance oracle. build_deck.mjs itself has no LLM calls in its render step — the codex dependency was purely the proprietary shape/text/image render library it imported.

build_deck.py ports every primitive (shape, text, pill, line, arrow, footer, title, wash, image placement) to python-pptx, reproduces slides 1-18 and (renumbered) 23-26 losslessly from the prior 22-slide edition, and adds the four release-engineering slides (19-22) deck-specification.md already called for but build_deck.mjs never implemented:

• 19 — checkpointed resume: a real two-gate-row diagram (first run stopping at driver-review, second run skipping the six already-passed gates) using abbreviated chips for the Makefile RELEASE_GATES list, plus a mono excerpt distinguishing python-check's content-hash checkpoint from release-check's coarser gate-name-only checkpoint. The 2026-08-19 drawing listed 15 chips including codegraph; current authority is the 15-gate list (as of 1.2.0) without codegraph-ready (see the 0.7.1 edition entry).
• 20 — dual dispatch targets: litai release check --target local|github fanning into a private-worker-fleet panel and a GitHub Actions panel that converge on the same make release-check command, naming --target gitlab as recognized-but-unsupported.
• 21 — per-step timing: a stage-duration bar row plus a real-shaped litai perf JSON-Lines span excerpt (stage, target, coding_cli, model, timestamps, duration_seconds, outcome).
• 22 — provenance pinning: a "what the pin protects" panel plus a real, shortened excerpt of scripts/review_lifecycle_driver.py --record's actual output shape from this repository (not a hypothetical), and the documentation-authority marker as the same fail-closed pattern applied to the doc surface.

Every claim on the four new slides traces to "Release engineering claims used by the technical sequence" below, already recorded on 2026-08-18. scripts/verify_document_pair.py passed against the rebuilt artifact unmodified — the oracle reads raw OOXML/zip and never imported the retired build tool, so it required no changes. One structural gap from the prior edition's build script closed as a side effect: build_deck.mjs's own translucency comment noted the artifact-tool it depended on silently ignored the shape opacity option, rendering every wash() overlay as fully opaque; python-pptx supports a real <a:alpha> element, so those overlays are now actually translucent as originally intended, a small visual improvement rather than a claim change.

regenerate.sh prefers the portable python-pptx path (regenerate_python.sh) so a vanilla worker with make doc-toolchain-bootstrap and no Codex plugin can regenerate; plugin discovery (setup_artifact_tool_workspace.mjs) remains as fallback until three-OS visual parity closes. regenerate_python.sh is the portable implementation the launcher execs when the OBJ_DIR toolchain imports. The narrative member is realized through build_narrative.py on the same path.

Vanilla worker regeneration without Codex plugin (2026-08-30)

DOC-TOOLCHAIN-001 remaining work: a worker with empty CODEX_HOME regenerates both members from this checked-in package through regenerate.sh after make doc-toolchain-bootstrap, and scripts/verify_document_pair.py accepts the result. Live Google Slides were not regenerated for this evidence.

Release-engineering pillar added ahead of the 0.4.1 release (2026-08-18)

Added a new labeled technical sequence and narrative section, "Release engineering: proving the system knows when it's valid," to both deck-specification.md (slides 19-22, in Consequences, renumbering the prior 19-22 to 23-26) and narrative-specification.md (new §7, renumbering "Where this is going" to §8 and "How to engage" to §9), by explicit owner decision. The existing deck and narrative describe Literate-AI's generation/foundry model in depth but named release engineering only in a single bullet ("release control," part of litai's four separated concerns in §6.1). This cycle's own work — building and battle-testing checkpointed fail-fast release gates, multi-target dispatch (a private SSH worker fleet and, from the release after 0.4.1 forward, GitHub Actions), litai perf telemetry, and TCB/documentation-authority provenance pinning, then finding and fixing three real defects with it in the process — is real, differentiated, load-bearing capability that was previously unrepresented. See "Release engineering claims used by the technical sequence" below for the cited evidence. Regeneration of the PPTX/Google Doc from these updated specifications was not yet attempted as of this entry; regenerate.sh previously failed on the Codex presentations/documents plugin spend cap (see the 2026-08-16 entry above), an external constraint to check again before assuming it still applies.

Document-pair widening for the 0.4.0 release (2026-08-16)

components/literate-ai-overview/component.md was widened from a presentation-only declaration to declare both the presentation and narrative members of literate-ai.document-pair, by explicit owner decision. The narrative member is a comprehensive, multi-page Google Doc describing the codebase and its behavior — a fuller technical account than the deck's succinct sales-pitch framing, sharing the same factual ledger and the same requirement to cite the durable mechanism sequence and the failure path. Its authoring source is narrative-specification.md in this package. Both members are realized together whenever a publication is authorized. Actual regeneration was attempted via codex exec driving the Codex documents/presentations plugins (the now-interactive replacement for the old regenerate.sh headless flow); the probe call failed immediately with "You hit your spend cap set by the owner of your workspace" for the openai-primary-runtime provider, an organizational limit only a workspace owner can lift — not a code or configuration defect in this repository. Regeneration and publication of both members remain open until that spend cap is raised. See components/literate-ai-overview/component.md's "Scenario: Only one member's authoring source has changed" for why a single-artifact edit does not exempt the other member from re-verification against this ledger.

Ledger-only refresh for the 0.4.0 release (2026-08-17)

Revalidated the build-system Flavor matrix claim against current authority (flavors/build-cmake/, flavors/build-bazel/, flavors/build-make/) ahead of the 0.4.0 release, which added a build-cmake Flavor, an explicit litai release check --target local|github|gitlab execution-target choice, a project-level ci_targets manifest preference, and two new default specification-to-source skills (python-service-application, react-dashboard-application). This pass updated only this factual-claim ledger and deck-specification.md's narrative source (the latter's existing "multiple languages and build systems" phrasing already covers the addition without a specific-name edit); the PPTX itself was not re-rendered and the published Google Slides copy was not re-imported, because the presentations artifact-tool plugin required by regenerate.sh is not installed in this environment. Re-render and re-import remain open follow-up work in a fully-tooled environment.

Authorities reviewed for the 2026-08-11 edition

• Current repository specifications, root SKILL.md, user documentation, architecture documentation, and source-to-specification qualification documentation.
• Current implementation and CLI surfaces located through CodeGraph where applicable.
• litai project validate using the repository’s managed Python 3.13 environment.
• Historical narrative in docs/presentations/literate-ai-overview.pptx, with every reused claim checked against current authority.
• Current litai help, the Component-execution-plan architecture, sample catalog, and fan-out implementation and documentation.
• The current user-owned test matrix was inspected only to count configured runner roles; private destinations are not copied into this package.

Component model for this artifact

• This deck is component://literate-ai/literate-ai-overview, a terminal document Component. It provides no capability, is absent from the project template, and is citable but not inheritable.
• It requires literate-ai.document-pair, the reusable capability defined by components/document-pair/, and declares both the presentation and narrative members (widened from presentation only on 2026-08-16).
• The documentation.ecosystem Flavors now bind to that capability and contribute concrete member, access, and formatting mappings.
• Current boundary: build-source generation through the ordinary lifecycle is not yet wired. The checked-in Python builders are deterministic project-local authoring tools, while the presentation runtime remains host-provided rather than a declared toolchain Flavor. build_deck.mjs is retained only as the documented plugin fallback.

Inherited artifact authoring

• Literate AI carries skills/agent/author-presentations-and-documents/SKILL.md into newly initialized projects.
• The documentation.ecosystem Flavor axis has google-workspace and microsoft-365 choices. The first targets Google Slides and Google Docs; the second targets PowerPoint and Word with SharePoint or OneDrive collaboration when authorized.
• These choices govern artifact format and collaboration surface, not product claims, approval state, application generation, build execution, or release authority.

Current claims used

• A Component specification is the durable, human-readable authority.
• Specification, Flavors, Skills, Workflow, and Routing resolve into an exact, inspectable plan before model execution.
• The Standard core implements exact per-Component planning, bounded parallel generation, invalidation, accepted-source caching, restart custody, build authorization, artifact assembly, generated tests, independent acceptance, and project-admission seams.
• Generated source is treated as an untrusted candidate and cache hits are revalidated against current gates.
• Pre-build and post-build CycloneDX evidence are supported.
• The live language Flavor matrix is Python 3.11+, C++17, Rust 2021, JavaScript with Node.js 20+, TypeScript, Swift with explicit Apple/Linux/Windows toolchain realizations, Go, Zig, and Elixir with Erlang/OTP 27+.
• The live build-system Flavor matrix is Bazel, GNU Make, CMake, Cargo, Mix, and repo-man. Bazel is a removable preference, never hard-coded authority.
• The live operating-system Flavor matrix is macOS, Linux, and Windows.
• The packaging Flavor catalog contains pip wheels, Conan, apt, Homebrew, WinGet, Chocolatey, Cargo, npm, and deterministic ZIP archives. Compatible providers compose as independent selections. The current CLI provides exact, read-only multi-provider package planning and Standard-lifecycle-backed native construction/independent verification for deterministic pip wheels and portable Conan cache archives, plus local Debian construction on compatible Linux hosts. Homebrew, WinGet, and Chocolatey construction remains open.
• The current private user-owned inventory configures six workers spanning macOS ARM64, Windows 11 CPU/GPU, Ubuntu 24.04 CPU/GPU, and Ubuntu 26.04 CPU. This is configuration evidence, not a claim that the full Cartesian product has passed.
• The sample portfolio now contains 26 behavior applications. Three are OS-pinned: Linux Cgroup Budget Interpreter (C++/Conan), Windows Path Auditor (C++/Conan), and macOS LaunchAgent Catalog (Swift/Apple toolchain/Homebrew). Host discovery excludes the other two before generation while catalog discovery retains all three for readers.
• Repository samples used in the deck include the Python Composable Invoice Service, the Rust Build Pipeline Dependency Planner, the Rust/JavaScript Full-Stack Release Dashboard, and the C++ Exact Statistics Library realization. Their specifications and verifier oracles define deterministic acceptance behavior.
• Greeting Card Starter and Exact Statistics Library select pip; Dependency Planner and the OS-specific native utilities select Conan. make samples-packages is the opt-in live proof that selected Standard samples can construct and independently verify native wheel/Conan bytes from their accepted artifacts without publication. Ordinary sample execution does not pay this package-construction cost.
• First-class multi-entrypoint Components retain every declared deployment unit through build, TEST, EXECUTE, packaging, independent acceptance, receipts, and SBOM evidence.
• The durable split-service sample composes four separately generated frontend, API, collector, and snapshot-cache Components across two Standard roots and verifies their cross-process lifecycle rather than collapsing them into one prompt.
• make install consumes a strict tuple-specific host-prerequisite SBOM; make uninstall removes only Literate AI-owned runtime files. Durable private configuration is resolved by one platform policy and migrated explicitly with litai config migrate.
• Source-to-specification can index an inert mirror, draft reviewable Component and Flavor material, and journal model calls without executing the mirrored source.

CLI, graph, and fan-out claims used

• Current litai help exposes: help, version, status, doctor, orchestrate, onboard, design, release, package, flavor, perf, matrix, config, work, video, document, worker, init, cache, skills, prompt, catalog, graph, render, build, test, run, verify, update, reparent, learn, lock, component, clean, really-clean, project, plan, generate, rebuild, profile, and spec (re-verified for 1.2.0). Diagnostic and deterministic connector verbs do not authorize a release.
• litai release evidence explain|index|show|prune inspects or reclaims the append-only release evidence ledger. These are diagnostic and retention commands; the ledger does not authorize a build or accept a release.
• litai package exposes separate plan, build, and verify verbs. build requires explicit host-execution acknowledgement, writes content-addressed package batches only beneath OBJ_DIR, embeds component.md plus the resolved CycloneDX SBOM, and grants no external publication authority. verify reopens retained inputs and native bytes; Conan is restored into a fresh isolated cache.
• Component plans support arbitrary acyclic dependency graphs, exact public-interface bindings, provider-before-consumer layers, deterministic result ordering, and bounded concurrency among independent nodes.
• Component hierarchy never authorizes context flattening: a consumer receives direct public contracts, not private transitive specifications, source, or tests.
• scripts/fanout_samples.py runs user-selected samples across user-owned SSH targets in parallel, selects platform Flavors, binds an exact Git revision or working tree, fails fast, and checkpoints successful target IDs under OBJ_DIR for repair-cycle resume.
• A completed resumed repair cycle clears its checkpoint and requires a clean rerun before the result can serve as release evidence.

Mechanism claims used by the technical sequence

Authority: docs/architecture/component-execution-plans.md, docs/architecture/production-containment-threat-model.md, docs/architecture/sbom-and-dependency-graph.md, docs/architecture/source-promotion.md, and the repository sample at components/money-calculation/.

• Slide 7 quotes the money-calculation Component specification and its interface contract verbatim from the repository. Neither excerpt is illustrative prose.
• A ComponentGenerationKey binds the ordered specification set and document identities, selected target and Flavors, specification-to-source skills, workflow, routing policy, model, authored assets, its own exported public-interface identities, and the public interfaces of its direct generation dependencies.
• It deliberately does not bind aggregate Component or authoring revisions, nor a dependency's revision, private specifications, source tree, build output, tests, routing policy, or skills.
• The four resulting invalidation consequences are stated rules, not inferences.
• Action plans schedule every locked revision in explicit zero-based layers with provider-before-consumer ordering; independent nodes in a layer run concurrently up to an explicit bound; results emit in canonical Component-revision order.
• Absent runtime measurements remain null rather than an invented zero, and a supplied measurement exceeding the exact budget fails the node while retaining observed values.
• A failed provider cancels dependent generation nodes before their adapters are called while independent branches continue; a different key fails closed before reuse.
• An accepted-source cache hit still runs the complete current index, authorization, build, test, execution, and acceptance sequence, and is not republished.
• A BuildRequestDeclaration names builder, toolchain, sandbox, privileges, and outputs before generated bytes exist, and deliberately cannot name a source bundle.
• The ordered isolation levels are host-yolo, process-limited, and os-sandboxed. A local sufficiency decision is explicitly unauthenticated-local and is neither execution authorization nor release evidence.

Release engineering claims used by the technical sequence

Authority: scripts/run_checkpointed_unittests.py and src/literate_ai/test_checkpointing.py (fail-fast checkpointed resume); src/literate_ai/project_releases.py and src/literate_ai/adapters/ssh_transport.py (multi-target release dispatch); src/literate_ai/perf.py and src/literate_ai/cli/perf.py (litai perf); src/literate_ai/adapters/ project_lifecycle_driver.py (lifecycle_driver_implementation_identity, the TCB pin) and docs/user/troubleshooting.md's "Documentation authority review is missing, duplicate, or stale" section (the documentation-authority marker). docs/user/troubleshooting.md's "make python-check/make release-check reruns everything after a small edit" section documents the same checkpoint mechanics for users, not only this ledger.

• A checkpointed test/gate run records only tests or gates that actually executed and passed; a run interrupted partway resumes from that exact point on the next invocation rather than restarting. python-check's checkpoint is keyed by a content hash of each test module's own bytes, so it is always safe to trust a resume. The coarser release-check gate-level checkpoint has no such content fingerprint — it tracks only the ordered gate-name list — so it is reset explicitly before re-validating a checkout against a different commit than it last ran against.
• A checkpointed run that resumed any prior state deliberately reports a distinct exit status from a genuine, from-scratch clean pass, and asks for one more full run before its result counts as release evidence — a resumed pass is not silently promoted to the same evidentiary weight as a full one.
• litai release check --target local|github|gitlab accepts all three target names, but GitLab is recognized and fail-closed as unsupported rather than dispatched. Local and GitHub execution use the same declared gate command (make release-check), while a single-host legacy-local run executes the gate on the invoking VM when no worker fleet is configured. Configured local fan-out still runs in parallel across eligible workers, requires every dispatched worker to pass, and names the first failing worker deterministically; absent fan-out and provider paths are recorded as explicit skipped or unavailable evidence. A GitHub Actions --target github pass is not a substitute claim that local fan-out ran.
• When the policy names default_branch, prepare creates release/<major>.<minor>.x if the plan says to; check and publish refuse that default branch and any per-patch name. Do not wrap a raw git branch / git checkout in place of prepare.
• SSH-dispatched remote commands run under a forced login-and-interactive shell (bash -lic) rather than sshd's default non-login, non-interactive invocation, so a worker's real toolchain (reached only through its own shell startup files) is reliably visible to the dispatched command without any worker-side configuration change.
• Every top-level litai command, and every worker dispatched during a --target local fan-out, records one structured JSON-Lines performance span: stage, target kind and id, coding CLI, model, start/end timestamps, duration, and pass/fail outcome. This telemetry is diagnostic, never authority — a read-only or missing build root never fails the command it observes. litai perf show/litai perf chart --dir PATH can report on an archived copy of that telemetry directly, so it survives past the disposable build directory being cleaned.
• The lifecycle driver's implementation identity is a single content-addressed digest over the exact declared source-file closure that is trusted to execute the project's build/test/acceptance lifecycle. Any change under that closure invalidates the pin; the project fails closed until the pin is explicitly re-recorded, which is itself a reviewable, single-line diff. The documentation-authority marker applies the same fail-closed pattern to the declared documentation surface: a stale marker blocks litai project validate until a human re-reviews and re-records it.

Boundaries that must remain visible

• The Standard core is implemented, but some reference samples still retain a content-pinned external driver while remaining ordinary-CLI integration work is completed.
• Current source-to-specification qualification carries a v2-required boundary. Draft generation is not automatic authority transfer; effective authority remains source-baseline until trusted, current qualification evidence exists.
• Do not claim live repository acquisition as an ordinary generation behavior unless that behavior has become implemented and verified.
• The next two-week hardening horizon is investment framing, not a measured delivery guarantee. The 0.9 durable application loop and 0.10 operator-adoption surface are implemented; the next horizon concerns production containment, broader native application packages, deployment automation, and downstream adoption evidence.
• Production containment is an architecture contract in this repository, not a shipped backend. The live sample path runs with explicit YOLO authorization as the host user, and only the source-to-specification observation path has narrower macOS sandbox-exec and Linux Bubblewrap adapters.
• Portfolio-scale concurrency is design intent. No throughput figure is a measured result.

Claims intentionally excluded

• Invented productivity, cost, quality, or deployment-frequency percentages.
• A claim that every reference sample already runs solely through the ordinary CLI.
• A claim that inferred specifications automatically supersede legacy source today.
• A demonstrated count of concurrently executing bounded tasks. The previous edition implied hundreds or thousands; no such measurement exists and the claim has been removed.
• Any product-studio implementation claim. The inspected successor project is currently a specification scaffold without an indexed implementation surface, so it is intentionally absent from this edition.