updates

Author: Shaw

launchdocs/07-android-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 07: Android Build And QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: `build:android:system` is now present at the repo root and in `packages/app/package.json`.
+- Still open: mobile device-bridge embedding requests are mismatched with the device client, Android smoke CI still appears to install SDK 34 while the project compiles SDK 36, and legacy release signing workflow drift remains.
+- Launch gate: static mobile artifact checks pass; emulator, physical device, Cuttlefish/AOSP, Play upload, foreground service, Doze, logcat, SELinux, and cloud-hybrid embedding tests remain unvalidated.
+
 ## Current state
 
 Android is a real Capacitor app under `packages/app`, with current app identity `ai.elizaos.app` / `elizaOS` (`packages/app/app.config.ts:21-30`, `packages/app/capacitor.config.ts:4-24`). The Gradle project targets minSdk 26, compileSdk 36, targetSdk 35, Java 21, AGP 9.2.0, and Kotlin 2.3.21 (`packages/app/android/variables.gradle:1-17`, `packages/app/android/build.gradle:17-30`, `packages/app/android/build.gradle:46-59`).

launchdocs/08-cloud-milady-ai-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 08: Cloud milady.ai QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: pairing-token 202 server-side tests exist.
+- Still open: the Web UI client still lacks 202 retry handling, custom `dockerImage` is sent by the UI but stripped by API schema, raw dashboard `fetch` calls bypass shared bearer-token injection, and authenticated cloud lifecycle e2e remains missing.
+- Launch gate: cloud API-key client/redaction coverage is wired into launch QA; live login, agent creation, web UI open/resume, billing, and migration flows still need credentialed validation.
+
 Review timestamp: 2026-05-04 PDT. Scope was repo inspection plus public, non-mutating network checks. I did not create accounts, provision agents, open checkout, or spend money.
 
 ## Current state

launchdocs/09-desktop-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 09: Desktop QA
 
+## Second-Pass Status (2026-05-05)
+
+- Current: the core desktop runtime-mode risks remain accurate, including disabled/manual-mode UX coverage and local/runtime persistence divergence.
+- Still open: packaged Electrobun Playwright regressions are not exposed by a package script, release CI references missing heavy/desktop scripts, and `test-electrobun-release.yml` still contains intentional no-op porting checks.
+- Launch gate: desktop work is not fully automated; add real packaged Playwright scripts and wire release CI before treating desktop launch validation as complete.
+
 ## Current state
 
 The desktop app is an Electrobun shell around the app-core renderer. The shell owns the main window, tray/menu behavior, detached surfaces, native OS permission bridges, auth/session bridges, and an optional embedded app-core runtime child process.

launchdocs/10-remote-interfaces.md

@@ -1,5 +1,11 @@
 # Launch Readiness 10: Remote Interfaces
 
+## Second-Pass Status (2026-05-05)
+
+- Current: the main blockers are still accurate: cloud pair has no consume/promote/update-ingress path, no persisted expiry, and T9a data-plane resolution still happens before the final durable session id exists.
+- Still open: phone manual pairing and chat mirroring are placeholders, remote scenarios are weak prompt-routing checks rather than transport/session tests, and multi-controller revoke/fanout e2e is missing.
+- Launch gate: app-core pairing-token and LifeOps service tests cover pieces only; add cloud-to-T9a contract and two-client browser/data-plane tests before launch.
+
 ## Current state
 
 Remote/second-device support exists in several partially overlapping layers:

launchdocs/11-browser-wallet-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 11: Browser And Wallet QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: launchpad dry-run now stops before transaction-triggering steps, and `providerOption` is implemented and tested.
+- Still open: no pump.fun launchpad support, Solana cloud signing still depends on local `SOLANA_PRIVATE_KEY`, external browser bridge cannot inject wallet providers, app-browser action schema is not realistic enough for site automation, and transaction previews remain thin.
+- Launch gate: fake-wallet tests are useful deterministic coverage; real wallet extension, site login, signature rejection/approval, testnet transaction, and selector-drift checks remain live/manual.
+
 ## Current state
 
 Static review says the side-chat browser path can open, navigate, inspect, click, fill, upload, and run desktop-only realistic actions when the desktop browser workspace bridge is configured. The Browser view prompt is explicitly watch-mode oriented and says the agent must narrate each browser action and never auto-sign transactions.

launchdocs/12-computer-use-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 12: Computer Use QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: agent status now recognizes `@elizaos/plugin-computeruse` and has a regression test.
+- Still open: default approval posture remains `full_control`, OS permission grants can auto-enable the plugin, settings still has two separate Computer Use controls, and approval-mode API/client lacks visible app UI.
+- Launch gate: route/overlay tests cover deterministic behavior; real desktop click/type/screenshot, macOS TCC, permission revoke/regrant, and packaged app validation remain live/manual.
+
 ## Current state
 
 Computer use is implemented as the optional core plugin `@elizaos/plugin-computeruse`. The plugin registers a `computeruse` service, desktop/browser/window/file/terminal actions, and a provider that exposes platform capabilities, recent actions, and approval queue state. The service defaults to `approvalMode: "full_control"` unless `COMPUTER_USE_APPROVAL_MODE` is configured or changed through the compat API.

