Fix #744: state one-PR-per-spec convention in SPIR builder-prompt

[waleedkadous]

Summary

The SPIR/ASPIR builder-prompt templates did not state any PR-strategy convention. Builders interpreted the plan's "each phase commits independently" as "each phase gets its own PR" and shipped per-phase PRs that the architect then had to close (Shannon Spec 1353 → PR #1373).

Fixes #744

Root Cause

Two issues stacked:

1. codev/protocols/spir/builder-prompt.md (and the ASPIR equivalent) had no PR-strategy guidance at all.
2. The codev-skeleton mirror had a "Multi-PR Workflow" section that explicitly said "Continue to the next phase, open another PR. Repeat." This pattern is intended for architect-requested slice splits of large specs (e.g. Spec Better handling of builders that stop mid-protocol and create premature PRs #653), but the template framed it as the default workflow.

Fix

Adds a ## PR Strategy section to all four SPIR/ASPIR builder-prompt files (codev + skeleton) prohibiting only the builder's autonomous decision to open a PR per implementation phase — while explicitly preserving the architect's ability to request a PR at any point.

Key wording (per architect review on this PR):

• "Do not autonomously open a PR per implementation phase." Plan phases ship as git commits within a single PR.
• By default, the PR is opened during/after the final implement phase, with all phase-commits already on the branch.
• Architect-requested PRs (new subsection): the architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs. The prohibition is specifically on the builder autonomously deciding to open per-phase PRs without architect request.

In the skeleton, the existing multi-PR mechanics block (cut branch → push → merge → fetch → next branch) is preserved and re-scoped as "Multi-PR Mechanics (when the architect requests sequential PRs)" — the how-to for architect-driven slice splits.

Test Plan

• Regression test (bugfix-744-spir-pr-strategy.test.ts) — asserts all four builder-prompt files contain (a) the autonomous-PR prohibition, (b) the git-commits-vs-PRs clarification, (c) the architect-override carve-out, and (d) the default PR-timing statement
• Build passes
• All tests pass (2616 passed | 13 skipped — same baseline as main)

[waleedkadous]

Architect requesting changes — the current text is too rigid.

What you have now:

ONE PR per spec, opened at the end of the implement phase

This would block a real workflow: the architect MAY request a PR early (e.g., for spec review, mid-implementation feedback, or to slice a large spec into shippable PRs). The current wording forbids that.

What we actually want to prohibit: the builder autonomously opening a separate PR for each implementation phase. NOT "one PR per spec, ever, no matter what."

Suggested wording:

## PR Strategy

**Do not autonomously open a PR per implementation phase.** Plan phases ship as git commits within a single PR, not as separate PRs. The plan's instruction that 'each phase commits independently' refers to git commits, not PRs.

By default, the PR is opened during/after the final implement phase, with all phase-commits already on the branch.

### Architect-requested PRs

The architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs, etc. When the architect explicitly asks for a PR earlier (or for additional PRs), follow that direction. The prohibition is specifically on the *builder* autonomously deciding to open per-phase PRs without architect request.

Please update the four prompt files (SPIR + ASPIR × codev/ + skeleton/) and adjust the regression test if it pins the old wording. Same triple-APPROVE CMAP cycle when ready.

[waleedkadous]

Architect approval — the revised wording captures the intent exactly. The three-part structure (autonomous prohibition / default timing / architect-override carveout) is the shape we want as a pattern for all future prompt restrictions. Approved — please merge with gh pr merge 747 --merge --admin.