[jaywedgeworth22]

This does not touch CC-199 or CC-200, which stay with BF-Builder, and it is not C-102.

Summary

Makes the iOS version-manifest publish after a successful TestFlight upload explain its result and write through a pull request (CC-202).

The remote manifest site/ios-versions.json in Simple-With-Us/ai-fleet-coordinator can no longer be updated by a direct write to main — main requires a PR and the ship job's GITHUB_TOKEN is contents:read. The publisher now uses a dedicated credential to open/reuse a branch and PR instead of failing silently with a swallowed 403.

What changed

• Remote publish via branch + PR — scripts/ios-fleet/publish-ios-versions.sh:

  • Reads the live manifest, merges this app's marketingVersion / build / appleId / displayName row into it so other apps' rows are preserved.
  • No-ops with remote-manifest-already-current when the row is already current.
  • Creates or reuses a stable branch ios-versions/<bundle>-<version> off main, writes the merged file to that branch, then opens or reuses a PR chore: <bundle> <version>.
  • Best-effort arms PR auto-merge; a refusal is reported but does not fail the publish.
  • Skips out loud with remote-manifest-publish-skipped when IOS_VERSIONS_PUBLISH_TOKEN is missing, explaining the ship token cannot write the other repo. All failures report as remote-manifest-publish-failed with HTTP status and API message. Secrets are never printed.
  • Still updates the local ios-app-versions.json record.

• Ship logging stays non-fatal but visible — scripts/ios-fleet/ship-testflight.sh:

  • Captures the publisher output and logs each line as version-manifest: ....
  • Success logs published <bundle> <version>; failure logs warning: version-manifest publish failed (non-fatal, rc=...) without failing the already-succeeded TestFlight upload.

• Credential wiring — .github/workflows/ios-ship.yml:

  • Provides IOS_VERSIONS_PUBLISH_TOKEN: ${{ secrets.GH_PAT }} scoped to the TestFlight ship step only. Job permissions remain contents:read.

Testing

• Added scripts/ios-fleet/test-publish-ios-versions.sh with a stubbed GitHub API covering: PR creation on a non-main branch, preservation of other apps, refused write surfacing HTTP 403/message with non-zero exit, and missing-credential messaging.
• Wired the new test into .github/workflows/ios-ship-contract.yml and scripts/ios-ship-workflow.test.mjs contract checks for cause-naming, PR flow, read-only permissions, and secret handling.

---

Summary

Prevents placeholder versions from reaching the public iOS version manifest and makes manifest publish failures explicitly named.

What changed

• Upload-only TestFlight ships no longer publish a manifest entry: when the version is unresolved ((from IPA) placeholder for marketing/build number), record_successful_ship now only records ship-gate state and skips the version-manifest publisher, so the IPA-carried version is not overwritten with a placeholder.
• Named manifest publish failures: invalid --apple-id, unreachable manifest API, and unreadable live manifest content now fail with a remote-manifest-publish-failed: reason instead of a bare error/traceback. Non-numeric --apple-id is rejected early with validation.
• More robust remote manifest read: replaced platform-specific base64 -d decoding with portable Python decoding and hardened API request handling so curl/network failures surface as a named reachability error.
• Doc naming: updated TestFlight release-notes comment from AGENT-SYNC to FLEET-PROTOCOL.

Verification

• Extended test-publish-ios-versions.sh to assert non-numeric --apple-id exits non-zero with the named error and no traceback.
• Extended ios-ship-workflow.test.mjs to assert the (from IPA) placeholder guard runs before the manifest publisher call.
• Automated code review found no issues.

[linear-code]

CC-202

[github-actions]

Autofix run https://github.com/Simple-With-Us/CodeCaps/actions/runs/40272582547 started for `sentry[bot]`'s tagged request. Owner/sentry request: exempt from the per-bot cap (owner rule 2026-10-20).

[kody-ai]

Task description is insufficient for business logic validation.

🤔 Insufficient Task Context

I found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details.

🔍 What I need to validate:

• Business requirements and acceptance criteria
• Expected behavior and business rules
• Edge cases and constraints to consider

💡 How to improve the task context:

• Add a description to the linked ticket
• Include acceptance criteria or business rules
• Describe the expected behavior after the change

⚠️ Important:

A task title alone is not sufficient to determine whether the implementation is correct or complete.

---

💡 This validation runs automatically only on the first review of a pull request. To run it again, comment @kody -v business-logic.

Prompt for LLM

Task description is insufficient for business logic validation.

<!-- task_context_status:weak -->
## 🤔 Insufficient Task Context

I found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details.

### 🔍 What I need to validate:
- Business requirements and acceptance criteria
- Expected behavior and business rules
- Edge cases and constraints to consider

### 💡 How to improve the task context:
- Add a description to the linked ticket
- Include acceptance criteria or business rules
- Describe the expected behavior after the change

### ⚠️ Important:
A task title alone is not sufficient to determine whether the implementation is correct or complete.

---
> 💡 This validation runs automatically only on the first review of a pull request. To run it again, comment `@kody -v business-logic`.

​

[swu-wise]

@kody start-review

[kody-ai]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

⚠️ 2 Kody Rule(s) were not evaluated

These rules declare that they need repository context beyond this diff, and the review could not retrieve it, so they were not judged on this pull request:

• Never move or delete existing app support.html URLs
• Never log tokens or credentials; only safeIssues may reach the handoff file

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​