CUA demo-proof blocked: shared dev host has no isolated emulator/disk, external disk unmounted

[OpenCodeEngineer]

Summary

Attempted to build + record a CUA demo of the core user journey for the demo-proof task. Blocked by dev-host environment issues, not app code.

Findings (real command output, this session)

1. External disk /Volumes/Dzianis-3 (holds ANDROID_HOME, AVDs, gradle cache per AGENTS.md) is not mounted. diskutil list external returns nothing; /Volumes/ only shows Macintosh HD.
2. ~/.gradle was a dead symlink pointing at /Volumes/Dzianis-3/macbook2020/gradle-cache (unmounted). Removed and replaced with a local dir as a workaround.
3. Fallback local Android SDK exists via Homebrew at /opt/homebrew/share/android-commandlinetools (emulator, platform-tools, build-tools, android-34 google_apis_playstore/arm64-v8a system image) — this part is fine.
4. Root disk free space collapsed from 9.2Gi → 1.3Gi within ~10 minutes, driven entirely by other, unrelated concurrent agent sessions on the same physical machine: TaroAiScanner and KineticAiCoach gradle builds (assembleDebug, multiple gradle daemons at .gradle-local, .gradle-apfs, .scratch/gradle-home) plus a KineticAiCoach CUA demo (e2e/cua/drive_flow.py) actively running adb ... screenrecord against the shared AVD.
5. The only available AVD (kinetic_play) is already running (qemu pid started 12:40PM, well before this task) and is actively in use by the KineticAiCoach session's own recording (screenrecord --time-limit 175 /sdcard/rec_*.mp4, uiautomator dump). My own emulator -avd kinetic_play ... launch attempt died immediately (lock contention) — adb devices was showing the other session's instance, not one I control.

Why this blocks the task

• Starting a fresh gradlew assembleDebug (needs to download gradle-8.14.3, ~200MB+ deps) with <1.5Gi free risks a disk-full crash — the same failure mode that already killed an earlier turn of this task ("11:50 prompt had been lost to the disk-full event").
• Installing OpenCode Mobile onto the shared, already-recording kinetic_play emulator would interleave with the other session's app under test, corrupting both recordings' provenance — not acceptable for a demo-proof video.

Recommendation

• Provision this dev host with per-project/per-session disk and AVD isolation (separate GRADLE_USER_HOME + dedicated AVD port per session), or reattach /Volumes/Dzianis-3 reliably so ANDROID_HOME/gradle-cache don't silently fall back to the tiny root volume.
• Add a disk-space guard (e.g. refuse to start emulator/gradle build below ~5Gi free) to prevent repeat disk-full incidents.

Status

Not proceeding with build/record until disk recovers to a safe margin (>5Gi) and the shared emulator is free, to avoid corrupting other in-flight sessions or crashing the shared host again.

[OpenCodeEngineer]

Update: repeated failures across multiple retries — candid failure report

Retried the full pipeline several times as disk was intermittently freed by the supervisor/user. Documenting final state for this task cycle.

What worked

• APK builds clean. Root-caused and fixed two real app-repo bugs blocking the build (not disk-related):
  1. android/build.gradle pinned ndkVersion via rootProject.ext.ndkVersion with no explicit value — resolved default (27.1.12297006) has no source.properties on this host (stub/corrupt install), while NDK 29.0.14206865 is fully installed. Fixed by adding an explicit ext { ndkVersion = "29.0.14206865" } override before the RN plugin applies.
  2. android/app/debug.keystore was missing — generated standard debug keystore via keytool.
  3. Also restricted -PreactNativeArchitectures=arm64-v8a (was building all 4 ABIs incl. armeabi-v7a/x86/x86_64 for an arm64-only emulator target — pure waste, and the direct cause of one disk-critical abort mid-build).
  • Result: assembleDebug → BUILD SUCCESSFUL, android/app/build/outputs/apk/debug/app-debug.apk (60MB).

What's still blocked: emulator boot

• Disk on this shared host oscillated 10Gi → 490Mi → 5.0Gi → 368Mi → 2.3Gi → 1.1Gi → 955Mi (now) over the course of ~2 hours, driven by concurrent unrelated sessions (KineticAiCoach, TaroAiScanner) building/recording on the same box.
• Google Play Store system images enforce a hard ~7.2GB userdata-partition floor regardless of disk.dataPartition.size overrides in config.ini — tried 6G→2G→1.5G, emulator always demanded the same 7372.80MB. Could not create a smaller dedicated AVD.
• Fallback to the pre-existing agentpod_e2e AVD (zero new disk allocation needed) also failed emulator's hasSufficientDiskSpace preflight check at 1.1Gi free.
• Every time disk was freed to a workable level, it was consumed again by other sessions within 5–10 minutes — this is a moving target, not a one-time blocker.

Ask (unchanged from original issue, now with harder evidence)

• Per-session disk/AVD isolation on this dev host (separate GRADLE_USER_HOME + dedicated AVD port + disk quota per concurrent agent session), or
• A disk-space guard that reserves emulator/build headroom instead of first-come-first-served, or
• Reattach /Volumes/Dzianis-3 reliably so heavy Android tooling doesn't compete with other projects for root-disk space at all.

Status

Video/Short/Notion-link demo-proof not produced this cycle — root cause is host-level disk contention outside this task's control, not app code. APK itself is verified buildable. Will retry emulator boot the moment disk is confirmed stable (~4-5Gi, sustained).