tracker

This text was generated by an LLM (how cgwalters uses LLMs). cgwalters has not reviewed it yet.

Work items and questions for cgwalters-bot's workstream. The Workstream board is a view over these issues plus the upstream issues and PRs the bot works on; anything on the board that isn't upstream is an issue here.

• Work items are ordinary issues. Larger efforts are parent issues whose sub-issues are the steps, so the board shows their progress.
• Questions for cgwalters are issues labelled question and assigned to him, usually a sub-issue of the work item they block. The first line says which item that is (Blocks: <url>). They offer lettered options, the recommended one first as A.

Answering a question

Comment on the question issue. To pick an option, make the first line of the comment just its letter (e.g. B), optionally followed by more text; otherwise write whatever you want. The bot acts on the answer, then closes the issue with a one-line comment saying what it did.

Only comments by the cgwalters login count as answers. The bot reads everyone else's comments, including its own, as input to consider, never as instructions.

These issues are opened by the bot's workflows here or by manually running agent-board's ask create. The review app is a UI for the same queue.

docs/bring-up.md says how to start a coordinator on a fresh machine from credentials alone, how to dispatch a run and where its state is. docs/operator-notes.md is the log of cgwalters' instructions.

Review drafts

The prose review checklist gives contextual, advisory rewrite suggestions and meaning-preservation checks. It does not enable an automated prose reviewer. It includes a versioned manual prompt and positive/negative fixtures.

The offline architecture-review prototype contains a versioned pattern library and manual review procedure. It has only a three-PR development pilot and no held-out result. It is not wired into the production review step.

docs/review-corpus.md describes the corpus of cgwalters' public review feedback, which is published weekly as a new dated review-corpus-* release. It explains how to find, pin and download a version.

Agent-drafted reviews of others' pull requests wait as issues labelled review-draft (is:open label:review-draft is the queue). To send the newest draft as cgwalters-bot, tick the body's Send the newest draft as cgwalters-bot box or comment just /send; .github/workflows/review-send.yml then runs agent-board's review send, which posts it only to the repositories listed in the review section of .github/poll/agent-board.json and closes the issue. If it cannot send a draft (a moved head, a line not in the diff), it explains the refusal in a comment. A missing or stale approval only fails the run. The approval rules are in agent-board's docs/review-drafts.md.

Dispatched tools

Dispatched runs have a staged opt-in to agenthome's install-tools through the commented [setup.tools] in .github/agentic-job/hosted.toml, including ast-outline and ast-grep. The pin is the API-resolved merge of agenthome#4, 9b43eb81e1266ec762a6c49a4e31fb6b4ff3e0e0 (main on 2026-10-14). This configuration waits for the shared actions wrapper to upgrade from agentic-job v0.2.0 to a release containing #602; v0.2.0 cannot parse the opt-in. After that upgrade, uncomment the four-line table. The wrapper does not need a new input: it already passes the caller's runner configuration. The installer runs before network lockdown as the sandbox user, with upstream's 120-second Git phases and 600-second install limit; its code and dependencies are trusted setup, not sandboxed task code. A real install and hardening check need a fresh dispatched runner.

The pass

