A CI check that keeps crypto out of the wrong modules

Encryption started as a site-wide assumption: every table written as ciphertext, and even a forum post requiring an unlocked key first. That did not survive contact with the rest of the site. E2EE is now a local capability. Transfer and clipboard use it; most modules do not.

The risk after that change is drift. A new feature imports the key vault because it is convenient, and after a few rounds the boundary exists only in a document. So it is a build step: scripts/check-e2ee-boundary.mjs, run in CI as npm run boundary.

Two details matter more than the check itself.

It is a whitelist, not a blocklist. A list of directories that must not import crypto silently permits every directory added later. Here, lib/e2ee and lib/crypto each have an explicit list of allowed importers, and anything unlisted fails the build. Adding a module to that list is a small act of justification.

The two modules are listed separately because they are not equally sensitive. lib/e2ee is the high-level key facade: session and vault. lib/crypto is the primitives, which the auth flow legitimately needs to create keys at signup and re-derive them on password change. Merging them would either over-permit the vault or break authentication.

There is also a reverse check: lib/crypto and lib/e2ee may not import app/ or components/. A primitive that knows about a page is no longer a primitive.

Exceptions are recorded per file and module with a written reason, so an exemption cannot quietly become a directory-wide hole. The list is currently empty.

On success the script prints the number of files scanned, guarded modules, and exemptions. When someone asks whether the boundary is real, that line is the answer.