They blocked and delayed my testing and successful production release.
Anna platform-side blocking issues
apps release status check bug
Cause: The CLI sees the app status as lowercase published, but the release guard seems to check against uppercase PUBLISHED / APPROVED.
Where it happened: Running apps release 0.1.59 and apps release 0.1.60 failed.
Impact: Blocks the normal release flow.
Suggested fix: Unify the Anna CLI / API status enum casing. published should be accepted for release.
Installed grant does not auto-update after release
Cause: apps release only updates the latest version, but does not automatically upgrade the current developer/user installed version to latest.
Where it happened: apps grants still showed the old installed_version, with update_available: true.
Impact: The Dashboard keeps loading the old version, making online testing look like the fix did not work.
Suggested fix: Provide a clear apps update / apps install latest command, or automatically prompt/trigger installation update after release.
Dashboard iframe runtime/RPC returns 400 but the error body is not visible
Cause: DevTools only shows api/v1/anna-apps/run... 400, without clearly exposing which RPC namespace/method/body was rejected.
Where it happened: Dashboard Console.
Impact: Makes debugging difficult and forces developers to reproduce runtime APIs one by one.
Suggested fix: In developer mode, the Dashboard runtime dispatcher should show safely redacted RPC method, error code, and message.
Dashboard iframe sandbox warning
Cause: The iframe uses both allow-scripts and allow-same-origin.
Where it happened: Chrome DevTools warning.
Impact: Not the direct cause of failure, but it affects security review and developer confidence.
Suggested fix: Anna Dashboard should evaluate splitting sandbox permissions, or document the security boundaries of this combination in the developer docs.
Anna App SDK / Dashboard runtime is too sensitive to startup-time calls
Cause: Extra chat.write_message or diagnostic calls during startup can cause 400 noise in the Dashboard.
Where it happened: App initialization flow after AnnaAppRuntime.connect().
Impact: Blocks Dashboard test judgment and makes it easy to misinterpret the problem as a tool-call failure.
Suggested fix: The platform SDK should provide a clear allowlist and error explanation for startup-time host calls. The Dashboard should not show bare 400s for non-critical failures.
Accessing the app bundle directly from an unauthenticated browser redirects to sign-in
Cause: Anna app asset/runtime URLs are protected by platform authentication.
Where it happened: Opening the online app URL directly with unauthenticated Playwright redirects to Sign In.
Impact: Automated end-to-end UI testing cannot easily verify the online iframe directly.
Suggested fix: Provide a developer smoke/test token, or a read-only preview URL for CI verification.
Anna App internal issues
Root-path assets caused 404s: /app.js, /style.css, /anna-tool-ids.js.
The iframe <base> was not fixed to https://anna.partners/.
The proxy did not consistently rewrite src / href.
<base> affected local fallback API fetches.
The production bundle included ANNA DIAGNOSTIC logs.
Startup automatically wrote a preflight chat message, increasing the risk of runtime 400s.
The executa binary URL and app version need to be kept in sync
The Anna platform-side release guard, installed grant update mechanism, insufficient observability for Dashboard runtime 400 errors, and authentication restrictions for online iframe testing have directly blocked the testing loop and successful release verification.
I am trying to work around these issues from the App side and use platform APIs as a fallback to complete the deployment, but these problems need to be fixed at the Anna platform layer before future App release workflows can become stable and repeatable.
