feature - RFC 104 stdlib and package receipts, redaction, replay, and reports

[dannymeijer]

Area

• Runtime / Core crates (stdlib/core/derive)
• Tooling (CLI/formatter/test runner)
• Documentation

Problem statement

Receipts cannot be a logging convention. RFC 104 requires every host-bound stdlib operation and package-defined domain operation to emit compatible structured authority facts without exposing secrets.

Proposed solution

Implement the shared receipt API, redaction model, replay classifications, report artifacts, and standard-library/package integrations required by RFC 104.

Alternatives considered

• Telemetry-only events: do not give local policy and tooling a stable authority contract.
• Private stdlib receipt hooks: exclude package authors from the common report model.

Scope / acceptance criteria

• In scope:
  • Public typed receipt APIs for stdlib and package-defined capabilities.
  • Receipts for environment, filesystem, process, HTTP, clock, randomness, model, and tool boundaries where the corresponding surfaces exist.
  • Status, nesting/correlation, source and semantic identity, redaction metadata, partial-work honesty, and replay classification.
  • Machine-readable run reports with requested/granted/denied capabilities, receipts, diagnostics, redaction summaries, artifacts, and replay limitations.
  • Receipt/report relationship to telemetry without making telemetry required.
• Out of scope:
  • Raw secret reveal or mandatory remote telemetry.
• Done when:
  • Stdlib and package receipts flow into one report schema.
  • Reports accurately describe allowed, denied, failed, partial, redacted, and replay-limited paths.

[dannymeijer]

Blocked: the receipt contract is being rewritten in an open PR

Recording why I did not start this, with the evidence, rather than leaving it as a stalled item.

What already exists. The receipt core in crates/incan_semantics_core/src/receipts.rs is substantial and well-shaped: OperationReceipt, ReceiptStatus, ReplayClassification, AttributeSensitivity, ReceiptAttribute with public/redacted construction, redacted_keys(), and validate() against ReceiptContractViolation. This is not a greenfield item.

Why it cannot proceed now. #1277 is open and materially rewrites the contract this issue implements. From its diff, it adds or redefines:

• receipt-required semantics, with observe and governed as reporting modes and permissive explicitly receipt-free;
• an execution-evidence binding created at the execution boundary after final argument conversion, covering the selected implementation identity, target boundary, a commitment to normalized arguments or byte streams, and the observed outcome;
• receipt identity computed from a canonical, versioned serialization of non-secret fields;
• a report-level ordered receipt-set commitment anchoring those identities;
• per-receipt execution attestation split into local and boundary-attested, the latter requiring issuer identity, key id and generation, algorithm, signing time, signature over stated coverage, and verification material.

Those are exactly the fields any implementation of "stdlib and package receipts flow into one report schema" has to produce. Building the schema against the pre-amendment contract would mean rewriting it when #1277 lands.

A second dependency. This issue's receipt surface is reached through from std.runtime import receipts (RFC line 170). std.runtime now exists — #1389 added it and declared the nine host.* capabilities — but that PR deliberately stopped short of grants and enforcement. A receipt records an authority decision, so there is nothing yet for a receipt to bind to. #1029's remaining half is a genuine prerequisite, not just an ordering preference.

Small lifecycle note. PR #1277's description says "RFC 104 remains Planned". That is true of main, but the RFC reads In Progress on 0.6.0-dev.2, 0.6.0-dev.3, and 0.6.0-dev.7. Worth reconciling before that PR merges so the lifecycle does not read as a regression.

Suggested order: merge #1277, finish #1029's grant and enforcement half, then implement this against the settled contract.