fix(agents): deliver the cycle directive on the default heartbeat path

[lilyshen0722]

Of 27 deployed moltbots, 9 have no cycle-reflection directive in their HEARTBEAT.md and 1 (theo) carries one naming commonly_write_agent_memory — a tool that writes the whole memory envelope and cannot append to cycles. Fleet counts from the gateway PVC by @ux-lead and @sprint-review; mechanism traced to source here.

Corrected twice after opening. Originally "10 silent, one fossil", then "8 silent + 2 wrong-tool", now 9 + 1. The middle reading mis-bucketed pixel-demo: its commonly_write_agent_memory at line 34 is the ## Commented / ## Pods maintenance step, not a cycles directive. Confirmed from source — it is character-for-character agentProvisionerServiceK8s.ts:125, Step 7 of the default template, and that template contains zero occurrences of "cycle". pixel-demo is running the raw default, which is exactly what this PR's diagnosis predicts for an unmatched agent.

The trailer was never wrong — its delivery was

withCyclesDirective is applied at exactly two sites, provision.ts:294 and reprovision.ts:137, both inside matchedPreset?.heartbeatTemplate ? {...}. The 35 preset ids are role names and the match is p.id === (explicitPresetId || normalizedInstanceId) — exact equality.

No affected agent matches:

aria · nova · pixel · theo · nova-demo · pixel-demo · newshound-aiyo   no match
backend-engineer-nova    → starts with preset id "backend-engineer"   no match
dev-pm-theo              → starts with preset id "dev-pm"             no match
devops-engineer-ops      → starts with preset id "devops-engineer"    no match

Three are named <preset-id>-<agent> — but that shape is resolveOpenClawAccountId's output, ${agentName}-${instanceId}, not a convention anyone chose. Their agentName happens to be a preset id (dev-pm, backend-engineer, devops-engineer) while the match runs against explicitPresetId || instanceId and never consults agentName, so the coincidence cannot help them, and nothing logs the miss.

Corrected 2026-08-04. An earlier revision of this line said installationConfig.presetId is unset for all 30 instanceIds. That path does not exist in the collection; config.presetId is set on 54 of 417 rows (@ux-lead). Installations are per-pod, so one agent holds many rows and they disagree with each other — theo has 6 active rows at dev-pm and 7 with none (@sprint-review). Where no row on an agent carries a preset, matching falls back to instanceId, which is never a preset id; those agents get the raw default template, which before this PR structurally could not carry the directive.

Two fixes — both required for every agent this path can reach, not one per population

An earlier revision of this description claimed each gate served a different subset. That was mechanically wrong:

1. "Missing the directive" counts as stale — the trigger. All 10 files lack the marker, so this is what makes any of them eligible for rewrite. The ten are not uniform below the marker, read off the PVC 2026-08-04: seven carry no cycle instruction at all; theo carries one naming commonly_write_agent_memory (line 36), a tool that cannot append to cycles; nova (lines 29, 41) and pixel (line 43) carry one that names no tool at all. A directive with no tool is not obviously better than none — it is the shape that sends an agent hunting, which is the failure feat(memory): inject ADR-012 cycle-reflection trailer into all heartbeat templates #295 was rolled back for. Previously the only triggers were two 2026-era marker strings, which none of the 10 carry.

Corrected 2026-08-04. An earlier revision concluded from that: "reprovision as it stands today repairs zero of them." That is wrong for any row carrying a presetId. reprovision.ts:137 sets forceOverwrite: Boolean(explicitPresetId); skipHeartbeat (agentProvisionerServiceK8s.ts:2563) is customizations.heartbeat === true && !heartbeat?.forceOverwrite, so force survives it; and the force branch at :506 writes unconditionally, consulting no marker. That branch has carried withCyclesDirective(matchedPreset.heartbeatTemplate) since #295 (2026-05-03). Chain traced by @sprint-review, re-verified here link by link including that dev-pm / backend-engineer / frontend-engineer each define a heartbeatTemplate, without which the block never fires.

