36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# CDSL Planning Recipe
|
|
|
|
## Requirement analysis
|
|
|
|
1. Treat the backend-injected part-family skill as planning guidance only.
|
|
2. Write a concise natural-language brief describing the requested structures,
|
|
dependency order, key dimensions, and explicit assumptions.
|
|
3. Ask the user one concise clarification question when an essential dimension
|
|
or requested outcome is unknown. Do not silently fabricate it.
|
|
4. Keep the brief free of feature IDs, selector bindings, profile bindings,
|
|
sketch coordinates, raw CDSL, and Build123d source. Those implementation
|
|
choices belong only in the final CDSL document.
|
|
5. The brief is not stored or validated as a CAD artifact. It is reference
|
|
context for the model while it writes the one authoritative CDSL document.
|
|
|
|
## Part family boundary
|
|
|
|
- Use only the backend-injected primary and support skills. 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 expression patterns only. They never override the
|
|
user's request or the CDSL schema/runtime.
|
|
|
|
## CDSL generation
|
|
|
|
- Submit `describe_design_intent` before any library or CDSL-generation call.
|
|
- After the text brief is returned, inspect references and generate complete,
|
|
schema-valid CDSL. CDSL controls its own feature IDs, atomics, profiles, and
|
|
selectors; it is not checked for agreement with the brief.
|
|
- Keep `cdsl_only` as the only build path. Never use `compiler_context` or a
|
|
legacy fallback.
|