Context
Stefan Coetzee runs his work in the cockpit, a view that shows every task, finding, and decision by the eight areas of the CTO powersuit, with a scorecard per area and the trend. His own install runs on beads, a local issue tracker, and that data stays on his machine. On 2026-10-14 he asked for a version of the cockpit on Inside as a demo, and chose GitHub Issues as its data: an install can run the cockpit on beads or on GitHub Issues, and the public work is on GitHub already.
Decision
The cockpit page is one page in the Inside section of site/nav.yml, after Mission Control. It is static: scripts/build_cockpit.py writes its blocks from inside/cockpit/cockpit.json, and the page reads nothing in the browser.
The data is the open issues and pull requests, and those closed in the last 14 days, of the owner's own public repositories (no forks, nothing archived). Two labels place an item: area:<area> for one of the eight areas, and kind:<kind> for finding, decision, action, or lead. Both exist on every public repository of the owner. An item reaches the page with its title only when a maintainer has given it an area label and its author is the owner, a member, or a collaborator; other open items are counted per repository, without their text, as the board does with untriaged issues. The author rule matters because anyone can open an issue on a public repository and edit its title after a maintainer has labelled it. A lead (kind:lead) is only counted, since its title may name a person or a company. Blocked and in progress come from the board's status labels, and an open pull request counts as in progress.
Only public GitHub data reaches the page:
--fetchreads the repositories from the GitHub API, withGH_TOKENif set and else with no token. In the deploy jobGH_TOKENis this repository's workflow token, which reads no private repository of the owner. The read stops, and writes nothing, on any repository that GitHub does not report as public or that belongs to another owner.check()allows exactly the keys of the contract at every level, no key twice, fixed forms for every value, and as free text only an item's title. Each item's URL must be the GitHub URL of that issue or pull request in a listed repository of the owner.- The deploy job runs
--fetchafter the board's snapshot (artifact only, never committed), so the live page is as fresh as the last deploy. A failed read or check leaves the committed page in place. - The Conformity checks job runs
--checkon the committedcockpit.json, before the gate. It also fails when the page's blocks or its sitemap date differ from the data, so nothing between the cockpit markers comes from anywhere else.
Each area row names the plugins that do its work and links their pages. The area titles, lines, and plugin lists come from site/powersuit.yml and cto-powersuit/modules.json. The board stays the view of this site's issues by status, and the cockpit is the view of all public repositories by area. Each page links the other.
Consequences
Labelling is part of the work: an issue without an area label is only counted. The labels area:<area> and kind:<kind> have no space after the colon. The board's own labels (area: docs, area: gate) have one, and the two sets stay apart. A repository of another owner needs a reviewed change to OWNER in the script. Titles reach the live page at deploy time without the gate's text scan, and only from the owner's account and its collaborators; on the committed copy, the gate scans them like any other page text. A powersuit pin move changes the area rows too, so scripts/build_powersuit.py rebuilds the cockpit page from its committed data.
The page carries the definition of the CTO powersuit in the same words as the other pages that use the term, so it is one more input to the CTO powersuit experiment. Steps and the contract: Cockpit page.