operational-rigor + skill-vetting: trust-grant breadth — judge the effective grant expansion, never the syntax

reviews/2026-08-30-trust-grant-breadth/FINAL-WORDING-RECONSTRUCTION.md

@@ -0,0 +1,66 @@
+# Final-wording reconstruction — landed bytes vs r2-reviewed bytes
+
+**Claim:** the landed operational-rigor §2 canonical rule and the landed
+skill-vetting §2 mirror are byte-verbatim the two fenced blocks of the r2
+review packet (`design-review-packet-r2.md`) that both PROCEED verdicts
+reviewed.
+
+**Machine proof at landing** (pre-commit, against pre-landing main
+`5824f30222124c6e474e49f6c94b8923592550b6`): (1) the landed operational-rigor file contains the
+reviewed canonical block exactly once, byte-identical — block sha256
+`7b566804084eec8df77e667a7be435ec1ed3630026fa6323126984e565ce003d`; (2) the landed skill-vetting file
+contains the reviewed mirror block exactly once, byte-identical — block
+sha256 `b1a1779a2f2ba478e683ff44494dc38a087104abd7617da4723953e719effb2d`; (3) the full diff against
+pre-landing main is pure additions (zero deletions), the operational-rigor
+added-line multiset equals exactly the canonical block plus the owner-settled
+Provenance entry (sha256 `559727bf29b51b767d1b1da0b4c9ddce14113f88ccb05b487eacb26ba03400f0`) plus one
+separating blank line, and the skill-vetting added-line multiset equals
+exactly the mirror block.
+
+**DECLARED-LANDING-ADAPTATIONS (exhaustive):** (1) the single inline
+`unprobed` marker — already inside the r2-reviewed canonical bytes, zero byte
+delta; (2) the owner-settled Provenance entry (adjudication layer; it carries
+the file's second `unprobed` occurrence — the same one marker identity); (3)
+placement — canonical between the instruction-files install-gate block and
+the activation-gated-payload rule, mirror between MCP/tool auto-registration
+and self-vouching; no re-wrapping was needed. Substantive semantic drift:
+**0** — the implementation grant's stop-and-return clause (any third
+substantive wording change) was never triggered.
+
+**Neighbors byte-unchanged (explicitly extracted and matched):** the
+instruction-files bullet, the activation-gated-payload rule, skill-vetting's
+config-self-propagation and authorization-default-flip bullets, its MCP/tool
+auto-registration bullet, and its self-vouching + activation-gated-payload
+pointer block are each present verbatim in the landed files, and the
+pure-addition multiset proof above excludes any other change. Exactly two
+canonical files touched; the only other landed paths are this evidence
+package. Marker accounting: operational-rigor `unprobed` occurrences 59 → 61
+(inline marker + Provenance sentence — one marker identity), skill-vetting
+1 → 1 (the mirror carries none).
+
+**Special verifications (all machine-checked PASS):** the mirror carries no
+criterion copy ("effective granted capability set" absent), no clearers, no
+own fail-closed semantics ("nothing is restated here" present), and no
+marker; the canonical carries the independent-policy limb in the headline,
+disclosure-cannot-launder, human-typed-is-not-independent-authorization,
+fail-closed-without-enumeration, the authorized-as-a-class verdict language,
+and the deny/bounded/exact-grant protections; static controls W1–W8 + W2b
+9/9 (`STATIC-CONTROLS.md`).
+
+**Gate-artifact integrity (byte-verbatim copies of the review trail):**
+
+```
+3cee1e81272f5966ebf083a31d2fee1132c969b6b7008f772ea787e19eab06d0  design-review-packet-r1.md
+d19b06726713837db4999f6afc22ba1be4bdcc2f8bb638d868e5c1c2ba895a04  design-review-packet-r2.md
+059583f7d5856edc9e062795d9ee184676b2bd3f2c93e642db3b447061d4fc67  verdicts/r1-luna-max.md
+187a04f32e9803cb3ee54d6b9c7154f632f4c9dcec4f7e0405cb3d08273cd50c  verdicts/r1-sol-max.md
+bbbcf838f01bbd954a1f8d0e712254264db54bc47e936e269c254ba05437d277  verdicts/r2-luna-max.md
+e759f2a537d8d79b867059f136b6ae732bd790bf8ad5eefbda1212108794ec42  verdicts/r2-sol-max.md
+```
+
+Per-reviewer packet copies in the gate's isolated dirs were byte-identical to
+the canonical packets in both rounds (r1 packet sha256
+`3cee1e81272f5966ebf083a31d2fee1132c969b6b7008f772ea787e19eab06d0`, r2 packet sha256
+`d19b06726713837db4999f6afc22ba1be4bdcc2f8bb638d868e5c1c2ba895a04`); reviewer identity is from the tool
+banners recorded per run (`model: gpt-5.6-luna` / `model: gpt-5.6-sol`,
+`reasoning effort: max`, all four runs).

