Doctor checks

foreman doctor checks that this computer and this project are ready to run Foreman. It runs every check, none stops the others, and prints one line each: ok, warn or FAIL, the check’s name, then its detail when it has one. Under each warn and FAIL line comes a fix: line with what to do and, in brackets, the Set up step that fixes it (“dashboard: Set up › Project keys”). It exits 1 when any check failed; warnings alone exit 0. No line ever holds a key’s value, a token or a username: the checks read variable names only. Run it first whenever something is wrong, and paste its output when you ask for help (see Getting help). This page lists every check in the order the groups run, with the fix hint the code prints, in our words.

The Set up tab runs the same checks. Each step has a Test it button that runs that step’s own checks in the background, plus any check whose last result counted against the step (the env variables check runs under Project keys, but a missing RESEND_API_KEY counts against Notifications). Opening the tab runs nothing; each step shows the last result of its checks and how long ago it was tested, from setup-checks.json in the state folder. Checks that take over 15 minutes are stopped, and foreman doctor in a terminal then shows which one hangs. A warning shows on a step but never stops it being done.

foreman doctor --end-strays runs no check. It ends the Foreman processes that are not this run’s, the ones the stray processes line counts, prints “Ending …” with their pids, then “Ended N.” and any “Still running: pid …”, and exits 1 when some are left. With none it prints “No stray processes.” It refuses inside a story session, so a slot never ends another slot’s tests, and when ps fails it ends nothing and exits 1.

Which checks run depends on the config: with no foreman.config.json only the config and Claude checks run; the Jira group runs with stories.adapter: "jira"; the Salesforce group with pack: "salesforce"; the Cloud runner checks only when their files are there. The Salesforce pack is a preview: its release paths pass their own tests, but no story has yet shipped through them on a live org, and the Gearset path has not run against a live Gearset pipeline.

Project and tools

These belong to the Set up steps This project, GitHub and Tools and checks.

