← back to dashboard

SumRaceKids — fleet issue

_Re-verified against live state: 2026-08-04. No app code was changed for this issue._

Status (one line): Not actually broken — build 3 archived and exported cleanly and is parked at the fleet's *intentional* manual publish gate (in_flight: pending_review, last_upload_status: held_for_review); the auto-healer correctly declined to act (Not auto-healing (fixable=false, autoHeal=true)) because there is no defect to repair, so this needs a human publish decision, not a code fix.

Root cause & evidence

The 2026-07-30 pipeline run bumped the build to 3, archived, and exported with zero errors, then stopped *by design* at the human publish gate instead of uploading to App Store Connect.

The blocking log line — final lines (328–331) of the 331-line log /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/runs/SumRaceKids-2026-07-30T20-54-24Z.log; the run never got further:

[04:54:56] BUILD READY — held for your review (build 3)
[04:54:56] IPA: /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apps/SumRaceKids/build/Export/SumRaceKids.ipa
[04:54:56] to publish to ASC after review:  fleet publish SumRaceKids
[04:55:01] done (awaiting publish approval)

Success markers are both present: ARCHIVE SUCCEEDED (line 314) and EXPORT SUCCEEDED (line 326).
grep -cEi "error:|ARCHIVE FAILED|EXPORT FAILED" <log> → 0 (re-run 2026-08-04). There is no failure anywhere in the run.

This is policy, not malfunction. The app's own fleet config documents the gate explicitly — /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apps/SumRaceKids/.fleet/config.sh lines 6–8:

# Review gate: the driver runs BUILD_PHASE_CMD only; `fleet publish SumRaceKids`
# runs UPLOAD_PHASE_CMD (`make upload`) after human review. Do NOT list upload here.
BUILD_CMD="make archive && make export"

The same policy is restated in /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet-build.sh (lines 230–232):

# REVIEW GATE: hold the IPA, do NOT upload. ----------------------------------
# Per user policy (2026-05-29): no automatic ASC publish. The signed IPA is
# left in place; `fleet publish <APP_NAME>` runs the upload after review.

The healer reports fixable=false because nothing in the app source, signing, or build tooling is broken. /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet-doctor.workflow.js line 174 only auto-heals when diag.fixable is true:

