karakeep-app/karakeep: technical due diligence, read from its repository

100 test files against 1,038 source files (9.6%). This does not measure whether the tests are good, only whether enough of them exist for the codebase to be changed safely by someone who did not write it — which is exactly the situation after an acquisition.

71 of 1394 commits in the last 24 months changed over 2,000 lines of code, not counting reformatting, renames, vendored or generated code. A change that size is rarely reviewed line by line. Ask how they were reviewed, and what made them that large.

apps/web/package.json declares 94 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

Of 760 fixes in the last 24 months, 89 touched a test. A fix without the test that would have caught the bug can quietly come back, and the suite never learns from what went wrong.

No USER instruction switches away from root, so the process runs with full privileges inside the container. It is a one-line fix and an ordinary expectation, which is why its absence is worth asking about: it usually says more about whether anyone has reviewed the deployment than about this container specifically.

22 of 3,377 locked dependencies match 52 published advisories in OSV, 25 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version.

The build configuration emits source maps for production, so the original source, with its comments and structure, is downloadable by every visitor. Upload them to an error tracker and keep them off the public server instead.