longguikeji/arkid: technical due diligence, read from its repository

42 test files against 570 source files (7.4%). 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.

Of 465 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.

There is no disclosure policy, no automated dependency updates, no named code owners and no pre-commit configuration. None of these is load-bearing on its own. Their collective absence says that security posture here is whatever the current team happens to remember to do, which is not a posture that survives the team changing.

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.

The root licence changed 1 time(s). The latest terms restrict what users, hosts or a buyer may do in ways the earlier ones did not. Code taken under the old terms stays under them, so both matter in diligence.

None of 1,076 readable files references an instrumentation, metrics or error-reporting library. If this system is in production, nobody learns that it broke from the system itself — they learn it from a customer. That is a reliability finding before it is an observability one.

Nothing references a structured logging library. Logs that are written to be read by a person are not searchable by a machine, which means incident response here is proportional to how well someone remembers the codebase rather than to what the tooling can find.