plankanban/planka: technical due diligence, read from its repository

22 test files against 1,234 source files (1.8%). 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.

client/package.json declares 83 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 224 fixes in the last 24 months, 5 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.

7 of 1,130 locked dependencies match 16 published advisories in OSV, 5 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.

LICENSE.md exists but its text does not match any standard licence. A bespoke or hand-edited licence is not wrong, but it cannot be cleared by recognising its name: counsel has to read it, and until they do neither side knows precisely what rights transfer with the code.

Both probes call the same endpoint. When a dependency slows down, the liveness probe fails with the readiness probe, so the platform restarts pods that only needed taking out of rotation, and a partial outage becomes a full one. Liveness should ask whether the process is alive; readiness whether it can serve.