Replace the worktrunk-marker convention with CAP (cap-protocol.org) once it stabilizes

[noirbizarre]

Depends on #86.

Problem

The marker convention proposed in #86 is worktrunk's own bespoke git-config
format, populated only by the specific plugins worktrunk ships for Claude
Code, Codex, OpenCode and Gemini CLI
(https://worktrunk.dev/claude-code/#activity-tracking) — any other agent CLI,
or a user who hasn't installed the matching plugin, gets nothing, and
git-wipe falls all the way back to #66's coarse process scan.

CAP is a draft protocol (v1, public review since
2026-05-18) purpose-built for the same problem from the orchestrator side:
driving/observing any CLI agent uniformly. Its agent manifest already models
the "working vs waiting" distinction generically, without per-agent plugins:

[parse]
idle = ["^> $", "^❯ $"]

An agent's manifest declares its idle-state pattern once; a CAP-aware consumer
matches it against the agent's PTY output (or a structured fast-path event,
when the agent exposes stream-json/gRPC/ACP/A2A) to know whether it's idle
or mid-turn — a superset of worktrunk's binary 🤖/💬 marker, sourced from the
agent/protocol layer instead of a third-party tool's plugins.

Proposal

This is explicitly not actionable yet. CAP is a draft spec with a
reference implementation "in progress" and no released agent manifests, per
its own roadmap (stated bar for wider governance: "once 3+ independent
implementations exist"). Filing this now so it isn't forgotten; revisit once:

• CAP publishes a stable (non-draft) Core v1 spec, and
• either a released crate implementing the manifest/PTY-parsing side exists to
  depend on, or the manifest format is stable enough to parse [parse].idle
  directly, and
• first-party manifests exist for the agents actually used against this
  project's worktrees (Claude Code, Codex, OpenCode, Gemini CLI, aider, ...).

When those conditions hold, extend the detection added in #86 with a second,
preferred source: look for a CAP manifest for the running agent (bundled with
the agent, /usr/share/cap-agents/, or via --cap-manifest) and derive
working/waiting from its [parse].idle pattern rather than — or in addition
to — the worktrunk git-config marker. Keep the worktrunk-marker path as a
fallback for repos without CAP-aware agents rather than removing it; the two
are not mutually exclusive.

Acceptance

• Stays open/blocked and out of scope for implementation until CAP Core v1
  leaves draft status.
• When picked up: CAP-sourced status takes priority over the worktrunk
  marker when both are available; the worktrunk marker remains the
  fallback for non-CAP agents.
• No new required runtime dependency on an unstable/pre-1.0 crate — vendor
  or gate behind a feature flag if the reference implementation is still
  pre-release at that time.

[noirbizarre]

I think CAP is now interesting enough to revisit this sooner than the original “wait until stable” criteria suggest.

The reference implementation already has an OpenCode integration via ACP, including structured agent messages/reasoning, tool calls, plans and permissions, so we could potentially consume agent state without relying on the worktrunk-specific marker/plugins. Pi is also a target I’m interested in supporting, which makes a protocol-level integration more attractive than adding another agent-specific hook.

For git-wipe, I’d propose treating CAP as a read-only agent inventory alongside the existing Git/worktree inventory:

• correlate CAP agents with worktrees primarily via their cwd;
• expose an optional agent state on each status row (working, waiting, permission, idle, etc.) rather than adding these as Git flags;
• show the agent/provider and state in git-wipe status and the interactive branch/worktree selection;
• add filters such as --agent working, --agent waiting, and --no-agent;
• support multiple agent states in a single filter, e.g. --agent working,waiting, with inclusive (OR) semantics; repeated --agent options could also be accepted as an equivalent form;
• apply the same multi-state filtering semantics to the interactive deletion selection;
• eventually use agent activity as a safety guard so an active/waiting agent’s branch is not selected for deletion.

I’d keep the worktrunk marker as a fallback for non-CAP agents, and avoid making CAP a hard dependency while the protocol/crate is still pre-1.0 (feature-gate or optional integration if needed).

This also gives us a useful real-world test case for CAP: passive discovery of agent/session state from an existing Rust CLI, rather than making git-wipe responsible for launching or controlling agents.