decide cryptify's repo and issue home now that the crate is in the workspace

[rubenhensen]

Question

The cryptify crate now lives in this workspace (#285, landed in ba380a1/#277), but encryption4all/cryptify is still an un-archived repo with live issues in it. Where do they live?

#285's deliverable named this as a consequence to follow through — "cryptify's issues need a home decision like the archived apps got" — and it is the one part that did not happen.

What is actually stranded

Four are children of this map, so the frontier walks straight into them:

• cryptify#116 (umbrella) — upload session state is not persisted
• cryptify#197 — persist upload-session state to SQLite
• cryptify#198 — restore sessions on boot
• cryptify#136 — upload and download sessions are not robust

Verified still untouched: cryptify/src/store.rs persists only the rolling-quota usage table; there is no upload-session table and no restore-on-boot. So this is live work whose code is now in this repo while its ticket is in another.

Why it is not simply #282 again

#282 covers three archived, read-only repos whose issues cannot be assigned, labelled, commented on or closed. cryptify's are none of those things — the repo still works. So the question is different in both directions:

• Whether to archive encryption4all/cryptify at all. The crate moved, but the repo still owns released artifacts and a git history that other things may reference (the image now publishes from here, per ci(cryptify): publish the cryptify image from this repo #280 — check what else points at the old repo before deciding).
• If it is archived, its issues become stranded by that act, which is a self-inflicted version of decide where the archived apps' 62 stranded open issues live #282's problem. Deciding to archive without first deciding where the issues go is how the three app repos got into their current state.
• If it stays, the map carries children in a repo whose code no longer lives there, and the drift-detector / CI story has to keep working across that split.

Deliverable

A decision on both halves — archive or keep, and where the open issues live — with the four map children re-homed or re-pointed accordingly, and their blocking edges preserved.

Blocked by #282 so the archived-apps decision sets the precedent rather than being contradicted by this one.

Surfaced by the map-tree reconciliation in #281. Part of #247.

[rubenhensen]

Resolution

Archive encryption4all/cryptify, once the publish pipeline cuts over — issues move to postguard, not postguard-js.

Unlike #282's three app repos, cryptify's code consolidated into postguard (a Rust workspace member), not postguard-js — so applying #282's own "consolidate into wherever the code now lives" logic points at postguard as the destination, not a copy of #282's answer.

The blocker #282 didn't have to deal with: encryption4all/cryptify's own ci.yml is still the only working production publisher of the Docker image — it builds and pushes ghcr.io/encryption4all/cryptify unconditionally on every push to main. postguard's side (#280) is built but gated if: vars.PUBLISH_CRYPTIFY_IMAGE == 'true', and that variable is unset — flipping it needs a manual GHCR package permission grant nobody has done yet (#280's PR body names this as its own deferred step 1, with "retire the cryptify repo's own build" as deferred step 4). Archiving disables a repo's Actions, so archiving today would kill the only live image pipeline with no fallback. The decision is made now; the archive action is gated behind the cutover.

Scope: all nine open issues, no triage — #116 (umbrella), #136, #197, #198 (the four map children) plus five not currently tracked by this map: #188, #101, #47, #32, #4. Same reasoning as #282: triaging during the migration is how the four app repos ended up stranded in the first place. Stale release-plz PR #161 ("chore: release v0.1.28") is not part of this — 0.1.28 already shipped through the new workspace path (18e0ab0/#279), so it just gets closed as superseded before archiving.

Mechanics: no new label needed — postguard already has repo:cryptify in its existing repo:<name> convention (repo:e2e, repo:website, repo:addons, repo:docs, repo:sdk), a closer fit than #282's invented area:<app> labels. Apply it to all nine transferred issues. cryptify's README gets a "development moved to postguard, crate is cryptify/" banner before archiving, matching the pattern #282 established (the outlook-addon repo already had one; the other three didn't).

Dependency structure to preserve on transfer (verified live): cryptify#197 blocks cryptify#198 and cryptify#116; cryptify#198 blocks cryptify#116; cryptify#116 (umbrella, sub-issues #197+#198) blocks cryptify#136. All four are direct children of this map (#247). Once transferred, each gets a new postguard issue number — re-wire both the sub-issue/blocking edges and this map's four sub-issue links to the new numbers before any of them can be worked again.

Execution split into two tickets, since they have different blockers and different owners:

• Task A — cut over the publish pipeline: grant postguard Write on the cryptify GHCR package, flip PUBLISH_CRYPTIFY_IMAGE=true, verify a real push-to-main build, retire cryptify's own build/push steps. ci(cryptify): publish the cryptify image from this repo #280's deferred steps 1–4, restated as a ticket. Needs an org-admin action no API token here can grant — HITL for a maintainer.
• Task B — transfer all nine issues (repo:cryptify label, no triage) + close PR fix(pg-pkg): propagate IO errors when reading key files #161 + add the README banner + re-wire the dependency structure above, then archive. The transfer itself doesn't need Task A first (the repo isn't archived yet, so it's a plain transfer, not decide where the archived apps' 62 stranded open issues live #282's unarchive-dance) — only the final archive step is gated on Task A, noted in Task B's body rather than as a native block, so the transfer work stays on the frontier now.

Generalizes #282's rule a step further: consolidating a repo means transfer-open-issues-then-archive regardless of which repo the code lands in, and when the old repo still runs live production infrastructure, that has to be cut over before the archive step — not just before someone works the old tickets.