macroonz-compiler 0.2.0

Deterministic Rust code generation for procedural macros: plan, render, close, explain, and bind one sealed expansion from declared input.
Documentation
# explanation — the answer sheet nothing is generated without

Anything this compiler produces can be held to account, and this is where it answers.

The compiler's universal questions ask what an output is, who required it, what caused and qualified it, what was emitted, what it depends on, what invalidates it, what happened to related work, and what repairs a refusal.
A kind's own questions are a second roster answered beside that one.
Nothing narrows the first roster, so no kind can owe less by declaring less.

## Coverage is the whole value

A `View<K>` exists only when every question on both rosters has exactly one answer.

There is no partial view and no "mostly answered" posture: a set of answers that could not be completed is an `ExplanationError` naming every unanswered question, every doubled one, every answer standing outside its own roster, and the seat bound where a kind's roster is too wide to seat at all.
They are reported together, because a caller repairing an answer sheet one question per attempt is a caller the protocol failed.

## A view is ABOUT something, and it says what

Coverage says a set of answers covered a kind's rosters.
It never said WHOSE expansion those answers were about — and a kind is not an expansion: two plans of one kind admit the same rosters, so a view written over one of them covers the other's rosters exactly.

A binding handed such a view would get plan A, closure A, and a complete, well-formed, correct-looking account of something else.

So a view carries the parentage it was answered over, and it is not supplied: the constructor is handed the actual plan and the actual proof and reads both identities off them.
A closure is reachable only by proving a rendering against a plan, so a caller standing at that road has done the proving or has nothing to hand in.
The view then mints its own identity over the plan, the closure, and the canonical answers, so a binding has three names to compare and one to commit to.

## Identities, not prose

Every answer carries typed values — identities, typed rosters, typed dispositions — and never a sentence standing in for a fact.

Two things are derived from an answer rather than seated beside it: the question it belongs to, and the line a person reads.
So an answer filed under the wrong question is unrepresentable rather than validated, and so is a sentence that contradicts the answer it is shown with: the line is composed when it is asked for and never stored, which leaves no second value to keep in agreement.
No prose enters a preimage, and nothing reads a line back.

## What it does not do

It answers nothing itself.

The compiler does not know which owner required a projection, which facts it rests on, or what repairs a refusal — those are the caller's, and a compiler that invented them would be explaining a decision nobody made.
It owns the universal accountability vocabulary, complete coverage, canonical answer order, the view's parentage and identity, and the human projection derived from each typed answer.
Exact roster rows, encodings, bounds, and refusal contracts live on the public items that callers use.