What that repairs on the current fleet is not established. PVC mtimes read 2026-08-04: theo 2026-08-02, nova 2026-07-30, pixel 2026-07-09 — all written well after 2026-05-03, and none carries the marker. Whatever last wrote those three was not the force path, so "a reprovision fixes them today" does not follow from the chain being live. Of the ten, only dev-pm-theo and devops-engineer-ops (both 2026-05-04 00:57) sit where the force path would explain them — inside the #295→#296 window when withCyclesDirective was rolled back to a no-op — and both are row-less now. That is a reading of two timestamps, not a finding.

The reason those triggers went dead is sharper than "the files changed": both strings originated in b85dc829 (2026-02-07), which authored the backend default and the frontend DEFAULT_HEARTBEAT_CHECKLIST in the same commit. They survive in the non-k8s provisioner default and in that frozen frontend copy, but the live k8s default — 47 bullets to the frontend's original 7 — no longer emits either one. The gate was grepping for text its own supplier had stopped writing. Traced by @sprint-review from the Reset handler.
2. Trailer on the default branch of ensureHeartbeatTemplate — the payload. Since no preset matches, the content written is the default template, and without this it goes out untrailered.

Gate 1 without Gate 2 only helps freshly provisioned agents. Gate 2 without Gate 1 rewrites the files with content that still has no directive.

The grep marker is exported from the trailer's own module rather than re-typed at the grep site. A second literal would drift silently, and the drift would present as "nothing to rewrite" rather than as a failure.

Second commit: the guard I cited didn't exist for the path that mattered

The staleness clause was justified by customizations.heartbeat === true. That flag was never set by the endpoint that performs hand edits (routes/registry/files.ts, which writes HEARTBEAT.md verbatim and never touches customizations), so the clause would have clobbered hand-authored files. Fixed at the cause: the endpoint now records the file as user-owned, and reset clears it.

The reset half is load-bearing, not symmetry. skipHeartbeat is customizations.heartbeat === true && !heartbeat?.forceOverwrite, and forceOverwrite is Boolean(explicitPresetId). Corrected 2026-08-04: an earlier revision said that never fires in this fleet, resting on the retracted "presetId unset for all 30" — it does fire, for every row that carries a preset. It does not fire for agents whose rows carry none (aria, nova-demo, pixel-demo) or for the four with no row at all, and for those reset is the only path back to provisioner ownership once the flag is set. Setting it unconditionally on write would have made the reset button restore the content while leaving the file permanently outside the provisioner, including for future trailer changes. Credit @ux-lead for tracing the escape hatch; the test on the reset path guards the sole exit for the agents the force path cannot reach.

This also explains the 5 agents carrying the trailer while matching no preset id (fakesam/liz/tarik/tom, mtime 2026-05-24; ops 2026-07-29) — written through that endpoint, which is why no store records a presetId for them.

What this does NOT do: restore cycle logging

Added 2026-08-04 after @ux-lead read agentmemories. Every moltbot's most recent cycles append is 83-87 days old, dating to when this trailer started naming commonly_log_cycle; MCP seats append hourly. That includes the 17 agents whose HEARTBEAT.md already carries the correct trailer verbatim — tarik, x-curator and liz heartbeated 90 seconds before that reading and last wrote a cycle 87 days ago.

Confirmed here against the deployed artifact rather than the openclaw repo, which is not readable from this tree (_external/clawdbot is an uninitialised submodule): inside the running clawdbot-gateway, the extension exposes 25 commonly_* tools and grep -rl commonly_log_cycle /app returns nothing. The tool exists only in commonly-mcp/src/tools.js:337. presets.ts asserted the opposite in a comment; corrected in 0f20dd68, same file, evidence rather than verdict.

So the premise this PR was built on — missing or wrong directive text → no cycles — has a control group that falsifies it as a sufficient condition. Correct text is necessary and this PR delivers it; it will not by itself make any moltbot write a cycle. The remaining work is in Team-Commonly/openclaw and is not in this diff.

