Quality scorecard

Audit reopening (2026-09-05): the second-computer CLI handoff and new negative regressions revealed gaps outside the earlier test inventory. Scores and ceiling-completion statements below describe the previous campaign; they are not a current release approval. See the v12 release audit for reviewed scopes, corrections and gates that must pass before reconfirming those conclusions.

Rullst generates an evidence-bound quality scorecard for every push to main and every pull request. The report is attached to the corresponding Rust CI run as quality-scorecard-<commit SHA> and is also written to that run’s job summary.

The permanent source of a run score is therefore the commit plus its workflow run, not a mutable badge. The versioned expert-audit ceilings live in .github/quality-scorecard-policy.json; CI can reduce them when required evidence fails, but a green run cannot inflate them.

What the score measures

Specialist evidence includes database/Redis live matrices, AI evals, the threat minimum, release local-access negatives, provider matrices, the facade’s shared-local recovery composition, and Messaging’s wire/trace, encrypted SQLite and ORM outbox crash-replay cases. Failed, cancelled, or skipped applicable gates suppress the dimensions they prove; the report is still generated so a red push cannot hide its note.

Documentation/DX evidence also includes a Cargo-aware aggregation of the 52 public tutorials. It consumes the Markdown files directly during the normal all-feature doctest run, so a green workspace test proves the standalone Rust examples compile on that SHA; explicitly contextual fragments remain visible as ignored and do not count as compiled examples.

Grades use the following fixed bands: A+ 97–100, A 90–96, B 80–89, C 70–79, D 60–69, and F below 60.

The v12 RC quality objective is A (90) or better for every crate except rullst-iot, whose approved floor is B (80). A+ is an evidence threshold, not a value to assign by intent. This owner-approved gate is deliberately stricter than the earlier all-B floor and reopens bounded implementation work before the feature freeze. It does not pre-approve a commit: the exact SHA still earns each ceiling only when every constraining gate succeeds.

Current audited green-gate scores — 3 September 2026

These are the maximum current scores when every referenced Rust CI gate passes. They are not presumed results for a new commit; the exact per-SHA artifact applies the real gate outcomes and includes the full finding for every row. They are also not the highest scores that future repository-owned work can earn. Here, current audited score means the score supported by code and evidence already present; local campaign ceiling means a planning target that must still be earned. Keeping those columns separate prevents a desired score from being published as an achieved one.

Measured gap to the v12 quality gate

Every non-IoT crate now has an audited ceiling of A or better, while IoT meets its approved B exception. The gap to the required grade is therefore zero. This also closes the repository-owned ceiling campaign, but it does not authorize a release: the exact RC SHA must still make every conditioning gate green, including the dedicated facade composition job.

Maximum-local v12 campaign

The release floor is not the stopping target. The table below records the provisional highest score that the current campaign can responsibly pursue with repository-owned implementation, deterministic fixtures, local services, CI and documentation. These targets do not alter the scorecard policy and must not appear as achieved scores until their evidence is implemented and green on the exact commit.

The campaign is scoped to the 15 non-IoT crates, v12 quality, and the historically promised [x] capabilities. IoT remains audited at its accepted 83/B evidence but is outside the remaining ceiling work. The campaign does not pull every open v13 idea into the RC. External provider acceptance, app-store/device testing, fiscal homologation, independent audit and production operation remain external even when a bounded implementation earns a high A.

All 15 active crates have now reached their audited local target: rullst-core, rullst-macros, rullst-orm-macros, rullst-messaging, rullst-capital, rullst-mail, rullst-auth, rullst-nexus, cargo-rullst, rullst-studio, rullst-orm, rullst-security, rullst-connect, rullst-ai, and the umbrella rullst facade.

On this planning scale, 100% of the maximum-local v12 target is now backed by committed evidence and zero planning points remain. Awarding those points is still conditional on every applicable gate succeeding for the exact SHA; this completion is not a release decision or an external validation claim. rullst-iot is the only accepted campaign result below A; its approved B exception reflects missing physical/device evidence rather than lowering the release gate for the other 15 crates. This table must be re-audited whenever implementation reveals a stronger or weaker boundary.

The final point allocation may differ from these candidate clusters after code review. External provider acceptance, fiscal homologation, device testing, store publication, and independent audit must stay explicitly external even when enough repository-owned evidence exists to reach A.

What the score does not measure

The score is not:

• feature completeness or roadmap percentage;
• a claim that every crate has the same maturity;
• provider acceptance, device/store validation, fiscal homologation, or a security/compliance certification;
• a benchmark or proof that Rullst is better than another framework;
• a substitute for the exact release gates on the candidate SHA.

Those questions belong to the capability status, the capability ledger, and the release evidence. Keeping these axes separate prevents a well-tested bounded foundation from being mistaken for a finished remote integration.

Interpreting changes between pushes

A score should change only when its evidence changes. The per-push review will call out:

1. the previous and current SHA;
2. repository score and changed crate rows;
3. the exact gate responsible for a gain or loss;
4. feature-completeness movement separately, when applicable.

No points are added for code volume, number of features, marketing claims, or raw test count alone.