launchdocs/14-lifeops-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 14: LifeOps QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: follow-up tracker task-row seeding and Google OAuth callback channel refresh drift are fixed and covered by tests.
+- Still open: connected-account flows are mostly mocked or manual, local-only intent sync needs product signoff, and WhatsApp/Twilio/Ntfy/Discord/Signal/Telegram route parity needs deterministic fake-adapter coverage plus periodic live checks.
+- Launch gate: `fake-connectors.contract`, follow-up tracker, and Google connector tests cover critical pieces; repair or delete the permanently skipped browser-settings defaults test before counting it as evidence.
+
 ## Current state
 
 LifeOps is implemented as a broad app plugin in `plugins/app-lifeops`. The plugin registers LifeOps actions for browser bridge management, calendar/inbox, X, approvals, routines, relationships/followups, Twilio, remote desktop, cross-channel send, intent sync, password/autofill, health, subscriptions, unsubscribe, payments, connector management, and mutations (`plugins/app-lifeops/src/plugin.ts:207`). It also registers providers/services for browser bridge context, blockers, LifeOps context, health, inbox triage, cross-channel context, activity profile, browser bridge service, website blocker service, activity tracking, and presence signal bridging (`plugins/app-lifeops/src/plugin.ts:254`).

launchdocs/15-utility-apps-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 15: Utility Apps QA
 
+## Second-Pass Status (2026-05-05)
+
+- Current: Workflow Builder remains a package-level stub while the user-facing route is `/automations`; Screenshare remains hidden; Electrobun menu entries still drift from renderer app entries.
+- Still open: Android Contacts/Phone/WiFi packages are not imported by the host app, WiFi is absent from native entrypoints, and current tests do not catch renderer registration gaps.
+- Launch gate: add host-import/native-entrypoint assertions and make Screenshare tests discoverable before treating utility apps as complete.
+
 ## Current state
 
 The app catalog has a working client-side path for bundled utility apps. Renderer-owned internal tools are injected before server catalog data so their curated names, hero images, order, capabilities, and direct routes win over bare runtime entries (`packages/app-core/src/components/pages/AppsView.tsx:451`). The merged catalog loader also combines static catalog apps, installed apps, and registered overlay apps, then hides explicitly internal/system-only packages from normal browse (`packages/app-core/src/components/apps/catalog-loader.ts:13`, `packages/app-core/src/components/apps/helpers.ts:43`).

launchdocs/16-all-app-pages-qa.md

@@ -1,5 +1,11 @@
 # Launch Readiness 16: All App Pages QA
 
+## Second-Pass Status (2026-05-05)
+
+- Superseded: route smoke coverage exists in `packages/app/test/ui-smoke/all-pages-clicksafe.spec.ts` and is now mandatory through `packages/app` `test:e2e`.
+- Still open: overlay direct-route filtering is inconsistent, Phone/Messages/Contacts can silently fall back to chat outside Android, `/apps/tasks` semantics are confusing, and app-window/native overlay rendering is not covered end to end.
+- Launch gate: extend the Playwright smoke to representative app-window and native overlay URLs before calling all pages fully verified.
+
 ## Current state
 
 The launch host is `packages/app`, with shared page rendering and navigation in `packages/app-core`. The same React renderer is used by web, Capacitor mobile, and Electrobun desktop; desktop adds detached surface windows and per-app windows, while mobile adds native WebView configuration and Android-only phone surfaces.

launchdocs/17-prompt-optimization.md

@@ -1,5 +1,11 @@
 # Launch Readiness 17: Prompt Optimization
 
+## Second-Pass Status (2026-05-05)
+
+- Current: prompt source drift remains real; source prompt files do not fully match generated core prompts, and planner/response scoring still mixes older XML/action-name expectations with TOON-era prompts.
+- Still open: explicit TOON encapsulation, same-timestamp optimized-prompt tie-breaking, token efficiency budgets, planner `params` scoring, and dataset contamination checks need tests.
+- Launch gate: training-focused tests cover pieces, but no held-out prompt-quality/effectiveness gate proves the optimized prompts are launch-ready.
+
 ## Current state
 
 The prompt stack has meaningful launch hardening in place: the generated core prompts are TOON-oriented, planner outputs are schema-validated, malformed planner outputs have repair paths, and bounded prompt-optimization tests pass locally. The main runtime path also has several guardrails for action/provider name repair, missing parameter repair, metadata-action rescue, and prevention of speculative tool calls.