Codify plan-stage output scope-flex (≤3 ACs = inline plan; 4+ = separate doc) in development template

[clkao]

TL;DR

In a deliberately-larger-scope task workflow (development-template-shaped, with multi-AC tasks rather than the agile-story shape), the plan stage's default output is a separate plans/{slug}.md document. That shape is right for medium-and-large tasks (5-8 ACs across multiple files) but heavy for tiny tasks (1-3 ACs, single-file change) — the plan worker spends a meaningful slice of context producing a 600-line plan doc that ends up being read by a validator who could have read the entity's ## Acceptance criteria section directly.

A captain operating a real workflow this session asked: "FU-2 is tiny — how do we manage granularity vs PKG-4 which is large? Same workflow, different shape?" The answer that emerged was: same workflow, plan-stage output scales by AC count:

• ≤3 ACs / single-file change → inline plan (plan worker writes a short stage report on the entity body itself, no separate plans/{slug}.md doc; validation reads the AC list directly).
• 4+ ACs / multi-subsystem change → separate plan doc at plans/{slug}.md per the existing default.
• The FO names the size at dispatch time ("tiny task — inline" vs "standard — separate doc").

The captain manually codified this in their workflow's README prose under the plan-stage definition. It would be a small but real captain-experience improvement to ship this scope-flex rule as part of the development template's plan stage definition by default, so future commissioned workflows don't reinvent it.

Proposed fix

In skills/commission/references/templates/development.md, under the plan stage's bullet list, append a new bullet:

- **Plan output scope (flex by AC count):**
  - ≤3 ACs / single-file change → **inline plan**. Plan-stage worker writes
    a short stage report on the entity body itself (no separate
    `plans/{slug}.md` doc). Validation reads the AC list directly.
  - 4+ ACs / multi-subsystem change → **separate plan doc** at
    `plans/{slug}.md` per the standard flow. AC↔task map table at the top;
    design-doc §-cites per task.
  - The FO names the size at dispatch time (\"tiny task — inline\" vs
    \"standard — separate doc\").

This text matches the README a captain just shipped in a real workflow. The threshold (≤3 / 4+) and the FO-names-the-size-at-dispatch protocol are both load-bearing — the threshold gives the worker a clear rubric, and the dispatch-time naming makes the size choice auditable in commit messages.

Optionally, the refinement template could carry the same rule with a different threshold (since refinement tasks are usually smaller).

Why this matters

Captains commissioning new workflows hit this within their first sprint:

• The default "every task gets a 600-line plan doc" feels right for the first 2-3 tasks.
• Then a tiny fix task lands (one-line change to fix a defect), and the captain notices the plan worker just spent ~2 minutes producing a plan doc that is 4× longer than the actual fix.
• The captain manually adds a scope-flex rule to their README and forwards the dispatch-time-naming protocol to the FO.

Codifying this in the template means every commissioned workflow gets it on day one.

Acceptance criteria

• AC-1 — development template's plan-stage bullet list includes the scope-flex rule. Verified by reading skills/commission/references/templates/development.md.
• AC-2 — Commissioned READMEs include the rule as a consequence of the template injection. Verified by commissioning a new workflow and inspecting the generated README's plan-stage section.
• AC-3 — (Optional) refinement template carries a matching rule. Verified similarly.

Out of scope

• Auto-detecting AC count and warning the captain. The captain knows what they're filing; the rule is for the plan worker's behavior, not for filing-time validation.
• Changing the threshold (≤3/4+) by template. The threshold is a sensible default; captains can override in their README.

Spacedock version

commissioned-by: spacedock@0.11.2 (from the workflow that motivated this).