[PolarisCzh]

Problem and behavior

A new Studio MPA can still use an old veFaaS internal image when its source is :latest. Keep latest as the configured input, but resolve it to an already-published tag with exactly the same manifest digest before creating the Worker and Runtime. Discovery is anonymous and read-only: no cloud credentials, CR management API, registry writes, image copies, or new pipeline.

Read bounded tag pages using repository-scoped anonymous pull tokens; prefer an existing digest-named tag, otherwise verify non-latest tags in deterministic order. Persist both selected references under the existing deployment lock. Retries verify the saved tags without resolving latest again, including selections from the earlier implementation. No match or changed content fails explicitly. Fixed tags, existing MPAs, and standalone CLI behavior are unchanged.

Requests validate manifest bytes/digests and trusted provider hosts, reject unsafe authentication/pagination redirects and cycles, and enforce response, enumeration, and time budgets. No new dependencies or public request fields. English/Chinese designs and maintained contracts are included; the original registry-writing design is marked superseded.

Validation

• 1266 managed/CLI regression tests passed; 93 focused discovery/integration tests passed.
• Resolver line/branch coverage 100%; added executable production lines 173/173 covered.
• Frontend 118 passed, production build passed; changed-file Pyright and all-files pre-commit (Ruff/format/secret scanning) passed.
• The actual production resolver anonymously selected matching tags and revalidated saved selections in all four BP/domestic public Agent/Worker repositories. Cloud credential access was replaced by a function that raises; it was never invoked. No registry writes were performed.
• Deployed the tested source to BP Studio function cst7puxr, stable revision 12. Deployed resolver/service hashes match local source; all existing environment values and scheduler settings were retained.
• Created studio-readonly-1021-a through Studio. Runtime r-yexqmg6z9cy9bkt9hm42 is Ready version 2, health/readiness HTTP 200; the native record is ready and retains both selected image references across same-request retries.
• Real Worker function ptlrrzjl, revision 1, uses image ID ayk6eadc2t rather than old vollyz6n0i. Its 215-file source fingerprint matches the published new Worker; the dedicated source-probe session was deleted.
• A fresh Studio session executed printf STUDIO_READONLY_1021_FRESH_OK, returned the expected stdout and exit 0 in the completed UI answer.

Observed functional limitation

The initial explicit Worker-dispatch smoke failed with inactive_worker_dispatch and harness invocation plan update was not persisted; the command was not executed even though harness/control state reported completed. The separate fresh-session stop-on-error smoke passed. The initial failure is preserved in the bilingual delivery record; its root cause remains unproven, and Agent MainRuntime grant/plan code was not modified. This PR does not claim all initial-session or explicit dispatch paths pass E2E.

Creation also encountered the existing OV account collection cap of 20, surfaced as InvalidParameter. After the user explicitly approved deleting one previously created test library, the same creation request succeeded while reusing its Worker and both image selections. No quota/model/OV code workaround was added.

Limits

Each latest publication must retain a matching version tag and never overwrite it; tag names alone do not enforce immutability. No-match/private-inaccessible repositories fail rather than falling back to latest. Discovery is bounded to 20 pages / 1000 tag entries with a checked 120-second per-image budget and bounded network timeouts. Full A2A, Codex/Pi/Harness suites, domestic deployment, calendar authorization, and human IM are outside this verification. The earlier independent Studio completion exception and platform cache internals are not changed.

CI repair and fork validation (2026-10-22)

The shared frontend job exceeded its 3-minute timeout during npm dependency installation, making both aggregate gates fail. It now uses the existing release verifier's public npm registry and host-replacement settings, with a bounded 10-minute timeout. Coverage and failure aggregation are unchanged. PR validation now runs in forks; publishing and notifications still require manual dispatch on upstream main.

The complete PR change was first validated against upstream main 5e5deb6 in fork PR #1, head 7ee50a7. All seven workflows and 14 validation jobs succeeded: Python 3.10 (7633 passed, 46 skipped, 4 xfailed), Python 3.12 (7636 passed, 43 skipped, 4 xfailed), Codex smoke, backend/frontend/aggregate gates, license, secret scan, dependency policy, pre-commit, full Studio bundle, simulated customer update and installed-runtime smoke. Release allocation, publishing and notifications were skipped. Shared frontend jobs completed in 66s and 58s. Local focused Python tests: 272 passed; Ruff, Pyright, all-files pre-commit, frontend coverage/tests and production build also passed.

The upstream branch contains the same verified workflow and source changes plus a documentation-only evidence update. Upstream CI approval/results are independent. This CI-only repair does not resolve the separately documented initial MainRuntime inactive_worker_dispatch failure, and no application was redeployed for this repair.