v13 delivery plan and evidence

13.0.0-alpha.4 prepared on October 29, 2026 (not yet published). The release commit sets the twenty packages of the release order to 13.0.0-alpha.4; the coordinator records the tag, the exact-SHA admission and the release run here after publication. It makes the main CLI leaner: green (formerly footprint) stays in it as an Experimental command and the terminal AI assistant (cargo rullst ai) is removed; it removes Foundry, Nix, Buildah, gRPC, the Fly.io, Render and Railway deploy targets and the self-updater’s binary replacement; gives deploy one path for any Linux VM with guides for Hetzner Cloud, DigitalOcean, Oracle Cloud and Google Cloud; keeps three starters and moves LMS, ERP and Portfolio to the repository’s examples; adds one --json contract and an optional section to llms.txt; and shortens the development builds of generated projects. The framework crates’ APIs do not change. The first targeted cargo-rullst mutation campaign is merged, and the CLI’s measured files are in the pull-request mutation gate. 13.0.0-alpha.4 is the 13.0 feature freeze: next come 13.0.0-rc.1 (fixes and documentation only) and then 13.0.0. Rullst keeps aws-lc-rs as the TLS crypto provider (rustls’ post-quantum hybrid key exchange), so the aws-lc-sys build script stays in a project’s first build; moving to ring is not planned. SQLx’s macros compiling some crates twice and Nexus pulling rullst-ai into the SaaS starter are planned for 13.0.0-rc.1 if they need no breaking change, otherwise for 13.1 (Build times). Work planned next is under Planned after 13.0.0-alpha.4.

13.0.0-alpha.3 published on October 24, 2026. All twenty packages were published from tag v13.0.0-alpha.3 at be336833 after the 25 required workflows passed on that exact commit (release run 40129821475). It carries the fixes from the alpha.2 dogfooding reports, first-class PWA support and the retirement of Omni, the Studio production monitor (endpoint, standalone remote mode, history and alerts), OAuth login with make:oauth for Google, GitHub, Microsoft and Apple, CLDR plurals and formatting, and the breaking changes listed in the changelog. The mutation campaign finished rullst-orm, rullst-orm-macros, rullst-core and rullst-nexus; cargo-rullst is not yet mutation-measured and its targeted campaign continues after this release. The work planned next was delivered in 13.0.0-alpha.4.

13.0.0-alpha.2 published on October 17, 2026. Tag v13.0.0-alpha.2 points at 0daf4941. Release run 39041726912 followed an exact-SHA admission of all 28 required workflows; the release fuzz campaign (42 targets, no crash) ran on 01aa4b10 and was reused for the release commit, whose fuzz inputs were identical. It carries the fixes from the alpha.1 dogfooding report and the breaking html! → Markup, Schema date/time and Nexus changes (see the changelog). Admission found and fixed, before publication: the upstream zip yank (Studio’s Swagger UI page replaced), Windows, sanitizer, coverage and Miri failures, an exact-pin packaging check, and the zip 6 advisories (a governed exception until 2026-10-31). A first tag at 669befe6 failed release verification before publishing anything (the CLI evidence audit did not receive the exception) and was replaced after the maintainer’s approval. The work planned next was delivered in 13.0.0-alpha.3.

13.0.0-alpha.1 published on October 11, 2026. Tag v13.0.0-alpha.1 points at fc44bf76. Release run 38151068563 followed an exact-SHA admission of all 28 required workflows. Its fuzz evidence was reused from campaign 38056935372. All twenty crates on crates.io match the release checksums. The GitHub release is a prerelease, and 12.3.0 remains the latest stable release.

A smoke test used the published Linux CLI to generate a Blank SQLite project from the registry crates. The project built, passed its tests and served /. First publication of the four new names is recorded in the release recovery runbook.

Direction revised on September 22: maintain stable v12.1 and continue v13 according to product value, evidence and available resources. The owner no longer requires publication by September 26; it is a review/handoff point, and work may continue in later sessions. The earlier calendar below is retained as history, not a release obligation. The priority proposal classifies all 41 master milestones without requiring the entire roadmap for 13.0.0. The SST governs APIs and architecture; no deadline or alpha label waives a security or publication gate.

Maintenance direction adopted on September 22: follow the maintenance scope and extension strategy for future v13 work. Preserve common application foundations, contain Capital’s scope and assess independent lifecycles for specialized extensions. This planning decision does not change current package admission, publication inventory or v12.1.1. Earlier implementation queues below are historical where they imply broader expansion without the strategy’s product, maintenance and acceptance criteria.

Evaluation direction adopted on September 23: after the active v12.1.1 maintenance admission, begin the bounded comparison plan with a usable application journey. The 25 A themes are investment priorities, not a requirement to finish every theme before measuring effort, failures, performance and maintenance. Use findings to select later work; this adds no release gate, paid resource, live-account test or claim of superiority.

The owner asked about an alpha-first release on September 22. The 13.0.0-alpha.N prerelease versions support that evaluation path: consumers opt in explicitly and APIs may change before stable v13. Alpha, beta and RC labels do not waive the applicable verification, ownership or protected-publication checks. Choosing a prerelease label does not authorize an upload; stable 13.0.0 still requires its own readiness decision.

Direction recorded on 2 October: publish 12.2.0 from v12 first, through its complete admission and the protected crates.io step. The v13 publication decision is deferred to the owner’s next working session, after 7 October. The owner is considering a first v13 alpha that includes the current candidate packages as well as the sixteen published ones. That option is not yet approved, and the alpha label does not waive the checks above: each candidate still needs its own admission and a place in the release order before upload. main remains the v13 development line. When stable 13.0.0 is published, a v13 maintenance branch can be cut from its release source, as v12 was, and main moves on to the next major.

Verification order adopted on 3 October: the 12.2.0 admission showed that mutation findings arrive too late once the release gates have started, because any correction then forces a new exact-source admission. For v13 releases, mutation testing moves ahead of the version freeze. It stays manual and informational:

1. During development, a pull request that changes security-critical code gets a manual targeted mutants.yml run for each changed production file before merge. Critical code covers secret masking and redaction, authentication and sessions, rate limiting, request, mail and upload inspection, webhook and token verification, and access control. Meaningful survivors get tests in the same pull request.
2. Before the version freeze, a full campaign runs on the candidate source. Each survivor is triaged as a defect to fix, a missing test in critical code to add, or an equivalent or low-value mutant accepted with its reason. Critical areas aim for at least 90% caught under the conservative count; other areas must not fall below the previous release.
3. Only then does the version change land, followed by one run of the exact-source release gates, with fuzzing dispatched first because it takes longest.

Mutation testing stays out of the required pull request checks. Each mutant rebuilds and retests its crate, so a run takes from tens of minutes to hours, and it would compete with the release gates for the same hosted runners. A non-blocking run triggered by a pull request label can be reconsidered if runner capacity grows.

