Files
chimera-gfx-Public/docs/runtime/phase-0.9d-operational-windows.md
Chimera GFX release export a6037502d7
phase0-ci / build-and-audit (push) Successful in 2m14s
Publish Chimera GFX source
2026-09-03 03:27:14 +02:00

92 lines
3.3 KiB
Markdown

# Phase 0.9D operational windows
Date: 2026-07-18
Status: future review design only
No window is authorized by this document. Because the existing stack has no
file readback route, Window 2 is currently blocked and the later windows cannot
open.
## Window 1 — manual fact collection
Proposed content:
- firmware text exactly as displayed in the PS5 interface;
- visible exploit, loader, and Manager status/version strings;
- non-secret device/session identifier;
- operator photograph or literal transcript;
- autoload state only if it is visible without a request or mutation.
Prohibitions: network request to Manager unless separately justified, file
transfer, `/autoload_status`, payload launch, configuration change, USB
operation, retry.
Current outcome: `PARTIAL`, then `BLOCKED_WINDOW1` until a concrete
non-mutating operator procedure is reviewed. It can become
`READY_FOR_WINDOW2_REVIEW` only through a new exact authorization.
## Window 2 — single off-device readback
Intended constraints:
- one existing component and one literal proven live source path;
- PS5-to-host only;
- no write/create/truncate/rename/unlink/delete/upload/launch/autoload/config,
no automatic retry or resume;
- new exclusive local output, binary framing, exact byte count, short-read and
timeout rejection;
- any accepted `server_active_flag`, logging, socket, buffer, counter, cache,
atime, scheduling, audit, accounting, or network-counter effect must be named
by the future permission.
Current outcome: `BLOCKED_NO_READBACK_PATH`. There is no first component to
recommend. No route satisfies binary response, exact length, EOF, short-read,
and partial-output rejection.
## Window 3 — independent repeat readback
Would require a new connection/session and output, no reused bytes, no
resume/retry, full size/hash/byte comparison, and no automatic third attempt.
A mismatch means `SOURCE_UNSTABLE_OR_READBACK_INVALID`.
Current outcome: `BLOCKED` because Window 2 is blocked.
## Window 4 — second component
Would require separate permission, session, and files after successful Windows
2 and 3. A combined backup-all operation is forbidden.
Current outcome: `BLOCKED`.
## Window 5 — recovery contract review
Offline only. A matching pair of host copies may establish
`OFF_DEVICE_BACKUP_VALID`, never `RECOVERY_PROVEN`. Exact write executor,
non-self-dependence, target selection, write-then-verify, old-file retention,
and power-loss behavior must be proven.
Current outcome: `UNPROVEN`.
## Window 6 — non-live staging
Outside Phase 0.9D and blocked until both readbacks match, live target mapping
is proven, independent recovery is sufficient, a non-live staging path is
proven, and a separate permission exists.
## Window 7 — side-by-side execution
Outside Phase 0.9D. No autoload, retry, live replacement, or combined lifecycle
probe is permitted. Current classification: `BLOCKED`.
## Hard stops
- no existing PS5-to-host file transport;
- no runtime-observed live component path;
- current installed identity and persistence are unproven;
- exploit/port-9020 executor source and repeatability are absent;
- independent byte-exact restore is absent;
- power-loss-safe restore is unproven;
- current Payload Manager backup is still the installation blocker;
- every device write is blocked by missing independent recovery;
- all authorization fields remain false.