brigade-cli 0.5.0__py3-none-any.whl

brigade/templates/memory/cards/memory-scanner.md

@@ -0,0 +1,98 @@
+---
+topic: memory-scanner
+category: foundation
+tags: [memory, sweep, session-review, promotion, daily-logs]
+---
+
+# Memory Scanner
+
+The memory scanner is the upstream half of the handoff flow. It is a session-review pass that distills durable knowledge from recent activity (sessions across all your harnesses, daily logs, chat archives) and persists it into canonical memory through the handoff path.
+
+```text
+sessions               daily session logs       chat archives
+(Claude Code,            (memory/                (discrawl,
+ Codex, OpenClaw,         YYYY-MM-DD.md)          slackcrawl, ...)
+ ACP threads)
+        \                     |                    /
+         \                    |                   /
+          v                   v                  v
+                       ┌────────────────┐
+                       │ memory scanner │  cron (typical: nightly)
+                       │ (session-review│
+                       │  agent)        │
+                       └────────┬───────┘
+                                |
+                                v
+              .claude/memory-handoffs/*.md   OR   direct card writes
+                                |                       (only when high-confidence)
+                                v
+                         brigade ingest
+                                |
+                                v
+              memory/cards/, TOOLS.md, USER.md, rules/, .learnings/
+```
+
+## What it does
+
+A real implementation (typical nightly cadence):
+
+1. **List recent sessions.** Last 12-24 hours, across all harnesses connected to canonical memory.
+2. **Skip noise.** Cron-spawned sessions, heartbeat/reminder-only sessions, empty subagent shells, pure delivery mirror / announce-only sessions.
+3. **Prioritize real human-facing sessions first.** Discord, WhatsApp, Telegram, Slack, manual ACP threads. These are where decisions, corrections, and preferences actually land.
+4. **Start with summaries.** Only fetch deeper history for sessions that clearly contain durable decisions, corrections, preferences, project changes, new tooling facts, or new published outputs.
+5. **Cap deep review** to the top N most promising sessions (typical: 8) unless there is an obvious reason to exceed it.
+6. **Avoid duplication.** Do not re-promote facts that already exist as cards or in daily-log entries.
+
+## What gets persisted
+
+- **Update existing cards** when facts changed.
+- **Create new cards** for durable workflows, infra facts, project state, or repeatable lessons.
+- **Append concise timestamped notes** to the relevant daily log if the info is recent and session-specific.
+- **Update `MEMORY.md`** only if the index itself needs to change (new card category, major architecture shift).
+
+## What does not get persisted
+
+- Banter, casual replies, "yeah" / "ok" exchanges.
+- Anything already covered by an existing card.
+- Speculation, reflections, or unverified findings.
+- Raw transcripts. Transcripts stay in their archive; the scanner produces summary writes, not copies.
+
+## Output format
+
+The scanner reports back on what it did:
+
+```text
+Sessions listed: N
+Sessions deeply reviewed: N
+Sessions with meaningful content: N
+Persisted: [bullets]
+Skipped: [short bullets]
+Net result: [1-3 bullets]
+```
+
+This gives you an audit trail and a heartbeat for the scanner itself. If "persisted" is empty for a week, either nothing durable happened or the scanner stopped firing.
+
+## Scheduling
+
+Common cadence (matches reference cookbook): nightly at quiet hours, after [pipeline-standups](pipeline-standups.md) have run and the day's activity has settled.
+
+Avoid promoting during active sessions because card writes invalidate prefix caches.
+
+## Implementation surface
+
+`brigade` ships the contract; it does not ship the scanner agent itself. Wire it as:
+
+- a cron job that spawns an isolated agent session with a "review last 12h and persist durable facts" prompt
+- the prompt should embed the skip-rules and cost controls above
+- output goes either directly to `memory/cards/*.md` (if your harness can write there) or through `.claude/memory-handoffs/` for the conservative ingester to route
+
+## Relationship to Memory Care
+
+The memory scanner captures new durable knowledge. The memory-care staleness loop reviews old cards for drift. Run both: scanner for new facts, staleness checker for old facts that may no longer be true. See [memory-care-staleness](memory-care-staleness.md).
+
+## Anti-patterns
+
+- **Auto-promoting raw session fragments into `MEMORY.md`.** The index loads on every session; appending fragments nightly bloats it past the bootstrap budget and turns the on-load cache cost into a monthly tax. Write cards instead.
+- **Persisting reflections as facts.** The scanner reads sessions and produces summaries of decisions that happened, not generated commentary on what might have. Promoted findings must be evidence-backed.
+- **Reviewing its own output.** The scanner must skip cron-spawned sessions, heartbeats, announce-only noise, and prior scanner runs. Otherwise it spirals.
+- **Skipping the handoff gates when uncertain.** When confidence is below the auto-promote bar, route through `.claude/memory-handoffs/` and let the ingester apply the same conservative rules everything else gets.

