After PR #1335 Shipping

What other commands need checkpoints v1.1 support? Check out the changes in that PR to answer.

Real gaps

1. entire doctor (and doctor bundle) — the main one.

Zero references to the mirror ref anywhere in doctor.go/doctor_bundle.go. Doctor diagnoses v1 local-vs-origin disconnection (doctor.go:339) but nothing detects a missing, stale, or diverged mirror. Since the PR explicitly removed read-time self-repair, doctor is the natural repair path. A check + fix is cheap: compare mirror to v1 tip and call strategy.MirrorCommittedMetadataRef. doctor bundle also doesn't capture mirror ref state for debugging.

2. entire resume / session resume — remote-metadata story under v1.1.

Deliberately degraded in this PR, and flagged as such in its CLAUDE.md edit:

• promoteRemoteTrackingMetadataBranch is skipped when the read ref isn't v1 (resume.go:193)
• checkRemoteMetadata (resume.go:606) bails with "This ref is local-only. Try: entire explain"

So under v1.1, resuming a checkpoint whose metadata only exists on origin doesn't work. This matches the mirror-first phased rollout — a later phase needs the v1.1 fetch story.

3. entire clean — no way to remove or reset the mirror ref.

clean.go, strategy/cleanup.go, and manual_commit_reset.go enumerate shadow branches, session state, and temp files only — refs/entire/* is never discovered or deleted.

Minor / Housekeeping

• checkpoint.LookupSessionLog — exported committed-read entry point still bound to v1 via NewGitStore, but it has zero callers on the branch. Dead API — delete or convert before someone uses it.
• benchutil.go:174 — benchmarks construct a v1-bound store directly; only matters if you want benches to exercise the v1.1 read path.

Looks Like a Gap But Is Intentional (Don't Chase These)

• attach.go:423–430``checkpointPresentLocally reads local v1.
• manual_commit_hooks.go:1064/2773 (attribution, transcript finalize) read v1 right after writing v1.
• cleanup.go:172 orphan detection reads v1.
• manual_commit_logs.go trailers embed entire/checkpoints/v1.
• entire search, activity, trail — no local committed-metadata reads.

Short Version:

The next PRs are (1) doctor check+repair for the mirror, (2) the v1.1 remote-fetch path, (3) mirror-ref cleanup in entire clean, plus deleting dead LookupSessionLog.

Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short, but you MUST present it and get approval.

Checklist

You MUST create a task for each of these items and complete them in order:

1. Explore project context
2. Offer visual companion
3. Ask clarifying questions
4. Propose 2-3 approaches
5. Present design
6. Write design doc
7. Spec self-review
8. User reviews written spec
9. Transition to implementation

Process Flow

digraph brainstorming {
    ... 
}

Understanding the Idea

• Check out the current project state first.
• Help the user decompose into sub-projects.

Exploring Approaches

• Propose 2-3 different approaches with trade-offs.

Presenting the Design

• Once you understand what you’re building, present the design.

Design for Isolation and Clarity

• Break the system into smaller units that each have one clear purpose.

Working in Existing Codebases

• Explore the current structure before proposing changes.

After the Design

• Write the validated design (spec) to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md. See the visual companion section for more context.

Test-Driven Development (TDD)

Overview

Write the test first. Watch it fail. Write minimal code to pass.

Key Principles

• One question at a time
• Multiple choice preferred
• YAGNI ruthlessly
• Explore alternatives
• Incremental validation
• Be flexible

Common Rationalizations

Verification Checklist

• Every new function/method has a test
• Watched each test fail before implementing
• Each test failed for expected reason (feature missing, not typo)

Testing Anti-Patterns

When adding mocks or test utilities, read @testing-anti-patterns.md to avoid common pitfalls.