task: transfer cryptify's 9 open issues into postguard, then archive

[rubenhensen]

Question

Transfer encryption4all/cryptify's nine open issues into postguard, then archive the repo.

Checklist

1. Transfer all nine open issues as-is, no triage (gh issue transfer, repo is not archived yet so this is a plain transfer, not decide where the archived apps' 62 stranded open issues live #282's unarchive-dance):
   • #116 (umbrella) — upload session state is not persisted
   • #136 — upload and download sessions are not robust
   • #197 — persist upload-session state to SQLite
   • #198 — restore sessions on boot
   • #188 — per-recipient email delivery status / bounce detection
   • #101 — Grafana dashboards for usage stats on Scaleway
   • #47 — optional attributes don't show in email
   • #32 — allow external storage from the host
   • #4 — perform encryption in a Web/Service Worker
2. Apply the existing repo:cryptify label to each transferred issue (no new label needed — it's already in postguard's repo:<name> convention).
3. Re-wire the dependency structure, which does not survive a transfer automatically: #197 blocks #198 and #116; #198 blocks #116; #116 (sub-issues #197+#198) blocks #136.
4. Repoint this map's (#247) four sub-issue links from the old cryptify#116/#136/#197/#198 URLs to their new postguard numbers — the old URLs redirect, but the sub-issue relationship needs to point at the new numbers directly.
5. Close PR fix(pg-pkg): propagate IO errors when reading key files #161 ("chore: release v0.1.28") as superseded — 0.1.28 already shipped through the workspace path (18e0ab0/fix(cryptify): release the stranded security fixes as 0.1.28 #279).
6. Add a "development moved to postguard, crate is cryptify/" banner to encryption4all/cryptify's README, matching the pattern already on postguard-outlook-addon's.
7. Archive encryption4all/cryptify — blocked on the publish-pipeline cutover (task: cut cryptify's Docker publish pipeline over to postguard, task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build #293). Do steps 1–6 immediately; hold this step until task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build #293 closes.

Why this exists

Surfaced by #286 (part of #247). Applies #282's "consolidate into wherever the code now lives" rule to cryptify: the crate moved into postguard, not postguard-js, so that's the destination. All nine open issues move (no triage), same reasoning #282 used — triaging during migration is how the four app repos ended up stranded.

[rubenhensen]

Steps 1–6 done; step 7 (archive) still waits on #293.

1. Transferred all 9 open issues from cryptify into postguard:
   • #116 → #300 (umbrella)
   • #136 → #301
   • #197 → #302
   • #198 → #303
   • #188 → #304
   • #101 → #305
   • #47 → #306
   • #32 → #307
   • #4 → #308
2. Labelled all nine repo:cryptify.
3. Dependency edges (blocks/blocked by) survived the transfer automatically — #302 still blocks #303+#300, #303 still blocks #300, #300 still blocks #301. No manual re-wiring needed, contrary to the ticket's expectation.
4. Sub-issue (parent/child) links partially auto-repointed, partially didn't — worth knowing for the next transfer of a non-leaf issue:
   • The map's (Wayfinder: fleet remediation — enforce the seams, kill silent failure (2026-07 audit) #247) direct links to #116→#300 and #136→#301 auto-repointed correctly (same mechanic #288/#289/#290 found), but only after a short propagation delay — the first check right after transfer showed #300's parent as null, a re-check ~a minute later showed #247 correctly. Don't conclude "didn't survive" from an immediate check.
   • #300's own sub-issue links to #302/#303 (formerly #116→#197/#198) did not survive and needed manual re-attachment via POST /repos/{owner}/{repo}/issues/{number}/sub_issues (REST sub_issue_id wants the issue's numeric database id, not its number or GraphQL node id — gh api ... -f sends it as a string and 422s; use -F or fetch the id and interpolate an unquoted value). So: a transferred issue's link to its own parent survives, but its link to its own children does not — re-check and re-attach both directions after any transfer of a non-leaf issue.
5. Closed cryptify PR fix(pg-pkg): propagate IO errors when reading key files #161 ("chore: release v0.1.28") as superseded — 0.1.28 already shipped through the workspace path (18e0ab0/fix(cryptify): release the stranded security fixes as 0.1.28 #279).
6. README banner added on cryptify main (encryption4all/cryptify@7350d3b, via branch + PR Headless YiviDriver: issue + disclose via irmago irmaclient #204 + gh pr merge --admin — cryptify's branch protection requires 1 review but has enforce_admins: false, same shape as postguard-tb-addon in task: transfer postguard-tb-addon's 17 open issues into postguard-js, then re-archive #290). Deliberately did not claim "no longer publishes container images" the way the outlook-addon banner does — cryptify's ci.yml is still the only working publisher until task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build #293 lands, and the banner says so.

Step 7 (archive) intentionally not done — still blocked on #293 (GHCR Write grant, org-admin only). Leaving this ticket open until that lands and the archive step can run.

[rubenhensen]

Step 7 done: encryption4all/cryptify is archived. All seven checklist steps are complete, so the repo-consolidation family that started at #286 is finished.

What step 7 actually cost

The archive itself is one API call. What it needed first was the half #293 deliberately left open — and that half was not inert.

cryptify's release-plz was still live, and it out-ran the cleanup. Step 5 closed the superseded chore: release v0.1.28 PR (cryptify#161) at 12:46 on 2026-08-07; release-plz-pr re-opened the identical PR as cryptify#205 at 12:47. Archiving on top of that would have stranded an open PR read-only — the exact failure class #282 exists to prevent, arriving through a door that ticket never looked at. Closing it wasn't enough either: any later push to main re-creates it. So the fix had to be to retire the jobs.

The README banner had gone false. It still read "this repository's CI is still the only publisher of ghcr.io/encryption4all/cryptify — do not remove its build/push steps yet". True when step 6 wrote it, false the moment #293 landed, and unfixable once the repo is read-only.

Both went into cryptify#207 (squash-merged 13b4cc2e, all three checks green). The post-merge run on main ran quality alone — no release-plz job, no re-opened PR — which is the confirmation that the retirement stuck. Then cryptify#205 was closed as superseded, and the repo was archived with 0 open issues and 0 open PRs.

The one thing that needed measuring

Archiving the source repo of a GHCR package could plausibly have revoked the Write grant #293 obtained for postguard — package permissions are normally inherited from the linked repo. I could not read the package API to check (read:packages absent from the token), so the check had to be empirical.

build-cryptify carries no if: and pushes unconditionally, on pull_request too, so #311's own run was the measurement: ghcr.io/encryption4all/cryptify:pr-311 pushed at 12:28 UTC, two minutes after the archive. So archiving a package's source repo does not revoke another repo's Write grant on it. Recorded in root CLAUDE.md.

Verified end state

encryption4all/cryptify	archived: true, public, 0 open issues, 0 open PRs
Old issue URLs	redirect — cryptify/issues/116 → #300, and the redirect survives archiving
The 9 transferred issues	#300–#308, all open, all repo:cryptify
Dependency edges	#302 blocks #303+#300; #303 blocks #300; #300 blocks #301 — survived the transfer
Image publisher	postguard's delivery.yml, sole — cryptify's build/push jobs retired in cryptify#206, its release-plz jobs in cryptify#207
Versioning	postguard's workspace release-plz, tags cryptify-v*; last tag cut in the old repo was v0.1.27

For the next repo archived

#282's rule was "transfer the open issues first, then archive". This ticket adds the rest of it, now in root CLAUDE.md:

Open PRs strand exactly the same way open issues do, and release automation manufactures them faster than you can close them. Closing is not enough — retire whatever re-creates them, in the same commit that finalizes the README banner, or the merge of that very commit re-opens one. Order that works: retire release automation + finalize banner in one PR → close the open PRs → transfer the issues → archive.

Also worth carrying: the banner is the last writable version of the README, so it has to be true at archive time rather than at the time it was written.

Closes #294. Landed in cryptify#207 and #311 (c1682ba).