[minion] Propose features from monitored sources

.github/workflows/doc-minion.yml

@@ -19,23 +19,20 @@ permissions:
 
 jobs:
   update-docs:
-    runs-on: ubuntu-latest
+    runs-on: github-runner-partio-minion-ai-01
     timeout-minutes: 15
 
     steps:
       - uses: actions/checkout@v4
 
-      - name: Install Claude Code
-        run: npm install -g @anthropic-ai/claude-code
 
       - name: Install minions
         run: |
-          go install github.com/partio-io/minions/cmd/minions@v0.0.3
+          go install github.com/partio-io/minions/cmd/minions@v0.0.5
           echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH"
 
       - name: Run doc-update program
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.GH_PAT }}
         run: |
           ARGS="run .minions/programs/doc-update.md"

.github/workflows/minion.yml

@@ -30,7 +30,7 @@ jobs:
       github.event_name == 'workflow_dispatch' ||
       (github.event_name == 'issues' && (github.event.label.name == 'minion-ready' || github.event.label.name == 'minion-approved')) ||
       (github.event_name == 'issue_comment' && contains(github.event.comment.body, '/minion build'))
-    runs-on: ubuntu-latest
+    runs-on: github-runner-partio-minion-ai-01
     timeout-minutes: 30
 
     steps:
@@ -52,17 +52,14 @@ jobs:
             echo "issue_num=${ISSUE_NUM}" >> "$GITHUB_OUTPUT"
           fi
 
-      - name: Install Claude Code
-        run: npm install -g @anthropic-ai/claude-code
 
       - name: Install minions
         run: |
-          go install github.com/partio-io/minions/cmd/minions@v0.0.3
+          go install github.com/partio-io/minions/cmd/minions@v0.0.5
           echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH"
 
       - name: Run program
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.GH_PAT }}
         run: |
           ARGS="run ${{ steps.program.outputs.path }}"

.github/workflows/plan.yml

@@ -19,18 +19,16 @@ jobs:
     if: >
       github.event_name == 'workflow_dispatch' ||
       (github.event_name == 'issues' && github.event.label.name == 'minion-planning')
-    runs-on: ubuntu-latest
+    runs-on: github-runner-partio-minion-ai-01
     timeout-minutes: 15
 
     steps:
       - uses: actions/checkout@v4
 
-      - name: Install Claude Code
-        run: npm install -g @anthropic-ai/claude-code
 
       - name: Install minions
         run: |
-          go install github.com/partio-io/minions/cmd/minions@v0.0.3
+          go install github.com/partio-io/minions/cmd/minions@v0.0.5
           echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH"
 
       - name: Determine program
@@ -53,6 +51,5 @@ jobs:
 
       - name: Run program with planner
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.GH_PAT }}
         run: minions run ${{ steps.program.outputs.path }} --dry-run

.github/workflows/propose.yml

@@ -17,23 +17,20 @@ permissions:
 
 jobs:
   propose:
-    runs-on: ubuntu-latest
+    runs-on: github-runner-partio-minion-ai-01
     timeout-minutes: 15
 
     steps:
       - uses: actions/checkout@v4
 
-      - name: Install Claude Code
-        run: npm install -g @anthropic-ai/claude-code
 
       - name: Install minions
         run: |
-          go install github.com/partio-io/minions/cmd/minions@v0.0.3
+          go install github.com/partio-io/minions/cmd/minions@v0.0.5
           echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH"
 
       - name: Run propose program
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.GH_PAT }}
         run: |
           ARGS="run .minions/programs/propose.md"

.minions/programs/auto-upgrade-stale-hooks.md

