Cad sim complaint distiller

CAD Sim Complaint Distiller

Use this skill when a reset-experiment run produced frustration, failed to finish, left unclear handoff artifacts, or when long project threads need to be mined for the user's recurring expectations.

Goal

Turn raw complaint context into small improvements to skills, contracts, or viewer checks. Preserve the complaint's practical meaning without copying bulky old framework behavior back into the reset experiment.

Inputs

Useful inputs include:

• a user complaint or operator note;
• a rehearsal report;
• changed files from the run;
• intake/project_brief.yaml and review rounds, when present;
• viewer validation output;
• final assistant report from the failed or abandoned session.
• long project threads or thread summaries, especially recent complaints and reviewer misses.

Distillation Steps

1. Identify the moment where the workflow became confusing, false, too large, or blocked.
2. Classify the friction as one of: intake_gap, rubric_gap, review_loop_gap, artifact_contract, viewer_check, scope_boundary, or external_dependency.
3. Propose the smallest concrete change.
4. Apply edits only inside the reset experiment root when the fix is clear.
5. If the complaint is that the user had to repeat a requirement, first ask whether project_brief.yaml.review_contract should have preserved it as an acceptance test before changing the grill, broad rubric, or reviewer prompt. Repeated complaints should usually become open_issues or resolved_promises in the review contract so fresh reviewers check them without reading the transcript.
6. When the complaint involves multiple reviewer-ready bundles, prefer a handoff.json rule or viewer3d handoff check that names one canonical annotation_view before adding broader workflow machinery.
7. Leave larger workflow changes as a recommendation with a reason.
8. If a first-review handoff has only a render mesh, prefer adding native/model traceability guidance or an explicit render-only absence reason before broadening the artifact format.
9. If the complaint is about comparison replay evidence, prefer the viewer3d handoff --require-native-model gate so render-only bundles fail clearly instead of becoming weak comparison data.
10. If the complaint is that the reset output looks worse than a raw Codex result, classify it as rubric_gap or review_loop_gap unless the viewer render itself is broken. Add or tighten a visual-fidelity gate before adding solver, optimization, or old-framework machinery.
11. If the complaint is that the reviewer declared done too early, tighten the review completion criterion against project_brief.yaml.review_contract before adding another reviewer or hard gate. Prefer a concrete acceptance test plus autonomous-continuation criterion: ready_for_user should mean no material issue, no open or regressed review-contract issue, and no high-value self-contained improvement remains within the revision budget.
12. If the complaint is that CAD, bought parts, print orientation, assembly instructions, tool access, real use, or validation assumptions do not line up, classify it as intake_gap, rubric_gap, or review_loop_gap and tighten build_use_review_ready intake/rubric/reviewer closure before adding new artifacts.
13. If the complaint is that a manager stopped while a child role later produced artifacts, add or tighten the manager settle check before changing the CAD workflow itself.
14. If the complaint is that a comparator contaminated itself or overreached, add or tighten the comparator allowed-source preflight before changing the design/review loop.
15. If a comparator focuses on easy packet hygiene while the reset output still falls short of raw-Codex-like autonomous quality, classify the root issue as review_loop_gap or rubric_gap. Preserve packet hygiene as a secondary warning unless it changed the product-review outcome.

Thread Expectation Distillation

Use Thread Expectation Distillation when the user asks to review one or more long threads to understand what the reviewer, rubric, or Meta-Agent should have learned. This branch is for pattern extraction, not direct design review.

1. Scope the source set: thread ids, named projects, local run roots, date window, and any "focus on recent complaints" instruction.
2. Preserve chronology without letting old framework state override the current reset framework. Mark each expectation as current, historical, or superseded_by_framework_change when that distinction is visible.
3. Sample recent material first, then scan older material for repeated patterns. Do not treat a single early complaint as active unless it recurs, appears in the latest project state, or the user re-raised it.
4. Extract expectation patterns, not every complaint. Each pattern should name: user_expectation, missed_by_system, evidence_example, affected_skill, and candidate_contract_or_rubric_rule.
5. Separate product-specific facts from general review standards. For example, "rubber band hooks are implausible" is product-specific; "reviewer must challenge behavior-critical retention geometry against the actual motion path" is reusable.
6. If multiple subagents or chunks are used, assign each a bounded slice and require the same compact output shape. The manager integrates duplicates and resolves contradictions; subagents do not propose final framework edits in isolation.
7. Produce a short expectation_distillation summary with:
   • recurring_expectations;
   • recent_active_expectations;
   • historical_patterns_to_remember;
   • framework_gaps;
   • project_cleanup_actions;
   • skill_or_rubric_change_candidates.
8. Convert only stable, repeated, or high-cost misses into framework changes. Put one-off project feedback into the active review contract or active rubric for that project instead.
9. If the result would add a new skill, first check whether this skill, cad-sim-review-revise-loop, or cad-sim-reviewer-lenses can own the behavior with a tighter completion criterion or disclosed reference.

Guardrails

• Do not edit the old cad-sim project.
• Keep distillation write scopes explicit: either use a role-owned workspace under the run root or list the exact reset-local files the distiller may edit.
• Do not install or publish skills.
• Do not create solver, optimization, CI, or migration machinery.
• Do not make reviewer evidence stronger than the underlying artifacts support.
• Do not let "valid bundle", "native model present", or "source-blind boundary maintained" erase a visual-quality complaint. Those are process checks, not a design-quality pass.
• Do not apply raw-aware comparator findings directly to an active source-blind author. Convert them into future intake questions, rubric checks, or reviewer completion criteria.
• Do not erase the complaint by rephrasing it into a vague lesson; keep at least one specific example.
• If a manager created fallback artifacts because a child role was unavailable, preserve that label in the complaint summary, report, and state rather than treating the artifacts as normal delegated output.
• If the complaint is about a comparison replay, route child authoring failure to blocked with reason_code: blocked_meta_agent_authoring after one procedural nudge; do not propose manager CAD fallback as replay evidence. Preserve the manager settle record so late child artifacts do not get mistaken for a permanent blocker.
• Do not trust raw-aware comparator recommendations unless its allowed-source manifest and sources_inspected.md prove the comparison stayed in bounds.
• Do not let thread distillation become transcript replay. The output should be a compact expectation map and concrete contract/rubric candidates.
• Do not overfit a framework rule to one project's vocabulary. Rewrite the rule around the reusable behavior the reviewer should catch.

Output Standard

Report:

• complaint summary;
• root friction category;
• files changed, if any;
• checks run;
• remaining risk or open question;
• whether the old cad-sim project was modified.

For Thread Expectation Distillation, also report:

• source threads or summaries inspected;
• recency policy used;
• recurring expectations;
• recent active expectations;
• historical patterns retained only as background;
• recommended project-contract updates;
• recommended framework changes, if any.