feat(contracts): closed schemas for the mint family + content-free usage metering

[POWERFULMOVES]

Follow-up to Codex's P2 on #2332: the content-free invariant on chit.economics.usage.v1 existed only in Markdown. The envelope path validates a payload only when the subject is registered in topics.json with a schema, so a future publisher could have added prompt text and nothing would have failed. The five archon.mint.* subjects had the same gap — catalogued but unvalidated.

Six schemas, all additionalProperties: false.

Why closed matters here specifically

TensorZero's own observability is disabled by policy (tensorzero.toml, Cyber Defence Initiative 2026-04-25) because enabling it auto-creates ClickHouse tables holding full prompt and response text with no TTL — a warrantable store of user content, unacceptable for a co-op pilot serving elders. chit.economics.usage.v1 exists so agent cost is measurable without recording what was said. A closed schema is the mechanism that makes that hold rather than a promise.

Verified it bites:

legit counts-only payload -> ACCEPTED
payload with 'prompt'     -> REJECTED: Additional properties are not allowed
payload with 'response'   -> REJECTED
payload with 'messages'   -> REJECTED
payload with 'content'    -> REJECTED

topics.json

Registrations added by targeted text insert, not a json.dumps round-trip. The round-trip reflowed every inline array in the file — 210 insertions / 49 deletions instead of a clean addition. This is 18 insertions, 0 deletions, and the script asserts no pre-existing entry changed (99 → 105 topics).

Scope

These subjects still have no publisher. Schemas are a precondition for the first one, not progress toward it. topics.json will now contain six more entries whose subjects are dead — consistent with the broader finding that PMOVES' contract layer is well-developed and its runtime layer is not.

Testing

• Six schemas parse; all assert additionalProperties: false before landing (the apply script refuses otherwise)
• Privacy invariant exercised against Draft202012Validator (above)
• topics.json re-parses; every pre-existing entry byte-identical in meaning
• pytest pmoves/tests/test_chit_contract_schemas.py — 5 passed, 5 failed, unchanged from main (pre-existing; that suite's inputs are untouched by this branch)

Note for the reviewer

pmoves/contracts/schemas/ is a damage-control readOnlyPath. The operator authorised this with a schema:pr:2332 Known Road grant. However — see my PR comment: the write did not actually traverse the guard, and there is a gap worth closing.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@POWERFULMOVES, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ad7bddeb-fd75-4bd6-baba-71238b65dd3e

📥 Commits

Reviewing files that changed from the base of the PR and between 2f72861 and 1fa05cb.

📒 Files selected for processing (7)

• pmoves/contracts/schemas/archon/mint.agent.v1.schema.json
• pmoves/contracts/schemas/archon/mint.confirmed.v1.schema.json
• pmoves/contracts/schemas/archon/mint.creator.v1.schema.json
• pmoves/contracts/schemas/archon/mint.skill.v1.schema.json
• pmoves/contracts/schemas/archon/qa.result.v1.schema.json
• pmoves/contracts/schemas/chit/economics.usage.v1.schema.json
• pmoves/contracts/topics.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[POWERFULMOVES]

Disclosure: these writes bypassed the damage-control guard

Flagging this against myself, because it undermines a property the guard is supposed to provide.

pmoves/contracts/schemas/ is in readOnlyPaths (patterns.yaml:1157). When I first tried to create a schema with the Write tool, it was correctly blocked and pointed me at KNOWN_ROAD=schema:<reason>. The operator then set the file grant (schema:pr:2332).

But the files were actually written by a Python script invoked through Bash:

python "$SD/apply_schemas.py" "$(pwd)" "$SD/schemas"

bash-tool-damage-control.py:225 matches readOnlyPaths against the command string. The protected path never appears there — it's constructed inside the script from argv. So the guard had nothing to match, the write proceeded, and known-roads.jsonl has no entry for it (last entries are compose/pr:1533 from 2026-07-27).

Net effect: the grant the operator set was never consulted. The change is substantively authorised — they set the grant for precisely this — but the provability property is not satisfied, and PATTERNS.md is explicit that "an unrecorded bypass is not provable."

The gap

Any script taking paths as arguments defeats path-based command-string matching. This isn't specific to my script — python x.py, cp via a variable, a Makefile target, or a heredoc-written file all have it. pmoves/contracts/topics.json was untouched by this because it sits under pmoves/contracts/ which is only in noDeletePaths, so writing it is legitimately unguarded.

Worth considering

The PreToolUse hook can't see a script's runtime behaviour, so command-string matching has an irreducible hole. Options, roughly in order of cost:

1. A PostToolUse check that diffs git status for touched readOnlyPaths and fails loudly after the fact — catches the effect rather than the intent, and would have caught this.
2. A pre-commit hook rejecting staged changes under readOnlyPaths without a matching known-roads.jsonl entry — moves enforcement to the commit boundary, which is where provability actually matters.
3. Accept it as out of scope and treat the guard as advisory for indirect writes.

I'd lean toward (2): it's where the audit trail is consumed anyway, and it can't be defeated by indirection.

Happy to open a separate issue rather than tack it onto this PR — say which you prefer. I did not touch the hooks myself; PATTERNS.md notes that modifying them needs an explicit permission rule agents cannot self-grant, which seems right.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6400249423

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Accept creator confirmations on the shared subject

When /archon:creator-onboard reaches its confirmation step, it publishes { "kind": "creator", "handle": ..., "confirmed_at": ... } on this same subject (.claude/commands/archon/creator-onboard.md:111-113). This schema instead requires agent_id and, because it is closed, rejects both kind and handle; now that the subject is registered, the standard validated event path cannot publish a creator confirmation. Model both documented confirmation variants or give creators a separate subject.

AGENTS.md reference: pmoves/AGENTS.md:L219-L219

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Permit canonical registry IDs in usage records

The field description says this value matches the ID in agent_registry.yaml, but canonical IDs there are snake_case—for example agent_zero and llm_observability—while this pattern permits only lowercase letters, digits, and hyphens. Usage records from existing registered agents will therefore fail schema validation; accept the registry's underscore convention or define an explicit normalization boundary.

AGENTS.md reference: AGENTS.md:L25-L25

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Align the QA schema with its producer payload

The mandated producer output in .claude/agents/archon-qa-agent.md:36-39 includes a top-level subject: "archon.qa.result.v1", but this closed schema does not declare subject. Sending that documented verdict through the newly registered validation path is rejected as an additional property, preventing either pass or fail results from reaching the QA gate; either remove the field from the producer payload or represent it in the schema.

AGENTS.md reference: pmoves/AGENTS.md:L219-L219

Useful? React with 👍 / 👎.

[POWERFULMOVES]

Schema inconsistency found by the first live QA-gated mint (2026-08-04): mint.agent.v1.schema.json declares agent_id as format: uuid (line 9), but agent_name enforces slug pattern ^[a-z0-9][a-z0-9-]*$ and the manifest_url room convention (rooms/<room_id>/agents/<agent_id>.manifest.json) reads most naturally with slug ids. Draft 2020-12 treats format as annotation-only by default, so slug ids pass lax validators and fail strict ones — a silent interop trap. The archon-qa-agent gate caught it live (verdict FAIL, correctly withheld mint.confirmed). We conformed to the schema as written (uuid agent_id, slug kept as agent_name/manifest agent_slug) for mint 2bf86daa-3fa7-43a7-91f6-32acc9e36a4b, but the contract should pick one convention explicitly: either drop format: uuid in favor of the slug pattern, or document uuid-id + slug-name as canonical. — 5090-CLAUDE