Module requirements 

v0.99 (ADR — agent capability provenance): the capability-requirement ledger.

A requirement is where a capability is needed and why. The checker already decides, at every capability-consuming site, whether the enclosing handler’s given covers it (and errors when it does not). This sink records every such decision — covered or not — so the editor surfaces can answer two questions the bare diagnostic cannot:

• “What given does this handler still need?” — the uncovered requirements drive the materializable ghost given inlay hint (DECISION E).
• “Why does this handler declare given Clock?” — the covered requirements explain, on hover, what a declared capability is for.

The sink mirrors HintSink: a &mut parameter threaded through the checker entry points, NOT part of the Ok(TypedCommons) payload — so requirements persist through a transient type error at every site the checker still reaches. Spans are bare byte offsets into the file the sink was attributed to via RequirementSink::enter_file.

Decisive property (DECISION C): the human reason is a total function of the RequirementSource — a small closed enum — with no per-capability text. Adding a new capability needs zero new reason text; a fragment is authored only when a new capability-consuming feature is added (a store kind, a builtin) — a closed, compiler-internal set.

Structs

Materialize

The data the ghost given inlay hint needs to render and one-click apply.

Requirement

One capability requirement: which capability, at what site, why, and whether the enclosing handler already covers it.

RequirementSink

Records capability requirements per file. A fresh sink records nothing until enter_file attributes it.

Enums

RequirementSource

Why a capability requirement arises. The reason renders from this alone.

StoreKind

The storage kinds that consume a capability. A closed set: a new kind is a deliberate language addition, and adding one is the only time a new store reason fragment is authored.

Functions

store_reason

The storage feature’s (kind, op) -> reason table — the one place that knows why a store consumes a capability. Total over the clock-consuming store ops (requirements::tests::store_reason_table_is_total pins this); a (kind, op) outside the table falls back to a generic phrasing rather than panicking, so a new store op can never crash a render before its fragment is authored.

Type Aliases

FileRequirements

Project-relative source path → that file’s requirements, span-ordered.