Source-line transition approved on 21 September

The owner approved development on main, stable maintenance on v12, and retention of the Pages branch. Stable source 184bc1f7 is preserved in the v12 history. PR #237 prepared its maintenance workflows and versioned release rules; it merged at 0bb7406b after all 43 required checks and 24 relevant workflows passed. main and v12 have the same strict, admin-enforced 43-check protected profile.

The six-feature source was admitted in PR #236 as recorded below. PR #238 combines that source with all six Dependabot updates and the 13 → main, 12 → v12 transition. Its exact combined source passed workspace/platform, coverage, security and extracted-package admission and merged normally at 0ce3306d. No tag or published crate changed.

Approved delivery sequence

The release owner approved this scope on 20 September 2026 UTC: a first-party, provider-independent privacy foundation, optional external integrations, and a local facial engine as follow-up work. This does not make declarations into verified attributes or permit incomplete higher-assurance checks in production.

The privacy decision sets the first required product journey. The broader execution queue below was reconciled with the master roadmap on 20 September after the owner asked for more of the planned v13 capabilities. Privacy, migration and release preparation are the minimum priorities, not a ceiling on useful implementation during the active sessions.

The prioritized implementation sequence is:

1. Retain the admitted v12.1 closeout and admit the v13 integration after its existing hosted checks pass; carry applicable stable corrections and keep mutation findings visible.
2. Admit the optional PostgreSQL replay candidate after its hosted checks. Its real-database tests cover concurrency, quota, expiry, failures, cancellation, clock rollback and server restart. Keep SQLite’s shared-local boundary and PostgreSQL’s operator-owned replication/failover obligations explicit.
3. Build an authenticated first-party declaration journey, with server-owned policy, tenant/session/action binding and rejection when stronger assurance is required. Exercise the supported SaaS/LMS consumer shapes without a paid provider, fake age determination or mandatory camera capture.
4. Implement purpose/version choices, effective withdrawal of optional processing and one scoped rights workflow that actually exports or erases application data. Test ownership, cross-tenant denial, retention and restore boundaries.
5. Extend the product queue with server-side SaaS plan entitlements, a typed API contract with its first TypeScript consumer, and CLI verification of signed Android artifacts. Their bounded acceptance requirements appear below. Resolve their SST/API decisions before implementation; none is shipped merely by appearing in this plan. Independent work can advance while hosted checks run, without launching duplicate campaigns for unchanged inputs.
6. Inventory the actual 12.1-to-13 compatibility changes as each feature lands, implement the supported migration rules and exercise generated consumers, stale inputs and recovery.
7. Improve the documentation and bounded generated project context for the delivered scope. Attempt the small production-linked Verus pilot only after the mandatory feature work is ready for its verification campaign.
8. First additional priority, explicitly requested on 20 September: evaluate rullst-supervision for transparent exam/learner supervision and parental rules within the application, ahead of other conditional extensions. Start after the required deliveries are implemented and validated, leaving time for combined acceptance and publication. The preliminary engineering estimate is one to two days for a bounded first journey and its tests, plus hosted CI; it is not a commitment to complete device-wide controls by 26 September.
9. Subsequent September 20 direction: finish usable journeys before opening more optional implementation streams. After the current deployment and supervision implementations, prioritize Bunny Stream private course video, then Labs with an actual isolated exercise/grading path. A signing helper or mock-only Labs contract is an intermediate checkpoint, not either product’s completion. Remote brokers, a new gateway and expansion of the Verus pilot follow these journeys; mandatory fixes and release checks retain precedence.

Additional priorities approved on 21 September

After the six-feature source admission, the owner selected the following two deliveries for implementation through September 23. PR #238 passed source admission and was merged into main at 0ce3306d; the v12 maintenance line is preserved. Consent and email login joined the other five increments in PR #239, which passed combined hosted and extracted-package source admission on September 22 and merged at 9f543ed5. Final release acceptance remains separate.

The email-login item now has a local Auth/Mail candidate: explicit account opt-in, independent browser/email secrets, atomic opaque-session creation, durable SQLite/PostgreSQL state, fenced encrypted delivery and deterministic localized Mail templates. Local SQLite, native PostgreSQL, Chromium, fresh-process, database-restart and extracted-facade Auth/Mail contracts passed. Combined hosted source/package/coverage admission passed in PR #239. See the email-login contract. No owner-provider accounts were used.

The owner subsequently approved the five additional items below as the next implementation queue after the two priorities, emphasizing security throughout. All seven are targeted through September 23; completion still requires the advertised behavior and its acceptance evidence. Report any unfinished item before the freeze instead of silently including it in the supported release. The previously discussed metadata-only Studio messaging inspector remains a separate candidate.

The API-token item now has a local implementation candidate with exact scopes, owner-only management, revision-based rotation, account-epoch invalidation, SQLite/PostgreSQL authoritative checks and a Core machine-route verifier. Local SQLite, native PostgreSQL, fresh-process/database-restart and HTTP contracts passed, including the extracted facade/Auth/Core archives. Full workspace, coverage, security and hosted package admission were then still required; see the API-token contract.

The shared mail-suppression item has a local PostgreSQL candidate with keyed recipient/event identifiers, namespace-bound configuration, atomic replay/quota enforcement and the existing final-dispatch guard. Native independent-pool, restricted-role, failure/cancellation, worker/tenant and process/database-restart contracts passed, including the extracted facade/Mail/Core archive consumer. Full hosted admission was then still required; see shared mail suppression.

The durable recurring-publication item has a local Messaging candidate with PostgreSQL coordination, encrypted frozen occurrences, bounded UTC catch-up and coalescing, cancellation, fenced retries and metadata retention. Native tests passed real SQL rollback/lock deadlines, restricted roles, competing instances, fresh processes/database restart and durable broker replay after lost ACK. Messaging all-feature regression and strict Clippy passed; extracted archive consumers passed the native journey. Full hosted admission was then still required; see durable recurring publications.

The outgoing-webhook item has a local Messaging candidate with an encrypted SQLite outbox, approved destinations, fresh DNS validation and address pinning, exact-body HMAC signatures, bounded retry/manual recovery and permanent cancellation. Owned HTTP/TLS and fresh-process journeys passed receiver deduplication after lost responses, untrusted certificates, redirect/private address denial, SQL failure, retention and delivery uncertainty. These journeys also passed through extracted facade/Messaging archives. A reproduced SQLite lock-contention defect was corrected: lease deadlines are sampled after acquiring the write lock. Full hosted admission was then still required; see durable outgoing webhooks.

