docs: requirements and testing is the fifth pillar, and the two entry docs still said four

`docs/llms/llms.txt` and `llms-full.txt` moved to five pillars when the pillar
shipped — deliberately, upstream first, because the site mirrors them. AGENTS.md
and README.md did not, so the two documents an adopter or an agent reads first
still enumerated four capabilities and called prompt construction the youngest.

Both now carry it, with the port split stated exactly rather than flattened into
"ships in all five ports": the vocabulary and the `verify` checks are cross-port,
`requirementTests()` is TypeScript-only. A project that declares no `requirement.*`
nodes sees no change at all.

The one place that still says four is deliberate and now says so in AGENTS.md:
`agent-context/skills/metaobjects-fit-assessment/SKILL.md` carries a written
ruling deferring `requirement.*` from the assessment — not a fifth pillar there,
not a rubric row, not a verdict line. That ruling was nearly "finished" once
already; the pointer is so the next reader finds it before repeating that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTcEKXTQMYt84fAjuw5A2M

Author: dmealing

AGENTS.md

@@ -6,14 +6,15 @@ MetaObjects is a **cross-language metadata standard** for declaring typed entity
 
 The metamodel is the **durable spine**; generated code is the **disposable artifact**. Substrate is local-first: typed metadata lives in your repo, generated code is idiomatic per-language output that runs without any MetaObjects dependency at runtime. If `@metaobjectsdev/*` disappears tomorrow, you keep working code.
 
-## Four pillars
+## Five pillars
 
-Equal weight — all four ship per-language today across the five ports (TS / C# / Java / Python / Kotlin), with cross-port conformance corpora verifying byte-identical behavior:
+The first four ship per-language today across the five ports (TS / C# / Java / Python / Kotlin), with cross-port conformance corpora verifying byte-identical behavior. The fifth ships its vocabulary and its `verify` checks in every port, and its test scaffolding in TypeScript only:
 
 1. **Codegen** — emit idiomatic per-language code (Drizzle/Zod + Fastify for TS, EF Core + ASP.NET for C#, Spring REST + DTO + Repository for Java via `codegen-spring`, Pydantic + FastAPI for Python, KotlinPoet + Exposed + Spring for Kotlin via `codegen-kotlin`). Hand-edit-preserving regen via three-way merge.
 2. **Runtime metadata** — load metadata at runtime, drive behavior dynamically (CRUD, validation, relationships, dynamic admin UIs, LLM tool registration). On Kysely (TS), a DB-API 2 driver via ObjectManager (Python), modernized JDBC + Spring-tx via OMDB (Java), Exposed (Kotlin), EF Core (C#).
 3. **Drift detection** — `meta verify` catches divergence between code and metadata (covers entity codegen, prompt templates, output parsers, schema). Quality-of-life on top of codegen + runtime.
 4. **Prompt construction** — a prompt is code, not a string scattered across services. Declare a prompt's payload as a typed projection (payload bloat becomes a diff), keep its text external and provider-resolved, and render it deterministically: snapshot-testable, cache-stable (no whitespace change silently breaking exact-prefix prompt-cache hits), and drift-checked at build time so a renamed field can't degrade a prompt. Conformance-gated, so the guarantee holds in every language port. **Render + payload-VO codegen + `verify` + parser-on-receipt for a *responding* `template.prompt` — one carrying `@responseRef` (FR-006) — + the output-format prompt fragment & tolerant `extract` parser (FR-010) ship in all five ports today** (since 0.24.0 the whole inbound tier keys off `@responseRef`; a `template.output` is outbound-only and emits no parser — ADR-0052) — the library-side building blocks of the pillar are complete. The one remaining library-side piece is MCP exposure of declared prompts/tools (see `spec/roadmap.md`); the application-level consolidation (eval harness, end-to-end declared-prompt orchestration) and consumer adoption are exercised in adopter projects, not in this library repo. Designed in `docs/superpowers/specs/2026-05-22-fr-004-cross-language-prompt-construction-design.md`.
+5. **Requirements and testing** — declare what the software is supposed to *do* in the same model as the entities, so a capability claim is checkable instead of prose. The other four pillars keep the code honest about the *model*; this one asks whether the thing you said the software does is actually built — an absence no test can fail on, because a test exercises code that exists. `requirement.functional` (fails when *nothing* implements it) and `requirement.architectural` (fails when something *violates* it) are registered vocabulary in all five ports, with the loader enforcing the closed `@status` enum. `@implementedBy` is **resolved, not trusted** — it names a real member of the real model, so a claim whose implementation was renamed or deleted fails the build instead of going quietly stale. `meta verify` reports the ledger on every run (unresolved links, entities no claim covers, gaps recorded versus gaps nobody has ruled on) plus an authoring lint whose findings can never fail a build; `meta docs` renders it for humans and for agents. **The port split, stated exactly: the vocabulary and the `verify` checks are cross-port; `requirementTests()` — which scaffolds a test stub per claim — is TypeScript-only.** A project that declares no `requirement.*` nodes sees no change at all. Note the standing carve-out: `agent-context/skills/metaobjects-fit-assessment/SKILL.md` deliberately does NOT treat `requirement.*` as an assessment axis — see the ruling in that file before "finishing the job" there.
 
 ## Status
 

README.md

@@ -133,14 +133,15 @@ URL grammar + wire format the client speaks, and
 the consumer-side wiring (React + TanStack, and the
 [Angular 18 tier](docs/ports/typescript-client.md#angular-18)).
 
-## Four pillars
+## Five pillars
 
-All four ship per-language today — but they are not uniformly deep. See the
+The first four ship per-language today — but they are not uniformly deep. See the
 [capability matrix](#capability-matrix) for per-port coverage; in field
 materialization the ranking is **drift > codegen > prompts > runtime metadata**
-(the youngest pillar). The prompt pillar's library-side building blocks are
+(the youngest of the four). The prompt pillar's library-side building blocks are
 complete in all five ports; MCP exposure of declared prompts/tools is the one
-remaining roadmap item:
+remaining roadmap item. The fifth pillar ships its vocabulary and its `verify`
+checks in every port, and its test scaffolding in TypeScript only:
 
 1. **Codegen** — emit idiomatic per-language code (Drizzle/Zod + Fastify for TS,
    Spring REST + DTO + repository for Java, `data class` + Exposed for Kotlin, EF Core
@@ -158,6 +159,15 @@ remaining roadmap item:
    deterministically (snapshot-testable, cache-stable, drift-checked at build
    time, conformance-gated cross-language). See
    [`docs/features/templates-and-payloads.md`](docs/features/templates-and-payloads.md).
+5. **Requirements and testing** *(vocabulary + `verify` checks in all five ports;
+   `requirementTests()` scaffolding is TypeScript-only)* — declare what the software
+   is supposed to *do* in the same model as the entities. The other four pillars keep
+   the code honest about the model; this one asks whether a claimed capability is
+   actually built. `@implementedBy` is **resolved, not trusted** — it names a real
+   member of the real model, so a claim whose implementation was renamed or deleted
+   fails the build rather than going quietly stale, and `meta verify` reports the
+   ledger on every run. A project that declares no `requirement.*` nodes sees no
+   change at all. See [`docs/features/requirements.md`](docs/features/requirements.md).
 
 ## Repo layout