macroonz-compiler 0.1.0

Deterministic Rust code generation for procedural macros: plan, render, close, explain, and bind one sealed expansion from declared input.
Documentation
# request — the front door

A request is what you hand this compiler, and an expansion is what comes back.
This home owns the consumer-declared door and the complete walk from captured meaning to a sealed expansion.

## The door says who is asking

One door declares the prefix your users read at the head of every line, the stable name of the declaration grammar, the stable name of the entry point, the crate rendered paths are rooted at, and the producer namespace and name generated identities stand under.

Say them once, in a `const`, and pass a reference from then on.
Diagnostics read the diagnostic spellings, rendered paths read the crate binding, and the projection-kind identity reads the producer qualification, so each fact reaches only the product surface it owns.

No consumer spelling lives here.
A consumer may rename its dependencies, so a binding this compiler chose for you would name a crate you do not have.

`Door` is declared here.
The crate root and `diagnostic::Door` remain compatibility navigation to that same request-owned type.

## What a request decides for you

A kind declares its seats, and a request through this door plans one member per seat.

That is the whole selection rule, and it is this home's own declared fact: what a kind's roster names is what one request produces.
The content binding, semantic key, origin node, and digest contract of each member are derived from the captured bytes, the owner-qualified kind, the content's canonical bytes, and the seat as each identity grammar requires.
They are never supplied, because a caller who could supply them could make a plan agree with content or a rendering it was not planned for.

A kind whose output set varies with what was declared does not use this door.
The lower-level homes remain reachable underneath, which is where a conditional membership is built and proved explicitly.

## What you decide

The caller hands over captured material, the kind's own content, and the door.
It may then state the captured dependencies the content stands on, the profile the request runs under, the owner facts the projection assumes, the address of each publishing seat, and the answers to the kind's own questions.
The exact defaults and replacement behavior are the caller contract on [`Request`](crate::request::Request).

The compiler's universal questions are answered from the plan and proof, so a caller answers only what its own kind asked.

## How it says no

Every step refuses in the vocabulary of the home that owns it, and this home turns each one into a diagnostic without translating it.

The phase, the family, the class, the first established issue, and the related set all ride on the refusal's own type.
This home supplies the door and the placement, and the placement is always the declaration as a whole: a refusal raised at or after planning is about the declaration, not about a token inside it, and a line naming a position would send a reader somewhere the refusal is not.

There is no partial answer anywhere on the road.
A request that fails a step is refused whole, and nothing that did not bind is handed out.