Dowel's inline Moxn briefing opens by calling the surface read-only, so the lane refuses writes it is granted #1015

New issue

Closed

opened 2026-08-19 01:55:29 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-19 01:55:29 +00:00

Member

moxn-knowledge-base.md is inline: always, and its opening sentence defines the Moxn surface as four read tools. Seventy lines later the same file says the grant is nine tools and that writing is the point. The opening is the one that lands.

Line 7:

Dowel reaches a shared knowledge base at moxn.dev through the rostered moxn server: moxn__find, moxn__search, moxn__read, moxn__resolve.

Line 80:

The grant is find, read, search, resolve, documents, edit, branches, merge_requests, and comments. Writing is the point rather than an accident.

What it does to the lane, observed live

Asked whether it could make a page, the deployed lane (d32e6058) said:

Not this turn. My tool list has no verb that creates or edits pages on the site, so I can't land a page myself right now. [...] 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, including documents (create, update, delete), edit, branches, merge_requests, and comments, and then caught the contradiction on its own:

the standing knowledge-base reference describes this lane as four read-only tools (find, search, read, resolve) with no write surface, but the live tool list is broader and includes write verbs [...] Per the tool-surfaces map, the offered list wins over the reference where they disagree.

So the capability is present and correctly granted. The always-inline briefing talks the lane out of it, and only a direct request to enumerate recovers the truth. A member asking the ordinary question gets the refusal.

Why this matters more than a doc nit

The deployed grant was scoped deliberately. sirens-dowel-moxn-mcp-values.yaml says it plainly:

Writing is the point. Moxn is an editor for human and agent collaboration with branching and merge requests, so a read-only agent demonstrates nothing about what it is.

site-work.md then gives this lane full landing authority, with no operator seat, and states that a write returning successfully is the work delivered. Every layer below the briefing is built for an agent that makes things.

The Moxn MCP has served exactly two calls since it came up: find and search. No write has ever been attempted on this surface.

Suggested fix

Make the opening sentence name the whole grant, or name no tools at all and let the offered list speak, which is the pattern site-work.md already uses deliberately ("This file is about how to use them and deliberately does not name them, because the surface behind them is being replaced"). The read-only framing then cannot outlive the grant.

Worth a pass for the same shape elsewhere in the root, since an inline file that enumerates a tool surface will drift the moment the grant changes.

#993 - all six references inline every turn, which is why the opening line has this much reach.
#1004 - skill contract, entrypoints index rather than inline. Same area, and the fix here may fall out of it.
#977 - site-work.md naming a stale write surface. Same failure, different file. That one appears already addressed, since the current file deliberately names no verbs.

`moxn-knowledge-base.md` is `inline: always`, and its opening sentence defines the Moxn surface as four read tools. Seventy lines later the same file says the grant is nine tools and that writing is the point. The opening is the one that lands. **Line 7:** > Dowel reaches a shared knowledge base at moxn.dev through the rostered `moxn` server: `moxn__find`, `moxn__search`, `moxn__read`, `moxn__resolve`. **Line 80:** > The grant is `find`, `read`, `search`, `resolve`, `documents`, `edit`, `branches`, `merge_requests`, and `comments`. Writing is the point rather than an accident. ## What it does to the lane, observed live Asked whether it could make a page, the deployed lane (`d32e6058`) said: > Not this turn. My tool list has no verb that creates or edits pages on the site, so I can't land a page myself right now. [...] **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, including `documents` (create, update, delete), `edit`, `branches`, `merge_requests`, and `comments`, and then caught the contradiction on its own: > the standing knowledge-base reference describes this lane as four read-only tools (find, search, read, resolve) with no write surface, but the live tool list is broader and includes write verbs [...] Per the tool-surfaces map, the offered list wins over the reference where they disagree. So the capability is present and correctly granted. The always-inline briefing talks the lane out of it, and only a direct request to enumerate recovers the truth. A member asking the ordinary question gets the refusal. ## Why this matters more than a doc nit The deployed grant was scoped deliberately. `sirens-dowel-moxn-mcp-values.yaml` says it plainly: > Writing is the point. Moxn is an editor for human and agent collaboration with branching and merge requests, so a read-only agent demonstrates nothing about what it is. `site-work.md` then gives this lane full landing authority, with no operator seat, and states that a write returning successfully **is** the work delivered. Every layer below the briefing is built for an agent that makes things. The Moxn MCP has served exactly two calls since it came up: `find` and `search`. No write has ever been attempted on this surface. ## Suggested fix Make the opening sentence name the whole grant, or name no tools at all and let the offered list speak, which is the pattern `site-work.md` already uses deliberately ("This file is about how to use them and deliberately does not name them, because the surface behind them is being replaced"). The read-only framing then cannot outlive the grant. Worth a pass for the same shape elsewhere in the root, since an inline file that enumerates a tool surface will drift the moment the grant changes. ## Related - #993 - all six references inline every turn, which is why the opening line has this much reach. - #1004 - skill contract, entrypoints index rather than inline. Same area, and the fix here may fall out of it. - #977 - `site-work.md` naming a stale write surface. Same failure, different file. That one appears already addressed, since the current file deliberately names no verbs.

coilyco-ops referenced this issue from a commit

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

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

coilyco-ops referenced this issue from a pull request that will close it,

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

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

coilyco-ops referenced this issue

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

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