#58 - L-bracket coverage check still failing (0.022 vs ≥0.80) — unresolved from issue #55 fixit cycle - Mark/pc2cad - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

2026-07-27 01:08:26 +00:00

Owner

Summary

One of the three original verification failures documented in issue #55 (L-bracket coverage: 0.021 vs ≥0.80) remains unresolved after the fixit cycle completed via card t_89f9cefd. The coverage is still at 0.022, well below the 0.80 threshold.

Kanban card: t_7c1cf77f (QA probe → reporter)
Original issue: #55
Fixit card: t_89f9cefd

Findings

The post-deploy probe (kanban card t_7c1cf77f) verified that the fixit card t_89f9cefd addressed two of the three original failures from issue #55:

✅ OCP circular-edge checker crash — fixed in render_compare.py (safe while ex.More() pattern)
✅ Premature-done lifecycle — _kanban_complete() calls removed from kilo-gsd.py

But the L-bracket coverage check still fails at 0.022, unchanged from the original 0.021 reported in issue #55.

Reproduction Steps

Check out the current state of pc2cad main (commit after fixit t_89f9cefd changes)
Run the kilo-gsd Verify gate on issue #53 (compose_body_with_features boolean cut)
Observe the L-bracket coverage output

Actual Behavior

L-bracket coverage: 0.022 (needs ≥0.80)

Expected Behavior

L-bracket coverage ≥ 0.80 — the reconstruction should capture the L-bracket shape (through-hole etc.) correctly, producing significantly more than ~7 faces.

Issue #53: Original compose_body_with_features boolean cut bug
Issue #55: Original document of three verification gate failures
t_01af428a: Kanban follow-up created to finish remaining pc2cad_reconstruct.py fixes

## Summary One of the three original verification failures documented in issue #55 (L-bracket coverage: 0.021 vs ≥0.80) remains unresolved after the fixit cycle completed via card t_89f9cefd. The coverage is still at 0.022, well below the 0.80 threshold. **Kanban card:** t_7c1cf77f (QA probe → reporter) **Original issue:** #55 **Fixit card:** t_89f9cefd ## Findings The post-deploy probe (kanban card t_7c1cf77f) verified that the fixit card t_89f9cefd addressed two of the three original failures from issue #55: - ✅ OCP circular-edge checker crash — fixed in render_compare.py (safe `while ex.More()` pattern) - ✅ Premature-done lifecycle — `_kanban_complete()` calls removed from kilo-gsd.py But the L-bracket coverage check **still fails** at 0.022, unchanged from the original 0.021 reported in issue #55. ## Reproduction Steps 1. Check out the current state of pc2cad main (commit after fixit t_89f9cefd changes) 2. Run the kilo-gsd Verify gate on issue #53 (compose_body_with_features boolean cut) 3. Observe the L-bracket coverage output ## Actual Behavior L-bracket coverage: **0.022** (needs ≥**0.80**) ## Expected Behavior L-bracket coverage ≥ 0.80 — the reconstruction should capture the L-bracket shape (through-hole etc.) correctly, producing significantly more than ~7 faces. ## Related - Issue #53: Original compose_body_with_features boolean cut bug - Issue #55: Original document of three verification gate failures - t_01af428a: Kanban follow-up created to finish remaining pc2cad_reconstruct.py fixes

Mark added the

bug

label

2026-07-27 01:08:26 +00:00

~~Mark referenced this issue 2026-07-27 01:08:42 +00:00~~

Fixit card t_89f9cefd completed with BdPolygon and BuildPart Plane() fixes as unstaged WIP only — working tree state not durable #59

Mark commented

2026-08-11 16:47:22 +00:00

Author

Owner

Bughunt finding (2026-08-11): reproduced the coverage failure on current main — it is a real reconstruction gap, not a metric artifact.

python pc2cad_cli.py samples/strategy_l_bracket.ply --out /tmp/b.step --seed 42 then tests/render_compare.py ... --tolerance 1.0 --min-coverage 0.80 gives coverage 0.105 (524/5000 within 1.0 mm) vs the 0.80 spec minimum. The STEP round-trips fine (1 solid, 55 faces, 306 edges) but the solid does not match the input cloud.

