Cad sim project intake

CAD Sim Project Intake

Contents

• Invocation Order
• Contract
• Minimal Artifacts
• Surface Re-Intake Mode
• Workflow
• Brief Shape
• Routes

Invocation Order

1. Use cad-sim-project-intake first for a rough idea or a new run.
2. Use cad-sim-design-orchestrator next after intake/project_brief.yaml exists and CAD/system authoring should begin.
3. Use cad-sim-review-revise-loop after the design pass has produced a current handoff.json and canonical annotation_view/.
4. When cad-sim-review-revise-loop routes narrow surface re-intake, use this skill only to ask targeted questions and update the brief/review contract; return to the review loop afterward.

Use cad-sim-threaded-rehearsal-workflow instead of these individual steps when the user wants a fresh-folder role-separation rehearsal with controller, Rehearsal Agent, Meta-Agent, reviewer, and optional comparator.

Contract

Turn a rough CAD idea into one compact brief and rubric before any CAD authoring starts. The completion criterion is a project_brief.yaml that lets a Meta-Agent proceed without repeatedly asking the user for reminders, while making clear how far it may continue autonomously before returning. When the user wants minimal steering, compile an autonomy_after_grill contract that lets the Meta-Agent keep working until the reviewer has no material feedback or the next useful step truly needs user evidence.

The user does not need to create a run folder. If no run root is provided, create a timestamped run root under the active project folder, report it, and use that root for all intake artifacts.

Minimal Artifacts

Write under the active run or study root. If there is no active run root, create one before writing:

source_boundary_preflight.yaml   # only for source-blind or comparator-sensitive runs
intake/project_brief.yaml
intake/open_questions.md   # only while waiting for user answers
intake/surface_reintake_NNN.yaml   # only for narrow surface re-intake

project_brief.yaml is the single source of truth for initial prompt, bounded research notes, grill questions, user answers, requirements, assumptions, review contract, review rubric, and stop rules. Do not create separate interview, requirement, issue-ledger, or validation-plan files unless the run has a specific reason to split them. Use source_boundary_preflight.yaml only as a compact boundary lock before active authoring inspects context that could contaminate a source-blind run.

Surface Re-Intake Mode

Use narrow surface re-intake only when an existing run already has a candidate or primary outcome surface, but the Meta-Agent or reviewer cannot infer what the user values, who the surface is for, what depth matters, what decision it supports, or which tradeoff priority controls the work.

Ask 1-3 directed questions with concrete options. Good question targets include audience, next real action, depth allocation, decision target, tradeoff priority, and whether the surface should be a website, guide, report, notebook, dashboard, robot bring-up guide, simulator packet, CAD handoff, or evidence packet. Do not ask broad questions such as "What do you think?".

Write intake/surface_reintake_NNN.yaml with the questions, answer options, safe default if any, and resume point. Update intake/project_brief.yaml with a compact primary_outcome_surface block and any review-contract acceptance tests created by the answer. Do not author, revise, or review the candidate; return to cad-sim-review-revise-loop.

Workflow

