Block Plan Testfit

The two bugs this exists to prevent

### 1. A layout that looks placed and isn't

Block-plan generation is a packing problem, and the failure is geometric: a room that overlaps another, or one placed inside the notch of an L-shaped suite — outside the actual demised area. Both render as a clean floor plan. Nobody catches it by looking, because a plan is exactly the kind of picture that looks correct.

So the geometry is asserted directly: pointInPoly for inside/outside an L-shape, rectInsidePoly rejecting rectangles that span the notch, and rectsOverlap honouring a margin. Then the generator is tested end-to-end — the full program placed in a rectangular suite with no overlaps, and every room inside an L-shaped suite, never in the notch.

### 2. The number that came from a model

Quantities here come only from the confirmed layout geometry, rates from an editable card, totals from arithmetic. No language model touches any of it.

That is not a purity preference. A model asked for a construction estimate returns a plausible figure with no derivation, and the resulting number cannot be checked, argued with, or corrected — it can only be believed or discarded. A quantity derived from a polygon can be pointed at.

The range is the output, not a decoration

buildEstimate returns an ordered LOW/EXPECTED/HIGH band, and every estimate carries its assumptions, exclusions and data date. Percentage lines compound in a fixed order rather than being applied ad hoc.

An estimate without a data date is undated forever: six months on, nobody can tell whether it reflects current pricing, and it gets used anyway because it is the number that exists.

About the rate card — read this before you trust a total

The shipped card is a seed, explicitly stamped 2026-07 LA seed, and every rate is a LOW/MID/HIGH band rather than a point.

It is a starting structure, not pricing advice for your market or your date. Replace it. The vintage stamp is deliberately part of the output so a stale card is visible in the estimate rather than discovered in a bid meeting. Non-office asset classes fall back to a coarse whole-suite band, which is honest about being coarse.

What this does NOT do

No CAD, no drawing, no rendering, no PDF, no boundary tracing — you supply the polygon. No code compliance, egress, ADA or occupancy checking: this places rectangles, it does not know the building code.

No procurement, scheduling or bid levelling.

Verified

12 tests: quantity derivation including shared-partition credit and door counts, mode scaling, office trade lines with compounding percentage lines and an ordered range, the coarse band for non-office classes, every estimate carrying assumptions/exclusions/data date, the three geometry predicates, and full-program placement in both rectangular and L-shaped suites.

Not covered: no test on a concave suite more complex than an L, no performance test on large programs, and nothing validates that the seed rates are accurate for anywhere — they are a structure to replace.

Related

takeoff-estimating shares lineage with this code: both descend from the same measurement utilities, and their geometry/types overlap substantially. They are separate products because they answer different questions — this one generates a layout and prices it, that one prices measurements you have already taken. If you need both, expect some duplicated utility code.