[19] RC detail CAD constructibility review

[Batuis]

POC / IMPLEMENTATION PHASE — Stabileo producer complete, CAD consumer not started

Still a draft. Do not review or merge. The Stabileo half of the POC is now real production
code with real gates; the text-to-cad consumer (STEP/GLB, the independent cross-check, the review
artifact) has not been started.

Builds directly on PR15–PR18

Ancestor	Head	Verified
PR15 / #78	7d0ab24ef937cd0d7e5f78808d806adcabdab80c	ancestor ✓
PR16 / #79	b13c81ce843e5fe5ca14619a8f2f1b441df22c8f	ancestor ✓
PR17 / #80	86b8b3acea2d2630e48e05e776a1e95c04c6a50c	ancestor ✓
PR18 / #84	d19588ef3ecd21b4bc1bd8d054fdbaca961ed040	ancestor ✓ (base)

Not based on a QA branch. No solver / Rust / Cargo / WASM changes.

---

What this branch now produces

A production Foundations → Export CAD handoff action that turns a really-detailed footing into
a versioned, deterministic RcCadHandoffV1 manifest.

The subject is a connection, and it says so

Footing column-transfer cage — column dowels and starter ties connecting the footing to the
supporting column. Footing mat geometry is not included.

This is not complete footing reinforcement, and the manifest is built so it cannot be read as
such. assembly.kind = footingTransferCage, assembly.completeness = partialConnectionOnly, and
FOOTING_MAT_GEOMETRY_NOT_MODELED is a declared unsupported condition with a stable code.
Semantic validation refuses a document that claims completeFootingReinforcement while that
condition is present — the enum member exists so the refusal is a real check rather than a vacuous
one, and it equally refuses a transfer cage that omits the condition.

Nothing is invented

Datum	Value	Where it comes from
Footing pad	2,00 × 2,00 × 0,50 m, base z = −1,20 m	Footing.B/.L/.thickness/.foundingElevation
Footing top	z = −0,700 m	foundingElevation + thickness — the same expression run-footing-design.ts:596 hands the dowel generator as footingTopZ
Column footprint	0,40 × 0,40 m	section b/h of element 1, read exactly as collectFootingColumns reads it
Column stub	z = −0,700 → +0,447263 m	footing top up to the top of the production cage's steel, clamped to the column top
Interface	planar rect, z = −0,700 m, 0,40 × 0,40 m	the contact between the two solids
Cover	0,050 m	Footing.cover. 50 mm is never hard-coded anywhere

No generic column size. No arbitrary stub height. No invented anchor bolts, hooks, tolerances, BIM
semantics or fabrication approval.

Two derivations that had a wrong answer available

The stub top is a surface extent, not a centreline extent. Reading the maximum segment endpoint
z gives 0,4423 m — and then the top starter tie protrudes through the concrete by its own radius.
Two corrections were needed and only the first is obvious: grow by d/2, and measure on the
arc-aware production sampler (samplePath at COLLISION_CHORD_TOLERANCE = 0,5 mm), which finds
a true arc extreme the endpoints miss. Endpoint arithmetic would have understated the stub by ~2 mm
and left steel outside the concrete — the same class of error the stored arc centre exists to
prevent.

The stub's upper face is a truncation, not a surface. It carries truncatedFaces: ['top'] and
the cover requirement sets excludeTruncatedFaces. A cut plane admits no cover measurement.

A real discontinuity, surfaced rather than smoothed

Element 1's base node sits at z = 0, which is 0,700 m above the footing top. The analysis
model's column does not reach its own footing. The stub is taken from the footing top anyway,
because that is where the production dowels and starter ties actually are, and the gap is exported
as COLUMN_ELEMENT_BASE_ABOVE_FOOTING_TOP with all three numbers. No concrete is invented to close
it.

The interface is not an exposed face

The footing top beneath the column is an intentional concrete-to-concrete contact. A dowel crossing
it is the detail working. It is emitted explicitly, marked exposure: 'internal', listed in the
cover requirement's excludeInterfaceIds, and carries the crossing bars as
intentionalBarPassage with §16.3.4. A consumer has three independent reasons not to read a
penetration as a breach, and a test asserts no cover or containment finding is ever raised against
a crossing bar.