brigade/templates/memory/cards/multi-workspace-handoff-admin.md

@@ -0,0 +1,63 @@
+---
+topic: multi-workspace-handoff-admin
+category: workflow
+tags: [memory, handoff, multi-workspace, admin]
+---
+
+# Multi-Workspace Handoff Admin
+
+When one person administers multiple agent homes, only one workspace should own canonical durable memory. Other workspaces can run local sessions, keep local context, and write repo-local notes, but durable facts should flow back to the owner through Memory Handoffs.
+
+## Shape
+
+```text
+managed workspace A      managed workspace B      repo-local sessions
+  .claude/                 .claude/                 .claude/
+    memory-handoffs/         memory-handoffs/         memory-handoffs/
+          \                         |                         /
+           \                        |                        /
+            v                       v                       v
+          staging inboxes on the canonical memory owner
+                           |
+                           v
+                    brigade ingest
+                           |
+                           v
+              memory/cards/, TOOLS.md, USER.md, rules/, .learnings/
+```
+
+## Why
+
+Multiple active setups drift unless the agents can tell each other what happened. A secondary workspace should not silently become a second source of truth. Its job is to emit handoffs that say what changed, what evidence supports it, and what the canonical owner should remember.
+
+## Pull Pattern
+
+Run a small trusted sync from the canonical memory owner:
+
+```bash
+rsync -a --remove-source-files \
+  --include='*.md' --exclude='processed/***' --exclude='*' \
+  <remote>:<workspace>/.claude/memory-handoffs/ \
+  <canonical-workspace>/pipeline/incoming-handoffs/<remote-label>/
+```
+
+Then include each staging directory in the ingest loop. Keep remote labels generic, such as `laptop`, `homelab`, `client-a`, or `research-vm`.
+
+## Admin Rules
+
+- Pull into staging first, then ingest. Do not ingest directly over SSH.
+- Remove remote source files only after successful transfer to the canonical host.
+- Exclude `processed/` so archives do not churn forever.
+- Preserve the original handoff text for review. The canonical owner should see exactly what the remote harness wrote.
+- Use per-source labels so failures can be traced to the workspace that produced them.
+- Surface non-empty pulls to the agents that need to know. A handoff is both memory input and a coordination signal.
+
+## Verification
+
+```bash
+find pipeline/incoming-handoffs -name '*.md' -not -path '*/processed/*'
+brigade ingest --target . --dry-run
+ls memory/handoff-inbox/ 2>/dev/null | wc -l
+```
+
+If no remote handoffs arrive for a week while remote work is happening, the remote workspace probably lacks the closeout instruction, the sync is broken, or the files are landing in the wrong repo.

brigade/templates/memory/cards/obsidian-notes.md

