Corrections

What was wrong

The Extension Ladder Height Calculator said it followed OSHA's ladder rule, gave the angle as about 75.5°, and worked the ladder's length as if the foot stood one foot out for every four feet up: a ladder 1.0308 times the height. The two do not agree. One out for every four up is about 76°; OSHA's rule (29 CFR 1926.1053(b)(5)(i)) sets the foot about a quarter of the ladder's working length out, which is 75.5° and a ladder 1.0328 times the height. At the page's 3.6 m (11.8 ft) default the answer was 15.17 ft of ladder, three feet above the eave included. It was found by an independent review of a new triangle page that cited the same rule.

What is correct

The page now works to OSHA's own words, quoted in its help: a ladder 4 ÷ √15 = 1.0328 times the height, with the angle 75.5°, so the 3.6 m default reads 15.20 ft. Every answer rises by about 0.2%. The calculator is at version 1.1.0, so a project line saved from it shows that it changed.

What stops it coming back

A test pins the rule as OSHA words it, the 75.5° angle, the 1.0328 factor and the absence of the old one-in-four-up wording. Nothing checks in general that an angle a page quotes is the ratio it computes with; that gap is recorded here as open.

In: src/lib/registry/extension-ladder-height-calculator.test.ts, src/content/corrections-figures.test.ts

Pages affected

Extension Ladder Height Calculator: the ladder length at every input, by about 0.2%; its help text; any project line added from it before this date.

What was wrong

The Pool Volume Calculator and the Hot Tub & Spa Volume Calculator work the water out in cubic feet and multiply by the US gallons in a cubic foot, and both used 7.48. The exact figure is 1,728 ÷ 231 = 7.4805, because a US gallon is defined as 231 cubic inches, so every gallon the two pages printed was 0.007% low, and so was every litre, which the pages restate from those gallons. On the pool page's metric default, a 10 × 5 m pool at 1.5 m, which is 75 m³, the page printed 74,990 litres. The imperial page opens at 33 × 16.5 ft at 5 ft, 2,722.5 cubic feet, and there it printed 20,360 gallons; those cubic feet hold 20,365.7 gallons, which is what the site's own cubic feet to gallons converter gives, and 20,370 at the four figures the page prints. Both pages had used 7.48 since their first release on 26 August 2026. The site's Gallons to Cubic Feet converter, the pool page's first related link, was moved to the exact figure on 16 September 2026, and that change did not reach either page. It was found by an independent review of the pool page's new round, oval and kidney shapes.

What is correct

Both pages now multiply by the exact 1,728 ÷ 231 = 7.4805 US gallons per cubic foot, taken from the site's unit table as the converters take it. Every answer rises by 0.007%, at most one step in the fourth figure the pool page prints: its metric default reads 75,000 litres and its imperial default 20,370 gallons. The hot tub page prints three figures, which move only near a rounding step; its defaults read 3,120 litres and 864 US gallons, as they did. Both calculators are at version 1.1.0, so a project line saved from either shows that its answer changed.

What stops it coming back

A test now pins the pool page's metric default at 75,000 litres at the precision the page prints and its imperial default at 20,370 gallons, holds every rectangle the page shipped to the old arithmetic times 1,728 ÷ 231 over 7.48, and holds the pool page's round pool to the hot tub page's answer, so the two pages cannot drift apart again. A second test holds the figures this entry quotes to what the pages compute. Nothing checks in general that a conversion constant written into a page is the exact one: the site's factor gate recognises a factor written to its full digits, and 7.48 has three, which is how the converter's correction did not reach these pages. That gap is recorded here as open.

In: src/lib/registry/pool-volume-calculator.test.ts, src/content/corrections-figures.test.ts

Pages affected

Pool Volume Calculator: every answer, in gallons and in litres, by 0.007%; Hot Tub & Spa Volume Calculator: every answer by the same 0.007%, which its three-figure answer shows only near a rounding step; the pool gallons page that works backwards from a volume, and the factor it quoted; any project line added from either calculator before this date.

What was wrong

One FAQ answer on the Horizontal Cylinder Tank Partial Fill Volume Calculator, "How much do the ends actually matter?", said that on a tank whose barrel is twice its diameter, the two hemispherical heads, which together make one complete sphere, are about a sixth of the whole capacity. They are a quarter. The sphere is πD³/6 and a barrel 2D long is πD³/2, so the heads are (1/6) ÷ (1/2 + 1/6) = 1/4 of the tank. On the page's own 1.2 m (3.9 ft) diameter with a 2.4 m (7.9 ft) barrel and hemispherical ends, the calculator gives 3,619 litres (956 US gallons) full, 905 litres (239 US gallons) of them in the heads, where a sixth would be 603 litres (159 US gallons). The answer had said a sixth since the page's first release on 15 September 2026. It was found while the page's answers were being rewritten to open on the figure the page computes, which meant working this one out on the page.

What is correct

The answer now opens on the right figure: on a tank whose barrel is twice its diameter, two hemispherical heads hold about a quarter of the whole capacity. The calculator was right throughout and no result it printed changed, so its version was not bumped and saved estimates show no change notice.

What stops it coming back

faq-figures.test.ts now works the quarter out on the page itself, from its barrel and full-capacity rows, and fails if the answer stops saying it; corrections-figures.test.ts holds every figure this entry quotes to what the page computes. Nothing checks in general that a figure in an answer's prose is what its page computes: the figures test covers the answers listed in it, the ones rewritten to open on a figure, and that gap is recorded here as open.

In: src/content/faq-figures.test.ts, src/content/corrections-figures.test.ts

Pages affected

