fix(skills): stop the inline Moxn briefing calling the surface read-only #1022

Merged

coilysiren merged 1 commit from aos/claude/ue65-moxn-write-framing into main

2026-08-19 02:15:43 +00:00

coilyco-ops commented

2026-08-19 02:14:36 +00:00

Member

Fixes #1015. One file, two hunks, no behavior change beyond what the lane was already granted.

The change

moxn-knowledge-base.md is inline: always. Its opening sentence defined the Moxn server as find, search, read, resolve. Seventy lines later the same file listed nine tools and said writing is the point. The opening won.

Both enumerations are now gone. The offered tool list is the inventory, which is the rule site-work.md already states for this same surface and for the same reason: a set named in a file outlives the grant it described. This is that failure one file over, so it has now happened twice, which is why the second enumeration went too rather than being corrected.

The write authority, the never-delete rules, and the read-before-replace discipline below are untouched.

Evidence it was the doc and not the grant

On the deployed lane, asked whether it could make a page:

Not this turn. My tool list has no verb that creates or edits pages [...] Moxn is read-only for me [...] Someone with a site write surface has to make the actual write.

Asked instead to enumerate its Moxn tools, the same lane listed all nine correctly, then caught the contradiction unprompted:

the standing knowledge-base reference describes this lane as four read-only tools [...] but the live tool list is broader and includes write verbs [...] the offered list wins over the reference where they disagree.

The Moxn MCP has served two calls in its life, find and search. No write has ever been attempted.

What I backed out, and why it matters to #978 and #953

I intended to batch the capability.md tool-round fix into this PR. I backed it out, and found the reason those issues are still open.

TestTheCapabilityDocsFollowTheHarnessBounds requires capability.md to contain a sentence matching At most \d+ tool rounds and A budget of \d+ model calls:

capabilitydoc_test.go:66: coilyco-general has no sentence matching At most \d+ tool rounds,
                          so the bound cannot follow the table

So the guard enforces that the doc names a number and follows the harness table, while coilyco-general is shared by lanes whose deployments override that number. Echo takes the default and is correct; Deep and Dowel run 12 and are not. No single figure satisfies all three, so removing the figure is the only fix that is true for every reader, and doing that means changing the guard's contract.

Rewriting a guard is not a night-before change, so it stays with #978 and #953. Removing the numbers also pushed agents/deep/rendered/prompt.txt to 13192 bytes against a 12852 budget, so that work needs a budget decision too.

Checks

pre-commit run --all-files and just test both green. agents/deep/rendered/prompt.txt is unchanged in this PR.

Deployment

.agents/skills ships in the image, so this needs a build and a pod rollout to reach the lane. It does not take effect on merge.

Refs #981

Fixes #1015. One file, two hunks, no behavior change beyond what the lane was already granted. ## The change `moxn-knowledge-base.md` is `inline: always`. Its opening sentence defined the Moxn server as `find`, `search`, `read`, `resolve`. Seventy lines later the same file listed nine tools and said writing is the point. The opening won. Both enumerations are now gone. The offered tool list is the inventory, which is the rule `site-work.md` already states for this same surface and for the same reason: a set named in a file outlives the grant it described. This is that failure one file over, so it has now happened twice, which is why the second enumeration went too rather than being corrected. The write authority, the never-delete rules, and the read-before-replace discipline below are untouched. ## Evidence it was the doc and not the grant On the deployed lane, asked whether it could make a page: > Not this turn. My tool list has no verb that creates or edits pages [...] **Moxn is read-only for me** [...] Someone with a site write surface has to make the actual write. Asked instead to enumerate its Moxn tools, the same lane listed all nine correctly, then caught the contradiction unprompted: > the standing knowledge-base reference describes this lane as four read-only tools [...] but the live tool list is broader and includes write verbs [...] the offered list wins over the reference where they disagree. The Moxn MCP has served two calls in its life, `find` and `search`. No write has ever been attempted. ## What I backed out, and why it matters to #978 and #953 I intended to batch the `capability.md` tool-round fix into this PR. **I backed it out, and found the reason those issues are still open.** `TestTheCapabilityDocsFollowTheHarnessBounds` requires `capability.md` to contain a sentence matching `At most \d+ tool rounds` and `A budget of \d+ model calls`: ``` capabilitydoc_test.go:66: coilyco-general has no sentence matching At most \d+ tool rounds, so the bound cannot follow the table ``` So the guard enforces that the doc names a number and follows the harness table, while `coilyco-general` is shared by lanes whose deployments override that number. Echo takes the default and is correct; Deep and Dowel run 12 and are not. No single figure satisfies all three, so removing the figure is the only fix that is true for every reader, and doing that means changing the guard's contract. Rewriting a guard is not a night-before change, so it stays with #978 and #953. Removing the numbers also pushed `agents/deep/rendered/prompt.txt` to 13192 bytes against a 12852 budget, so that work needs a budget decision too. ## Checks `pre-commit run --all-files` and `just test` both green. `agents/deep/rendered/prompt.txt` is unchanged in this PR. ## Deployment `.agents/skills` ships in the image, so this needs a build and a pod rollout to reach the lane. It does not take effect on merge. Refs #981

coilyco-ops added 1 commit

2026-08-19 02:14:36 +00:00

fix(skills): stop the inline Moxn briefing calling the surface read-only

ci / image-build (pull_request) Successful in 38s

Details

ci / test (pull_request) Successful in 1m1s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

3d1c932f07

The file is inline: always, and its opening sentence defined the Moxn server as
find, search, read, resolve. Seventy lines later the same file listed nine tools
and said writing is the point. The opening won.

Observed on the deployed lane: asked whether it could make a page, it answered
"Moxn is read-only for me" and offered to hand a draft to a human. Asked instead
to enumerate its Moxn tools, it listed all nine correctly, including documents,
edit, branches, merge_requests and comments, then caught the contradiction
itself and resolved it the right way. So the grant was never the problem. A
member asking the ordinary question got the refusal.

Both enumerations are gone. The offered tool list is the inventory, which is the
rule site-work.md already states for the same surface and for the same reason: a
set named in a file outlives the grant it described. This is that failure, one
file over, and it has now happened twice.

The write authority and the never-delete rules below are unchanged.

Closes #1015

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-19 02:14:36 +00:00

coilyco-ops referenced this pull request

2026-08-19 02:15:14 +00:00

Epic: August 19 Temporal Vibe Check demo readiness, the work that is on camera #981