/lab-team-review MERGED VERDICT (v2, post-fix) — C-C1 uni_propose_change

verdict: PASS evidence_class: C supersedes: none (first review pass for this item)

/lab-team-review MERGED VERDICT (v2, post-fix) — C-C1 uni_propose_change

• Base SHA: 85b0e8c (working tree, spec-correction pass applied on top, uncommitted)
• Mode: real (5 independent persona agents re-reviewing the corrected spec)
• Files reviewed:
  • production\mcp\SPEC_uni_propose_change.md
  • production\schemas\evidence_bundle.schema.json

Fix summary (what changed before this re-review)

Summary

Re-verified every cited file:line against the live repo before editing (all citations in the findings were accurate — no drift found). Fixed both files; no .ex/.exs/.py/.cjs source touched.

production\schemas\evidence_bundle.schema.json (finding 2)

• Did NOT tighten the top-level required array, because the schema's own description (and production/docs/DEPLOYED_STATE.md:133-136, docs/PUBLIC_REPRODUCIBILITY_BUNDLE.md) confirm this schema is generic across any mutating MCP call (D-B1), not just uni_propose_change — doing so would force pure-OS mutations on other future tools to carry fields that don't apply to them.
• Instead added an additive, non-breaking $defs.uni_propose_change variant: allOf: [{"$ref": "#"}, {required: [lab_team_review_receipt_path, typed_spec_path, paired_red_launcher_path], minLength:1 on each}]. Base schema/$id/required untouched. Verified live with the jsonschema library: a bundle missing the three fields is refused by the variant but still accepted by the base schema (proving both mechanical enforcement for this tool and non-breakage for other consumers).

production\mcp\SPEC_uni_propose_change.md

• Registration (finding 1) — rewrote as four explicit numbered steps: add to MUTATING_TOOLS (server.py:247-254), add to HUMAN_GATED never IN_SHOW_VERBS (server.py:256 / 241-245), add a TOOL_HELP entry in help.py:56-186 — named explicitly as non-optional because _verify_tool_consistency() (server.py:922-945, literal at 928-932) raises RuntimeError at boot without it — and the async def/asyncio.to_thread(approvals.require...) implementation shape from server.py:8-14.
• Refusal check #5 rewritten to point at evidence_bundle.schema.json#/$defs/uni_propose_change so it's mechanically checkable, not prose.
• Test coverage (finding 3) — confirmed test/production/ doesn't exist, repo test tree is Elixir-only, and there is no pytest scaffolding anywhere in the repo. Found the repo's one real Python test precedent, uni/brain/test_active_inference.py (self-contained script, test_*() + main() runner, no framework), and rewrote the unit-test artifact as production/mcp/test_uni_propose_change.py following that shape, with pytest scaffolding named as an explicit future prerequisite if ever wanted. Also found the repo's one real MCP-verb red-team precedent, production/mcp/red_team_g_pa.sh, and moved the red-team artifact there (production/mcp/red_team_uni_propose_change.sh) instead of runs/, which I verified is the unrelated Minecraft colony/lab-simulation harness tree.
• Cross-references / Approval flow — added force=True to the approvals.require(...) call (consistent with HUMAN_GATED), added cross-refs to help.py and red_team_g_pa.sh, and flagged the parallel cross-reference item (finding 4) inline: SPEC_uni_self_audit.md's Registration section currently only says "add to read-only tools" and is missing the same TOOL_HELP boot-check step — I did not edit that file since it's explicitly a parallel/out-of-scope item, but noted it in Cross-references so the two stay consistent when it's corrected.

Not fully resolved / judgment calls flagged honestly:

• Whether to point the Python test at the self-contained-script convention vs. requiring new pytest scaffolding was a genuine design choice; I chose the existing-precedent route (lower complexity, zero new infra) per the task's stated preference order, but a reviewer could reasonably prefer real pytest/CI wiring instead — I named that as an explicit future prerequisite rather than silently deciding it's out of scope.
• I did not verify docs/UNIVERSE.md or docs/LAB_PROTOCOL.md §II content itself (only that the files/sections exist) since neither was in the findings list.

Persona verdicts (re-review)

math-breaker (Falsifier) — Lab Team role 2/5, docs/lab_team/01_math_breaker.md