Per-check authority — and the field that makes it enforceable

Check	Authority	Status	Consumer policy
barCollision	stabileo	EVALUATED — 12 findings	MAY_CROSS_CHECK
barClearSpacing	stabileo	EVALUATED — 0 findings	MAY_CROSS_CHECK
concreteCover (footing)	none	NOT_EVALUATED	MAY_OBSERVE_NOT_COMPARABLE
concreteCover (column stub)	none	NOT_EVALUATED	OUT_OF_SCOPE
reinforcementContainment	none	NOT_EVALUATED	MAY_OBSERVE_NOT_COMPARABLE

consumerObservationPolicy is new and it is what turns the 2-C decision into something checkable.
The distinction between its members is the whole point: MAY_OBSERVE_NOT_COMPARABLE permits a
measurement and forbids presenting it as a verdict; OUT_OF_SCOPE forbids the measurement itself.
Collapsing the two would let a consumer report an unevaluated property as passing. Cover is two
checks scoped to two bodies, so the stub cannot inherit the footing's status by omission.

barClearSpacing is EVALUATED with zero findings, and that is a result rather than an
absence: 78 pairs were evaluated and every reported one was a prohibited overlap, judged by rule 1
of the classifier before any spacing clause applied.

The twelve conflicts are real, and they are exported

The production assembly reaches COORDINATED with 12 prohibitedOverlap conflicts and
constructibility CONFLICTED: all eight dowel hooks turn toward the column centre and interfere at
the bottom of the footing. A genuine finding about this fixture's geometry, exported as twelve
findings carrying Stabileo's own pairClass — not smoothed into a pass, not hidden behind a
summary boolean.

Clear spacing: two shapes that are not interchangeable

classifyPair takes surfaceClearance and the tangents at closest approach, so it is
geometry-dependent. Re-running it in the exporter without the collision detector's data would
produce a different pairClass than production — exactly the divergence that makes a second
implementation worse than none. So the manifest carries:

• the code-derived rule per role pair, from the exported minClearSpacingFor with its clause
  refs (column Ø16 → 40 mm, absolute floor; two beam-rule pairs → 26,67 mm, aggregate term);
• the per-pair verdict for the twelve pairs Stabileo reported, with its real pairClass.

Pairs Stabileo did not report get no per-pair entry. Stated as a limitation, not filled in.

---

Cover remains deferred

Stabileo exports the cover placement intent it owns and reports containment as NOT_EVALUATED
with a mandatory reason, because checkCover has zero production callers — for any element type.
CAD may measure achieved cover as an independent geometric observation and may never turn
NOT_EVALUATED into PASS. Generalized authoritative cover validation stays in
docs/handoffs/deferred-cover-validation-pr20.md. No production behaviour changed outside the
new export.

---

Validation, in two layers

Schema — the shipped JSON Schema, checked by a validator restricted to the keywords that schema
uses. A hand-written validator's real risk is not a wrong rejection but silent
under-validation, so assertSupportedSchema walks the schema first and throws on any keyword it
does not implement. A schema that grows past the validator fails loudly instead of checking less
than it claims. No new dependency in the browser bundle.

Semantic — where the honesty lives, since a document can be perfectly shaped and still say
something false. 36 rules: unique ids; resolving references; valid interface participants; an
interface plane that must actually be where the two solids meet; positive dimensions and diameters;
finite coordinates; an arc that drops its centre must declare the approximation; no footing cover
requirement on the stub; no cover requirement that fails to exclude the internal contact; no
containment verdict at all; no cross-check invitation without a verdict; every body needs its own
cover check. It lives in a module free of JSON imports so the browser journey can run it against a
downloaded file.

Where the exporter refuses rather than guessing

NO_COLUMN_REFERENCE · FOOTING_NOT_DIMENSIONED · FOOTING_ROTATION_NOT_RESOLVED ·
FOOTING_ECCENTRICITY_NOT_RESOLVED · PEDESTAL_NOT_SUPPORTED · NO_TRANSFER_CAGE ·
NO_COLUMN_DOWELS · UNCLASSIFIED_CAGE_BAR · NO_ASSEMBLY · STALE_ASSEMBLY ·
INVALID_MANIFEST

