diff --git a/.github/workflows/doc-minion.yml b/.github/workflows/doc-minion.yml index 9f4237b..666421d 100644 --- a/.github/workflows/doc-minion.yml +++ b/.github/workflows/doc-minion.yml @@ -30,7 +30,7 @@ jobs: - name: Install minions run: | - go install github.com/partio-io/minions/cmd/minions@v0.0.1 + go install github.com/partio-io/minions/cmd/minions@v0.0.3 echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH" - name: Run doc-update program diff --git a/.github/workflows/minion.yml b/.github/workflows/minion.yml index 0e3c806..bba9317 100644 --- a/.github/workflows/minion.yml +++ b/.github/workflows/minion.yml @@ -57,7 +57,7 @@ jobs: - name: Install minions run: | - go install github.com/partio-io/minions/cmd/minions@v0.0.1 + go install github.com/partio-io/minions/cmd/minions@v0.0.3 echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH" - name: Run program diff --git a/.github/workflows/plan.yml b/.github/workflows/plan.yml index d60885d..ab197bd 100644 --- a/.github/workflows/plan.yml +++ b/.github/workflows/plan.yml @@ -30,7 +30,7 @@ jobs: - name: Install minions run: | - go install github.com/partio-io/minions/cmd/minions@v0.0.1 + go install github.com/partio-io/minions/cmd/minions@v0.0.3 echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH" - name: Determine program diff --git a/.github/workflows/propose.yml b/.github/workflows/propose.yml index 19b1c64..35c7262 100644 --- a/.github/workflows/propose.yml +++ b/.github/workflows/propose.yml @@ -28,7 +28,7 @@ jobs: - name: Install minions run: | - go install github.com/partio-io/minions/cmd/minions@v0.0.1 + go install github.com/partio-io/minions/cmd/minions@v0.0.3 echo "$(go env GOPATH)/bin" >> "$GITHUB_PATH" - name: Run propose program diff --git a/.minions/programs/add-partio-configure-command.md b/.minions/programs/add-partio-configure-command.md new file mode 100644 index 0000000..78d310f --- /dev/null +++ b/.minions/programs/add-partio-configure-command.md @@ -0,0 +1,53 @@ +--- +id: add-partio-configure-command +target_repos: + - cli +acceptance_criteria: + - "`partio configure` command exists and is registered in the root command" + - "`partio configure --agent ` updates the `agent` field in `.partio/settings.json`" + - "`partio configure --strategy ` updates the `strategy` field in `.partio/settings.json`" + - Running `partio configure` without flags prints the current configuration (same as `partio status` config section, or a brief config dump) + - The command returns a clear error if run outside a git repository or before `partio enable` + - Existing `enable` and `disable` commands are unchanged + - Table-driven tests cover flag parsing and settings file update +pr_labels: + - minion +--- + +# Add `partio configure` command + +## Source + +Inspired by entireio/cli#851 (`entire configure` to remove agent / manage agents). + +## Problem + +Once a user has run `partio enable`, changing their agent or strategy requires: +``` +partio disable && partio enable +``` + +There is no dedicated command for updating configuration after initial setup. This is a rough experience for users who want to switch from the default `claude-code` agent or change their strategy without reinstalling hooks. + +## Desired behavior + +Add a `partio configure` command with flags to update individual settings in `.partio/settings.json`: + +``` +partio configure --agent +partio configure --strategy +partio configure # prints current config +``` + +The command should: +1. Verify partio is enabled (`.partio/` directory exists) +2. Load the current repo-level config from `.partio/settings.json` +3. Apply any flag overrides +4. Write the updated config back to `.partio/settings.json` +5. Print a confirmation of what changed + +## Files to create/modify + +- `cmd/partio/configure.go` — new file implementing the `configure` subcommand +- `cmd/partio/main.go` — register `newConfigureCmd()` on the root command +- `internal/config/config.go` — ensure there is a `Save(path string)` method or equivalent for writing back to JSON (add if missing) diff --git a/.minions/programs/checkpoint-push-auth-env-token.md b/.minions/programs/checkpoint-push-auth-env-token.md new file mode 100644 index 0000000..6c00c2d --- /dev/null +++ b/.minions/programs/checkpoint-push-auth-env-token.md @@ -0,0 +1,41 @@ +--- +id: checkpoint-push-auth-env-token +target_repos: + - cli +acceptance_criteria: + - When `PARTIO_CHECKPOINT_TOKEN` is set and the checkpoint remote uses HTTPS, git push/fetch operations for the checkpoint branch inject the token via `GIT_CONFIG_COUNT`/`GIT_CONFIG_KEY_*`/`GIT_CONFIG_VALUE_*` env vars (not CLI args) to avoid leaking it in /proc/cmdline + - Token is encoded as Basic auth (`x-access-token:` base64) matching GitHub's Git HTTP protocol requirement + - SSH remotes emit a warning that the token is ignored (SSH handles auth separately) + - A unit test verifies the correct header format is injected for HTTPS remotes + - A unit test verifies no header is injected for SSH remotes +pr_labels: + - minion +--- + +# Support `PARTIO_CHECKPOINT_TOKEN` for checkpoint branch push/fetch authentication + +## Description + +Add support for a `PARTIO_CHECKPOINT_TOKEN` environment variable that, when set, is injected into the git push/fetch operations Partio uses for the checkpoint branch. This allows users and CI environments to authenticate checkpoint operations against HTTPS remotes (e.g., a private GitHub repository used as a checkpoint store) without needing to configure git credentials globally. + +The token should be passed via the `GIT_CONFIG_COUNT` / `GIT_CONFIG_KEY_*` / `GIT_CONFIG_VALUE_*` environment variable pattern rather than as CLI arguments, to avoid the token appearing in process listings (`/proc/cmdline`). For GitHub HTTPS remotes, encode the token as Basic auth with `x-access-token:` base64-encoded in the `Authorization` header (GitHub's Git HTTP protocol requires Basic, not Bearer). + +SSH remotes do not use this mechanism; if the remote URL is SSH and the env var is set, log a warning that the token is unused. + +## Why + +Users pushing checkpoints to a separate private repository (via `checkpoint_remote` config) in CI environments have no clean way to authenticate those git operations without setting up global git credential helpers. A dedicated env var with secure injection matches how CI systems manage secrets and avoids credential leakage. + +## User Relevance + +CI users and teams using a centralized checkpoint repository can authenticate checkpoint push/fetch with a single environment variable, without touching global git config or exposing tokens in process arguments. + +## Source + +Inspired by entireio/cli#818 and entireio/cli#827 + +## Context Hints + +- `internal/git/` — git operations including push/fetch for checkpoint branch +- `internal/hooks/` — pre-push hook that triggers checkpoint push +- `internal/config/` — environment variable handling diff --git a/.minions/programs/checkpoints-v2-compact-transcript.md b/.minions/programs/checkpoints-v2-compact-transcript.md new file mode 100644 index 0000000..4c104cb --- /dev/null +++ b/.minions/programs/checkpoints-v2-compact-transcript.md @@ -0,0 +1,36 @@ +--- +id: checkpoints-v2-compact-transcript +target_repos: + - cli +acceptance_criteria: + - "When checkpoints_v2 feature flag is enabled, a compact transcript.jsonl is written to a v2 ref layout alongside the full session JSONL" + - "The compact transcript contains normalized, per-turn entries (user prompt + assistant response) instead of raw JSONL events" + - "The v2 ref layout uses a stable path structure (e.g. refs/partio/checkpoints/v2/main)" + - "When checkpoints_v2 is disabled (default), no v2 refs are written — existing behavior is unchanged" + - "make test passes" + - "make lint passes" +pr_labels: + - minion +--- + +# Checkpoints v2: write compact transcript.jsonl alongside full session data + +## Description + +Partio currently stores full JSONL session data in git objects on the checkpoint branch. For large sessions this means fetching/reading the full event stream to get a summary view. A compact `transcript.jsonl` containing only normalized turn-level entries (user prompt + assistant response, stripped of internal tool calls) would make session browsing faster and reduce storage cost for downstream consumers. + +This is the approach taken in entireio/cli (changelog 0.5.2, PRs #828, #788, #781). + +## What to implement + +1. Add a `checkpoints_v2` boolean field to the `Config` type (default: false) as a feature flag. +2. When the flag is enabled, after writing the full checkpoint blob, also write a compact `transcript.jsonl` to a v2 ref path (e.g. `refs/partio/checkpoints/v2/`). +3. The compact transcript format: one JSON object per turn, each with `{"role": "user"|"assistant", "ts": "...", "content": "..."}`. Strip raw tool-call events and internal events; keep only conversation-level content. +4. The v2 ref write must use the same git plumbing approach (hash-object, mktree, commit-tree, update-ref) as the existing checkpoint storage. +5. Add a unit test for the compact transcript generation from a sample JSONL session. + +## Context hints + +- `internal/checkpoint/` — checkpoint domain type and git plumbing storage +- `internal/agent/claude/` — JSONL parsing utilities +- `internal/config/` — Config type, layered config loading diff --git a/.minions/programs/claude-worktree-session-path.md b/.minions/programs/claude-worktree-session-path.md new file mode 100644 index 0000000..7f3a986 --- /dev/null +++ b/.minions/programs/claude-worktree-session-path.md @@ -0,0 +1,37 @@ +--- +id: claude-worktree-session-path +target_repos: + - cli +pr_labels: + - minion +acceptance_criteria: + - When Claude Code is launched with `--worktree` (creating worktrees under `.claude/worktrees//`), `partio rewind` correctly finds and restores the session + - `partio doctor` correctly identifies the Claude session directory when `--worktree` was used + - `find_session_dir.go` handles the case where the Claude project directory key is the main repo root, not the worktree path + - Existing worktree tests still pass + - A new table-driven test covers session discovery for the `--worktree` case +--- + +# Fix Session Discovery for Claude Code `--worktree` Sessions + +## Description + +Claude Code has a `--worktree` flag that creates its own git worktrees under `.claude/worktrees//`. When this flag is used, Claude Code keys the session directory to the **main repo path** (e.g. `/home/user/myrepo`) rather than to the worktree path (`.claude/worktrees/feat-x/`). This causes Partio's session discovery to look in the wrong place, breaking `partio rewind` and the post-commit hook's session linking. + +This mirrors the fix in [entireio/cli#817](https://github.com/entireio/cli/pull/817). + +### Root cause + +`find_session_dir.go` walks up from the worktree root to find the Claude session directory. But when Claude Code's `--worktree` creates sub-worktrees under `.claude/worktrees/`, the session is stored under a path derived from the **main repo root**, not the git worktree root. The walk-up logic doesn't account for this indirection. + +### What to fix + +In `internal/agent/claude/find_session_dir.go`: + +1. Detect if the current working directory is inside a `.claude/worktrees//` path (i.e. a Claude-managed worktree). +2. If so, resolve the **main repo root** (i.e. the directory above `.claude/`) and use that as the Claude project key for session directory lookup. +3. Add a table-driven test case that creates a temp directory structure mimicking `.claude/worktrees//` and verifies `FindSessionDir` returns the correct session path. + +### Why + +Users who invoke Claude Code with `--worktree` (a common pattern for parallel Claude sessions on different branches) get no checkpoints because Partio can't find the session. This is a silent failure — hooks run but nothing is linked. diff --git a/.minions/programs/codex-agent-support.md b/.minions/programs/codex-agent-support.md new file mode 100644 index 0000000..f0f6615 --- /dev/null +++ b/.minions/programs/codex-agent-support.md @@ -0,0 +1,42 @@ +--- +id: codex-agent-support +target_repos: + - cli +acceptance_criteria: + - "A new Detector implementation exists in `internal/agent/codex/` that satisfies the `agent.Detector` interface" + - "The detector identifies running Codex CLI processes via process inspection" + - "Session JSONL/transcript parsing handles the Codex transcript format" + - "Integration is registered alongside the existing Claude Code detector" + - "Unit tests cover process detection and transcript parsing" +pr_labels: + - minion +--- + +# Add Codex CLI agent integration + +Add support for capturing sessions from OpenAI's Codex CLI agent, similar to the existing Claude Code integration. + +## Source + +entireio/cli#772 (changelog 0.5.2) + +## Description + +Partio currently only supports Claude Code as an AI agent. Codex CLI (OpenAI's coding agent) is gaining adoption and users running Codex sessions are not getting their sessions captured in checkpoints. + +Implement a `Detector` for Codex CLI in `internal/agent/codex/` following the same pattern as `internal/agent/claude/`: + +1. **Process detection**: Identify running Codex CLI processes by executable name and working directory. +2. **Transcript parsing**: Parse Codex session transcripts (JSONL format) to extract prompt, context, and tool call history. +3. **Session discovery**: Find the current Codex session directory for the working repository. +4. **Registration**: Wire the new detector into the agent detection chain in `internal/agent/`. + +The detector should implement the `agent.Detector` interface defined in `internal/agent/detector.go`. Follow the file-per-concern convention: `detect.go`, `find_session_dir.go`, `find_latest_session.go`, `parse_jsonl.go`. + +## Why + +Partio's core value proposition is agent-agnostic: it captures the *why* behind AI-assisted code changes regardless of which agent is used. Supporting only Claude Code limits adoption and leaves Codex users without session capture entirely. + +## User Relevance + +Developers using Codex CLI can have their sessions automatically captured in checkpoints, giving them the same traceability and context preservation that Claude Code users already enjoy — without any manual intervention. diff --git a/.minions/programs/detect-claude-code-nonstandard-ide-environments.md b/.minions/programs/detect-claude-code-nonstandard-ide-environments.md new file mode 100644 index 0000000..a6162a1 --- /dev/null +++ b/.minions/programs/detect-claude-code-nonstandard-ide-environments.md @@ -0,0 +1,39 @@ +--- +id: detect-claude-code-nonstandard-ide-environments +target_repos: + - cli +acceptance_criteria: + - "process.go detects Claude Code when launched as a subprocess of a known IDE process (e.g. IntelliJ, VS Code) rather than only when launched directly from a terminal" + - "`partio status` correctly shows Claude Code as active when it was launched via an IDE plugin" + - "detection does not produce false positives when the IDE is running without Claude Code" + - "unit test covers the case where the claude process is a child of a non-terminal parent" + - "fallback behaviour is unchanged: if detection is ambiguous, partio still proceeds without blocking the commit" +pr_labels: + - minion +--- + +# Detect Claude Code sessions launched from non-standard IDE environments + +## Problem + +Partio's Claude Code detection (`internal/agent/claude/process.go`) finds running Claude Code processes by scanning the process list. When Claude Code is launched via an IDE plugin (e.g. Cursor plugin inside IntelliJ IDEA, VS Code extension), the process may appear with a different parent hierarchy or execution context than when launched from a terminal. This causes Partio to miss the running session and produce no checkpoint for those commits. + +The user's workflow is unchanged — they are still using Claude Code to write code — but Partio silently fails to capture their session. + +## What to implement + +Extend `internal/agent/claude/process.go` to detect Claude Code in non-terminal launch environments: + +1. When the direct process scan doesn't find a Claude Code process, walk the process tree upward from the current process to look for a Claude Code ancestor or sibling (covering IDE plugin scenarios where the agent is a child of the IDE process). + +2. Alternatively, check for the presence of an active Claude Code session directory (`.claude/projects/`) as a secondary signal when process detection returns no result. If a session file was modified recently (e.g. within the last 10 minutes), treat it as a running session. + +The second approach (session directory recency check) is simpler and more portable across OS/IDE combinations. It avoids complex process-tree traversal and is resilient to the specific launch mechanism. + +Keep the change within `process.go` or a new `find_active_session.go` file. The `Detector` interface in `internal/agent/detector.go` does not need to change. + +## Inspiration + +- `entireio/cli` issue #844 — Entire CLI does not capture sessions when using IntelliJ IDEA with Cursor plugin on macOS + + diff --git a/.minions/programs/diagnostic-logging-checkpoint-failures.md b/.minions/programs/diagnostic-logging-checkpoint-failures.md new file mode 100644 index 0000000..8ad377a --- /dev/null +++ b/.minions/programs/diagnostic-logging-checkpoint-failures.md @@ -0,0 +1,41 @@ +--- +id: diagnostic-logging-checkpoint-failures +target_repos: + - cli +acceptance_criteria: + - "When `stagedFilesOverlapWithContent` returns false, the actual staged file paths and the session content paths are both logged at debug level" + - "When a checkpoint trailer is not added to a commit, a warning is logged that includes the commit hash and the reason" + - "When `PARTIO_LOG_LEVEL=debug` is set, users can see exactly which file paths were compared during overlap detection" + - "No new dependencies are introduced — use the existing `log` package" + - "Existing tests continue to pass" +pr_labels: + - minion +--- + +# Add diagnostic logging for checkpoint linking failures + +When Partio hooks run successfully but no `Partio-Checkpoint` trailer appears on commits, there is currently no way to diagnose why. Add structured debug logging at the overlap detection step so users can self-diagnose path mismatch issues. + +## Source + +entireio/cli PR #785 (changelog 0.5.2), issue #768 + +## Description + +The most common silent failure mode in Partio is: hooks run, no error is reported, but commits never receive a `Partio-Checkpoint` trailer. This happens when `stagedFilesOverlapWithContent` returns false — typically because file paths don't match between what git staged and what the session recorded. + +Add diagnostic logging in the post-commit hook path: + +1. **In `internal/hooks/` post-commit logic**: when the overlap check fails, log at `slog.LevelDebug` the full list of staged file paths and the full list of session content file paths. This lets users running `PARTIO_LOG_LEVEL=debug` immediately see the mismatch. + +2. **Warn on no-trailer commit**: if the post-commit hook finishes without amending the commit with a trailer, emit a `slog.LevelWarn` message including the commit hash and the specific reason (no active session, overlap check failed, no checkpoint created, etc.). + +Use the existing `internal/log` package — no new dependencies. + +## Why + +Issues like #768 and the entireio/cli equivalent show this is the most common support request: "hooks are installed and running, but nothing is being captured." Right now there is no way to self-diagnose without reading source code. A single debug log line would make this immediately actionable. + +## User Relevance + +Users can run `PARTIO_LOG_LEVEL=debug git commit -m "..."` to see exactly why a checkpoint wasn't created, dramatically reducing the time to resolve configuration or path-mismatch issues. diff --git a/.minions/programs/fail-closed-pre-commit-content-detection.md b/.minions/programs/fail-closed-pre-commit-content-detection.md new file mode 100644 index 0000000..6dad0ae --- /dev/null +++ b/.minions/programs/fail-closed-pre-commit-content-detection.md @@ -0,0 +1,37 @@ +--- +id: fail-closed-pre-commit-content-detection +target_repos: + - cli +acceptance_criteria: + - When session content detection errors in the pre-commit hook, the checkpoint trailer is NOT added to the commit + - The error is logged at warn level with enough context to diagnose the root cause + - A regression test covers the corrupt/stale session scenario in the pre-commit hook + - Existing behavior for healthy sessions is unchanged +pr_labels: + - minion +--- + +# Fail closed on pre-commit content detection errors + +## Description + +Partio's pre-commit hook currently fails open when checking whether a session has new content: if `sessionHasNewContent` (or equivalent) returns an error, the hook still marks the commit as linked to the session. This means a stale, corrupt, or unresolvable session can cause the commit to receive the checkpoint trailer even though post-commit cannot create a valid checkpoint. The user ends up with a commit that appears to be linked to a session but has no actual checkpoint data. + +Fix this by making content detection fail closed: if checking a session produces an error, log a warning and skip that session instead of treating it as linked. + +## Why + +A fail-open error path creates ghost checkpoints — commits that look linked but contain no data. These are confusing and erode user trust. The fix makes the system conservative: only link a commit when we are confident there is real session content to attach. + +## User Relevance + +Users won't encounter mysteriously empty checkpoint pages after commits that happened near session corruption, network issues, or leftover state files. The hook becomes more predictable: a commit either has a valid checkpoint or it doesn't. + +## Source + +Inspired by entireio/cli#826 (changelog 0.5.2) + +## Context Hints + +- `internal/hooks/` — pre-commit hook implementation +- `internal/session/` — session state and content detection logic diff --git a/.minions/programs/fix-checkpoint-remote-owner-mismatch.md b/.minions/programs/fix-checkpoint-remote-owner-mismatch.md new file mode 100644 index 0000000..9930188 --- /dev/null +++ b/.minions/programs/fix-checkpoint-remote-owner-mismatch.md @@ -0,0 +1,35 @@ +--- +id: fix-checkpoint-remote-owner-mismatch +target_repos: + - cli +acceptance_criteria: + - "When checkpoint_remote is configured with a different owner than origin, pushes go to checkpoint_remote, not origin" + - "When checkpoint_remote push fails, a user-visible warning is printed to stderr (not silently swallowed to a log file)" + - "Existing behavior for matching-owner checkpoint_remote configs is unchanged" + - "make test passes" + - "make lint passes" +pr_labels: + - minion +--- + +# Fix checkpoint_remote silently falling back to origin on owner mismatch + +## Description + +When a user configures `checkpoint_remote` in `.partio/settings.json` (e.g. `{"provider": "github", "repo": "alice/checkpoints"}`) and the origin remote belongs to a different owner (e.g. `org/work-repo`), Partio silently ignores the configured checkpoint remote and pushes to origin instead. The fallback messages are written only to debug/warn logs — the user has no visible indication their config is being ignored. + +This was reported in entireio/cli#800 and fixed in entireio/cli#805. + +## What to fix + +In the pre-push hook logic that resolves push settings: + +1. When `checkpoint_remote` is explicitly configured, respect it regardless of owner mismatch between push remote and checkpoint remote. Owner mismatch should not trigger a silent fallback. +2. For all fallback paths (remote URL lookup failure, URL parse failure, URL derivation failure), print a user-visible warning to stderr so users know their checkpoint_remote config is being ignored and why. +3. Add a test case covering the scenario where `checkpoint_remote` owner differs from origin owner — verify the checkpoint push goes to the configured remote. + +## Context hints + +- `internal/hooks/` — pre-push hook implementation +- `internal/config/` — Config type with checkpoint_remote field +- `internal/git/` — remote URL lookup utilities diff --git a/.minions/programs/fix-multi-session-attribution-loss.md b/.minions/programs/fix-multi-session-attribution-loss.md new file mode 100644 index 0000000..4e5e0e1 --- /dev/null +++ b/.minions/programs/fix-multi-session-attribution-loss.md @@ -0,0 +1,38 @@ +--- +id: fix-multi-session-attribution-loss +target_repos: + - cli +acceptance_criteria: + - When two or more agent sessions contribute to the same checkpoint (same base commit), attribution data from all sessions is aggregated correctly + - The final agent_percentage reflects contributions from all sessions, not just the most recent + - A test covers a two-session scenario and asserts that attribution is summed across both + - No regression in single-session attribution calculation +pr_labels: + - minion +--- + +# Fix multi-session attribution summary loss during checkpoint condensation + +## Description + +When multiple agent sessions contribute to the same checkpoint (i.e., they share the same base commit), Partio loses per-session attribution data during condensation. The root `CheckpointSummary` ends up reflecting only the most recent session's attribution rather than an aggregate across all sessions. This means the reported `agent_percentage` is wrong for repositories where users work in multiple short sessions on the same branch before committing. + +Fix the condensation logic to accumulate `InitialAttribution` across all contributing sessions when building the final `CheckpointSummary`, so that the reported attribution accurately reflects the combined agent and human contributions. + +## Why + +Attribution accuracy is a core Partio value proposition. If two sessions each contribute 50% of the changes but the summary only records one, the user sees a misleading 50% instead of a correct combined view. The bug silently discards real work. + +## User Relevance + +Users who run multiple short agent sessions before a commit will get accurate attribution percentages rather than percentages that only reflect the last session. This matters especially for code review contexts where the attribution data informs decisions about AI-assisted work. + +## Source + +Inspired by entireio/cli#813 + +## Context Hints + +- `internal/checkpoint/` — checkpoint domain type and condensation logic +- `internal/attribution/` — attribution calculation +- `internal/session/` — session lifecycle and data diff --git a/.minions/programs/fix-multiple-commits-per-turn-missing-trailer.md b/.minions/programs/fix-multiple-commits-per-turn-missing-trailer.md new file mode 100644 index 0000000..9e5c5ba --- /dev/null +++ b/.minions/programs/fix-multiple-commits-per-turn-missing-trailer.md @@ -0,0 +1,30 @@ +--- +id: fix-multiple-commits-per-turn-missing-trailer +target_repos: + - cli +pr_labels: + - minion +acceptance_criteria: + - "All commits made within the same agent session turn receive the `Partio-Checkpoint` trailer" + - "The pre-commit hook correctly detects and saves state for each commit, not just the first" + - "A regression test covers the case of two sequential commits within the same active session" + - "The fix does not affect the hook re-entry prevention logic for `git commit --amend`" +--- + +# Fix: subsequent commits within the same agent turn don't get checkpoint trailers + +## Description + +When using the `manual-commit` strategy, only the first commit in an agent session turn gets the `Partio-Checkpoint` trailer. Subsequent commits within the same active session are silently skipped, causing their changes to be orphaned from the session transcript. + +**Root cause (analogous to entireio/cli#784):** The pre-commit hook saves detection state to `.partio/state/pre-commit.json`. The post-commit hook reads and immediately deletes this file before creating the checkpoint. For the *second* commit in the same turn, if the session state or detection logic produces a result that is filtered out (e.g., the session appears to have no *new* content since the previous checkpoint was already written), the linking is silently skipped. + +**Fix:** Ensure the session new-content detection in `internal/hooks/post_commit.go` accounts for content added between checkpoints within the same turn, not just between the previous checkpoint and the start of the turn. The detection cursor should advance after each commit's checkpoint is written. + +## Context Hints + +- `internal/hooks/` — pre-commit and post-commit hook implementations +- `internal/session/` — session state tracking +- `internal/agent/claude/` — JSONL parsing and new-content detection + + diff --git a/.minions/programs/fix-stale-attribution-base-mid-session.md b/.minions/programs/fix-stale-attribution-base-mid-session.md new file mode 100644 index 0000000..382387a --- /dev/null +++ b/.minions/programs/fix-stale-attribution-base-mid-session.md @@ -0,0 +1,36 @@ +--- +id: fix-stale-attribution-base-mid-session +target_repos: + - cli +acceptance_criteria: + - "When unrelated commits occur on the same branch during an active agent session, attribution for subsequent agent commits is scoped to changes since the last unrelated commit — not since session start" + - "AttributionBaseCommit in session state is updated whenever the post-commit hook runs without a checkpoint trailer (i.e. for unrelated human commits)" + - "Attribution percentages are not deflated by including prior unrelated changes in the human-side diff" + - "Existing attribution tests still pass" + - "make test passes" + - "make lint passes" +pr_labels: + - minion +--- + +# Fix stale attribution base when unrelated commits occur during an active agent session + +## Description + +In long agent sessions where the user also makes unrelated commits between agent turns, the `AttributionBaseCommit` stored in the session state is not updated when those unrelated commits land. As a result, when the agent eventually commits, the attribution diff (`AttributionBaseCommit → HEAD`) spans multiple unrelated human commits, inflating the human line count and deflating the agent percentage. + +This was fixed in entireio/cli#792. + +## What to fix + +In the post-commit hook: + +1. When a commit lands without a `Partio-Checkpoint:` trailer (i.e. an unrelated human commit during an active session), update the session's `AttributionBaseCommit` to the new HEAD. +2. This ensures subsequent agent-attributed commits diff only against the most recent baseline — not against a stale session-start commit. +3. Add an integration test that commits unrelated changes mid-session and verifies that final agent attribution reflects only the agent's own changes. + +## Context hints + +- `internal/hooks/post-commit.go` — post-commit hook, session state updates +- `internal/session/` — session state types and persistence +- `internal/attribution/` — attribution calculation diff --git a/.minions/programs/gemini-agent-support.md b/.minions/programs/gemini-agent-support.md new file mode 100644 index 0000000..388cdbc --- /dev/null +++ b/.minions/programs/gemini-agent-support.md @@ -0,0 +1,40 @@ +--- +id: gemini-agent-support +target_repos: + - cli +acceptance_criteria: + - "A new Detector implementation exists in `internal/agent/gemini/` that satisfies the `agent.Detector` interface" + - "The detector identifies running Gemini CLI processes via process inspection" + - "Transcript parsing handles the Gemini `transcript.jsonl` compact format" + - "Integration is registered alongside the existing Claude Code detector" + - "Unit tests cover process detection and transcript parsing for the Gemini format" +pr_labels: + - minion +--- + +# Add Gemini CLI agent integration + +Add support for capturing sessions from Google's Gemini CLI coding agent. + +## Source + +entireio/cli PR #819 (changelog 0.5.2) + +## Description + +Gemini CLI uses a compact `transcript.jsonl` format that differs from Claude Code's JSONL format. Implement a `Detector` for Gemini CLI in `internal/agent/gemini/` following the same pattern as `internal/agent/claude/`: + +1. **Process detection**: Identify running Gemini CLI processes by executable name and working directory. +2. **Transcript parsing**: Parse Gemini's compact `transcript.jsonl` format to extract prompts, context, and tool usage. The format condenses multi-turn conversations differently from Claude's full session JSONL. +3. **Session discovery**: Find the Gemini session directory associated with the current working repository. +4. **Registration**: Wire the new detector into the agent detection chain. + +Follow the one-file-per-concern convention matching `internal/agent/claude/`: `detect.go`, `find_session_dir.go`, `find_latest_session.go`, `parse_jsonl.go`. + +## Why + +Gemini CLI is widely used by developers on Google's AI ecosystem. Without Gemini support, Partio cannot capture sessions for a significant portion of AI-assisted development workflows. The pluggable `Detector` interface was designed exactly for this extensibility. + +## User Relevance + +Developers using Gemini CLI get the same automatic session capture and checkpoint traceability that Claude Code users already have — Partio becomes genuinely agent-agnostic for the three major coding agents. diff --git a/.minions/programs/handle-negative-refspecs.md b/.minions/programs/handle-negative-refspecs.md new file mode 100644 index 0000000..81f0c9a --- /dev/null +++ b/.minions/programs/handle-negative-refspecs.md @@ -0,0 +1,43 @@ +--- +id: handle-negative-refspecs +target_repos: + - cli +acceptance_criteria: + - "`partio status` and other commands succeed in repositories that have negative refspecs (lines starting with `^`) in their git config" + - "Negative refspec lines are filtered out before passing the config to any git library parsing" + - "A test covers a repo config containing a negative refspec and verifies that partio commands complete without error" + - "No behavioral change for repos without negative refspecs" +pr_labels: + - minion +--- + +# Handle negative refspecs in git config without crashing + +Partio commands fail with a `malformed refspec` error in repositories that use negative refspecs (the `^` prefix, added in Git 2.29). Strip negative refspec lines before passing config to the git library. + +## Source + +entireio/cli issue #778 + +## Description + +Git 2.29 introduced negative refspecs (lines like `^refs/heads/experimental`) to exclude refs during fetch. However, many third-party Git libraries — including the one Partio uses — don't support this syntax and report a fatal parse error when they encounter it. + +This breaks all `partio` commands in affected repositories with an error like: +``` +Error: metadata check failed: failed to open repository: ... read config: malformed refspec, separators are wrong +``` + +Fix by pre-processing the git config before handing it to the library: +- In `internal/git/` where the repository is opened, detect and strip lines matching the negative refspec pattern (`^\s*fetch\s*=\s*\^`) before parsing. +- Alternatively, if the library supports a config override path, write a sanitized config to a temp file and use that. + +Add a test in `internal/git/` with a synthetic repo config containing a negative refspec to verify the fix. + +## Why + +This is a hard blocker for users of monorepo tooling, sparse checkouts, or any workflow that uses negative refspecs. The user cannot work around it at all — Partio simply doesn't work for them. + +## User Relevance + +Partio becomes usable for a class of repositories (monorepos, sparse checkouts, advanced fetch configurations) where it currently crashes unconditionally on every command. diff --git a/.minions/programs/implement.md b/.minions/programs/implement.md index 147aa7b..388924f 100644 --- a/.minions/programs/implement.md +++ b/.minions/programs/implement.md @@ -31,3 +31,14 @@ A human will review your PR. Make it easy for them: - Key design decisions you made - How to test the changes - Reference to the source issue (e.g., "Resolves #120") + +## Agents + +### implement + +```capabilities +max_turns: 100 +checks: true +retry_on_fail: true +retry_max_turns: 20 +``` diff --git a/.minions/programs/nightly-releases.md b/.minions/programs/nightly-releases.md new file mode 100644 index 0000000..5d555be --- /dev/null +++ b/.minions/programs/nightly-releases.md @@ -0,0 +1,44 @@ +--- +id: nightly-releases +target_repos: + - cli +pr_labels: + - minion +acceptance_criteria: + - A GitHub Actions workflow file `.github/workflows/nightly.yml` exists and runs on a daily cron schedule + - The workflow creates a nightly pre-release tag in the format `v-nightly.YYYYMMDD` only when new commits exist since the previous nightly tag + - GoReleaser builds and publishes nightly binaries for Linux, macOS (amd64 + arm64), and Windows + - The Homebrew tap formula for `partio-nightly` is updated so users can install with `brew install partio-io/tap/partio-nightly` + - Nightly binaries are clearly identified as pre-release in `partio version` output + - The release workflow for stable releases is not affected +--- + +# Nightly Releases via GoReleaser and Homebrew Tap + +## Description + +Add a nightly release workflow so users and contributors can test pre-release builds of Partio without waiting for a stable release. This mirrors how `entireio/cli` ships nightly builds (see [entireio/cli#825](https://github.com/entireio/cli/pull/825)). + +### What to implement + +1. **`.github/workflows/nightly.yml`** — a cron-driven workflow (e.g. `0 2 * * *`) that: + - Checks if any commits have been pushed since the last nightly tag + - Computes the next nightly tag: `v-nightly.$(date +%Y%m%d)` + - Creates the tag and pushes it + - Triggers GoReleaser with `--snapshot` or a dedicated nightly config + +2. **GoReleaser config** — add a nightly release config (or extend `.goreleaser.yml`) that: + - Marks the release as a pre-release (`prerelease: true`) + - Uploads binaries for `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`, `windows/amd64` + - Publishes to GitHub Releases with the `nightly` label + +3. **Homebrew tap** — add a `partio-nightly` formula to the `partio-io/homebrew-tap` repo so users can install with: + ```sh + brew install partio-io/tap/partio-nightly + ``` + +4. **Version string** — embed the nightly tag in the binary so `partio version` outputs something like `partio v0.x.y-nightly.20260402 (abc1234)`. + +### Why + +Pre-release builds let users test bug fixes and new features (e.g. new agent support) before a stable release. This is especially valuable for a CLI tool deeply integrated into Git workflows, where users often want to validate a fix against their own repos before it ships officially. diff --git a/.minions/programs/normalize-checkpoint-file-paths.md b/.minions/programs/normalize-checkpoint-file-paths.md new file mode 100644 index 0000000..647dfb5 --- /dev/null +++ b/.minions/programs/normalize-checkpoint-file-paths.md @@ -0,0 +1,41 @@ +--- +id: normalize-checkpoint-file-paths +target_repos: + - cli +acceptance_criteria: + - "All file paths stored in checkpoint data use forward slashes regardless of the OS where the checkpoint was created" + - "`filepath.ToSlash` (or equivalent) is applied to all paths before they are written into checkpoint metadata" + - "Existing checkpoints with backslash paths are handled gracefully when read back (normalized on read)" + - "A test verifies that paths with backslashes are normalized to forward slashes in checkpoint output" + - "No functional change on Linux/macOS where paths already use forward slashes" +pr_labels: + - minion +--- + +# Normalize file paths in checkpoint data to forward slashes + +Ensure all file paths stored in Partio checkpoint metadata use forward slashes, preventing cross-platform path mismatch bugs when checkpoints written on Windows are read on Linux/macOS or vice versa. + +## Source + +entireio/cli PR #803 (changelog 0.5.2), issue #778 + +## Description + +On Windows, Go's `filepath` functions return backslash-separated paths. When Partio stores these raw paths (e.g. in `FilesTouched` or session content path lists) in checkpoint metadata, those backslash paths don't match the forward-slash paths that git and Unix tools produce. This causes overlap detection in `stagedFilesOverlapWithContent` to silently return false, resulting in commits never receiving a `Partio-Checkpoint` trailer on Windows. + +Apply `filepath.ToSlash()` to all file paths at the point they are written into checkpoint data structures: + +- In `internal/checkpoint/` when constructing checkpoint metadata +- In `internal/hooks/` when building the list of staged/touched files for overlap detection +- In `internal/agent/claude/` (and any future agent) when recording session content file paths + +Additionally, apply normalization on read to handle any existing checkpoints that may contain backslash paths. + +## Why + +Path mismatch is the leading cause of silent checkpoint failures. Normalizing at write time is cheap, idempotent on Unix, and eliminates an entire class of cross-platform bugs without behavioral changes for Linux/macOS users. + +## User Relevance + +Windows users (and teams with mixed OS development environments) get reliable checkpoint capture instead of silent failures where hooks run but no trailer is ever added to commits. diff --git a/.minions/programs/partio-attach-manual-session-link.md b/.minions/programs/partio-attach-manual-session-link.md new file mode 100644 index 0000000..24f15f5 --- /dev/null +++ b/.minions/programs/partio-attach-manual-session-link.md @@ -0,0 +1,44 @@ +--- +id: partio-attach-manual-session-link +target_repos: + - cli +pr_labels: + - minion +acceptance_criteria: + - "`partio attach ` links a previously untracked session to the most recent commit" + - "`partio attach ` links the session to the specified commit" + - "Command validates that the session ID exists in the local sessions directory" + - "Command creates a checkpoint on the orphan branch linking session to commit" + - "Command fails gracefully with a helpful error if the session or commit is not found" + - "Command is idempotent: re-attaching an already-linked session updates rather than duplicates" +--- + +# Add `partio attach` command to manually link untracked sessions to commits + +## Description + +When Claude Code sessions are started outside the normal pre-commit hook flow — for example, when Partio wasn't enabled at session start, when the agent was launched from a parent directory before the repo was initialized, or when a session ran without triggering the pre-commit hook — users have no way to retroactively link those sessions to their commits. + +Add a `partio attach` command that accepts a session ID and optional commit hash, then creates a checkpoint on the `partio/checkpoints/v1` branch linking the session to that commit. + +``` +partio attach # link to HEAD +partio attach # link to specific commit +``` + +The command should: +1. Validate the session ID exists in the local Claude sessions directory (via `internal/agent/claude`) +2. Parse the session's JSONL transcript to extract metadata (prompt, context, files) +3. Calculate attribution from the session data +4. Write a checkpoint using the existing git plumbing machinery in `internal/checkpoint` +5. Amend the target commit with the `Partio-Checkpoint: ` trailer (or print instructions if amending HEAD is not desirable) + +## Context Hints + +- `cmd/partio/` — add new `attach` command +- `internal/checkpoint/` — checkpoint creation logic +- `internal/agent/claude/` — session discovery and JSONL parsing +- `internal/session/` — session lifecycle types +- `internal/git/` — git operations for commit amendment + + diff --git a/.minions/programs/session-list-info-commands.md b/.minions/programs/session-list-info-commands.md new file mode 100644 index 0000000..5698299 --- /dev/null +++ b/.minions/programs/session-list-info-commands.md @@ -0,0 +1,44 @@ +--- +id: session-list-info-commands +target_repos: + - cli +acceptance_criteria: + - "`partio session list` lists captured sessions for the current repo with columns: session ID (truncated), commit hash, timestamp, agent name, and attribution percentage" + - "`partio session info ` shows full detail for a single session including prompt excerpt, context files, and commit trailers" + - "Both commands read from the checkpoint branch (`partio/checkpoints/v1`) using git plumbing, not a checkout" + - "Output is human-readable by default; `--json` flag emits machine-readable JSON" + - "Commands are registered under a `session` sub-command of the root `partio` command" + - "Unit tests cover the output formatting logic" +pr_labels: + - minion +--- + +# Add `partio session list` and `partio session info` sub-commands + +Add CLI sub-commands for inspecting captured sessions stored on the checkpoint branch, giving users visibility into what Partio has recorded. + +## Source + +entireio/cli PR #822 + +## Description + +Partio captures rich session data on its orphan checkpoint branch, but there is currently no way to browse or inspect this data from the CLI. Users have no feedback loop to confirm what was captured or review past sessions. + +Implement a `session` sub-command group under the root `partio` command: + +- **`partio session list`**: Read checkpoints from `partio/checkpoints/v1` using git plumbing (`git cat-file`, `git log`) and display a table of sessions with: truncated session ID, linked commit hash, capture timestamp, detected agent, and attribution percentage. Support `--limit N` (default 20) and `--json` for machine-readable output. + +- **`partio session info `**: Show full detail for a session: complete session ID, commit hash, agent name, attribution, prompt excerpt (first 500 chars), list of context/session files recorded, and any trailers from the linked commit. + +Both commands must operate via git plumbing on the checkpoint branch without checking it out, consistent with how `internal/checkpoint/` already stores data. + +Register the `session` command in `cmd/partio/` following the existing command pattern. + +## Why + +Without visibility into captured sessions, users cannot verify Partio is working correctly, cannot review what context was captured, and cannot debug issues. The existing `partio rewind` command demonstrates that plumbing-based read access is feasible. + +## User Relevance + +Users get a fast feedback loop: run `partio session list` after any AI-assisted commit to confirm the session was captured, see attribution, and spot issues before they accumulate. diff --git a/.minions/programs/show-agent-detection-in-status.md b/.minions/programs/show-agent-detection-in-status.md new file mode 100644 index 0000000..cd0b398 --- /dev/null +++ b/.minions/programs/show-agent-detection-in-status.md @@ -0,0 +1,53 @@ +--- +id: show-agent-detection-in-status +target_repos: + - cli +acceptance_criteria: + - "`partio status` shows a line indicating whether the configured agent (Claude Code) is currently detected as running" + - When the agent process is detected running, the status line reads e.g. `Agent running: yes` + - When the agent is not currently running, it shows `Agent running: no` + - When detection fails with an error, it shows `Agent running: unknown (detection error)` + - The line is only shown when partio is enabled + - The existing status output for hooks, strategy, and checkpoint branch is preserved +pr_labels: + - minion +--- + +# Show agent detection state in `partio status` + +## Source + +Inspired by entireio/cli#847 (Show installed agents in status output). + +## Problem + +`cmd/partio/status.go` currently shows the configured agent name from config (e.g. `Agent: claude-code`) but does not indicate whether the agent is actually detectable in the current environment. Users enabling partio for the first time have no way to verify from `partio status` that: + +1. The Claude Code process detection mechanism is working +2. The agent is currently running (or was recently active) + +This forces users to make a commit and check if a checkpoint appears — a slow feedback loop. + +## Fix + +In `runStatus`, after confirming partio is enabled, call the agent detector and display the result: + +```go +detector := claude.New() +running, err := detector.IsRunning() +switch { +case err != nil: + fmt.Println("Agent running: unknown (detection error)") +case running: + fmt.Println("Agent running: yes") +default: + fmt.Println("Agent running: no") +} +``` + +This gives users an instant verification step without needing to make a commit. + +## Files to modify + +- `cmd/partio/status.go` — add agent detection call and output line after the hooks section +- `internal/agent/claude/process.go` — no changes needed (uses existing `IsRunning`) diff --git a/.minions/programs/stale-session-indicator-in-status.md b/.minions/programs/stale-session-indicator-in-status.md new file mode 100644 index 0000000..f06a4ce --- /dev/null +++ b/.minions/programs/stale-session-indicator-in-status.md @@ -0,0 +1,37 @@ +--- +id: stale-session-indicator-in-status +target_repos: + - cli +pr_labels: + - minion +acceptance_criteria: + - "`partio status` marks ACTIVE sessions with no interaction for >1 hour as stale" + - "Stale sessions show a hint like `(stale — run 'partio doctor')` alongside their status" + - "The staleness threshold (1 hour) matches the threshold used by `partio doctor`" + - "Sessions with a nil `LastInteractionTime` fall back to `StartedAt` for staleness calculation" + - "Non-stale ACTIVE sessions and all ENDED/IDLE sessions are unaffected" + - "A unit test covers the stale-detection logic for both the nil-fallback and normal cases" +--- + +# Add stale session indicator to `partio status` for stuck ACTIVE sessions + +## Description + +`partio status` currently shows session phase (ACTIVE, IDLE, ENDED) but gives no indication when an ACTIVE session has become stuck — for example when the Claude Code process exited without Partio detecting the session end. Users have no way to know they should run `partio doctor` to clean up. + +Add a stale indicator to `partio status` output: if an ACTIVE session's `LastInteractionTime` (or `StartedAt` as fallback) is more than 1 hour ago, annotate it with a hint: + +``` +● ACTIVE claude-code (stale — run 'partio doctor') + started 3h ago, 0 commits +``` + +The 1-hour threshold should be the same constant used by `partio doctor` for identifying stuck sessions, keeping the two commands consistent. The check is read-only — `partio status` should never modify session state. + +## Context Hints + +- `cmd/partio/` — status command rendering +- `internal/session/` — session types and `LastInteractionTime` field +- `internal/agent/` — agent session state phases (ACTIVE, IDLE, ENDED) + + diff --git a/.minions/programs/store-tree-hash-in-checkpoint-metadata.md b/.minions/programs/store-tree-hash-in-checkpoint-metadata.md new file mode 100644 index 0000000..d8476d4 --- /dev/null +++ b/.minions/programs/store-tree-hash-in-checkpoint-metadata.md @@ -0,0 +1,49 @@ +--- +id: store-tree-hash-in-checkpoint-metadata +target_repos: + - cli +acceptance_criteria: + - "checkpoint.Metadata struct gains a TreeHash field (string, json:\"tree_hash,omitempty\")" + - "post-commit hook resolves the current commit's tree hash via `git rev-parse HEAD^{tree}` and stores it in Metadata when creating a checkpoint" + - "checkpoint write path includes tree_hash in the stored JSON blob on the orphan branch" + - "existing checkpoints without tree_hash are unaffected (field is omitempty)" + - "unit test verifies tree_hash is populated in the Metadata written by post-commit" +pr_labels: + - minion +--- + +# Store tree hash in checkpoint metadata for linkage resilience after history rewrites + +## Problem + +When users rewrite git history (e.g. `git rebase -i reword`, `git filter-branch --msg-filter`, `git commit --amend`), the `Partio-Checkpoint:` trailer is stripped from the rewritten commit message. The checkpoint data still exists on `partio/checkpoints/v1`, but the rewritten commit no longer points to it. The user loses their agent label and session link. + +A commit's tree hash represents its code content. History rewrites change the commit SHA and can strip the message, but the tree hash stays the same (same code = same tree). By storing the tree hash during checkpoint creation, the web-side or `partio rewind` can match rewritten commits to their original checkpoints via tree hash when no trailer is found. + +## What to implement + +In `internal/checkpoint/checkpoint.go`, add `TreeHash string` to the `Metadata` struct: + +```go +type Metadata struct { + // ... existing fields ... + TreeHash string `json:"tree_hash,omitempty"` +} +``` + +In the post-commit hook (`internal/hooks/postcommit.go`), after the commit completes, resolve the current commit's tree hash: + +```bash +git rev-parse HEAD^{tree} +``` + +Pass the tree hash into the checkpoint creation flow and store it in `Metadata.TreeHash` before writing to the orphan branch. + +The `Checkpoint` domain type (`checkpoint.Checkpoint`) does not need to change — tree hash is metadata-layer detail relevant to storage and recovery, not business logic. + +## Inspiration + +- `entireio/cli` PR #840 — store tree hash in checkpoint metadata for linkage resilience +- `entireio/cli` issue #834 — rewording commits can silently break Entire linkage when trailers are dropped + + diff --git a/.minions/programs/warn-on-checkpoint-trailer-rewrite-loss.md b/.minions/programs/warn-on-checkpoint-trailer-rewrite-loss.md new file mode 100644 index 0000000..4aa80e8 --- /dev/null +++ b/.minions/programs/warn-on-checkpoint-trailer-rewrite-loss.md @@ -0,0 +1,37 @@ +--- +id: warn-on-checkpoint-trailer-rewrite-loss +target_repos: + - cli +acceptance_criteria: + - "`partio doctor` detects commits that are missing Partio-Checkpoint trailers and reports them" + - "`partio doctor` output includes actionable guidance when trailer loss is detected (e.g. how to reattach or what caused the loss)" + - "Detection covers git rebase reword, interactive rebase, and git commit --amend scenarios" + - "make test passes" + - "make lint passes" +pr_labels: + - minion +--- + +# Warn users when Partio-Checkpoint trailers are dropped by commit rewrite operations + +## Description + +When users reword commits via `git rebase -i` (reword action), `git commit --amend`, or `git filter-branch --msg-filter`, the rewrite operation replaces the entire commit message. If the replacement message does not include the `Partio-Checkpoint:` trailer, the session link is permanently lost — Partio shows no checkpoint for those commits in `partio rewind` and `partio doctor` output, with no explanation of why. + +This was reported in entireio/cli#834. + +## What to fix + +In `partio doctor`, add a check that scans recent commits for this pattern: + +1. Find commits that have a `Partio-Checkpoint:` trailer in the previous version of the commit (detectable via reflog) but not in the current commit message. +2. Alternatively, detect commits where the parent commit has a checkpoint but the current commit does not — a possible sign of rewrite loss. +3. Report these commits with a clear message explaining that git rebase/amend operations can drop Partio trailers and how to avoid it (e.g. by preserving trailers in the rebase editor or using `git notes` as an alternative). + +The check should be non-fatal and informational — it should not block any git operations. + +## Context hints + +- `cmd/partio/` — doctor command implementation +- `internal/git/` — git log, reflog, and commit message parsing utilities +- `internal/checkpoint/` — checkpoint reference and trailer utilities diff --git a/.minions/sources.yaml b/.minions/sources.yaml index 7add2e8..829b41f 100644 --- a/.minions/sources.yaml +++ b/.minions/sources.yaml @@ -2,14 +2,14 @@ sources: - name: entireio-cli url: https://github.com/entireio/cli/blob/main/CHANGELOG.md type: changelog - last_version: 0.5.1 + last_version: 0.5.3 - name: entireio-cli-issues url: https://github.com/entireio/cli/issues type: issues repo: entireio/cli - last_version: "750" + last_version: "844" - name: entireio-cli-pulls url: https://github.com/entireio/cli/pulls type: pulls repo: entireio/cli - last_version: "746" + last_version: "856"