brigade

module

v0.1.0 Latest Latest Go to latest Published: Sep 6, 2026 License: MIT

Details

Valid go.mod file
Redistributable license
Tagged version
Stable version
Learn more about best practices

Repository

github.com/appshapes/brigade

Links

Open Source Insights

README ¶

Brigade

Team messaging between the Claude Code sessions of different people and machines. A session registers itself as an addressable session in a team; another person's session sends it a text message; the message is stored durably by a backend and injected into the recipient session's context without a human in the loop. Identity is a principal (one person's credential on one backend) and an opaque session id; display names are unverified labels. Delivery is at least once with an explicit acknowledgement point. Everything a model sees from another principal is sanitised, and a message can never grant permission, approve a prompt or represent human consent.

Brigade ships as a Claude Code plugin. The plugin talks to its backend through an adapter: a separate executable that speaks the Brigade Adapter Protocol (BAP/1) on argv, stdin and stdout. The bundled adapter targets Supabase; any other backend is its own adapter, selected per profile.

You want to…	Go to
Get started	What Brigade is · Layout · Set up a team · Security
Write an adapter	For adapter contributors · `docs/adapter-authors.md` · `docs/protocol-v1.md`
Build, test, release	Gates · `scripts/ci/README.md`
Run the plugin locally	`plugin/README.md`
See what is proven	`docs/experiments/` · the proof results
Find where the work stands	the execution log · `CHANGELOG.md`
Read the research	`docs/research/`

For adapter contributors

If you are writing an adapter for another backend (a raw PostgreSQL or MySQL database, an object store, your own service), everything you need is in this repository, in this order:

docs/adapter-authors.md — the authoring guide. Its "Start here" section carries describe and session list end to end; three independent implementers built both from that page alone and passed the suite's first four cases. Read it before the spec.
docs/protocol-v1.md — BAP/1, the normative protocol, frozen. Every MUST cites a conformance case. Section 4.8 lists what the protocol deliberately does not say — how you authenticate, store credentials, represent membership or transport events, the shape of your identifiers, your profile file — and that freedom is yours. Section 4.7 is the capabilities registry: omitting a capability is a first-class answer (a polling adapter omits message.watch.push; an adapter whose membership is managed elsewhere omits team.join).
internal/adapters/fs/ — the reference adapter, a complete BAP/1 implementation over a directory on disk, insecure and test-only by design. Its README documents the store layout; it is the worked example the guide walks through and the dry run for an object-store adapter.
brigade-conformance — the arbiter. make build, then bin/brigade-conformance --adapter /abs/path/to/your-adapter (with --shared-env <VAR> if your backend is a directory every test principal must share, and --setup <cmd> if principals are provisioned out of band). 45 cases, three principals in two teams, an environment built from scratch. An adapter is correct when the suite is green; the suite's own positive control is four deliberately broken builds of the reference adapter, each of which must fail exactly its own cases.

Facts that changed since the early brief some of you read: the ten open questions about section 4 are decided, the lease range is each adapter's own and is advertised in describe, the suite reads no poll interval — so a polling adapter gets the same 5 s delivery deadline as a push one — and a profile carries its default adapter while a session may override it. docs/protocol-v1.md Appendix C names each decision and the sentence that honours it, and the wording questions a second implementation may surface are collected as BAP/1.x items in the execution log, where an answer changes a minor revision and never the frozen major.

What we still ask of you: read the frozen core — describe, session *, message * and the semantics of 4.5 — against your backend and tell us, naming section numbers, whether there is anything you cannot express without GoTrue, PostgREST and Realtime. A real gap is a BAP/1.x question; a change an existing conforming adapter would fail is a new major version.

Gates

The acceptance gate is make typecheck lint build test vuln deps-check schema-check tidy-check. make test is Docker-free and stack-free; the suites that need the local Supabase stack are make supabase-start supabase-env followed by make test-all. make help lists every target, and a trailing (CI) marks the ones a workflow step invokes — scripts/ci/README.md says what each CI script does and what calls it.

Go 1.27.0 is pinned in go.mod with no toolchain line, and docs/allowed-deps.txt binds only the shipped brigade binary, not your adapter. master only, merges only, never rebase; commit messages 15: <Imperative summary>, through make push message="15: …". Plans live in .context/plans/, ephemeral scratch in .ignored/ (gitignored).

To run the conformance suite against the bundled adapter and a local stack, pass the backend as --env BRIGADE_SUPABASE_URL=… --env BRIGADE_SUPABASE_PUBLISHABLE_KEY=… — team create/team join honour that pair only when the profile names no backend, never overriding a configured profile. The suite provisions its own teams, so no --setup hook is needed.

Layout

Path	What
`CHANGELOG.md`	what changed in each release
`docs/protocol-v1.md`, `docs/protocol-v1.schema.json`	the frozen protocol and its advisory JSON Schema
`docs/adapter-authors.md`	how to write and prove an adapter
`docs/setup.md`	how to set up Brigade for a team
`docs/security.md`	what Brigade protects, what it does not, and what was measured
`docs/experiments/`	the dated experiment writeups (Phases 0, 3 and 4): what was measured, and what each run does not prove
`docs/research/`	the research digests the plan was written from, and the security threat model that defines the test ids
`internal/protocol`, `internal/adapterkit`	the wire types with `Validate()`, and the shared adapter plumbing
`internal/adapters/fs`, `cmd/brigade-adapter-fs`	the reference adapter (dev and test only)
`internal/conformance`, `cmd/brigade-conformance`	the conformance suite (dev and test only)
`cmd/brigade`	the one shipped binary: the plugin harness and the bundled Supabase adapter
`plugin/`	what the Claude Code plugin ships: the manifest, the lifecycle hooks, the two skills, the sh bootstrap and the release pins
`supabase/`	the Supabase backend: migrations, pgTAP tests, local stack config
`scripts/`	the proof scripts behind `make e2e` and `make proof`, the headless smoke test and the release sequence
`scripts/ci/`	the CI checks (plugin tree, secrets, release pins, keep-alive), their fixtures and the Go drift tests that pin them
`.context/plans/`	the implementation plan (an index plus one file per section under implementation/), the execution log and its archive
`.context/plans/brigade-proof-results.md`	the Phase 4 exit record: the ten success criteria, each with a verdict and the test that discharges it

Status

Phases 1 to 4 and 6 are complete: the protocol is frozen, and the shared library, the reference filesystem adapter, the conformance suite, the bundled Supabase adapter, the plugin and its harness — the lifecycle hooks, the session-bound commands and the detached watcher — all exist, are green and were driven end to end through real Claude Code sessions with no person at a keyboard (the proof results: ten success criteria met, eight open findings, none blocking). Phase 5 delivered the rest: the backend is deployed on a hosted project with the daily keep-alive and the conformance suite green against it, team administration and the hold inbox ship, retention is verified live, the two-hour soak has run, the frame's instruction text ships as levels, and the user documentation is written.

0.1.0 is the first release. make release version=0.1.0 pins plugin/bin/VERSION and the plugin manifest to 0.1.0, writes the sha256 of each published binary into plugin/bin/checksums.txt, and pushes the tag v0.1.0; the release workflow builds the four binaries from that tag and publishes them beside their checksums.txt. A tree in which that command has not run carries the pre-release 0.0.0 and an empty checksums file, and its plugin has nothing to download. Installing is claude plugin marketplace add appshapes/brigade and then claude plugin install brigade@brigade (docs/setup.md). Not in 0.1.0: a Homebrew tap or a Linux package, and an operating-system keychain for the credential — it is a 0600 file, and docs/security.md says what that costs. The single source of truth for where the work stands is .context/plans/brigade-execution-log.md.

Directories ¶

?	: This menu
/	: Search site
f or F	: Jump to
y or Y	: Canonical URL

Path	Synopsis
cmd
brigade command Command brigade is the one shipped Brigade binary: the human and model command surface, the Claude Code lifecycle hooks, the detached watcher and the bundled adapters, all in one multi-call image (D35).	Command brigade is the one shipped Brigade binary: the human and model command surface, the Claude Code lifecycle hooks, the detached watcher and the bundled adapters, all in one multi-call image (D35).
brigade-adapter-fs command Command brigade-adapter-fs is the Brigade filesystem adapter: a second BAP/1 implementation whose backend is a directory on disk (plan P1-5).	Command brigade-adapter-fs is the Brigade filesystem adapter: a second BAP/1 implementation whose backend is a directory on disk (plan P1-5).
brigade-conformance command Command brigade-conformance runs the BAP/1 conformance suite (C-01..C-43, plan 9.2) against any adapter.	Command brigade-conformance runs the BAP/1 conformance suite (C-01..C-43, plan 9.2) against any adapter.
brigade-fake-adapter command Command brigade-fake-adapter is a scripted BAP/1 adapter used only as a test fixture (plan 9.5; brief section 2.10).	Command brigade-fake-adapter is a scripted BAP/1 adapter used only as a test fixture (plan 9.5; brief section 2.10).
brigade-schema command Command brigade-schema writes the Brigade Adapter Protocol JSON Schema document to stdout.	Command brigade-schema writes the Brigade Adapter Protocol JSON Schema document to stdout.
docs
research/plugin-bootstrap-cli.files command
internal
adapterkit Package adapterkit is the shared plumbing every Brigade adapter uses (plan P1-3): the bounded stdin document reader with its TTY refusal, the result printer (the only place under internal/ that may write protocol output to os.Stdout, plan 7.3), the XDG directory resolution of 3.2, the atomic 0600 file writer and the strict 0600 reader (U-10), the advisory flock helper on a sidecar file with its 10 s bound (5.1, corrected by E0-6), the O_EXCL pidfile helper with compare-then-delete removal (E0-5), and the profile file schema of 5.2.	Package adapterkit is the shared plumbing every Brigade adapter uses (plan P1-3): the bounded stdin document reader with its TTY refusal, the result printer (the only place under internal/ that may write protocol output to os.Stdout, plan 7.3), the XDG directory resolution of 3.2, the atomic 0600 file writer and the strict 0600 reader (U-10), the advisory flock helper on a sidecar file with its 10 s bound (5.1, corrected by E0-6), the O_EXCL pidfile helper with compare-then-delete removal (E0-5), and the profile file schema of 5.2.
adapterkit/log Package log is Brigade's one redacting slog handler (plan 7.3, T12): every diagnostic line an adapter or the harness writes to stderr or a log file goes through it, because the harness captures adapter stderr at debug level and a leak here puts a credential in a 0600-but-still- on-disk log file (U-09, U-23).	Package log is Brigade's one redacting slog handler (plan 7.3, T12): every diagnostic line an adapter or the harness writes to stderr or a log file goes through it, because the harness captures adapter stderr at debug level and a leak here puts a credential in a 0600-but-still- on-disk log file (U-09, U-23).
adapters/fs Package fs implements the Brigade filesystem adapter: a second BAP/1 implementation whose backend is a directory on disk.	Package fs implements the Brigade filesystem adapter: a second BAP/1 implementation whose backend is a directory on disk.
adapters/supabase Package supabase is the bundled Brigade adapter for a Supabase backend (plan section 5, protocol docs/protocol-v1.md): one anonymous GoTrue principal per profile, every write through the `brigade.*` RPCs of the finished migrations over PostgREST, and a Phoenix channel over coder/websocket for the watch.	Package supabase is the bundled Brigade adapter for a Supabase backend (plan section 5, protocol docs/protocol-v1.md): one anonymous GoTrue principal per profile, every write through the `brigade.*` RPCs of the finished migrations over PostgREST, and a Phoenix channel over coder/websocket for the watch.
app Package app is the multi-call dispatch seam of the shipped `brigade` binary: one process image serving the human command table, the Claude Code lifecycle hooks, the detached watcher and the bundled adapters (D35, 7.1).	Package app is the multi-call dispatch seam of the shipped `brigade` binary: one process image serving the human command table, the Claude Code lifecycle hooks, the detached watcher and the bundled adapters (D35, 7.1).
buildinfo Package buildinfo carries the version string of the running binary.	Package buildinfo carries the version string of the running binary.
cli Package cli holds the `brigade` command table, the interspersed-flag parser of plan 7.3, the usage and help output, and the mapping from a command failure to a process exit status (4.6).	Package cli holds the `brigade` command table, the interspersed-flag parser of plan 7.3, the usage and help output, and the mapping from a command failure to a process exit status (4.6).
conformance Package conformance is the BAP/1 conformance suite of plan 9.2: the library behind the dev binary cmd/brigade-conformance and behind the `go test` subtests of suite_test.go (TestConformanceFS/C-25), so that `go test ./...` stays a complete gate on its own.	Package conformance is the BAP/1 conformance suite of plan 9.2: the library behind the dev binary cmd/brigade-conformance and behind the `go test` subtests of suite_test.go (TestConformanceFS/C-25), so that `go test ./...` stays a complete gate on its own.
conformance/cases Package cases holds the conformance cases of plan 9.2, one file per case, coded against the T API of internal/conformance.	Package cases holds the conformance cases of plan 9.2, one file per case, coded against the T API of internal/conformance.
harness/adapterclient Package adapterclient is the one place the harness spawns an adapter child (plan 3.4, 4.1, 6.6; brief section 2.2).	Package adapterclient is the one place the harness spawns an adapter child (plan 3.4, 4.1, 6.6; brief section 2.2).
harness/backoff Package backoff is the retry arithmetic of plan 6.6 and 6.8 item 7 (U-16): an exponential schedule with jitter for the watcher's restart of its `message watch` child (1 s doubling to a 30 s cap) and for adapter errors (1 s doubling to a 5 min cap), and the retryability predicate — only `rate_limited` and `unavailable` (and a crash or signal, which adapterkit.Spawn already maps to `unavailable`) are ever retried; `invalid_input`, `unauthorized`, `loop_detected` and every other code are terminal.	Package backoff is the retry arithmetic of plan 6.6 and 6.8 item 7 (U-16): an exponential schedule with jitter for the watcher's restart of its `message watch` child (1 s doubling to a 30 s cap) and for adapter errors (1 s doubling to a 5 min cap), and the retryability predicate — only `rate_limited` and `unavailable` (and a crash or signal, which adapterkit.Spawn already maps to `unavailable`) are ever retried; `invalid_input`, `unauthorized`, `loop_detected` and every other code are terminal.
harness/bootstrap Package bootstrap holds no Go code that ships.	Package bootstrap holds no Go code that ships.
harness/commands Package commands implements the human and model command surface of the `brigade` binary (plan 6.4): `sessions`, `send`, `whoami`, `team members`, the hold policy's `inbox` and `inbox release` (inbox.go), and the terminal pass-through of `team create\|join\|leave` and `profile init\|status\|reset\|revoke-credentials`.	Package commands implements the human and model command surface of the `brigade` binary (plan 6.4): `sessions`, `send`, `whoami`, `team members`, the hold policy's `inbox` and `inbox release` (inbox.go), and the terminal pass-through of `team create\|join\|leave` and `profile init\|status\|reset\|revoke-credentials`.
harness/config Package config is the only harness package that reads configuration from the environment (plan 3.2, 6.5, 7.3; forbidigo enforces the static half).	Package config is the only harness package that reads configuration from the environment (plan 3.2, 6.5, 7.3; forbidigo enforces the static half).
harness/e2e Package e2e holds the end-to-end harness tests of plan 9.5 (the integrator's half of P3-3/P3-4/P3-5, E2E-01's fs precursor): the built `brigade` binary and the built fs adapter, driven as real processes — the terminal pass-through that creates and joins a team, the three lifecycle hooks with their stdin documents and session environments, the REAL detached watcher the SessionStart hook spawns, `brigade send` from a second principal's own session, the frame arriving at a fake inbox socket, and the token appearing in no file and on no argv afterwards (U-25's whole-tree grep).	Package e2e holds the end-to-end harness tests of plan 9.5 (the integrator's half of P3-3/P3-4/P3-5, E2E-01's fs precursor): the built `brigade` binary and the built fs adapter, driven as real processes — the terminal pass-through that creates and joins a team, the three lifecycle hooks with their stdin documents and session environments, the REAL detached watcher the SessionStart hook spawns, `brigade send` from a second principal's own session, the frame arriving at a fake inbox socket, and the token appearing in no file and on no argv afterwards (U-25's whole-tree grep).
harness/frame Package frame renders and parses the `<brigade-message>` frame of plan 6.7 — the text a receiving model actually reads — in the shape D19 settled on (variant C, decided by E0-3 at an interactive sitting on 2026-08-31): Brigade's own frame, nested by Wrap inside the native `<cross-session-message from-name="…">` wrapper that the Claude Code harness consumes into its "Message from @<name>" attribution.	Package frame renders and parses the `<brigade-message>` frame of plan 6.7 — the text a receiving model actually reads — in the shape D19 settled on (variant C, decided by E0-3 at an interactive sitting on 2026-08-31): Brigade's own frame, nested by Wrap inside the native `<cross-session-message from-name="…">` wrapper that the Claude Code harness consumes into its "Message from @<name>" attribution.
harness/hook Package hook implements the three Claude Code lifecycle hooks of plan 6.3 — `brigade hook session-start`, `brigade hook prompt` and `brigade hook session-end` — the processes Claude Code runs from plugin/hooks/hooks.json with a JSON document on stdin and the session's environment (6.5).	Package hook implements the three Claude Code lifecycle hooks of plan 6.3 — `brigade hook session-start`, `brigade hook prompt` and `brigade hook session-end` — the processes Claude Code runs from plugin/hooks/hooks.json with a JSON document on stdin and the session's environment (6.5).
harness/inbound Package inbound is the receive-side pipeline of plan 6.8 — the ordered controls every `message` event passes before it is framed and handed to an injector — implemented once, PURE, so that P3-5's watcher (socket post or `--sink`) and P3-4's prompt-hook poll (6.3) run the same code:	Package inbound is the receive-side pipeline of plan 6.8 — the ordered controls every `message` event passes before it is framed and handed to an injector — implemented once, PURE, so that P3-5's watcher (socket post or `--sink`) and P3-4's prompt-hook poll (6.3) run the same code:
harness/pidfile Package pidfile is the watcher's single-instance guard (plan 6.6, the `${BRIGADE_STATE_DIR}/watchers/<claude_pid>.json` row of 3.2, corrected by E0-5 items 1 and 3; package tree 7.1).	Package pidfile is the watcher's single-instance guard (plan 6.6, the `${BRIGADE_STATE_DIR}/watchers/<claude_pid>.json` row of 3.2, corrected by E0-5 items 1 and 3; package tree 7.1).
harness/policy Package policy decides the inbound policy a session runs under — the step 3 of plan 6.8, with the native `crossSessionInbound` scan of 6.10 folded in — and is the ONLY implementation of that decision: the SessionStart hook (P3-4) calls it to fill the by-pid map's `inbound`, the prompt-hook poll and the watcher's pipeline (internal/harness/ inbound) run under the value it produced.	Package policy decides the inbound policy a session runs under — the step 3 of plan 6.8, with the native `crossSessionInbound` scan of 6.10 folded in — and is the ONLY implementation of that decision: the SessionStart hook (P3-4) calls it to fill the by-pid map's `inbound`, the prompt-hook poll and the watcher's pipeline (internal/harness/ inbound) run under the value it produced.
harness/registry Package registry reads Claude Code's own session registry, best effort and read-only (plan 6.5, A.3): $CLAUDE_CONFIG_DIR/sessions/<pid>.json, an undocumented file that carries the session's display name (set with --name or /rename), its busy/idle status, the inbox socket path and the Claude Code version.	Package registry reads Claude Code's own session registry, best effort and read-only (plan 6.5, A.3): $CLAUDE_CONFIG_DIR/sessions/<pid>.json, an undocumented file that carries the session's display name (set with --name or /rename), its busy/idle status, the inbox socket path and the Claude Code version.
harness/sessionmap Package sessionmap is the hook-written state that binds a Claude Code process to its Brigade session (plan 3.2, 6.5): the by-pid map at ${stateDir}/sessions/by-pid/<claude_pid>.json, from which the session-bound commands and the watcher resolve EVERYTHING (profile, config dir, adapter argv, Brigade session id, team, socket path), and the by-native map at ${stateDir}/sessions/by-native/<claude_session_id>.json, which lets a later `claude --resume` re-open the same Brigade session (3.7).	Package sessionmap is the hook-written state that binds a Claude Code process to its Brigade session (plan 3.2, 6.5): the by-pid map at ${stateDir}/sessions/by-pid/<claude_pid>.json, from which the session-bound commands and the watcher resolve EVERYTHING (profile, config dir, adapter argv, Brigade session id, team, socket path), and the by-native map at ${stateDir}/sessions/by-native/<claude_session_id>.json, which lets a later `claude --resume` re-open the same Brigade session (3.7).
harness/socketpost Package socketpost is the inbox socket client of plan 6.7 and A.2: it writes one frame into a Claude Code session's `CLAUDE_CODE_MESSAGING_SOCKET` as the two NDJSON lines the harness reads — an auth line carrying the session's messaging token, then a user line carrying the content — and closes.	Package socketpost is the inbox socket client of plan 6.7 and A.2: it writes one frame into a Claude Code session's `CLAUDE_CODE_MESSAGING_SOCKET` as the two NDJSON lines the harness reads — an auth line carrying the session's messaging token, then a user line carrying the content — and closes.
harness/watch Package watch is the detached inbound watcher of plan 6.6 and 6.8 — the process `brigade hook session-start` spawns with Setsid and the hook-built environment, and which then supervises the adapter's `message watch` child, runs every `message` event through the shared receive-side pipeline (internal/harness/inbound), injects each frame into the Claude Code session's inbox socket (internal/harness/socketpost) or, in the test harness's sink mode, appends it to a file, acknowledges only what was injected, heartbeats the Brigade session, and exits when the Claude Code process, the by-pid map or a SIGTERM says the session is over.	Package watch is the detached inbound watcher of plan 6.6 and 6.8 — the process `brigade hook session-start` spawns with Setsid and the hook-built environment, and which then supervises the adapter's `message watch` child, runs every `message` event through the shared receive-side pipeline (internal/harness/inbound), injects each frame into the Claude Code session's inbox socket (internal/harness/socketpost) or, in the test harness's sink mode, appends it to a file, acknowledges only what was injected, heartbeats the Brigade session, and exits when the Claude Code process, the by-pid map or a SIGTERM says the session is over.
procutil Package procutil answers one question about a process id — is the process alive, and which incarnation of the pid is it — for the watcher's single-instance guard (plan 6.6, corrected by E0-5; package tree 7.1).	Package procutil answers one question about a process id — is the process alive, and which incarnation of the pid is it — for the watcher's single-instance guard (plan 6.6, corrected by E0-5; package tree 7.1).
protocol Package protocol implements the wire layer of the Brigade Adapter Protocol, version 1 (BAP/1, plan section 4): a Go type for every JSON shape of 4.4 with a hand-written Validate method, the 4.6 error taxonomy with its exit-code map, and the protocol constants of 4.4.1.	Package protocol implements the wire layer of the Brigade Adapter Protocol, version 1 (BAP/1, plan section 4): a Go type for every JSON shape of 4.4 with a hand-written Validate method, the 4.6 error taxonomy with its exit-code map, and the protocol constants of 4.4.1.
protocol/schema Package schema generates the JSON Schema (draft 2020-12) document for the wire shapes of the Brigade Adapter Protocol v1 (plan 7.3): one document with a $defs entry per protocol type, reflected from the Go structs of internal/protocol with invopop/jsonschema and then patched where reflection cannot see the protocol's rules — the C-23 forbidden SendRequest members become `false` property schemas, pointer-typed members become nullable, and the 4.4.1 code-point caps become maxLength.	Package schema generates the JSON Schema (draft 2020-12) document for the wire shapes of the Brigade Adapter Protocol v1 (plan 7.3): one document with a $defs entry per protocol type, reflected from the Go structs of internal/protocol with invopop/jsonschema and then patched where reflection cannot see the protocol's rules — the C-23 forbidden SendRequest members become `false` property schemas, pointer-typed members become nullable, and the 4.4.1 code-point caps become maxLength.
testutil Package testutil holds the helpers the Brigade test tree shares.	Package testutil holds the helpers the Brigade test tree shares.
testutil/fakeadapter Package fakeadapter is a scripted BAP/1 adapter used as a test fixture (plan 9.5; brief section 2.10).	Package fakeadapter is a scripted BAP/1 adapter used as a test fixture (plan 9.5; brief section 2.10).
testutil/fakeregistry Package fakeregistry is the test double for Claude Code's session registry (plan 9.5, A.3): an fstest.MapFS holding <pid>.json entries in the observed shape, served through the fs.FS the registry reader takes, wrapped in a recorder that FAILS THE TEST when any name ending in .key is opened and records every name that was.	Package fakeregistry is the test double for Claude Code's session registry (plan 9.5, A.3): an fstest.MapFS holding <pid>.json entries in the observed shape, served through the fs.FS the registry reader takes, wrapped in a recorder that FAILS THE TEST when any name ending in .key is opened and records every name that was.
testutil/fakesock Package fakesock is the fake inbox socket of plan 9.5: a unix-domain server standing in for a Claude Code session's `CLAUDE_CODE_MESSAGING_SOCKET`, so the socket poster (6.7, U-17, U-19, U-20) and later the watcher can be tested against a real socket with no Claude process anywhere near.	Package fakesock is the fake inbox socket of plan 9.5: a unix-domain server standing in for a Claude Code session's `CLAUDE_CODE_MESSAGING_SOCKET`, so the socket poster (6.7, U-17, U-19, U-20) and later the watcher can be tested against a real socket with no Claude process anywhere near.
testutil/tscmd Package tscmd holds the custom testscript commands the Brigade scripts use.	Package tscmd holds the custom testscript commands the Brigade scripts use.