plugin check without flags records a FAILED C1 that blocks a valid enable; corpus gates never run C1

buildagent commented

2026-11-09 18:42:13 +01:00

Member

Found while auditing #531 (codex-531 D12) and investigated on the integration tree with rust 0.1.8 (sha256:039a50d1…). No bundled user is affected: bundled adoption and plugin add --grant requested run C1 under the requested grant, and it passes. Two defects remain.

1. A bare plugin check records a FAILED verdict, and that verdict blocks a valid enable.

Real operator flow in a scratch CODE_INDEX_HOME (pack, sign, trust add, install):

Command	Result
`plugin check $D --root <repo>`	`verdict FAILED`: `fixtures/call_shapes.rs REFUSED fact.role_not_granted`. The check ran with NO roles granted.
`plugin enable $D --root <repo> --grant requested`	`conformance_failed`, even though C1 under exactly that grant passes
`plugin check $D --root <repo> --capabilities lexical_local`	`verdict passed`; after this, `enable --grant requested` approves and indexes

call_shapes.rs emits lexical_local, one of the seven resolver roles the manifest requests (tests/packages/rust/plugin.toml:44).
check records its explicit authority (crates/cli/src/plugin.rs:2991).
enable requires a covering passing verdict (plugin.rs:3464).

A verdict recorded under a NARROWER grant should not block an enable under a wider grant. Expected, as one rule: enable with a grant the recorded verdict does not cover re-runs C1 under that grant, as add already does. A bare check either uses the manifest's requested grant or says in its output that it checked with no roles.

2. The corpus gates never run C1. install_shipped (crates/test-support/src/shipped.rs:142-161) writes a requested-grant approval directly. A corpus green therefore cannot show that an operator could actually admit the package. Expected: the gate runs C1 under the requested grant once per package before grading it.

Found while auditing #531 (codex-531 D12) and investigated on the integration tree with rust 0.1.8 (`sha256:039a50d1…`). **No bundled user is affected:** bundled adoption and `plugin add --grant requested` run C1 under the requested grant, and it passes. Two defects remain. **1. A bare `plugin check` records a FAILED verdict, and that verdict blocks a valid enable.** Real operator flow in a scratch `CODE_INDEX_HOME` (pack, sign, `trust add`, install): | Command | Result | |---|---| | `plugin check $D --root <repo>` | `verdict FAILED`: `fixtures/call_shapes.rs REFUSED fact.role_not_granted`. The check ran with NO roles granted. | | `plugin enable $D --root <repo> --grant requested` | `conformance_failed`, even though C1 under exactly that grant passes | | `plugin check $D --root <repo> --capabilities lexical_local` | `verdict passed`; after this, `enable --grant requested` approves and indexes | - `call_shapes.rs` emits `lexical_local`, one of the seven resolver roles the manifest requests (`tests/packages/rust/plugin.toml:44`). - `check` records its explicit authority (`crates/cli/src/plugin.rs:2991`). - `enable` requires a covering passing verdict (`plugin.rs:3464`). A verdict recorded under a NARROWER grant should not block an enable under a wider grant. Expected, as one rule: `enable` with a grant the recorded verdict does not cover re-runs C1 under that grant, as `add` already does. A bare `check` either uses the manifest's requested grant or says in its output that it checked with no roles. **2. The corpus gates never run C1.** `install_shipped` (`crates/test-support/src/shipped.rs:142-161`) writes a requested-grant approval directly. A corpus green therefore cannot show that an operator could actually admit the package. Expected: the gate runs C1 under the requested grant once per package before grading it.

buildagent referenced this issue

2026-11-11 07:24:31 +01:00

v0.41.49: PHP namespace paths, settled answers, validated configuration, rules files removed #567