@@ -0,0 +1,44 @@
+---
+id: auto-upgrade-stale-hooks
+target_repos:
+  - cli
+acceptance_criteria:
+  - "`partio enable` compares installed hook content against expected content and updates hooks that differ"
+  - "Hooks that already match expected content are left untouched (no unnecessary writes)"
+  - "Backup chain is preserved — existing `.partio-backup` files are not overwritten during upgrade"
+  - "A message is printed when hooks are upgraded (e.g., 'Updated pre-commit hook')"
+  - "The `.partio/` directory existence check no longer short-circuits the entire enable flow"
+  - "Table-driven tests cover: fresh install, stale hook upgrade, already-current hook skip, and backup preservation"
+pr_labels:
+  - minion
+---
+
+# Auto-upgrade stale hooks on `partio enable`
+
+## Problem
+
+When a user upgrades the Partio CLI binary, the git hook scripts installed in their repositories become stale — they may reference old binary paths, use outdated shim logic, or miss new hooks added in later versions. Currently, `partio enable` short-circuits entirely when `.partio/` exists (`cmd/partio/enable.go:38-42`), telling the user "partio is already enabled" without checking whether the installed hooks are up to date.
+
+The only workaround is `partio disable && partio enable`, which users must know to do and which unnecessarily tears down and rebuilds state.
+
+## Desired behavior
+
+`partio enable` should detect stale hooks and silently upgrade them:
+
+1. If `.partio/` exists, skip directory/config creation but still check hooks.
+2. For each expected hook (`pre-commit`, `post-commit`, `pre-push`), read the installed script from the hooks directory (`git rev-parse --git-common-dir`).
+3. Compare the installed content against the expected content from `hookScript()` / `hookScriptAbsolute()` (`internal/git/hooks/hooks.go`).
+4. If the content differs, overwrite the hook file (preserving the existing backup chain — do not re-backup a partio-managed hook).
+5. If a hook is missing entirely (e.g., a new hook type added in a later version), install it following the normal backup logic.
+6. Print a summary of what was upgraded, or "partio is already enabled and hooks are up to date" if nothing changed.
+
+## Context hints
+
+- `cmd/partio/enable.go` — the `.partio/` existence check that needs to be relaxed
+- `internal/git/hooks/install.go` — `installHooks()` needs an upgrade-aware code path
+- `internal/git/hooks/hooks.go` — `hookScript()` / `hookScriptAbsolute()` generate expected content
+- `internal/git/hooks/uninstall.go` — backup restoration logic to preserve during upgrades
+
+## Source
+
+Inspired by entireio/cli PR #775 — OpenCode plugin hook rewrite when content differs.

.minions/programs/checkpoint-v2-migration-command.md

@@ -0,0 +1,46 @@
+---
+id: checkpoint-v2-migration-command
+target_repos:
+  - cli
+acceptance_criteria:
+  - "`partio migrate --checkpoints v2` converts existing v1 checkpoint data to v2 format"
+  - "Migration reads all commits from `partio/checkpoints/v1` and writes compact `transcript.jsonl` + metadata to the v2 ref layout"
+  - "Migration is idempotent — running it twice does not duplicate or corrupt data"
+  - "Progress output shows how many checkpoints were migrated"
+  - "Dry-run flag (`--dry-run`) previews what would be migrated without writing"
+  - "make test passes"
+  - "make lint passes"
+pr_labels:
+  - minion
+---
+
+# Add `partio migrate` command for checkpoint format upgrades
+
+Add a `partio migrate --checkpoints v2` CLI command that migrates existing checkpoint data from the v1 orphan branch format to the v2 compact format.
+
+## Context
+
+Partio currently stores checkpoints on `partio/checkpoints/v1` using git plumbing commands. A v2 format with compact `transcript.jsonl` and metadata on a `/main` ref layout would reduce storage overhead and improve query performance. Before v2 can become the default, users need a migration path for existing checkpoint data.
+
+## What to implement
+
+1. A new `partio migrate` Cobra command under `cmd/partio/`
+2. A `--checkpoints` flag accepting `v2` as the target format
+3. A `--dry-run` flag that shows what would be migrated without writing
+4. Migration logic that:
+   - Reads checkpoint commits from the v1 branch
+   - Extracts session data and transcript content
+   - Writes compact transcript.jsonl files and metadata to the v2 ref layout
+   - Preserves all existing checkpoint metadata (session IDs, attribution, timestamps)
+5. Progress output showing migration status
+
+## Agents
+
+### implement
+
+```capabilities
+max_turns: 100
+checks: true
+retry_on_fail: true
+retry_max_turns: 20
+```

.minions/programs/configurable-checkpoint-path-filter.md