The eccentricity refusal is the one worth reading. Footing.eccentricityB/L is documented as the
offset of the footing centroid from the node, while run-footing-design uses node + eccentricity
as the column centre. At zero the two coincide and nothing is ambiguous. At a non-zero value
they are different places, and choosing one would invent where the column stands.

Every refusal is shown verbatim in the panel, in EN and ES. No disabled button without an
explanation.

---

The artifact

Path	web/src/lib/export/__fixtures__/rc-footing-cad-poc.handoff.json
Downloaded as	rc-cad-handoff-Z1-det3-dem2.json
Size	88 101 bytes
SHA-256	795e9de26f2eb8ce8d51f2ac7130336702fc534588f390071e3bd40bc03aa0e7
Schema	RcCadHandoffV1, schemaVersion 1
Source fixture SHA-256	15ce4e150919bf8f91ef1e3fae36dcde584b770fea45861465742654153e3e79

Committed as the shared contract sample (Decision 2A), in its own test file so its revision is the
one a first export actually reaches rather than whatever a suite of earlier cases left a
monotonic counter at.

Contents: 8 column dowels Ø16 · 6 starter ties Ø6 · 14 bars · 2 marks (F1 ×6, F2 ×8) · 90
segments including 38 arcs, all 38 with exact centres and none approximated · 2 concrete bodies
· 1 interface · 12 collision findings · 5 checks · 3 unsupported conditions · 4 assumptions.

The filename carries identity and revisions and no timestamp: a timestamp makes two identical
exports look different and a stale one look fresh.

Fixture change

The committed .ded is now saved as the PRO project it is — analysisMode moves 3d → pro.
The old value produced a file that, reopened, landed the user in Básico where the footing they
created is neither visible nor reachable; that was an artifact of the generator test's default, not
a decision. The model snapshot is byte-identical; only the saved mode and the serializer's
timestamp changed. This is what lets the browser journey open a real committed project through the
production file input instead of a test-only load hook.

---

Tests

105 unit test cases (260 assertions) across four suites, plus eight browser journeys. Every one starts from the
committed .ded, restores it through deserializeProject → modelStore.restore, solves with the
real WASM solver, and runs the production design and detailing commands. Nothing is
injected — not the assembly, not the cage, not the manifest.

• rc-cad-handoff-manifest.test.ts (47) — component extraction, stub derivation, interface geometry,
  transfer-cage classification, exact arcs, ID resolution, cover scoping, containment
  NOT_EVALUATED, column cover not evaluated, interface passage never a failure, collision
  preservation pair-for-pair against the assembly, determinism, fixture reconciliation
• rc-cad-handoff-validation.test.ts (43) — 43 rejections, each mutating exactly one thing on the real
  manifest, including the validator's own refusal to under-enforce a schema
• rc-cad-handoff-golden.test.ts (3) — byte-exact golden reproduction
• rc-cad-export-prerequisites.test.ts (12) — every refusal, including a stale assembly after a real
  demand-revision bump
• e2e/rc-cad-handoff.spec.ts (8) — the project is opened through the toolbar's file picker, the
  cage is generated by the panel's own button, and the manifest is downloaded by the panel's own
  export button. The downloaded bytes are then re-validated against the committed schema file. EN
  and ES, including a check that no exported sentence is a bare i18n key.

Gates, all green before this push

Gate	Result
npm run typecheck	490 / 490 baseline, no new errors
npm run test (unit)	4664 passed, 12 skipped, 228 files
npm run test (build)	5 passed
npm run build	✓
npx playwright test	131 passed, 4 skipped

---

Not started

• text-to-cad consumer: STEP/GLB generation, the independent OCCT cross-check, cad-review.json
• the invalid/mutated fixture for the injected-defect demo
• the 0,5 mm agreement band and cross-check-disagreement as an issue kind
• Viewer linking (Decision 4B)

QA note

http://127.0.0.1:4000/ is still serving the previous green QA head db311d674
(qa/main-plus-pr19-cad) and does not contain this commit. Main, PR15 and PR16 are being
updated in parallel, so no propagation or QA rebuild was attempted. QA is knowingly stale with
respect to this branch.

[Batuis]

Architecture decision brief added — awaiting your decisions

docs/poc/rc-footing-cad-architecture-decisions.md (b1c795c5). The six choices are now a
decision packet with measured evidence rather than a summary. Still POC / DESIGN PHASE — NOT
READY FOR REVIEW; no production code.

