[PIR][WP11] Expose constitution/admission-gate API for external capability-expansion approval

[ruvnet]

Epic: #12 · Cross-repo counterpart: ruvnet/RuVector#851 · Program epic: ruvnet/RuVector#837 · Plan: 03-program-plan.md in ruvnet/ruvector

Goal

Expose this repo's constitution / admission-gate as an externally callable API for capability-expansion approval, so ruvector's promotion pipeline can use it as PIR's enforcement point for "zero unapproved capability expansion."

Every mutation that would expand an agent's capability set — new tool access, new physical action class, or new communication peer — requires explicit constitutional approval logged to the witness chain, at a higher bar and logged distinctly from ordinary behavioral-mutation promotion (which WP2 handles in ruvector).

The distinction is the point. A behavioral mutation makes an agent better at what it may already do; a capability-expanding mutation changes what it may do at all. Routing both through one gate means the second class silently inherits the first's threshold, and "zero unapproved capability expansion" becomes unverifiable after the fact.

Why this repo

Per the program's asset map, this repo is the most governance-complete component surveyed — observe → explain → mutate → prove → canary → promote/rollback, with a typed mutation genome, signed antibody packages, and an existing constitution governance plane. PIR adopts that pattern rather than building a parallel gate.

Grounding note: the real implementation is TypeScript in packages/radio-moe/ (~6.2K LOC source + 3.2K LOC test), not the Rust crate listing an earlier program pass pointed at.

Acceptance criteria

• An external API surface for submitting a candidate mutation and receiving an approve/reject decision with a recorded rationale.
• Capability expansion is defined precisely and enumerated: new tool access, new physical action class, new communication peer, plus any further categories found during design. This definition is the load-bearing artifact — a vague one makes the gate trivially bypassable.
• A mutation is automatically classified as capability-expanding or behavioral. Classification must not depend on the submitter self-declaring, which is exactly the case the gate exists to catch.
• The capability-expanding bar is demonstrably higher than the behavioral one, and the difference is documented rather than asserted.
• Approvals are logged to the witness chain distinctly enough that WP12 can query "zero unapproved capability expansion" directly, rather than joining across record types — using the shared record schema from WP8 ([PIR][WP8] Conform promotion records to ruflo ADR-322C for anchoring into rvm witness chains #10).
• Negative test: an unapproved capability-expanding mutation is blocked and appears in the day-30 diff as a rejection, proving the query has discriminating power rather than returning zero because nothing was ever classified.
• Rollback: a capability expansion later found unapproved triggers the existing promotion/rollback controller.
• API stability expectations stated plainly — this repo self-labels "research prototype", and ruvector is budgeting for churn rather than assuming production-grade stability.

Honesty discipline

Per rvm ADR-285's precedent, do not let a Cloud Run–hosted control plane imply enforcement strength it does not have. If the gate is advisory in some deployment topology, say so in that topology's status reporting.

Dependencies

WP8 (#10) — approvals must be anchorable into the canonical chain, or WP12's single-query traversal is impossible. Feeds WP12 in ruvector.