Horizontal Cylinder Tank Partial Fill Volume Calculator: one FAQ answer, "How much do the ends actually matter?". No figure the calculator printed was wrong.

What was wrong

The U-Value Converter (W/m²K to BTU/hr·ft²·°F) answers "Why is the factor 5.678?", and the answer said the factor is "the watt per square metre per kelvin expressed in BTU per hour per square foot per degree Fahrenheit". That is backwards: one BTU per hour per square foot per degree Fahrenheit is 5.678 W/m²K, so one W/m²K is 0.1761 of the US unit, not 5.678 of it. The arithmetic in the same answer, 0.29307 ÷ (0.0929 × 5/9) = 5.678, was right, and so was every conversion the page made: its factor line says to divide by 5.678263. A reader who took the sentence at its word and multiplied would have turned the page's default 0.18 W/m²K into 1.02 rather than 0.0317, 32 times too high. The answer had read that way since the page's first release on 22 September 2026. It was found while the page's answers were being rewritten to open on the answer, which put that sentence first.

What is correct

The answer now opens: one BTU per hour per square foot per degree Fahrenheit is 5.678 watts per square metre per kelvin, followed by the same arithmetic. No figure the page printed was wrong and none changed, so its version was not bumped and saved estimates show no change notice.

What stops it coming back

faq-figures.test.ts requires the answer to keep the corrected sentence and the page to keep the NIST SP 811 line it restates, 1 Btu(IT)/(h·ft²·°F) = 5.678 263 W/(m²·K); corrections-figures.test.ts recomputes every figure this entry quotes. Nothing checks in general that a sentence explaining a conversion factor states it in the direction the page converts; this was found by reading the answer against the page's own factor line, and that gap is recorded here as open.

In: src/content/faq-figures.test.ts, src/content/corrections-figures.test.ts

Pages affected

U-Value Converter (W/m²K to BTU/hr·ft²·°F): one FAQ answer, "Why is the factor 5.678?". No figure the converter printed was wrong.

What was wrong

The Floor Screed Thickness Calculator works out how thick a sand and cement screed must be and then, at that thickness, the cement, the bags and the sand it takes. It worked the materials by volume: one part cement to four of sand, the sand taken as the screed's own volume and the cement as a quarter of it, with a 25 kg bag counted as 17 litres loose and a US sack as one cubic foot. BS 8204-1 sets a screed's proportions by weight, nominally 1 : 4 cement to sand, as the Mineral Products Association's Data Sheet 22 reports it, while the page's own source line called the mix one gauged by volume. So the cement came out 6 to 8% under the standard's mix, and the sand was given as a volume, which is not how it is bought. On the metric default, 60 m² floating on insulation in a house over a base 10 mm out, which is 75 mm with 10% for waste and 4.95 m³ of screed, the page asked for 73 bags of 25 kg; the standard's 1 : 4 by weight, at 2,000 kg of sand and cement in each cubic metre, takes 1,980 kg of cement, which is 80 bags. The imperial page opens at 650 sq ft over a base 0.39 in out, and there it asked for 44 sacks of 94 lb where the same mix takes 4,388 lb of cement, which is 47 sacks. The page had worked by volume since its first release on 15 September 2026. It was found by an independent review of the new Floor Screed Calculator, which works by weight and gave the thickness page's own floor 80 bags, so a reader who ran both pages got two answers for one floor.

What is correct

The page now works the cement and sand by weight, through the same function as the Floor Screed Calculator, at BS 8204-1's nominal 1 : 4 and Sika's 2,000 kg of sand and cement as batched in each cubic metre. The metric default takes 1,980 kg of cement, 80 bags of 25 kg, and 7.92 tonnes of sharp sand; the imperial default takes 47 sacks of 94 lb. Its rows give the cement and the sand by weight, as they are bought, and its sources name the MPA data sheet and Sika's. The thickness, which is the page's answer, did not change. The calculator is at version 1.1.0, so a project line saved from it shows that its figures changed.

What stops it coming back

screed-materials-agree.test.ts runs the Floor Screed Calculator at the depth the thickness page works out, on the same floor and margin, and requires the volume, the cement, the bags and the sand to match in both unit systems, at every way of laying the screed and across a sweep of floors, deviations and margins, as the two tile adhesive pages are held together. A second test holds the figures this entry quotes to what the page computes. Nothing checks in general that two pages working out the same quantity use the same method: this was found because a new page did the same sum another way, and that gap is recorded here as open.

In: src/lib/registry/screed-materials-agree.test.ts, src/content/corrections-figures.test.ts

Pages affected

Floor Screed Thickness Calculator: its cement, its bag or sack count and its sand, at every input, from its first release; any project line added from it before this date. The thickness it works out did not change, and no answer on the Floor Screed Calculator changed.

What was wrong

The Diagonal Tile Corner Waste Calculator counts the cut positions around the edge of the room by dividing the perimeter by the tile size. Its help text and one FAQ answer said that for a rectangular tile, entering the LONGER side gives the more conservative, higher estimate. The formula does the opposite: the longer side gives fewer positions and the lower figure. On the page's default 20 m perimeter with a 600 × 300 mm tile, entering 600 mm gave 34 cut positions and 3.06 m² of corner waste; entering 300 mm gave 67 positions and 6.03 m². A reader who followed the advice ordered against the smaller of the two.

What is correct

The help text and the answer now say to enter the SHORTER side, which gives the higher, conservative count, and the answer carries a dated note that it was the wrong way round. The formula itself was right throughout and no result changed, so the calculator's version was not bumped and saved estimates show no change notice.

What stops it coming back

Nothing automatic compares the direction a help text claims with the direction the formula moves; it was found by reading the page against its own formula while writing a worked example. That is recorded here as open rather than closed. What does guard the arithmetic is the calculator's pinned test cases, which are unchanged.

