Publish Chimera GFX source

docs/runtime/phase-0.9-recovery-and-rollback-contract.md

@@ -0,0 +1,106 @@
+# Phase 0.9A recovery and rollback contract
+
+Status: **DESIGN_ONLY — RECOVERY UNPROVEN**.
+
+This contract states what future evidence must prove. It does not authorize or
+implement backup creation, transfer, installation, switch, rollback or
+execution.
+
+## Valid backup contract
+
+A future backup is valid only when all conditions hold:
+
+1. it is created before staging or any live mutation;
+2. the source object and exact restoration target are recorded;
+3. the source stays the same stable object throughout the read;
+4. every byte is read and the exact size is recorded;
+5. SHA-256 equals the current observed pre-image;
+6. the backup is a distinct object, not an alias of live;
+7. it is closed, reopened without redirection, re-identified and rehashed;
+8. its storage medium and mount are recorded;
+9. content and metadata capacity plus reserve are proven;
+10. autoload, cleanup and packaging cannot delete it;
+11. it is never replaced by candidate bytes;
+12. mapping is literal and not selected by a glob, basename or guess;
+13. rollback does not guess the live target;
+14. recovery can use it without the component being replaced.
+
+A second byte-exact off-device copy with its own manifest and SHA-256 is
+strongly recommended. Creating or transferring that copy is a later,
+separately authorized phase and is not permitted here.
+
+For the controlled Payload Manager, an absent, differing, unstable,
+non-reopenable or recovery-dependent byte-exact on-device backup remains a
+**HARD STOP-GATE**.
+
+## Recovery independence
+
+Before any component transaction, evidence must answer all rows without
+inference:
+
+| Question | Hardened elfldr | Controlled Payload Manager |
+|---|---|---|
+| How is recovery started? | UNPROVEN | UNPROVEN |
+| Which exact component executes recovery? | UNPROVEN | UNPROVEN |
+| Is that executor outside the component being replaced? | UNPROVEN | UNPROVEN |
+| Does recovery work when elfldr does not start? | UNPROVEN | UNPROVEN |
+| Does recovery work when Payload Manager does not start? | UNPROVEN | UNPROVEN |
+| Does recovery work without autoload? | UNPROVEN | UNPROVEN |
+| Does recovery work without the replaced listener? | UNPROVEN | UNPROVEN |
+| Is a second independent recovery path proven? | UNPROVEN | UNPROVEN |
+
+A generic console recovery mode is not counted. No public evidence in this
+repository proves that it restores custom project files.
+
+If rollback depends on the component being replaced, the result is:
+
+**CATASTROPHIC BLOCKER.**
+
+## Rollback transition
+
+Rollback is not an automatic exception path. It requires:
+
+```text
+POST_SWITCH_VERIFY failure
+-> ROLLBACK_REQUIRED
+-> separate human ROLLBACK_AUTHORIZED
+-> ROLLBACK_IN_PROGRESS
+-> ROLLBACK_VERIFIED
+```
+
+The rollback action may use only the already reopened and verified backup and
+the fixed target mapping. It may not autoload, start or retry either component.
+After the switch, path, mount, object ID, type, size, SHA-256, ownership, mode
+and relevant metadata are re-established before any later decision.
+
+An interrupted rollback is acceptable only if a proven atomic primitive leaves
+exactly one complete live identity and preserves the verified backup. That
+primitive is not proven on PS5. A wrong post-rollback hash is
+`CATASTROPHIC/BLOCKED`; there is no retry.
+
+## Component isolation
+
+The hardened elfldr and controlled Payload Manager have separate live
+pre-images, backups, candidates, target mappings, recovery dependencies,
+process/service/listener states, autoload evidence, approvals, staging,
+switches, post-switch checks, executions, acceptances and rollbacks.
+
+There is no shared approval and no combined transaction. A second component
+cannot begin until the first is separately accepted or fully rolled back.
+Which component comes first is `UNPROVEN`; order must follow demonstrated
+dependencies rather than convenience. The lifecycle probe is outside both
+installation and rollback models.
+
+## Current blockers
+
+- historical `READ_ONLY_PREFLIGHT_BLOCKED`;
+- current live identities and firmware behavior are unproven;
+- exact Payload Manager backup is absent as proven evidence;
+- filesystem atomicity, exchange, file durability and directory durability are
+  unproven;
+- process, supervisor, listener, autoload and retry topology is unproven;
+- no independent recovery executor or second recovery path is proven;
+- no component order is proven;
+- every device authorization remains false.
+
+No blocker is lifted by this design, manifest, host simulator or test result.