1. Choose the run root. Use the provided root when one is explicit; otherwise create a timestamped root under the active project and record the path in the response or workflow state.
2. Read the user prompt, allowed local references, and named source-boundary rules. Only read raw-session packets when the role's allowlist explicitly names them. For source-blind, comparator-sensitive, or rehearsal runs, lock the source boundary before the active Meta-Agent reads memory files, workflow state, previous run folders, comparator outputs, raw solution material, or local reset-repo skill files. Write source_boundary_preflight.yaml with the role, allowed inputs, forbidden inputs, and a note that no pre-lock memory or workflow-state inspection occurred. If the boundary is unclear, stop as needs_source_boundary_preflight instead of inspecting more context to infer it.
3. Gather only context that changes the first grill or rubric. Cite or name the source in research_notes; skip broad research when the prompt is already concrete enough.
4. Ask one consolidated grill. First identify the project domain mix: mechanical/CAD, printable part, robotics, electromechanical, fixture, enclosure, software-connected hardware, or other. Cover the relevant interfaces, envelope, attachment, retention, loads/motions, purchased or reused hardware, electrical/power/signal interfaces, sensors/actuators, firmware/software/control assumptions, tools, assembly and install/remove sequence, print or fabrication process, intended real-world use, validation/simulation needs, materials/process assumptions, visual references, success criteria, rejection criteria, and evidence limits. When analysis or optimization may matter, classify the analysis intent: design_aid for quick checks that catch mistakes, physically_reasonable_optimized_design for a buildable baseline followed by bounded variant improvement, or simulation_optimization_study when simulation/optimization is the main project and CAD is one artifact inside the study. When the user wants the system to get as far as possible before returning, also ask for an autonomy-after-grill contract: preferred autonomy mode, acceptable default hardware/materials, printer/process assumptions, dimensional variants, whether bounded online research, browser use, computer use for simulator UIs, datasheet lookup, package/library install, CAD/reference-file download, locally authored simulations, GPU simulation frameworks such as Warp, open-source simulators, commercial simulators, or cad-sim-tooling-research-scout are allowed, which analysis or simulation tiers are allowed, which decisions require the user, which evidence requires physical measurement or testing, and whether needs_user pauses should resume automatically after the answer. Also ask how the user wants later clarification handled: one phone-friendly question at a time or a compact batch, preferred answer format, which decisions may be defaulted, and which questions require desktop review or inspecting files. When the prompt asks for high autonomy, manufacturing, printing, ordering parts, or "tell me what to buy/build," ask whether the desired first user review should target prototype_handoff_review_ready: a compact BOM, custom manufacturing handoff, assembly/use and first-test instructions, visible retention/fastener paths, and no unexplained visible geometry. Include why each question matters. When the user asks for a prototype handoff, high autonomy, or easy review, also ask whether an interactive assembly/manufacturing handoff surface is allowed or desired when useful. Explain that this can be a compact HTML page, linked viewer3d view, simple stepper, animation, simulator view, or other small artifact, but only when it makes manufacture, assembly, use/removal, or first-test review clearer. When a prototype handoff or user-facing guide is likely, ask what primary handoff surface the user expects to review, or choose a default such as assembly_guide.html, design_review_packet.html, build_use_package.md, prototype_handoff/index.html, or an equivalent project-specific surface. Also capture the short list of actions that surface must let the user review, such as buy, print, machine, prepare, assemble, install, use, remove, inspect, test, reject, flash, calibrate, or simulate. Capture enough information to seed annotation_view/primary_outcome_surface_brief.yaml: audience, next real action, primary surface type/path, canonical entities/artifacts, critical claims, topics that deserve deep treatment, topics that should stay compact, required sections or states, evidence the user expects embedded, launch expectations, and explicit non-claims. Existing legacy runs may still use annotation_view/primary_surface_brief.yaml. Add a compact rubric-customization grill when A+ handoff, high autonomy, optimization, simulation, real-world build/use, or a primary guide is likely. Ask what A+ would mean in the user's words, which risks matter most, what evidence would convince them, whether they want one evidence-embedded primary website or equivalent front door, and how much design-option exploration is worth doing. Default to one embedded primary handoff surface for A+ work: readiness-critical CAD views, staged states, plots, tables, calculations, simulator exports, procurement examples, and design-decision evidence should be visible in the primary artifact, while raw files remain audit/download links. Default option exploration to a compact comparison of 2-4 plausible approaches for behavior-critical decisions; create full alternate CAD or simulation variants only when cheap and likely to change the selected design. When high autonomy, A+ handoff, prototype handoff, simulation/optimization, a primary outcome surface, or minimal future steering is in scope, record compact exemplar_calibrated_handoff intent. Default it to active with reusable_tests_expected: true and choose 2-5 emphasis tags from the project, such as procedural_clarity, mechanism_legibility, design_story, simulation_decision_packet, robot_bringup, software_setup_diagnostics, or evidence_maturity. Do not create a separate rubric here; this seeds active-rubric rows later. For high-autonomy prototype handoffs, record a compact handoff_quality_bar: the primary audience is a practical non-CAD builder, the secondary audience is a competent engineer/auditor, instruction density should be detailed but skimmable, the default ready threshold is A_plus_builder_handoff, and the tooling-scout policy is separate_agent_when_in_doubt. Also record that critical design decision evidence closure is required for A+ readiness: the Meta-Agent and reviewer should identify behavior-critical choices and evidence-close them at the right fidelity tier before asking for user review. Record design_decision_coverage for A+ handoff, optimization, simulation, raw-parity autonomy, or real-world build/use projects. Use the leading phrase design-decision coverage: important non-obvious choices must be named, justified, and evidence-backed, not merely discovered ad hoc by a reviewer. Choose compact expected_decision_types from the project, such as geometry/features, retention/fastening/load path, material/process, manufacturing/print orientation, assembly/tool access, simulator/tooling choice, optimization variables/objectives, validation strategy, and claim boundaries. Also record option_space_coverage for the same projects: the system must compare plausible options for behavior-critical or trust-critical choices, or explicitly explain why alternatives are not useful. Keep this as a light design-decision standard, not a mandatory multi-branch CAD pipeline. When this A+ threshold is requested, also plan a masters_engineering_submission score rubric using the shared cad-sim-reviewer-lenses/references/master_engineering_handoff_rubric.md and cad-sim-reviewer-lenses/references/submission_grade_calibration.md reference and the profile overlays in cad-sim-reviewer-lenses/references/rubric_profiles.md. Select review_rubric.profile from physical_prototype, robotics_electromechanical, simulation_optimization, software_connected_hardware, design_review_only, or hybrid. For hybrids, choose one primary profile and list secondary checks instead of merging every checklist. Keep the rubric compact and project-specific inside project_brief.yaml; split to intake/review_rubric.md only if it would make the brief unwieldy. Also record compact review_rubric.profile_critical_risks from the selected profile so later reviewers do not wait for the user to name obvious checks such as mechanism confidence, sourcing, manufacturability, model fidelity, wiring/config, or validation boundaries. Record review_rubric.submission_grade_calibration with grade_as_submitted_now: true, route_grade_separation_required: true, and a profile-specific note about what evidence maturity would be required for A/A+. The default is that useful route readiness can exceed the submitted-now grade. When the project is simulation-heavy, optimization-heavy, domain-unfamiliar, commercial-tool-sensitive, or likely to need a custom review surface, ask a compact tooling decision grill before first CAD. Do not leave the answer as ask_first. Force the user to choose required_before_first_design, allowed_when_triggered, or forbidden for a tooling scout; identify the decision owner (separate_tooling_scout, inline_meta_agent, or user_selected_tool); choose whether the scout may only recommend, run small allowed probes, or request approval for installs/runs; and choose programmatic_first, balanced, or capability_first for agent operability. Separately resolve whether simulation may be selected and run within the allowed tier, must be recommended and approved, or is forbidden without new approval. Ask separately about web access, downloads, package installs, local scripts, GUI automation, credentials, cloud/GPU jobs, paid tools, and private-file upload. Ask for capabilities and boundaries rather than making the user choose an unfamiliar product name. Clarify that a separate scout chooses tools and evidence strategy; it does not judge or author the design. If the user explicitly authorizes safe assumptions, default to allowed_when_triggered, recommend_only, balanced, and scout_recommends_then_asks, while preserving narrower capability policies.
5. Stop for the user's answers unless the user explicitly says to proceed by assumption. While stopped, keep only intake/open_questions.md.
6. After answers arrive, write intake/project_brief.yaml and provisional Quality Harness intent. Treat the first answers as the point where intake becomes a draft contract: capture resolved grill rounds in the brief, create compact candidate rows for quality/quality_harness.yaml through $cad-sim-quality-harness when high autonomy, prototype handoff, simulation/optimization, robotics/electromechanical, Garmin-style mount, canoe-study, or A+ review quality is in scope, and ask at most one Quality Harness targeted drilldown round when missing facts would change a required harness row, verifier, boundary, objective, or next real action. Use 1-3 pointed questions. If uncertainty can be bounded honestly, record physical_boundary, user_boundary, or stage_approval instead of asking indefinitely. New runs must write schema_version: 2, select an acceptance_profile, include every mandatory row from references/profile_contracts.yaml, and add no more than three run-specific risk rows. Preserve V1 harnesses when resuming an existing run. intake/open_questions.md exists only while waiting; after answers, resolved drilldown terms, project vocabulary, and decisions live in project_brief.yaml, not repo-level CONTEXT.md or ADRs. The grill-with-docs pattern is inspiration for drilling into the answer, not a literal artifact format for reset CAD runs. For every project that activated the tooling decision grill, also write the compact tooling_strategy block from the brief template. Set decision_status: answered; preserve the chosen scout, execution, agent-operability, simulation, and evidence-export policies; and require a ready-route receipt at tooling/tooling_scout.md. The receipt may honestly choose the default stack or no extra tooling, but a tool-sensitive run may not become ready with an unrecorded tooling/simulation decision.
7. Convert unresolved answers into named assumptions or needs_user blockers; do not hide them in prose. Set target_maturity, defaulting to concept_review_ready. Use build_use_review_ready when the user asks for raw-Codex-like first deliverables, instructions for what to buy or assemble, or stricter review before user inspection. Use prototype_handoff_review_ready when the user wants a first-prototype package: what to buy, what to fabricate/order/print, how to assemble and inspect it, how retention/fastening works, and what physical tests remain, without implying production readiness or validated safety/fit. Also set autonomous_review_depth: use raw_codex_parity when the user wants fewer later nudges or asks the system to keep improving before user review; use maturity_ladder when the user wants the Meta-Agent to self-promote as far as the evidence allows; otherwise use first_review. Add autonomy_after_grill when the answer changes behavior. Default to maximize_until_evidence_boundary when the user says to keep going, minimize nudges, or behave like a strong raw Codex session.
8. Add an autonomy_envelope only when it changes behavior. Keep it compact: autonomy bias, assumptions the Meta-Agent may make, clarification triggers, external-evidence stop points, allowed research/download/simulation/browser or computer-use capabilities, and a reviewer-owned maturity ladder. Treat the ladder as a soft review policy, not a coded checklist. A typical printable-hardware ladder is: concept_review_ready -> build_use_review_ready -> pre_print_review_ready -> prototype_handoff_review_ready. The pre-print tier means stronger CAD/build/use closure, print orientation and fit-check planning, hardware traceability, risk/non-claim clarity, and first bench-test guidance, not road-safety, strength, waterproofing, or fabrication proof. The prototype-handoff tier additionally asks for a compact BOM, smallest useful custom manufacturing outputs, visible retention/fastener closure, assembly/inspection/first-test steps, and removal or explanation of visible mystery geometry. For robotics, electromechanical, or software-connected projects, choose relevant labels such as system_integration_review_ready or prototype_plan_review_ready; do not force print-specific tiers when the project is not mainly printable. For autonomous_review_depth: raw_codex_parity, add one optional investigation tier when it would change reviewer behavior: mechanical_use_investigation_ready for hardware/mechanism work, system_integration_investigation_ready for robotics or electromechanical work, or domain_investigation_review_ready as a generic fallback. This tier asks for one bounded self-contained investigation before user review, not a proof, solver validation, or new artifact family. Add a compact analysis_intent and analysis_envelope when they would change behavior. This is a soft policy for useful checks before user review, not a hard simulation gate. Keep analysis_intent to mode, objective, optimization scope, and claim boundaries; do not create a new state machine. Use design_aid for most simple CAD projects. Use physically_reasonable_optimized_design when the user wants a real object improved against objectives: first make a coherent baseline, then run a bounded variant sweep or comparison without breaking physical/build/use constraints. Use simulation_optimization_study for projects such as hull, aero, thermal, robotics, or control studies where scenarios, metrics, calibration, and optimization are the core deliverable before final CAD. Allowed tiers may include paper_sanity, lookup_backed_estimate, lightweight_numeric_check, lightweight_simulation, local_gpu_simulation, solver_simulation, and commercial_simulator_run. Add optimization_loop only when optimization is the project or the user explicitly asks for bounded optimization. Default away from heavy solvers unless the user allows them and the model has meaningful loads, materials, and boundary conditions. For external simulator capability, record permission once as a compact policy: local scripts and small simulations may be allowed by default; web research, browser use, computer use, package installs, downloads, Warp or other GPU frameworks, open-source solver setup, and commercial simulator use each need a clear allowed/ask-first/forbidden value. Always ask before spending money, accepting licenses, entering credentials, uploading private files, installing large packages, running long/cloud/GPU jobs, or making safety/compliance/performance-proof claims. Require a fidelity note for any analysis or simulation: what it models, what it omits, key assumptions, real-world evidence needed, and claims it does not support. Keep autonomy_after_grill separate from the envelope as the user-facing operating contract. Use modes such as first_review, build_use, system_integration, pre_print, or maximize_until_evidence_boundary. Record allowed_self_decisions, ask_user_before, resume_after_user_answer, revision_budget, and analysis_budget, clarification_style, and phone_review_ok. This is the contract the review loop should use to decide whether to keep working, pause for a precise answer, or stop for user review. Record interaction_closure_targets when they change behavior: the build, install, use, service, software/control, calibration, and test touchpoints the reviewer should reason through as one user workflow. Record next_action_worthiness when high autonomy, A+ handoff, manufacturing/execution, simulation/optimization, or a user-facing primary handoff is in scope. Use the leading phrase Next-Action Worthiness: identify the likely next real user action, the user's cost or risk, what the packet must make clear before that action is worth taking, and which improvements remain allowed inside the current stage. Record stage_frontier when the user requests high autonomy, A+ handoff, manufacturing, simulation, optimization, raw-parity behavior, or "get as far as you can." Use the leading phrase Stage Frontier: the reviewer should be ambitious about the next useful stage, but the Meta-Agent may only work autonomously inside the currently approved stage. Derive current_stage from target_maturity; record approved_stage_scope, allowed_within_stage, ask_before_next_stage, and stage_entry_tooling_scout_policy: allowed_before_each_stage_when_useful. Typical allowed in-stage work is cheap checks, guide/evidence improvements, local tooling-scout recommendations, bounded local analysis, slicer preview, and CAD revisions needed to satisfy the current-stage rubric. Typical ask-first next stages are major redesign, broader optimization, heavy simulation/FEA/CFD, commercial or licensed tools, production-grade website work, physical testing, and broader validation. Print-time, support-material, sourcing, slicer preview, or evidence-embedding work is in-stage when it determines whether the same approved next action, such as printing or bench testing, is worth doing; treat it as a frontier only when it expands into a broader optimization or redesign stage.
9. Build a compact review_contract before the review_rubric. The contract is the project-specific reviewer memory and completion criterion: ready criteria, user complaint acceptance tests, resolved promises that must not regress, and likely user nudges to avoid. Keep it inside project_brief.yaml unless the run has a strong reason to split it out. New user complaints should become open_issues with a concrete acceptance test; they are not resolved until a later reviewer confirms current evidence. Build a review_rubric that catches the reminders the user would otherwise have to send later: missing major interface, invisible retention, unsupported fit/load/manufacturing claim, vague native traceability, or design output that validates as files but reads as a schematic. Include a visual-evidence check when the design will be reviewed visually: reviewable_product_concept requires actual render-mesh views, not only schematic dimension plots. When handoff_quality_bar.ready_threshold is A_plus_builder_handoff, set review_rubric.grading_mode: masters_engineering_submission, review_rubric.profile, target_points: 95, grade thresholds, route/grade separation policy, and 100 total points across the default categories from master_engineering_handoff_rubric.md plus the selected profile from rubric_profiles.md. Customize category weights, notes, and deduction examples to the project so the reviewer grades like a strict master-level engineering instructor, not a checklist completer. Include multiple project-specific deduction examples with rough point ranges for small, moderate, major, and severe issues; tell the reviewer to apply multiple deductions within a category when multiple independent defects are present. Do not encode hard caps for broad evidence types; use calibrated point deductions instead. Unless the user timeboxes the work, set minimum_a_plus_review_depth: 3 so A+ is not awarded from one permissive pass; a lower route can still stop earlier when the remaining gap is user measurement, physical testing, approval, purchase, credential, license, heavy install, or a large/long run. Keep the intake rubric as intent and initial calibration. The review loop's Active Rubric Compilation may later compile or refresh intake/active_review_rubric.yaml from this intent, current open issues, selected profile, route policy, option-space requirements, minimum viable alternative evidence expectations, and evidence-container requirements. That compiled rubric should be a contract-only object that records required evidence quality targets, not the current packet's pass/fail status. Once compiled, keep only compact pointers in project_brief.yaml.review_rubric; do not duplicate the full active rubric or Quality Harness rows in multiple places. When the harness is required, record project_brief.yaml.review_rubric.quality_harness.path: quality/quality_harness.yaml and let quality_harness.yaml remain the single source of truth for falsifiable rows. Record profile-specific A+ requirements. Examples: for physical_prototype, main mechanism confidence, procurement, manufacturing or printability, assembly, and first-test evidence must be strong; for simulation_optimization, objectives, scenarios, model fidelity, optimization variables, tradeoffs, and validation boundaries must be strong; for robotics_electromechanical, mechanical/electrical/software integration, calibration, diagnostics, and bench tests must agree. A polished page alone should not satisfy A+ for any profile. For high-autonomy A+ projects, record that disputed profile-critical choices need exploration confidence, not just explanation confidence: a compact alternative sketch, CAD-backed variant, staged comparison, calculation, scenario/variant result, or tooling-scout export should challenge the selected option when that work is self-contained. For hardware, accessory, mount, enclosure, bracket, fixture, or mechanism concepts, include a lightweight mechanical_feasibility_sanity check: actual views should show plausible non-colliding interface, load/retention, fastening/removal, and hand/tool-access paths. This is a first-review visual sanity check, not a solver, fit, safety, or manufacturing claim. For robotics, electromechanical, or software-connected hardware, include a system_integration_sanity check: mechanical layout, power/signal routing, sensors/actuators, firmware/software/control assumptions, calibration, and bench-test plan agree at a first-review level without claiming validation. For the robotics_electromechanical acceptance profile, require the hash-bound quality/system_interface_manifest.yaml defined in artifact_contract/README.md; local subsystem passes use AND semantics with every declared interface and cannot average away a mismatch. When target_maturity is build_use_review_ready or prototype_handoff_review_ready, include build/use closure checks for CAD-to-instruction consistency, purchased hardware traceability, assembly/tool access, print-orientation/load-path alignment, and validation assumptions matching real use. Include assembly/action grounding when instructions are part of the expected output: important physical actions should map to actual exported parts, visible features, hardware, access/clearance, and sequence state, especially split/separable parts, insertion/removal, routed straps, tightened fasteners, connector/service access, and custom manufacturing outputs. For prototype_handoff_review_ready, also include prototype handoff checks: no unexplained visible geometry, retention or fastening closure visible in CAD and instructions, compact BOM, custom manufactured outputs or ordering instructions, assembly/inspection/first-test steps, and explicit non-claims. If the user requested or allowed an interactive handoff surface, include a soft interactive_handoff_surface check: the surface must be grounded in CAD/system evidence, link or label exact manufacturing files/results, show meaningful step states, and make the user workflow reviewable without hidden inference. Include a critical_design_decision_evidence check for A+ handoff, optimization, simulation, and real-world-use projects: behavior-critical choices must have evidence appropriate to the claim, such as CAD-backed state, dimension check, calculation, lightweight simulation, external tool output, or explicit user/physical-test boundary. Clean prose or a surrogate diagram is not enough when canonical CAD/viewer evidence, manufacturing files, or the primary guide tell a different physical story. Include a design_decision_coverage check for the same projects: the packet must identify important non-obvious decisions before review. Missing decisions are defects even when the visible CAD and guide look polished. The reviewer should use cad-sim-reviewer-lenses/references/design_decision_evidence_closure.md and distinguish covered decisions, missing decisions, and under-evidenced decisions. Include a rubric deduction example for proxy visuals when the project's main behavior depends on physical motion, force, material, fluid, signal, or user action: proxy evidence can support review, but cannot earn full A+ behavior credit unless it makes the real behavior believable or is paired with a stronger test, analysis, simulation, or explicit physical boundary and first test plan. When target_maturity is prototype_handoff_review_ready, or when a primary handoff surface is requested, include an action_grounded_primary_handoff rubric item: the primary artifact must satisfy the shared action-grounded prototype handoff standard from cad-sim-reviewer-lenses/references/assembly_and_prototype_handoff.md, not merely link to details scattered elsewhere. If external capabilities are allowed, include a soft check that the Meta-Agent should use a bounded lookup, downloaded reference, lightweight simulator, or cad-sim-tooling-research-scout before user review when it would resolve a major self-contained uncertainty. Prefer the scout when the project is simulation-heavy, optimization-heavy, domain-unfamiliar, or tooling-sensitive. Include an analysis_or_simulation_opportunity check when the project has mechanics, actuation, power, sensing, controls, fixtures, or real-world use assumptions where a cheap calculation, lookup-backed estimate, numeric check, or lightweight simulation could catch a first-build mismatch. The check should route continue_autonomous only when the work is self-contained, allowed by the analysis envelope, and likely to reduce user steering; otherwise it should record not_useful, needs_user_measurement, or physical_test_required. For optimization-oriented projects, include an optimization_reasonableness check: the baseline must be physically coherent before optimization, the objectives and constraints must be explicit, design variables must be bounded, and selected variants must not win by breaking build/use, integration, safety-boundary, or solver-fidelity assumptions. Include an interaction_closure check for any project that must be built, installed, used, serviced, calibrated, controlled, or tested: the CAD or system design, bought/reused parts, tools, assembly steps, access paths, software/control assumptions, and validation plan should agree as one real workflow. Include a prototype_readiness_continuation check when the user wants high autonomy: before ready_for_user, the reviewer should ask whether one more cheap allowed step would make the packet more prototype-ready or prevent a likely later nudge, without demanding physical proof.
10. Set stop_rules.max_revisions, defaulting to 2, or 3 for autonomous_review_depth: raw_codex_parity unless the user asked for a light smoke or strict timebox. Define user_review_ready_means as no material rubric issue, open review-contract issue, regression, or high-value autonomous improvement remaining within the budget. For autonomous_review_depth: raw_codex_parity or maturity_ladder, include continue_until_reviewer_has_no_autonomous_feedback: true. When the autonomy envelope allows self-promotion, also include allow_maturity_promotion: true and a concise promotion_policy: promote only when the current tier is clean and the next tier can be improved from allowed inputs; ask the user when the next tier depends on a major preference, missing dimension, safety boundary, purchased part choice, or physical test. Include needs_user_is_resumable: true when the user wants minimal interruption: a clarification should pause with one precise question and resume the same loop after the answer, not require the user to restate the goal or say "continue."
11. Route to cad-sim-design-orchestrator only after the brief has the user's answers or explicit proceed-by-assumption permission. If the answer message also says to continue, route directly; otherwise stop at ready_for_design.

Brief Shape

Do not preload the expanded brief template. After the consolidated grill answers are recorded, read references/project_brief_template.md completely and use its Brief Shape section as the authoritative shape for intake/project_brief.yaml. Keep this core skill loaded during the grill; lazy-load the template only when it is time to synthesize the answered brief.

Routes

• awaiting_answers: intake/open_questions.md exists and CAD has not started.
• ready_for_design: project_brief.yaml is complete enough for CAD.
• needs_source_boundary_preflight: a source-blind or comparator-sensitive run needs a boundary lock before active authoring can inspect more context.
• needs_user: a missing answer would make the CAD misleading. Treat this as a resumable pause when needs_user_is_resumable or autonomy_after_grill.resume_after_user_answer is true: record one precise question, why it matters, the preferred answer format, resume_from, remaining revision or analysis budget, and the next action after the answer. After the answer arrives, update project_brief.yaml and resume without asking the user to restate the goal or say "continue."
• blocked: required evidence or files are unavailable.
• invalid_boundary: the requested source-blind boundary cannot be preserved.