[ScriptedAlchemy]

Merge #4478 first, followed by #4526, #4510, #4524, #4489, #4485, #4527, #4528, #4530, #4531, #4529, #4534, and #4541.

This PR is number 13 of 13, based on #4534.

Use merge commits. After merging a parent PR, change its child's base to master before merging the child. Auto-merge is disabled.

Problem

Standalone session reflection, combined review, and runtime validation described the same fact proposal differently. In particular, combined review advertised string store IDs and numeric-only trust while runtime required numeric IDs and also accepted normalized trust labels. This made valid proposals depend on which route produced them.

Changes

• Add one typed fact proposal and exclusive source-reference contract in tracedecay-contracts. Generate its inline JSON Schema with the existing Schemars dependency and embed it in both response envelopes.
• Decode each untrusted fact once before the existing semantic validation. Preserve the original malformed item in quarantine and repair evidence, so one malformed sibling does not discard valid proposals.
• Preserve released trust-label normalization and omitted tags/entities. Numeric store IDs must fit signed 64-bit bounds; integral JSON numbers such as 7.0 normalize to 7, while strings, fractions, and overflow are rejected.
• Keep content/evidence limits, citation membership, privacy, deduplication, trust policy, and apply authority in their existing runtime owners. Standalone partial application and combined-review atomic failure behavior remain covered.
• Point task prose at the generated response schema and bump the input identities to session_reflector:v3 and combined_review:v4.

No dependency changes or public retained-evidence schema changes are needed. The accepted-item handoff remains the separate scope of #4430.

Validation

Cargo validation used the pinned nightly and retained production features, debug assertions, and overflow checks. All selected runs had nonzero test counts and no ignored or failed tests.

• 52 library tests passed: the full automation library suite (39), canonical proposal contract tests (5), and focused runtime validation/effect/replay tests (8).
• 9 integration tests passed: both full generated schemas versus the shared decoder; repair through both actual runners with canonical memory reads and receipts; standalone partial application and quarantine; combined-review atomic success and failed-repair no-write behavior; learned-skill repair and exhaustion; deterministic combined input hashing.
• Pinned rustfmt, git diff --check, commitlint, and the existing generated BUILD-file check passed (61 generated files current).

Native-storage fixtures ran in isolated temporary tmpfs directories and were removed afterward. No paid model calls were used.

The 61 passing tests cover this change on parent ea18e44c202fcb1b0bf82156bd9f8fafd65b2502 (the then-current #4529 head). The ten changed files are byte-identical after rebasing onto #4534 at b0a1c65b3e71f5ccbddfd3e25a39f4db2179056b. The intervening upstream changes are scheduler cancellation classification, structural-ID privacy handling, and status/doctor backlog-prefix memoization; none edits the fact-proposal contract or runner changes here.

Final rebuild limitation: a recheck after the upstream privacy update rebuilt missing cached dependencies and was killed while compiling asupersync under the 8 GiB container limit. It did not reach test execution. The 61 earlier passing tests are not presented as a run on the final stack parent. The last parent (#4534) was separately inspected: its single-file backlog-health cache change is outside these automation test paths.

The earlier successful production-feature build used package-scoped compiler settings (hint-mostly-unused, fewer LLVM names, and one frontend/backend job) to fit compilation into this container. These are local settings, not repository changes; they were also present in the final unsuccessful rebuild.

Closes #4431

[changeset-bot]

⚠️ No Changeset found

Latest commit: c658246

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR