# Evidence package — Prune Data-Loss (four-gate isolation)

**Claim supported:** A promotion path reached `PARTIAL_SUCCESS` and cleanup (prune) then destroyed an
orphaned submodule commit before it could be pushed anywhere reachable. The remedy separated
close/promote/prune/deploy into four gates, made push-before-prune binding, made ambiguous reachability
a HALT with fail-closed exit codes, and Caliber **C112** keeps the isolation installed. (Articles:
foundational four-failures table; technical companion §3 walked example + §9.)

**Claim IDs:** E2-C001, E2-C002
**Evidence level:** fleet-codified (installed → enforced → exercised → outcome → fleet-codified)
**Access classification:** Sanitized public excerpt

## What this package proves, and what it does not

**Proves:** the close/promote/prune/deploy separation is real and each is its own command boundary
(`four-gate-contract.md`); the prune gate is fail-closed with named exit codes, orders push before any
destructive operation, and HALTs on ambiguous reachability (`prune-exit-codes.md`); the isolation is
mechanically enforced by a Critical, no-grace Caliber criterion (`c112-contract.md`); and the whole
control traces to a concrete incident whose three structural defects were eliminated rather than patched
(`incident-sequence.md`).

**Does not prove:** that the original data-loss event can be re-triggered from this package — that was a
one-time close-out of the Cure v2 blind-benchmark work recorded in the owner plan's failure narrative,
not reproducible here. This package evidences a **discipline/enforcement outcome** on internal build
tooling; it makes no claim about any production customer data (the destroyed commit was an internal
canary commit in an internal canary app).

## Source

- **Source date:** 2026-05-13 (incident remedy + codification); package built 2026-08-02.
- **Source commit:** `24ec65306` (FoundryOS monorepo).
- **Original internal locations:** `system/_operator/scripts/{close,promote,prune,deploy}-session.mjs`;
  `system/_operator/docs/CLOSE_PROMOTE_DEPLOY_CONTRACT.md § 1`;
  `system/caliber/lib/c112-four-gate-prune-isolation.mjs`; `system/caliber/docs/CRITERIA.md § Criterion 112`;
  `system/_operator/plans/2026-05-13-promote-session-resilience-push-before-prune.md`. The destroyed
  commit `cc1fc8a` and its recovery live in the `apps/rentos-canary` submodule / monorepo root history
  and are **Internal evidence only**.

## Redaction statement

No secrets, credentials, private URLs, API keys, tokens, connection strings, or customer/staff/tenant
identifiers appear in these artifacts. The sources are framework orchestration scripts, fleet
contract/doctrine, scanner logic, and an internal engineering plan. Two incident-specific identifiers
are retained because they are load-bearing and non-sensitive: `apps/rentos-canary` (an internal canary
app, not a customer tenant) and `cc1fc8a` / `202cec2` (internal git commit SHAs). See
`manifest.json` → `redactions`.

## Reproduction

- Four-gate separation: read the four script headers under `system/_operator/scripts/` and
  `CLOSE_PROMOTE_DEPLOY_CONTRACT.md § 1` (I75–I78); confirm each destructive/deploy capability is
  confined to exactly one gate.
- Fail-closed prune: read `system/_operator/scripts/prune-session.mjs` (EXIT map ~L74–84; reachability
  HALTs ~L443–461 and ~L584–600) and confirm codes 30/31/32/33 and push-before-prune ordering.
- Enforcement: run `node system/caliber/lib/c112-four-gate-prune-isolation.mjs --self-test` and confirm
  it exits PASS across all five dimensions.
- Incident: `system/_operator/plans/2026-05-13-promote-session-resilience-push-before-prune.md`
  (Objective, Defects D1–D3, failure narrative).