In: src/lib/registry/calculators/diagonal-tile-corner-waste-calculator.ts

Pages affected

Diagonal Tile Layout 45° Corner Cut Waste Calculator (help text and one FAQ answer). No figure it printed was wrong.

What was wrong

The worked example for a 4 × 3 m room with 2.4 m walls gave the masonry wall as 8.4 m², which is neither a 4 m wall (9.6 m²) nor a 3 m wall (7.2 m²) of that room, and counted two external corners that a plain rectangle does not have. The boarded walls, 25.2 m², only balanced because the total was right. An introduction paragraph spoke of four corners taking four beads, which matched nothing on the page. The bathroom example on the same shelf said its first calculator gave the starting line and the cut size at each edge; that calculator returns a tile count, not a layout.

What is correct

The room now has what its figures always implied: the masonry end wall carries a chimney breast 1.2 m wide projecting 250 mm. That makes the masonry faces 3.5 m long (8.4 m²), gives the two external corners, adds two internal angles, and takes 0.3 m² off the ceiling. The boarded walls are 26.4 m² and the ceiling 11.7 m², and every step that used them was re-run through its calculator: the scrim is 84.2 m, the skim 109.5 kg in five bags (seven at 3 mm) and the mist coat 3.9 L. The undercoat and the bead counts did not change. The bathroom's first step now says what its calculator computes.

What stops it coming back

Every figure a worked example prints now comes from a run of its calculator, re-computed on every build: the test fails if the calculator's answer moves or if the figure shown does not round from it. That guards the arithmetic. It does not check that the geometry a page describes agrees with itself, which is how this was wrong; that stays a reading task, and is recorded here as open.

In: src/content/worked-examples.test.ts

Pages affected

