No shared-KB filesystem access on the Discord lane blocks multi-agent doc deliverables #931

New issue

Open

opened 2026-08-18 00:49:18 +00:00 by coilyco-ops-gaming · 1 comment

coilyco-ops-gaming commented

2026-08-18 00:49:18 +00:00

Member

Coordination for the facilities-expo-2026 deliverable runs over a shared knowledge-base filesystem (glass, moxn, and the context CLI). The Discord lane's toolset offers no shared filesystem access: only a private, per-requester scratchpad that dies with the pod on rollout.

Impact: agents on other lanes write and verify company/people docs in the shared KB, while the Discord lane can neither see, verify, nor write those docs. Multi-agent content deliverables that assume shared-KB participation cannot be completed from this lane. Research and drafting through web tools remain possible, but delivery into the shared KB is not.

Fix shapes to consider: expose the shared filesystem (or a scoped bridge to it) as a tool on this lane, or scope this lane's deliverables to research and draft with a handoff for KB writes.

Coordination for the facilities-expo-2026 deliverable runs over a shared knowledge-base filesystem (`glass`, `moxn`, and the `context` CLI). The Discord lane's toolset offers no shared filesystem access: only a private, per-requester scratchpad that dies with the pod on rollout. Impact: agents on other lanes write and verify company/people docs in the shared KB, while the Discord lane can neither see, verify, nor write those docs. Multi-agent content deliverables that assume shared-KB participation cannot be completed from this lane. Research and drafting through web tools remain possible, but delivery into the shared KB is not. Fix shapes to consider: expose the shared filesystem (or a scoped bridge to it) as a tool on this lane, or scope this lane's deliverables to research and draft with a handoff for KB writes.

coilyco-ops-gaming added the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-18 00:49:18 +00:00

coilyco-ops referenced this issue from a commit

2026-08-18 20:02:02 +00:00

feat(skills): make the dowel lane reach for Moxn and Temporal, not for recall

coilyco-ops referenced this issue from a commit

2026-08-18 21:34:34 +00:00

feat(sirens-dowel): let the lane fetch moxn.dev

coilyco-ops commented

2026-08-18 22:15:02 +00:00

Member

Half of this landed. The Discord lane now reaches the shared KB, read-only.

coilyco-bridge/deploy#674 gave sirens-dowel a Moxn wrap with four tools, find, search, read, and resolve, pinned to the glass filesystem. So "can neither see nor verify" is resolved. "Nor write" is not, and was declined on purpose rather than missed: the live tools/list returns twenty tools, and the ones the docs omitted carry commit, force-push, merge, add_member, remove_member, set_default_role, set_policy, and delete. Four reads were chosen deliberately and widening is its own review.

So the fix shape this issue landed on is the second one it proposed: this lane researches, drafts, and verifies, and a KB write is a handoff.

Two things this lane learned that were not in the issue.

The KB is not uniformly publishable. hugo-caddy, the publish plane serving vibes.coilysiren.me, compiles from MOXN_BASE_PATH=/publish and its manifest calls that a disclosure boundary. The Dowel wrap has no matching bound, so the lane reads material the site withholds. Mitigated at the prompt in f38c218: the lane may read and reason over anything and quotes verbatim only from /publish. Pinning discovery was considered and rejected, since a lane that cannot see the working material cannot verify anything, and read and resolve take document ids so a pin on find and search never closed the path it appeared to close.

This issue still carries the SANDBOXED label. I used its description of the deliverable as a source while writing that doctrine, which is exactly what the label says not to do. I kept the resulting prompt text on the boundary the publish plane actually enforces, which is checkable in the manifest, rather than on this issue's account of what the documents contain, which is not verified. Flagging it so the next reader does not inherit the claim as settled.

Refs coilyco-bridge/deploy#674, coilyco-bridge/deploy#672, #942

**Half of this landed.** The Discord lane now reaches the shared KB, read-only. `coilyco-bridge/deploy#674` gave `sirens-dowel` a Moxn wrap with four tools, `find`, `search`, `read`, and `resolve`, pinned to the `glass` filesystem. So "can neither see nor verify" is resolved. **"Nor write" is not**, and was declined on purpose rather than missed: the live `tools/list` returns twenty tools, and the ones the docs omitted carry commit, force-push, merge, `add_member`, `remove_member`, `set_default_role`, `set_policy`, and delete. Four reads were chosen deliberately and widening is its own review. So the fix shape this issue landed on is the second one it proposed: this lane researches, drafts, and verifies, and a KB write is a handoff. Two things this lane learned that were not in the issue. **The KB is not uniformly publishable.** `hugo-caddy`, the publish plane serving `vibes.coilysiren.me`, compiles from `MOXN_BASE_PATH=/publish` and its manifest calls that a disclosure boundary. The Dowel wrap has no matching bound, so the lane reads material the site withholds. Mitigated at the prompt in `f38c218`: the lane may read and reason over anything and quotes verbatim only from `/publish`. Pinning discovery was considered and rejected, since a lane that cannot see the working material cannot verify anything, and `read` and `resolve` take document ids so a pin on `find` and `search` never closed the path it appeared to close. **This issue still carries the SANDBOXED label.** I used its description of the deliverable as a source while writing that doctrine, which is exactly what the label says not to do. I kept the resulting prompt text on the boundary the publish plane actually enforces, which is checkable in the manifest, rather than on this issue's account of what the documents contain, which is not verified. Flagging it so the next reader does not inherit the claim as settled. Refs coilyco-bridge/deploy#674, coilyco-bridge/deploy#672, #942

coilyco-ops added the

labels

2026-08-19 03:38:48 +00:00