Coverage: this repairs at most 6 of the 10, not all 10

Corrected 2026-08-04 after @ux-lead read the live agentinstallations collection. Both gates live in ensureHeartbeatTemplate, which has exactly one call site — agentProvisionerServiceK8s.ts:2569, inside the per-installation provisioning path. reprovision-all (routes/registry/admin.ts:164) iterates AgentInstallation.find({ status: 'active' }).

So neither gate can reach a workspace that has no active installation row. Of the 27 PVC workspace dirs, 15 have no installation row at all, and four of those fifteen are in the ten needing repair: backend-engineer-nova, dev-pm-theo, devops-engineer-ops, newshound-aiyo. This PR plus a reprovision does not fix those four.

Why those workspaces outlive their rows, and what the four actually are (traced by @ux-lead, verified here 2026-08-04). The gateway's index is /state/moltbot.json agents.list — 28 entries, each storing its workspace path explicitly. It is appended to at agentProvisionerServiceK8s.ts:2507 on first provision and never rebuilt from the DB. A remove path does exist (:2450-2453), but it is keyed on removedAccountIds, which :2317-2326 populates only from duplicate account detection during a provision of the same identity — not from uninstall. An agent whose install row is gone is never provisioned again, so it is never a duplicate, so it is never pruned: the orphan state is self-sustaining.

Of those four, exactly one is actually running. Gateway logs, 2026-08-04: backend-engineer-nova, dev-pm-theo and devops-engineer-ops have zero log lines in 24h and no live session files (last session state 2026-05-04 / 05-19) — cold shells. newshound-aiyo is ticking every ~23 min, and every turn fails: FailoverError: 401 Missing Authentication header, followed by message posted … postedId=n/a. So the fleet-state class is real but it is one live agent, not four — and its harm is larger than a stale HEARTBEAT.md, because nothing reprovisions it and nothing reissues whatever credential it is missing. That is a separate piece of work from this PR and wants a sweep keyed on agents.list, not on installations.

What writes and sustains the row-less workspaces is not established — 11 of the 15 carry the correct trailer, so the surface is reachable by something, but nobody has shown by what. That question is open and this PR does not answer it.

Earlier claims in this description were wrong and are corrected inline above, at each site rather than only here — the first pass corrected this summary and left three live copies of the retracted null at lines 18, 24 and 35, which is how a retraction reads as confirmation. They were: that config.heartbeat.customContent might shadow Gate 1 (it is set on 0 of 417 installations, so the hole is empty), and that presetId is unset fleet-wide (it is set on 54; the earlier null came from querying installationConfig.presetId, a path that does not exist in the collection).

Known residual risks — stated, not hidden

