Files
AXP-Resurection/docs/chatgpt-context.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

101 lines
5.9 KiB
Markdown

# ChatGPT conversation continuity
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.