Every other panel here answers where do I need to look, and after a good week they are all zero — which is exactly what a dead fleet looks like too. This is the other reading: what happened, per day. Every figure comes from reads the page already makes, so the panel costs no extra request; what that costs instead is depth, and where a series runs past what one page of issues or thirty runs can see it says so rather than drawing a confident zero.
The detail behind the block at the top, from each member's own usage fold — the file the sweep already read, so none of this costs a request. A check failure is a win: the finding went back into the session and the agent fixed it before the work left the branch, which is the closest thing this pipeline has to a measure of what the corpus is worth. Runner errors is the one number whose right value is zero. Every count is a floor: only captured sessions are read, and a session whose container was reclaimed is invisible.
Two ranges, on purpose. The workload tiles are this week against last, like the block at the top. The scopes, rules, skills and member rows cover the whole folded range the files hold, with no comparison: a rule that fired twice this week and once last is not a trend, and "mounted, never loaded" is only a claim worth making over as long a range as there is. A skill that never loads in one repo may just not be that repo's subject; one that never loads anywhere is mis-described or should not be gated at all. A member with no usage file is named and counted in nothing.
Ordered by the worst thing that is true of each member, not by how much it has. One item parked for a human outranks forty healthy ones, because the first needs you today and the second is the system working. A member that cannot be read, one that does not run Claudinite, and one that is fine are three different rows and never collapse into a zero.
The columns are grouped as three questions, in the order you ask them: Activity — is anyone working on this repo; Waiting on a person — what is on your plate here and roughly how long it is; Claudinite — what the machinery is doing. Stars and CI sit beside the name rather than in columns, because they are how you recognise the row rather than findings about it. Every column but the commit curve comes from a read this page already makes. Rule tokens, sessions and check counts are not columns here: they live in What the corpus is doing across the fleet below, read off each member's own usage fold. Issues and pull requests are counted within the issue window — the most recent hundred — so an older one is not counted rather than counted wrongly.
Commits is the last 90 days as a curve, drawn by week — a quarter at daily resolution is a sawtooth of weekends and Tuesdays with no shape to read — and scaled to that row's own busiest week, so height compares two weeks in one repo and never two repos. The number beneath is the real total, and the hover carries both peaks. A break in the curve is a stretch outside the year GitHub reports statistics for, which is not the same as a quiet one; a cell reading not read is this page declining to spend the request, since this is the one figure here that is decoration rather than a fault signal and so the first thing a tight budget goes without.
Est. is a deliberately crude figure: every item parked for a person, at a flat 7 minutes each. Nothing here measures how long a park actually takes, and the honest way to publish a number nothing measures is to publish the assumption where you can argue with it. A broken scheduler is not counted into it — that is not a queue of work to get through — though it is still reported. Packs wears the mount's verdict as a badge: a scheduler run when what is declared here is current, a timer when it is behind, and the versions on hover. Two facts read together, and the second says the same thing on nearly every row, so it earns a corner rather than a column.
Click a member to open its scheduler in full.
The one question no single repo's page can answer. A task ships from a shared pack, so it runs in every member that declares it — and the same task parked in four members at once is a canon problem, while in any one repo it looks like that repo's bad luck.
A shared pack's task, everywhere it runs. One parked in several members at once is the pack's problem, not any one member's.
Who a change to a pack would reach. Before editing a pack's rules or its checks, this is the blast radius; after, it is how many members have to converge before the change is real.
The board is the same rows drawn on a time axis, one lane per flow — a
connected component of the Blocked-by / Ends-when / Closes
graph, never one task and never one kind, because the edge is the finding. Every mark is read
off a label, a body line, a timestamp or a task declaration; a field the listing does not carry
is drawn as not read, never as 0.
The three tables remain behind it. stuck is what has stopped and how long it has been, pending is what is moving, all is what each task is and what it has done. The page opens on the board whenever anything is stuck or waiting on a person; a repo with nothing live opens on all, since an empty board teaches its reader the page is broken.
This repo declares its scheduler dormant, so nothing is instantiated, readied or
picked up. Its declared tasks and any open work items are not drawn here, because none of them
can move — the rest of the page is still live, and a mount that has fallen behind canon is still
reported as behind. Clear dormant on the claudinite-tasks pack entry to
wake it; a dormant spell is not replayed, so it simply starts scheduling again from now.
Every occurrence is a work item, and a converged one closes wearing its outcome. Today is
counted from the live issue page; the days before it come from this repo's own
usage.GENERATED.json, folded hourly. A day neither source reached is left
blank rather than drawn at the floor — "not read" and "nothing happened" are
different facts and this chart keeps them apart.
Three different things per hour: scheduler runs (the hourly tick that decides what is due), executor runs (a dispatch actually being run), and agent sessions (a session that opened and captured). A scheduler run that fails is not a task that fails — it means nothing got to be decided at all.
The freshest hours come from the live run listing this page already fetched; the rest from the usage fold. Hover an hour for the tasks that executed in it — the run listing cannot say, since nothing in it names a task, so that detail is the fold's or it is absent.
The two halves of what the corpus costs and buys: rule tokens are what the mount puts into every session's prompt before its first turn, and checks executed is how often the conformance rules ran. A check that fails is a win — the finding goes back into the session and the agent corrects before the work leaves the branch.
The two lines are on separate scales, stated on each axis: rule tokens are five figures a day and check runs are single ones, so on a shared axis the second would be drawn as the x-axis. Two heights here never compare. A break in a line is a day nothing answered for — never a day drawn as quiet. Everything in this panel comes from the repo's own usage fold; a repo that does not run it says so instead of showing an empty chart.
Every other panel on this page is the scheduler, which every member has. These are what this repo's own declared packs have to say about it — a release pack the last release, a spec pack the requirements that moved — and they differ from repo to repo, which is why they come last. A pack contributes data, never code: it ships a descriptor naming what it has, and its own task writes the values into the repo's tree. Nothing here is executed, and a figure that has not been written says so rather than reading as a zero.