Cockpit

Every dot is one merged pull request: the minutes spent writing and fixing the code against the minutes spent in the harness, which means the review rounds, the test runs and the browser pass. Bigger dots needed more rounds. Every pull request pays a fixed harness cost, so a small change sits above the dashed line whatever it did.

Below the chart, every pull request is listed with its rounds and how long it took to merge.

Every Claude Code session is recorded and tied to its pull request and issue. The report splits the cost by step: scoping and planning, building, local code review, local security review, after push and the reviews in CI. It can group by pull request, issue, engineer, step or day, and export to CSV.

So I see which changes were expensive and which step made them expensive. The most expensive one in the screenshot cost $140, almost all of it building. One gap the report states itself: Claude Code Review and Claude Approvals run on Anthropic's side, so they are not in it.

Every CI job's pass rate over 7 and 30 days, with the run counts it comes from and how long the job takes, worst first. A cancelled run is left out of the rate and counted on its own. So I see quickly when a check has become unstable and needs fixing.

CI runs only the tests a change can affect. Without that, every change would run the whole suite, which would be far too slow and too expensive. This report shows whether the selection works: how often it misses a test, how often it is forced to run everything, and how much time it saves.

When the harness feels slow, I open a pull request here and see which tests ran and the chain of imports that made each one run.

Each row is a part of the product as a person would name it, each column a level of test, and each cell counts the rules proven there. Every rule links to the line of the test that proves it.

When one area starts to see too many regressions, I look here to see how well it is covered, and then I know which gap to close.

Every area of the code, each drawn below the areas that import it, with one box per connector. Red marks what goes against the design: an import going back up, or a connector that is not a clean package of its own.

Which area imports which. The areas are ordered so each one sits above what it imports, and each cell counts the files that import across. That makes a dependency in the wrong direction stand out:

• a red cell is an area importing one above it;
• an outlined cell is the other half of that import, so two areas depend on each other and neither can be changed or tested on its own.

Which workflow deploys to which environment, and what each environment uses, read from the Worker config and the workflows. I use it to check that a change in how we deploy is the change I expected.