reviews/2026-08-30-trust-grant-breadth/README.md

@@ -0,0 +1,65 @@
+# Trust-grant breadth — design + landing record (candidate ③)
+
+**Landed rule:** `operational-rigor` §2 canonical — *a trust or allow rule is
+judged by its effective grant expansion, never its syntax* — placed between the
+instruction-files install-gate block and the activation-gated-payload rule;
+plus a bare-pointer mirror in `skill-vetting` §2 (**Over-broad trust grant**,
+between MCP/tool auto-registration and self-vouching). Invariant: **the
+effective granted capability set must stay within what was actually vetted, or
+what an independent trusted policy explicitly authorizes as a class.**
+
+## Trail
+
+1. **Orientation (read-only, adjudicated PARTIAL-GAP).** Existing doctrine
+   catches config WRITES (config self-propagation), authorization RHETORIC
+   (authorization-default flip), and tool REGISTRATION (MCP rule) — but no rule
+   anywhere evaluated whether a persistent trust/allow entry's EFFECTIVE GRANT
+   SET exceeds the actually-vetted set, and a candidate that merely instructs
+   the human to paste a broad grant intercepted nothing. External threat
+   evidence cited as shape (ATR-2026-02192; AWS Kiro AWS-2025-019) — not
+   first-hand reproduced (no such artifact was cloned or executed).
+2. **Owner-settled semantics.** Judge effective expansion, never wildcard
+   syntax (wildcards, prefixes, globs, inherited namespaces, future-name
+   patterns are examples, not the criterion); a candidate's own disclosure
+   never launders the breadth; a human typing the entry on the candidate's
+   instructions is not independent authorization; an independent trusted
+   owner/project policy CAN authorize the broader class — the verdict then
+   says authorized-as-a-class, never individually-vetted; bounded globs and
+   deny patterns are protected from false hits; undeterminable expansion fails
+   closed with no exhaustive future-name enumeration burden.
+3. **Design review — two rounds, dual-blind** (mutually blind, isolated dirs;
+   identity from tool banners in all four runs: `model: gpt-5.6-luna` /
+   `model: gpt-5.6-sol`, `reasoning effort: max`). **r1 = luna FIX-1 + sol
+   FIX-2**: convergent finding — the mirror restated the operative criterion
+   and clearance fragments, an incomplete second authority; sol additionally
+   flagged the headline ("silently" wrongly implied disclosure could matter,
+   and the independently-authorized limb was missing). Both findings were
+   reproduced first-hand and fixed. **r2 = luna PROCEED + sol PROCEED — 2/2,
+   zero findings**, all ten mandatory axes line-anchored by both reviewers
+   (canonical/mirror separation and the authorized-as-a-class verdict language
+   explicitly confirmed by both). Packets in `design-review-packet-r1.md` /
+   `design-review-packet-r2.md`; verdicts in `verdicts/`; per-reviewer packet
+   copies were byte-identical per round (hashes in
+   `FINAL-WORDING-RECONSTRUCTION.md`).
+4. **Owner adjudication.** Final wording ratified; implementation and
+   landing-to-PR authorized, with reviewer closure conditioned on the landed
+   blocks proving byte-identical to the r2-reviewed blocks (any third
+   substantive wording change → STOP; never triggered). Marker/provenance
+   shape settled: exactly one inline `unprobed` marker on the canonical rule;
+   an owner-settled Provenance entry in operational-rigor; the mirror owns no
+   criterion copy, no clearers, no fail-closed wording, and no marker.
+5. **Landing.** Both reviewed blocks landed **byte-verbatim**
+   (`FINAL-WORDING-RECONSTRUCTION.md`); declared landing adaptations: the
+   Provenance entry and placement only — the inline marker was already inside
+   the r2-reviewed bytes.
+
+## Status
+
+The rule carries **exactly one** new `unprobed` marker (canonical only; the
+mirror has none). **Behavioral transmission/effectiveness remains unprobed**;
+the future behavioral probe joins the standing #115 queue. Static
+discriminating power only — see `STATIC-CONTROLS.md` (W1–W8 + W2b, 9/9). The
+three locked sibling candidates (compiled-bytecode/decoy-source divergence;
+visible homoglyph deception; approval-fatigue reviewer-targeting) remain
+LOCKED — zero of their content here. Target runtime: runtime-agnostic (pure
+instruction text; no executable dependency).

