# Ballbox rebrand v3 status

## Base
- `/home/sebas/outputs/ballbox-machine-copy-final.zip`

## Work completed
- extracted and decoded the active Ballbox final package
- identified the English skin package as an APK-like `.skin`
- identified 3 main TCN APK variants carrying visible language strings
- confirmed existing Spanish translation resources already exist inside TCN APKs
- patched these packages so default / EN / ZH visible string resources resolve to Spanish-facing text
- rebuilt all 4 packages successfully
- signed rebuilt packages with a new local key
- assembled candidate package:
  - `/home/sebas/outputs/ballbox-machine-copy-v3-spanish-candidate.zip`

## Patched binaries
- `TcnFoldercopy/v3Skins/en_00~English-20260107.01.skin`
- `TcnFoldercopy/TCN-SD-05-V3.2.0.4-20250926.01.apk`
- `TcnFoldercopy/TCN-SD-05-V1.0.0.13-20251210.01.apk`
- `TcnFoldercopy/TCN_SD_05_V03.02.20250523.0110.apk`

## Truth / blocker
Main technical blocker now is signature trust, not buildability.

These APKs were rebuilt and re-signed with a new local key, not the original vendor signing key. If the machine enforces same-signature updates, field install may fail unless:
- vendor original signing key is available, or
- target machine allows fresh install / uninstall-reinstall path, or
- these APKs are only consumed as loose resources by another process.

So we have a real v3 candidate zip, but deployment truth depends on machine acceptance of the new signatures.

## Next decision needed from user
Need one deployment-path decision:
- try this candidate on the real machine as-is, accepting signature-risk
- or stop and pursue vendor-signature / install-path validation first