Atlas of boundaries

Understand

An auditable architecture lets you trace a responsibility from the interface to the package that implements it. The map doesn't replace the code: it tells you where to start verifying.

The map can also lie from the manifest: the DriftDetector compares what milpa.json declares against what the code carries in #[PluginMetadata]. When they diverge, the report names it (MILPA_MANIFEST_DRIFT), because the contract that teaches is the one that runs, not the one that is written: a drifted milpa.json teaches humans and agents a shape that no longer exists, and every decision made from that manifest inherits the gap. The fix is regenerative, not manual: php coa coa:plugins manifest <Plugin> (a host command) rewrites the manifest from the code, which is the source of truth.

See

Open Atlas of boundaries

Select a package and follow its relationships and primary sources.

Open artifact

Do

Run the practice in your checkout and keep the output as evidence.

Browse the senior reference (source packages)

Verify

Show that you can apply the unit. Progress only advances once you pass the assessment.

Criteria assessed

Locate the owner of boot, capabilities, tools, gates and state.
Back every important claim with a primary source.

Graded assessment

Solve the 4 scenarios. This unit requires 4 of 4 correct answers.

0 attempts

Question 1 of 4doctor confirms the kernel booted and /reports responds over HTTP, but inspect:tools doesn't show GenerateReport. Which boundary should you audit first?

The tool registry and pipeline in tool-runtime, starting with ToolRegistry.The general boot sequence in runtime, because any later absence belongs to the kernel.The event store, because a tool doesn't exist until it leaves a persisted event.

Question 2 of 4A tutorial claims: "Core executes and persists approvals because it defines VerificationResult." What is the most precise architectural correction?

Keep the claim: whoever defines a type necessarily owns all of its execution and persistence.Separate the responsibilities: Core defines the three-state contract; Workflow implements the machinery and Orchestrator/Event Store contribute process and history as the case requires.Move VerificationResult into Academy so the interface and the educational experience share a single owner.

Question 3 of 4A new atlas card says a package "owns authorization," but it only links to the organization's landing page and identifies no interface, manifest or file. How should it be published?

As a verified fact, because the package name makes the responsibility plausible.As a stable internal detail, with no source, so links don't distract the reader.As a pending hypothesis, or not published at all, until it lands on a primary source that backs the claim.

Question 4 of 4ReportsPlugin's milpa.json declares that it provides exports, but the code's #[PluginMetadata] no longer declares it. A tutorial cites that manifest as evidence of the capability. What is the correct reading?

The manifest rules: if milpa.json declares exports, the capability exists and the map can cite it as a verified fact.It is MILPA_MANIFEST_DRIFT: the contract that teaches is the one that runs, not the one that is written — every decision made from that manifest inherits the gap, and the fix is to regenerate it from the code with php coa coa:plugins manifest ReportsPlugin (a host command).Hand-editing milpa.json to drop exports is enough; keeping manifest and code in sync is the editor's discipline.

Grading validates answers in this browser; it doesn't certify identity.

Routes

Atlas of boundaries

By the end, you'll be able to

Understand

See

Do

Verify

Primary sources

By the end, you'll be able to

1Understand

2See

3Do

4Verify

Primary sources

Understand

See

Do

Verify