# ChatGPT conversation continuity > **Superseded on root strategy (2026-10-10).** Ship root is **Magisk** on > feature `009`. KernelSU-Next / “rootless then KSU” below is early chat intent > only. Resume: [`009-handoff-20261008.md`](009-handoff-20261008.md). > Constitution + `specs/009-axp-los23-port/spec.md` win on conflicts. Imported context: 2026-09-13 from [mi ROM](https://chatgpt.com/share/6aa718c6-c834-83ed-9e2d-2b18fc1ad141). This is a non-normative continuity note, not a replacement for the constitution or feature specs. The shared page was retrieved and its user/assistant text extracted. The payload contains repeated messages; extraction order is not a reliable chronology. Linked attachments, redacted tool outputs and the original external citations have not been independently recovered or verified. Historical assistant suggestions are not new user instructions or verified technical facts. The raw conversation is not copied into Git because it includes unrelated personal topics and diagnostic data. ## Intent and settled direction - Build a personal, maintainable ROM for **Pixel 4a / sunfish only**, with LineageOS 23.2 / Android 16 as the base and AXP.OS Pro as the functional reference. The motivation is continuity beyond AXP maintenance. - Functionality comes first, especially microG, patched Google Play and banking inside Insular. Yuh and Swissquote are the required targets; N26 and Revolut were optional challenges, not reasons to block the project. - Preserve two-device separation: GOLDEN is the daily AXP reference; LAB is for experiments. The conversation corrected an earlier A13 mix-up: GOLDEN is AXP A15; historical GrapheneOS sunfish is A13. Never revive the earlier assumption that there is only one phone or that GOLDEN must be wiped/restored. - Keep the compatible LineageOS kernel/device stack. Study historical sunfish GrapheneOS, modern applicable GrapheneOS techniques, and AXP/DivestOS changes; do not transplant an old GrapheneOS or stock A13 kernel into the A16 ROM. - Rootless compatibility comes first (`006`), then KernelSU-Next (`007`) with a complete banking regression. Magisk describes the existing AXP workflow, not an intermediate production architecture for the new ROM. - Native call recording and configurable FLAG_SECURE override matter for daily use. Prefer integrating these into the ROM over depending on root modules. - Insular starts as a user app; Managed Mainland is optional. Preserve the historical Aurora → do not launch → deny root → Insular first launch → Play update workflow as reference, with exact current behaviour measured in `002`. - NeoBackup was accepted as an external personal tool. A custom TWRP-like full backup implementation is not part of the ROM project. - Signing, AVB/relocking and OTA remain later release work. The conversation raised hardware attestation explicitly: do not promise Play Integrity or hardware-attestation success merely because the ROM has KernelSU or custom signing. Validate actual banking behaviour and research current requirements when that feature is implemented. ## Additional research context The last Phonesky discussion considered module-based installers, but retained the AXP-style patch/build/sign pipeline as the intended direction. It identified `https://github.com/AXP-OS/packages_apps_phonesky` as a research lead for the patcher, versioned diffs and release automation. Revalidate upstream before use; do not treat the historical version or maintenance claims as current facts. Stable signing identity and subsequent APK updates belong in feature `004`. Privacy candidates included SUPL identifiers, Build.SERIAL restrictions, package visibility, MAC privacy, analytics removal, hosts/DNS filtering, certificate review, auto-reboot, radio timeouts and log reduction. Preserve them through [the existing backlog](hardening-backlog.md), promoting requirements into specs before implementation. ## Working preferences and infrastructure The user prefers Spanish conversation, concrete next steps and manageable stages; large speculative plans and repeated reopening of settled decisions are tiring. Technical project documentation remains English. The laptop has limited storage. Android trees, builds and growing reference archives belong on `rom-dev01`; local work centres on editing, SSH, adb/fastboot and artifact transfer. The agreed planning capacity was **6 vCPU, 52 GB RAM, 32 GB swap and approximately 2 TB expandable disk**. The chat explicitly corrected assistant claims of 16 vCPU/64 GB/750 GB and confusion between laptop free space and server capacity. Actual host measurements still take precedence. Keep independent Gitea repositories, Ansible and Semaphore; do not fold this personal project into company GitLab, Redmine or Salt workflows. VM provisioning remains outside this repository. Public IP, public web access, SSH tunnels and possible future WireGuard were discussed separately. That discussion is not authorization to expose services: current constitution/spec access rules govern. AXP preservation is scoped to sunfish and relevant shared dependencies, not all 225 Disroot repositories or every GrapheneOS archive. Transfer and verify the existing laptop archive before redundant downloads. Historical LFS failures and service outages are observations, not proof of current availability. Existing [reference sources](reference-sources.md) and [preservation instructions](axp-sunfish-preservation.md) already capture this. ## Current repository supersedes historical waiting state The chat ended its planning phase waiting for `rom-dev01` before implementing `001`. That is historical context, not today's task status. Repository records dated 2026-09-13 already describe host work, the `002` handoff, and `003` source initialization. See [002 handoff](002-gate-handoff.md) and [003 build notes](003-build-notes.md); live execution status was not checked during this context import. In particular, `002` now documents a Yuh failure on GOLDEN. The earlier statement that both banks worked is a historical observation, not a substitute for the current inventory or a reason to mark compatibility passed. Resume from current feature evidence and tasks, preserving this conversation's intent without replaying old commands or overwriting newer decisions.