The private multipart item now has a local Core/facade candidate with encrypted object/tenant-bound resumable checkpoints, exact-size SHA-256-checked parts, remote receipt reconciliation, completion uncertainty and bounded abort/cleanup. Owned S3 tests passed independent clients, process/service restart and both endpoint profiles; HTTP failure tests reject tampering, foreign resources, DTDs, oversized XML, redirects and embedded errors under HTTP 200. Checkpoints require durable application retention/CAS; provider lifecycle expiration handles uploads whose initiation response was lost. Full hosted admission was then still required; see private multipart uploads.

All seven then passed combined hosted source admission in PR #239. This does not freeze their APIs or admit a crates.io release. The next priorities are package readiness, targeted security review and corrections before September 24.

The September 21 dependency refresh includes aws-sigv4 1.5.3 (with its Smithy runtime API patch) in the multipart S3 evidence, and updates the Labs structural parser to wasmparser 0.259.0. Its byte offsets now use a wider range; checked subtraction preserves the existing 65,536-byte function-body limit. A parse-only boundary regression and the ordinary runner tests/strict Clippy passed locally. The Wasmi executor was pinned to 2.0.0 with its own validator; hosted isolation and package source admission subsequently passed in PR #239. The runner, and with it these dependencies, was removed from the workspace on 30 September 2026 before any independent isolation review or release acceptance.

New OpenTelemetry 0.33 proposals remain pending compatible adapter evidence. The current tracing-opentelemetry 0.33 manifest depends on OpenTelemetry 0.32; a registry probe found no 0.34 adapter release at this observation. Do not treat those five bot PRs as integrated or combine incompatible public types. The next default-branch Dependabot configuration groups the OpenTelemetry and tracing adapter family into one reviewed proposal, without ignoring updates or weakening required checks. Recheck upstream availability before the validation freeze. The v12 maintenance proposals remain separate, with the same family grouping to avoid incompatible individual updates.

Repository housekeeping on September 21

main already contains the v13 promotion from PR #238; v12 is the stable maintenance line and gh-pages serves the site. The obsolete v13 reference (d246ea07) was retired after proving it is an ancestor of main (0ce3306d). Fourteen additional remote feature references were removed only after confirming their complete history remains in main or the consolidated PR #239. Local worktrees and unique local commits were retained. Both maintained branches now require the existing 43 checks, CodeQL Rust and JavaScript analyses, and the separate CodeQL findings check from GitHub’s security app (46 in total).

Dependabot PRs #244 and #247 are superseded by the AWS and Wasm parser changes in PR #239; those compatible updates passed source admission. Individual OpenTelemetry PRs #241–243, #245–246 and #248–250 are closed as incompatible pending the coordinated adapter upgrade described above. Registry inspection still finds tracing-opentelemetry 0.33.0 as the latest stable adapter, requiring OpenTelemetry 0.32. No OpenTelemetry 0.33 adoption is claimed. Compatible v12 maintenance updates are consolidated in PR #240, preserving #251’s complete history. Its SES constraint check now expects the 1.6.4 pin while retaining the historical 12.0.0 SemVer baseline’s separate 1.6.3 guard. The combined maintenance commit passed all 46 protected checks and complete CI/SemVer workflows. PR #240 merged normally into v12 at 6dde0cb1 on September 22; no package was published.

Scorecard’s binary finding points to the trusted checked_sum.wasm test vector, not application code. Rebuilding its adjacent Rust source with pinned Rust 1.96 reproduced every byte; the Labs acceptance job repeated that check until the fixture, the job and the runner were removed on 30 September 2026. The scanner annotation records test data without suppressing SARIF output. The historical SAST finding persisted in Scorecard run 35675329836, reporting 15/30 despite verified successful CodeQL checks on all three PR heads associated with the sampled 30 commits: #228 (977e40a3, six commits), #236 (54821688, 15 commits), and #238 (87a3bdbf, nine commits). Both REST check runs and GraphQL check suites report success. Scorecard v5.5.0 reads only the first 30 check suites; #228’s CodeQL suite is 32nd, demonstrating incomplete detection. The exact remaining discrepancy is not established. The alert is classified as a false positive for this reviewed snapshot; it does not imply that every intermediate commit was scanned independently. Required CodeQL jobs now enforce both language analyses for future PR admission. Scanner output remains enabled.

The first combined PR #239 campaign exposed a Redis TLS provider-selection panic and omitted public-guide doctest registrations. The corrected Redis adapter preserves an installed provider and installs ring only when none exists; the actual Redis/TLS/restart suite and strict targeted Clippy pass locally. All three newly registered guide examples compile with their real features. Windows Labs initialization also returned Storage after about three seconds. The unchanged store passed both its local four-test suite and the fresh Windows workspace run at 5c6a8136; the original transient cause is not established. Redis/TLS, strict quality, coverage, isolated Labs and the actual archive/installed CLI campaign 35676290050 also passed on that snapshot. Other jobs were still pending, so this is not full-source or release admission.