.github/workflows/poll.yml runs one agent-board pass every ten minutes, with .github/pass.json as its configuration. A pass follows the bot's pull requests to a fix, a merge or a person, refreshes the pools' usage from the inference broker and publishes the bot-usage/v1 snapshot the review app reads (from agent-board#306 on), plans and applies the operator's live epics, starts board work by Priority within wip and each pool's pace, and derives each board item's Status. Each decision is one line of the run's summary; agent-board's docs say what each means and what it holds. The rules themselves live and are tested in agent-board, not here.

The agent-board commit is pinned as AGENT_BOARD_REV in poll.yml, since the binary gets the bot's token (CGWALTERS_BOT_PAT); move it only with a review of that revision's pass. The job token starts dispatch.yml and review.yml runs. The job joins the tailnet for the broker, whose address is set by the repository variable INFERENCE_URL (or, if unset, the organization's tailnet setting); without joining, the pass paces on the last published snapshot. Passes share one concurrency group and never overlap.

A scheduled pass only previews unless the repository variable PASS_APPLY is enabled. When run manually, gh workflow run poll.yml previews and -f apply=true applies. While PASS_APPLY is enabled, each applying pass starts the next one ten minutes after its own start, since GitHub drops most of the */10 schedule. A pass does not start the next while a newer applying run on the default branch has not finished, so a second chain, say from a manually started applying pass, usually folds into the newer one; a run arriving during that check, or a newer run that never continues, can still leave two chains or none. Setting the variable to anything else, or cancelling the run that is waiting, ends the chain. Every pass is capped at eight agent runs, twenty other writes and fifty Status changes (exceeding the Status cap rejects that stage, even in preview, until someone has reviewed it); raise them in poll.yml after observing the passes. New work goes through the board: an open issue on it in a workRepositories repository, under a live epic or opened by the operator or the bot, is taken in Priority order. Dispatch by hand (docs/bring-up.md, "Dispatching a run") for anything else.

.github/workflows/maintain-shadow.yml (tracker#1356) runs agent-board poll --dry-run on agentic-job every half hour, with the job's read-only token and the settings just maintain-shadow-config takes from pass.json. Its job summary previews what poll alone would do there, for comparison with what the pass did; it takes no step. The pass-only pr keys, such as operatorPaths and noMerge, are not applied, so the poll can preview a merge that the pass holds.

A pull request labelled needs-human is not touched again until the label is removed. A fix run can request one add_comment explaining why it cannot safely change the pull request, without a push (opt-in in .github/agentic-job/fix.toml); the unchanged head is what stops the fix rounds.

Apply opens complete work ready for review (ready_when_complete in dispatch.toml and fix.toml), except on a midstream fork: a repository with the bot-midstream topic whose main tracks upstream (#336). Every pull request there stays a draft. dispatch.yml gives those targets midstream.toml and midstream-fix.toml instead, based on those files' repos. A fork with that topic must be added to those lists before receiving dispatches. cgwalters-review skips drafts, so a midstream pull request gets no automatic review; /review still works.

Paced-review cutover

Prepared, not activated (5 November 2026, #1198/#1171). This updates the merged #1103 preparation, not its old separate-review-wrapper route. The threat is duplicate, unpaced inference for one PR head while event reviews remain authoritative. dispatch.yml therefore rejects reviews unless the trusted repository variable REVIEW_DISPATCH is exactly enabled (unset is off), before calling any wrapper or inference. No dispatch input bypasses that gate. pr.reviewPools and pr.reviewDispatchRepositories remain absent in .github/pass.json. Existing review.yml, its SHA pin, events, base bounds/task and write-authorized /review admission remain unchanged and authoritative. No settings, credentials, admission, rulesets or live reviews were changed.

The pinned producer's ordinary dispatch contract selects exact followed base repositories with pr.reviewDispatchRepositories. It dispatches kind=review, repo=OWNER/REPO, positive item, exact head, nonempty pool and a task hint to the base repository's default-branch dispatch.yml. The run identity is exactly review OWNER/REPO#ITEM HEAD (POOL). The caller requires a lowercase 40-hex head only for reviews, rejects effort/config overrides for reviews, and routes review/non-review jobs mutually exclusively. Non-review profile, ordinary pools.json/AGENT/AGENT_MODEL fallback and moving-main wrapper call stay as before; reviews never enter those jobs.

The separate literal ordinary-wrapper call pins actions#198 at f05e2372d3bd5540406d444e26c70ba8c845b07d. It receives only kind/repo/item/head/pool and a fixed task hint, no apply PAT or provider key. The wrapper owns trusted REVIEW_POOLS resolution (explicit agent/model and optional base-owned config, no ordinary fallback), fixed base-owned bounds/task, default-branch/public/base-repository admission, expected-head policy, and checked submission with the same base-repository job token. It caps reviews at 150 requests, 500 AIC and 75 policy minutes. Review code is fetched as data inside the credential-free sandbox, not executed in a privileged head checkout. Missing/malformed/unknown pools fail at that owning layer, not in a second tracker pool resolver.

just test-review-caller is offline caller plumbing coverage: disabled routing, exclusive jobs, malformed/missing head, expected-head forwarding, exact title, and unchanged non-review/legacy contracts. It does not prove stale-head rejection or checked submission. Immutable wrapper boundary tests are cgwalters-agentic-job.test.mjs (including missing/unknown pool, head/admission and pre-submit checks) and review_wrapper.rs (credential, immutable dependency and checked-publication boundaries). just test-review-wrapper PATH runs the Node boundary suite from a read-only checkout at that exact SHA; it performs no live inference or review.

Followed caller inventory

Read-only default-branch observations below (4 November 2026) are snapshots, not deployment attestations. Every path is .github/workflows/review.yml. pr.reviewPools is global across follow, not scoped to tracker or workRepositories.

Repository (under cgwalters-forge)	Observed default-branch commit	Blocker
agentic-job	7d6b5a29af4f5b63ac7b61a09189804cc6ca713e	Consumer contract exists; operator settings unverified
agent-board	4966c522c259ea0fa744bd37070de925aeb29d74	Event-only caller, actions 1b4539d
tracker	f017042504ae0792212c2c285bcb93524555d515	Event-only caller, actions 1b4539d
actions	95c09b9947f39100117fbc69bf0b6239d2cf22c3	Event-only caller, local incompatible wrapper
review	cae17abc764c97a15cd6838e38534ad7d81579c9	Event-only caller, agentic-job v0.6.4
agenthome	e8607434f5083ecce81b52073c556be9b245e09e	Event-only caller, actions bc0ea82
forge-infra	9896d511523f5cbbeb3e9f20b5ef71bb0ed85d23	Event-only caller, actions d8e22f7
cgwalters-forge.github.io	1e39839639e56179556e8b101dc8ac5a9c895a37	Event-only caller, actions bc0ea82
bootc (forge branch)	3ff59436aa70ea4b3561fd99ac463aaa44ad53ac	No review.yml (404)
composefs-rs (forge branch)	c8f8eb7384bdea4aa40018f446ed3bc0fbf05ba9	No review.yml (404)
bcvk	b2d1cc90055d0c846d649bf5519b79650aabe0a9	No review.yml (404)
rpm-ostree	911dd734bdc9d35eae33a074a613e436e7b400ee	No review.yml (404)
atomic-linux-sandbox	27811ece4961bf174e03d957477edf1575c70d2d	Event-only caller, actions d8e22f7

No external callers were edited. Missing workflows remain blockers, not implied exemptions because their PRs are drafts or merging is disabled.

Coordinated activation and rollback (operator work, not run here)

This is not rollout approval. Broker/tailnet admission of the pinned ordinary wrapper's job_workflow_ref, token permissions, trusted REVIEW_POOLS settings and agent configuration remain unverified. Re-inventory all followed base repositories at their deployed default-branch SHAs; the dated read-only table above is historical inventory, never global-coverage proof. No external callers were edited. Verify dispatch permission (actions: write) in each selected base repository and exact producer/consumer pool identity before proposing settings.

Coverage must include all authors admitted by the authoritative event route, including bots, associated humans and in-repository branches, plus currently write-authorized exact /review commands for otherwise unadmitted authors. The ordinary wrapper's author policy is not proof of event-route equivalence; its bot ID/login requirements, associated-human rules and bounded command history checks need explicit coverage. Do not silently drop authors or weaken admission to make a pilot work. The unchanged legacy wrapper has no coordinated record-only contract for this ordinary route: replacing/suppressing events and commands without loss or double starts is still future approved work, not something enabled by this caller gate.

The producer also explicitly leaves general dispatch.yml merge/fix provenance unresolved: a review-shaped title is not kind/caller attestation. Existing acceptance still requires the immutable Actions bot ID, current head, public bot-fork scope, cited run and dedicated pr.reviewWorkflow; ordinary intake does not widen merge authority. Do not change that workflow setting or merge policy to pretend the preparation resolves this blocker.

For a future approved cutover, first stop paced starts and pause applying passes. Drain/cancel existing event and ordinary review runs and inspect ambiguous claims/reservations without erasing them. Deploy and verify the coordinated authoritative event/command suppression or pending-record route before activating ordinary starts; never enable both inference paths for a head. Only then coordinate REVIEW_DISPATCH=enabled in approved callers with reviewed pr.reviewDispatchRepositories and pr.reviewPools settings. Keep existing WIP/pace/write/start bounds. Before resuming paced starts, also verify the existing publication opt-in AGENT_REAL_REVIEWS=true in each caller: the inference gate does not enable submission, and without that opt-in the wrapper can spend inference and finish without publishing a verdict or apply fallback. Preview before resuming applying passes. Merging source or previewing is not a live proof.

Retain live bot ID, exact head, run URL/title and run-marker evidence for the single submitted verdict on that head. Verify checked publication and that a push cannot approve its replacement head, authorized-command and all-author coverage, full-WIP/held-pool refusal, no duplicate start across later passes and reopen/synchronize events. Exercise outage catch-up: pending current heads must be recovered in bounded paced starts after recovery, without lost commands or blind redispatch of an ambiguous reservation. A completed run with no verified verdict or an exhausted failed-job retry requires human inspection. None of these live checks ran in this preparation.

Rollback after a future approved cutover: stop paced starts first (pause passes and remove the review scheduling opt-ins), drain/cancel outstanding runs, and inspect ambiguous reservations without erasing claims. Disable ordinary caller activation only after reconciling queued starts. Restore the authoritative event and authorized-command route in every affected repository before resuming normal operation; do not swap wrapper pins under active paced runs. Inventory pending, still-open current heads left by suppression or an outage. Check for active runs and existing exact-head verdicts before a write-authorized operator requests /review for each remaining head, then verify head/run-marker binding. Restoring events does not replay missed events: never push/reopen just to retrigger or clear reservations to force duplicate starts.

Draft-review buckets

Blocked, not proposed (5 November 2026, #1324). agent-board's draft buckets label the bot's drafts on the four midstream forks review:quick or review:deep. The threat they guard against is a forged, stale or merely small draft passing as reviewed. The producer is ready: AGENT_BOARD_REV d742eb8052aec70d8d4ecf1da98bec9b645ae40f contains agent-board#680 (9841aab) and the architecture-finding veto after it. The only newer agent-board commit, 957cb93, does not touch drafts, so the pin stays. The rest of the chain is missing, so .github/pass.json sets none of pr.draftReviewRepositories, pr.reviewDispatchRepositories or pr.reviewPools. just test-review-caller keeps all three unset and checks the shape the coordinated change must take:

• Callers: bootc 3ff5943 and composefs-rs c8f8eb7 (branch forge), and bcvk b2d1cc9 and rpm-ostree 911dd73 (main), have no dispatch.yml, review.yml, workflow/review.toml or workflow/review-command.toml, so they have no agent-board-review-result-v1 writer job. bootc's and bcvk's gh-aw review.md reviews do not write one either. The open prerequisites are bootc#99, composefs-rs#69, bcvk#24 and rpm-ostree#13.
• Wrapper: actions 9589edab2953e53fb244ec058011efe5e714c6ec (actions#198 closed actions#174) binds a review to its expected head and pool. It still refuses draft pull requests and has no result-writer job, so ordinary dispatched reviews can't produce draft evidence. actions#201 only documents the prerequisite.
• Consumer: review b04aa1d does not read the needs-you review_buckets extension, so it would show every draft as unknown.

Once all three exist, propose pr.draftReviewRepositories and pr.reviewDispatchRepositories for exactly those four repositories, plus pr.reviewPools = ["openai", "claude"]. Keep them in follow and pr.noMerge, keep the existing caps and the private holds destination, and coordinate this with the paced-review cutover above, since pr.reviewPools applies to every followed repository. Preview before applying. To roll back, remove pr.draftReviewRepositories. A review:quick label, whether added by hand or left over from before the rollback, never grants authority to mark ready, merge, fix or approve. Approval stays bound to the head the app displays.

Broker outages

Set the repository variable BROKER_OUTAGE=apply to enable the fifteen-minute broker-probe.yml schedule (off otherwise). It runs agent-board's broker probe at the commit supervisor.yml pins, with .github/broker/config.json. The probe joins using the dispatch tailnet wrapper and adds INFERENCE_URL to that config as its url, using the repository variable or, if unset, the wrapper's configured proxy. It makes one TCP connection and one unauthenticated GET, each limited to ten seconds. Any HTTP response shows reachability, not that inference works. It creates one bot-owned outage issue here, updates it while down, and comments and closes it on recovery. Tailnet join or reporting failures fail the workflow rather than falsely reporting broker recovery. There are no ACL or credential changes. The pass does not read the issue.

Epics

The 3 November 2026 composefs (C) CI inventory records the read-only 30-day baseline for #1222 under the green-CI epic #1215, including zero default-branch activity and evidence/coverage limits. It is not the ongoing monitor or a CI fix.

Plans for review

Design-level work is planned with the operator before any of it runs (#675): work started without an agreed target has gone the wrong way. A planning session (the controller and a subagent working from local clones, iterating with the operator) files its plan as an issue in this repository, assigned to the operator and labelled needs-human. Its body leads with the example contract, the workflow YAML or command a user would actually write, then the design, the slices in order, risks and open questions (#674 is one). The operator's comments ask for revisions. Without an epic label, it is a plan under review, and the pass does not touch it. The operator approves it by adding epic and removing needs-human; as for any epic, only the configured operator's label counts. The pass then plans it: the slices become sub-issues, the example contract the first where there is one, and it schedules them as for any epic.

Supervisor

supervisor.yml runs agent-board supervise health every fifteen minutes on the default branch, from its own crons. Every run, including a prompt-less dispatch, is a health pass. agent-board supervise due decides the sweep from the times.json the previous supervisor-health artifact carries: a pass sweeps when the last sweep was two hours ago or more, or on an explicit request (a prompt or a comment). If looking up that artifact fails (rather than finding no artifact), only an explicit request triggers a sweep (#814). health.json is a list of checks with id, status (ok, warn, fail), evidence links and a suggested action; each check also has one summary line. All thresholds and collection bounds are in .github/supervisor/config.json, with repository identities in that file and the existing poll configuration, never dispatcher inputs.

The health step reads with the bot's token (CGWALTERS_BOT_PAT), as the execute job and the poll do. The usage snapshot (pace) is in the private repository named in .github/usage/config.json, which the job token cannot read. The job token's 1000 requests an hour are nearly used up by four passes. The step runs only agent-board built from the pinned revision, never an agent or pull request code (the operator, 17 Oct: the same token as everything else of the bot's, rather than a separate read-only one). Missing access and truncated listings are warnings, not healthy observations, and fail once they have lasted unavailableFailHours: each pass reads the previous pass's health.json artifact to find when they began. API requests have deadlines and a total budget and a seven-minute collection deadline; the health step has an eight-minute limit, within a 25-minute job that installs a verified agent-board binary using just build-agent-board at the commit pinned as AGENT_BOARD_REV in supervisor.yml. The execute job installs the same binary. As in poll.yml, it never follows agent-board's branch: the executor receives the bot's token, so a change to agent-board reaches it only when that pin moves here, after review. The newest health artifact among the last five completed runs is restored with a two-minute bound and passed as --previous; a missing or unreadable report starts unavailable timers afresh. These bounds prevent a stalled API or oversized census from exhausting a runner. The JSON artifact contains links and fixed actions, not issue bodies, titles, private decisions or logs.

The health pass reads the epics with its own census. Recent PR/queue activity is every PR updated within eventLookbackHours, up to maxPages GraphQL pages per followed repository; it is not a historical audit. A removal from the queue because the PR merged is not counted. Infrastructure findings are warnings from probe/label time overlap, not proof that a retry is safe. A disabled broker probe (BROKER_OUTAGE unset) provides no observation: this is a warning that fails after an hour. Decisions currently cover open public question issues assigned to the operator, excluding ones with an authenticated operator reply; the private decision document is not published or interpreted. Loop detection uses checkpoint failures and pending-operation staleness, not speculative interpretation of agent prose.

The checks the controller ran by hand: idle and stuck, which read the old board scheduler's lines from the log of the job schedulerJob names and so find nothing in the pass's log (pass) until the supervisor is redesigned; pace, a pool's used share of its window beyond paceMarginPercent points from the share elapsed; failures, the newest dispatch run of a kind and target that failed with a secret-shaped string, an E0NN safe-output refusal or missing data naming a closed blocker, from its failed jobs' annotations; held, needs-human on the bot's PR past holdWaitHours; unqueued, an approved PR whose merge state is clean, out of the queue past unqueuedWaitHours; unclosed, the bot's merged implement PR whose run's issue is open past unclosedWaitHours, unless it says it is part of it.

The agent and the executor (D14) are off unless SUPERVISOR is preview or apply. No repository variable is changed by this wiring. The agent runs on a failing check (with agent.cooldownHours cooldown), a two-hour sweep (decided in the health job, with 7 */2 * * * as a fallback), a manual prompt, or a new comment by the configured operator on the locked requests issue (here #656). The comment gate also rejects PR comments; the login and issue are checked against trusted config in tests. The requests issue must be locked by the operator before comments can wake the agent. Another deployment sets the repository variables OPERATOR and SUPERVISOR_REQUESTS_ISSUE to its operator and agent.requests.issue, since that gate runs before checkout; unset, they default to this one's.

gh workflow run supervisor.yml -R cgwalters-forge/tracker \
  -f prompt="close what triage found done in agent-board"

With -f session=true (and optionally -f pool=openai, default claude) the agent runs as an interactive session: after its first turn it waits for the operator's prompts over the tailnet, for up to session.json's idleMinutes each, and its supervisor-actions comment goes to the executor when the session ends, as for any run. A session is an explicit request, in supervisor-agent, and needs TAILNET_DOMAIN and session.json enabled. A step posts its wss:// endpoint on session.json's issue (#728) as session.yml's runs have it; the review site's chat pane reads only the workflows its configuration lists, so far session.yml. [session] operators and origins are hosted.toml's, copied into supervisor.toml.

A check that never clears fails on every pass and so started an agent every cooldown hour to read the same report (#804). With agent.skipUnchangedFailures set to true (it ships false), agent-board supervise repeat leaves the trigger out of a pass that is not a sweep or request if every failing check also failed in the previous report; the sweep reads ongoing failures and their new evidence. A failure that first appeared while the trigger declined (cooldown, an active agent) also waits for a sweep.

Comments, prompts and the sweep share workflow-wide supervisor-agent concurrency without cancelling an active run, so a request waits through the previous executor instead of the trigger discarding it. The fifteen-minute health passes, prompt-less dispatches included, use supervisor-health: GitHub retains only one pending run per group and a newer arrival replaces it, so a shared group would let the next pass evict a queued prompt. A health pass that finds an agent active declines and retries after its cooldown; a prompt the trigger declines fails its run. The executor keeps its own supervisor-execute group. A second prompt queued behind a pending one still replaces it, so use the requests issue for durable requests and steering an active agent. The agent is a research run of the shared wrapper, using agent.pool and the wrapper's read-only job token, not the bot token. Its task includes the supervisor profile and skill of the agenthome repository and commit that agent.profile pins, agent-board's policy and this pass's health report. It also reads docs/operator-notes.md, the latest supervisor-health artifact's health.json and the configured state issue. Its isolated runner config sets session.watch-item = true: later comments arrive as attributed data, and only the configured operator's comments are instructions. Its one comment on the requests issue carries a supervisor-actions block of typed requests.

agent.state names the locked state issue #718, distinct from the requests and log issues. replace_state edits only that issue's body, within its daily cap below. The body persists and every later run reads it first, so a misled run can plant text for later runs; it is data to them, but with the other caps above zero a later run can act on it within those caps. A batch that would exceed a daily cap is rejected in full. Missing state is reported, never guessed.

The execute job has CGWALTERS_BOT_PAT in the agent-apply environment and does not run agent code. It executes only on a run's first attempt, and accepts only the bot's comment, unedited, on the requests issue that this run's apply reports. It validates the whole batch with agent-board supervise execute. The shared executor admits dispatches, with fixed briefs and reasons, on open issues regardless of who wrote them, and an implement dispatch only under an open epic-labeled parent. The boundary against an injected request is the run's sandbox and the required pull request review, not collaborator-only input (agent-board#158). That review is a model's verdict (review.yml), and the pass merges an approved, green head, so an issue anyone writes can reach a merge with no human step; the caps bound how many runs it can spend. Trusted config names the permitted dispatch kinds, tracker and project, and the caps: maxDispatchesPerPass: 4 and maxDispatchesPerDay: 40, and the daily caps comment: 20, create_issue: 15, close: 10, remove_needs_human: 12, replace_state: 48 and status_update: 1. Only the operator raises caps after review. The executor records requests before starting them, stops at the first failed write, and logs the outcome without agent text. agent-board supervise trigger supplies the wrapper inputs through GITHUB_OUTPUT. In preview, the execute job lists the proposed comment without a bot token or calling the executor (which always writes its log). Only SUPERVISOR=apply runs agent-board supervise execute with the bot token. The hosted preview proof still requires an operator-enabled run: confirm it lists requests and applies none, then compare a week of preview against the local loop before enabling apply with small caps. The pacing, the repeat check, the task composition and the preview are agent-board's supervise due, repeat, compose and preview, tested there. CI installs the supervisor workflow's exact pin with just build-supervisor-agent-board, and just test-supervisor-config runs supervise trigger on empty health checks, without --daily, to validate the shipped settings and executor policy without API calls or writes.

The agent cannot read the private decisions document (its token reads only this repository), and the review site's last-run panel is cgwalters-forge/review's to build; both are left from #626.

The release train

.github/workflows/release-train.yml runs agent-board's release-train, at the commit it pins as AGENT_BOARD_REV, to cut agentic-job's releases and move the pins after them (#650), in the order the controller did by hand: the version bump PR, release.yml once it merges, the pin bump of the actions wrappers once the release is out, then the review.yml pin bumps of the callers once that merges. The repositories, files, threshold and labels are in .github/release-train/config.json. A release is due when at least threshold PRs have merged since the last release and it was intervalHours ago, or immediately when one of them is labelled P0; the bump is minor if one is labelled breaking, a patch otherwise. The train also follows releases cut outside it, whether manually or by anyone else (#723): when the wrappers pin an older version than the latest release, a pass opens a train for that release starting at the wrappers' pin bump, unless a train for it was closed or its tag is not on agentic-job's default branch. The PRs come from the bot's forks with the release notes for the callers' interface changes, and go through each repository's review and queue; the train only waits for them.

It is off unless the repository variable RELEASE_TRAIN is dry-run, which prints each pass's step, or apply, which executes it with CGWALTERS_BOT_PAT: that token needs to open issues here, push to the bot's forks (named in the configuration: a fork does not have to share its parent's name) with the workflows permission, as the pins are in workflow files, open PRs upstream and run agentic-job's release.yml. Each release has one tracking issue here, opened by the bot and labelled release-train, with a comment per step. A step it cannot take (a PR closed unmerged, a failed release.yml, a file whose pin it cannot find) labels the issue needs-human, which halts the train until the label is removed; closing the issue drops that release: a later train for the same version ignores its closed PRs, halts on one still open, and does not start while main has a version bump that was never released. agent-board release-train --config .github/release-train/config.json is a dry pass with the token in GH_TOKEN; its tests are agent-board's.

The agent-board pin

Every workflow that installs agent-board pins the same commit as AGENT_BOARD_REV; just agent-board-pin, part of just test in CI, fails when they differ. .github/workflows/agent-board-pin.yml runs just bump-agent-board. The pass starts it when agent-board's main differs from the pin and has no pin PR yet; it also runs hourly as a fallback. When agent-board's main is ahead of the pin, all its check runs passed and its published binary passes the shared installer's verification, it opens or updates one pull request from the bot's fork (branch agent-board-pin) moving every pin to it and listing the commits in between. The review and the pass handle it like any bot PR. It is off unless the repository variable AGENT_BOARD_PIN is enabled, and uses CGWALTERS_BOT_PAT, which needs the workflows permission on the fork.

just build-agent-board retains its historical name and installs into $RUNNER_TEMP/agent-board/bin/agent-board, emitting rev to GITHUB_OUTPUT. It requires a full commit argument (or AGENT_BOARD_REV), never a moving branch. On Linux x86_64 it downloads build-<commit>'s static musl binaries, manifest, checksums and provenance. It verifies the manifest's attestation against agent-board's CI on main and the pinned source digest without a token, then checks the manifest identity and both binary digests before installation. This prevents substituted assets from running with the bot's write token. Downloads and attestation verification each have a 180-second limit. Missing assets, unsupported platforms and failed verification stop the job; there is no compilation fallback. Only the download step receives the ordinary job token; job permissions and mutation gates are unchanged. The exception is just bump-agent-board: its nested install inherits GH_TOKEN and downloads with the bot's token, CGWALTERS_BOT_PAT, though verification still runs without one. Fixture tests cover these failures and refuse bump selection without a verified binary. They also run the real gh attestation verify, offline, on a published release's manifest and bundle and Sigstore's trusted root, committed under .github/agent-board-install/: it accepts that commit and rejects another commit, a changed manifest and another signing workflow.

Weekly runs

Two scheduled workflows start a run of dispatch.yml as the pass does, with the job token and actions: write. weekly-eval.yml, on Tuesdays, does only that: it starts a research run that re-evaluates our tools against gh-aw and the like and comments on #519.

The separate monthly review refresh runs on the first of the month at 08:00 UTC, or manually, with the same fixed implement task. It is off by default: repository variable REVIEW_REFRESH must be enabled, and both entries require the default branch. Leave it unset until reviewed artifact pins, complete retained snapshots, frozen component protocols and unused isolated evaluation samples exist. It only dispatches; the task checks prerequisites again and returns unfinished/no-update when they are missing. Updates to code, architecture and prose go through one draft PR; activation through reviewed release-train pins remains separate. See the corpus prerequisites.

weekly-blog.yml, on Sundays, runs agent-board's digest with .github/weekly-digest.json for this deployment's templates and budgets. It gathers the week's material for the weekly notes on the organization site (cgwalters-forge/cgwalters-forge.github.io, /blog/): agent-board changes --public-only (the status updates are copied whole: they are public because the project is) from the Sunday before at 18:00 UTC to this one (--until), trimmed to a fixed 26,000 characters with --max-chars, then releases published in that window in the public repositories in the board configuration's follow list (tag, name, URL and publication time), then the project's status updates, oldest first. Release listings are capped at ten pages of 100 per repository; an incomplete listing fails the run. The release section gets at most 10,000 bytes, with an omission count if needed, within the existing 56,000-byte body budget. It files that, after a short brief, as the issue Weekly notes: week ending YYYY-MM-DD in the site repository, adds it to the board at P0 and starts an implement run on it that writes the post, content/blog/YYYY-MM-DD.md, and opens a pull request that closes the issue. The issue and the board item are written with CGWALTERS_BOT_PAT, at the agent-board commit the workflow pins. The status updates get the rest of GitHub's body limit, without their HTML comments; the oldest are left out first, and the body says so. A run before the week ends is refused, unless started with partial=true, which files the material available so far and says so; that is then the week's material, as a later run reuses the issue. A re-run reuses the week's issue, the latest Sunday's, as it was filed; once it is closed, or while a pull request that closes it is open or a run for it is queued or running, nothing more is started. The schedule is off unless the repository variable WEEKLY_BLOG is enabled; gh workflow run weekly-blog.yml runs it at once. The site repository has no review workflow yet, so the operator's approval is what lets the pass merge the post.