reconcile the map tree with what actually landed (open-but-done, closed-but-not-done)

[rubenhensen]

Question

Which of this map's open children are already satisfied by work on main, and which of its closed children were closed by a stray commit keyword rather than by completed work?

The tree is known to be wrong in both directions, so nothing else on the map can be sequenced honestly until this is fixed.

Open, but apparently done.

• #249 (oasdiff gate) is open, yet .github/workflows/api-diff.yml exists, pg-pkg/tests/api_gate.rs is its executable spec, and 71e9f50 shipped it.
• #251 (bidirectional wire-compat gate) is open, yet pg-compat is in the tree and build.yml runs wire-compat-rust (1237573, 4e6e2c2, e642786).

Neither is necessarily fully done — #251 still wants branch protection, which only a maintainer can set, and #268 tracks known reader-list gaps. State the real remaining scope, or close it.

Closed, but possibly not done. postguard-js#139 documents that history-preserving imports carry closing keywords verbatim, and GitHub resolves them against the destination repo — this has already silently closed js#127/#128/#129 plus a live issue once, and they had to be reopened. Today js#128 (examples import) and js#129 (single envelope implementation) are closed again. Verify against the tree that examples/ and the shared envelope module actually exist and that per-app parsers are actually deleted, rather than trusting the issue state. #259 depends on the answer.

Also settle: is postguard-website#44 (integration tests) satisfied by the merged Playwright gate in website#329?

Deliverable

Every child of this map either confirmed genuinely open with its remaining scope written down, or closed with a pointer to the commit that satisfied it. Where something is half-done, say which half remains. Post the reconciliation as a comment here and update the affected issues.

[rubenhensen]

Reconciliation

Verdict: three children are open but done (one of them the biggest thing on the map), nothing is closed-but-not-done, and the closing-keyword hazard this ticket warned about fired again in this repo since the map was charted, taking a live issue with it.

Everything below was checked against origin/main (f1b2e14), not against issue state. Note that a local checkout is likely to be stale in a way that inverts one of these answers — see the method note at the bottom.

---

A. Open but done → closing three

#249 — oasdiff gate. Done, 71e9f50 (#269).

.github/workflows/api-diff.yml runs oasdiff/oasdiff-action/breaking pinned by sha (0ab8ad2, v0.1.10 = tufin/oasdiff:v1.26.1) against the PR's base sha, at fail-on: WARN plus the two opt-in ERR checks. pg-pkg/tests/api_gate.rs is its executable spec: 19 mutations with asserted verdicts, an anchor test, and the_workflow_step_matches_the_pinned_inputs reading fail-on/include-checks/the action ref back out of the YAML. COMPATIBILITY.md records the enforcement and the one rule the gate cannot see (dropping the /v2/irma/... alias, which stays a review rule).

One deliberate deviation from the issue text: there is no "explicit override label" escape hatch. A /v3 route added next to /v2 reads as additive, so versioned routes are the hatch instead, documented in the workflow header. That is the better answer — an override label is a green checkmark you can vote yourself — so the issue is satisfied, not half-satisfied. #249 never asked for branch protection, so its absence is not remaining scope.

#263 — legacy irma 0.2.1 in pg-core. Done, f2f06cd (#192), shipped in pg-core 0.6.2.

Resolved as option 2 of the three the issue listed (migrate to irmars). f2f06cd switched every pg-* crate off the abandoned irma 0.2.1 onto irmars 0.2.2 via the package-rename trick, and bumped pg-pkg/pg-cli to reqwest 0.12 in the same step. Root Cargo.lock now contains irmars 0.2.2 and no irma at all; reqwest resolves to 0.12.28 and 0.13.4, no 0.11.

The premise was accurate when filed and the timing is worth recording, because it is what actually closed the issue. In-tree the fix landed 2026-05-18, two months before the issue was written on 07-27 — but the newest published pg-core was still 0.6.1, and published 0.6.1 really does depend on irma ^0.2.1 (visible right now in pg-compat/Cargo.lock: irma 0.2.1, reqwest 0.11.27, because that crate pins =0.6.1). pg-core 0.6.2 released 2026-07-30 (361cdeb) and is the current max_version on crates.io, so consumers are off the legacy chain. Ties into #268 below: the last declared reader is exactly the version that still carries it.

