vibeflow-geometry

name	vibeflow-geometry
description	Use when generating, editing, validating, repairing, importing, exporting, or documenting VibeFlow geometry from 0-caseDict/caseDict, especially CadQuery parameterized CAD, STEP/STL organization, computational-domain construction, named faces/regions/interfaces, geometry manifests, and geometry-to-mesh handoff.

VibeFlow Geometry

This skill is responsible for turning caseDict.geometry into stable, repeatable, exportable, mesh-ready geometry artifacts. A geometry script is not an isolated CAD helper; it must serve downstream regions, interfaces, boundariesLoadsInitials, mesh, and post-processing sampling semantics.

When to Use

• CadQuery parametric CAD needs to be generated from geometry.parameters, geometry.entities, and caseMeta.units.
• Existing STEP / STL / BREP files need to be organized, checked, or re-exported.
• A computational domain, obstacle, internal passage, multi-region solid, interface surface, load/boundary entity, or moving component needs to be constructed.
• Named bodies, domains, features, sensors, regions, and interfaces need to be aligned with downstream mesh and solver backends.
• Geometry modeling fails and the root cause needs to be classified as missing parameters, Boolean failure, scale issue, non-manifold geometry, or export problem.

What to Read First

• caseMeta, intent, physicalProblem, geometry, materials, regions, interfaces, boundariesLoadsInitials, and mesh in 0-caseDict/caseDict
• Template structure: StandardCase/0-caseDict/caseDict
• CadQuery modeling conventions, export, and validation: references/cadquery-playbook.md

Inputs

• 0-caseDict/caseDict
• Existing geometry scripts or exported files under A-geo/
• User-provided CAD, sketches, images, paper parameters, or Ref/ materials

Outputs

• A-geo/geometry.py
• A-geo/*.step
• A-geo/*.stl
• A-geo/geometry_manifest.json or A-geo/geometry_validation.md
• Preview scenes/images, build logs, and necessary repair records
• A-geo/logs/cadquery_geometry_executor.log confirmed clean after Studio rebuild or direct runner execution
• Updates to 0-caseDict/caseDict when required

Path Selection

• parametricCAD + cadquery: Preferred by default. Suitable for dimension-driven geometry, paper cases, reproducible experiments, and geometry that needs rapid parameter changes.
• importedSTEP: Preserve CAD semantics first. Check scale, solids, face/body naming, and whether splitting or manifest export is needed.
• importedSTL: Focus on watertightness, normals, duplicate faces, patch splitting, and snappyHexMesh compatibility.
• blockMeshPrimitive: For regular topology or teaching cases, do not force CAD; define geometry directly for blockMeshDict.
• oversetComposite / multiRegion: Confirm regions, interfaces, and moving boundaries first instead of exporting only a single STL.

Workflow

1. Read caseDict.geometry, while also confirming geometry-entity naming requirements from physicalProblem, regions, interfaces, boundariesLoadsInitials.boundarySets, and mesh.meshSource.
2. Validate the coordinate system, units, main flow direction, gravity direction, computational domain, key parameters, and region semantics.
3. If key parameters are missing or a physical assumption would change the geometry, return to vibeflow-case-dict for follow-up questions.
4. Generate or organize the geometry script, keeping parameter names consistent with geometry.parameters and entity names consistent with geometry.entities.
5. Build named bodies / domains / features / sensors / regions / interfaces; avoid relying on fragile face indices.
6. Export stable artifacts and write them to geometry.artifacts.
7. Run lightweight validation: file existence, scale, bounding box, entity/region/interface/boundary-set coverage, and obvious non-manifold risks.
8. If validation fails, write to errors.entries, mark stage=geometry, and state whether the issue is blocking.

Rules

• Parameter names must match caseDict.geometry.parameters; do not introduce undocumented magic numbers inside scripts.
• CadQuery scripts should preferably include clear build_geometry(ctx) and export_geometry(ctx, objects) or equivalent entry points, but basic preview must also work for ordinary CadQuery scripts that define result, objects, call show_object(...), or leave top-level CadQuery objects.
• Use ctx.stage(name, object, color=..., alpha=...), show_object(...), or a returned dictionary for important named components so Studio's Geometry Preview tree can hide or show parts independently. A final boolean-unioned solid will normally appear as one object because feature history is not recoverable from the final BREP alone.
• Exported filenames must be stable and semantically clear, such as A-geo/exports/domain.step, A-geo/exports/body.stl, and A-geo/geometry_manifest.json.
• Stabilize boundary, region, and interface naming before pursuing complex modeling techniques.
• Do not mix solver settings such as residuals, time steps, or post-processing charts into geometry scripts.
• Automatic repair, feature suppression, and tolerance relaxation must be recorded in geometry, provenance.decisions, or errors.
• Any geometry simplification that changes physical meaning must be confirmed by the user or written to intent.primaryAssumptions / provenance.assumptions.

Validation

• The script can run repeatedly without depending on the current shell's incidental working directory.
• After editing A-geo/geometry.py, trigger Studio Rebuild/Auto Preview or run the geometry runner directly, then inspect A-geo/logs/cadquery_geometry_executor.log; there must be no traceback/error, and A-geo/preview/scene.json must contain at least one preview object or OCP payload.
• Exported files exist, are non-empty, and their paths are written back to geometry.artifacts.
• Key dimensions, bounding box, volume/area, geometry.parameters, and geometry.entities are consistent.
• geometry.entities covers the entities required by downstream regions, interfaces, and boundariesLoadsInitials.boundarySets.
• CAD/STL scale is consistent with geometry.scaleToMeters and caseMeta.units.length.
• The output is sufficient for vibeflow-mesh to select a mesher while preserving region, interface, and boundary-set naming.

Fallback Conditions

• If dimension meaning is unclear, constraints conflict, or physical assumptions affect the geometry: return to vibeflow-case-dict.
• If CadQuery, Python, or export tools are unavailable: hand off to vibeflow-toolchain.
• If geometry is stable but mesh size fields, boundary layers, or conversion fail: hand off to vibeflow-mesh.
• After usable geometry has been generated, update workflowState or related status records only if there is no blocking geometry error.