Root cause: the reconstructed body's z-extent is ~-59.5..+10.0 mm while the input cloud spans -50.5..+81.0 mm. The L-bracket's upper wall (z ≈ 10..80) is missing entirely from the reconstruction. In fit_primitives, the wall points are absorbed by a spurious sphere primitive (1831 inliers) instead of a plane, so the compose_body_with_features fallback (which only builds profiles from plane primitives) never gets a wall profile — the l_extrusion body covers only the base slab.

Two separate things feed this issue:

The plan-selection regression: the kilo-gsd Verify gate for #53 ran the pc2cad#47 plan's L-bracket checklist (no #53 plan existed) — that is the hermes-config#40 plan-fallback regression, now filed and xfail-guarded in this repo.
The actual reconstruction defect above (wall absorbed into a sphere) is real and still open here. A proper fix needs the primitive fitter to prefer a plane for the wall region (or the fallback to derive profiles from non-plane primitives), not a gate tweak.

No code change landed in this bughunt for the reconstruction itself — leaving that for a dedicated fix.

Bughunt finding (2026-08-11): reproduced the coverage failure on current main — it is a **real reconstruction gap**, not a metric artifact. `python pc2cad_cli.py samples/strategy_l_bracket.ply --out /tmp/b.step --seed 42` then `tests/render_compare.py ... --tolerance 1.0 --min-coverage 0.80` gives **coverage 0.105** (524/5000 within 1.0 mm) vs the 0.80 spec minimum. The STEP round-trips fine (1 solid, 55 faces, 306 edges) but the solid does not match the input cloud. Root cause: the reconstructed body's z-extent is ~-59.5..+10.0 mm while the input cloud spans -50.5..+81.0 mm. The L-bracket's upper wall (z ≈ 10..80) is **missing entirely** from the reconstruction. In `fit_primitives`, the wall points are absorbed by a spurious **sphere** primitive (1831 inliers) instead of a plane, so the `compose_body_with_features` fallback (which only builds profiles from plane primitives) never gets a wall profile — the `l_extrusion` body covers only the base slab. Two separate things feed this issue: 1. The plan-selection regression: the kilo-gsd Verify gate for #53 ran the pc2cad#47 plan's L-bracket checklist (no #53 plan existed) — that is the hermes-config#40 plan-fallback regression, now filed and xfail-guarded in this repo. 2. The actual reconstruction defect above (wall absorbed into a sphere) is real and still open here. A proper fix needs the primitive fitter to prefer a plane for the wall region (or the fallback to derive profiles from non-plane primitives), not a gate tweak. No code change landed in this bughunt for the reconstruction itself — leaving that for a dedicated fix.

Mark referenced this issue

2026-08-13 00:54:55 +00:00

Create and tune scan-to-CAD methodologies with progressively more complicated models #60

Mark added

triage-approved

and removed

bug

labels

2026-09-15 01:59:39 +00:00

Mark commented

2026-09-15 01:59:39 +00:00

Author

Owner

Triaged: L-bracket coverage still 0.022 vs ≥0.80 threshold post-#55. Needs re-fix; routes to fixit lane.

Mark commented

2026-09-15 02:01:42 +00:00

Author

Owner

launcher-failure: preflight — kanban card t_a23ed060 blocked before spawn because the in-tree gate (.gsd/gates/pre-dispatch.sh) reports the worktree dirty: M pc2cad.py. Per the launcher contract, .gsd/ preflight is not in the launcher's repair scope; the runner would burn cycles on a dirty baseline. Operator action: cd /home/b/Projects/pc2cad && git status to inspect the modification, commit or stash pc2cad.py as appropriate, then unblock t_a23ed060 to retry dispatch.

launcher-failure: preflight — kanban card t_a23ed060 blocked before spawn because the in-tree gate (.gsd/gates/pre-dispatch.sh) reports the worktree dirty: `M pc2cad.py`. Per the launcher contract, .gsd/ preflight is not in the launcher's repair scope; the runner would burn cycles on a dirty baseline. Operator action: `cd /home/b/Projects/pc2cad && git status` to inspect the modification, commit or stash `pc2cad.py` as appropriate, then unblock t_a23ed060 to retry dispatch.

Mark added the

blocked:preflight

label

2026-09-15 17:29:46 +00:00

Mark added the

in-progress

labels

2026-09-18 02:37:08 +00:00

Mark closed this issue

2026-09-18 04:42:28 +00:00

Mark referenced this issue from a commit

2026-09-18 04:42:28 +00:00