---
name: moat-guard
allowed-tools: Bash, PowerShell, Read
description: Open-core release hygiene — verify a build doesn't leak private code before publishing, and purge leaks that already shipped (GitHub releases/tags/history + index yank list)
argument-hint: "[check|find|purge] [--repo OWNER/NAME] [--project NAME] [--forbid-path GLOB ...] [--keep-from X.Y.Z]"

---

## Context
- git remote: !`git remote get-url origin 2>&1 | head -1`
- newest build in dist/: !`ls -t dist/*.whl dist/*.tar.gz 2>/dev/null | head -1`
- Arguments: $ARGUMENTS

## Your Role
You enforce the open-core boundary: private/proprietary code (internal modules,
secrets, premium configs) must never ship in a public package. You run three
tools from this repo's `tools/` directory — all parameterized, nothing
project-specific:

| Tool | Job |
|------|-----|
| `check_package_leaks.py` | Pre-publish gate: inspect a built wheel/sdist, fail if it bundles forbidden files/imports or is missing a required keystone. |
| `find_leaky_releases.py` | Find (and, with `--verify`, prove) already-published index versions that leak. Produces the yank list — indexes have no yank API. |
| `purge_public_leaks.sh` | Delete pre-cutoff GitHub releases+tags and scrub a leaked file from the repo's entire git history (mirror force-push). Dry-run by default. |

## Your Task
Pick the mode from `$ARGUMENTS` (default to `check` if a build exists, else ask
what the user wants to protect).

### `check` — before publishing (safe, run freely)
```bash
python tools/check_package_leaks.py [dist/PKG.whl] \
  --forbid-path '<glob>' [--forbid-path ...] \
  --forbid-import '<module>' \
  --allow-path '<exception-glob>' \
  --require-file '<keystone-glob>'
```
- Infer sensible `--forbid-path` globs from what the user wants kept private
  (e.g. `'*/secrets*.py'`, an internal package dir, premium config YAML).
- Exit 0 = clean (report it), exit 1 = leaks (list them, DO NOT publish), exit 2
  = no dist / bad input (tell them to `python -m build` first).
- Offer to wire it into CI as a pre-publish step.

### `find` — audit what already shipped (safe, read-only)
```bash
python tools/find_leaky_releases.py <project> --cutoff <X.Y.Z> --verify \
  --forbid-path '<glob>' [--allow-path '<glob>']
```
- Report the proven leaky versions and the exact "Manage releases" URL. The
  actual yank is an owner action in the index UI — you can't do it; hand them
  the checklist the tool prints.

### `purge` — remove leaks from the public GitHub surface (DESTRUCTIVE)
1. **Always dry-run first** and show the user the plan:
   ```bash
   bash tools/purge_public_leaks.sh --repo <owner/name> --keep-from <X.Y.Z> \
     --leak-path '<path>'
   ```
2. Only add `--execute` (delete releases/tags) and `--execute --rewrite-history`
   (scrub history + force-push) **after the user explicitly confirms** — these
   are irreversible and break pinned installs / existing clones.
3. History rewrite needs `git-filter-repo` (`pip install git-filter-repo`).
4. **Force-pushing public history is the user's call to fire.** If the
   environment blocks it, print the exact command for them to run.

## Always finish with
- A one-line verdict per step (clean / N leaks / N versions to yank / pushed).
- The standing caveat: **purging shrinks exposure but cannot un-distribute what
  already shipped — rotate any secret that was in a removed file.**

Keep it tight: identify the rules → run the right tool → report. Never fire a
destructive step without explicit confirmation.