Repository navigation
For Sam and Hunter: remaining server uncertainty and validation limits #176
Description
Handoff after the manager closed source changes at #11 head 3baa338. These limits do not establish that the property proves every possible scan safe.
- Extend uncertainty validation to multiple corners between meter and battery. The final meter route bound is derived for its stated directions and standoff. The sampled property is not a proof over arbitrary wall chains.
- Check shared-corner perturbations as one coherent geometry change. Independently represented wall ends can change joins or gaps; make the admissible-world model explicit.
- Coverage observations remain fixed while the property perturbs geometry. Add tests for what an observation guarantees when walls, the meter and objects move within declared bounds.
- Investigate Shapely difference_prec numerical warnings. The independent deterministic run passed 380 tests with 1 expected failure, but emitted divide-by-zero and invalid-value warnings from test_more_space. No false result was reproduced from those warnings.
- Refresh the stale web: placement review page #15 sample web/src/samples/corner-not-walked/result.json with its owner. The limit-end repair changed the selected spot while retaining manual_review. Details and the narrower monotonicity statement are in server: narrow monotonicity properties and refresh the corner sample #150.
The manager directed that any newly verified false PASS after this head be added here with a minimal witness for Sam and Hunter, rather than reopening #11. No private rules, keys, real captures or dataset images belong in this public issue.
Activity
SamGu-NRX commentedon Sep 27, 2026
Additional reviewed limits at #11 head 3baa338, deferred under the manager's handoff decision. Sam and Hunter own the remaining policy decisions.
server/solver.py:883-885: route standoff subtracts the candidate wall's error, not the wall carrying that part of the route. Independently reproduced with an exact gas footprint 0.5 ft off a routed wall whose error is 1 ft. The nominal candidate passes; moving that wall 0.5 ft within its error exposes a crossing with unknown height and changes the route to UNSURE. Codex 4114814615.server/solver.py:542: span-only hazard geometry omits its supporting wall's error. Independently reproduced with a battery on an exact wall and gas equipment on a perpendicular wall with 0.5 ft error. Moving that wall's far endpoint within its error changes the same candidate's gas clearance from 3.037289 ft, PASS, to 2.950651 ft, FAIL. Codex 4115344688.server/scene.py:875: modeled outdoor reach omits meter error. The bounded reviewer reproduced an all-PASS candidate with meter error 2 ft and ground observed to 13 ft, although its pool coverage needs 13.833333 ft. A recorded pool beginning at depth 13.2 ft makes the same candidate UNSURE. This also matches final Opus finding 5. Codex 4115344676.server/solver.py:924-933: route coverage checks the base cable height, not its elevated detour. The bounded reviewer reproduced a 2 ft excursion around a box with wall coverage only 1.1 ft high, yet a full PASS. No second-obstacle example proving every alternative route impossible was tested. Codex 4115344679.server/rules.py:130-132: zero workspace width or depth validates, then the bounded probe produces NaN and strict JSON serialization fails. An HTTP 500 was not exercised. Reject these invalid rule configurations. Codex 4114814623.server/rules.py:279-290: a partial override retains demo auto-approval unless it overrides the policy too. A dummy public-rule probe confirms the behavior. Decide whether partial overrides must explicitly select a policy; inheritance alone does not prove an unauthorized decision. Greptile 4115050490.server/solver.py:894-897: unknown obstacle height leaves the reported route length as a lower bound without labelling it as such. The result remains UNSURE, not an approval. Greptile 4115050493.server/solver.py:1286-1315: measurement-span boundaries omit drift-root candidates. The bounded reviewer found a direct passing start at 5.03 ft while generated candidates contain no passing position. This misses a usable spot rather than approving an unsafe one. Codex 4115344684.server/solver.py:1867-1868: a wall shorter than the battery can reject with a route-length explanation while its sweep correctly names wall backing. Codex 4115344694.server/api.py:304-324: ZIP member metadata is parsed before any member-count guard. The bounded bot review did not stress memory. The separate final Opus review measured 121 MB extra RSS for an 18.8 MB archive; its 1.6 GB estimate at the local upload cap was extrapolated, not measured. Hosted request limits reduce exposure. Codex 4114814619, final Opus finding 10.Other deferred final Opus findings: workspace starts at the wall instead of the meter front,
solver.py:305; the fixed 0.05 ft collinearity tolerance contradicts the wall-error docstring,scene.py:544,563; the README span table omits inside-corner plan coverage,README.md:95-99; several scene errors echo whole wall IDs,scene.py:753,825,932,989; missing tests for three documented scene refusals,scene.py:841-854,1021-1026.These are limits at the reviewed head, not claims about the repair head still in progress. The caretaker ran only tiny public synthetic probes. No private configuration or large resource test was used by the caretaker.
SamGu-NRX commentedon Sep 27, 2026
Added from the goal's fresh Opus re-verification of #11 at 1d1e7e1 (manager, not fixed in #11):
N1 (major, not reachable from the current iOS app).
server/scene.py:265-276(view_polygon) treats a ground span that lies within a wall gap as a view into the passage behind it, out to itsout_ft. The side-passage fix therefore depends on how a client splits its ground spans. On ther_gap2layout (walls x in [-20,10] and [14,40]), one span along the walls leaves the passage unseen, so gas, AC and pool are UNSURE. The same view split at 10 and 14 ft, or into 0.5 ft cells, marks the passage seen 20 ft deep, and all three pass 1.65 ft from it. That's no looser than 3baa338, where the passage never counted. The iOS app sends no wall gaps today, but any client that does, such as a reconstruction pipeline, would hit it. A fix would decide "into the passage" from camera position and direction, not span boundaries.Also recorded there: at both caps (200 segments, 5000 keyframes, 780 KB) parse takes 7.9 s because
_check_orientationscales with keyframes × segments. That's bounded, but close to #13's 10 s hostile-input budget.