Recommendations, one line each

#	Decision	Recommendation
1	Handoff mechanism	Versioned JSON + CLI. Only option whose licence boundary is unarguable and whose artifacts are the audit trail. Its CLI becomes the local-service handler later, unchanged
2	Manifest ownership	Stabileo-owned RcCadHandoffV1, with a JSON Schema as the shared artifact and generated bindings both sides. Stabileo owns structural meaning; CAD reads numbers
3	Solid generation	Split — Stabileo exports concrete boundaries + full BarPath intent; cadpy realises named solids. Preserves arc fidelity by construction
4	Viewer	External for the first POC, linked immediately after. Embedded is the right end state but the upstream viewer surface is churning
5	Collision authority	Stabileo authoritative + independent OCCT cross-check, agreement band stated at 0.5 mm, disagreement as its own issue kind
6	Review return path	cad-review.json for the POC, persisted import for production. The POC file is the production import payload

Bundle B — clash-aware vertical slice — is recommended and deliberately not chosen.

Why Decision 5 got the most space

engine/detailing/collision.ts is not a stub. Uniform spatial hash sized
max(0.05, 2r + requiredClear + placement + 0.02); exact narrow phase at EPS = 1e-12; arcs
sampled at COLLISION_CHORD_TOLERANCE = 0.0005 m using the stored centre; placement
tolerance zero by default because a hardcoded 10 mm was once silently deducted from every
measured clearance; and the documented sagitta errors — 5.9 mm on a Ø8 90° corner, 12.3 mm
on a 135° hook, both larger than the bars being checked.

So moving collision authority to CAD is rejected: it would replace a regulation-aware, arc-exact,
tolerance-audited checker with a generic one, and porting the CIRSOC classification rules would mean
putting AGPL-derived logic into an MIT repository. The cross-check is what adds assurance —
OCCT BRepExtrema_DistShapeShape on exact geometry is genuinely independent of Stabileo's sampled
segments, which is what makes agreement meaningful instead of a re-run.

"Clash-aware RC detail" is achieved under both 5A and 5B; only 5B adds independent
confirmation, and only 5C puts the design at risk.

Two gaps, and one thing I did not assume

Missing: a read-only required-clear-spacing accessor (requiredClearFor arrives as a
caller-supplied callback, so the numbers are never materialised) and a STEP/GLB writer (Stabileo
emits DXF R12, 2D).

Not verified, flagged rather than glossed: SectionPrism models a prismatic member, and a
footing pad is not that shape. Whether PR18's footing path is covered by that containment check must
be confirmed before fixtures are frozen. If footings are not covered, that materially strengthens
the case for the CAD-side containment cross-check.

Confirmed

Bundle B needs neither PR #22 nor Netgen/NGSolve — the cross-check needs the same OCCT that
cadpy's STEP support already uses, not a mesher. The AGPL/MIT boundary holds as long as Stabileo
exports numbers rather than rules. The first footing needs only production PR18 data — all
27 datums trace to an existing owner, so no duplicate footing or reinforcement model.

No production code, no CAD artifacts, no new dependencies, no QA or server changes.

[Batuis]

Bundle B selected — clash-aware vertical slice

The user has approved Bundle B with all six recommendations from
docs/poc/rc-footing-cad-architecture-decisions.md:

1. Versioned JSON + CLI handoff.
2. Stabileo owns RcCadHandoffV1 and the engineering meaning of its fields.
3. Stabileo exports intent and exact bar paths; cadpy/text-to-cad realises STEP/GLB solids.
4. External viewer first, linked workflow next — no embedded viewer in this slice.
5. Stabileo remains authoritative for regulatory collision/clearance classification; OCCT
   performs an independent exact-geometry cross-check with the documented 0.5 mm agreement band.
6. cad-review.json is the POC return artifact, deliberately shaped as the future
   persisted-import payload.

Seismic is not revived. Its surviving knowledge stays in
docs/handoffs/deferred-seismic-103-2026-07-29.md.

---

Foundation questions resolved before implementation — 9df181ba

docs/poc/rc-footing-foundation-findings.md. One shrinks, one opens a decision.

