What the maintainer reports
Every worktree build runs the test suite first. That verification should be able to reuse a CI result for the same head, or a shared compilation cache, instead of paying a cold build each time.
What this appliance can confirm about the environment
There is no shared build cache. Reading the supervisor process environment directly (73 entries readable, so the read works):
CARGO_TARGET_DIR 0 occurrences
sccache not installed on this machine
Every git worktree is a separate checkout, so with no CARGO_TARGET_DIR each one compiles into its own <worktree>/target. Nothing is shared between a worktree and the checkout it came from, or between two worktrees of the same repository. Each verification is a cold Rust build by construction.
The CI plumbing already exists, one gate away. libraries/forge/merge/ci_gate.lua consumes libraries/forge/github/check_runs.lua, and libraries/devloop/ci_failure_keys.lua already keys a CI result to a head commit and a check digest:
local head, checks = value:match("^head:([^/]+)/checks:(.+)$")
if head == nil or not forge_validators.is_git_sha(head) then
return false
end
return checks:match("^digest%-%d%d%d%d%d%d%d%d%d%d$") ~= nilSo the system already knows how to say "these checks passed for this exact SHA". It uses that at the merge gate. Local worktree verification does not consult it.
FKST does not currently see the build at all. Across two full runs of three deployments, department child logs record zero cargo invocations, while git worktree appears (4 in packages, 7 in substrate). The build and test run inside the codex agent in the worktree, outside the EVENT=external_command record. That matters for the fix: FKST cannot cache or skip something it has no record of, so whichever lever is chosen has to be applied to the environment handed to the agent, not to a command FKST issues.
Not verified here
I did not measure the "runs the tests first, every time" claim or what a cold verification costs on this machine — the invocation is inside the agent and is not in FKST's logs. The environment facts above are measured; the workflow claim is the maintainer's and is recorded as theirs.
The two levers, and what distinguishes them
They are independent and not equivalent:
- Shared build cache (a
CARGO_TARGET_DIR per repository rather than per worktree, or sccache) makes the build cheap without changing what is verified. It is a pure speedup and changes no decision.
- Reusing a CI result skips the local run entirely when checks already passed for that head. It is faster but it changes what the appliance knows: CI ran a different environment against that SHA, and a worktree can hold uncommitted work whose head no longer describes the tree.
ci_failure_keys already binds a result to head:<sha>, which is exactly the check that would have to hold.
The first is safe to do unconditionally. The second needs the head-binding to be exact, and its failure mode is a green verification for a tree that was never tested.
What would close it
Verification of a worktree should not pay a cold compile when an equivalent result already exists — either as compiled artifacts from a sibling checkout of the same repository, or as a CI result bound to the same head. Which of the two, and whether both, is the platform owner's call.
What the maintainer reports
Every worktree build runs the test suite first. That verification should be able to reuse a CI result for the same head, or a shared compilation cache, instead of paying a cold build each time.
What this appliance can confirm about the environment
There is no shared build cache. Reading the supervisor process environment directly (73 entries readable, so the read works):
Every
git worktreeis a separate checkout, so with noCARGO_TARGET_DIReach one compiles into its own<worktree>/target. Nothing is shared between a worktree and the checkout it came from, or between two worktrees of the same repository. Each verification is a cold Rust build by construction.The CI plumbing already exists, one gate away.
libraries/forge/merge/ci_gate.luaconsumeslibraries/forge/github/check_runs.lua, andlibraries/devloop/ci_failure_keys.luaalready keys a CI result to a head commit and a check digest:So the system already knows how to say "these checks passed for this exact SHA". It uses that at the merge gate. Local worktree verification does not consult it.
FKST does not currently see the build at all. Across two full runs of three deployments, department child logs record zero
cargoinvocations, whilegit worktreeappears (4 inpackages, 7 insubstrate). The build and test run inside the codex agent in the worktree, outside theEVENT=external_commandrecord. That matters for the fix: FKST cannot cache or skip something it has no record of, so whichever lever is chosen has to be applied to the environment handed to the agent, not to a command FKST issues.Not verified here
I did not measure the "runs the tests first, every time" claim or what a cold verification costs on this machine — the invocation is inside the agent and is not in FKST's logs. The environment facts above are measured; the workflow claim is the maintainer's and is recorded as theirs.
The two levers, and what distinguishes them
They are independent and not equivalent:
CARGO_TARGET_DIRper repository rather than per worktree, or sccache) makes the build cheap without changing what is verified. It is a pure speedup and changes no decision.ci_failure_keysalready binds a result tohead:<sha>, which is exactly the check that would have to hold.The first is safe to do unconditionally. The second needs the head-binding to be exact, and its failure mode is a green verification for a tree that was never tested.
What would close it
Verification of a worktree should not pay a cold compile when an equivalent result already exists — either as compiled artifacts from a sibling checkout of the same repository, or as a CI result bound to the same head. Which of the two, and whether both, is the platform owner's call.