Concrete consumer failure
ContextualWisdomLab/ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472 received Noema CHANGES_REQUESTED on 2026-09-05 asserting that .github/workflows/product.yml's cargo generate-lockfile --locked is invalid because generate-lockfile does not support --locked.
That premise is false. The current official Cargo command reference for cargo-generate-lockfile(1) explicitly documents --locked under Manifest Options and describes the deterministic-CI behavior used by the workflow: https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html . The ConceptWeave line is therefore not a valid source repair target.
This is a review-evidence defect, not permission to dismiss the review, weaken review policy, fabricate approval, or push a no-op leaf commit.
Owner-path finding
The central review corpus already tells OpenCode to verify peer claims from source/tests/runtime-library documentation or scratch reproduction, but a Noema review can still elevate a mutable external-tool capability assertion into REQUEST_CHANGES without machine-verifiable primary evidence. The review body even claimed that Cargo documentation and runtime behavior confirmed the unsupported flag, while the primary documentation says the opposite.
Required RED/GREEN contract
Add a deterministic Noema review-gate regression shaped like the ConceptWeave case before changing production behavior:
- candidate finding asserts that a concrete CLI/library option or API is unsupported;
- supplied authoritative evidence states that the exact option/API is supported;
- the gate must not publish
REQUEST_CHANGES from the contradicted premise;
- absence of authoritative evidence must remain fail-closed/inconclusive rather than being converted to an invented approval;
- provenance must distinguish current primary documentation or executed scratch/runtime evidence from model-authored prose;
- do not hard-code Cargo or
generate-lockfile; the contract should cover externally mutable tool/library capability claims generally.
Prefer a bounded evidence/verification seam in the Noema review owner path over leaf-specific prompt wording. Preserve exact-head binding, orchestrator/free, reviewer identity, no-self-approval, and all existing adversarial-evidence requirements.
Consumer acceptance
After protected integration, re-review unchanged ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472. Acceptance requires the false Cargo premise not to survive as a blocking finding. ConceptWeave's separate CodeQL and independent-approval gates remain independently blocking until their own exact-head evidence is valid.
Concrete consumer failure
ContextualWisdomLab/ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472received NoemaCHANGES_REQUESTEDon 2026-09-05 asserting that.github/workflows/product.yml'scargo generate-lockfile --lockedis invalid becausegenerate-lockfiledoes not support--locked.That premise is false. The current official Cargo command reference for
cargo-generate-lockfile(1)explicitly documents--lockedunder Manifest Options and describes the deterministic-CI behavior used by the workflow: https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html . The ConceptWeave line is therefore not a valid source repair target.This is a review-evidence defect, not permission to dismiss the review, weaken review policy, fabricate approval, or push a no-op leaf commit.
Owner-path finding
The central review corpus already tells OpenCode to verify peer claims from source/tests/runtime-library documentation or scratch reproduction, but a Noema review can still elevate a mutable external-tool capability assertion into
REQUEST_CHANGESwithout machine-verifiable primary evidence. The review body even claimed that Cargo documentation and runtime behavior confirmed the unsupported flag, while the primary documentation says the opposite.Required RED/GREEN contract
Add a deterministic Noema review-gate regression shaped like the ConceptWeave case before changing production behavior:
REQUEST_CHANGESfrom the contradicted premise;generate-lockfile; the contract should cover externally mutable tool/library capability claims generally.Prefer a bounded evidence/verification seam in the Noema review owner path over leaf-specific prompt wording. Preserve exact-head binding,
orchestrator/free, reviewer identity, no-self-approval, and all existing adversarial-evidence requirements.Consumer acceptance
After protected integration, re-review unchanged
ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472. Acceptance requires the false Cargo premise not to survive as a blocking finding. ConceptWeave's separate CodeQL and independent-approval gates remain independently blocking until their own exact-head evidence is valid.