plan — everything a request settles before any syntax exists

A plan is the complete output set of one request, named before a token of the target language has been written.

The planning road moves through related views of one declared request. The account is what the caller walked in with: the kind-specific content bound to its exact captured declaration and owner-qualified kind, and the independent captures it declares it stands on. The intent is what that request meant — its owner-qualified kind over the content commitment, and nothing else, so two requests that meant the same thing derive one intent whatever machinery would realize them. The context is what the request is decided under: the profile it selected, and the generator answering. The plan is what all of that decides: every unit that will exist, where each came from, what invalidates the whole, why it was decided that way, and what it does not claim.

The output firewall

A plan states its complete membership up front, and the declared set is the whole set.

A rendering is proved against it seat by seat, so a unit nobody planned has nowhere to be admitted and a planned seat nobody rendered is a refusal rather than a quiet absence. The membership is structurally non-empty and bounded: a plan that would generate nothing is a disposition, and one that would generate past the declared magnitude refuses rather than materializing part of a set.

Two members may not stand under one seat. Closure matches a rendered unit to a planned one BY SEAT, so a doubled seat would make that match elect one member and prove nothing about the other — which is why the doubling is caught in the declaration rather than downstream.

One account, and no second copy

The intent, invalidation, diagnostic-cause, and origin readings all take the account.

None of them keeps a copy. A second list of what content depends on — beside a plan, inside a context, at a call site — would agree with the first until it did not, and nothing downstream could tell which of the two a plan was actually planned over.

What makes a plan stale

The watch set is derived from the account and the context rather than listed at a call site, and it covers all of both.

A set watching only part of a declaration’s causes is byte for byte the shape of a complete one, so a plan over it would read as current after an unwatched cause changed. Compiler-owned invalidation follows the identity-bearing facts the account and context already hold rather than restating them at the planning call. Consumer-owned invalidation names any further declared fact in the consumer’s own vocabulary. The compiler enumerates no further nouns there, because a mechanism profile, a work formula, and a fixture population are three different owners’ meanings and a roster of them would be this crate minting vocabulary for facts it does not hold.

What it does not do

It renders nothing, proves nothing, and explains nothing.

It holds no rendered bytes and therefore no digest of them: a member states the contract its eventual digest must satisfy, and closure recomputes that digest over the bytes a renderer actually produced. It names no delivery of its own either — a member’s delivery is its seat’s own answer, so two plans of one kind cannot disagree about which build compiles a seat’s unit. And it enumerates no kind: the owner-qualified name, canonical content, seats, and questions all arrive from whoever declared the kind.

How it says no

Planning issues are independent and co-establishable — one pass may find a doubled seat and an overrun magnitude at once — so a refusal carries every issue its pass established rather than electing a primary one.

A body that fills its bound keeps what fits and counts the rest, which is a different statement from “no further defects exist”. The refusal is an ordinary error: it prints, it is a core::error::Error, and it projects into a diagnostic through the one contract every refusing step implements.