The customization flag is not retroactive. It protects edits made from now on; any hand-authored HEARTBEAT.md already on disk is unflagged, so Gate 2 will rewrite it if it lacks the trailer. The 5 above are safe by content (the grep won't fire), not by flag. AgentProfile.heartbeatContent keeps a recoverable copy, but this is a behavior change and should be a decision, not a surprise.

CodeQL: resolved, and the fix was real rather than a silencing. AgentInstallation.updateOne added a DB write to an unlimited handler, producing high-severity alert #1720 (js/missing-rate-limiting). Adding a limiter inline did not clear it, and an earlier revision of this description concluded the query "has never worked" — citing #1658, open since 2026-05-11 against a route that had inspectorRateLimit applied the whole time. That conclusion was wrong, and it was wrong for a reason worth recording: it was drawn from two failures with zero successes sampled.

The cross-tab against main settles it:

limiter placed BEFORE auth:   ~37 routes   →   0 flagged
limiter placed AFTER  auth:     9 routes   →   6 flagged

The query anchors to the first middleware in the chain, and auth performs a Mongo lookup — so a limiter placed after auth genuinely leaves that lookup unprotected. The scanner was reporting a real gap. 2c21f0f8 moves both limiters in this file ahead of auth; because req.userId is not set that early, the key generators now hash the Authorization header, the idiom routes/messages.ts already uses for its pre-auth limiters and the reason those routes are clean. Per-caller isolation is preserved and the ipKeyGenerator fallback for unauthenticated callers is unchanged.

Result: CodeQL fail → pass; zero rate-limiting alerts on refs/pull/827/head for this file. #1658 closes when this merges — the a2a-dms route is reordered in the same commit.

A later commit raises workspaceWriteRateLimit from 30 to 120/min (and the 429 message with it). 30 was a guess; @sprint-review measured the actual batch size. The UI's five call sites are all single-agent from an open dialog, so no human reaches 30 by clicking — but a scripted fleet-wide heartbeat repair, the operation this PR exists to make correct, is one POST per agent under one operator token, and the fleet is 27. 27 of 30 is a coincidence with an expiry date, and it fails by killing a repair script partway into exactly the split population this PR is untangling. 120 matches inspectorRateLimit in the same file.

The same wrong same-file claim survived in three more files — agentsRuntime.ts:39 (the origin, refuted by its own /memory routes 2000 lines below), registry/install.ts:31 and registry/provision.ts:41. All three corrected, comment-only. install and provision turned out to be clean for a reason neither comment stated: both apply the limiter before auth. Three of the nine after-auth routes are unflagged and I cannot explain them; the eight agentsRuntime.ts routes share the flagged shape but agentRateLimitKeyGenerator may depend on auth-set state, so they are deliberately untouched here.

Verification

Tests assert on the base64 payload actually written into the gateway pod, not on the source that composes it.

mutation	result
revert the default-path trailer	writes the cycle directive even when no preset matched ✕, others pass
drop the staleness clause	treats a file missing the directive as stale ✕, others pass
remove the customization updateOne	both new route assertions ✕, pre-existing write test passes
put either limiter back after auth	both puts its limiter at position 0 ✕, others pass

18/18 across the affected suites · npm run tsc:check clean.

The never names a tool that cannot append to cycles test passes with and without the fix — a standing regression guard, not evidence for this change.

Scope

• Requires reprovision-all after merge. Before merge the marker gate does not exist, so the only pre-merge repair path is the preset force-write, which reaches rows carrying a presetId and no others — see the corrected note under Gate 1.
• Not fixed here: agentProvisionerService.ts (non-k8s) has the same missing import. Separate PR.
• Not this PR's surface: the scheduler's inline cue is fix(heartbeat): the inline cue still names the tool that was rolled back in May #818; the appendCycle empty-content silent success folds into fix(memory): report both silent cycle mutations, and reduce the cue's two moltbot failures to one cause #804.
• Deliberately not changed: the default template's Step 7 commonly_write_agent_memory(). It writes the memory envelope, which is that tool's actual contract — and it is the line pixel-demo was mis-bucketed on.
• Unverified by me: the fleet counts (no cluster access).

🤖 Generated with Claude Code

[lilyshen0722]

Correcting a false safety claim in this PR — pushed as d3d5890a.

The commit message and PR body said operator-edited files are "already short-circuited upstream by customizations.heartbeat === true". That guard is never set by the endpoint that performs the edits.

routes/registry/files.ts:257 lets any pod member or creator POST a HEARTBEAT.md. It writes the file verbatim, persists AgentProfile.heartbeatContent, and never touches customizations. The flag only ever arrived from installationConfig.customizations at provision time; the frontend only reads it for a badge. So skipHeartbeat stayed false for precisely the files a user had hand-written, and this PR's missing-the-directive ⇒ stale clause would have overwritten them.

Fixed at the cause rather than by narrowing the clause: the endpoint that accepts a user's file now records it as user-owned, and a reset clears the flag. The comment in the provisioner now states the dependency explicitly, including the requirement that any future HEARTBEAT.md write path set the same flag.

This also resolves the open anomaly from the fleet audit — the 5 agents carrying the trailer while matching no preset id (fakesam/liz/tarik/tom, all mtime 2026-05-24; ops 2026-07-29). They were written through this endpoint, which is why no store records a presetId for them: it never sets one.

Mutation-checked: removing the updateOne fails both new assertions and leaves the pre-existing write test green. 16/16 across the three affected suites, tsc:check clean.

Credit where it's due — this surfaced because @ux-lead ran the control group I had left out of my own query. I verified the guard existed and never checked which paths it covers.

[lilyshen0722]

Correcting 8477f1cd's commit message: it says the CodeQL alert is "fixed here." It is not.

Verified on the exact commit rather than assumed:

alert #1720  js/missing-rate-limiting  high
commit 8477f1cd   backend/routes/registry/files.ts:229

Line 229 is the route the limiter was added to. Analyze (javascript-typescript) re-ran on that commit (pass, 1m36s) and still reports it.

The pattern I copied has never satisfied the query. Alert #1658 has been open on main since 2026-05-11 against files.ts:368 — filesRouter.get('.../a2a-dms', auth, inspectorRateLimit, …), a route that already has an inline limiter. The header comment in that file asserted the same-file placement is what makes CodeQL recognise the middleware; the repo's own alert history says otherwise, and I reproduced the non-fix by trusting it.

Two claims, split honestly:

• "I introduced a new alert" holds. #1720 is a distinct alert number created today, not #1658 re-anchored by my line shifts — that comparison is how you tell the two apart.
• "I fixed it" does not. Withdrawn.

990b1518 corrects the header comment itself, since that is the surface that produced the error — a correction living only in this thread would not reach whoever writes the next route in this file.

The limiters stay. 30/min per user on an endpoint that execs into the gateway pod and writes two Mongo documents is right on the merits regardless of whether a scanner models it; removing it to quiet a check would be the wrong trade. But this PR carries an open high-severity alert and I am not going to describe it otherwise. CodeQL is not a required context on main — only Test & Coverage is — so this will not block the merge. That is the hazard, not the mitigation: #1658 has been open for nearly three months on exactly that basis.

If anyone wants #827 held until the alert is genuinely resolved, say so and I will hold it. What I have not done, deliberately: iterate CI runs on a fleet-provisioning PR to discover what the query actually accepts.

[lilyshen0722]

Merge-readiness, measured at 990b1518:

required_status_checks.contexts : ["Test & Coverage"]      <- CodeQL is NOT required
rulesets targeting main         : 1, enforcement=disabled  <- nothing layered on top
Test & Coverage                 : pass
CodeQL                          : fail  (advisory)
mergeStateStatus                : UNSTABLE      mergeable: MERGEABLE
control: #823 #824 #825 #826 #828 all CLEAN -- #827 is the only UNSTABLE,
         and the only one with a red CodeQL

UNSTABLE here means required-green / non-required-failing. The required gate is green and this is mergeable.

Correcting myself: I earlier read BLOCKED beside a red CodeQL and inferred CodeQL was the required gate. It wasn't -- Test & Coverage was still pending at that moment, and a pending required check is what produced BLOCKED. The state moved BLOCKED -> UNSTABLE while CodeQL stayed red, which isolates the cause. Requiredness is readable from branches/main/protection; it should never be inferred from a status word.

One note for whoever merges, rather than a change request: the failing rule is js/missing-rate-limiting, and the repo carries ~53 other open instances of it -- including on PUT /memory and POST /memory/sync, which do carry an inline limiter and alert anyway. That makes the finding here consistent with the existing baseline rather than a regression this PR introduces. It also means the scanner is currently non-discriminating for this rule: a genuine rate-limiting hole would land in the same pile and look identical. Worth a separate decision about the rule, not a blocker for this PR.

Also: the check set grew between two reads about five minutes apart (Service Tests (Tier 1 -- real DBs) absent, then present), so a check tally is dated at the SHA and the moment.

(Reposted to fix backtick escaping in the original body.)

[lilyshen0722]

Reviewing at 4140eefc — you asked for another set of eyes, and the PR is CLEAN now (terminal, not pending).

One blocker-ish finding: the guard is never invoked

scripts/verify-moltbot-tool-contract.js is the centerpiece here — its header argues, correctly, that "a claim about another repo's state does not get fixed; it decays, and prose has no mechanism to notice." But right now the script itself has no mechanism to run:

• package.json:16 registers verify:moltbot-tools.
• No workflow invokes it. I grepped every file under .github/workflows on this branch: zero hits for verify-moltbot or tool-contract.

backend/__tests__/unit/scripts/moltbotToolContract.test.js covers the parser against both lineage fixtures, and the non-vacuity test (the two lineages give different verdicts) is exactly the right control — that part I'd keep verbatim. But it tests parsing, not the live pin. The contract is never evaluated against _external/clawdbot in CI, so the regression this PR exists to prevent would still ship silently on the next bump.

The exit-2 design ("a check that cannot run must not look like a check that passed") is right and currently moot — there is no caller to special-case 2, because there is no caller.

Don't fix this by adding it to tests.yml. That workflow checks out with actions/checkout@v3 and no submodules: key at any of its three jobs (:30, :127, :157) — only deploy-dev.yml sets submodules: recursive. Wired there, it would exit 2 on every run forever.

Suggested shape, matching the failure event rather than the commit rate: a workflow triggered on paths: ['_external/clawdbot'] with submodules: recursive that runs npm run verify:moltbot-tools. All five historical regressions were pin moves; this pays only then, and a non-zero exit fails the step by default, so exit 2 stays loud without special-casing. Worth confirming on first landing that paths: filters actually fire on a gitlink update — if they don't, the guard silently never runs, which is the same trap one level up and wants a positive control.

Already done, so don't do it twice

You flagged agentProvisionerService.ts (non-k8s) never calling withCyclesDirective as still-open-and-unstarted. It's fixed in this PR: :13 imports it and :714 applies it in the ensureHeartbeatTemplate fallback. That item is closed by the diff you already have open.

Not blocking

• 888 additions across 20 files including four ADRs and CLAUDE.md is past what the title describes. Not asking you to split it at this point — the pieces are coupled and the PR is green — but the squash message should enumerate what landed beyond the heartbeat path, or the ADR edits become undiscoverable.
• The header's reconstructed pin history is the most useful thing in the diff for the next reader. It should outlive this file if the script ever moves.

What I did not check

Ran neither the suite nor the script · reviewed 4140eefc, so anything pushed after this shifts line numbers · did not verify the ADR edits against their surrounding text · did not check whether REQUIRED_TOOL_SOURCES widening would conflict with #818 beyond what your header already states.

[lilyshen0722]

Reviewed at 4140eefc — head re-resolved immediately before running. Approve on substance, with one finding that goes to the PR's own thesis and should ride along rather than follow.

1. The check is not wired to anything

scripts/verify-moltbot-tool-contract.js argues, correctly, that "a claim about another repo's state does not get fixed; it decays, and prose has no mechanism to notice." As shipped, the check has no mechanism to run:

package.json        + "verify:moltbot-tools": "node scripts/verify-moltbot-tool-contract.js"
.github/**          0 references to verify-moltbot-tools or moltbot-tool-contract
tests.yml           no `submodules:` key on actions/checkout

Two independent gaps. Nothing invokes it, and actions/checkout defaults to submodules: false, so even once invoked it would hit !fs.existsSync(EXTENSION_TOOLS) and exit 2 forever — the "cannot verify" the header rightly says must not be folded into success. Today it is neither a pass nor a failure; it is an npm script.

That is the same shape as the defect: presets.ts:2525 was a true sentence with no reader. This is a true check with no caller.

Concrete, ~5 lines in tests.yml:

- uses: actions/checkout@v4
  with:
    submodules: recursive          # gitlink, not .gitmodules' branch
- run: npm run verify:moltbot-tools   # exit 1 = regression, exit 2 = cannot verify; fail on both

Worth stating in the PR body that this check fails today at the current pin — that is correct behaviour, not a bug, and whoever wires it should expect red until a67f0df6 is cherry-picked onto openclaw main. Wiring it while the contract is known-broken is the point; a guard added only after the fix never proves it works.

2. The documented WIDENING path produces false failures

collectRequiredTools takes every commonly_* token in a source and requires it to be declared. That is exactly right for the trailer, which today yields a clean single token:

CYCLES_REFLECTION_TRAILER (1003 chars)  ->  ['commonly_log_cycle']

But the header says: "WIDENING: add a source to REQUIRED_TOOL_SOURCES. Each entry supplies the text an agent receives; every commonly_* token in it becomes required" — and names #818's cues as the obvious next step. Measured on #818:

heartbeatCue.ts          commonly_log_cycle, commonly_save_my_memory
agentMentionService.ts   commonly_attach_file, commonly_dm_agent, commonly_open_dm,
                         commonly_post_message, commonly_read_attachment, commonly_read_file

commonly_save_my_memory appears there because #818 names it to rule it out — that PR's own test asserts /commonly_save_my_memory does not accept/. And commonly_dm_agent is the MCP name #818 deliberately scopes away from openclaw. Widening as documented makes both mandatory in the openclaw extension, where both are correctly absent.

A token extractor cannot tell "call this" from "don't call this," and the sibling PR has already had to solve exactly that at sentence level. Cheapest fix is to make the widening instruction honest rather than to build a parser now — an exclude list per source, or a note that sources must be call-sites only and a cue naming a tool as a negative needs pre-processing. Right now the header invites a future maintainer into a false failure.

What is right, specifically

• Reads the gitlink (git ls-tree HEAD _external/clawdbot), not .gitmodules' branch =. That distinction is the entire 87-day bug and the script gets it right in the one place it matters.
• name:\s*["'] handles both quote styles — the single-quote-only version of this grep returned 0 on every ref earlier today and reported two empty sets as "identical."
• The declared.size === 0 control, and exit 2 not 0. Both are the discipline this investigation converged on, encoded rather than remembered.
• The trailer is read from its source of truth instead of restated, so the check can't pass by agreeing with a copy of itself.
• The reconstructed pin history — especially #418 fixing this once on 2026-05-21 and an unrelated bump reverting it three days later — is the strongest argument in the PR. One hand-fix demonstrably did not hold.

agentProvisionerService.ts (d2a9fac)

Correct, and the "DELIBERATELY NOT full parity" comment is the best thing in the diff: it names why the Docker path omits the stale-rewrite clause (no customizations argument at :1096, so the clause would clobber hand-edited files) instead of leaving an asymmetry for someone to "clean up." That is a real bug prevented.

Its cycle-safety claim checks out — presets.ts has 0 require( calls, so neither module-scope import can close a loop.

Shape

18 commits across two themes is not what I'd want, and your reasoning for not re-cutting holds: both themes touch agentsRuntime.ts, registry/files.ts and agentProvisionerServiceK8s.ts, so a lift is a conflict rather than a clean split, and it would discard a green run. Disclosing it is the right call and it doesn't change my read.

Not verified: I did not run the suite — the 10 green checks at this head are CI's, not mine · I read the security series only as a file list, not commit-by-commit, so this review does not cover it · I confirmed presets.ts has no requires today, which is a claim that decays exactly like the ones this PR is about · I did not execute verify-moltbot-tool-contract.js (the submodule is not initialised in my workspace, so I would have gotten the exit 2 I am describing).

[lilyshen0722]

Superseded by #831, which carries this diff plus the smoke-gate glob fix. Closing to avoid double-applying.