reviews/2026-08-30-trust-grant-breadth/STATIC-CONTROLS.md

@@ -0,0 +1,22 @@
+# Static discrimination — trust-grant breadth (9/9; expected verdicts written before determination; doctrine-level, no behavioral probe)
+
+| # | Control | Setup | Expected | Landed clause that carries it | Verdict |
+|---|---|---|---|---|---|
+| W1 | GLOBAL-WILDCARD | `trustedCommands: ["*"]` | HIT | "ask whether the pattern's semantics CAN match anything beyond the reviewed set" | HOLDS |
+| W2 | PREFIX-FUTURE | `vendor/*`; only `vendor/tool-a` vetted | HIT | "present siblings and future arrivals inherit authorization nobody vetted" | HOLDS |
+| W2b | EXTERNAL-POLICY-BROAD-GRANT | same `vendor/*`, but the repo's own trusted policy explicitly authorizes the whole `vendor/*` class | ③ RECOGNIZED, then cleared by the independent policy; verdict must say authorized-as-a-class, never individually-vetted | "an independent, trusted owner or project policy … authorized-as-a-class by that policy, never that the broader members were individually vetted" | HOLDS |
+| W3 | EXACT-GRANT | precise `vendor/tool-a` | CLEAR | "a precise single-capability grant is the shape that clears" | HOLDS |
+| W4 | BOUNDED-GLOB | literal wildcard; effective set mechanically bounded to the vetted set | CLEAR | "independently bounded to the reviewed set … not hits for their syntax alone" | HOLDS |
+| W5 | DENY-GLOB | `deny: ["dangerous-*"]` | NOT a hit | "a deny/block pattern is no authority expansion however broad" | HOLDS |
+| W6 | REGISTRATION-NOT-TRUST | tool registered; no trust-pattern entry | ③ silent; the existing MCP rule governs | trigger requires a trust/allow ENTRY ("asks for a persistent trust/approval/allowlist entry") | HOLDS |
+| W7 | SELF-PROPAGATION-CROSS | candidate writes config AND broad trust | BOTH rules fire, orthogonally | "the write channel changes which OTHER rules also fire … never whether the breadth is a finding" | HOLDS |
+| W8 | HUMAN-ENTERED-BROAD-GRANT | candidate only instructs the human to paste `["*"]` | ③ still HIT; candidate's own framing clears nothing | "binds however the entry gets written … a human pasting the entry on the candidate's instructions is not independent authorization" | HOLDS |
+
+These are doctrine-level discrimination controls (the same table both r2
+reviewers received; expected verdicts were written before determination), not
+executed fixtures — nothing here was run against a live agent.
+
+W2b exists specifically to prove the carve-out's provenance discipline: the
+breadth is RECOGNIZED as a finding, the clearance can come only from the
+independent trusted policy, and the recorded verdict is class authorization —
+the broader members are never thereby individually vetted.

reviews/2026-08-30-trust-grant-breadth/design-review-packet-r1.md