Check	What it looks at	ok / warn / FAIL	How to fix it
config	foreman.config.json loads, passes every rule in foreman.config.json, and every trait file the roles name can be read.	FAIL with each problem as path: message; “the config could not be loaded” when nothing else explains it.	Fix what it names in foreman.config.json. Step: This project.
local settings	Each local setting in .foreman/settings.json that Foreman ignored because it is invalid or does not apply to this project. One line per ignored value.	ok when none; warn per ignored value.	Change or remove that setting with foreman settings. Step: This project.
git remote	git remote get-url <remote> works for the remote in the config (origin by default).	FAIL “git has no remote named origin”.	git remote add origin <url>. Step: GitHub.
gh signed in	gh auth status succeeds.	FAIL.	gh auth login. Step: GitHub.
check: <run>	One check per entry in checks whose when is always: the command runs through sh -c and exits 0.	FAIL “exited N”.	Run the command and make it pass. Step: Tools and checks.
merged code tested	Which release step tests the code merged with the base branch: a ship step marked as testing merged code (ci), else merge-main running the checks when the base brought in new commits.	ok naming the step; warn “no CI step and no checks: code merged at release is not tested”.	Add checks to the config, or a ci step to ship.steps. Step: This project.
role agents	Every agent the roles name exists: a foreman:<name> agent must be in Foreman’s agents/ folder, a plain name in the project’s .claude/agents/, or in ~/.claude/agents/ only when session.userSettings is true. Agents of other plugins are not checked.	warn, never FAIL, naming each missing one; a missing builder adds that the architect can still pick it and its build fails.	Point that role’s agent at one that exists, or remove it from roles. Step: This project.
pack <name>	Only with pack set: the pack loads and its own checks can be built.	FAIL with the pack’s message.	Fix pack in the config, or update Foreman. Step: This project.
pack <name> env adapters	A pack env adapter that reuses a core adapter’s name (none, docker, supabase).	FAIL.	Update Foreman or the pack. Step: This project.
tools	Every tool the configured notifier, env adapter, ship steps and pack say they need is on PATH (command -v).	FAIL “not on PATH: …”	Install them, then open a new terminal. Step: Tools and checks.
docker compose	Only with env.adapter: "docker": docker compose version works.	FAIL.	Install Docker with its compose plugin. Step: Tools and checks.
branch protection	gh api can read the protection of the base branch.	ok when protected; warn “branch protection is off”, warn when the repository’s GitHub plan does not offer it (a private repo on the free plan), warn when gh could not check.	Turn protection on for the base branch, upgrade the plan or make the repository public, or check gh can read the repository. Step: GitHub. See Release safety.
vercel story previews	Only when vercel.json exists or ship.deploy-github.statusContext is vercel: vercel.json turns off deployments for story/* branches (git.deploymentEnabled), so each story does not spend a preview and a production deployment.	warn when the file is missing, unreadable or does not turn previews off.	Add {"git":{"deploymentEnabled":{"story/*":false}}} to vercel.json. Step: Tools and checks. See Deploy targets.
background service	Whether the run is installed as a service (launchd on macOS, systemd on Linux), whether the Node it starts is still there and starts, whether it runs this copy of Foreman, and whether it is running.	ok “no service manager on this computer”, “runs as a service”, or “installed, stopped with foreman stop”; warn when not installed, when its Node is gone or does not start (a Homebrew upgrade is the likely cause), when it runs Foreman from another copy, or when it is installed but not running.	foreman service install (again after a Node upgrade); brew reinstall node when Node does not start; foreman run or read the service log when it is not running. Step: Tools and checks. See Run, pause, stop.
macOS privacy prompts	macOS only, with the service installed.	Always ok, with a note: launchd starts the run, so macOS asks on behalf of node when something reaches a private folder; Foreman never needs one, so answer Don’t Allow.	Nothing. Step: Tools and checks.
stray processes	Foreman supervisors, hook runs and foreman learn or notify runs that are not this run’s, over 10 minutes old, in temp folders or this project’s folders. Tests and manual checks leave them, and they slow the run.	ok when none, or when ps cannot run; warn with their count and memory.	foreman doctor --end-strays. Step: Tools and checks.
machine load	While a run is going: the 1-minute load against the cores.	ok “no run going” or “load X on N cores”; warn when the load is over twice the cores, naming the five busiest processes. Never FAIL.	Run fewer stories at once with foreman workers <n>, or end what else is busy. Step: Tools and checks.
story sessions	Whether one slot folder has two story sessions running: both edit the same worktree and both are paid for.	ok, or “could not list the running processes”; warn naming the slot, the stories and the pids.	kill <pid> for each session but the oldest, as the line says. Step: Tools and checks.
last interrupt	The record the supervisor writes when a signal stops the run, kept 7 days.	ok, naming the time, for a plain interrupt (Ctrl-C, kill or a closed terminal); warn when a story session’s agent had just run a kill command, naming the story, the slot and the command.	Start again with foreman run, and report that command: a story session must never stop the run. Step: Tools and checks. See When things go wrong.

Claude

These belong to the Set up steps Claude Code and Claude sign-in.

Check	What it looks at	ok / warn / FAIL	How to fix it
claude on PATH	claude --version works.	FAIL.	Install Claude Code, then open a new terminal. Step: Claude Code. See Install.
claude sign-in	Which sign-in the story sessions will use, in Claude Code’s own order: a cloud provider (CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, CLAUDE_CODE_USE_FOUNDRY), then ANTHROPIC_AUTH_TOKEN, then ANTHROPIC_API_KEY, then CLAUDE_CODE_OAUTH_TOKEN, then the login on this computer from claude auth status. The two Claude names in .env.foreman count where the environment lacks them. After the credits ran out or the key hit its usage limit and sessions moved to the subscription, it leaves the key out and says since when, and when access returns if Claude Code said.	ok for a cloud provider, a gateway token or a Console API key (“per-token billing”); warn for a subscription token or a claude.ai login, which count against your plan’s limits and are for your own projects only; warn when claude auth status could not be read; FAIL “no Claude sign-in”.	Set ANTHROPIC_API_KEY, or CLAUDE_CODE_OAUTH_TOKEN from claude setup-token, or run claude auth login; use a Console API key if you sell Foreman or run it for others. foreman claude use-key goes back to the key. Step: Claude sign-in.
plugin installed and enabled	claude plugin list shows the foreman plugin, enabled.	warn when the list cannot be read; FAIL when not installed or installed but disabled.	Install the plugin, or turn it on with claude plugin enable. Step: Claude Code.
plugin fresh	The installed plugin is the code this copy runs: same version as the source, not an older cached copy, and not another installed copy the sessions would load instead.	ok; warn with the versions when they differ, when the installed copy is older than the source’s last commit, when another copy is installed, or when freshness cannot be read.	claude plugin update, or reinstall. Step: Claude Code.
review engine <name>	One per reviewer engine in roles.reviewers[].engine (antigravity): its CLI answers --version.	warn: reviews with that engine fall back to the Claude reviewer.	Install the engine’s CLI and sign in, then open a new terminal. Step: Claude Code. See Agents and traits.
story session scope	What story sessions load: every server in session.mcpServers is defined in the project’s .mcp.json; every mcp__<server>__ tool in session.extraTools names a server the sessions load.	FAIL when .mcp.json cannot be read or a named server is missing (saying when it exists only in your user-level ~/.claude.json); warn when an extra tool names a server the sessions do not load; ok saying that sessions leave out your user-level CLAUDE.md, memory, hooks, skills, agents and plugins unless session.userSettings is true.	Add the server to .mcp.json, or name it in session.mcpServers. Step: Claude Code. See Story sessions.
agent models	The newest run record of the last 7 days that recorded its agents: did each agent run on the model family its role is set to?	ok; warn naming the story, when it ended and each mismatch. Only the newest session decides, so it clears once a later one runs right.	foreman settings list --group models, and make sure plugin fresh is ok. Step: Claude Code. See Settings and switches.
workflows	Nothing it can test.	Always warn: Claude Code workflows need a paid plan or the API; on Pro, turn them on in /config.	On Pro, turn workflows on in /config in Claude Code. Step: Claude Code.

Keys

These belong to the Project keys step, or to the step that owns the missing key. Foreman’s own keys live in foremanEnvFile (.env.foreman by default), which no slot gets; the project’s keys live in envFile (.env.local), which every slot links. See Files Foreman writes.

Check	What it looks at	ok / warn / FAIL	How to fix it
foreman keys file	Git ignores .env.foreman, and only its owner can read it. When git does not ignore it, the doctor adds the .gitignore line itself (inside a story session it only warns).	ok, “added .env.foreman to .gitignore” when it did; warn when git could not be asked, when the line could not be added, or when the file’s mode lets other users read it.	chmod 600 .env.foreman; add it to .gitignore. Step: Project keys.
foreman keys placement	Any of Foreman’s own keys still in the project env file, where agents can read it.	warn naming them.	foreman keys migrate from the project’s folder. Step: Project keys.
env variables	Every variable the configured notifier, env adapter, ship steps and pack need (RESEND_API_KEY and RESEND_FROM_EMAIL for the email notifier, for instance) is set in the env file, in .env.foreman or in the environment. Names only.	ok when nothing is needed or all are set; FAIL “missing: …” saying which file each belongs in.	Add each name to the file it names, or to the environment. Step: the one that owns the first missing key (Notifications for the Resend keys, Jira app for the Jira ones, Gearset for GEARSET_API_TOKEN, Claude sign-in for the Claude ones), else Project keys.

Jira

Only with stories.adapter: "jira". Each Jira call gets 20 seconds, so an unreachable site cannot hang the doctor. See Stories from Jira.

Check	What it looks at	ok / warn / FAIL	How to fix it
jira options	The stories block passes the Jira adapter’s own check. When it fails, no other Jira check runs.	FAIL with the adapter’s message.	Fix the stories block. Step: Jira site and filter.
jira signed in	The token file for stories.site (~/.config/foreman/jira-<site>.json) holds an access and a refresh token.	ok “<site> as <name>”; FAIL “not signed in”.	foreman jira login. Step: Jira sign-in.
jira sign-in age	How long ago the refresh token was renewed, from the file’s savedAt or its time. Atlassian ends a sign-in left unused for 90 days.	ok “renewed N days ago” under 80 days; warn at 80 days or more, or when the age cannot be told; warn “skipped: not signed in”.	Renew with foreman jira login. Step: Jira sign-in.
jira JQL	stories.jql runs (a search for one issue), with the approximate count.	ok “runs (about N issues)”; FAIL when the JQL fails, when Jira cannot be reached, or when the sign-in expired; warn “skipped: not signed in”.	Fix stories.jql so it runs in Jira; check stories.site and the network; sign in again. Step: Jira site and filter.
jira transitions	Only when stories.transitions has names: each is a transition offered by one issue the JQL finds, by transition name or the status it leads to, or a status of that issue’s project, in any case.	ok; warn naming the names not found from that issue (a move open only from another status cannot be seen from here); warn “skipped” when the JQL did not run or found no issue. Never FAIL.	Check the names against your Jira workflow. Step: Jira site and filter.
jira app keys	JIRA_CLIENT_ID and JIRA_CLIENT_SECRET are in the environment, .env.foreman or the env file.	FAIL “missing: …”	Add them to .env.foreman. Step: Jira app.

Cloud

Two sets of checks. The first runs on your own computer as part of foreman doctor, under the Cloud runner step, and only when its files exist. The second is foreman cloud doctor, run on the runner (or wherever foreman cloud run will run) to say whether that machine is ready to run unattended. See Run in the cloud and Cloud doctor.

On your computer

Check	What it looks at	ok / warn / FAIL	How to fix it
cloud workflow	Only when .github/workflows/foreman.yml exists: state.store is branch, which the workflow needs, and the file is exactly what this Foreman writes for this config.	FAIL when the state is not on a branch; warn when the file is from another Foreman version or was changed by hand, or cannot be read.	Keep the run state on a branch, and rewrite the workflow, from Set up › Cloud runner. See Run state on a branch.
cloud secrets	Only with the workflow: GitHub has every secret the workflow reads (the token, one Claude sign-in, and the project’s keys), asked with gh secret list.	FAIL “not set on <repo>: …”; warn when git has no GitHub remote or gh cannot list.	Set the secrets from Set up › Cloud runner; check gh is signed in.
cloud runner file	Only when .env.runner exists (or is a link, even a dangling one): it is a plain file, git ignores it and does not track it, and only its owner can read it.	FAIL when it is a link, not ignored, or tracked; warn when other users can read it.	Replace it with a plain file; add it to .gitignore from Set up › Cloud runner; git rm --cached .env.runner; chmod 600 .env.runner.

On the runner: foreman cloud doctor

It prints the same ok, warn and FAIL lines, without a fix: line, and exits 1 when any failed. The runner checks run first; then, when a foreman.config.json is found here or in the runner’s clone, the project checks. The Set up tab’s Cloud runner step runs the five runner checks that are safe on your own computer (FOREMAN_REPO, GH_TOKEN, github token, pull request checks, dashboard token); not claude sign-in, which would find your local login, not claude answers, which spends tokens, and not plugin or work folder, which are the runner’s.

Check	What it looks at	ok / warn / FAIL	How to fix it
FOREMAN_REPO	Set as owner/name.	FAIL.	Set FOREMAN_REPO to the project repository.
GH_TOKEN	Set.	FAIL.	Set GH_TOKEN to a GitHub token for the project repository.
claude sign-in	The same sign-in order as the local check, from the runner’s environment.	As above.	Give the runner a Console API key or a subscription token.
github token	The token works (gh api user), can read FOREMAN_REPO and can push to it.	FAIL with the reason, secrets blanked.	Use a token with push access to the repository.
pull request checks	The token can list the repository’s pull requests and read the newest one’s checks the way the ci ship step does.	ok, or ok noting it reads through Actions and commit statuses only, so checks other apps post are not seen; warn when the repository has no pull request yet; FAIL when it cannot list or read, saying a fine-grained token needs Pull requests, Actions and Commit statuses read.	Widen the token’s permissions.
claude answers	claude -p "Reply with the word ok." answers within 120 seconds.	FAIL with what it said.	Fix the sign-in; check the network.
plugin	FOREMAN_PLUGIN_DIR holds a Foreman plugin of the same version as this command.	FAIL.	Set FOREMAN_PLUGIN_DIR, or match the versions.
work folder	The runner can write in FOREMAN_WORK (/work by default).	FAIL with the error code.	Mount a volume there that the foreman user can write.
dashboard token	When FOREMAN_DASHBOARD_HOST is beyond loopback, FOREMAN_DASHBOARD_TOKEN is set.	ok on loopback; FAIL.	Set FOREMAN_DASHBOARD_TOKEN.
docker socket	Project check, with env.adapter docker or supabase: /var/run/docker.sock exists.	FAIL.	Mount it with -v /var/run/docker.sock:/var/run/docker.sock.
state branch	Project check, with state.store: "branch": the branch can be fetched from the remote and a dry-run push succeeds.	FAIL.	Give the token push access; check the remote.
salesforce tools	Project check, with pack: "salesforce": the same tools check as the Salesforce group.	FAIL, adding to use the Salesforce variant of the Foreman runner image or build with --build-arg SALESFORCE=1.	Use that image.
python	With the pack: python3 is on PATH at 3.10 or later.	FAIL.	Use the Salesforce runner image.
java	With the pack: java is on PATH at 11 or later.	FAIL.	Use the Salesforce runner image.

Salesforce

Only with pack: "salesforce". The pack is a preview: its release paths pass their own tests, but no story has yet shipped through them on a live org, and the Gearset path has not run against a live Gearset pipeline. These checks run sf in the isolated sf home the sessions use (~/.config/foreman/sf-home, or FOREMAN_SF_HOME), so they test the logins the sessions will see; only the tools and telemetry checks run it as you. Each org is queried once per doctor run, and an org that refused logins is left alone until its cool-down ends. A detail names aliases, org IDs, branches, versions and test names, never a username or a value. See Salesforce set-up, Salesforce config and Build orgs.

Check	What it looks at	ok / warn / FAIL	How to fix it
salesforce tools	sf plugins --core: @salesforce/cli at 2.0.0 or later, sfdx-git-delta at 6.0.0, @salesforce/plugin-code-analyzer at 5.0.0; @salesforce/plugin-agent unless salesforce.agentforce is off.	ok with the CLI version; FAIL when sf is missing or a plugin is missing or too old; warn when the agent plugin is missing.	Install or update the Salesforce CLI and the plugins it names, or set salesforce.agentforce to off. Step: Salesforce CLI.
salesforce layout	Where each step runs, from the config alone (no sf, no git): the build orgs (or the Dev Hub in scratch mode), the test org, each stage’s org and branch, the slots, each stage org that is also a build org (“shared”), and each production org (“connected; deployments blocked, data changes not blocked”).	Always ok, as one line.	Fix the salesforce block if the line is not what you meant. Step: Salesforce environments.
salesforce org build	Scratch mode only.	Always warn: build orgs are made per story and not checked here.	Nothing. Step: Salesforce org sign-in.
salesforce org <alias> (<roles>)	Each org once: the build orgs, each stage’s, the org the Cases come from (“stories”), then the rest of salesforce.orgs (“not used”). It is in salesforce.orgs, signed in to the isolated home, a sandbox (or, marked "production": true, a production org), and the org ID the config names. An alias the home maps to an org outside salesforce.orgs fails without any query.	ok “sandbox <id>” or “production (connected; deployments blocked)”; FAIL when not in salesforce.orgs, not signed in (with the sf org login jwt command to run), not a sandbox, the wrong org ID, marked production but a sandbox, or cooling down (up to an hour); warn when it cannot be reached.	Sign the org in to Foreman’s sf home; fix the alias or org ID in salesforce.orgs; point it at a sandbox. Step: Salesforce org sign-in.
salesforce sf isolation	The isolated sf home exists and holds only orgs in salesforce.orgs, each a sandbox or a marked production org, plus in scratch mode the story scratch orgs the state folder records, which the Dev Hub must list as active.	ok with the home’s path; warn when the home does not exist yet; FAIL naming any org it holds that is not allowed, with the sf org logout command for each, or when sf is missing or FOREMAN_SF_HOME is not absolute.	Sign out the extra orgs there; keep only the sandboxes in salesforce.orgs. Step: Salesforce org sign-in.
salesforce plugin	Whether the salesforce-development Claude Code plugin is enabled for you.	ok; warn: Foreman turns it off for its own runs.	Nothing. Step: Salesforce CLI.
salesforce source tracking <alias>	Each build sandbox: SourceMember can be queried, so source tracking is on. Stage-only orgs are not checked.	FAIL when tracking is off; warn when it could not be checked, or skipped when the org check failed.	Turn on source tracking for Developer sandboxes in the production org’s Dev Hub settings, then refresh the sandbox. Step: Salesforce org sign-in.
salesforce stories options	Only with stories.adapter: "salesforce": the stories options pass the Cases source’s own check, and stories.org is in salesforce.orgs and not a production org. When it fails, the next two fail with “skipped: fix the stories options first”.	ok “Cases in <org>”; FAIL.	Fix the stories block, and the stories org in salesforce.orgs. Step: Salesforce org sign-in. See Stories from Salesforce.
salesforce stories filter	stories.where, or the SOQL behind stories.listView, runs in the stories org.	ok “finds N Cases” (Foreman reads the first 200); FAIL when the org refuses it or the list view cannot be read; warn “skipped” when the org check failed.	Fix stories.where or the list view so it runs there. Step: Salesforce org sign-in.
salesforce stories statuses	Every stories.statuses value is an active Case Status (a near match in another case is named), and doneWhenField, dependsOnField and ownerField are fields of Case, from one sf sobject describe.	ok, or “none set”; FAIL naming each problem.	Use a Status that Case has and is active, and fields that exist on Case. Step: Salesforce org sign-in.
salesforce baseline <alias> (<roles>)	Each org with a role: what already fails there before any story. The first run starts the org’s local tests without waiting and saves the run; later runs read it until it ends, then reuse the result until foreman sf baseline --refresh.	ok “no failing tests, N% Apex coverage, recorded <date>”; warn while the tests run or were just started, when aborted, when a stage org has failing tests or coverage under 75% (RunLocalTests deploys there cannot pass), or when a build-only org has failing tests (the tester reports them as inherited).	Fix the org or salesforce.testLevel, then foreman sf baseline --refresh; run the doctor again when the tests finish. Step: Salesforce org sign-in.
salesforce agentforce	Unless salesforce.agentforce is off: each org with a role has Agentforce (GenAiPlannerDefinition can be queried) and an active Data Cloud permission set licence. When one lacks either, it turns Agentforce off with the reason, so releases refuse agent bundles; when all have both, it turns it back on.	ok “off in foreman.config.json” or “on in <orgs>”; warn “Agentforce is off: …” or when an org was skipped or a query failed.	Turn on Agentforce and Data Cloud in that org, then run the doctor again. Step: Salesforce org sign-in. See Agentforce and OmniStudio.
salesforce test level	From the saved baselines only: testLevel.deploy (release sf, each stage’s org) or testLevel.validate (stage 1’s org) is RunLocalTests or RunAllTestsInOrg on an org whose baseline cannot pass it.	ok, or “no baseline yet for <orgs>”; warn naming each.	Set it to RunRelevantTests, or fix the org. Step: Salesforce environments.
salesforce production branch	salesforce.productionBranch is a branch name, is on the remote, and neither the pull request target nor any stage’s own branch merges into it. Unset passes as “none set” unless a stage has its own branch or release is gearset.	ok; FAIL when unset but needed, not a branch name, or a merge target; warn when not on the remote or the remote could not be checked.	Fix salesforce.productionBranch. Step: Salesforce environments. See Production stays yours.
salesforce gearset token	Release gearset only: GEARSET_API_TOKEN is set in the environment, .env.foreman or the env file.	FAIL.	Create a Gearset API access token (My account, Team security, Access token management) and add it to .env.foreman. Step: Gearset.
salesforce gearset branch	Release gearset only: ship.merge.keepBranch is true, as Gearset needs the story branch until the last stage.	FAIL.	Turn on ship.merge.keepBranch. Step: Gearset.
salesforce gearset merge method	Release gearset only: ship.pr.mergeMethod is merge; Gearset supports merge commits only.	FAIL.	Set ship.pr.mergeMethod to merge. Step: Gearset.
salesforce gearset environments	Release gearset only: each stage’s org is the target of a Gearset environment that is not production, through the Gearset Reporting API, in the pipeline salesforce.gearset.pipelineId names or in every pipeline.	ok “stage <name> → Gearset <environment>”; FAIL naming the stage; warn “skipped” without the token, or on a rate limit or no answer.	Make each stage org a Gearset environment that is not production. Step: Gearset.
salesforce gearset ci job	Release gearset only: each stage’s Gearset environment has a CI job that is turned on.	FAIL naming the stage; warn when skipped or on a rate limit.	Turn on the CI job of each stage’s environment in Gearset. Step: Gearset.
salesforce gearset ci tests	Release gearset only: Gearset’s newest successful deploy to each stage in the last 30 days ran Apex tests, read from the Reporting API and the deploy’s DeployRequest in the stage’s org.	ok with the test counts, or “no Gearset deploy in the last 30 days”; warn when a deploy ran no tests (only sf-validate then tests the change before each merge), or when it could not be read. Never FAIL.	Set a test level on each Gearset CI job. Step: Gearset.
salesforce workflows	Every .github/workflows file that runs on push to the pull request target or a stage branch: no sf or sfdx deploy in it targets an org outside salesforce.orgs, a marked production org, or a target it cannot read (a secret, a variable, a command). Reads files only.	ok; FAIL naming the file and the branch, never an alias or a secret’s name.	Make the workflow deploy only to orgs in salesforce.orgs. Step: Salesforce environments.
salesforce skills lock	skills-lock.json pins skills from salesforce.skills.source at salesforce.skills.tag, each installed in .agents/skills, linked from .claude/skills and unchanged since install.	ok “N skills from <source>”; warn when there is no lock yet; FAIL when it lists no skills, skills from another source, another tag, a skill not installed, not linked or changed, or when the source holds a user name or token.	foreman sf skills; take any credentials out of salesforce.skills.source. Step: Salesforce skills. See foreman sf.
salesforce skills named	Every skill a Foreman agent in the roles names in its skills: frontmatter is in skills-lock.json.	ok “N named skills, all in skills-lock.json”, or “no pack agent names a skill”; FAIL naming the missing ones.	foreman sf skills. Step: Salesforce skills.
salesforce telemetry	The Salesforce CLI sends no telemetry: SF_DISABLE_TELEMETRY, DO_NOT_TRACK, or sf config get disable-telemetry.	ok; warn.	Set SF_DISABLE_TELEMETRY=true in the env file, or sf config set disable-telemetry true --global. Step: Salesforce CLI.
salesforce CONFIRM_PROD	Nothing confirms a production deploy for Foreman: CONFIRM_PROD is not in the environment or the env file, and no check’s run or quick command holds CONFIRM_PROD or --I-CONFIRM-PROD.	FAIL.	Remove it wherever it is set. Step: Salesforce environments.

Learning

Three checks on self-learning, ok or warn only, under the This project step. They print ids, skill names, tags and short commits, never a learned item’s text. See How Foreman learns.

Check	What it looks at	ok / warn / FAIL	How to fix it
learning	Whether learning is on (learning.auto, learning.apply), the items in force and on trial, and the rollbacks and refusals of the last 7 days, from learning.jsonl in the state folder.	ok “on; N active, M evaluating; last 7 days: R rolled back, F refused” (or “on, but the agents use none of it”, or “off”); warn when learning.jsonl cannot be read.	Check that learning.jsonl in the state folder is a readable file.
learning caps	Only with learning.auto on: each cap reached, in order: each role’s traits (learning.maxPerRole), learned skills (learning.maxSkills), on trial (learning.maxEvaluating), changes today (learning.maxPerDay), and the learner’s spend today against the daily cap in US dollars (learning.maxUsdPerDay). A cap of 0 counts as reached.	ok; warn “reached: …” with each count against its cap; warn when learner.jsonl cannot be read, so the spend is unknown.	Raise the limit with foreman settings (learning group), or foreman learning undo <id>.
learned skills and pack tags	Only when skills-lock.json lists a skill and a learned skill is in force: each learned skill whose version in force names a pack skill that moved to another tag or commit, or left the lock.	ok; warn naming each, with the tag or commit it was learned at and where the lock is now.	foreman learning show <id>, then foreman learning undo <id> if it no longer fits.