#285 — sqlx↔rusqlite coupling + the cryptify merge. Decided yes and landed.

The map's Decisions-so-far still says "the deliberate yes/no and the merge itself are still open". Both happened, on 07-31 and 08-03:

• ba380a1 (feat(cryptify): merge cryptify into the workspace #277) — feat(cryptify): merge cryptify into the workspace
• 9887e1a — chore(cryptify): re-attach the imported cryptify history
• 18e0ab0 (fix(cryptify): release the stranded security fixes as 0.1.28 #279) — releases the stranded security fixes as 0.1.28
• f1b2e14 (ci(cryptify): publish the cryptify image from this repo #280) — publishes the cryptify image from this repo

Root Cargo.toml is now members = ["pg-core", "pg-cli", "pg-pkg", "pg-ffi", "cryptify"], and the lockfile resolves sqlx 0.9 + rusqlite 0.39 + libsqlite3-sys 0.37 — exactly the price the #255 spike quoted, paid deliberately. The test/format/clippy matrices all carry cryptify (keyed on directory rather than a pg- prefix, which renamed the check contexts from Test workspace (core) to Test workspace (pg-core) — nothing required points at them today, but a ruleset added later must use the new names). The two-lockfile bincode-next gap #285 described is closed by construction.

One consequence of #285 is not done, and it is the one the issue itself flagged: "cryptify's issues need a home decision like the archived apps got." encryption4all/cryptify is not archived and still holds live map children (#116, #136, #197, #198). Filed as a new child, blocked by #282 so the archived-apps decision sets the precedent.

---

B. Genuinely open, with the remaining half named

#251 — bidirectional wire-compat gate. Open, scope reduced to one child plus branch protection.

#260 and #261 are both closed and real: pg-compat (976b6af, #265) + wire-compat-rust, and pg-compat-js (4e6e2c2, #267) + wire-compat-js, both live jobs in build.yml. Remaining:

• compat gate: consolidate into one required status check #262 — consolidate into one required status check (open, unblocked, takeable now).
• Branch protection — maintainer-only; the App cannot set it. The two Wire compat contexts are already the only required ones per the build.yml comment, so this is verification plus making the Rust/JS pair consistent.
• compat gates: close the reader-list coverage gaps (crates.io rows unchecked, nuget row ungated) #268 — the declared reader window is still not evenly covered.

#268 — the drift it predicted has now actually happened.

Not hypothetical any more. pg-core 0.6.2 published 2026-07-30, and:

• COMPATIBILITY.md's reader list still reads crates.io pg-core 0.6.1 0.5.10
• pg-compat/Cargo.toml still pins =0.6.1

The file's own rule is "a producer publishing a new version moves a pin", and nothing moved, because nothing reads the crates.io rows — precisely the silent-green class #268 exists to close, caught by hand rather than by a gate. So #268 now has a concrete first task: move the row to 0.6.2 and pin it, then add the parser test mirroring manifest.test.mjs. Bonus: doing so also drops irma 0.2.1 / reqwest 0.11 out of pg-compat's lockfile.

#272 — half done, and the done half is in this repo.

pg-pkg/tests/api_gate.rs::the_workflow_step_matches_the_pinned_inputs already does for api-diff.yml exactly what cryptify#203 does. Remaining: the same guard for wire-compat-rust, wire-compat-js and semver-checks (the higher-value targets, since the wire pair are the required checks), plus the postguard-js targets the issue lists. Nothing outside scripts/semver-checks.sh reads build.yml today.

postguard-website#44 — not satisfied by website#329. Stays open.

website#329 is a merged PR (2026-07-27), not an issue, and it is phase 1 only: it got the 15 pre-existing Playwright specs running as the E2E Tests job. Its own body closes with "Phase 2 (the full send/receive flow matrix in the issue description) is out of scope, so #44 stays open." So the remaining scope is all of #44's actual content — send (single/multi recipient, attachment, cryptify, armored, fallback link), receive/decrypt (single/multi, required + optional attribute mixes, URL and attachment fallback), and the three edge cases (wrong identity, one-of-many wrong identity, retry after a failed Yivi session).

Complication that has to travel with it: the specs now live in apps/website inside postguard-js, while the ticket is stranded in the archived postguard-website and cannot even be commented on. Its remaining scope moves with #282.

The rest — confirmed open, spot-checked in the tree

• pg-core: canonical identity normalization (email lowercase, E.164 phone) with test vectors, exported via wasm/ffi #250 — nothing in pg-core/src normalizes identities (no lowercase, no E.164 path anywhere). Untouched.
• Chunk sizes should be configured server-side and fetched by clients #147 — cryptify has a server-side configurable chunk size (TOML, default 5 MB) and its spec describes the constraint, but no endpoint exposes it, so clients still duplicate the value. Ground moved in its favour: cryptify is in-tree now, so the server half is a one-repo change.
• Sonarqube CI tests failing #48 — the SonarQube job is commented out in build.yml (4352154), so nothing is failing any more; what is open is the decision (restore with a working SONAR_TOKEN, or delete the commented block and sonar-project.properties). Matches the fog line the map already carries.
• cryptify#197 / feat(api): accept Yivi condiscon in IrmaAuthRequest #198 (and their parents chore: add keywords metadata to pg-pkg #116, chore: remove website/ in favor of postguard-docs #136) — cryptify/src/store.rs persists only the rolling-quota usage table to SQLite. No upload-session table, no restore-on-boot. Untouched.
• e2e: provision business-db from real postguard-business migrations (schema-contract fidelity) #237, e2e: keyshare-backed disclosure flow (test scheme + keyshare server) #238, adopt Renovate org-wide (grouped weekly, auto-merge patch/minor on green CI) #254, decide & spike: fold postguard-dotnet into postguard (ship pg-ffi and bindings together) #256, shrink the promised surface: deprecate /v2/irma alias, drop dead format_version, unify x-postguard semantics #257, backlog: container format 3 — authenticate preamble+header (AAD + signature binding), format number = wire value #258, backlog: envelope format 2 — self-describing part, fix double-base64 #259, decide where the archived apps' 62 stranded open issues live #282, make "fail closed, no swallowed errors at a seam" executable instead of a review convention #283, split prod-verification between the synthetic probe (e2e#20) and the infra e2e (ops#38) #284, postguard-e2e#19/0.3.0 rc.0 #20/Wasm support in-memory sealing/unsealing #21/chore(deps): bump openssl from 0.10.46 to 0.10.52 #23/Add typescript types #24/chore(deps): bump openssl from 0.10.52 to 0.10.55 #25, ops#36/chore(deps): bump openssl from 0.10.60 to 0.10.66 #37/Fixed local build by updating to latest packages #38/Fix ISealOptions TypeScript type to include skipEncryption #64, postguard-js#123/pg-core: panics on malformed ciphertext input instead of returning errors #138/pg-pkg: CORS allows any origin on the PKG server #139 — all genuinely open. No dotnet spike branch exists for decide & spike: fold postguard-dotnet into postguard (ship pg-ffi and bindings together) #256.
• One overlap to settle before someone builds it twice: postguard-e2e#24 wants a tier-1–3 envelope corpus, and postguard-js already ships one from js#131 (packages/pg-js/tests/fixtures/envelopes/tier{1,2,3}-*.json plus envelope-archival.test.ts / envelope-forward.test.ts). Not a close — decide which repo owns the envelope corpus.

---

C. Closed but not done → nothing survives

All 23 closed children were closed by hand (no commit_id on the close event), with one exception, and that exception was repaired: js#127 was stray-closed by 079a7fe, reopened 16 minutes later, and re-closed manually at 22:08 on 07-29 after the real import. js#128 and js#129 follow the same pattern — stray-closed 11:04:55, reopened 11:20, re-closed after the real work landed.

Verified in the tree rather than from the issue state, as this ticket asked:

• js#128 ✅ examples/ exists (pg-node, pg-sveltekit, pg-manual, pg-dotnet), examples/* is a pnpm-workspace.yaml member, and .github/workflows/examples.yml builds them. Closed 07-29 22:51, right after ffd8b22 (FTP/SFTP export of encrypted messages #145, "import postguard-examples as examples/*, on the workspace SDK"). postguard-examples is archived, as the issue required.
• js#129 ✅ The shared readers are packages/pg-js/src/email/parse.ts + extract.ts, exported from the package index. Per-app parsers are genuinely gone: apps/outlook-addon/src/lib/mime.ts is down from 225 lines to a single Office.js guessContentType helper with a comment pointing at fix: correct typos and outdated references in READMEs #129, and apps/tb-addon/src/lib/detection.ts now calls detectPostGuard from the SDK. Closed 07-30 17:24, right after 5fd30b7 (CI: outdated actions/checkout versions (v2, v3) should be updated to v4+ #157, "one MIME reader, shared by both add-ins"), which also fixed a real quoted-printable mojibake bug it surfaced.

So the tree is wrong in one direction only, not both.

---

D. The hazard fired again — in this repo, and it took a live issue

The cryptify history re-attach is a history-preserving import, so js#139's failure mode applied to it, and the guard js#139 prescribes was not run. The imported commits carry 18 distinct closing keywords, resolved against postguard's numbering:

Closes #38 #45 #52 #54 #123 #125 #134 #142 #146 #153 #155 #157 #159 #167 #186 #191 #194 #273

Seventeen of those numbers were already closed here, so they were no-ops. One was live:

postguard#146 "Active Directory sync for organization user management" was closed by ba380a14 at 2026-07-31T07:07:34Z — an unimplemented feature request, marked done by an imported cryptify commit. Green checkmark, no warning.

Reopened. No map child was hit — the numbers do not overlap this map's range — but that is luck, not protection.

Two things follow. js#139's guard needs generalizing from "the remaining JS imports" to "every history-preserving import", because postguard is now a destination for them too; commented there with this instance. And #272's premise widens: the unguarded second half of an import is the same silent-green shape as the unguarded second half of a gate.

---

Tree-shape corrections

The map's Notes say #248 and postguard-js#123 are the only umbrellas. There are five: also #251 (children #260/#261/#262), postguard-e2e#19 (#23/#24/#25) and cryptify#116 (#197/#198). All three are wired blocked by their open children and so are correctly off the frontier — the query in the Notes finds them fine, the prose undercounts them. Fixed in the map.

Also worth knowing while reading CI: main is red at f1b2e14, and it is not a regression. Run wasm tests in browsers (chrome) failed on fatal: unable to access 'https://github.com/encryption4all/postguard/': 503 during checkout, and safari was cancelled by fail-fast. Infrastructure flake at a different step than the documented renderer-timeout one, same conclusion: re-run, which needs a maintainer.

---

Method note, so this is reproducible

Two traps, both hit while doing this:

1. Do not read your working tree. My postguard-js checkout was three commits behind origin/main, and at that sha apps/outlook-addon/src/lib/mime.ts is still the full 225-line parser — which reads as "js#129 was never done". The postguard checkout was 25 commits behind and showed no cryptify in the workspace. Every claim above uses git show origin/main:<path> or git ls-tree origin/main.
2. Read close events, not close state. A keyword-close carries a commit_id on its closed timeline event and a hand-close does not, which is what separates the two directions mechanically:

gh api repos/OWNER/REPO/issues/N/timeline --paginate \
  -q '.[] | select(.event=="closed" or .event=="reopened")
      | "  "+.event+" "+.created_at+" commit="+((.commit_id//"-")[0:8])'

And before merging any history-preserving import, from the import branch:

git log origin/main..HEAD --pretty=%B \
  | grep -oiE '(close[sd]?|fix(e[sd])?|resolve[sd]?) +#[0-9]+' | sort -u