The screen says the buttons chain together; the engine says the thing is done behind. A capability is only truly verified if both exist and pass.

Each card states a FACT, not a verdict. "Failed proofs" is the only one that talks about a fault; the other three count proofs nobody ever wrote, a plan of work, not an alarm.

One row per capability, grouped by product domain. Two columns: what the SCREEN said, what the ENGINE said. Under each result, the tests that carry it.

Getting in 2

Building a team 4

Talking and following 4

Granting capabilities 5

Staying in control 5

Automating 2

Steering 2

The label @cap:<slug>/ecran or @cap:<slug>/moteur goes in the title of a describe or of a test, and holds for every case it contains. node apps/qa/porte.mjs refuses a label that names nothing, and a required capability no test claims any more; a label with no level is flagged without blocking, for the duration of the transition.

Four numbers: the share of code a test goes through, the number of tests, the share of user scenarios the CI plays, and the number of bench sections. The first one only holds for the measured packages.

Coverage by package

A package = a folder of the repository with its own code (the runner, the web app, the tools…). Sorted by what costs the most to ignore: the lines nobody tests.

Sorted by uncovered line count: what sits on top is what costs the most to ignore. An unmeasured package is hatched, it does not have zero, it has nothing. A package left out on purpose says so, and says why.

1. 01

   1 open card(s) written by an agent carry no verified facts

   An agent opened them and wrote no "Verified" section, so nothing in them was checked against npm, git or a test run. That is exactly how a version that shipped a week earlier became a task on this board.

   #579 Cost totals still turn an unknown into a precise number: run summary, CLI pipeline view, refused capped turn

2. 02

   38 flaky test(s)

   Green and red within their window. No isolated run gives them away: they pass for green every time they pass.

   Proof commands — la page du projet @cap:verifier-un-livrable/ecran F — /code mène à Workspaces : la liste a disparu, le panneau est sur le projet Proof commands — la page du projet @cap:verifier-un-livrable/ecran G — RIEN ne déborde du panneau, chemin long et commande longue comprises Approvals tab @cap:regler-autonomie/ecran Autonomy tab is visible in the agent editor Connector scope disclosure Google Drive states it reaches the ENTIRE Drive Connector scope disclosure Google Sheets and Docs disclose their reach too déplier un bloc du fil @cap:parler-a-un-agent/ecran C — déplier DEPUIS LE BAS ne fait pas filer la zone visible Built-in tools — per-tool controls return_result is shown but locked, with the reason Built-in tools — per-tool controls and can be handed back — the restriction is reversible Built-in tools — per-tool controls blocking a built-in tool persists across a reload Built-in tools — per-tool controls the section lists the built-in tools, always — no fixtures needed A — allowlist renders: owner badged, pending has Approve/Deny, member has Revoke Help guides — OAuth wizard (Google Drive) @cap:consulter-l-aide/ecran wizard shows 4 Google API links and format hint Google Drive OAuth flow (wizard-driven) @cap:connecter-un-service/ecran connect via wizard → callback → connected status and toast MCP Connectors page Scenario A — /mcp renders the connected Cogni Cortex server le registre lui-même nomme la preuve attendue exactement là où le dépôt n’en a aucune Airtable OAuth flow (wizard-driven) connect via wizard → callback → connected status Apify api_key connector smoke test marketplace card opens modal; connect with name + apiKey creates active instance Test A — LLM key add + test connection + save navigate to /llm-providers, add a provider, test connection, save, row appears Connector multi-instance can create two instances of the same api_key connector and both appear in Active Connectors Credential reuse — Drive + Gmail share one Google credential connect Drive via wizard → reuse credential for Gmail via dropdown

3. 03

   The CI grew 195% over the window

   First half of the runs against the second half. A drift is repaired while it is small; once settled, it becomes the normal nobody argues with any more.

46 versioned, and only 6 guard a pull request: the others observe after the fact, or never.

Three groups by cadence: played on every pull request (blocks), every night (observes), by hand (never). The last result is case by case, a journey can be partly green, partly skipped.

every pull request 6

These BLOCK a regression before the merge.

every night 40

These OBSERVE it the next day. They guard no pull request.

Last run on 29 Sept 2026, 10:12Z: no regression, no section down.

One card per measured section. The baseline is the last accepted value, with the commit that accepted it: that is what the next run will be compared against.

How long you wait for a pull request's checks, over the CI's last thirty green runs. It is this number that decides the fate of the tests: when the wait becomes unbearable, it is the suite that gets shortened.

The most harmful 20

The tests that fall most often relative to their runs. A 30% rate over ten runs is worse than a test that is always red: you never know whether to believe it.

Sorted by failure rate. The ribbon reads left to right, oldest to newest.

Broken

Red at their last runs. "Red since" only dates the flips we saw: a test red since before the first measurement has no date, and that is honest. "Age" counts the days as of the collection, not as of when you open the page; past 14 days it turns red.

What moves

The same numbers as the Overview, but over 30 days. The figure next to the title is the gap between the first and the last collection of the window. Collections started from a workstation are left out: they do not measure main.

Every collection