Files
AXP-Resurection/specs/002-axp-reference-capture/spec.md
T
sunfish-admin 12d2179c20 AXP Magisk resurrection track: Speckit 009 port AXP/LOS22 to LOS23.
Ship Magisk like GOLDEN; KernelSU optional recycle only; parallel to sunfish-a16-rom standby.
2026-09-16 21:56:22 +00:00

8.0 KiB
Raw Blame History

Feature Specification: AXP.OS GOLDEN reference capture

Feature Branch: 002-axp-reference-capture

Created: 2026-08-09

Status: P1 complete (gate to 003); archive rsync may still finish in background

Input: Document and sample the GOLDEN daily-driver AXP.OS sunfish as a live compatibility oracle; label GOLDEN vs LAB; prepare LAB stock factory rescue. Experimental flashing stays on LAB only (docs/device-roles.md).

Context / non-goals

  • There are two sunfish devices: GOLDEN (AXP.OS 22.2 / Android 15 daily driver — do not experiment/flash) and LAB (flash/reflash freely).
  • Exact GOLDEN build fingerprint/patch is measured here (getprop). GOLDEN is AXP 22.2/A15 — not the last GrapheneOS sunfish release (that was A13, historical reference only).
  • Broader offline AXP sunfish archive (website, selected git, images) is documented in docs/axp-sunfish-preservation.md for execution on rom-dev01 — not a full Disroot org clone; does not replace live GOLDEN adb.
  • Capture essential versions/config up front; GOLDEN remains available for later live adb re-queries — do not require an exhaustive one-shot dump of everything before 003.
  • NeoBackup / wipe / migrate GOLDEN are not project requirements.
  • Do not invent package versions/UIDs in the constitution; this feature records what GOLDEN actually runs.
  • Do not commit credentials, tokens, or personal identifiers to Git.
  • Observe devices; do not assume bootloader unlock state until measured (both GOLDEN and LAB).
  • Product intent vs AXP Pro lives in non-normative docs/axp-pro-parity.md.

User Scenarios & Testing (mandatory)

User Story 1 - Device roles + LAB stock rescue (Priority: P1)

As the developer, GOLDEN and LAB are clearly identified, and LAB has a written Google factory-image emergency rescue so experiments cannot permanently brick the lab phone.

Why this priority: Prevents flashing the wrong phone; keeps LAB recoverable.

Independent Test: Serials/labels documented; factory image procedure for LAB reviewed; GOLDEN marked do-not-flash.

Acceptance Scenarios:

  1. Given two sunfish devices, When I record serials (or equivalent IDs) and physical/doc labels, Then GOLDEN vs LAB cannot be confused.
  2. Given GOLDEN and LAB, When I inspect bootloader/fastboot/getprop on each, Then lock state and build identity are recorded without prior assumptions.
  3. Given official Google sunfish factory images, When I document image set, hashes, and flash steps for LAB, Then LAB emergency stock rescue exists before 003 experiments.
  4. Given project docs, When reviewed, Then they state GOLDEN must not receive experimental project flashes.

User Story 2 - Essential GOLDEN inventory (Priority: P1)

As the developer, I have enough structured inventory of GOLDEN AXP to start 004–006, knowing I can re-probe GOLDEN later for missing details.

Why this priority: Defines the live oracle without blocking on perfection.

Independent Test: Essential checklist complete or explicitly deferred with “re-query GOLDEN later” notes — no silent unknowns for hard-gates.

