DesignIntent Planning Recipe

Requirement analysis

Treat the backend-injected part-family skill as the selected family before identifying structures. It provides planning guidance only.
Decompose the requested part into structures with roles: base, reference, additive, subtractive, dressup, or pattern.
Every structure must state a purpose, structural dependencies, parameter roles, selector roles, an executable CDSL atomic ID, and a named profile type when its atomic needs a sketch.
Put every structure exactly once in feature_order, after its dependencies. Its cdsl_feature_id is the immutable ID that the later CDSL feature must use.
Do not put coordinates, raw CDSL, Build123d, or low-level sketch data in a DesignIntent.
Missing essential dimensions are blocking open_questions. Unsupported geometry is a capability_gaps item. A blocking item requires status: needs_clarification; do not approximate silently.

Use only the backend-injected primary and support skills. Never submit part_skill_ids; the backend records the canonical selection for audit.
Explicit user requirements override part skills. The executable CDSL schema/runtime overrides both part skills and library examples.
The current primary family is inherited during revisions unless the user explicitly asks to replace the whole part. A family conflict needs a concise clarification before a ready plan can be submitted.
CDSL library examples show only expression patterns. They never add or remove a requested DesignIntent structure.

Submit propose_design_intent before any library or CDSL-generation call.
After its ready result includes intent_id, inspect references and generate complete CDSL. Use every planned cdsl_feature_id once, in feature_order.
Do not add undeclared CDSL features, delete planned features, change planned atomics/profiles, or omit declared selector evidence.
Keep cdsl_only as the only build path. Never use compiler_context or a legacy fallback.