casosorg/casos: technical due diligence, read from its repository

The median source file here is 115 lines. 3 files exceed 1,150 lines, the largest being 2,134. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.

Of five ordinary markers — CI workflows, CODEOWNERS, a pull-request template, pre-commit hooks, contribution guidance — 1 is present: CI workflows. Branch protection itself is a GitHub setting rather than a file, so this is a reading of proxies and not of the rules themselves. What it does establish is that the process is not written down anywhere a new engineer would find it.

The suite is configured to retry failing tests (web/playwright.config.js). A retry turns a flaky test green without saying why it failed, so a green build means the tests passed eventually. Ask how many retries a typical run needs, and which tests need them.

3 third-party CI actions are referenced by a tag or branch rather than a commit, so they run whatever that tag points to on the day; 3 steps pipe a download straight into a shell. Tags have been moved to malicious commits in real supply-chain attacks, and a piped script is whatever the server returns that minute. Pinning to a commit is the fix, and it is small.

Third-party code is committed into this repository without any statement of the terms it arrived under. Unknown terms are harder to deal with than inconvenient ones: an awkward licence can be complied with, an absent one cannot. Each of these needs its origin established before the code changes hands.

1 deployments set `replicas: 1`, and nothing (an autoscaler, a disruption budget) adds more. Every deploy and every node drain is downtime, and the availability the buyer inherits has a ceiling.