@@ -0,0 +1,53 @@
+---
+id: configurable-checkpoint-path-filter
+target_repos:
+  - cli
+acceptance_criteria:
+  - "Users can configure `checkpoint_path_filter` in `.partio/settings.json` with include and exclude glob patterns"
+  - "Excluded paths are omitted from checkpoint transcript and prompt data"
+  - "Include patterns (when specified) restrict checkpoints to only matching paths"
+  - "Default behavior (no filter configured) captures all paths as before"
+  - "Filters apply during post-commit checkpoint creation"
+  - "make test passes"
+  - "make lint passes"
+pr_labels:
+  - minion
+---
+
+# Add configurable path filtering for checkpoint content
+
+Allow users to configure which file paths are included or excluded from checkpoint data via glob patterns in Partio settings.
+
+## Context
+
+Checkpoint data currently captures all files touched during a session. In large monorepos or repos with generated files, build artifacts, or sensitive directories, users may want to exclude certain paths from checkpoint transcripts and metadata. This is distinct from secret redaction — it controls which file paths appear in checkpoint data at all.
+
+## What to implement
+
+1. Add `checkpoint_path_filter` to the config schema with `include` and `exclude` glob arrays
+2. Apply path filtering in the post-commit checkpoint creation flow when determining which files to include
+3. Exclude patterns take precedence over include patterns when both match
+4. Support standard glob syntax (e.g., `vendor/**`, `*.generated.go`, `build/`)
+5. Add config validation in `partio doctor` to warn about invalid glob patterns
+
+## Example config
+
+```json
+{
+  "checkpoint_path_filter": {
+    "exclude": ["vendor/**", "node_modules/**", "*.generated.go"],
+    "include": ["src/**", "internal/**"]
+  }
+}
+```
+
+## Agents
+
+### implement
+
+```capabilities
+max_turns: 100
+checks: true
+retry_on_fail: true
+retry_max_turns: 20
+```

.minions/programs/deprecate-reset-in-favor-of-rewind.md

@@ -0,0 +1,41 @@
+---
+id: deprecate-reset-in-favor-of-rewind
+target_repos:
+  - cli
+acceptance_criteria:
+  - "`partio reset` prints a deprecation warning to stderr before executing: `Warning: 'partio reset' is deprecated and will be removed in a future release. Use 'partio rewind' instead.`"
+  - "The command still functions after the warning so existing scripts are not broken"
+  - "`partio reset` is hidden from the default help output (marked as deprecated in cobra)"
+  - "The deprecation warning is tested in `cmd/partio/reset_test.go`"
+pr_labels:
+  - minion
+---
+
+# Deprecate `partio reset` in favor of `partio rewind`
+
+## Source
+
+entireio/cli changelog 0.5.3: "Deprecated `entire reset` command in favor of `entire rewind`"
+
+## Problem
+
+`partio reset` is a destructive command that deletes and recreates the entire checkpoint branch, wiping all stored checkpoint data. `partio rewind` is the safer alternative — it lists checkpoints and restores to a specific one without discarding history. Having both commands creates confusion about which to use, and `reset` is easy to run accidentally with severe consequences.
+
+## Proposed Change
+
+Mark `partio reset` as deprecated in Cobra so it:
+
+1. Is hidden from `partio --help` output (users discover it only if they explicitly run it or know about it)
+2. Prints a deprecation warning to stderr when invoked: `Warning: 'partio reset' is deprecated and will be removed in a future release. Use 'partio rewind' instead.`
+3. Still executes its current logic so existing scripts continue to work during the transition period
+
+The implementation touches only `cmd/partio/reset.go`. Cobra supports `Deprecated` field on commands which automatically prints the warning and hides from help.
+
+## Why This Matters
+
+Surfacing the deprecation now sets expectations before `reset` is eventually removed. Users who discover `reset` (e.g. from old blog posts or AI suggestions) get a clear redirect to `rewind`, reducing the risk of accidental checkpoint data loss.
+
+## Context
+
+- `cmd/partio/reset.go` — current reset implementation
+- `cmd/partio/rewind.go` — the preferred replacement command

.minions/programs/fix-rewind-checkpoint-not-fetched.md

