What the design names and the code does not build Diagram

The short answer

• The version gate, the adequacy grade, the Polyx advisor and the Polytrion twin are not built, and the commands explain, grade, deploy and dispatch are listed as not built

Not shown here

• Everything that is built
• the other questions cover it
• Connected but out of scope: poly CLI, poly-lang, poly-embed, poly-core, poly-lower, Certified build

Risks

• Nothing in the packages records advice: the runtime can append an advice event, but no package calls it and no advisor is consulted at issue or at the gate; only tests call it. The architecture document describes the advisor as part of the runtime.

What the design names and the code does not build

Which parts of docs/02-architecture.md have no code behind them at v1.1.0?

The architecture document was last revised before any code existed. Reading it against the code at v1.1.0 shows which parts of its promise were built, which were built differently and which are still only a plan.

The long read

The pipeline stops at stage 5. Stage 7, the version gate with polyvers, and stage 8, replay with controls, are not stages of the pipeline; polyvers and polynv are not imported anywhere. The command list marks explain, grade, deploy and dispatch as not built, with the reason.

The Polyx advisor is not consulted. The runtime can append an advice event to a run, and the trace export counts advice events, but no code calls the method outside tests.

Polytrion is deferred by design: the document defers worlds to v2 and the grammar has no world declaration.

The source construct version N from M with a migrate block is not lowered: the machine header parses a version number, but no migrate.cjs is written.

Terms used here

poly-ref: poly's own model checker. It is written from the semantics and shares no code with the compiler.
gate: The two-phase mediation of an effect: propose before the call, settle after it. The Polyaxion engine decides allow, deny or escalate.
outbox: The table in which a step leaves its effect intents. The effect worker takes them out one at a time, at least once.
ledger: The record of every step, advice, decision, outcome, gate verdict and effect of a run, hash-chained per run with signed heads and a periodic anchor.
work order: A unit of work that a workflow issues to an agent or a person, with a budget; the reservation is the cap.
idempotency key: A value sent with a write so that the receiver can recognise a retry of the same request and do the work once. In poly it is the intent id, and the runtime sets it.