📦 deps(thirdparty): update snapshots

2026-06-21 09:15:23 +00:00
parent 0e1bb1aef3
commit 3d137606c0
805 changed files with 93512 additions and 4532 deletions
@@ -0,0 +1,76 @@
+# Review Waiver Method
+
+Review waivers make human risk acceptance explicit. They are not a way to hide problems; they are a local audit record for warning-level risks that the reviewer intentionally accepts for a bounded release window.
+
+## When To Use
+
+Use a waiver when:
+
+- Review Studio shows a warning that is understood and intentionally accepted.
+- The warning cannot be fixed before release without a worse tradeoff.
+- A reviewer can name the reason, scope, evidence, and expiry date.
+
+Do not use a waiver for blocker gates in v0. Blockers must be fixed before production, library, governed, or public readiness is claimed. In governed mode, missing or invalid high-permission approvals are blockers and should be fixed in `security/permission_policy.json`, not waived.
+
+## Required Fields
+
+Every waiver must include:
+
+- `gate_key`: the Review Studio gate being accepted.
+- `decision`: `accepted-risk`, `false-positive`, or `temporary-exception`.
+- `reviewer`: the accountable human or team.
+- `reason`: a concrete reason of at least 20 characters.
+- `created_at`: ISO date.
+- `expires_at`: ISO date.
+- `evidence`: optional path or note that explains the decision.
+- `scope`: default `current-release`.
+
+## Gate Key Policy
+
+The waiver ledger must track the Review Studio gate universe explicitly:
+
+- `review_studio_gate_keys`: every gate Review Studio can render.
+- `waiverable_gate_keys`: warning gates that may receive bounded human acceptance.
+- `non_waivable_gate_keys`: gates that must not be accepted through a waiver.
+
+When Review Studio adds or renames a gate, update the waiver gate policy and tests in the same change. `review-waivers` and `world-class-evidence` stay non-waivable: the first is the waiver mechanism itself, and the second can only be satisfied by accepted ledger evidence.
+
+## Release Semantics
+
+- Invalid waiver records block Review Studio.
+- Expired waiver records stay visible and no longer cover warnings.
+- Active waivers cover only the exact gate key they name.
+- A warning without an active waiver remains visible as a warning.
+- Raw user prompts, outputs, credentials, and private transcripts must not be stored in waiver reasons.
+
+## Commands
+
+Render or validate the ledger:
+
+```bash
+python3 scripts/render_review_waivers.py .
+```
+
+Add a bounded approval:
+
+```bash
+python3 scripts/yao.py review-waivers . \
+  --add-waiver \
+  --gate-key trust-report \
+  --reviewer "Yao Team" \
+  --reason "Network-capable scripts are documented and bounded for this release." \
+  --expires-at 2026-09-30
+```
+
+For a non-governed release where `permission-gates` is only a warning, the same command can name `--gate-key permission-gates`. Governed releases must instead provide reviewer, scope, reason, expiry, evidence, and target-enforcement fields in `security/permission_policy.json`.
+
+Review Studio reads `reports/review_waivers.json` and links to `reports/review_waivers.md`.
+
+## Candidate Actions
+
+The waiver report also surfaces current candidate actions from local evidence:
+
+- waiverable warning candidates, such as an `output-lab` warning caused by pending reviewer decisions or missing provider-backed runs
+- non-waivable boundaries, especially `world-class-evidence`, where pending ledger evidence cannot be converted into completion by a waiver
+
+A waiver can make a bounded warning auditable for a release window. It cannot count as provider-backed evidence, human adjudication, native runtime enforcement, external telemetry, or public world-class readiness.