What
cmd/ailang/help.go:37-53 decides staleness by walking four CWD-relative directories
(internal/parser, internal/elaborate, internal/eval, cmd/ailang) and warning if any
.go file's ModTime is after the binary's mtime.
A freshly created git worktree writes every tracked file with a current mtime. So the warning
fires on a binary that is byte-identical to the worktree's own HEAD, built minutes earlier.
Why it matters
Every mission sub-agent (design-doc-creator, sprint-planner, sprint-executor) runs inside a fresh
worktree, so every one of them sees this warning on a correct binary. It is not cosmetic: in
mission iteration 190 a design-quorum reviewer rejected a design document on the grounds that its
behavioural premises "were measured with a PATH binary that explicitly warned it was stale". That
cost a full quorum round (~$0.04 plus a designer revision pass) to refute.
Measured (v0.33.0-184-gfd01a37c1)
- Binary mtime
07:02:33; worktree internal/parser/parser_expr.go mtime 07:04:25 → warns.
- The same binary run from the non-worktree checkout (source mtime yesterday) → no warning.
- Command-scoped:
ailang --version never emits it; ailang check does.
- Content identity, proven by differential rather than assertion: a binary built from the
worktree and the PATH binary produce byte-identical output on 10/10 fixtures (only the two
warning lines differ).
- Negative control — the differential is sensitive: against a
HEAD~40 build (0a84f5377,
v0.33.0-141) it detects a difference (1/10 fixtures, plus --version).
Suggested fix
Compare content, not mtime. The binary already embeds its commit via
-X …version.Commit, so the cheap and correct check is that value against git rev-parse HEAD
(plus a dirty-tree check), which is both accurate and immune to worktree creation. Failing that,
scope the walk to the repo the binary was built from rather than the process CWD, or drop the
warning from non-interactive/--format agent output.
Found by mission-control iteration 190 while designing #539.
What
cmd/ailang/help.go:37-53decides staleness by walking four CWD-relative directories(
internal/parser,internal/elaborate,internal/eval,cmd/ailang) and warning if any.gofile'sModTimeis after the binary's mtime.A freshly created
git worktreewrites every tracked file with a current mtime. So the warningfires on a binary that is byte-identical to the worktree's own HEAD, built minutes earlier.
Why it matters
Every mission sub-agent (design-doc-creator, sprint-planner, sprint-executor) runs inside a fresh
worktree, so every one of them sees this warning on a correct binary. It is not cosmetic: in
mission iteration 190 a design-quorum reviewer rejected a design document on the grounds that its
behavioural premises "were measured with a PATH binary that explicitly warned it was stale". That
cost a full quorum round (~$0.04 plus a designer revision pass) to refute.
Measured (v0.33.0-184-gfd01a37c1)
07:02:33; worktreeinternal/parser/parser_expr.gomtime07:04:25→ warns.ailang --versionnever emits it;ailang checkdoes.worktree and the PATH binary produce byte-identical output on 10/10 fixtures (only the two
warning lines differ).
HEAD~40build (0a84f5377,v0.33.0-141) it detects a difference (1/10 fixtures, plus--version).Suggested fix
Compare content, not mtime. The binary already embeds its commit via
-X …version.Commit, so the cheap and correct check is that value againstgit rev-parse HEAD(plus a dirty-tree check), which is both accurate and immune to worktree creation. Failing that,
scope the walk to the repo the binary was built from rather than the process CWD, or drop the
warning from non-interactive/
--format agentoutput.Found by mission-control iteration 190 while designing #539.