@@ -0,0 +1,95 @@
+# Design-review packet — proposed doctrine rule "effective grant expansion" (③)
+
+You are one of two independent reviewers (mutually blind; you see only this packet). This is a WORDING-LEVEL design review of ONE proposed canonical rule for `skills/operational-rigor/SKILL.md` §2 plus a bare-pointer mirror for `skills/skill-vetting/SKILL.md` §2, in an agent-discipline skill pack. No bytes have landed; implementation is separately gated (including the marker/provenance shape). Review the PROPOSED WORDING on the ten axes below.
+
+## Settled context — do NOT re-vote it
+An orientation (owner-ratified PARTIAL-GAP) established: existing doctrine catches config WRITES (self-propagation rule), authorization RHETORIC ("assume authorized" flip rule), and tool REGISTRATION (MCP rule) — but no rule anywhere evaluates whether a persistent trust/allow entry's EFFECTIVE GRANT SET exceeds the actually-vetted set, and a candidate that merely tells the human to paste a broad grant intercepts nothing. The owner-locked invariant: **effective granted capability set ⊆ vetted/explicitly-authorized capability set; judge the expansion, never wildcard syntax — wildcards/prefixes/globs/namespaces/future-name patterns are examples, not the criterion.** Canonical home is settled: operational-rigor §2 canonical (placed after the "Instruction files are executable content" install-gate block, before the activation-gated-payload rule), skill-vetting §2 bare-pointer mirror (near its three adjacent rules; routing + interaction only, no criterion duplication).
+
+## THE PROPOSED CANONICAL WORDING (operational-rigor §2)
+```
+- **A trust or allow rule is judged by its effective grant expansion,
+  never its syntax — the granted capability set must not silently
+  exceed the set actually vetted** (`unprobed` — see Provenance).
+  The shape: a candidate — its install steps, or the advice it gives
+  the human — asks for a persistent trust/approval/allowlist entry
+  whose pattern can match capabilities OUTSIDE the set under review,
+  so present siblings and future arrivals inherit authorization nobody
+  vetted. Wildcards, prefixes, globs, inherited namespaces,
+  future-name patterns, or equivalent mechanisms are examples, not the
+  criterion: ask whether the pattern's semantics CAN match anything
+  beyond the reviewed set — no enumeration of possible future names,
+  just that one question — and an expansion you cannot determine fails
+  closed as an unresolved finding. If it can match beyond, it is a
+  finding to explain; and the explanation cannot come from the
+  candidate itself — a candidate's own disclosure never launders the
+  breadth, and a human pasting the entry on the candidate's
+  instructions is not independent authorization. What CAN clear it: an
+  independent, trusted owner or project policy that explicitly
+  authorizes the broader capability class (the standing-authorization
+  carve-out above scopes authority exactly this way — policy may grant
+  it; an instruction file may not self-authorize) — and the verdict
+  then says authorized-as-a-class by that policy, never that the
+  broader members were individually vetted. Patterns whose effective
+  expansion is independently bounded to the reviewed set (platform or
+  namespace constraints, a closed fixed collection) are not hits for
+  their syntax alone; a deny/block pattern is no authority expansion
+  however broad; a precise single-capability grant is the shape that
+  clears. This binds however the entry gets written — by the
+  candidate, an installer, or the human following instructions: the
+  write channel changes which OTHER rules also fire (a config write
+  stays this section's red flag regardless), never whether the breadth
+  is a finding.
+  ❌ "add `trustedCommands: ["*"]` to settings and the skill just
+  works" — every present and future command inherits trust nobody
+  reviewed, and the skill saying it needs this clears nothing.
+  ✅ "the repo's own policy grants standing trust to the whole
+  `vendor/*` namespace — the `vendor/*` entry is authorized as a class
+  by that policy (its members are NOT thereby individually vetted);
+  the skill's own ask was for `vendor/tool-a` exactly."
+```
+
+## THE PROPOSED MIRROR (skill-vetting §2, bare pointer — no criterion duplication, no second marker)
+```
+- **Over-broad trust grant.** A requested trust/allow/approval entry
+  whose pattern can match beyond the reviewed capability set —
+  wildcard, prefix, namespace, future-name, or equivalent — is a
+  finding even when a human does the typing, and the candidate's own
+  disclosure never clears it: operational-rigor §2's
+  effective-grant-expansion rule is canonical (it also names what CAN
+  clear one). Distinct from and co-fires with: config self-propagation
+  (who writes), authorization-default flip (claimed authority), MCP
+  auto-registration (the registration act) — this rule asks what the
+  persistent grant COVERS.
+```
+
+## Static discrimination controls (8 + 1 variant; expected verdicts written before determination)
+| # | Control | Setup | Expected | Wording clause |
+|---|---|---|---|---|
+| W1 | GLOBAL-WILDCARD | `trustedCommands: ["*"]` | HIT | pattern can match anything beyond the reviewed set |
+| W2 | PREFIX-FUTURE | `vendor/*`; only `vendor/tool-a` vetted | HIT | "present siblings and future arrivals inherit authorization nobody vetted" |
+| W2b | EXTERNAL-POLICY-BROAD-GRANT | same `vendor/*`, but the repo's own trusted policy explicitly authorizes the whole `vendor/*` class | ③ RECOGNIZED, then cleared by the independent policy; verdict must say authorized-as-a-class, never individually-vetted | "an independent, trusted owner or project policy … authorized-as-a-class by that policy, never that the broader members were individually vetted" |
+| W3 | EXACT-GRANT | precise `vendor/tool-a` | CLEAR | "a precise single-capability grant is the shape that clears" |
+| W4 | BOUNDED-GLOB | literal wildcard; effective set mechanically bounded to the vetted set | CLEAR | "independently bounded to the reviewed set … not hits for their syntax alone" |
+| W5 | DENY-GLOB | `deny: ["dangerous-*"]` | NOT a hit | "a deny/block pattern is no authority expansion however broad" |
+| W6 | REGISTRATION-NOT-TRUST | tool registered; no trust-pattern entry | ③ silent; the existing MCP rule governs | trigger requires a trust/allow ENTRY |
+| W7 | SELF-PROPAGATION-CROSS | candidate writes config AND broad trust | BOTH rules fire, orthogonally | "the write channel changes which OTHER rules also fire … never whether the breadth is a finding" |
+| W8 | HUMAN-ENTERED-BROAD-GRANT | candidate only instructs the human to paste `["*"]` | ③ still HIT; candidate's own framing clears nothing | "binds however the entry gets written … a human pasting the entry on the candidate's instructions is not independent authorization" |
+
+## Review scope — answer ALL ten explicitly
+1. Does the rule close the GRANT-BREADTH gap (effective set vs vetted set), rather than restating the config-write rule?
+2. Is the criterion genuinely independent of wildcard syntax (examples-not-criterion; a non-wildcard mechanism with the same expansion would still hit)?
+3. Is the human-entered broad grant still caught (W8)?
+4. Are bounded globs and deny globs protected from false hits (W4/W5)?
+5. Do registration, self-propagation, and authorization-flip stay orthogonal (W6/W7 + the mirror's distinct-from list)?
+6. Is the independent-policy carve-out safe — the candidate cannot self-vouch, the human-typed entry is not independent authorization, and the cleared verdict must say authorized-as-a-class rather than individually-vetted (W2b)?
+7. Does unknown/undeterminable expansion fail closed WITHOUT requiring exhaustive future-name enumeration?
+8. Do canonical + mirror avoid a dual-authoritative-source problem (mirror = routing + interaction only)?
+9. Is the rule complete without any runtime scanner/tooling?
+10. Zero content from the locked sibling candidates (compiled-bytecode/decoy-source divergence; visible homoglyph deception; approval-fatigue/human-reviewer batching)?
+
+## Marker note (informational)
+A single canonical `unprobed` marker on the op-rigor rule is PROPOSED (mirror carries none, per this pack's discipline); the owner adjudicates the final marker/provenance shape at the implementation gate — not part of this review's verdict.
+
+## Verdict format (mandatory)
+Number findings, anchor each to the wording, classify on an axis. Final line exactly one of:
+`PROCEED` or `FIX <numbered list of blocking findings>`