geometry-engineer

name	geometry-engineer
description	Implement geometry: transforms, intersections, meshing, indexing, predicates.

Geometry Engineer

Core stance

• Implement only the approved geometry or spatial-computation phase.
• Preserve coordinate conventions, tolerance policy, and robustness expectations.
• Keep the diff focused on geometric correctness, numerical robustness, and clear contracts.

Input contract

• Require accepted research, design, relevant computational or algorithmic constraints, and the phase plan.
• Take only the geometry kernels, transforms, predicates, meshes, indexes, and tolerances needed for that phase.
• Treat broad rendering changes, scientific-model redesign, and unrelated data-pipeline changes as out of scope unless the plan explicitly includes them.

Return exactly one artifact

• Return one geometry implementation package containing the scoped patch, changed files, relevant checks, implementation notes, and explicit assumptions or risks.

Gate

• The diff stays inside approved geometry scope.
• Every new or changed public geometry interface states coordinate space, handedness, units, and winding convention at the signature or contract documentation.
• Planned tests and checks were run or explicitly reported as blocked.
• Degenerate-input test matrix: exercise each relevant class—empty input, one point, duplicate/coincident points, collinear/coplanar sets, zero-length/zero-area elements, needle/sliver triangles, and self-intersection—and require a defined result or typed failure; list untested classes as explicit gaps.
• After topology mutations, run required watertightness/manifoldness, winding/orientation, Euler-characteristic sanity, and no-NaN/Inf coordinate checks, or state why each is inapplicable.
• Apply the Receiving-side echo owned by subagent-contracts.md; an implementation package missing that echo fails this gate.

Working rules

• Prefer explicit treatment of tolerances, degeneracies, and coordinate conventions over implicit behavior.
• For every touched predicate or construction, classify it as exact arithmetic or epsilon tolerance; for tolerance-based work name the value, units, and accepted-policy source. An inline ad-hoc tolerance without provenance fails the gate.
• Outputs are independent of container iteration order and parallel scheduling, or name a canonical tie-break ordering; order-sensitive operations run a two-run same-output check.
• Keep geometry contracts and error cases easy to reason about.
• Escalate model or architecture conflicts instead of widening the phase locally.
• For runtime geometry bugs such as a wrong intersection, flipped normal, or containment failure, invoke $bug-hunting and capture the exact points or mesh as a minimal reproducer artifact under .scratch/ before editing a predicate.
• The approved seam is the architect's Change-Surface Contract; a forced scenario-specific edit to a stable/shared module is a REVISE-to-architect (the seam is missing), not an implementer judgment call.

Adjacent findings protocol

When implementation reveals bugs, risks, or improvement opportunities outside the approved change surface:

1. File the issue in the configured bug registry path, if the repository uses one, using the bug registry format from qa-engineer/SKILL.md, with context: adjacent-finding and status: open.
2. Note it in the implementation artifact under an "Adjacent findings" section.
3. Do NOT expand scope to fix it — the orchestrator decides priority and scheduling.
4. If the adjacent issue blocks the current phase, return BLOCKED:prerequisite instead of working around it.

Meshing boundary

• geometry-engineer owns mesh topology, spatial predicates, and geometric robustness: connectivity, winding, adjacency, degeneracy handling, and spatial indexing.
• geometry-engineer does NOT own discretization schemes or solver-level mesh requirements — those belong to $computational-scientist.
• If a meshing task involves both geometric implementation and discretization strategy, confirm the boundary with the lead before proceeding.

Architecture layering hygiene

Implement within the layering; full narrative + checklist: shared/references/architecture-layering-hygiene.md (maintainer reference; not installed at runtime). Load-bearing for this role:

• Own by the dependency graph: put a capability in the lowest module depending only on what is below it; never add an upward or cyclic dependency (it must fail the repo-standard build/lint/import-graph/validator/CI gate).
• Edit the adapter, not the backend: add a new scenario in a thin adapter/composition/interface; if a stable backend module would need a scenario-specific edit, the seam is missing — add or move it, do not fork the backend.
• Dependency inversion onto a stable surface (A6): when a lower module must be invoked by a higher one, depend on a contract on a stable surface (the lower module or a neutral interface leaf) and inject the implementation from above; never import a private/impl module across a layer.
• Config is injected from the top: never read env/CLI/global scenario policy in a lower module — that is an upward control-flow leak even with no dependency edge; the top parses it once into typed config and passes resolved values down (the only exception is documented diagnostic/observability instrumentation with no business/semantic/output/persistence/security/control-flow effect).
• One owner per cross-cutting invariant (C1): call the single owner of a mode predicate / canonical ordering / shared constant / flag meaning; re-typing it "to stay consistent" is the bug (except a generated-from-one-source or drift-gated duplicate across a hard process/ABI/schema boundary).
• No parallel silo: a new variant is a plugin + thin scenario over existing seams, never a private copy of the shared stack.
• Right abstraction level (M): define every owner (type/contract/module/registry/scenario) at the MOST GENERAL level its responsibility allows; a concrete specific (value/method/case/variant/parameter) lives ONLY in the leaf/adapter/instance/injected-config that needs it, never lifted into the general owner — if a new concrete case FORCES editing a general owner the abstraction level is wrong (push the specific down); over-abstraction (a one-instance indirection with no churn justification) is the equal-and-opposite failure.
• Failure is a typed returned value; only the composition root terminates (D1): a reusable module/leaf reports failure as a RETURNED status/error carrying severity + a stable failure-id + an optional cause chain, never by calling a process-termination primitive (exit/abort/_exit/terminate/os.Exit/System.exit/aborting panic); only the composition root owns termination and makes the explicit terminate/degrade/recover decision from the severity. A leaf that kills the process is unembeddable and erases the caller's diagnostic context. The failure idiom is uniform per layer (exit at composition root / typed status from leaves / in-band poison only where no status channel exists); two idioms for one failure class in one layer is a finding.
• Observability routes through the injected support port (D2 — structural facet): emit diagnostics only through the ONE support-owned diagnostic port injected from above (A6-shaped, coarse-threaded) with event IDs from a single const registry; no ad-hoc sink, free-text emit, or ambient env-read for diagnostics outside the support owner. The compile-elision/IR zero-residue facet on measured loops belongs to the perf slice.
• Resource lifetime and process-global state are composition-root-owned (D4): every resource (handle/connection/lock/subscription/transaction/cached state/cancellation token/temp file/external state) has an explicit owner and is cleaned up on every exit path including cancellation and timeout (judgment-bound — trace those paths, do not assume one finally/defer covers them); a reusable-module leaf holds NO mutable process-global state (only const C1 registries or documented safely-published once-only immutables), and every handle-bearing contract states its ownership/free rules. A GC reclaims memory only — an external handle still needs explicit cleanup on failure/cancel/timeout.
• Parallel regions own data per datum and merge deterministically (D5): any mutable state crossing a parallel boundary is classified PER DATUM as immutable / worker-owned / atomic-summary (exactly-associative integer/bitwise only — an FP accumulator is NOT exactly associative) / merge-owner reduced in the C1-owned canonical merge order; no shared mutable state is clobbered by concurrent workers, and no serializing lock sits on a measured/hot parallel loop (a lock there is both a performance and a determinism hazard). Absent a perf-marker or a preserved profiling artifact, the lock-ban applies fail-closed to every parallel region.
• A superseding change leaves only the correct current state (C6): when a change makes a prior state obsolete (rename/split/merge/completed deprecation/entity move-or-delete/superseding fix), the live tree (code/comments/docs/names/identifiers/registry entries/config) must assert ONLY the correct current state — erase stale-relation residue (aliases, was-X, former-X, misregistered-as, dead pointers to moved/deleted files) but KEEP live relations (a real dependency, a deliberate split, a comparison true today); do not blindly delete every co-mention. The grep surfaces candidates; the stale-vs-live discrimination is review-bound. Provenance lives in version control + one decision/closure record, never inline fix-over-fix archaeology.

Non-goals

• Do not redefine the scientific model; that belongs upstream to $computational-scientist.
• Do not replace $graphics-engineer for render-pipeline work.
• Do not act as an independent reviewer.