@@ -0,0 +1,82 @@
+---
+topic: obsidian-notes
+category: foundation
+tags: [obsidian, notes, callouts, vault, sync, knowledge-capture]
+---
+
+# Obsidian Notes (Verbatim + Concept)
+
+The `/note` skill captures a session's durable knowledge as an Obsidian-formatted markdown file in `~/notes/`, then syncs it to the user's configured Obsidian vault inbox. It is the user-facing complement to the [memory-scanner](memory-scanner.md): cards are for the agent, Obsidian notes are for the human.
+
+Full skill spec lives in `skills/note/SKILL.md`. This card explains *when* to use it and the two modes you must distinguish before writing.
+
+## Two modes
+
+| Mode | Use when | Output style |
+|------|----------|--------------|
+| **Verbatim fix** | Troubleshooting, root-causing, post-incident. Future-you needs the exact commands to reproduce the fix. | `[!bug]` -> `[!success]` -> "How it works" -> `[!warning]` gotchas. Heavy on exact strings and runnable code. |
+| **Summarize / concept** | Learning, capturing a workflow, documenting a system. The reader needs to understand *why* before they trust the *how*. | Overview -> How it works -> Example -> Tips and gotchas. More prose than callouts. |
+
+Ask the user which mode applies if it is not obvious. Default to verbatim for bugs and to concept for everything else.
+
+## Callout vocabulary
+
+Obsidian callouts make the critical parts stick out without breaking prose flow. Use them sparingly. A note should be mostly regular markdown with callouts highlighting the parts that matter.
+
+| Callout | Use for |
+|---------|---------|
+| `[!bug]` | Problems, errors, symptoms |
+| `[!success]` | Solutions, fixes, what worked |
+| `[!tip]` | Helpful hints, shortcuts |
+| `[!warning]` | Dangers, things that can break |
+| `[!info]` | Background context |
+| `[!note]` | General annotations |
+| `[!example]` | Practical examples, runnable commands |
+| `[!question]` | Open questions, things to investigate |
+
+Syntax:
+
+```markdown
+> [!success] Optional title
+> Content.
+> Multi-line is fine.
+```
+
+## YAML frontmatter (required)
+
+```yaml
+---
+tags:
+  - tag1
+  - tag2
+created: YYYY-MMM-DD
+---
+```
+
+- 3-5 lowercase, hyphenated tags.
+- Date format `YYYY-MMM-DD` (e.g. `2026-Jan-24`). Not ISO. The vault sorts on this.
+
+## Sync target
+
+Three common shapes; the user picks one and documents it in `TOOLS.md`:
+
+1. **Google Drive + rclone bisync.** `~/notes/` writes propagate to the vault inbox on the next bisync timer fire. Most common for cross-machine vaults.
+2. **Local Obsidian vault on disk.** `cp ~/notes/<slug>.md ~/Obsidian/<Vault>/<Inbox>/`. Same machine only.
+3. **Direct rclone copy.** `rclone copy ~/notes/<slug>.md "gdrive:My Drive/<VaultPath>/<Inbox>/"`. One-shot, no bisync.
+
+If no sync target is configured, leave the file in `~/notes/` and surface the path. Do not invent a sync path.
+
+## When NOT to use /note
+
+- **Durable agent-facing knowledge** -> memory card via the handoff flow, not a vault note. Cards are searched semantically by the agent every session; vault notes are read by humans.
+- **Operational runbook detail** -> `TOOLS.md` or a `rules/*.md` file. The publish gate and memory ingester treat those as canonical.
+- **Sensitive personal context** -> not in `~/notes/` if the vault syncs to a cloud provider. Use the local-only sync path or skip the note entirely.
+
+## Relationship to the memory system
+
+Vault notes are human-readable references; memory cards are agent-readable durable knowledge. The two have different shapes and different audiences:
+
+- A `/note` is written for future-you reading on a phone at a coffee shop.
+- A memory card is written for the agent to retrieve via `memory_search` mid-session.
+
+When both apply, write the card first (through the handoff flow) and then optionally write a `/note` if the user will want to reference it outside the workspace. Do not duplicate content.

brigade/templates/memory/cards/pipeline-standups.md