@@ -0,0 +1,40 @@
+---
+id: fix-rewind-checkpoint-not-fetched
+target_repos:
+  - cli
+acceptance_criteria:
+  - "`partio rewind --list` shows a helpful fetch suggestion when the checkpoint branch exists on the remote but is not fetched locally"
+  - "When neither local nor remote has the branch, the original 'no checkpoint branch found' error is shown"
+  - "The fetch hint includes the exact git command to run"
+  - "make test passes"
+  - "make lint passes"
+pr_labels:
+  - minion
+---
+
+# Fix `partio rewind` when checkpoint branch isn't fetched locally
+
+`partio rewind --list` returns `"no checkpoint branch found"` when `partio/checkpoints/v1` doesn't exist locally. If the user is working in a cloned repo or on a new machine where checkpoints were pushed from elsewhere, the branch may exist on the remote but not be fetched. The current error message is confusing because it implies checkpoints don't exist at all.
+
+## Fix
+
+In `runRewindList()` (`cmd/partio/rewind.go`), when `git rev-parse --verify partio/checkpoints/v1` fails:
+
+1. Check if the branch exists on the remote:
+   ```
+   git ls-remote --heads origin partio/checkpoints/v1
+   ```
+2. If the remote has the branch, print a helpful message instead of the generic error:
+   ```
+   Checkpoint branch not fetched locally.
+   Run: git fetch origin partio/checkpoints/v1:partio/checkpoints/v1
+   ```
+3. If neither local nor remote has the branch, keep the current error.
+
+Also apply the same check in `runRewindTo()` for consistency.
+
+## Key files
+
+- `cmd/partio/rewind.go` — `runRewindList()` at line ~50 and `runRewindTo()` at line ~94
+
+**Inspired by:** entireio/cli changelog v0.5.3 — "Resume failing when checkpoints aren't fetched locally yet"

.minions/programs/guard-post-commit-rebase-reentry.md

@@ -0,0 +1,45 @@
+---
+id: guard-post-commit-rebase-reentry
+target_repos:
+  - cli
+acceptance_criteria:
+  - "Post-commit hook detects an in-progress interactive rebase (presence of `.git/rebase-merge/` or `.git/rebase-apply/`) and exits 0 immediately without creating a checkpoint"
+  - "A debug-level log message is emitted when the rebase guard triggers: 'skipping checkpoint creation: interactive rebase in progress'"
+  - "Normal commits (no rebase) are unaffected"
+  - "The guard does not prevent Partio from operating on commits made *after* the rebase completes"
+  - "Unit test covers the rebase-detection logic with a fake git dir structure"
+pr_labels:
+  - minion
+---
+
+# Guard post-commit hook against spurious checkpoints during interactive rebase
+
+## What
+
+During `git rebase -i`, git replays each selected commit and fires the post-commit hook for each one. Partio's post-commit hook will attempt to create a new checkpoint for every replayed commit — even though those commits already have checkpoints and no agent session is running.
+
+Add a guard to `internal/hooks/post_commit.go` (or wherever the post-commit logic lives) that detects an in-progress rebase and returns early with a no-op. Detection: check for the presence of `.git/rebase-merge/` or `.git/rebase-apply/` directories (these exist for the duration of an interactive or am-style rebase).
+
+Note: Partio already guards against `--amend` re-entry by deleting the state file before the amend. The rebase case is separate — the state file won't be present (so that guard won't trigger), but the hook still fires.
+
+## Why
+
+Without this guard, `git rebase -i` on a branch with many commits will:
+1. Attempt to create a new checkpoint for each replayed commit (most will fail gracefully since there's no state file, but it adds unnecessary overhead)
+2. Potentially create a spurious checkpoint if a pre-commit state file happens to be present from a prior interrupted operation
+3. Slow down rebases with checkpoint overhead
+
+This matches a pattern seen in `entireio/cli` PR #824 which added a guard against duplicate `session.created` events being processed.
+
+## Source
+
+Inspired by `entireio/cli` PR #824 (guard session-start hook on duplicate session.created) and the general pattern of making hooks resilient to git operations that replay commits.
+
+## Implementation hints
+
+- `internal/hooks/` — post-commit hook implementation
+- `internal/git/` — add a `IsRebaseInProgress(gitDir string) bool` helper
+- Check `filepath.Join(gitDir, "rebase-merge")` and `filepath.Join(gitDir, "rebase-apply")`
+- Use `internal/log` for the debug-level log message
+- The git dir is available via `git rev-parse --git-dir` (already used elsewhere)
+<!-- program: .minions/programs/guard-post-commit-rebase-reentry.md -->