1. Required clear spacing — resolved, and my earlier brief was too pessimistic

The brief said a read-only accessor must be added. Tracing requiredClearFor to its source shows
the rule is already exported: classifyPair (engine/detailing/classify.ts:266) returns
PairClassification { pairClass, requiredClear, reportable, refs: ClauseRef[], labelKey }, and
minClearSpacingFor / minClearBetweenLayers are public in codes/cirsoc201/spacing.ts.
Three production callers already use them; the floor coordinator builds requiredClearFor as a
one-line closure over minClearSpacingFor, so the callback is an injection seam, not a hiding
place.

Better than an accessor: classifyPair also yields the clause reference, the reportable
flag, and an i18n label key — so the manifest gets real provenance, the CAD side learns which
shortfalls Stabileo deliberately does not report, and EN/ES text reuses PR16 messages.
Only serialisation is new. No rule code, no new engine accessor.

2. Footing containment — not covered, and neither is anything else

checkCover has 7 references in web/src: its own definition and 6 call sites in
bar-geometry.test.ts. Zero production callers. It is implemented and unit-tested but unwired —
for footings, beams and columns alike. So Stabileo has no post-hoc geometric containment verdict
in production at all; the gap is broader than footings.

Cover is achieved by construction, as a placement input:
available = footingThickness - footingCover - 0.05, inset = panel.cover + d/2 + …. Bars are
placed at the right cover arithmetically; nothing afterwards measures whether the realised geometry
sits inside the concrete.

That leaves RcCadHandoffV1's required stabileoVerdict undefined for containment — a
material decision, with three options set out in the findings doc:

	Scope	Value	Risk
2-A declare containment unsupported	smallest, exporter only	honest; CAD adds a capability Stabileo lacks	a CAD bug looks like a design defect
2-B wire checkCover into the footing path	materially larger — changes product behaviour; needs a pad abstraction, SectionPrism is prismatic	best long-term; a real internal check	may start failing mature fixtures; outside the approved slice
2-C export cover as placement intent, CAD measures achieved cover	exporter only	strongest cross-check — audits the cover-by-construction assumption nothing currently verifies	will surface genuine discrepancies needing triage

Recommendation: 2-C, with 2-A's honesty framing, and 2-B deferred to its own PR.
Stopped before this choice — the exporter's stabileoVerdict shape and
unsupportedConditions[] wording depend on it.

Everything else is unblocked: envelope, identity, revisions, units/frame, concrete geometry from the
persisted Footing/Pedestal (B, L, thickness, rotationDeg, eccentricities,
cover, material ids — no second footing model needed), bars with exact arc centres, marks,
roles, layerId, ownerElementIds, required cover, required clear spacing + clause refs, and the
already-wired collision verdict.

Still draft, 0 reviewers. No production code, no solver changes, no new dependencies.

[Batuis]

Containment decision recorded: 2-C with 2-A's honesty — 6c5af5ce

2-B is not implemented in PR19. Generalized authoritative cover validation is deferred to a
probable PR20, with its own tracked handoff: docs/handoffs/deferred-cover-validation-pr20.md.

Rule	Implemented as
Stabileo exports the cover requirement it genuinely owns	Footing.cover / footingCover, value preserved — 50 mm never hard-coded
Footing containment reported NOT_EVALUATED	authority: "none", with a required notEvaluatedReason naming the cause: checkCover has zero production callers
CAD measures achieved cover independently	as a geometric observation
A CAD measurement is not a regulatory verdict or certificate	review artifact must label it so
CAD may never turn NOT_EVALUATED into PASS	distinct NOT_COMPARABLE state

Schema landed — web/src/lib/export/rc-cad-handoff.schema.json

Cover is not a global scalar. requirements.cover is a list; each entry keeps
requirementId, elementId, elementType, optional surface (face/region/note),
optional appliesToBarIds, distance, unit, category and provenance as separate
concepts. An absent surface means Stabileo does not model a per-surface distinction — a stated
limitation, not a wildcard. face is an open string, not a closed enum, because the production
model has no face roles yet and fixing an enum now would encode guesses. category admits only
placementInput | codeDerived | userSpecified — the three the model actually distinguishes.