@@ -0,0 +1,88 @@
+---
+topic: pipeline-standups
+category: foundation
+tags: [standups, recap, cron, cross-harness, daily-rhythm]
+---
+
+# Pipeline Standups (Night + Morning)
+
+Two short cron-driven sessions that produce a cross-harness daily rhythm: a nightshift standup that summarizes the day before bed, and a morning report that frames the day ahead. They are not memory writes; they are operational summaries delivered to a chat channel so the user can review state at a glance.
+
+## Why two
+
+A single end-of-day or start-of-day digest works for a single-harness setup. With sessions running across multiple harnesses (Claude Code, Codex, OpenClaw, ACP threads), the user needs a recap that spans them all - and a morning brief that picks up where last night left off.
+
+- **Night (typical: 21:00 local).** What got done today. What is uncommitted. What is queued.
+- **Morning (typical: 08:00 local).** Dev servers up/down. Yesterday's highlights. Today's priorities. Any overnight alerts.
+
+## Nightshift standup
+
+Prompt shape:
+
+```text
+Nightshift standup. Read these files and produce a brief status report:
+
+1. Read MEMORY.md (current state section)
+2. Read the latest memory/YYYY-MM-DD.md daily log
+3. Check git status across active repos under your work tree
+
+Produce a concise report:
+- What was done today
+- Any uncommitted/unpushed work
+- Active backlog items
+- Suggested priorities for tonight
+
+Keep it to 10-15 lines. No fluff.
+```
+
+Delivered to a single chat channel (the user's main work channel). Skip the headers, lead with bullets.
+
+## Morning report
+
+Prompt shape:
+
+```text
+Morning report. Read these and produce a brief daily briefing:
+
+1. Read MEMORY.md (key sections)
+2. Read the latest memory/YYYY-MM-DD.md
+3. Check for any failed cron jobs or errors overnight
+4. Probe configured dev servers / services for up/down state
+
+Produce:
+- Dev server status (X/Y online)
+- Yesterday's highlights
+- Today's priorities
+- Any alerts
+
+Keep it brief.
+```
+
+The dev-server probe is the differentiator: it surfaces silent process death between sessions without requiring the user to ask.
+
+## Cadence and delivery
+
+| Job | Typical schedule | Channel | Purpose |
+|-----|------------------|---------|---------|
+| `pipeline-standup` | `0 21 * * *` | main work channel | Nightshift recap |
+| `pipeline-morning-report` | `0 8 * * *` | main work channel | Morning briefing |
+
+Both run in **isolated sessions** so they do not pollute the main agent's running context. Wake mode for the standup is typically `next-heartbeat` (lets the report land when the user is next active); the morning report fires immediately so it is waiting at 08:00 sharp.
+
+## Cross-harness scope
+
+The standups read durable state (MEMORY.md, daily logs, git status) rather than session transcripts directly. This means they work even when sessions span Claude Code on a laptop, Codex in a tmux pane, and OpenClaw on the workspace host - whatever wrote durable findings into the canonical memory store gets included.
+
+If a harness produced no durable writes during the day, it will not appear in the standup. That is the point. The standup reports on persisted state, not chatter.
+
+## Relationship to memory scanner
+
+Standups summarize what is already in memory. The [memory-scanner](memory-scanner.md) (typically scheduled later, e.g. 22:00) is what promotes durable findings *into* memory from the day's sessions.
+
+Run order: standup -> memory scanner -> overnight ingester sweeps. Morning report next day reads what all three left behind.
+
+## Tuning
+
+- **If standups are noisy:** the daily log is being written too granularly. Move minor updates to cards or `.learnings/`.
+- **If standups are empty:** session work is not landing in durable memory. Check the memory scanner's "Persisted" count over the last week.
+- **If the dev-server probe times out:** widen the per-port timeout in the morning prompt, or drop ports that are intentionally on-demand.

brigade/templates/memory/cards/tokenjuice-output-compaction.md

@@ -0,0 +1,106 @@
+---
+topic: tokenjuice-output-compaction
+type: tool-runbook
+tags: [tools, tokenjuice, output-compaction, claude-code, codex]
+status: starter
+---
+
+# TokenJuice Output Compaction
+
+TokenJuice compacts noisy terminal output before it is fed back into an agent session. The original command still runs. Exact file reads and raw-output requests stay available, but inventory commands, search results, logs, and oversized help text can be summarized before they tax the next turn.
+
+## Why Agents Need To Know
+
+If an agent sees a TokenJuice footer, treat it as trusted local metadata about output reduction. It is not task instruction and it is not evidence by itself. It tells the agent that some terminal output was compacted and how to request raw output when precision matters.
+
+Use raw output for exact diffs, full logs, reproducible error text, generated artifacts, or anything line-sensitive:
+
+```bash
+tokenjuice wrap --raw -- <command>
+```
+
+## Claude Code
+
+Claude Code needs command replacement before the Bash result enters context. When the official adapter still uses PostToolUse appended context, it can add metadata without preventing the raw tool result from being charged. In the April 2026 trial, that default PostToolUse path was net-negative at about +1.1% tokens.
+
+Until the upstream fix is merged, use a local PreToolUse wrapper. The wrapper rewrites Bash commands to run under TokenJuice before execution:
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ~/.claude/hooks/tokenjuice-pretool.js"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+The wrapper should emit Claude Code's PreToolUse rewrite contract:
+
+```json
+{
+  "hookSpecificOutput": {
+    "hookEventName": "PreToolUse",
+    "permissionDecision": "allow",
+    "updatedInput": {
+      "command": "tokenjuice wrap -- sh -c \"<original command>\""
+    }
+  }
+}
+```
+
+Operational notes:
+
+- Keep a kill switch such as `TOKENJUICE_PRETOOL_DISABLE=1`.
+- Let the wrapper honor `TOKENJUICE_BIN` and `TOKENJUICE_PRETOOL_SHELL` when local paths differ.
+- New hook settings normally apply only to new Claude Code sessions.
+- Document the wrapper in `CLAUDE.md` so agents do not mistake the footer for prompt injection.
+
+## Codex
+
+Codex can use TokenJuice through its normal hook path because the harness honors PostToolUse substitution. Install and verify with:
+
+```bash
+tokenjuice install codex
+tokenjuice doctor hooks
+```
+
+Codex hook feature flags have changed across releases. Older configs used `codex_hooks`; newer configs use `hooks`. Do not trust old setup notes blindly. Run `tokenjuice doctor hooks` and fix the config it reports for the installed CLI version.
+
+## Savings Model
+
+TokenJuice always reports output compaction. Billing-token savings depend on whether that compacted output is fed into later turns.
+
+Observed local output stats in May 2026:
+
+- 17.1k compacted entries
+- 83.6m raw output chars
+- 24.7m reduced output chars
+- 58.9m chars avoided, about 70% output reduction
+
+Measured harness trials:
+
+- Claude Code PreToolUse wrapper: about -7.8% tokens in the April 2026 paired trial.
+- Claude Code default PostToolUse adapter: about +1.1% tokens in the same trial, because raw output still entered context.
+- Codex v0.5.0 paired trial: about -8.8% clean-run token reduction after reducer and hook fixes.
+- Codex GPT-5.5 one-turn gauntlet: about +0.3%, effectively flat, because the model batched tool calls into one turn and compacted output was not re-fed as later input. Per-command output reductions still remained large.
+
+Practical read: TokenJuice is most valuable for repeated terminal exploration where tool results become future context. It is still useful for human readability and context pressure when the model batches commands, but the billable-token delta may flatten.
+
+## Verification
+
+```bash
+tokenjuice --version
+tokenjuice stats
+tokenjuice doctor hooks
+tokenjuice wrap -- git status --short
+tokenjuice wrap --raw -- git status --short
+```

brigade/templates/openclaw/README.md

@@ -0,0 +1,40 @@
+# OpenClaw Fragments
+
+These are JSON fragments meant to be inspected and merged by hand into your `~/.openclaw/openclaw.json`. `brigade` does not mutate your live OpenClaw config; it generates fragments and lets you review them first.
+
+## Files
+
+| Fragment | Purpose |
+|----------|---------|
+| `model-aliases.openclaw.json` | Suggested alias map under `agents.defaults.models`. |
+| `ollama-memory-search.openclaw.json` | Local Ollama embeddings for memory search. |
+| `acp-escalation.openclaw.json` | ACP escalation lane via the `acpx` plugin. |
+
+## Merge
+
+`jq` is the safest way to merge a fragment into a live config without losing surrounding keys:
+
+```bash
+# Inspect first
+jq . brigade-fragments/model-aliases.openclaw.json
+
+# Merge (replace MERGE_PATH and re-check before saving)
+jq -s '.[0] * .[1]' ~/.openclaw/openclaw.json brigade-fragments/model-aliases.openclaw.json \
+  > /tmp/openclaw.json.merged
+diff ~/.openclaw/openclaw.json /tmp/openclaw.json.merged
+mv /tmp/openclaw.json.merged ~/.openclaw/openclaw.json
+```
+
+## Verification
+
+```bash
+brigade doctor --target ~/.openclaw/workspace --harness openclaw
+```
+
+The doctor reports which fragments your live config has picked up and which checks still need manual work.
+
+## Gotchas
+
+- Aliases referencing `<provider/...>` placeholders must be replaced with real ids before merging.
+- The ACP fragment assumes you have already installed `acpx` (see [solos-cookbook/ai-stack/acp-claude-code.md](https://github.com/solomonneas/solos-cookbook) for the install path).
+- `openclaw doctor` (the OpenClaw tool, not `brigade doctor`) has historically rewritten `openai-codex/*` prefixes on certain versions. If you use OAuth-only auth, audit `agents.defaults.model.primary` after any OpenClaw upgrade.

brigade/templates/openclaw/acp-escalation.openclaw.json

@@ -0,0 +1,33 @@
+{
+  "_comment": [
+    "FRAGMENT - inspect before merging into your openclaw.json.",
+    "",
+    "ACP escalation wrapper: route harder reasoning tasks to Claude Code via ACP",
+    "while keeping the main agent on a cheaper coder model.",
+    "",
+    "Requires acpx plugin: https://github.com/agentclientprotocol/claude-agent-acp",
+    "",
+    "Replace placeholders before merging:",
+    "  <provider/main-model-id>      - your main coder model alias or full id",
+    "  <provider/escalation-model>   - the model id that routes through ACP"
+  ],
+  "plugins": {
+    "entries": {
+      "acpx": {
+        "command": "${HOME}/.openclaw/vendor/acpx/node_modules/.bin/acpx"
+      }
+    }
+  },
+  "agents": {
+    "list": {
+      "escalation": {
+        "model": "<provider/escalation-model>",
+        "description": "ACP-routed reasoning lane. Use for refactors, architecture review, academic work.",
+        "tools": {
+          "allow": ["group:fs", "group:runtime", "sessions_*"]
+        },
+        "thinkingDefault": "xhigh"
+      }
+    }
+  }
+}

brigade/templates/openclaw/model-aliases.openclaw.json

@@ -0,0 +1,21 @@
+{
+  "_comment": [
+    "FRAGMENT - inspect before merging into your openclaw.json.",
+    "Generated by `brigade openclaw-fragments`. brigade never mutates your live config.",
+    "",
+    "Suggested merge target: agents.defaults.models",
+    "Replace <provider/model-id> with the actual provider-prefixed model id you want this alias to resolve to.",
+    "Aliases below are conventions used by the brigade reference setup; adapt freely."
+  ],
+  "agents": {
+    "defaults": {
+      "models": {
+        "main": "<provider/main-model-id>",
+        "coder": "<provider/coder-model-id>",
+        "cron": "<provider/cron-model-id>",
+        "fast": "<provider/fast-model-id>",
+        "escalation": "<provider/escalation-model-id>"
+      }
+    }
+  }
+}

brigade/templates/openclaw/ollama-memory-search.openclaw.json

@@ -0,0 +1,24 @@
+{
+  "_comment": [
+    "FRAGMENT - inspect before merging into your openclaw.json.",
+    "",
+    "Wires a local Ollama embedding model into OpenClaw's memory search.",
+    "Assumes Ollama is running on http://localhost:11434 with an embedding model pulled.",
+    "Replace <embedding-model> with the actual model name (e.g. nomic-embed-text)."
+  ],
+  "memory": {
+    "search": {
+      "embeddings": {
+        "provider": "ollama",
+        "baseUrl": "http://localhost:11434",
+        "model": "<embedding-model>",
+        "dimensions": 768
+      },
+      "index": {
+        "path": "memory/cards",
+        "include": ["*.md"],
+        "exclude": ["handoff-inbox/**", "processed/**"]
+      }
+    }
+  }
+}

brigade/templates/policies/public-content.json

@@ -0,0 +1,28 @@
+{
+  "_comment": [
+    "Public-content policy: stricter than public-repo. Applied to blog posts,",
+    "social drafts, and docs that will be published, not just pushed.",
+    "Use via: brigade scrub --policy public-content"
+  ],
+  "_brigade_version": "0.1.0",
+  "categories": {
+    "secret": "block",
+    "private-network": "block",
+    "private-identity": "block",
+    "attribution": "block",
+    "tooling": "block"
+  },
+  "rules": {
+    "loopback-ipv4": "block",
+    "localhost-port": "block",
+    "private-ipv4": "block",
+    "api-key": "block",
+    "oauth-token": "block",
+    "ssh-private-key": "block",
+    "claude-coauthor": "block",
+    "ai-attribution-trailer": "block",
+    "private-hostname": "block",
+    "personal-email": "block",
+    "internal-username": "block"
+  }
+}

brigade/templates/policies/public-repo.json

@@ -0,0 +1,27 @@
+{
+  "_comment": [
+    "Public-repo policy: blocks leaks in any file pushed to a public repo.",
+    "Used by brigade pre-push hook and `brigade scrub`.",
+    "Override by pointing CONTENT_GUARD_POLICY at your own copy of this file."
+  ],
+  "_brigade_version": "0.1.0",
+  "categories": {
+    "secret": "block",
+    "private-network": "block",
+    "private-identity": "block",
+    "attribution": "block",
+    "tooling": "warn"
+  },
+  "rules": {
+    "loopback-ipv4": "warn",
+    "localhost-port": "warn",
+    "private-ipv4": "block",
+    "api-key": "block",
+    "oauth-token": "block",
+    "ssh-private-key": "block",
+    "claude-coauthor": "block",
+    "ai-attribution-trailer": "block",
+    "private-hostname": "block",
+    "personal-email": "warn"
+  }
+}