• Verdict: SIGN_WITH_CHANGES
• Rationale: Fresh, independent re-review of production/mcp/SPEC_uni_propose_change.md + production/schemas/evidence_bundle.schema.json against the live repo (not the spec's word for it). Gauntlet check 1 (locate the term): this is Class C engineering/provenance tooling, not an FE math term touching A/B/C/D/E/precision — correctly, no reward-smuggling, decay-proof, or action-clone-invariance question applies here; the operative checks are provenance/traceability and mechanical-enforceability, which is where I spent the pass.

All four prior BLOCKED findings are genuinely resolved, each independently re-verified against live source rather than trusted from the spec's prose: (1) help.py TOOL_HELP registration — Registration step 3's citations (server.py:247-254 MUTATING_TOOLS, :256 HUMAN_GATED, :241-245 IN_SHOW_VERBS, :922-945 verify_tool_consistency, :928-932 the read-only literal, :8-14 the async-tool docstring, help.py:56-186 the TOOL_HELP dict) are byte-accurate — I read every one of those line ranges directly and they match exactly. (2) evidence_bundle.schema.json's required-array enforcement — verified live with jsonschema 4.23.0: the new #/$defs/uni_propose_change variant, resolved correctly, rejects bundles missing/empty on the three C-C1 fields and accepts complete ones, while the base schema (used by every other mutating tool) is untouched; confirmed no other spec depends on the base schema's exact shape in a way this breaks. (3) Test coverage — the spec's claim about the repo's real test tree (Elixir-only + two .cjs under test/body/, zero pytest.ini/pyproject.toml/conftest.py anywhere) is byte-accurate (independently globbed); uni/brain/test_active_inference.py's cited shape (self-contained test*() functions, assert-based, main() runner) is accurate; the new paths (production/mcp/test_uni_propose_change.py, red_team_uni_propose_change.sh) sensibly mirror the one real existing red-team script, production/mcp/red_team_g_pa.sh, which I confirmed exists. (4) Cross-reference consistency with SPEC_uni_self_audit.md's Registration — honest and current: I found a live, untracked receipt (docs/receipts/lab_team_review_85b0e8c.md) showing that sibling spec's own 5-persona MERGED VERDICT is still REVISE, so this spec's 'keep in the same shape when that spec is next corrected' framing is accurate, not presuming a fix that hasn't landed.

What survived my own falsification attempts and what didn't: the schema fix (finding 2) genuinely works when resolved correctly — I did not manufacture a pass. But going one level deeper than the prior review did, I found two concrete, reproducible defects the fix pass did not catch, both grounded in direct reads of the real source rather than assumption: the approvals.require() call shape in both the 'Approval + landing flow' and the newly-added 'Registration' step 4 names an action= kwarg that does not exist on the only require() implementation in this file (TypeError if built literally) and passes a raw dict where every sibling call site and the spec's own newly-cited docstring use a string; and the schema's #/$defs/uni_propose_change fragment, while correct, is self-referential ($ref:"#") in a way I proved recurses to RecursionError under a naive (extract-and-validate-standalone) implementation, with zero existing jsonschema-validation precedent anywhere else in this repo to anchor the correct call pattern. Neither is fundamental — both are small, precise prose additions (fix the require() call shape; name the summary serialization; add one sentence on how to resolve the schema fragment) — so REJECT is not warranted, but they are must-fix-before-implementation per the persona's 'earn SIGN' default. Also flagging, separately from spec content: the artifact I reviewed sits in an uncommitted, actively-multi-agent-edited working tree (HEAD moved under me mid-session; the schema file itself round-tripped through its pre-fix state and back while I was reading it) — worth committing before treating this SIGN_WITH_CHANGES as durable, per this repo's own 'ship from an immutable ref, never the working tree' rule.

• Concerns:
  • approvals.require() call-shape mismatch against the only real implementation in this repo. SPEC_uni_propose_change.md's 'Approval + landing flow' step 3 and the newly-added 'Registration' step 4 both call approvals.require(tool=..., summary=evidence_bundle, action="land tag ", force=True). The ONE require() implementation in production/mcp/server.py, _LocalApprovals.require (server.py:188-189), has signature (self, tool: str, args: Dict[str, Any], *, summary: str = "", force: bool = False) — no action parameter, no **kwargs. Verified against every real call site: open_session (server.py:734-738), admit_guest (817-819), schedule (833-835), start_broadcast (876-878) — all four parameters only, never action. Implemented literally as specified, this raises TypeError: require() got an unexpected keyword argument 'action'. This mismatch predates this fix pass (present in the prior BLOCKED version too), but the correction pass newly cited server.py:8-14's docstring as 'the shape this follows' in the same paragraph without reconciling it — a missed item, not a newly introduced one.
  • Same two call sites pass summary=evidence_bundle — a raw dict (evidence_bundle is typed dict on the tool's own signature) — where require()'s summary param is typed str and every real call site in server.py passes a human-readable f-string (e.g. summary=f"admit guest {guestId} to air"), never a dict, matching the exact docstring the corrected spec newly cites at server.py:8-14 (summary="...", a string). The spec's own stated premise for this field (Registration step 4, quoting D-B1) is 'the human's approval decision must be reproducible from the SAME bytes the agent saw' — an un-canonicalized dict object satisfies neither the type contract nor that reproducibility claim (Python dict repr is not a specified, stable byte serialization). The spec should name the exact serialization (e.g. json.dumps(evidence_bundle, sort_keys=True)) or explicitly justify diverging from the str-only convention every other tool in this file follows.
  • Refusal check #5's cited fragment, evidence_bundle.schema.json#/$defs/uni_propose_change, is a self-referential schema ({"allOf": [{"$ref": "#"}, {...}]}) whose correct resolution depends on preserving the document's base URI. I independently validated it with jsonschema 4.23.0 (Draft 2020-12): entered correctly (a $ref into the fragment, resolved against a registry rooted at the document's declared $id), it works exactly as claimed — rejects bundles missing/empty on lab_team_review_receipt_path/typed_spec_path/paired_red_launcher_path, accepts complete ones, and leaves the base schema's required array untouched (confirmed no other consumer — SPEC_uni_public_mcp.md, OS_SPOOL_POLICY.md, DEPLOYED_STATE.md — depends on the base schema's exact shape, so the additive-$defs approach doesn't break anything). But when the $defs/uni_propose_change object is extracted and validated standalone (e.g. jsonschema.validate(instance, schema["$defs"]["uni_propose_change"])) without preserving the enclosing document's base URI, the self-referential "$ref": "#" resolves back to itself and the validator recurses until RecursionError — I reproduced this directly. jsonschema (or any schema-validation library) is used nowhere else in this repo (grepped production/ for imports, zero hits outside this spec's own prose) and no requirements.txt/pyproject.toml exists under production/ to anchor a convention, so there is no existing precedent for 'the obviously correct way' to invoke this. Add one sentence to refusal check #5 (or the implementation step) naming the correct resolution pattern so the implementer doesn't hit the RecursionError I hit.
  • Minor/nit: 'Test coverage' section states uni/brain/test_active_inference.py is 'the ONE real precedent for a standalone Python test in this repo.' production/scripts/broadcast_test.py also exists and also matches a *_test.py naming convention — it's a live 5-stage broadcast-diagnostic script (PASS/FAIL/SKIP per stage, JSON+Markdown report), not a unit-test harness, so it doesn't actually compete with test_active_inference.py as the right shape to follow (the spec's choice is still correct) — but 'ONE real precedent' is a minor overclaim against the literal repo state. Does not block.
  • Process caveat, not a content defect: this review ran against an uncommitted, actively-edited working tree. git status shows both production/schemas/evidence_bundle.schema.json and production/mcp/SPEC_uni_propose_change.md modified (not committed) against HEAD, and HEAD itself advanced from 62dc97d to 8c1a557 mid-session, with a concurrent, untracked /lab-team-review receipt for the sibling C-C2 spec (docs/receipts/lab_team_review_85b0e8c.md, MERGED VERDICT REVISE, HEAD 85b0e8c) appearing while I was reading. Mid-session, one raw read of evidence_bundle.schema.json returned the file byte-identical to the committed pre-fix HEAD version (no $defs block, 2344 bytes) before a subsequent read showed the fix restored (3840 bytes) — almost certainly a concurrent editor in this same 'in-flight spec-correction pass' (per HEAD 8c1a557's own commit message), not corruption, but it means the artifact I'm signing off on is not yet a fixed, reproducible object. Per this repo's own CLAUDE.md ('Shipping production/ goes via git archive of an immutable, pushed ref — never the working tree'), commit the schema + spec fix to a ref before treating this SIGN_WITH_CHANGES as final, so a second reviewer (or the implementer) isn't scoring a moving target.

aif-theorist

• Verdict: SIGN_WITH_CHANGES
• Rationale: Independent re-verification (not trusting the spec's own citations) confirms all four prior BLOCKED findings are genuinely resolved against the live repo, not just asserted. (1) Registration step 3 now names the exact TOOL_HELP boot-time check; I read server.py:922-945 and confirmed _verify_tool_consistency() and the literal read-only set at 928-932 exist verbatim as cited, and help.py's TOOL_HELP dict runs exactly 56-186. (2) evidence_bundle.schema.json now carries a $defs/uni_propose_change variant (allOf against the base schema) that makes lab_team_review_receipt_path / typed_spec_path / paired_red_launcher_path mechanically required non-empty strings for this tool specifically, while the base schema stays generic for other mutating calls -- I traced every other consumer of this schema file (SPEC_uni_public_mcp.md, OS_SPOOL_POLICY.md, DEPLOYED_STATE.md) and none depends on the base required array excluding those three fields, so the change is safe and additive. (3) The Test coverage section now cites a real, existing precedent (uni/brain/test_active_inference.py, verified: self-contained assert-based test_*() functions + main() runner, exactly as described) instead of assuming unbuilt pytest scaffolding -- I confirmed test/production/ does not exist and no pytest.ini/conftest.py exists anywhere in the repo, and that red_team_g_pa.sh (the cited red-team precedent) is real and matches its description. (4) SPEC_uni_self_audit.md's Registration section has in fact been corrected to the same 3-step shape, so the two specs' Registration sections are now genuinely consistent in substance (my one concern here is that this spec's own cross-reference prose wasn't updated to say so -- see concerns). My assigned focus (claim-fence discipline / felt-state language) came back clean at the surface level: neither spec file contains any banned experience-family token (feel/felt/experience/conscious/aware), and the evidence_bundle schema is structurally built from typed shas/paths/timestamps with no freeform-prose field, which structurally forecloses felt-state narration from entering the evidence bundle itself. I did surface two new, concrete, file-grounded gaps the fix pass didn't touch: a stale cross-reference paragraph that now misdescribes SPEC_uni_self_audit.md's current (already-fixed) state, and an underspecified summary=evidence_bundle plumbing detail that leaves the spec's own "reproducible from the SAME bytes" claim unfalsifiable as written (it either breaks the only reference implementation's str-typed contract or relies on an unnamed coercion). Both are precise, easily-named, non-fundamental fixes -- not a reason to send this back to REVISE. A third, lower-priority observation about gates.ndjson content provenance is pre-existing/systemic and I flag it for awareness rather than as a blocker. Net: land with the two named changes made (and the third addressed if convenient).
• Concerns:
  • Stale cross-reference: SPEC_uni_propose_change.md's own Cross-references section (lines ~135-141) still describes SPEC_uni_self_audit.md's Registration section as deficient -- "it currently only says 'add to the read-only tools, not MUTATING_TOOLS'" -- and frames the TOOL_HELP + _verify_tool_consistency() boot-check parity as owed "when that spec is next corrected." I re-read SPEC_uni_self_audit.md:117-131 directly: it already has the full 3-step checklist (tool decoration, the read_only literal at server.py:928-932, and a matching TOOL_HELP entry) in the same shape as this spec's own Registration section -- parity is already achieved, not pending. This is a factual-accuracy leftover from the fix pass (both specs were corrected but the cross-reference prose in this one wasn't re-synced) and should be corrected to say parity is achieved, per this project's own honesty rail (claims must reflect current, not stale, state).
  • Registration step 4 instructs await asyncio.to_thread(approvals.require, "uni_propose_change", {diff_sha, spec_path, ...}, summary=evidence_bundle, force=True), passing the raw evidence_bundle dict as summary. I checked this against the only concrete reference implementation in the repo: _LocalApprovals.require() (server.py:188-189) types summary: str = "", and literally every existing MUTATING_TOOLS call site (cut_to server.py:549-550, admit_guest 818-819, schedule 834-835, etc.) passes a one-line f-string. As written the spec's step 4 either breaks that contract or relies on an unstated coercion -- and on refusal, the reference shim embeds summary into the human-facing reason text via f"...summary={summary!r}" (server.py:197), which for a dict produces a Python repr, not canonical/reproducible bytes. This directly undercuts the spec's own D-B1 claim that "the human's approval decision must be reproducible from the SAME bytes the agent saw" -- as written that's an asserted property without a named mechanism, which is exactly the kind of unfalsifiable claim the honesty rail (CLAUDE.md §3, "every claim carries a receipt or an explicit PENDING + its falsifier") flags. Name the exact serialization (e.g. json.dumps(evidence_bundle, sort_keys=True, separators=(",",":"))) and reconcile it with (or explicitly widen) the str-typed summary shape every sibling tool uses.
  • Lower priority, not unique to this spec and not blocking: landing step (g), "Appends a row to evidence/gates.ndjson if a gate transitioned," does not say where that row's content -- specifically gate_row.schema.json's free-text notes / pass_condition / falsifies_condition fields -- comes from, or how/whether it is checked against production/schemas/claim_fence.json before being written. I confirmed test/gate_registry_integrity_test.exs only checks JSON shape, required keys, and receipt-path existence -- it does not fence-check any free-text field, and this gap is systemic (it would apply to any manual gates.ndjson edit too), not introduced by this spec. Since docs/GATES.md's binding "Fence discipline" section governs exactly this ledger, this spec should at minimum name the content's provenance (most plausibly: verbatim from the landed diff, which was already reviewed under the MERGED VERDICT gate) or explicitly disclaim that this verb does not itself synthesize free-text gate-row prose, so a future reader doesn't assume step (g) is a second, unchecked place felt-state or over-claim language could enter a public-facing surface.

systems-architect

• Verdict: SIGN_WITH_CHANGES
• Rationale: All four prior BLOCKED findings are genuinely resolved and I independently re-verified each against live code rather than trusting the spec's prose: (1) help.py TOOL_HELP registration is now named against the real boot-time _verify_tool_consistency() check at server.py:922-945 (read-only literal at 928-932), matching exactly; (2) I loaded evidence_bundle.schema.json into the jsonschema library and computationally confirmed the new $defs/uni_propose_change variant correctly makes the three C-C1 fields required+non-empty while the base schema stays generic for other mutating tools -- refusal check #5 is now mechanically enforceable exactly as the spec claims, and I found no other schema consumer whose contract this breaks; (3) test/production/ genuinely doesn't exist, no pytest scaffolding exists anywhere in the repo (verified via find), and uni/brain/test_active_inference.py is a real precedent whose shape I read and confirmed matches what the spec describes -- the new test coverage is correctly scoped as new work, not confabulated infrastructure; (4) the cross-reference to SPEC_uni_self_audit.md honestly flags that spec's Registration section as still-unfixed rather than claiming false consistency, which I verified by reading that spec's live Registration section. However, my own fresh check surfaced a real, code-verified defect the fix pass didn't touch: the spec's envelope/refusal response-shape claims don't match what the real metadata()/_approval_refusal() functions in server.py actually produce, and don't even match each other -- the exact defect class that already sank the sibling spec to FAIL under the same review process on this codebase. Because the required fixes are scoped, nameable prose/parameter corrections (reconcile the envelope claims with the real metadata() shape or explicitly flag envelope.schema.json as aspirational/PENDING per this repo's own honesty rail; fix the summary= argument type) rather than a fundamental rework of the verb's design, SIGN_WITH_CHANGES is the correct verdict rather than REVISE or REJECT.
• Concerns:
  • Envelope/refusal shape claims are checkably false against live code. SPEC_uni_propose_change.md's Signature comment ('-> dict: # envelope response per production/schemas/evidence_bundle... envelope.schema.json v1') and its 'Envelope conformance' section ('Every response from this verb wraps result inside the envelope schema') assert conformance to production/schemas/envelope.schema.json, which requires top-level {schema_version, envelope:{server,instrument_version,timestamp,evidence_class,...}, result} (envelope.schema.json:8-9,14-15). But Registration step 4 has the real implementation call metadata() (production/mcp/server.py:91-118) on success and _approval_refusal() (server.py:215-231, itself wrapping metadata()) on refusal -- I read both and confirmed they return a flat, unrelated shape: {ok, tool, data, evidence_class, provenance:{...}, help, docs, audit_id?, how_to_fix?}, with no schema_version/envelope/result keys. I grepped server.py and production/mcp/adapters/*.py for 'schema_version' and found zero hits -- nothing in the live codebase produces the shape envelope.schema.json describes. The spec's own 'Refusal envelope' line ({envelope:{...}, refused:true, result:{reason, failed_field}}) is a THIRD shape that matches neither the schema-consumers' real output nor what _approval_refusal() actually returns -- an internal inconsistency independent of the schema question. This is the same defect class that already earned the sibling SPEC_uni_self_audit.md a FAIL from math-breaker (docs/receipts/lab_team_review_85b0e8c.md, concern 1: 'envelope-conformance claim is checkably false against the file it cites... metadata() emits an entirely different top-level shape'). It was not among the four prior BLOCKED findings for this spec and remains unaddressed in this corrected pass.
  • Registration step 4's approvals.require call passes summary=evidence_bundle (a dict) where the real require() signature (server.py:188-189, 'def require(self, tool, args, *, summary: str = "", force: bool = False)') types summary as str, and every one of the ~14 existing call sites in server.py (lines 550, 565, 582, 598, 619, 636, 655, 674, 695, 737, 769, 800, 819, 835, 878, 903) passes a formatted string, never a raw dict. As written this doesn't cleanly satisfy the spec's own D-B1 claim that 'the human's approval decision must be reproducible from the SAME bytes the agent saw' -- a Python dict repr is not the canonical JSON bytes the sha in evidence_bundle would be computed over. Should be something like summary=json.dumps(evidence_bundle, sort_keys=True).
  • Minor/optional: production/docs/receipts/uni_authored_.md substitutes a tag of the form uni-authored// (containing slashes) directly into a filename, which creates a nested production/docs/receipts/uni_authored_uni-authored//.md path rather than a flat, sane filename. This convention is inherited unchanged from production/docs/DEPLOYED_STATE.md:149 (not newly introduced by this pass) so it's low priority, but worth a one-line sanitization note before an implementer takes it literally.

RED Experimentalist / World Auditor (docs/lab_team/04_red_experimentalist.md) — role 4/5 on /lab-team-review, speaks after math+arch survive; designs the paired falsifying test and demands the registered PASS+FALSIFIES gate before signing.

• Verdict: SIGN_WITH_CHANGES
• Rationale: Independent re-verification, not just trusting the spec's prose, confirms three of the four prior BLOCKED findings are genuinely and mechanically resolved:

(1) help.py registration — RESOLVED. Every file:line citation in the Registration section (server.py:247-254 MUTATING_TOOLS, :256 HUMAN_GATED, :922-945 _verify_tool_consistency, :928-932 the read_only literal, help.py:56-186 TOOL_HELP) checks out exactly against the live source, verified with Read/Grep.

(2) evidence_bundle.schema.json required-array gap — RESOLVED, and I didn't just eyeball it: I ran the actual jsonschema (draft 2020-12) validator against the schema's new $defs/uni_propose_change variant with three probe bundles (missing the 3 fields, present-but-empty-string, fully valid). Resolved via the correct $id#/fragment $ref anchoring (the way any real implementation resolves 'evidence_bundle.schema.json#/$defs/uni_propose_change'), it correctly rejects the first two and accepts the third — the schema-variant fix mechanically works exactly as refusal check #5 claims. I also confirmed only DEPLOYED_STATE.md and this spec reference the schema path generically, so the additive $defs approach (leaving the base 'required' untouched) doesn't collide with any other consumer.

(3) missing test artifacts / no pytest scaffolding — RESOLVED. Verified test/production/ still doesn't exist and no pytest.ini/conftest.py exists anywhere in the repo; verified the cited precedent uni/brain/test_active_inference.py genuinely has the described shape (test_*() functions, main(), if __name__ guard) and that production/mcp/red_team_g_pa.sh genuinely exists in the cited shape. The spec correctly follows the real precedent instead of inventing unbuilt infrastructure, and correctly places new files under production/mcp/, not runs/ (which I confirmed is Elixir-colony-harness territory only).

(4) cross-reference to SPEC_uni_self_audit.md's Registration section is now slightly stale (see minor concern), a one-line prose fix, not a mechanical defect.

Where this fresh review earns its 'independent' billing: my specific mandate was testability — does the named test coverage catch a fabricated-but-schema-valid implementation, and is a FALSIFIES condition named. On both counts the answer for THIS spec is no, and the gap is not hypothetical: the sibling SPEC_uni_self_audit.md, corrected in the identical commit, demonstrates the author both knows this discipline applies to MCP-verb specs and knows how to write it (explicit FALSIFIES section, flip/field-provenance/cross-check tests) — yet SPEC_uni_propose_change.md, which governs the far higher-stakes self-modifying-code landing path, has neither. That is a genuine, named, fixable gap under this repo's own binding rules (CLAUDE.md science-gate discipline #4 + persona design principle #2), not manufactured scrutiny.

I did not manufacture additional concerns to pad this out — the schema/help.py/test-scaffolding fixes are clean, verified, and I say so plainly. I'm recommending SIGN_WITH_CHANGES rather than REVISE because the two required additions are precisely scoped and precedented by the sibling spec sitting right next to this one (a FALSIFIES section in the same shape, and landing-path tests in the same shape as the self_audit spec's field-provenance/flip/cross-check pattern) — this does not need a fresh open-ended rework pass, it needs those two named sections added.

Process note for whoever lands the MERGED VERDICT: during this review I directly observed production/mcp/SPEC_uni_propose_change.md and production/schemas/evidence_bundle.schema.json being actively rewritten by what appears to be a concurrent agent session — HEAD moved from 62dc97d to 8c1a557d mid-review, and two consecutive reads of the same path returned genuinely different byte content before settling. This matches the standing note that production/schemas/ + specs are a contested multi-agent-write surface ("PULL before touching evidence/docs/GATES/schemas/heartbeat/verify_p1_v2"). Everything in this review is checked against the settled snapshot at commit 8c1a557d034c18b1bcf64fa972198e30f73b85fa (2026-07-12 16:08:03) — re-diff against that exact commit before trusting this verdict if more time has passed.

• Concerns:
  • [REQUIRED] No FALSIFIES condition is named anywhere in SPEC_uni_propose_change.md (grepped the whole file for "FALSIFIES"/"falsif" — zero matches). CLAUDE.md's binding science-gate discipline #4 ("every cure registers its gates — named PASS condition + FALSIFIES condition — before the run") and the repo-wide persona design principle #2 ("Demand the falsifier before the cure. Every persona states the RED condition that would reject the proposal before suggesting fixes") both bind here. Proof this is the expected bar for MCP-verb specs, not just FE cures: the sibling spec corrected in this SAME commit, production/mcp/SPEC_uni_self_audit.md, carries an explicit '## FALSIFIES' section citing this exact CLAUDE.md rule for a read-only tool. uni_propose_change is the highest-stakes verb in the system — it lands self-authored commits/tags against the repo's own source — and needs a named no-go for its landing-fidelity claim, e.g.: 'the file tree at the landed tag diverges from git apply of the exact diff bytes attested by evidence_bundle.git_head_sha, OR the landing receipt's verdict field disagrees with the RED launcher's actual exit code/stdout.'
  • [REQUIRED] Test coverage (production/mcp/test_uni_propose_change.py + red_team_uni_propose_change.sh, spec lines 96-127) only exercises the six pre-approval refusal checks plus the schema-variant check. Zero named tests touch the Approval + landing flow's positive path (spec lines 76-89: git-apply on a fresh worktree, commit+trailer, deterministic tag, RED-launcher run, landing receipt write, DEPLOYED_STATE.md/gates.ndjson append). A fabricated-but-schema-valid implementation that correctly refuses malformed calls, but on approval skips the real git-apply/RED-run and just writes a hardcoded verdict:PASS receipt plus a fake DEPLOYED_STATE.md row, would pass every named test in this spec. Direct precedent for closing this in the SAME commit: SPEC_uni_self_audit.md's Test coverage section explicitly names this exact failure mode ('an implementation could pass by hardcoding schema-valid-looking values while fabricating half of what it claims to observe') and adds field-provenance/flip/cross-check tests to close it — this spec's Test coverage has no equivalent for the apply/commit/tag/receipt path, which is the actual mutating, irreversible surface of this tool.
  • [minor, file-grounded] Registration step 4 (spec lines 45-52) writes the example call as approvals.require(..., summary=evidence_bundle, force=True), passing the whole evidence_bundle dict as summary=. The live, only-executing _LocalApprovals.require() (production/mcp/server.py:188-189) types summary: str = "", and every one of the ~15 existing call sites in server.py passes a short human-readable f-string (e.g. summary=f"GO LIVE to {target}" at server.py:878; summary=f"admit guest {guestId} to air" at server.py:819). The force=True refusal path even interpolates summary via !r} into the denial reason string (server.py:197), so a raw dict renders as a Python repr, not canonical bytes. The spec invokes the D-B1 'same bytes the human sees' claim twice (lines 5, 47-49) but doesn't reconcile this — worth a one-line fix (e.g. JSON-serialize evidence_bundle before passing as summary) so that claim doesn't quietly break.
  • [minor, stale prose] Cross-references section (spec lines 135-141) says SPEC_uni_self_audit.md's Registration section 'currently only says add to the read-only tools, not MUTATING_TOOLS... keep the two Registration sections in the same shape when that spec is next corrected' — but I read the live SPEC_uni_self_audit.md and it has already been corrected in this same pass (its own 'What changed' item 9 documents the exact 3-step help.py/TOOL_HELP fix, and the Registration section now matches this spec's shape). This note is now factually stale about the sibling's current state and should be updated to 'confirmed consistent' rather than 'pending next correction.'

embodiment-designer (docs/lab_team/05_embodiment_designer.md) -- this spec is MCP infrastructure (uni_propose_change / evidence_bundle.schema.json), not an FE-touching organ, so the persona's usual organ/B/C/allostasis/action-clone-invariance checks are not applicable. Per the task's redirect I applied the persona's exposure/redaction lens (explicit field-level allowlist for anything crossing to a public surface; path/host-layout leaks) plus a fresh independent re-verification of every prior finding and every file:line citation against the live repo, the same discipline the original review used.

• Verdict: SIGN_WITH_CHANGES
• Rationale: All four prior BLOCKED findings check out as genuinely resolved on independent re-verification against the live repo, not just re-stated:

1. help.py TOOL_HELP registration -- Registration step 3 is explicit and every file:line citation (server.py:247-254 MUTATING_TOOLS, server.py:256 HUMAN_GATED, server.py:241-245 IN_SHOW_VERBS, server.py:922-945 _verify_tool_consistency, server.py:928-932 the read_only literal, server.py:8-14 the async-tool docstring shape, help.py:56-186 TOOL_HELP) is byte-exact against the live files -- I read server.py and help.py in full and confirmed every range.

2. evidence_bundle required-fields gap -- fixed via an additive $defs/uni_propose_change sub-schema (allOf: [{$ref:"#"}, {required:[the 3 fields], minLength:1 constraints}]), which is valid JSON Schema 2020-12 and does not break the base schema's additionalProperties:false (the 3 fields are already declared, optionally, in the base properties). I confirmed the only other two consumers of evidence_bundle.schema.json in the repo (docs/PUBLIC_REPRODUCIBILITY_BUNDLE.md, production/docs/DEPLOYED_STATE.md) reference it only generically, not against a shape this change would break. Refusal check #5 now names the exact JSON-pointer path (#/$defs/uni_propose_change), making it mechanically enforceable, not prose.

3. Test artifacts -- confirmed via find: no test/production/ directory, no pytest.ini/pyproject.toml/conftest.py anywhere in the repo; uni/brain/test_active_inference.py exists and matches the self-contained test_*()+assert+main() shape the spec describes. The spec now correctly locates its two new files at production/mcp/test_uni_propose_change.py and production/mcp/red_team_uni_propose_change.sh (not the old fictitious test/production/... and runs/... paths), mirroring the real, confirmed-existing production/mcp/red_team_g_pa.sh (I read it in full -- live-HTTP CAPTURE tool, bearer token, MCP streamable-HTTP initialize + Mcp-Session-Id handshake, exactly as described). Pytest scaffolding is correctly flagged as a named future prerequisite, not assumed to exist.

4. Cross-reference consistency with SPEC_uni_self_audit.md -- the actual Registration SECTIONS are now consistent in shape (both correctly do a 3-4 step checklist citing the same boot-time _verify_tool_consistency() check for their respective tool-set literal). But the prose Cross-references NOTE describing that sibling spec's state is stale -- see concern #2 above; this is the one prior-finding item that is only partially closed.

My assigned focus (embodiment exposure / redaction) came back clean: uni_propose_change is not proxied onto the public MCP surface (confirmed absent from SPEC_uni_public_mcp.md by grep), every path-bearing field (spec_path, red_launcher_path, review_verdict_path, and the three evidence_bundle path fields) is explicitly typed/described as repo-relative, and the diff itself is inherently repo-relative by the unified-diff format -- there is no field-level allowlist gap and no host-path/IP/secret leak to flag here, unlike the self_audit spec (which genuinely needed one for its Board/Mind-sourced kins[] fields). This spec simply doesn't touch a Mind-state or host-filesystem surface, so no allowlist is needed.

Independently (not on my assigned focus, and not in the given prior-findings list) I found one new, concrete, file-grounded defect: the spec's own Signature/​"Envelope conformance" text claims a schema conformance its own specified implementation (metadata()) does not produce -- confirmed by reading both the schema and server.py directly, and cross-checked against SPEC_uni_self_audit.md, which had the identical problem and explicitly fixed it in its own revision.

Neither of my two concerns requires redesigning any mechanism -- the refusal checks, registration steps, and schema enforcement are sound and re-verify cleanly against live source. Both are narrow, named prose corrections (fix two paragraphs), so SIGN_WITH_CHANGES rather than REVISE.

• Concerns:
  • production/mcp/SPEC_uni_propose_change.md's Signature comment ("# envelope response per production/schemas/envelope.schema.json v1") and its "Envelope conformance" section ("Every response from this verb wraps result inside the envelope schema (D-B2 -- production/schemas/envelope.schema.json)") claim conformance to envelope.schema.json's nested {schema_version, envelope:{server, instrument_version, timestamp, evidence_class, ...}, result} shape (verified by reading production/schemas/envelope.schema.json:6-46, required+additionalProperties:false at both levels). This is false per the spec's OWN Registration step 4, which specifies the implementation returns via server.py's metadata() (verified live at server.py:91-118) -- a flat {ok, tool, data, evidence_class, provenance:{server,version,git_commit,timestamp}, help, docs} shape with different field names, no nesting, no 'result'/'envelope' keys. This is the identical false-conformance pattern SPEC_uni_self_audit.md's own correction pass explicitly fixed for itself (its 'What changed' item 4: envelope.schema.json 'reframed as aspirational/future; the spec now matches the REAL flat metadata() shape... instead of claiming false conformance'). Fix: reword both spots in SPEC_uni_propose_change.md to say the tool follows the same flat metadata() shape every other tool in server.py produces, and that envelope.schema.json is a stated future migration target this verb does not meet today -- mirroring the sibling spec's own correction.
  • production/mcp/SPEC_uni_propose_change.md's 'Cross-references' section, citing SPEC_uni_self_audit.md, is stale: it states self_audit's Registration section 'currently only says "add to the read-only tools, not MUTATING_TOOLS"' and asks to align the two 'when that spec is next corrected' -- but SPEC_uni_self_audit.md has already been rewritten (its own frontmatter reads 'Revision: rewritten in full against the REVISE verdict at docs/receipts/lab_team_review_85b0e8c.md') and its Registration section (verified live at lines 117-131) is now a complete 3-step checklist citing the same _verify_tool_consistency() boot-check treatment this spec asks for. The cross-reference note should be updated to state the sibling spec is already corrected and that the two Registration sections are (substantively) already in the same shape, rather than describing the correction as still pending -- a reader trusting this note at face value would be misled about the current state of a file this spec cites as authoritative context.

MERGED VERDICT

SIGN_WITH_CHANGES

(Merge rule: the worst verdict wins.)

Honesty note

This is a v2 receipt following a spec-correction pass driven by the v1 review's own findings. This is the first formal review this spec has received. No FE source code (.ex/.exs/.py/.cjs) was written or modified by either the fix pass or this review -- only spec/schema/policy documents. If this verdict is SIGN or SIGN_WITH_CHANGES, implementation may proceed through this repo's normal ship gate; if REVISE or REJECT, further spec work is needed before any code diff.

Addendum — named changes applied (pass 3)

This is a direct-apply pass, not a fresh persona re-review — it closes out the named concerns above by editing the spec/schema files directly. It is not another independent verification round; nothing below should be read as a sixth persona's verdict. Every file:line citation used to write these fixes was re-read against the live repo before editing (server.py:91-118, 188-189, 215-231, 819, 922-945, 928-932; envelope.schema.json:6-46; gate_row.schema.json; DEPLOYED_STATE.md:127-149; SPEC_uni_self_audit.md:117-131; production/scripts/broadcast_test.py). Files touched: production/mcp/SPEC_uni_propose_change.md, production/schemas/evidence_bundle.schema.json. No .ex/.exs/.py/.cjs source was written or modified.

• math-breaker, concern 1 (approvals.require() call-shape mismatch, action= kwarg does not exist) — FIXED: rewrote both call sites (Registration step 4, Approval + landing flow step 3) to match the real _LocalApprovals.require(self, tool, args, *, summary="", force=False) signature (server.py:188-189) exactly — no action= keyword; the tag context that had been passed via the nonexistent action= now lives inside the args dict ("tag" key), consistent with every real MUTATING_TOOLS call site.
• math-breaker, concern 2 (summary=evidence_bundle raw dict vs. str-typed parameter, unfalsifiable "same bytes" claim) — FIXED: both call sites now specify summary=json.dumps(evidence_bundle, sort_keys=True, separators=(",", ":")), named explicitly as the canonical, deterministic serialization that makes the D-B1 "same bytes" claim mechanically true, matching the str-typed summary every sibling call site (e.g. server.py:819, admit_guest) uses.
• math-breaker, concern 3 (self-referential $ref: "#" schema fragment, reproducible RecursionError under naive standalone validation) — FIXED: added an explicit "Resolution note (implementation-critical)" to refusal check #5 in the spec, and a matching sentence to the $defs.uni_propose_change description in evidence_bundle.schema.json, both naming the correct resolve-against-the-enclosing-document pattern and warning against extracting the $defs fragment standalone.
• math-breaker, concern 4 (minor: "ONE real precedent" overclaim against production/scripts/broadcast_test.py) — FIXED: softened "the ONE real precedent for a standalone Python test" to "the clearest precedent for a standalone Python test harness" and added a parenthetical noting broadcast_test.py exists, matches the *_test.py naming convention, but is a 5-stage diagnostic script, not a competing unit-test-harness shape.
• math-breaker, concern 5 (process caveat: uncommitted/actively-edited working tree, commit before treating SIGN_WITH_CHANGES as durable) — NOT FIXED — genuine judgment call for the owner: this is an operational/process concern about when to commit, not a defect in the spec's own text, and it is already covered by this repo's existing binding rule (CLAUDE.md, Method of work #2, "Shipping production/ goes via git archive of an immutable, pushed ref — never the working tree"). There is nothing to edit in the spec document itself to resolve it; committing the current working tree is an action for whoever lands this pass, not a spec-content fix.
• aif-theorist, concern 1 / RED Experimentalist concern 4 / embodiment-designer concern 2 (stale Cross-references note describing SPEC_uni_self_audit.md's Registration as still-deficient) — FIXED: re-read SPEC_uni_self_audit.md:117-131 live, confirmed its 3-step Registration checklist (including the TOOL_HELP entry) already matches this spec's shape, and rewrote the Cross-references bullet to say parity is already achieved instead of "pending next correction."
• aif-theorist, concern 2 (same summary=evidence_bundle issue, D-B1 reproducibility) — FIXED: same fix as math-breaker concern 2 above (one shared defect, one shared fix).
• aif-theorist, concern 3 (lower priority: gates.ndjson row content provenance for landing step (g) not named) — FIXED: added a sentence to Approval + landing flow step (g) naming the row's free-text fields (notes/pass_condition/falsifies_condition per gate_row.schema.json) as sourced verbatim from the already-reviewed diff/spec, and explicitly noting this step does not itself check that text against claim_fence.json (named as a pre-existing, systemic gap shared by every manual gates.ndjson append today, not introduced by this verb — no source code was touched to "fix" that systemic gap, per the task's scope).
• systems-architect, concern 1 / embodiment-designer concern 1 (envelope/refusal shape claims checkably false against live metadata()/_approval_refusal(), and inconsistent with the spec's own third "refusal envelope" shape) — FIXED: rewrote the Signature return-type comment, the "Refusal envelope" line under Refusal shape, the on-deny line in Approval + landing flow step 5, and the full "Envelope conformance" section to state the real flat metadata()/_approval_refusal() shape (verified live at server.py:91-118, 215-231) and to name envelope.schema.json as an aspirational future migration target — mirroring the identical, already-landed correction in SPEC_uni_self_audit.md's "Result shape" section.
• systems-architect, concern 2 (summary=evidence_bundle issue) — FIXED: same fix as math-breaker concern 2 above.
• systems-architect, concern 3 (minor: uni_authored_<tag> landing-receipt filename would nest directories because the tag contains slashes) — FIXED: added a sanitization note to Approval + landing flow step (e) naming the required transform (e.g. tag.replace("/", "_")) before substitution into a filename, while leaving the slash-bearing tag format itself (inherited from DEPLOYED_STATE.md:149) unchanged.
• RED Experimentalist, concern 1 [REQUIRED] (no FALSIFIES condition named anywhere in the spec) — FIXED: added a new ## FALSIFIES section (placed between Non-goals and Test coverage, mirroring SPEC_uni_self_audit.md's placement), naming the landing-fidelity falsifier (landed file tree diverging from git apply of the attested diff bytes, OR the receipt's verdict disagreeing with the RED launcher's real exit code).
• RED Experimentalist, concern 2 [REQUIRED] (zero named tests touch the Approval + landing flow's positive/apply-commit-tag-receipt path; a hardcoding implementation would pass every existing test) — FIXED: added three new tests to the Test coverage section (landing-fidelity, RED-launcher-fidelity, fabrication-resistance) that specifically target the positive landing path and are the tests the new FALSIFIES condition is exercised by pre-ship.
• RED Experimentalist, concern 3 [minor] (summary=evidence_bundle issue) — FIXED: same fix as math-breaker concern 2 above.
• RED Experimentalist, concern 4 [minor, stale prose] (Cross-references section describes the sibling spec's correction as still pending) — FIXED: same fix as aif-theorist concern 1 above.
• embodiment-designer, concern 1 (envelope conformance false claim) — FIXED: same fix as systems-architect concern 1 above.
• embodiment-designer, concern 2 (stale Cross-references note) — FIXED: same fix as aif-theorist concern 1 above.

Summary: of the ~13 distinct named concerns across the five personas (several concerns were the same underlying defect flagged independently by multiple personas — the summary=evidence_bundle/action= call-shape mismatch by four personas, the stale cross-reference by three, the envelope-conformance false claim by two), all were resolved as direct spec/schema edits except one: math-breaker's process caveat about committing the working tree before treating this verdict as durable, which is an operational note about repository state and timing, not a defect in the spec document's content, and is left as a judgment call for whoever lands this pass (the underlying rule it invokes is already binding via CLAUDE.md and did not need restating in this spec).