Auditable architecture · Unit 4 of 8

Visible legacy and the migration plan

A dependency may close through a legacy-shaped manifest. This is allowed, but never silent: the report names it (MILPA_LEGACY_CONTRACT_ACTIVE) and the status degrades to legacy_compatible. Legacy compatibility is named so it stays visible instead of decaying into invisible archaeology.

Intermediate to senior35 min

By the end, you'll be able to

Tell tolerated legacy apart from legacy that is not allowed
Read the MigrationPlan as a read-only proposal

Understand

allowedLegacyContracts in the host profile is a gate, not a note: a legacy path the allowlist does not permit blocks with MILPA_LEGACY_NOT_ALLOWED instead of degrading. And deprecation warns before it breaks: MILPA_DEPRECATED_CONTRACT_USED works today, but the metadata announces that shape is scheduled to leave, and migrating before removal is cheaper than after.

The way out has a plan: coa:migrate:plan changes nothing — it only produces a plan. Per package it lists Detected, Recommended, Steps (with the re-inspect always last), Compatibility and Academy. The compatibility line is honest and goes verbatim: the plan never invents a deadline the code doesn't declare.

See

Open the frontier

The same discipline: when two representations diverge, the divergence is named and repaired from the source of truth, never left to decay in silence.

Open artifact

Do

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

terminal

$php coa coa:migrate:plan

Read the plan's contract (host command)

Verify

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

Criteria assessed

Tell the legacy_compatible status apart from the block enforced by allowedLegacyContracts.
Explain why the migration plan is read-only and its compatibility invents no dates.

Graded assessment

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

0 attempts

Question 1 of 3A contract closes through a legacy-shaped manifest and the host profile permits it. What should the resolution report reflect?

Status valid with no mentions: if the path is permitted, there is nothing to report.MILPA_LEGACY_CONTRACT_ACTIVE and status legacy_compatible: allowed, but never silent.Status blocked: any legacy shape prevents boot until it's migrated.

Question 2 of 3The host profile declares allowedLegacyContracts: ["billing"] and the reports contract can only resolve through a legacy shape. Which outcome is correct?

It degrades to legacy_compatible: it's enough that the allowlist permits at least one legacy contract.MILPA_LEGACY_NOT_ALLOWED and the graph blocks: the allowlist is a gate, not a note, and a selective list is a deliberate boundary the resolver enforces.The resolver adds reports to the allowlist and records the expansion as a warning.

Question 3 of 3A team runs php coa coa:migrate:plan on a host with legacy and deprecated contracts. What does that command guarantee?

It executes the migration step by step and updates the affected manifests.It computes a deadline for each deprecated contract based on its age.It changes nothing — it only produces a plan: per package it lists Detected, Recommended, Steps, Compatibility and Academy, with an honest compatibility line that invents no dates.

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

Primary sources

Milpa Resolver

Content verified: 2026-07-12

By the end, you'll be able to

1Understand

2See

3Do

4Verify

Primary sources

Understand

See

Do

Verify