I1018 — The surface rules exist as checks, proved by making them fail

BLOCKED wave 3 · p0 · deep-work profile · parallel safe

Part of capability-graph — One capability graph, two projections, and no second inventory of what this repository can do.

Objective

State the durable constraints of this architecture as project rules with executable checks: derived surfaces stay synchronised, a public capability is discoverable, a behavioural capability carries verification, a developer-facing capability resolves to documentation, and the two projections stay equal.

Why

Everything in this milestone decays the moment a change can land without a check noticing. A rule that exists only as a document is a suggestion wearing a uniform.

Current state

Project rules exist with checks for derived files, projections, hot paths, benchmark coverage and scope. None concerns UI exposure, capability documentation or verification policy.

Desired state

Each rule has a check, each check has a negative test that proves it fires, and CI runs all of them.

Scope

• .ai/repo/rules/project

Out of scope

• A rule with no executable check
• Requiring documentation or a test from purely descriptive metadata
• Duplicating a constraint an existing rule already enforces

Dependencies

• I1011READY The coverage matrix reports evidence, and never a green cell without one
• I1015ACTIVE A surface with no server behind it is not offered as if it had one

What waits on this

• I1019BLOCKED One skill runs the whole loop, and is itself in the graph
• I1027BLOCKED A synthetic capability proves the architecture instead of describing it

Acceptance criteria

• A change to an authoritative source that leaves any derived surface stale fails the drift check, and the failure names the source to change
• A public or developer-facing capability that is not discoverable through the generated interface fails, unless it declares itself internal
• A capability with behaviour carries verification appropriate to its kind, decided by typed policy rather than by one rule for everything
• A developer-facing capability resolves to canonical documentation, and the coverage is visible rather than only reported
• The static and runtime representations must remain equal after runtime-only fields are removed, enforced by the parity test
• Each rule has a negative test that proves the check fires, and CI executes every one

Validation

• bin/majordomus doctor
• bash test/run.sh

Evidence required

• rules_with_checks
• negative_tests

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Risk

Five new rules can make ordinary contribution feel like litigation. Each policy is typed by capability kind so that a descriptive object is not asked for a behavioural test.

Timeline

started

—

verified

—

completed

—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I1018.yaml. Read it back with majordomus plan show I1018.