From e2045ea65a771e29db57225761286d93e4b8f625 Mon Sep 17 00:00:00 2001 From: Tomoki Kobayashi Date: Fri, 21 Aug 2026 21:54:50 +0900 Subject: [PATCH 1/2] Write down that the site is being held, and what ends it --- .claude/skills/release/SKILL.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/.claude/skills/release/SKILL.md b/.claude/skills/release/SKILL.md index e4d9fdb..ef11c3b 100644 --- a/.claude/skills/release/SKILL.md +++ b/.claude/skills/release/SKILL.md @@ -32,6 +32,36 @@ are deployed by hand (Actions tab, or `gh workflow run pages.yml`) once the release is out. Do not add a `push:` trigger back for convenience: that is the timing this replaced. And `cancel-in-progress: false`, because a deploy interrupted midway can leave the live site as a half-written artifact. + +**Right now the live site is deployed from `site/1.0.0`, not from main** +(2026-08-26). The trigger above was added *after* a push-triggered deploy on +2026-08-11 had already put 1.1.0's page live โ€” ๐ŸŒณ blocks you make yourself, +Apple Vision Pro, privacy ยง6 โ€” while 1.1.0 was unreleased and iOS 1.0.0 was +still in review. That branch is main with `site/` rolled back, and it is +disposable. + +**The policy page is the exception, and it is the shape to reuse.** ยง6 is what +tells App Review why the app asks to sense the room, so it had to be live +before the visionOS build was submitted โ€” and deploying main to get it would +have taken the landing page along, selling a version still in review. So +`privacy.html` alone was carried across from main onto the branch and deployed +from there. A policy describing a version that has not shipped is a policy +written ahead of time; a landing page selling one is an advertisement for +something nobody can buy. + +**What ends the hold is 1.1.0 actually being on the store** โ€” not approved, not +submitted, live. Then `gh workflow run pages.yml --ref main`, and delete the +branch and its policy; the policy's id is in the environment listing, and +removing it is what stops a future deploy from having a second ref to choose +from. Two traps sit around this. Deploying from the `v1.0.0` +tag is *not* the same as deploying 1.0.0's site โ€” the tag was cut before the +app was on the store, so its page says "Coming soon" and points the badge at +GitHub; the branch re-applies the badge and the OG card on top of the tag's +`site/`. And a ref outside the `github-pages` environment's list fails in two +seconds with `not allowed to deploy to github-pages due to environment +protection rules`, which names the ref and nothing else: the list holds +`main`, `gh-pages` and `site/1.0.0`, tags are not in it, and it is edited +through `repos/{owner}/{repo}/environments/github-pages/deployment-branch-policies`. The policy page states what was *measured* โ€” no accounts, no analytics, no advertising or third-party SDK, no tracking, and no networking code anywhere in the app or in TortoiseGraphics2 โ€” which is also why no From 85cdcb072b5bf19e3039f33cb4efd03ee6adff1d Mon Sep 17 00:00:00 2001 From: Tomoki Kobayashi Date: Wed, 26 Aug 2026 09:13:13 +0900 Subject: [PATCH 2/2] Say that the note goes with the branch --- .claude/skills/release/SKILL.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.claude/skills/release/SKILL.md b/.claude/skills/release/SKILL.md index ef11c3b..05faa99 100644 --- a/.claude/skills/release/SKILL.md +++ b/.claude/skills/release/SKILL.md @@ -51,7 +51,9 @@ something nobody can buy. **What ends the hold is 1.1.0 actually being on the store** โ€” not approved, not submitted, live. Then `gh workflow run pages.yml --ref main`, and delete the -branch and its policy; the policy's id is in the environment listing, and +branch, its policy **and these three paragraphs** โ€” a note saying the site is +held, left standing after it is not, sends the next reader looking for a branch +that no longer exists. The policy's id is in the environment listing, and removing it is what stops a future deploy from having a second ref to choose from. Two traps sit around this. Deploying from the `v1.0.0` tag is *not* the same as deploying 1.0.0's site โ€” the tag was cut before the