if (!diag || !diag.fixable || !AUTO_HEAL) {
  return { app: appName, attempted: false, compiles: false, diff: '', summary: diag ? `Not auto-healing (fixable=${diag.fixable}, autoHeal=${AUTO_HEAL})` : 'No diagnosis', commands: [] }

So a pending-review hold can never be auto-healed, by design. The "failure" is an aging gate, not an error.

Fleet state (/Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/fleet.json → apps.SumRaceKids, re-read 2026-08-04 — unchanged):

"in_flight": "pending_review",
"updated": "2026-07-30T20:54:56Z",
"last_build_number": 3,
"last_build_status": "success",
"last_commit_built": "af075f9007dd3b9f49c9199232227f58138dbf5a1adb23093687b7bfabe60b41",
"pending_review_build": 3,
"pending_review_ipa": "/Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apps/SumRaceKids/build/Export/SumRaceKids.ipa",
"pending_review_since": "2026-07-30T20:54:56Z",
"last_upload_status": "held_for_review"

Supporting evidence:

Diagnosis: Not auto-healing (fixable=false, autoHeal=true)
Verify verdict: {"app":"SumRaceKids","isRealFix":false,"confidence":"high","reasoning":"No fix attempted","risks":""}

Note: the source has not changed since the previous hold — last_commit_built is still af075f90…, identical to the build-2 hold recorded 2026-06-17. SumRaceKids is not a git repo, so that value is a source-tree hash computed by fleet-build.sh (over all *.swift, *.plist, *.yml, Makefile; excluding ./build/* and ./.fleet/*; with CURRENT_PROJECT_VERSION stripped so the build bump does not self-trigger). Build 3 is a rebuild of unchanged code, not a fix.

Why no code edit was made

The root cause is an intentional gate, so any repo edit would be a symptom mask:

Claude-ready fix prompt

> SumRaceKids in the apple-apps fleet is flagged unhealthy. It is not broken — build 3 archived and exported successfully and is sitting at the deliberate manual publish gate. Do not edit any app source, project file, /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apps/SumRaceKids/.fleet/config.sh, or /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/asc.json to "fix" this. Resolve it as a publish decision:
>
> 1. Confirm the hold is genuine, not a masked failure. Read /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/runs/SumRaceKids-2026-07-30T20-54-24Z.log; verify it ends with BUILD READY — held for your review (build 3), contains both ARCHIVE SUCCEEDED and EXPORT SUCCEEDED , and has zero error: / ARCHIVE FAILED / EXPORT FAILED lines. Confirm /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apps/SumRaceKids/build/Export/SumRaceKids.ipa still exists. If any check fails, stop and re-diagnose instead of publishing.
> 2. Check whether the held build is still current. Recompute the source-tree hash the way /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet-build.sh does and compare to last_commit_built (af075f90…) in /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/fleet.json. If they match, the IPA is current and publishable as-is. If they differ, run fleet build SumRaceKids first and publish the fresh IPA.
> 3. Create the 1.0.1 version record in App Store Connect first — this is the real blocker. ASC (/Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/asc.json → apps.SumRaceKids) still shows version_string: "1.0.0" / READY_FOR_SALE, while the held binary is 1.0.1. fleet publish SumRaceKids alone will not reach the App Store: altool upload only gets the build into TestFlight processing. A 1.0.1 version record must exist under asc_id 6773766461 (bundle com.zhouzhengxi.sumgame) before build 3 can be attached and submitted for review. Create it in ASC (the create-new-ios-app skill covers the existing-app update path), then attach build 3 and submit.
> 4. Ask the user to approve the upload before running it. This gate exists precisely because ASC publishes are not automatic (policy dated 2026-05-29). Do not upload unprompted.
> 5. On approval, run /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet publish SumRaceKids (dispatches to fleet-build.sh … --publish). Watch the new run log under /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/runs/.
> 6. After a successful upload, verify apps.SumRaceKids in /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/fleet.json no longer has in_flight: "pending_review", and that latest_build_number in /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/asc.json advances from 1 to 3 (run fleet refresh if the ASC snapshot is stale). Then delete this issue file.
>
> If the user decides build 3 should not ship, clear the gate instead of publishing: /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet-status.sh set SumRaceKids in_flight 'null' (and clear the pending_review_* keys) so the app stops reading as unhealthy, and record that decision here.

Two flags for the next actor

  1. fleet publish SumRaceKids alone likely will not reach the App Store. See step 3 above — the ASC version record is 1.0.0 but the binary is 1.0.1, so a 1.0.1 version must be created under asc_id 6773766461 before build 3 can be attached and submitted.
  2. This is a fleet-wide publish backlog, not an app-specific bug. Builds 2 and 3 both stalled at this gate for SumRaceKids, and other apps sit in the same pending_review / held_for_review state — confirmed live in fleet.json on 2026-08-04: blind-bag-spells (build 13, since 2026-06-29), SynCal (build 11, since 2026-07-28), SumRaceKids (build 3, since 2026-07-30), plus sg-p1-open-house (build 8, 2026-07-31), kid-soothe (build 14), and some-singapore (build 15) with last_upload_status: held_for_review. Decide once whether the gate stays manual or these get batch-published.

Optional durable follow-up: if these stale-gate alerts are noisy, the fix belongs in fleet tooling, not the app — teach /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/bin/fleet-doctor.workflow.js to classify in_flight == "pending_review" as a distinct "awaiting human" state rather than "unhealthy", so it never enters the diagnose/heal path. Get user sign-off before changing fleet behavior.

Environment note: the user's shell profile aborts every non-interactive bash call with ERROR: GVM_ROOT not set. Please source $GVM_ROOT/scripts/gvm (reproduced again 2026-08-03), which made xcodegen falsely appear missing though it is installed at /opt/homebrew/bin/xcodegen (2.44.1). Work around with /bin/bash --noprofile --norc. The profile is worth fixing, as it will affect other fleet automation.

Last known-good build number

Build 1 — from /Users/zzxwill/Programming/go/src/zzxwill/apple-apps/apple-apps-fleet/state/asc.json → apps.SumRaceKids (snapshot generated_at: 2026-08-03T19:15:04Z):

"asc_name": "Sum Race Kids",
"bundle_id": "com.zhouzhengxi.sumgame",
"asc_id": "6773766461",
"latest_build_number": "1",
"latest_build_state": "VALID",
"latest_uploaded": "2026-05-27T07:23:02-07:00",
"build_count": 1,
"app_store_state": "READY_FOR_SALE",
"version_string": "1.0.0"

Build 1 (version 1.0.0) is live and READY_FOR_SALE — the shipping app is healthy. Builds 2 and 3 were both held at the review gate and never reached ASC, which is why ASC still shows build 1.