Rename: _stub_estimate -> _estimate_physics (it's a real deterministic
physics engine now, not a stub) and estimation_method "stub" ->
"physics_calc" to match the value pass 3 already used, for consistency
between the raw-estimate and scored-metric tables. Also skip the
cargo_capacity/cargo_capacity_kg arithmetic entirely in
_raw_physics_from_masses for domains that score neither and don't need
it as cost_efficiency's $/(kg·m) denominator either -- real but modest
savings on the ~11,000-eval-per-combo optimizer hot path (a separate
log1p-caching attempt was tried and reverted: it measured SLOWER, not
faster -- the extra dict lookup cost more than the two math.log1p calls
it avoided).
Six bugs found by a full-codebase review agent, verified individually:
- pipeline.py: LLM rate-limit retry called review_plausibility() with
domain.metric_bounds instead of domain, crashing the whole pipeline
run on any retry (every provider immediately accesses domain.name/
.metric_bounds on that arg).
- _explore_result.html: mass-bar width divided by total_mass with no
zero guard; biological/ambient actuators can legitimately have 0 mass
floors, so an all-zero slider combination 500'd the explore endpoint.
- routes/pipeline.py: if init_db/Repository(conn) raised before
repo/conn were assigned, the except/finally handlers referencing them
raised UnboundLocalError, silently swallowed by bare except/pass --
a bad PHYSCOM_DB path left a run stuck at status=pending forever with
no diagnostic. conn/repo now init to None and are guarded before use;
the truly-unreachable-DB case at least logs server-side now.
- repository.py: update_combination_status's downgrade guard protected
scored/llm_reviewed/*_fail but not a write of "valid" -- pass 1
re-running for a different domain against an already-reviewed combo
silently reverted its status back to "valid", erasing the review
signal. Verified directly: marked a combo reviewed, re-ran pass 1,
status held.
- pipeline.py: cost_efficiency's operating-cost term fell back to
ground rolling-resistance physics (effective_k_med or ...["ground"])
for media with no resistance model (space), instead of skipping the
term the way range_fuel explicitly does two lines above. Every scored
interplanetary_travel combo got a cost_efficiency computed from
ground physics applied to a spacecraft. Now reports amortized/upfront
cost only for such media -- an honest partial answer.
- pipeline.py: `if min_accel and specific_thrust:` used truthiness
instead of `is not None` -- dep_value() legitimately returns 0.0 for
a declared floor of zero (Spaceship declares min_effective_accel=0),
masking a real requirement as "undeclared."
Three seed-data guardrail holes, matching LOGIC DOCS/002's "missing
floor is a silent hole" pattern:
- constraint_resolver.py: CATEGORY_SEVERITY had no entry for the
"material" category, so Nuclear Thermal Drive/Nuclear Fuel's
radiation_shielding requirement defaulted to a non-blocking "warn"
nothing in the catalog ever satisfies. Added material -> block.
Consequence, verified: every nuclear combo across all domains now
correctly fails pass 1, since nothing currently provides shielding --
the accurate state given the catalog gap, not a regression.
- transport_example.py: Submarine had a mass range_min but no
range_max, unlike its sibling water platform -- _decide_masses skips
its entire structural-feasibility search when p_max is None. Added a
20,000,000kg ceiling (small submersible to large ballistic-missile
class).
- transport_example.py: Amphibious Vehicle declared no medium requires
at all, so it vacuously satisfied every domain's medium constraint
including space-only interplanetary_travel. Added medium=ground
(the current requires model has no OR semantics for "ground or
water," so this is a real tradeoff -- it can no longer participate in
maritime_shipping either, losing the water half of "amphibious").
Verified: interplanetary_travel's pass-2-estimated count dropped from
33 to 3, and all 3 remaining are genuinely Spaceship-based; the ~30
removed were confirmed to be Amphibious Vehicle's vacuous passes.
Logged the GPU-batching-for-the-optimizer discussion (why it doesn't
fit at current scale, what threshold would change that, what it would
actually require) as LOGIC DOCS/003 for future reference.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Andrew Simonson
3795a7e826