The same snapshot’s successful CodeQL analysis workflow produced two high-severity XSS findings (#348 and #349) in the test-only email-login HTTP fixture. All dynamic HTML attribute values now use Core’s HTML escaping function. The Chromium test parses both actual rendered forms with hostile quote/tag/handler input and checks that field values round-trip without injected elements or event handlers, in addition to the original SQLite/PostgreSQL sign-in, CSRF, replay and logout journeys. CodeQL confirmed both findings fixed on head 7776ccda, with zero open PR alerts. The CI observer now checks the separate security result and PR-ref alerts; success of the analysis workflow alone never counts as a clean security scan.

Execution order may respond to measured implementation and validation cost. Do not replace full journeys with mock-only placeholders to increase the feature count. Keep September 24–25 for combined validation and September 26 for final adjustments and separately authorized publication. No owner/provider account tests are authorized; disposable local services and deterministic protocol fixtures remain available. Architectural/API decisions must be recorded in the SST as each candidate becomes implementation work.

Seven-increment source admission and package preparation on September 22

PR #239 merged into protected main at 9f543ed5326029f8e4fbf0693dd7faab9288a526. Its admitted head 7776ccda and GitHub test merge 3a84b107 have identical tree abbbade9.

• All 46 protected requirements and 24 PR workflows passed. Additional S3 and isolated Labs jobs passed, both review threads were resolved and CodeQL had zero open PR alerts.
• Coverage passed both unchanged 90% floors: 108639/120114 whole-repository lines (90.4466%) and 80139/87903 governed library lines (91.1675%, 627 files). Downloaded nextest evidence records 2744 all-feature cases in 234 suites with no failures, errors or skips. Default/browser/database profiles ran separately.
• Archive acceptance audited 21 diagnostic archives, exercised archive-only consumers and compiled all six blueprints with the installed CLI. Diagnostic archives do not establish release eligibility for the four packages then excluded from publication.

The next publication-configuration candidate adds standalone rullst-supervision and rullst-media to the synchronized inventory (19 packages). Both preserve empty default features and explicit application authorization. Their archive consumers and the generated LMS supervision journey now run in the ordinary release rehearsal, without the diagnostic flag. The CLI upgrade inventory includes both names. Supervision’s stable CLI generator pins the matching registry version; prerelease evaluation still requires the matching local source and rejects absent or wrong source before applying edits. The reviewed initial-registration allowlist contains Privacy, Supervision and Media; the registry ownership check still rejects another owner. A read-only crates.io check on September 22 found all three names unregistered. The normal release workflow still rejects unregistered names; the allowlist does not enable a bootstrap credential path. No initial registration, tag, release approval or publication has occurred. (Update: make:supervision and its generated LMS journey were later removed with the complete Academy scaffold. The release rehearsal now tests the extracted Supervision archive directly and compiles only the SaaS age/privacy opt-ins.) (Update: all three names were first published in 13.0.0-alpha.1 on October 11, 2026.)

rullst-labs and rullst-labs-runner remain publish = false, outside the release inventory and available only through explicit diagnostic packaging. Their independent isolation-review requirement is unchanged. (Update: the runner candidate was removed from the 13.0 workspace on 30 September 2026; see the M40 row below.) The publication changes require their own hosted campaign and actual archive acceptance; previous-source results above do not admit them. Bunny account/CDN acceptance remains unvalidated. (Update: on 8 October 2026 the maintainer admitted rullst-labs to the release inventory as 13.0.0-alpha.1; it packages contracts only, and the removed runner is not published.)

This candidate also incorporates the newly opened Dependabot PRs #253 and #254: SES 1.136.0 and compatible AWS runtime updates, tokio-rustls 0.26.5, and immutable install-action 2.87.16 pins. Their declared Rust requirements stay below the 1.96 MSRV; the combined platform, feature and archive campaign is still required. The corresponding v12 PRs #252 and #255 require their own maintained-line compatibility checks.

The framework README now highlights the separately maintained Rullst Academy. Its public landing page returned HTTP 200 on September 22 and describes free Rust/Rullst and broader technology learning in Portuguese, English and Spanish. This is a product link, not validation of private accounts or application flows.

Depth before additional optional features

The owner asked to pursue a complete, comprehensive implementation of Bunny and Labs before moving to other new capabilities. Finish the supported user journey, its failure/recovery paths, integration documentation and executable acceptance before widening the provider, language or backend matrix. This changes priority and the intended outcome; it is not evidence that either implementation exists or a promise to finish both by the 26th. The feature freeze and validation dates remain unchanged.

Divide implementation into small reviewable commits and PRs without declaring the journey complete early. While hosted checks run, advance related documentation, recovery tests and packaging. Move implementation effort to the next journey after the preceding supported lifecycle and focused acceptance pass; required hosted admission may continue independently. Do not open an unrelated optional feature while useful completion work remains.

If a journey cannot meet its acceptance by the evening of September 23, report the precise unfinished behavior and keep it out of the stable supported scope. An independently useful contract package may remain explicitly experimental, but cannot be presented as a completed execution product. Preserve the reserved validation days and the isolation, provider-evidence and publication requirements.

A provider adapter advertised as live-validated requires environment, protocol and acceptance evidence. The owner’s later direction allows opt-in integrations with automated protocol evidence and explicit unvalidated-provider status; do not use personal/live libraries for testing. Provider availability does not suspend independent framework work. The final privacy package scope must accurately identify every supported method; unimplemented facial or provider methods cannot be advertised as functioning production verification. The package remains unpublished until its scoped consumer/state/API and release admission criteria pass. (It was first published in the 13.0.0-alpha.1 prerelease on October 11, 2026.)

Blueprint scope and automated acceptance

On September 20 the owner prioritized implementation and testing over extending every new feature to every blueprint. Keep existing working integrations and their regression tests. For new work, choose the smallest real consumer that exercises the capability: supervision in LMS, billing entitlements in SaaS, and a focused server/client fixture for an API contract. A public generator must still test each supported output shape; do not advertise an untested shape. Additional blueprint coverage belongs in the release only when it demonstrates a different supported contract or provides clear product value. Opt-in features must remain opt-in, and source/manifest, authentication, persistence and packaged installation checks cannot be replaced with mock-only examples.

Since 13.0.0-alpha.4 cargo rullst new keeps three starters (Blank, API and SaaS). The LMS, ERP and Portfolio blueprints became workspace examples under examples/ with their own tests, the Blog blueprint was dropped in favor of the existing blog showcase, and the CLI’s generated-project gates cover only the three starters.

Human exploratory testing is not assumed to be available during this delivery window. Use automated unit, integration, real-database, HTTP/browser and failure tests appropriate to each supported feature. Record environmental and usability limits explicitly; neither AI authorship nor a passing suite proves every deployment. Missing provider/device/isolation evidence stays missing and limits the supported scope. Defer optional scope and non-critical improvements when needed, but fix known authorization, privacy or data-integrity failures before admission. The possibility of a later patch does not turn a failing contract into an accepted release.

Starting evidence

• All sixteen v12.1.0 packages are published from b62390b4; the release record retains their receipt.
• The post-release closeout in PR #217 merged into main at 184bc1f7 on 20 September UTC, after 84 successful checks and three skips. It records publication, repairs mutation discovery and corrects the SemVer baseline resolver; the published source and artifacts remain unchanged.
• The integration candidate carries that exact published runtime source into v13, preserving the unpublished privacy crate and Labs/Verus plans. The combined source needs fresh CI; the v12.1.0 results do not certify v13.
• PR #218 admitted the integration and SQLite/PostgreSQL replay foundation into v13 at 7f48d882 on 20 September UTC. Its reviewed head 03601566 passed 85 hosted checks with four declared skips, including workspace tests, strict Clippy and the exact coverage floors. Three remaining review threads referred to the already individually reviewed test-only alerts 327–329 and were resolved after rechecking those fixtures and their existing dispositions. The later native declaration, challenge transport and generated consumers require their own hosted campaign; this admission does not certify those subsequent changes.
• The initial privacy foundation passed 16 integration tests and one doctest. The persistence change adds asynchronous verification, trusted clock rechecks and optional shared-local SQLite claims. Its 29 local integration tests cover independent pools, a fresh process, reopen, concurrency, quota, cancellation and failure paths. Hosted candidate validation and a live age provider remain outstanding; this is foundation evidence, not end-to-end production acceptance.
• The PostgreSQL candidate passed focused real-database bootstrap, restricted runtime-role, multi-pool replay/quota, expiry during lock wait, schema/durability drift, cancellation and server-restart checks. CI and coverage explicitly run that disposable-database contract; combined candidate evidence is still required.
• The next local increment adds native declarations and authenticated challenge transport, plus an opt-in generated SaaS dashboard journey. Local checks passed 42 privacy integration tests, one unit test and five doctests; the disposable PostgreSQL lifecycle and restart contract also passed explicitly. A generated SaaS executes real session/user lookup, production browser middleware, explicit choice and durable replay denial; a second process verifies missing-key denial, and the PostgreSQL consumer profile compiles. Installer tests cover formatted source, changed authentication, source selection, preserved edits and rollback after a write failure. Strict local CLI Clippy and book/link checks passed. The follow-up LMS consumer also passes a generated SQLite journey: bounded school selection, real membership/role resolution, header selection carried into a browser form, cross-school/user denial, replay and revoked membership. Its declaration writes no subject-age or guardian-consent row and does not install age-state middleware around other learning routes. Hosted admission and broader purpose/rights workflows remain outstanding; these checks do not establish deployed browser/provider acceptance.
• The initial CodeQL scan’s 26 age-replay alerts were individually reviewed: 23 intentional integration-test identifiers, two policy-field data-flow conflations and one unmodeled OS-random buffer overwrite. The review receipt binds those dispositions to the analyzed source. No query, workflow or source/test path was excluded.
• The initial review found main-only release admission/security filters and an unprotected v13 branch. The preparation change binds each major to its release branch and enables the missing automatic checks. On 20 September UTC, hosted v13 protection was enabled and read back with 43 required existing checks; the observed profile records its scope. Combined hosted evidence and packaging remain pending.
• The v12.1.0 post-release mutation campaign is informational. Its repaired controller discovers the measured source’s complete inventory and limits the 80 shards to four concurrent jobs. Findings are reviewed separately from v13 readiness, with security-relevant corrections carried to each affected line.

Release priorities and acceptance

The next local increment adds two privacy fuzz targets to the v13 release inventory (42 total; v12 remains 40). Two five-minute ASan diagnostics completed without a reproducer: 1,442,644 challenge-token inputs and 929,346 attestation inputs. These are local diagnostics, not the complete hosted release campaign. The independent consent/consent-sqlite foundation now provides explicit purpose/notice choices, revision-bound grants, unconditional withdrawal, default denial and per-action checks. Its shared-local adapter retains bounded state and clock metadata, refuses implicit initialization/repair and preserves withdrawal across pools and processes. Local contracts cover stale forms, version/tenant/subject boundaries, capacity, clock/expiry, cancellation and faulty adapters. The opt-in make:privacy consumer now supplies authenticated preferences, an optional name-based greeting and a direct own-account profile export through a concrete parameterized SQL adapter. Local generated SaaS/full LMS HTTP fixtures passed both age/privacy installation orders, explicit choices, withdrawal and stale grants, CSRF, account/session/school changes, expiry, unknown and oversized inputs, and missing/failed consent state. The profile export stays independent of optional-consent storage and form keys and never claims to export other application records or complete queued rights requests. A normal PostgreSQL-primary SaaS profile also compiles; live primary-database isolation and deployed browser acceptance are separate from that compile check.

These HTTP fixtures found a Core header composition defect: the outer layer replaced an endpoint’s no-referrer. Core and both Security header layers now share a narrow preservation rule; 36 local composition cases cover layer order, configured defaults, weaker handler policies and duplicate values. The prior PR #219 campaign finished with 84 successful checks, four skips and one macOS unit-fixture failure caused by the system temporary-directory symlink. Its fixture now resolves the same root as the CLI, with an explicit child-symlink rejection regression. Four new CodeQL policy-threshold conflations were individually reviewed and dismissed; the declaration review receipt binds those decisions to the old analyzed source. No query was disabled. PR #219’s corrected head d783f3b7 subsequently passed 85 hosted checks with four declared skips, including all-feature workspace tests, strict Clippy, coverage floors and the generated privacy consumers. It merged into v13 at df589770 on 20 September UTC. This admits that privacy increment; it does not certify the later adoption, Android or entitlement changes.

The next adoption increment gives the existing sixteen release packages and their internal requirements the explicit development version 13.0.0-alpha.1. Privacy remains unpublished. Migration catalog v2 admits source major 13, retains target-major selection and downgrade rejection, and invalidates old preparations. Local updater contracts exercise a distinct 12.1.0→13 resolution, review, stale-input rejection, application and recovery. Both executable names report the actual source version; prerelease tests keep the explicit opt-in. The adoption guide inventories the current additive changes and distinguishes tiny updater protocol packages from actual generated framework consumers. Combined hosted acceptance and an unpublished package rehearsal remain outstanding.

The development train passed 348 local CLI unit tests, 46 updater process contracts, 32 command/scaffold contracts and the generated foundation matrix (Blank/API, SaaS and full LMS, including LMS authorization negatives). Release preflight still identifies sixteen publishable packages with a consistent version and topological order; it does not admit the unpublished privacy package. Strict CLI all-feature/all-target Clippy and production panic checks passed. These are local checks, not the outstanding combined hosted/package campaign.

The Android candidate now binds one fresh bounded APK to the application’s expected certificate through the SDK verifier, checks its final bytes, rejects stale/ambiguous outputs and withholds captured signing-tool diagnostics. Native process fixtures exercise success, explicit selection, wrong certificates, missing/stale/oversized/changed files, verifier/build failures and output/time bounds. The hosted Android workflow now exercises this CLI against a real signed release and independently checks its certificate and receipt. That new hosted SDK job passed on PR #220 head 52657955: it compiled and verified a signed release APK through the CLI and the independent SDK check (run 35497371156). The rest of the combined campaign remains pending. This is SDK interoperability evidence; device/store acceptance remains separate.

The PR #219 follow-up CodeQL analysis reported one additional threshold-to-nonce conflation in the isolated privacy fuzz helper. Alert 338 was individually reviewed against SARIF 1806278303 and dismissed; the fuzz-policy review receipt records the exact source and reasoning. The policy literal is 18; the fuzz-only nonce is a separate deterministic fixture, and production issuance retains OS entropy. No source path, query or fuzz target was disabled.

PR #220 head 52657955 passed the real SDK signed-APK job, but its coverage and macOS CLI campaign exposed two Android fixture/build-timing issues. The follow-up preserves OS process helpers in the fixture PATH and compares artifact timestamps against a temporary filesystem anchor. Local native selection and redaction scenarios passed after correction; a fresh combined campaign is required.

PR #220 admitted the adoption, Android and conditional supervision-planning changes into v13 at 6ccbe2a7 on 20 September at 14:20 UTC. Its exact head ee4f46df completed 86 successful checks and four declared skips, with no unresolved review threads. This includes the full OS/workspace matrix, strict Clippy, coverage and the real SDK signed-APK job. The initial campaign’s changelog, filesystem timing and terminal prerelease fixture failures were corrected without weakening their checks. This admission does not certify the later entitlement, context, API, Verus or packaging changes.

The entitlement candidate adds a typed current-state gate in Capital and an authenticated SaaS billing report. It requires an exact server plan allowlist, fresh revision-fenced Stripe reads, a matching live/sandbox mode and an active, unexpired subscription. The six focused local contracts passed tenant/owner, status/mode, revocation, expiry, stale/future clock and adapter-failure cases. The existing generated SQLite/Turso billing contract also passed. The additional generated SaaS HTTP/reconciliation fixture passed all four configuration profiles, including real session/owner checks, a delayed active read losing to revocation, the 20-second provider deadline and strict generated all-target Clippy. Its test-only provider boundary is explicit; it is not a live Stripe acceptance run. CMS projections and offline billing fixtures cannot grant the new report. Local validation also passed the public doctest, strict Capital default-feature all-target Clippy, CLI all-feature/all-target Clippy, production panic checks, 353 CLI unit tests (one parent-owned child fixture ignored by the outer harness), 20 command/scaffold contracts and book/local links. Combined hosted acceptance remains outstanding.

The project-context candidate replaces raw source concatenation with a bounded, versioned file/dependency/configuration-key inventory. It creates common project instructions only when absent, preserves user AGENTS.md, supports non-writing freshness checks and records source scope/exclusions explicitly. Local contracts cover private-value omission, links, size/depth/count budgets, stale inputs, legacy migration, conflicting output and all six generated blueprints. Semantic route/authorization inference and task-specific context shards remain follow-up work; the guide states the exact candidate boundary.

The schema-first API candidate now generates Rust DTOs/operation codecs and a strict TypeScript client from one bounded OpenAPI 3.1 JSON profile. Seven generator contracts cover unsupported shapes, links, duplicate keys, collisions, regeneration and freshness. Local validation passed 371 CLI unit tests (one parent-owned child fixture ignored), strict all-target Clippy, the real generated Rust/TypeScript HTTP consumer, ten existing command contracts and the six-blueprint context journey. The HTTP fixture proves typed statuses, Unicode, optional/null semantics, exact safe integers, nested nullable arrays, unauthenticated/cross-owner denial and adversarial transport rejection. A GET-only Rust module also compiles with strict Clippy. Hosted Linux CLI acceptance requires the pinned TypeScript compiler and the actual HTTP journey; combined hosted admission remains pending.

The Verus pilot has a local candidate for the unchanged production AgePolicy::permits predicate. Rust syntax extraction checks the actual package, module path, enum/type/signature domain and body; the verifier covers all nine risk/method combinations. Both local runs verified the predicate and rejected all three deliberately incorrect implementations. They took about 12.1 seconds including complete pinned-tool validation, with prover peak RSS below 292 MiB. The runtime age suite and MSRV 1.96 check passed. The prepared manual workflow is separate from release admission; clean hosted evidence and any promotion remain pending. See the proof boundary; this does not prove age evidence, expiry, replay state or application authorization.

The next packaging candidate adds rullst-privacy as the seventeenth package, with its license, a bounded source archive, opt-in rullst::privacy features, coordinated upgrade inventory and registry-shaped age/privacy generators. The local seventeen-archive packaging/content audit and the durable facade reopen test passed. Both generated SaaS/LMS privacy journeys passed, including the registry-shaped LMS dependency and the existing local-source SaaS profile. Context freshness for both new commands, 372 CLI unit tests (one parent-owned child fixture ignored), strict CLI Clippy and the minimal facade panic gate also passed. A separate consumer compiled only the extracted framework archives and passed that durable facade test. All 42 fuzz targets’ eleven locked dependency graphs resolved offline without running a new fuzz campaign. Combined hosted acceptance remains outstanding. All seventeen local archives were subsequently generated from clean commit 30e2f753; their source identity, licenses and excluded secret/database paths were audited. The archive-only privacy consumer and privacy publication dry run passed without uploading a version. These are local rehearsals, not final release receipts. The archive-only hosted test then compiled the installed CLI’s SaaS/LMS opt-ins and executed the same durable facade contract from extracted packages. It passed at 365d2252 in run 35520146394 on September 20: seventeen package archives were audited, the durable facade test passed and all six installed-CLI blueprints compiled. This diagnostic does not replace the final full/native release campaign or publication authorization. A crates.io read on 20 September returned 404 for rullst-privacy; initial registration and Trusted Publishing configuration remain required. The stable publisher continues to reject an unregistered package. The ownership-policy validator now checks each proposed bootstrap name against the inventory, with unknown/duplicate/malformed-name negatives; the empty bootstrap allowlist and the stable publisher’s refusal remain in force.

PR 220’s Linux terminal fixture also needed an explicit prerelease dependency requirement and --prerelease when exercising the alpha CLI. All four local terminal scenarios passed after that correction: decline copying, decline execution, apply/recover, and a failing application. The corrected ee4f46df head then passed its own combined hosted campaign, as recorded above; previous Android/macOS passes were not substituted.

On 20 September at 07:31 UTC, the first four v12 mutation shards had hit their 330-minute execution budget; their partial artifacts were retained. For example, shard 2 had executed 72 of 220 scheduled mutations (40 caught, 30 surviving, two unviable), so it is explicitly incomplete. Surviving mutations require individual review and are not automatically confirmed runtime defects. The remaining campaign continues; partial results must not be reported as a complete mutation pass, and any later continuation must preserve source/inventory identity.

The first combined PR #221 campaign at 4773171a passed 85 checks, including the OS/workspace and generated consumer matrix, strict Clippy, coverage, feature boundaries and MSRV. Two inventory checks failed: the README omitted the added Verus workflow, and the observational scorecard omitted the seventeenth package. The correction retains both checks, adds a conservative unpublished privacy ceiling and preserves its planning floor. The corrected head requires its own hosted admission. A new explicit package-only diagnostic runs the existing archive/installed-CLI acceptance without repeating the OS matrix; a regression proves that this subset cannot admit a release.

The corrected 365d2252 head subsequently passed 87 hosted checks, with four declared skips and no unresolved review threads. PR #221 merged normally into v13 at 48a6ee51 on September 20 at 17:23 UTC, with all 43 required checks and administrator enforcement preserved. Its seventeen-archive/installed-CLI diagnostic passed separately as recorded above. This admits the combined application/privacy candidate; the final full/native/security release campaign and initial new-package registration remain outstanding.

The first conditional supervision implementation now has a separate unpublished crate, bounded domain contracts and shared-local SQLite state. Its focused local tests cover explicit acknowledgement, scoped/revocable authority, session transitions, event bounds, parental course windows, retention, fresh-process reopen, concurrent revisions, lock-wait expiry, cancellation and corrupt rows. An explicit full-SQLite-LMS generator now installs the original learning-service gate, signed/scoped SSR forms, local operator provisioning and a bounded visibility collector. Three local CLI integration tests pass, including both privacy/age composition orders, public-profile compilation, the real HTTP lifecycle and Chromium keyboard/no-JavaScript/visibility controls. A start form is bound to the last retained session revision so an old acknowledgement cannot silently start a new session after end. The generated application passes all fourteen original LMS library tests and strict production Clippy/zero-panic checks, and all 376 CLI library tests pass. These local results do not admit the package: full workspace regression, installed archives and hosted acceptance remain outstanding.

PR #222 head 20a9fca7 subsequently passed 86 hosted checks with four declared skips and no unresolved review threads. Its independent packaged-distribution run 35534311217 also passed at that exact head. The supervision source merged normally into v13 at 081c3805 on September 20, 21:14 UTC, preserving all 43 required checks and administrator enforcement. This admits that source increment; stable package registration/publication and the final combined v13 campaign are still outstanding. The next shared-passkey candidate is under its own hosted campaign; the deployment/body and local diagnostic increments remain separate.

The local deployment diagnostic passed seven executable contracts, including a generated SaaS, and two additional literal-parser/boundary contracts. All 376 previous CLI unit tests passed; strict all-target CLI Clippy, book/local links and architecture checks passed. A bounded six-mutation decision sample was fully caught. Inspection also reproduced acceptance of the public .env.example application-key placeholder in Auth; explicit rejection now passes the runtime regression, 65 Auth unit tests and three key-resolution process contracts, with strict all-target Auth Clippy. These are local candidate results; hosted and installed-package acceptance remain outstanding. The corresponding stable-line backport still needs preparation and its own checks; published artifacts remain immutable.

The next four source increments were merged into v13; their evidence is recorded individually below:

• PR #223, shared PostgreSQL passkey ceremonies, merged at b354d67c. The exact 15addc3d candidate passed hosted checks and archive acceptance.
• PR #224, HTTP response-body draining and the Caddy/Redis deployment contract, merged at a4a3b3e6. The exact 2e348f96 candidate passed hosted checks and archive acceptance.
• PR #225, deployment diagnostics and rejection of the public Auth key placeholder, merged at 873bc14a. The exact 45a573cc candidate passed hosted checks. The archive job in run 35554979487 was skipped, so that run is not archive acceptance. Correctly selected exact-commit validation subsequently passed on September 21 at 06:32 UTC, including the actual archive audit, extracted consumers and all six installed-CLI blueprints. This repairs that missing gate retrospectively.
• PR #226, transparent exam observations and bounded analysis adapters, merged at bb71dad8. The exact ae9b6d57 candidate passed 86 hosted checks. The archive job in run 35558912935 was skipped, so that run is not archive acceptance. The correctly selected exact-commit validation subsequently passed on September 21 at 06:27 UTC, including the actual archive audit, extracted consumers and all six installed-CLI blueprints. This repairs that missing gate retrospectively.

The September 21 audit found that these last two merges preceded their required installed-archive validation: a successful workflow was incorrectly credited despite its skipped archive job. Both gaps are now repaired by the actual exact-commit runs recorded above. These retrospective results do not erase the missed premerge gates; subsequent source admission requires checking the named archive job itself before integration.

These merges do not publish packages or replace the final combined release campaign. Bunny subsequently passed its own source admission in PR #227: the exact b21d52e7 candidate passed all 87 current checks, the actual installed-archive job, and review with no unresolved threads, then merged at 618655c1. PR #228 subsequently admitted Labs source at 278a115b. Candidate 977e40a3 passed all 24 native shards, 43 branch-required checks, actual isolated execution, the actual installed-archive job and both 90% whole/library coverage floors. Its non-required Codecov patch check remained at 83.45936%, below its 90% target; the profile evidence records this limitation without exporting worker profiles or relaxing isolation. Independent isolation review and final release admission remain outstanding. Stable-line backport preparation remains separate as well.

The September 20 observation extension now adds selected browser categories, capture-status contracts and bounded analysis adapters to the supervision candidate. Its five generated CLI/composition/process contracts pass with real Chromium, alongside 378 CLI unit tests, isolated feature checks, strict Clippy and an offline simulated adapter example. A targeted nine-mutation guard sample is fully caught. No camera/audio model, automatic misconduct determination or live-provider validation is claimed. Hosted workspace checks passed in PR #226; the missing archive gate subsequently passed as recorded above. The final release campaign remains required. See the integration guide.

P0 items have precedence over new integrations, cosmetic rewrites and expanding the number of crates. Each implementation should remain a small reviewable change with its own tests and migration/documentation updates. The acceptance column is a requirement, not a description of code already present.

Coverage of the wider roadmap

Additional increments approved on September 21

The owner approved the following order after the Bunny/Labs source work. Finish each supported journey and its acceptance before expanding its advertised scope. The six implementations passed the source admission recorded below; their combined dependency validation and final release admission remain separate.

Six-increment source admission on September 21

PR #236 admitted all six increments at source 548216881e062b83d6b73a824abe140936aca5b8. It merged normally into protected v13 at d246ea072a0bddd1ced86471c49ffdb22d2b96cc; its tree matches the tested merge candidate. Evidence for this source:

• Rust CI: all 43 protected requirements passed, including the Linux/macOS/Windows matrix, strict Clippy, format, MSRV and feature boundaries. Private S3 and isolated Labs acceptance also passed. All 21 relevant PR workflows completed successfully.
• Coverage: 103382/114571 whole-repository lines (90.2340%) and 74906/82383 governed library lines (90.9241% across 581 files). Both unchanged 90% floors passed; the downloaded summary was independently checked. The all-feature nextest artifact records 2701 cases with zero failures, errors or skips; default, browser, database, collector and isolated-controller profiles ran separately.
• CodeQL: Rust and JavaScript scans bound to the exact merge source completed with zero open findings. All seven review conversations were resolved.
• Packaged distribution: 21 candidate archives audited, archive-only consumers exercised, and all six blueprints compiled through the isolated installed CLI. The actual package job executed; skipped diagnostic jobs were not credited as PR checks.

This admits the documented source contracts, not a crates.io release or every parent roadmap milestone. No owner/provider accounts were exercised. The Labs profile retains its separate independent isolation-review boundary. The new main-line dependency combination must pass its own exact-source campaign.

After this approved round, report the delivered scope and remaining time to the owner before selecting another round. September 24–25 remain reserved for combined validation; September 26 remains the conditional final-adjustment and publication day. Publication is excluded from the current implementation goal.

The master roadmap owns the current status of the framework milestones and the separately governed M31 programme. Its milestones differ substantially in scope and remaining effort; counting their status labels cannot tell us whether this release adds “10% of all future work”. Nor does finishing one increment close its entire parent milestone. The wider v13/v13+ programme remains available for subsequent minor releases.

Items deferred beyond the September 26 target do not automatically become v14 work. Compatible additions can ship in 13.1, 13.2 and later minor releases; breaking changes belong in a future major under the compatibility policy. The current major’s concrete CLI/configuration change and the limits of its SemVer evidence are recorded in the migration inventory. The owner explicitly confirmed retaining the v13 release train on September 20.

This queue deliberately builds on existing code instead of restarting those capabilities. Within P1, a small independent increment can precede a larger one when its dependencies and verification capacity are ready.

Gateway/load-balancer implementation, physical IoT/Embassy, PQC protocols, local facial inference and broad database replication retain their dedicated roadmap scope. They are not counted as completed by a proposal, an empty crate or a mock. Reconsider them through their own dependency and acceptance evidence instead of promising the whole long-term programme by the 26th.

At each implementation checkpoint, record the delivered behavior, source, focused checks, pending hosted checks and next useful increment. The decision to start the next item uses remaining integration/test capacity as well as coding time. Preserve working increments and report unfinished acceptance explicitly; do not inflate a feature count by splitting contracts into crates.

Age and privacy design decisions to close first

Keep age assurance and reusable privacy contracts in the existing optional rullst-privacy package. Do not add a second age crate or make cameras, a vision runtime, a database or a provider a default Core dependency.

The v13 ReplayStore::claim interface now returns a statically dispatched Send future. Verification samples a trusted clock before validation and after storage, denying expiry or rollback during the wait. The initial SQLite adapter uses serialized durable transactions, persisted quota/clock metadata and hashed nonces. Local tests cover independent verifier pools, reopen, simultaneous claims, capacity, expiry, cancellation, uncertain acknowledgement and unavailable storage. Native hosted evidence remains pending. Its shared-local boundary is distinct from the PostgreSQL adapter’s multi-host operation; restoring an old backup requires quiescing verification and invalidating all outstanding challenges through a newly enforced policy or retired signing keys.

Use the current server-owned policy and signed threshold result rather than storing photos or full birth dates in the framework. Provider authenticity, subject/session binding and the quality of an age determination are separate contracts. A facial estimate cannot silently become a verified age attribute. Every denied, inconclusive or unavailable result needs an explicit product outcome; an alternative path must meet the same policy instead of bypassing it.

A live adapter requires an available authorized sandbox, a reviewed native protocol, failure tests and appropriate provider/capture evidence. The release owner confirmed that no provider environment is available and directed work on the foundation and local tests first. Prioritize that independently testable scope while the external dependency is unresolved. If it remains unavailable, do not label a simulated flow as live verification or mark the provider milestone complete. The approved independent foundation has its own consumer/state/API acceptance; any live adapter additionally needs its provider acceptance. Review this precise publishable package boundary at feature freeze, preserving the security guarantees of every advertised method.

For broader privacy, implement reusable processing controls and one real consumer journey before claiming coverage across every blueprint. Keep policy applicability, notices, processor obligations and external legal review explicit. The privacy roadmap remains authoritative for the wider jurisdiction and provider programme; this plan does not certify GDPR, LGPD or worldwide compliance.

Improvements that reduce maintenance friction

1. A current source baseline. Synchronize stable fixes before feature work; avoid repeatedly rediscovering or reintroducing already repaired SaaS, mail and updater problems.
2. One executable test map. Preserve complete test inventories and choose focused development checks from actual crate/dependent changes. Unknown, security, generator, dependency and workflow changes retain conservative coverage. Measure job execution separately from runner queue time.
3. Accurate generated guidance. Derive agent instructions and context from the chosen blueprint/features. Link to version-matched public APIs and commands; do not include credentials or imply that optional adapters are active.
4. Small complete examples. Use reproducible SaaS/LMS reference journeys with negative ownership, replay, withdrawal and recovery assertions. A compiling tutorial alone does not establish those behaviors.
5. A durable progress record. Record the source, checks, limitations and next action for each delivered item. Avoid duplicated readiness statements that drift apart across the README, roadmap, spec and release guide.

These implement the narrow first phase of the AI-maintainability roadmap. Broad model benchmarks and quality guarantees about arbitrary assistants are outside this release window. Keep changes modular; avoid unrelated mass refactoring merely to meet a line-count target.

Calendar and scope control

Superseded deadline: the owner revised this calendar on September 22. September 26 is no longer a required publication date. Use the checkpoints below as the original sequencing record; prioritize stable maintenance and completed, tested journeys under the revised plan.

Dates below use Brasília time. Work may move earlier when its dependencies and checks are ready; slow external acceptance reduces scope, never test quality.

The owner reconfirmed this calendar on September 20: prioritize remaining implementation through September 23 by user benefit, maintenance cost and acceptance capacity; reserve September 24–25 for validation/corrections and September 26 for final adjustments and protected publication. Local deployment configuration diagnostics and the supervision observation extension are merged with hosted checks passed. Their archive gaps have now been repaired as recorded above. The owner’s subsequent direction selects the complete supported Bunny journey next, followed by usable Labs execution and grading, before remote messaging or other optional expansion. Bunny has passed source admission; Labs has now passed source admission with its remaining quality, independent-review and release requirements tracked above. Increasing the crate count is not a priority.

The owner subsequently requested no manual or real-provider account testing in this window, including the confirmed existing Bunny library. Continue automated local/hosted tests, disposable databases and protocol fixtures. Preserve required regression/security gates and report unvalidated provider interoperability explicitly; do not describe simulated acceptance as a live integration pass. New optional provider scope can be delivered with that stated limitation, rather than waiting for manual tests or using the owner’s live resources.

At the feature freeze, move unfinished optional work to a named follow-up rather than leaving partially enabled behavior in a stable release. A blocking age, authorization, data-loss or migration defect is not an optional follow-up. Keep approved feature scope in the release notes and tests; do not mark the historical roadmap complete merely because the version is published.

Verification and final publication

Run cargo test --workspace --all-features, strict workspace/all-feature Clippy and formatting, plus the existing feature, threat, provider-protocol, generated-application, native-platform and release gates. New privacy parsers, state transitions and durable adapters need their own meaningful negative, concurrency and fuzz/property coverage. Local focused passes never substitute for the final workspace campaign.

Use hosted CI for builds whose peak cannot fit the workstation’s reserve; retain at least 12 GiB available and intervene at 15 GiB. Reuse verification only through the existing explicit input-equivalence/admission policy. Changes to a candidate invalidate the affected evidence; neither a green older commit nor cached compilation is a release result.

Before tagging, check every package/internal requirement, lockfile, release order, architecture edge, feature forwarding, CLI version string, documentation link and supported-platform claim. Include the new rullst-privacy, rullst-supervision and rullst-media packages in publication only after their advertised package scopes meet their gates and their ownership/trusted publisher configuration is ready. Confirm 12.1→13 consumer behavior, authenticated native assets, attestations and the protected deployment approval. Published 12.1.0 tags and archives remain immutable.

Execution proceeds within the active authorized session, while GitHub jobs can continue independently. Session availability and a running CI job are different things; this plan does not promise an unattended uninterrupted week. At each handoff, retain the next action and distinguish work still possible from work actually waiting on an external result.