Admit E3 and capacity on the test plane

Register in-process E3 and capacity fixtures, keep live database and
substrate targets pending, and ask ops-mason for namespace-only provision.
No packets, no credentials, no cancelled engagement IDs.

Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb

docs/e3-cadence.md

@@ -14,8 +14,13 @@ The executable plan is available with:
 
 ```sh
 PYTHONPATH=src python3 -m whitehat_security.cli e3-plan
+PYTHONPATH=src python3 -m whitehat_security.cli e3-fixtures
 ```
 
+`e3-fixtures` calibrates the seven expected outcomes in-process, including
+keeping the SQL-compromise reset as `inconclusive`. It opens no database
+connection and is not target assurance.
+
 The run checks the conformance view, unset-GUC reads, wrong-tenant reads and
 writes, `BYPASSRLS` on the runtime identity, and unsafe `SECURITY DEFINER`
 paths. The SQL-compromise reset probe is recorded as `inconclusive` under E3:

docs/operator-runbook.md

@@ -15,8 +15,8 @@ make fixture-evidence
 
 Success requires every read/write probe to pass against the enforcing fixture
 and to produce a finding against the fixture with its tenant predicate removed.
-`evidence/offline-calibration.json` is calibration evidence, not target
-assurance.
+`make fixture-evidence` also writes `evidence/offline-e3-calibration.json`.
+Both files are calibration evidence, not target assurance.
 
 ## Test plane
 

docs/rules-of-engagement.md

@@ -144,11 +144,13 @@ Live runs are admitted only through the test plane documented in
 projected short-lived identities, registered target, kill switch, rate watcher
 and lease cleanup. The plane is a control, not authorization.
 
-`fixture-e2` is the in-process class already permitted by §1. `live-e2` still
-requires the dated engagement record, target-owner acknowledgement and
-technique-specific operator approval required by §1, plus plane admission.
-`e3`, recovery, saturation and destructive techniques keep separate explicit
-approval classes and are not admitted by the E2 plane.
+`fixture-e2`, `fixture-e3` and `fixture-capacity` are in-process classes
+already permitted by §1. `live-e2` still requires the dated engagement
+record, target-owner acknowledgement and technique-specific operator approval
+required by §1, plus plane admission. Live `e3` additionally names the
+database and uses one ordinary runtime role with no `BYPASSRLS`. Live
+`capacity` additionally names an aggressor ceiling and a substrate window.
+Recovery and destructive techniques remain outside this plane.
 
 Cancelled engagement identifiers are terminal and must not be reused.
 

docs/test-plane.md

@@ -11,11 +11,15 @@ A live E2 run is admitted only when every item below is true:
 2. Known-bad calibration for that target has already failed in-process.
 3. The engagement is complete, in window, owner-acknowledged, and not a
    retired ID.
-4. `approval_class` is `live-e2` (or `fixture-e2` for in-process only).
+4. `approval_class` matches the registration (`fixture-e2` / `live-e2` /
+   `fixture-e3` / `e3` / `fixture-capacity` / `capacity`).
 5. The runner namespace is `whitehat`, the image digest is pinned, and
-   engagement labels are present.
-6. The custody broker projected exactly two identity *handles* (owner and
-   attacker). Credential values are not returned to the operator or agent.
+   engagement labels are present. Live E3 also names a `database`. Live
+   capacity also names an `aggressor_ceiling`.
+6. The custody broker projected the registered number of identity *handles*
+   (two for E2, one runtime for E3, none for capacity fixtures). Credential
+   values are not returned to the operator or agent. Live classes fail closed
+   while the custody broker is unconnected.
 7. The kill switch is clear.
 8. The rate watcher is attached. Cleanup revokes the lease.