janpeter/Scrum4Me
0
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(hub): TestFlight-voorwaarden in de M34-e2e-gate #162

Merged
janpeter merged 1 commit from docs/testflight-gate-notes into main 2026-08-14 14:00:41 +02:00
Conversation 1 Commits 1 Files changed 1 +21
janpeter commented 2026-08-14 13:59:17 +02:00
Owner
Copy link

Docs-only. Twee TestFlight-specifieke voorwaarden die de M34-gate nog niet noemde en die pas mét de telefoon in de hand opvallen.

Je moet opnieuw pairen. POST /api/hub/devices/pair doet hubDevice.create, geen upsert — elke installatie is een nieuw apparaat en vraagt een verse, eenmalige pairing-code. Een TestFlight-build erft de bestaande koppeling dus niet. De oude rij blijft daarnaast actief, dus mislukte pushes daarop zijn verwacht gedrag en geen gate-bevinding; zonder die zin kost dat middenin de gate een verkeerde diagnose.

De APNs-omgeving kantelt. AppDelegate.swift meldt sandbox in DEBUG en production in Release, en de deliverer kiest daarop zijn host (api.sandbox.push.apple.com ↔ api.push.apple.com). Een TestFlight-build loopt dus over een ander APNs-pad dan alles wat tot nu toe getest is. Staat er sandbox op de nieuwe device-rij, dan is er met een DEBUG-build gepaird en faalt alles met BadDeviceToken.

Aanleiding: de rollout van vandaag. De gate-runbook noemde TestFlight alleen in de frontmatter en verder nergens, terwijl de eerste echte gate-run juist op een TestFlight-build gaat draaien.

npm run docs groen (170 bestanden, alle links geldig). Geen code geraakt.

Docs-only. Twee TestFlight-specifieke voorwaarden die de M34-gate nog niet noemde en die pas mét de telefoon in de hand opvallen. **Je moet opnieuw pairen.** `POST /api/hub/devices/pair` doet `hubDevice.create`, geen upsert — elke installatie is een nieuw apparaat en vraagt een verse, eenmalige pairing-code. Een TestFlight-build erft de bestaande koppeling dus niet. De oude rij blijft daarnaast actief, dus mislukte pushes daarop zijn verwacht gedrag en geen gate-bevinding; zonder die zin kost dat middenin de gate een verkeerde diagnose. **De APNs-omgeving kantelt.** `AppDelegate.swift` meldt `sandbox` in DEBUG en `production` in Release, en de deliverer kiest daarop zijn host (`api.sandbox.push.apple.com` ↔ `api.push.apple.com`). Een TestFlight-build loopt dus over een ander APNs-pad dan alles wat tot nu toe getest is. Staat er `sandbox` op de nieuwe device-rij, dan is er met een DEBUG-build gepaird en faalt alles met `BadDeviceToken`. Aanleiding: de rollout van vandaag. De gate-runbook noemde TestFlight alleen in de frontmatter en verder nergens, terwijl de eerste echte gate-run juist op een TestFlight-build gaat draaien. `npm run docs` groen (170 bestanden, alle links geldig). Geen code geraakt.
docs(hub): TestFlight-specifieke voorwaarden in de M34-gate
All checks were successful
CI / Lint, Typecheck, Test & Build (pull_request) Successful in 4m35s
Details
CI / Deploy Manual (workflow_dispatch) (pull_request) Has been skipped
Details
CI / Detect deploy-relevant changes (pull_request) Has been skipped
Details
CI / Deploy Preview (PR) (pull_request) Has been skipped
Details
CI / Deploy Production (main) (pull_request) Has been skipped
Details
3d2343ec1a 
Twee dingen die bij een ⌘R-installatie niet spelen en pas mét de telefoon in de
hand opvallen, dus horen ze vooraf in het draaiboek.

De pair-route doet `hubDevice.create`, geen upsert: een TestFlight-build erft de
bestaande koppeling niet en vraagt een verse pairing-code. De oude rij blijft
naast de nieuwe actief, dus mislukte pushes daarop zijn verwacht gedrag en geen
gate-bevinding — anders kost dat middenin de gate een verkeerde diagnose.

En de APNs-omgeving kantelt: DEBUG meldt sandbox, Release meldt production, en
de deliverer kiest daarop zijn host. Een TestFlight-build loopt dus over een
ander APNs-pad dan alles wat tot dan toe getest is; staat er `sandbox` op de
nieuwe rij, dan is er met een DEBUG-build gepaird en faalt alles met
BadDeviceToken.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
s4m-codex-reviewer approved these changes 2026-08-14 14:01:03 +02:00
s4m-codex-reviewer left a comment
Copy link

Verdict: APPROVED

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

Geen findings. De wijziging is documentatie-only en de toegevoegde TestFlight-opmerkingen zijn consistent met het bestaande APNs-contract: device-environment bepaalt de APNs-host (sandbox versus production) en de e2e-gate vereist expliciet een TestFlight-build op het toestel.

# Verdict: APPROVED Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings Geen findings. De wijziging is documentatie-only en de toegevoegde TestFlight-opmerkingen zijn consistent met het bestaande APNs-contract: device-`environment` bepaalt de APNs-host (`sandbox` versus `production`) en de e2e-gate vereist expliciet een TestFlight-build op het toestel.
Sign in to join this conversation.
Reviewers
No reviewers
s4m-codex-reviewer
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/Scrum4Me!162
No description provided.