docs: clarify where specs live during brainstorming → plan → implement (main vs. branch)

[atomikpanda]

Observed

The bundled brainstorming skill writes specs to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and says "commit the design document to git". It doesn't say WHICH branch.

In practice on #104 this caused a tangle:

• Spec committed on main (no active task yet — brainstorming runs before mship spawn).
• mship spawn then cut the feature branch from main, inheriting the spec.
• Iterative spec edits during the brainstorm refinement landed on main (because absolute paths in tool calls resolved to main's checkout) — but the work was supposed to be on the feature branch.
• Result: spec divergence between main and the branch; manual cherry-picks to reconcile.

Why this matters

mship view spec resolves through .mothership/, which is anchored to main's git common-dir. Symlinks (and the blessed task-spec path) point into the main checkout, so updates to the spec on the feature branch are invisible to mship view spec unless the spec also exists on main with the same content. Agents and users following the brainstorming skill have no guidance about which side to edit.

This is a workflow ambiguity, not a CLI bug — but it's load-bearing for any agent that runs brainstorming → plan → implement in sequence.

Suggested direction

Pick a convention and document it. Two reasonable models:

1. Specs are docs and live on main. Brainstorming commits the spec on main BEFORE mship spawn. The feature branch consumes the spec; spec edits during the implementation happen on main directly (and then optionally rebase/merge into the branch). Matches current mship view spec resolution; fights "never edit main during a task".
2. Specs live on the feature branch. Brainstorming spawns the task FIRST, then writes the spec on the branch. mship view spec --task <slug> would need to resolve through the worktree's branch (currently it resolves through main).

Option 1 needs only a docs change. Option 2 needs (1) plus a behavior change in spec discovery.

Acceptance

• The brainstorming skill (in src/mship/skills/brainstorming/, if vendored, or the upstream superpowers source) explicitly says which branch to commit the spec on.
• The working-with-mothership skill mentions the convention in its spec/docs section.
• If we adopt option 2, file a separate issue for the discovery change.

Related

• First-class task dependency graph (blocks / depends-on) — design issue, marinating #104 (discovered during implementation).
• mship view spec --task <slug>: filename-match fallback before newest-by-mtime #140 (also a mship view spec resolution issue — adjacent surface).