Never run npm install/tsc/wrangler from a cloud/agent sandbox — node_modules sits on a mount shared with the real Mac, and a Linux sandbox install poisons it with wrong-platform workerd/esbuild binaries. Use Desktop Commander (or the user's own terminal) for install/typecheck/deploy; read-only curl against the live public URLs is fine from a sandbox.

A Linux cloud sandbox and the real macOS Desktop Commander session share a filesystem mount but not an OS/CPU architecture — installing Cloudflare Workers' native deps (workerd, esbuild) from the wrong platform silently corrupts every worker's node_modules until a full reinstall.

custom instructions

CLAUDE.md, "Session handoffs", "Cloud-sandbox rule for ALL workers/* projects"

Use Desktop Commander (or the user's own terminal) for install/typecheck/deploy. Every workers/subagentworkers and workers/subagentdb redeploy skill explicitly instructs running its script "from a real terminal — see that skill's SKILL.md for why not a cloud sandbox."

Direct restatement of the cloud-sandbox rule at the point of highest risk (an actual wrangler deploy) — matches attach-to-scope.md's own point that custom instructions at a narrower scope exist specifically to reinforce or extend a wider rule where the stakes are highest.

custom instructions

CLAUDE.md, "Architecture", workers/subagentworkers and workers/subagentdb redeploy skills

Every migration in this repo is applied with an explicit wrangler d1 execute --remote --file <path> command, listed verbatim under "Key commands" in CLAUDE.md — schema changes are never assumed to have been applied just because the .sql file exists in the repo.

D1 schema state lives in Cloudflare, not in git — a checked-in migration file describes intent, not fact, until the exact wrangler command has actually been run and its output checked, the same distinction claude-tag draws between a bundle being configured and a bundle actually being attached to a scope.

custom instructions

CLAUDE.md, "Key commands"

Work on the ~50-domain subagent*.com fleet is routed to the cwc-* plugin owning that domain function (12 knowledge-work domains + deploy + analytics-engineer). Definition of done is written as a contract or task before work starts; outcomes are rubric-graded; each plugin's gates.toml names the actions requiring operator approval. An unbuilt capability is reported as missing, never simulated.

Mirrors Anthropic's knowledge-work-plugins domain organization so skills and MCPs iterate per domain; keeps side effects behind explicit per-plugin gates; documented at subagentcoworkers.com/platform/concepts/role-taxonomy and visualized at subagentdevices.com/architecture.

custom instructions

.claude-plugin/marketplace.json

Code written for the cloud__* surface must use mcp__MCP_DOCKER__* tools only. Code for the macos__* surface can use npx/binary MCPs on the Mac.

The two surfaces have structurally different credential boundaries (fixed provisioned Docker MCP Toolkit catalog vs. the Mac's own local OS-level auth) — the same reason claude-tag scopes Access bundles to a channel rather than letting every session reach for whatever credential happens to be nearby.

custom instructions

CLAUDE.md, "Naming ontology: {device_surface}__{client_surface}__{coworker_enum}"

cargo run -p agent-gen requires RUSTC_WRAPPER='' on this machine to bypass a broken sccache wrapper — without it, rustc invocation fails with "could not execute process sccache ... (never executed)".

A machine-local toolchain quirk, not a portable rule — narrower than the repo-wide sandbox rule, and only adds an override on top of it, never replaces it (the same "narrower scope adds, doesn't replace" rule attach-to-scope.md states for overlapping Access bundles).

custom instructions

CLAUDE.md, "Type-safe agent system", "crates/agent-gen/"