Summary

Technical plans are often valuable when they include pseudo-code, DSL grammars, or architectural diagrams in plans to validate the approach direction — without the plan crossing into prescriptive implementation code that downstream implementing agents take as gospel.

This PR adds optional "High-Level Technical Design" support at two levels:

• Overview level (new plan section before Implementation Units): system-level shape — architecture diagrams, DSL grammars, state machines, data flow sketches. The skill chooses the right medium based on what the work actually involves.
• Unit level (new optional field per implementation unit): tactical shape of a specific component, only when prose alone would leave the approach ambiguous.

Both levels carry explicit non-prescriptive framing: "This is directional guidance for review, not implementation specification."

Ultimately this paves a nice path to promote this to stable sometime soon.

Why this matters

There's a gap between "decisions, not code" (current plan-beta) and literal implementation code. Pseudo-code/DSL sketches sit in that gap — they let a reviewer say "yes, this direction is right" without dictating what the implementing agent should produce. The key concern driving the design: avoid specific code that the next implementation agent takes as gospel and reproduces verbatim.

Changes

ce-plan-beta:

• Soften core principle to allow pseudo-code/DSL sketches with non-prescriptive framing
• New Phase 3.4 with decision table for choosing the right medium
• Optional per-unit "Technical design" field
• Template updated with optional section and framing
• Standard/Deep depth guidance clarified: optional sections should be omitted when they add no value

deepen-plan-beta:

• Confidence gap checklists for technical design (when present and when absent)
• Agent mapping for validating/strengthening technical design sections
• Guardrails explicitly permit pseudo-code in both top-level and per-unit locations