Hi Anna team,
Posting at the review team’s request. On September 23, they reported retesting World Director (Local) using review candidate 0.4.10, but Installed Apps still displayed 0.3.3 after installation, and the previous Executa-not-deployed error persisted. Uninstalling both the App and its corresponding Executa, then reinstalling from scratch, did not resolve it.
On our own account, the developer install endpoint also returned installed_version: "0.3.3". Could the core team trace version selection across the review candidate, account installation, frozen Executa dependency, and Agent deployment?
Intended versions
| Item | Value |
|---|---|
| App | World Director (Local), ID 82, slug anna-truman-director-local |
| Review candidate | 0.4.10, AppVersion 840 |
| Frozen Executa dependency | 0.4.9, ExecutaVersion 512 |
| Tool | tool-qingyu_ge-anna-truman-director-sxah66uc, Executa ID 1013 |
| Our test environment | CLI 0.1.53, Cloud Agent 1.1.0-beta.39 |
The App and engine have separate version numbers: 0.4.10 → 0.4.9 is intentional.
Our post-submission readback at September 21, 02:06 UTC was:
{
"app_id": 82,
"status": "pending_review",
"review_candidate_version": "0.4.10",
"latest_version": "0.3.3"
}
The cut response confirms AppVersion 840 freezes ExecutaVersion 512, with the bundle ready. We verified all four platform artifacts and hashes in the frozen Executa 0.4.9 snapshot. The App has not been released to the Marketplace.
Developer-side reproduction
- Publish/freeze Executa 0.4.9 with four directly uploaded platform binaries.
- Explicitly set the App dependency to 0.4.9, push, and cut App 0.4.10. Verify the frozen mapping 840 → 512.
- Call the developer self-install endpoint:
POST /api/v1/developer/apps/82/install. - Observe installed version 0.3.3, rather than the new cut 0.4.10.
- Subsequently submit for review and confirm candidate 0.4.10. On September 23, the review team’s independent retest still reports 0.3.3 displayed after installation.
We do not have the review team’s actual installation response, resolved ExecutaVersion, or Agent deployment logs. Their displayed version therefore does not by itself prove which binary ran, or that their failure has the same cause as our historical draft binding below.
What we have isolated
Earlier explicit reinstall attempts on our own account returned:
{
"resolved_from": "frozen_snapshot",
"resolved_version": "0.1.1",
"executa_version_id": 119,
"pinned_by_app": "anna-truman-director-local@0.0.0-draft"
}
That snapshot attempted to download an old v0.3.0 Linux asset and failed with 404. Creating a new cut did not automatically replace the existing draft pin.
After backing up our data, temporarily removing only our account’s App installation relation allowed the tool to deploy and load as 0.4.9 on our Cloud Agent. After restoring the working draft, two real-model ticks, APS persistence, and recovery after reload passed. We did not delete historical App versions or the Cloud Agent.
This establishes that the new engine can run in our Cloud environment. It is not a clean-install validation of candidate 840 or a production workaround for users.
Questions for the core team
- Should reviewer installation select AppVersion 840 directly from the review candidate? Could a path still be selecting the old
latest_version: 0.3.3? - Can you check the actual installed AppVersion, resolved ExecutaVersion, and loaded Agent version for this review attempt, distinguishing a display issue from installation binding or deployment failure?
- What is the supported developer flow to install a specific unpublished immutable cut? Is there a data-preserving repair for historical installation/draft pins?
- Could installation responses expose both resolved versions and deployment outcomes, so account installation success cannot be mistaken for a successful Agent deployment?
Related reports
- #284: another developer submitted 0.1.2 but repeatedly installed 0.1.1. The official reply acknowledged inconsistent “latest” resolution and tracked it separately from the storage bug that was fixed.
- #326 /3: after explicit reinstalls reported success, another developer still saw errors apparently produced by old code. No later official response was present when checked on September 23.
- Our earlier #280: historical frozen dependency resolution. The new evidence here is that a fresh cut exists, the review candidate is explicitly submitted, and the reviewers still report the old installed version.
These reports show similar symptoms, not a confirmed shared root cause. We can provide redacted install/cut/deploy responses or run targeted diagnostics.
Installation could resolve the App version from a stale “latest” marker instead of the submitted review candidate — so even with candidate 0.4.10 correctly pinned, installs (both reviewer-side and your developer self-install) could land on 0.3.3. Your frozen mapping (AppVersion 840 → Executa 0.4.9) was always correct; it was the version selection during install that picked the wrong row.
Platform v1.1.0-beta.181 — App installation and the review flow now always resolve the pinned review candidate first. Reviewer installs and developer self-installs of App 82 will get 0.4.10 with frozen Executa 0.4.9, as intended.
Cloud Agent v1.1.0-beta.41 — if a tool fails to load after deployment, the install now reports an explicit failure instead of a silent success, so account-level “installed” can no longer mask an Agent-side deployment problem.