Results are per check, never one aggregate boolean. Each check carries its own checkId,
checkKind (barCollision | barClearSpacing | concreteCover | reinforcementContainment),
authority, evaluationStatus, requirementIds, scope and findings. A JSON Schema
if/then makes notEvaluatedReason required when not evaluated, so a consumer cannot quietly
omit the reason.

The PR20 migration needs no redesign — only authority, evaluationStatus and the presence of
findings change; requirementId keys stay stable.

Also: BarSegment keeps the arc centre as the exact representation plus an explicit
arcApproximated flag, and clearSpacingRequirement carries reportable so a consumer respects
the pair classes Stabileo intentionally suppresses.

Gates on QA 77705cb7d

typecheck 490/490 no new · unit 4560 passed / 12 skipped · build PASS · production build
green · Playwright 123 passed / 4 skipped · WASM rebuilt, 0 tracked. Serving
http://127.0.0.1:4000/.

Blocked — one decision needed

Implementation of the serialiser is paused on a listed stop-condition (unavailable footing
geometry): no committed fixture JSON contains a footing. grep -l '"footings"' across all 56
fixtures returns nothing, and the existing run-footing-design.test.ts builds its footing from the
newFooting() factory with synthetic reactions. Since the acceptance criteria require the footing to
come through the production model path with no test-only shadow footing, how the demonstration
footing is sourced is a material choice. Options and a recommendation are in the report.

Still draft, 0 reviewers. Schema only — no serialiser, no exporter wiring, no cover UI.

[Batuis]

Checkpoint: canonical F-2 footing fixture — 42b2ac81

The manifest producer's data foundation is in place and green. The exporter itself is not yet
written; see the limitation note at the end.

Fixture

web/src/lib/export/__fixtures__/rc-footing-cad-poc.ded.json
· 11,752 bytes · sha256 50ded28d0fd701159c2b72d7e96a4210c0ecb5f7280753edb1ac66ac04cf5ce0

Built only through production actions:

modelStore.loadExample('rc-design-qa-8')   // production example loader
modelStore.addSoilProfile / updateSoilProfile
modelStore.addFooting / updateFooting      // what FoundationsPanel.svelte calls
serializeProject()                         // production .ded writer

read back through deserializeProject() → modelStore.restore() — the only path that actually
reaches snapshot restoration. templates/fixtures/*.json is replayed by loadFixture and never
restores a snapshot, which is why the canonical fixture is a .ded DedalFile.

rc-design-qa-8.json is not modified. The founding node is selected dynamically as the
lowest fully-fixed support, because loadFixture remaps ids and hard-coding node 1 would silently
drift.

Contents: 8 nodes, 8 elements, 4 fixed3d supports, 1 footing — Z1, kind isolated,
2.0 × 2.0 × 0.5 m, cover 0.05 m carried on the model, founding elevation −1.2 m, soil profile
with allowable bearing 250 kPa and provenance recorded as assumed. All illustrative in-domain
values, not project-derived and not regulatory. Nothing downstream hard-codes 50 mm.

Placement — a gate caught me

It lives under export/__fixtures__, not templates/fixtures. fixture-validation.test.ts
requires everything in the template registry to be registered in fixture-index.ts, and a
DedalFile is not a JSONModel that loadExample could load. My first placement failed that gate;
the gate was right and the file moved.

Tests — 4, all green

Production build (with optional regeneration behind WRITE_FIXTURE=1); restoration proving the
footing, its node, its surviving fixed support and its soil-profile reference; an assertion that
the snapshot persists no derived detailing state, so an assembly can never be seeded instead of
recomputed; and a regeneration check comparing model content with the production save timestamp
excluded — nothing was patched to force a fixed timestamp.

Gates

focused 287 passed · full unit 4564 passed / 12 skipped · build project PASS · typecheck
490/490 no new · production build green · Playwright 123 passed / 4 skipped.

QA c2ac5ab4e: all six heads reachable, 0 duplicate patch-ids, 0 engine/Cargo diff, WASM
untracked, serving http://127.0.0.1:4000/.

Not yet done

The exporter, its semantic validation, the Foundations export action with EN/ES strings, the
remaining ~11 tests, and all text-to-cad work. Stopped at this clean green checkpoint rather than
half-writing a ~400-line exporter. No decision needed — the next pass has a concrete restored
footing to export from.

Still draft, 0 reviewers.