Worked examples: A room replastered (walls, corners, scrim, skim and mist coat figures); A bathroom gutted and retiled (the first step's description). No calculator produced a wrong number.

What was wrong

Five statements about how the site is checked were wider than the checks. Every calculator page and every downloadable report printed 'formula audited site-wide 2026-09-06', including the 147 calculators written after that review, and pages revised after it without being re-dated. The review's own description, on those pages, on the About page and in the 2026-09-06 entry of this ledger, said the work was 'checked by two independent reviewers'; the reviewers were this project's own, which the validation page contradicted by saying no independent review exists. The validation page said the build runs every test vector and that a failing edit cannot ship, and the 2026-09-06 entry here says the suite runs before every build; the build does not run the tests, and the suite that does, on every push, does not block a deploy. The downloadable report re-ran each calculator's pinned cases in the visitor's unit system, so on the 76 calculators whose metric page takes another branch it printed FAIL beside cases that pass. The validation page and the API said 42 of the step-less vectors were single-step conversions, a figure typed in on 2026-09-16 that was 40 when checked. And this ledger, the API and the site's summary for AI assistants called it a record of every confirmed error, which it is not.

What is correct

The review's date now appears only on a page whose sources were last checked on or before it, labelled 'in the site-wide review of 2026-09-06', and the About page says a page revised afterwards may differ from what was read; the 147 later calculators show their own date alone. The review is described as first-party. The validation page says the test suite runs the vectors on every push and that a failing edit turns the check red, and the report runs the pinned cases exactly as the suite does. The converter figure is measured at build time. The ledger says what it holds: errors people reported and the ones this project judged a reader could have acted on. Its 2026-09-06 entry is left as it was written, because entries here are never edited; this one records that its 'independent' was wrong.

What stops it coming back

One function decides where the review's date may appear, and a test holds the page and the report to it. A second test checks every calculator against the list of the 963 the review read: one that is not on it must carry a sources-checked date after the review, so a new page cannot inherit the date by copying an older page's. The converter count is generated with the rest of the corpus coverage and re-measured by vector-provenance.test.ts. A test builds a metric visitor's report for a calculator that branches by system and fails on any FAIL. Nothing automatic checks prose about process — what a review was, what a build runs — against the process itself; those were found by an independent reading of the validation page and are recorded as open.

In: src/lib/registry/review-batches.test.ts, src/lib/registry/vector-provenance.test.ts, src/lib/calculator/calculation-report.test.ts

Pages affected

The provenance line on every calculator page and report; the pinned-case table in the report, for metric visitors; the About page; the validation page; validation.json's coverage note; the corrections page's own description; corrections.json's description in the API; llms.txt. No calculator produced a wrong number.

What was wrong

The site's rule is that a rate a third party sets — a lender's interest rate among them — opens blank until the visitor enters it, and every other interest rate on the site did. The Refinance Break-Even Calculator opened on a current rate of 6.5% and a new rate of 5%, and printed the payments, the monthly saving and the break-even month worked from them before anything was typed. Its two rates had been declared as the visitor's own amounts rather than as rates, which is why the rule did not reach them. The disclaimer, which says no rate is ever filled in for you, was untrue of this page.

What is correct

Both rates are declared as rates and open blank; until they are entered, the page asks for them rather than showing a figure. The example values a visitor can load are unchanged, and so is every result for the same inputs.

What stops it coming back

The rule was already enforced for fields declared as rates; what let this through was the declaration. Nothing yet classifies an input as a rate from what it is — a percentage field named for a lender's rate declared as an amount would still pass — and that is recorded here as open.

In: src/lib/registry/calculators/launch-financial.ts

Pages affected

Refinance Break-Even Calculator: what it showed on opening. No result for entered values changed.

What was wrong

The Deck Joist Span and Size Calculator gave IRC R507.5 as the source of the rule that a deck joist may cantilever no more than a quarter of its span. In the 2018 and 2021 IRC, R507.5 is the section on deck beams; the joist rule, cantilever included, is R507.6. The same page described the quarter-span rule as the whole limit, where R507.6 caps a cantilever at the lesser of a quarter of the span and the cantilever its Table R507.6 gives for the joist.

What is correct

The page now cites R507.6 (Deck joists), states both halves of the limit, and says in its limitations that it checks the quarter-span rule only, so the table must be read before an overhang is built. The arithmetic did not change and neither did any result, so the version was not bumped.

What stops it coming back

Nothing automatic checks a cited section number against the code it names: the codes are not reproduced here and their text is not available to a build. It was found by reading the section against the published code while working through a backlog of flagged citations, and is recorded as open rather than closed.

In: src/lib/registry/calculators/gap-batch-2.ts

Pages affected

Deck Joist Span and Size Calculator: its source list, its cantilever help text and its limitations. No calculator produced a wrong number.

What was wrong

The Gravel Base Layer Tonnage Calculator said a compacted crushed stone base weighs 1,600 to 1,900 kg/m³ (100 to 120 pcf) and opened on 1,700. Those are nearer the weight of crushed stone loose in a pile — the site's own density table puts it at 1,550 — than compacted in place: Wisconsin DOT's standard specifications convert completed dense-graded base at 1.85 US tons per cubic yard, about 2,195 kg/m³. An order worked from the default came out about a fifth light, and the density field would not accept more than 2,100. Four worked examples used the same figure, and so printed light tonnages too.

What is correct

The calculator now opens on 2,200 kg/m³ (about 137 pcf) for a compacted dense-graded base, accepts up to 2,400, cites the Wisconsin DOT factor, and says a clean open-graded stone packs far less densely and should be entered at the quarry's figure. The four examples were re-worked: the retaining-wall pad is 2.75 US tons, the patio base 4.86 US tons, the concrete driveway's new base 14.9 short tons and the old base it replaces 13.7, and the garden-room sub-base 7.92 tonnes. The gravel driveway's open-graded stone keeps its 1,600 kg/m³, now explained as that stone's own figure. The calculator's version is unchanged: its working is the same, and a saved line keeps the density it was entered with.

What stops it coming back

Two test vectors pin the new default and one compacted cubic yard at the Wisconsin DOT factor, so the source and the calculator cannot drift apart again. Nothing checks a density default against its source automatically; it was found by reading a flagged figure against a highway specification. The worked examples' re-run test is what found the four pages that depended on it.

In: src/lib/registry/calculators/gravel-base-tonnage-calculator.ts, src/content/worked-examples.test.ts

Pages affected

Gravel Base Layer Tonnage Calculator (default, range, help and source); worked examples: block retaining wall, paver patio, concrete driveway replacement, garden room slab, and the gravel driveway's wording; the patio-below-the-DPC guide, which repeated the 1,600 to 1,900 range.

What was wrong

The asphalt shingle roof takeoff gave the ice-dam membrane calculator the footprint length as the eave length. That calculator asks for the total of every eave, and a gable has two, so the takeoff ordered half the membrane. The same takeoff paired the ridge cap and the ridge vent as one choice: a project priced one or the other, the quote check read them as one line, and the takeoff's text said the two were alternatives rather than additions. They are not. The cap shingles are nailed over the vent, which is what both calculators' own pages and the worked example say, so a roof that chose the vent was told to buy no cap.

What is correct

The membrane row now takes both eaves of the gable, twice the footprint length, and the takeoff says a hip roof has eaves on all four sides. The ridge cap and the ridge vent are separate rows that are costed together, the text says the cap goes on over the vent, and the quote check's note says a quote with a vent and no cap has either folded the cap into the squares or left it out. No calculator changed; the takeoff's own figures did.

What stops it coming back

A test now requires the cap and the vent to be costed together and the membrane's eave to be twice the footprint length, and the pages that had them as one choice are required to name each other. What let it through is that nothing compares a takeoff's claim about two products with what either product's own page says; it was found by re-working the shingle roof example against the takeoff, and that gap is recorded as open.

In: src/lib/project/assembly-sets/envelope.ts, src/lib/composition/resolve.test.ts, src/components/calculator/part-of-takeoff.test.ts

Pages affected

The asphalt shingle roof takeoff: the ice-dam membrane row's quantity, the ridge rows and the text above them; any project line added from it before this date; the quote check's note for a shingle roof; and the ridge cap, ridge vent and shingle calculator pages, whose list of the job's other trades now names both.

What was wrong

A read of every job takeoff against the calculators it runs found rows fed the wrong kind of figure, rows that bought one thing twice, and text the calculators' own pages contradicted. The ones that changed what a visitor was told to buy: the pool surround paved the pool itself (1,137 pavers where the frame takes 758); the strip footing's backfill refilled the space its own concrete takes, and the wall standing in the trench (18.6 m³ where 8.3 m³ goes back); the eaves and gutter job measured one eave of a two-eave roof, so its fascia, soffit, gutter, hangers and guard were each about half; the kitchen splashback priced the tiled splash again as worktop; the room fit-out said its board and paint covered the ceiling when both rows count walls only, and had no row for the compound its text said the board decides; a bathroom's tile, adhesive and backer board covered the floor under the bath; the retaining wall took the exposed height where its geogrid and drainage rows ask for the full height, and priced a concrete footing its calculator reserves for cantilever walls instead of the gravel pad the wall sits on; the carpet ordered one drop across a room two rolls wide; the attic job's bags stopped short of the depth its own first row says the target needs; the shingle roof bought full underlayment under the ice-dam membrane as well as the membrane, and its shingle pitch was never set from the roof; the standing seam roof counted clips for a different number of panels from its panel row; the radiant floor lagged one pipe of each flow-and-return pair, and a duct wrap was priced for a duct several times the size of a bathroom extract; the conduit run counted every corner twice; the garage floor committed a self-levelling pour that removes the fall its own text relies on. Text elsewhere claimed things the calculators deny, among them that the site had no electric mat or downlight spacing calculator when it has both, and the panel upgrade offered its load check as an alternative to the full calculation it checks.

What is correct

Each takeoff now feeds its calculators what they ask for, or says in its text and its exclusions exactly what a row leaves to the reader. Rows were added where the site already measures the missing thing (ceiling board, ceiling paint and joint compound in the room fit-out, the gravel levelling pad under the retaining wall, the joint tape in the ceiling job, an electric-mat option in the heated floor, a lumen-method row for downlights), removed where they bought something twice or the wrong thing, and the paver calculator gained an optional area left unpaved so the pool surround counts its frame. Twenty-six takeoffs changed at their opening figures. No calculator's answer for the same inputs changed; the paver calculator gained a field that opens at 0.

What stops it coming back

Seven readers, one per takeoff file, compared every mapped input and every sentence with the calculators' own labels, help, limitations and working, and independent reviewers checked each change over three passes. Tests now pin the new mappings and the rows that open on a calculator's default (takeoff-defaults.test.ts), the alternative pairs (resolve.test.ts) and the gated rows (assemblies.test.ts). What let these through is that nothing compared a takeoff's claim with its calculator's own page; that read is not automated and is recorded here as open. A takeoff still cannot run one calculator in two rows, because the takeoff page and the picker identify rows by calculator; the backer board's mortar bed is therefore stated in the text rather than counted.

In: src/lib/project/takeoff-defaults.test.ts, src/lib/composition/resolve.test.ts, src/lib/project/assemblies.test.ts

Pages affected

The job takeoffs for a room fit-out, stud wall, retaining wall, plaster room, plasterboard ceiling, room repaint, carpet and pad, bathroom remodel, shower enclosure, kitchen splashback, heated bathroom floor, wet room tanking, asphalt shingle roof, standing seam roof, eaves and rainwater, attic insulation, window replacement, masonry wall, strip footing, electrical rough-in, panel upgrade, recessed lighting, bathroom ventilation, radiant floor loop, pool surround and garage floor coating; their quote checks; and any project line added from them before this date. Text-only corrections on others. The Paver Calculator gained a field.

What was wrong

The Tile Adhesive Calculator worked its rate as half the trowel notch at 1.5 kg per square metre for each millimetre of bed, so a 6 mm notch came to 4.5 kg/m² and a 10 mm notch to 7.5, and it added half again for back-buttering. Its source line said both rates sat inside the range printed on common bags. They do not: ARDEX's data sheets give about 1.0 kg of powder per square metre per millimetre of bed, CUSTOM's VersaBond table covers 90 to 100 sq ft (8.4 to 9.3 m²) with a 50 lb (22.68 kg) bag on a 1/4 in square notch, which is 2.4 to 2.7 kg/m², and the site's own Thinset Mortar Calculator already said 3 and 5 kg/m² for the same two trowels and 30% for back-buttering. On its metric default, 20 m² on a 6 mm notch with 10% waste, the page asked for 99 kg, five 20 kg bags, where 66 kg is the figure: four 20 kg bags. The imperial page opens at 220 sq ft on the same notch, and there it asked for 223 lb, five 50 lb bags, where 149 lb is the figure: three 50 lb bags. Back-buttered work came out about three-quarters high. The bathroom quote check reads the same calculator, so the adhesive range it held a quote against was high by the same half.

What is correct

The page now uses the manufacturers' figure of about 1.0 kg of powder per square metre per millimetre of bed and the thinset page's rate for every notch the two share — 1.5, 3, 4, 5 and 6.5 kg/m² for the 3, 6, 8, 10 and 12 mm notches — and adds 30% for back-buttering. A solid bed still doubles the combed figure. The default job is 66 kg on the metric page and 149 lb on the imperial one. Its sources now name the two data sheets, and the tile adhesive page that works backwards from a bag gives the new coverage per bag. The calculator is at version 1.1.0, so a project line saved from it shows that its answer changed.

What stops it coming back

A test now holds the two adhesive pages to the same kilograms for every notch they share, combed and back-buttered, so one cannot move without the other; the calculator's pinned cases were re-worked by hand from the new rates. What let it through is that each page was checked only against itself. Nothing compares two calculators that answer the same question except where a test like this one has been written for the pair, and that is recorded here as open. It was found while the job takeoffs were read against their calculators, where the two pages met on one job.

In: src/lib/registry/adhesive-rates-agree.test.ts, src/lib/registry/calculators/tile-adhesive-calculator.ts, src/content/corrections-figures.test.ts

Pages affected

Tile Adhesive Calculator: every result, its sources and its back-buttering answer; the tile adhesive page that works backwards from a bag; the bathroom quote check's adhesive line; any project line added from it before this date. The Thinset Mortar Calculator's answers did not change.

What was wrong

The Gravel Calculator works out the finished volume, adds a compaction allowance to give the loose volume to order, and prints both. Its weight used only the finished volume, at 1,600 kg/m³ (100 pcf), which the page called a compacted density. It is a loose one: the site's own density table gives gravel, dry loose, at 1,600 and crushed stone at 1,550, and a rolled dense-graded base weighs about 2,200 kg/m³ (137 pcf). So the tonnage and the loose volume printed beside it described two different amounts of stone. On the metric default, 10 × 3 m at 100 mm with a 20% allowance, the page asked for 3.6 m³ loose and said it weighed 4.8 tonnes; that load weighs 5.76 tonnes. The imperial page opens at 33 × 10 ft at 4 in with the same allowance, and there it asked for 4.89 cubic yards loose and said 5.49 US tons, where that load weighs 6.59 US tons. Either way an order by weight came out a sixth light. The page had weighed the loose volume until 2026-09-05, when a change made in the site-wide review switched it to the finished volume, reasoning that a compacted density times a compaction-inflated volume counts the compaction twice. The reasoning was sound and the premise, that 1,600 is compacted, was not. The Gravel Driveway Calculator also called its 1.4 US tons per cubic yard compacted, which is likewise a loose figure; its answer was not affected.

What is correct

The weight is now the loose volume to order at the loose density, so the two rows are one load: 5.76 tonnes on the metric default and 6.59 US tons on the imperial one. With the allowance at 0 the answer is the same as before. The page's source line, note and limitations call 1,600 kg/m³ loose, and its limitations name the gravel base tonnage page, which takes a compacted density, as the place to work a dense-graded base specified by its compacted thickness, at about 2,200 kg/m³ (137 pcf). The calculator is at version 1.1.0, so a project line saved from it shows that its answer changed. The Gravel Driveway Calculator's figure is now described as loose, and its answer is unchanged.

What stops it coming back

A test now requires every weight the page prints to be its loose-volume row at 1,600 kg/m³, at allowances from 0 to 40%, and the pinned cases were re-worked by hand from the loose volume. The pinned case the September change left behind had been written from the code it was pinning, which is how a correction in the wrong direction passed its own tests. Nothing checks that a density's state, loose or compacted, matches the volume it multiplies; this was found by reading the page against the gravel base page's correction of the same day, and that gap is recorded here as open.

In: src/lib/registry/gravel-calculator.test.ts, src/lib/registry/calculators/launch-batch-1-core.ts, src/content/corrections-figures.test.ts

Pages affected

Gravel Calculator: its tonnage and US tons at any compaction allowance above 0, from 2026-09-05; any project line added from it before this date. Gravel Driveway Calculator: the wording about its density only.

What was wrong

The Electric Underfloor Heating Mat Area Calculator works out the heatable floor and then names the largest standard mat that fits inside it, because a mat's cable cannot be cut to fit. It held one list of sizes, in square metres, and for imperial readers it converted them, so a reader in the US or Canada was told to buy a mat no North American maker lists. The imperial page opens on a 10 × 6.5 ft bathroom with a 2 in setback, 49.9 sq ft heatable, and there it named a 43.06 sq ft mat — the 4 m² mat, converted — with 6.87 sq ft left unheated. The metric page, which opens on a 3 × 2 m bathroom with 4.61 m² heatable and names the 4 m² mat, was right. The heated bathroom floor takeoff carried the same row, and its text said the imperial figure was the metric size converted. The heatable area, which is the page's answer, was right throughout.

What is correct

The imperial breakdown now chooses from mats sold by the whole square foot — 10 to 50 sq ft in steps of 5, then 60 to 100 in steps of 10, the 120 V range in SunTouch's installation manual — against the heatable area in square feet. The imperial default bathroom now names the 45 sq ft mat, with 4.92 sq ft left unheated. The note says makers' lists differ by a size here and there, so the mat is checked against the list of the one being bought. The metric breakdown and the heatable area are unchanged. The calculator is at version 1.1.0, so a project line saved from it shows that it changed.

What stops it coming back

A test pins the mat each unit system chooses on the metric default bathroom and on a 10 × 8 ft one, and requires the metric breakdown to stay exactly as it was; a second test holds the figures this entry quotes for the imperial page's own default to what the page computes. The calculator's own pinned cases check only the headline, which is why a breakdown row in the wrong market's sizes passed them. Nothing checks in general that a product size a page names in one unit system is one that market sells; this was found by reading the takeoff that uses the page, and that gap is recorded here as open.

In: src/lib/registry/underfloor-heating-mat-calculator.test.ts, src/content/corrections-figures.test.ts

Pages affected

Electric Underfloor Heating Mat Area Calculator: the largest-mat and unheated-floor rows for imperial readers; the heated bathroom floor takeoff's mat row; any project line added from it before this date. No metric figure changed.

What was wrong

The Wet Room Tanking and Waterproof Membrane Calculator counts a preformed collar for every pipe that passes through the membrane, and its reinforcing tape added 0.6 m (2 ft) at each of those pipes as well, on top of the junction length and its 10% lap. A collar is bonded into the first coat on its own, and tanking kits supply collars for the pipes and tape for the junctions, so each pipe was counted twice. On the metric default, 9 m of junctions and three pipes, the page asked for 11.7 m of tape where 9.9 m runs the junctions: 1.8 m over. The imperial page opens at 30 ft of junctions and three pipes, and there it asked for 38.9 ft where 33 ft runs the junctions: 5.9 ft over. Until 2026-09-25 its own help said a pipe takes a collar or a patch of tape; the takeoff review that day changed the help to say both, rather than changing the arithmetic. It was an over-order, never a shortfall, and the membrane and the collar count were right.

What is correct

Tape is now the junction length plus 10% for laps, and each pipe is counted once, as a collar: 9.9 m of tape on the metric default and 33 ft on the imperial one. The help, the source line and the working say the same thing. The calculator is at version 1.1.0, so a project line saved from it shows that its answer changed.

What stops it coming back

A test pins the tape and collar rows in both unit systems and requires that adding a pipe moves the collar count and not the tape. The calculator's own pinned cases check only the membrane litres, which did not change, so they could not see the tape. Nothing looks for one item counted in two rows of the same breakdown; this was found by reading the wet room takeoffs against the calculator, and that gap is recorded here as open.

In: src/lib/registry/wet-room-tanking-calculator.test.ts, src/content/corrections-figures.test.ts

Pages affected

Wet Room Tanking and Waterproof Membrane Calculator: its reinforcing tape row whenever a pipe was entered; the tape rows of the shower enclosure and wet room tanking takeoffs, and their text; any project line added from it before this date.

What was wrong

The project page asked for a version's name with a blocking browser dialog. In an embedded browser — the kind that opens when a link is tapped inside a messaging app, which is how a great many people on site open anything — that dialog is unavailable and throws instead of opening. The button did nothing at all: the saved-version count stayed at zero and no message appeared. Everything behind it went with it, because a version that cannot be named cannot be saved, compared, or turned into a change order. The confirmation before restoring a version failed the same way, so a saved version could be seen and never brought back. The same question was asked that way in five places.

What is correct

Nothing on this site asks in a browser dialog any more. A name is typed in a field that opens where the button was, and a destructive action arms itself and says what the second press will do rather than opening a window over the page. The check a developer would normally add does not help here and is worth recording: in the browsers where the dialog throws, the test for whether it exists still reports that it does.

What stops it coming back

A test reads every source file on the site and fails on a call to any blocking dialog, so the next one cannot be written. Separately, a browser test now drives the whole cycle — save a baseline, change the work, read the change order, restore — because the eighty-six tests covering the arithmetic all passed throughout and none of them could open a page.

In: src/components/project/ask.test.ts, e2e/works-cycle.spec.ts

Pages affected

Saving, comparing and restoring versions of an estimate; renaming a project; naming a zone. No calculator produced a wrong number.

What was wrong

The function that breaks a scope statement into paragraphs was written with a literal letter s where a whitespace pattern was meant — a backslash lost by the tool that wrote the file. It matched nothing, so every standards page rendered as one unbroken block, and the report covering that work claimed the problem had been fixed.

What is correct

The scope renders as paragraphs of two sentences, as it was meant to. The pattern now lives in one place, imported by both the page and the check, so there is no second copy that can be right while the first one is wrong.

What stops it coming back

The test now imports the same function the page renders with. It had previously written the pattern out a second time, correctly, and passed — a test carrying its own copy of the thing it is testing is not evidence about the thing.

In: src/lib/codes/standards-generated.test.ts

Pages affected

All fourteen /standards pages.

What was wrong

ASCE 7 — the loading standard the building codes point at — is cited by three calculators and qualified for a page of its own. It had none, because the code that builds those pages silently skips a document with no written scope statement, and the test checking the result compared it against the same function that had skipped it. Both sides of the comparison were missing the same page.

What is correct

ASCE 7 has a page, with a written scope like every other document, and the three calculators that cite it now link to it. The skip is no longer silent: a document that qualifies and has no scope written for it is reported by name.

What stops it coming back

A separate function now reports every document that qualifies and has no page, and a test fails while that list is not empty. What found the original defect was a second, independent count that disagreed — 14 against 13.

In: src/lib/codes/standards-generated.test.ts, scripts/standards-coverage.mjs

Pages affected

/standards, and the three calculators citing ASCE 7.

What was wrong

A citation that names two documents — "NFPA 54 / IFGC longest-length method" — was counted for the first one only, because the matcher stopped at its first hit. The report said ten documents qualified for a page while the site was already building thirteen, and its own description claimed it matched the same way the site does. It did not.

What is correct

It claims spans and keeps walking, the way the site's own detector does. Corrected counts: 92 distinct documents named, 14 qualifying.

What stops it coming back

Nothing automated compares the reporter against the builder — they are deliberately two implementations, and the disagreement between them is what found this. That is the check.

In: scripts/standards-coverage.mjs

Pages affected

The §2.3 coverage report. No visitor-facing page was wrong.

What was wrong

The rule behind the reference tables is that nothing is published unless a calculator computes with it. Checked at the level of the whole table it passed — 104 calculators. Checked row by row, which is what the rule actually says, two rates had nothing behind them. One is deliberate and documented. The other, hand excavation, has a matching rule that excludes every trench and post-hole calculator the site has, so no page can ever offer it.

What is correct

Both rows are published with the reason stated on the page rather than hidden. The hand-excavation rule is not changed here: widening it changes what live calculator pages suggest, which is a product decision.

What stops it coming back

A test fails when a row has no calculator behind it and no stated reason, so the next one forces a decision instead of disappearing.

In: src/lib/reference/reference.test.ts

Pages affected

The production rates reference table. No calculator produced a wrong number.

What was wrong

Consolidating the material densities showed the material weight calculator using 400 kg per cubic metre for bark mulch while two volume-and-weight converters used 600 lb per cubic yard, which is 356 — twelve per cent apart. Gravel, sand and topsoil agreed to within rounding.

What is correct

Both figures are inside the range bark mulch actually occupies, so the reference table publishes the range rather than picking one, and the calculators keep the numbers they had. Changing either would change an answer people may have used, and there is no basis for preferring one.

What stops it coming back

The densities now live in one module, so a future disagreement has to be introduced deliberately rather than by two files drifting. Nothing yet forces a calculator to publish a range where its figure is one — that is stated as open rather than claimed closed.

In: src/lib/materials/bulk-density.ts

Pages affected

Material Weight Calculator, Material Volume to Weight Calculator, Weight to Volume Material Calculator.

What was wrong

/tools/tape-calculator was served with an empty document head. No title, no description, no canonical URL, no social image, and none of the six language alternates every other page carries. To a search engine it was a page with no identity; to a person sharing it, a bare link.

What is correct

The head is restored in full — its own title, description, canonical, six alternates and image.

What stops it coming back

The post-build audit reads the pre-rendered HTML of every route and fails on a missing title, description or canonical. This defect is the reason that check covers tools and not only calculators.

In: scripts/audit.mjs

Pages affected

/tools/tape-calculator.

What was wrong

The site publishes a limit on how much the interactive drawing and tool panel may add to a calculator page. The page budget and the feature budget measured different sets of files, so the feature budget was over its limit on the live site for months and every report repeated the number as though it were met.

What is correct

Both budgets are measured on the built output, on the worst page of each family, and the build fails when either is over.

What stops it coming back

The audit now reads the built HTML of the page each budget is decided on and fails if the marker naming that page is missing or names a different one — because a saving that makes a number go down is indistinguishable from a measurement that stopped looking. Proved by breaking it: removing the marker from one page makes the audit name that page and stop.

In: scripts/audit-budget.mjs

Pages affected

Every calculator page carrying a drawing or a tool panel.

What was wrong

A rule meant to keep lines readable capped paragraphs at 54 characters' width. Because that unit scales with font size, a 12-pixel caption resolved to about 330 pixels and a 14-pixel paragraph to about 380 — a ribbon of text beside a 1,150-pixel page. The site owner reported it, with examples, as looking unprofessional.

What is correct

Paragraphs are capped at 672 pixels, the width the rest of the site already used, which is 96 characters at 14 pixels.

What stops it coming back

A test requires the rule to reference the named width rather than a hand-picked number. The deeper cause has no test and is stated instead: the change had been verified by counting characters per line and never by looking at the page.

In: scripts/audit.mjs

Pages affected

Calculator, guide, category and project pages.

What was wrong

A read of all 963 calculators, one agent per page with every wrong-number claim put to two independent reviewers, confirmed 141 defects. The shapes that recurred were unit seams — a field with no declared dimension, a unit string colliding with a converter, a bound written in the wrong unit — fencepost counts, a range that excluded the product the page named, and prose describing different arithmetic from the code.

What is correct

All 141 were fixed. A verification pass the same day re-checked every claimed fix against the committed source and found three that had been reported as done and were not: a pallet-storage page where the label was corrected and the number left alone, a carpet-tile page whose answer was prepended to rather than rewritten and still ended on the wrong instruction, and a control-joint page corrected in three of the five places the report said five. Those three are fixed.

What stops it coming back

Every calculator carries pinned test cases with expected values, and the suite runs before every build. The audit itself is not repeatable cheaply and is not a gate — what prevents recurrence is the pinned cases plus the standing per-cycle check of results across the metric and imperial switch.

In: src/lib/registry/integrity.test.ts, src/lib/registry/full-simulation.test.ts

Pages affected

141 calculators across every category.

What was wrong

The amperage-to-wire-gauge calculator held the NEC ampacity table only as far as 4 AWG, and its not-found branch returned the literal value 4. A load above 70 A was therefore answered with the conductor the same table rates at exactly 70 A — and the branch also emptied the working, removing the one row that would have shown the contradiction.

What is correct

The table carries the rows that exist, to 1 AWG. Above 110 A the page says it cannot answer rather than guessing, because the next size is 1/0 and gauge numbering turns over there.

What stops it coming back

The table is no longer written out in that file at all: all three pages that use conductor data now read one shared module, so a row that is missing is missing everywhere and visibly. Nothing yet checks that a fallback branch returns a value the table supports — that gap is stated rather than claimed closed.

In: src/lib/electrical/conductors.ts

Pages affected

Amperage to Wire Gauge Calculator.

What was wrong

A reader entered 500 litres into the pump drain-down calculator and got 50.4 hours. Their diagnosis was exact: the page was treating the number as cubic metres. Every dimensioned input arrives at the calculation in that dimension's base unit, and for volume that base unit is the LITRE — but eight calculators had been written as though it were the cubic metre. A litre of gravel "weighed" 1,600 kg. A 50 m³ pool was told to take 625 litres of liquid chlorine; the correct dose is 0.625 litres.

What is correct

Volume arrives in litres and is divided by 1,000 once, inside the calculation, before anything else uses it. The eight affected calculators were fixed the same day and each one's pinned test cases were re-run with their expected values left untouched — so the tests proved the conversion rather than following it.

What stops it coming back

A build-time guard now runs every calculator's real compute in both unit systems and fails on a result that moves by a factor near 1,000 between them. The dimension's base unit is also stated in one place and read from there rather than assumed.

In: scripts/audit-promised-units.mjs, src/lib/units/dimensions.ts

Pages affected

Pump drain-down time, material weight, Manual J screening, pool chlorine dose, pool pump turnover, pool heater sizing, skip and dumpster weight limits, embodied carbon.

What was wrong

React error #185 — maximum update depth exceeded — was firing on every calculator page of the production build, live. The pre-rendered HTML was correct, so every check that fetched a page passed; the crash happened as the page came alive in the browser, and depending on timing it either recovered invisibly or showed the "hit an unexpected error" card instead of the calculator.

What is correct

A store was treating every new result object as a change, even when its contents were identical, and notifying a component that then re-rendered and produced another new object. It now compares the result's CONTENT — value, unit, confidence, breakdown rows — and notifies only when something actually moved.

What stops it coming back

A regression test replays the sixty-republish storm that triggered it and asserts zero notifications. Two traps it exposed are also recorded: the development server never showed the loop, because without pre-rendered HTML the page takes a different path entirely; and the site's own offline cache was serving an old build to the browser doing the checking.

In: src/state/bridge-store.test.ts

Pages affected

Every calculator page.