Acceptance Scenarios:

  1. Given GOLDEN AXP, When I collect getprop / fingerprints, Then exact ROM/build identifiers are stored.
  2. Given microG, When inventoried at essential level, Then recorded: version, signing cert; Self-Check; Device Registration; Cloud Messaging; relevant permissions.
  3. Given Phonesky / com.android.vending, When inventoried, Then recorded: version; APK path; cert; permissions; spoofing state; useful dumpsys package / priv-app XML notes.
  4. Given Insular, When inventoried, Then recorded: profile IDs; profile owner; dumpsys device_policy excerpt; owner vs work UIDs/packages; Yuh/Swissquote locations.
  5. Given Magisk/root, When inventoried, Then recorded: Magisk version; modules; DenyList including processes.
  6. Given GSF Proxy and related packages, When inventoried, Then versions/paths/signatures are recorded.
  7. Given banking interest, When measurable, Then record observational Play Integrity (or equivalent) state plus Yuh/Swissquote pass/fail on GOLDEN — comparative baseline only, not a Strong Integrity promise for our ROM.
  8. Given Daily-driver MVP features we will replace natively, When capturing modules/settings, Then document current call-recording and FLAG_SECURE bypass behaviour/source on GOLDEN (AXP vs module; global/per-app).

User Story 3 - Golden banking flow on GOLDEN (Priority: P1)

As the developer, the known-good banking install order is written from GOLDEN so 006 can reproduce it on LAB (with KernelSU substituting DenyList later).

Why this priority: Order is load-bearing.

Independent Test: Step list matches GOLDEN procedure.

Acceptance Scenarios:

  1. Given GOLDEN, When I document the banking app install flow, Then it explicitly includes:

    1. Aurora Store → install
    2. Do not open
    3. Magisk DenyList before first process (include processes)
    4. Clone into Insular
    5. First launch inside Insular
    6. Phonesky/Play in Insular
    7. Play update inside work profile if required
    8. Verify login/biometrics/push/reboot as applicable
  2. Given that flow, When stored in the redacted summary, Then it omits passwords, OTPs, and personal identifiers.


User Story 4 - Safe artifact handling (Priority: P2)

As the developer, sensitive captures stay off Git; redacted summaries are committed to sunfish-a16-rom.

Acceptance Scenarios:

  1. Given raw pulls/APKs, When stored, Then they live under e.g. /srv/rom/references/axp/ on rom-dev01, not in Git.
  2. Given in-repo summary, When reviewed, Then it has versions/hashes/ workflow steps without personal secrets.

Edge Cases

  • GOLDEN encrypt/PIN: document without storing the PIN.
  • Missing detail later: re-attach GOLDEN and adb — do not invent.
  • LAB brick: use LAB stock factory rescue; do not wipe GOLDEN to “recover”.
  • Optional personal NeoBackup of GOLDEN is outside project gates.

Requirements (mandatory)

Functional Requirements

  • FR-001: Label and record GOLDEN vs LAB identities; measure bootloader/ fastboot state on both.
  • FR-002: Document LAB Google factory-image emergency rescue (hashes + steps).
  • FR-003: Capture essential GOLDEN inventory (microG, GSF, Phonesky, Insular, Magisk/DenyList processes, Yuh/Swissquote, call-recording + FLAG_SECURE sources, observational Play Integrity if measurable).
  • FR-004: Document GOLDEN banking flow (Aurora → NO OPEN → DenyList → Insular → Play update).
  • FR-005: Store raw artifacts off-Git; commit only redacted docs.
  • FR-006: Gate: no experimental flash on LAB until LAB rescue docs exist and GOLDEN is explicitly marked do-not-flash; no NeoBackup/wipe of GOLDEN required.
  • FR-007: Cross-link useful facts into docs/axp-pro-parity.md / docs/device-roles.md without inventing unseen features.

Key Entities

  • GOLDEN: live AXP oracle (not wiped for bring-up).
  • LAB: experimental flash target + stock rescue docs.
  • Reference bundle: host-local capture directory.
  • Redacted summary: in-repo documentation.

Success Criteria (mandatory)

Measurable Outcomes

  • SC-001: GOLDEN vs LAB clearly identified; agents/docs forbid flashing GOLDEN.
  • SC-002: LAB stock factory rescue written and reviewed before 003.
  • SC-003: Essential GOLDEN inventory + banking flow complete enough for 006 hard-gates; gaps marked “re-query GOLDEN” not invented.
  • SC-004: Yuh/Swissquote verified working on GOLDEN and documented.
  • SC-005: Git has no proprietary APK dumps or personal credential material.
  • SC-006: Bootloader states in docs match measured GOLDEN and LAB reality.