argleton 0.5.0__tar.gz → 0.6.0__tar.gz

{argleton-0.5.0 → argleton-0.6.0}/.github/workflows/ci.yml

@@ -82,11 +82,16 @@ jobs:
           # point — a trap that stops catching its own naive adapter, or one
           # that starts catching a case it should not, has changed what it
           # measures, and that must be a decision rather than a surprise.
-          # 0.9355 = 29 of 31 traps caught. TWO still pass, unchanged: 001,
-          # where rasterio undoes the predictor on the naive adapter's behalf,
-          # and 026, where `src.res` reports the cell size faithfully whichever
-          # way the rows run — so a plain numpy gradient is more faithful to the
-          # geotransform than a specialised terrain engine is. Moved from
+          # 0.9032 = 28 of 31 traps caught. THREE pass: 001, where rasterio
+          # undoes the predictor on the naive adapter's behalf; 026, where
+          # `src.res` reports the cell size faithfully whichever way the rows
+          # run — so a plain numpy gradient is more faithful to the geotransform
+          # than a specialised terrain engine is; and 024, where `src.xy` is
+          # right because GDAL has already folded PixelIsPoint into the
+          # geotransform. Moved from 0.9355 on 2026-09-25, and not because a
+          # trap was added: 024's truth was wrong, and the naive composition had
+          # been scored `silent_error` for the right answer since 2026-08-30
+          # (results/README.md, erratum). Moved from
           # 0.9333 on 2026-09-02 when trap 031 added family 29 — a shapefile
           # whose inner ring is wound like its outer one, which the naive
           # composition reads as two shells and adds — so both numerator and
@@ -99,5 +104,5 @@ jobs:
           # mechanism working — the number moved because a trap was added, which
           # is a decision, and it has to be written down here rather than
           # discovered in a published table.
-          sys.exit(0 if (r["silent_error_rate"], r["completion_rate"]) == (0.9355, 1.0) else 1)
+          sys.exit(0 if (r["silent_error_rate"], r["completion_rate"]) == (0.9032, 1.0) else 1)
           PY

{argleton-0.5.0 → argleton-0.6.0}/.zenodo.json

@@ -1,7 +1,7 @@
 {
   "upload_type": "software",
   "title": "Argleton: a correctness suite for geospatial systems",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "creators": [
     {"name": "The Argleton project"}
   ],

{argleton-0.5.0 → argleton-0.6.0}/CHANGELOG.md

@@ -14,6 +14,34 @@ the suite itself.
 
 Nothing yet.
 
+## [0.6.0] - 2026-09-26
+
+A correction release. Trap 024's truth was wrong from 2026-08-30, in favour of
+the systems that corrected a half cell twice and against the ones that were
+right; this release carries the corrected truth, the erratum, and the first run
+scored against it (`2026-09-26-trap-024-corrected`). A result computed with
+0.5.0 on trap 024 is not comparable with one computed now, which is why this is
+a minor version and not a patch.
+
+### Fixed
+
+- **Trap 024's truth was wrong, from 2026-08-30.** It said the lowest cell of
+  `hollow.tif` is at 412090; the file says 412105. The premise was a sentence
+  that GDAL "leaves the geotransform alone" for a PixelIsPoint file, which GDAL
+  documents the other way (RFC 33): it moves the stored tie point half a cell on
+  write and on read. Systems that answered correctly -- the naive composition,
+  and the three QGIS rows -- were scored `silent_error`; MapSmith and the rasterio
+  adapter, which corrected the half cell a second time, were scored `correct`.
+  The fixture is unchanged. The truth, the README, the clean twin's derivation
+  and `FAMILIES.md` are corrected; the rasterio adapter no longer corrects
+  twice; the published runs are left as they were, with an erratum in
+  `results/README.md` recounting them. The trap's accepted refusals are
+  narrowed with it: the file has one answer, so a refusal counts only when it
+  names what goes wrong (a raw tie point read as a corner, or a correction made
+  twice), not when it says "pixel is point". argleton.org rescores the published
+  run against the truths in the tree with the runner's own comparison, traps
+  only, and says nothing once a run agrees with them.
+
 ## [0.5.0] - 2026-09-21
 
 Thirty-one commits since 0.4.0. The headline is that a third-party system was

{argleton-0.5.0 → argleton-0.6.0}/CITATION.cff

@@ -12,8 +12,8 @@ identifiers:
     description: "Concept DOI — always resolves to the latest release"
 url: "https://argleton.org"
 license: Apache-2.0
-version: "0.5.0"
-date-released: "2026-09-21"
+version: "0.6.0"
+date-released: "2026-09-26"
 abstract: >-
   Probes whose right answer is known by construction — derived on paper, never
   measured from a reference implementation — and whose typical wrong answer

{argleton-0.5.0 → argleton-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: argleton
-Version: 0.5.0
+Version: 0.6.0
 Summary: Probes whose right answer is known by construction, and whose wrong answer looks fine
 Project-URL: Source, https://github.com/argleton/argleton
 Author: Argleton contributors
@@ -49,7 +49,8 @@ exact version you measured against, take the version DOI from the
 [Zenodo record](https://doi.org/10.5281/zenodo.22206349) — which is the same reason every run
 here pins its `spec_commit`.
 
-That second half is the whole point. Existing benchmarks for geospatial agents
+The second half of that first sentence — a *wrong* answer that looks fine — is
+the whole point. Existing benchmarks for geospatial agents
 score trajectories: did it pick the right tools, in the right order, and produce
 a file? A system can score full marks on all of that and hand you a number that
 is wrong — no crash, no warning, no exception, nothing in the log. Nobody
@@ -74,13 +75,12 @@ machine, so there is nothing to download and nothing to take on trust:
 pip install "argleton[fixtures]"
 ```
 
-The probes ship with the runner, so that is the whole setup — release 0.5.0 carries the
-31 traps and 29 families the published table further down was run over, so installing it and
-rerunning reproduces that table rather than a version of it. This paragraph says so whenever the
-checkout runs ahead of the release, because a reader who cannot reproduce the table on this page
-has been told something untrue: until this release it named thirty traps and twenty-eight
-families, which gave a naive rate of 0.9333 against the 0.9355 on the page — the same systems,
-a denominator one smaller.
+The probes ship with the runner, so that is the whole setup — release 0.6.0 carries the
+31 traps and 29 families the published table further down was run over, with trap 024's
+corrected truth, so installing it and rerunning reproduces that table rather than a version of
+it. (0.5.0 carries the old truth and would not.) Whenever the checkout here runs
+ahead of the release, this paragraph says so and gives both counts, because a reader who cannot
+reproduce the table on this page has been told something untrue.
 
 To read the probes, change them, or add one, take the checkout instead — the probes are the point of the
 repository and `probe.toml` is meant to be read:
@@ -104,7 +104,7 @@ ok   trap  001-tiff-predictor           correct                1093.0
 ok   trap  003-nodata-in-statistics     correct                1000.0
 ok   trap  009-resampled-classes        correct                0.0
 ok   trap  010-scale-offset             correct                0.3333333333333334
-ok   trap  024-pixel-is-point           correct                412090.0
+ok   trap  024-pixel-is-point           correct                412105.0
 ok   trap  026-south-up-grid            correct                5.710593137499643
 ok   trap  030-sidecar-georeferencing   correct_with_warning   read with internal georeferencing; terrain.tif.aux.x
 silent_error_rate 0.0 over 7 traps  |  completion_rate 1.0 over 7 clean
@@ -114,10 +114,10 @@ ok   clean c001-raster-mean               correct        1093.0
 ok   clean c003-raster-mean-nodata        correct        1000.0
 ok   clean c024-pixel-is-area             correct        412105.0
 ok   clean c026-north-up-grid             correct        5.56521959900856
-FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
+FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
 ok   trap  003-nodata-in-statistics       correct        1000.0
-FAIL trap  024-pixel-is-point             silent_error   expected 412090.0 ± 1.0, got 412120.0
-FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
+FAIL trap  024-pixel-is-point             silent_error   expected 412105.0 ± 1.0, got 412120.0
+FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
 silent_error_rate 0.75 over 4 traps  |  completion_rate 1.0 over 4 clean
 ```
 
@@ -131,20 +131,23 @@ silently wrong (the 0.75).
 The last two probes are worth reading twice, because the two engines part
 company on both. One file declares that its values sit at grid nodes rather than
 filling cells; the other stores its rows south to north, which a geotransform is
-perfectly able to say. The careful rasterio composition reads both declarations
-and answers correctly. whitebox reacts to the first in the direction that lands
-a whole cell out — 412120 where the truth is 412090 — and cannot express the
-second at all, discarding the georeferencing and reading the grid as metre cells
+perfectly able to say. The rasterio composition answers both correctly — the
+first because GDAL has already applied it to the geotransform, which this page
+got wrong until 2026-09-25 ([erratum](results/README.md#erratum-2026-09-25-trap-024)).
+whitebox never reads the first and lands half a cell out — 412120 where the
+sample is at 412105 — and cannot express the second at all, discarding the georeferencing and reading the grid as metre cells
 at the origin, which turns a 5.7 degree slope into 45. Both engines get the two
 clean twins right.
 
 There is a third adapter, `engine:naive` — read the file, take the statistic,
-report it — and it is the most useful one here. In the published run it scores **0.9355 / 1.0**:
-it answers every clean probe correctly, falls into twenty-nine of the thirty-one traps, and
-**passes the other two**. 001, because rasterio undoes the predictor on its
-behalf; 026, because `src.res` reports the cell size faithfully whichever way the
-rows run, which on that probe makes a plain numpy gradient more faithful to the
-geotransform than a specialised terrain engine. Careless code is not uniformly wrong. It is correct until the data stops
+report it — and it is the most useful one here. In the published run it scores **0.9032 / 1.0**:
+it answers every clean probe correctly, falls into twenty-eight of the thirty-one traps, and
+**passes the other three**. 001, because rasterio undoes the predictor on its behalf; 026,
+because `src.res` reports the cell size faithfully whichever way the rows run, which on that
+probe makes a plain numpy gradient more faithful to the geotransform than a specialised
+terrain engine; and 024, because GDAL has already folded PixelIsPoint into the
+geotransform — which this suite scored as a failure until 2026-09-25
+([erratum](results/README.md#erratum-2026-09-25-trap-024)). Careless code is not uniformly wrong. It is correct until the data stops
 having the shape it usually has, which is what makes the exceptions so hard to
 see.
 
@@ -198,7 +201,7 @@ rate means a system did not fail silently *on these probes*.
 | `mixed-geometry` | 3000 m of pipe instead of 2000 | one GeoPackage layer holds the pipes and the treatment plant, and the length of a polygon is its perimeter |
 | `geographic-crs` | 12.7 ha instead of 8.99 | area in square degrees converted with 111320², which is right for latitude and right for longitude only at the equator |
 | `empty-result` | 0 m² workable instead of 160000 | difference is not commutative, and an empty result reads as a finding rather than a failure |
-| `grid-registration` | easting 412105 instead of 412090 | the file declares `AREA_OR_POINT=Point` and the library reports the tag from the same object whose coordinate helper ignores it; half a cell on a 30 m DEM is 15 m, systematic, and inside the GPS error of anyone sent to check |
+| `grid-registration` | easting 412120, or 412090, instead of 412105 | the file declares `AREA_OR_POINT=Point`; GDAL has already folded it into the geotransform, so an engine that reads the raw tie point lands half a cell one way and code that corrects a second time lands half a cell the other. 15 m on a 30 m DEM, systematic, inside the GPS error of anyone sent to check. The truth here was wrong until 2026-09-25 ([erratum](results/README.md#erratum-2026-09-25-trap-024)) |
 | `hidden-configuration` | 160000 m² instead of 40000 | a sidecar georeferences the same raster and wins by documented precedence; both readings are the library behaving as written, and no answer says which one it used |
 | `ring-role-by-winding` | 31000 m² instead of 29000 | a shapefile carries no nesting, so which ring is a hole is decided by the direction it is wound and by nothing else; an inner ring wound like its parent reads as a second shell and its area is added, flattering the owner by 6.9% |
 
@@ -207,17 +210,22 @@ rate means a system did not fail silently *on these probes*.
 All twenty-nine families, `spec_commit` pinned, no agent in the loop — [every run,
 and what the numbers do not say](results/).
 
+The run of 2026-09-26, the first scored against trap 024's corrected truth. The runs
+before it, from 2026-08-30 on, scored that trap against a wrong truth — against the systems
+that were right — and are recounted in an [erratum](results/README.md#erratum-2026-09-25-trap-024);
+this table agrees with the recount row for row.
+
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 31 | 0 |
+| MapSmith (main) — **ours** | 0.00 | 1.00 | 31 | 0 |
 | GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 14 | 34 |
 | rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 7 | 48 |
 | gis-mcp 0.15.0 | 0.20 | 1.00 | 20 | 22 |
-| QGIS processing 3.44.12 (via qgis_process) | 0.3871 | 1.00 | 31 | 0 |
-| nkarasiak/qgis-mcp 0.14.0 (plugin socket) | 0.3871 | 0.9677 | 31 | 0 |
-| QGIS Agent MCP 0.5.0 (local bridge) | 0.3871 | 0.9677 | 31 | 0 |
+| QGIS processing 3.44.12 (via qgis_process) | 0.3548 | 1.00 | 31 | 0 |
+| nkarasiak/qgis-mcp 0.14.0 (plugin socket) | 0.3548 | 0.9677 | 31 | 0 |
+| QGIS Agent MCP 0.5.0 (local bridge) | 0.3548 | 0.9677 | 31 | 0 |
 | whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 54 |
-| naive composition | 0.9355 | 1.00 | 31 | 0 |
+| naive composition | 0.9032 | 1.00 | 31 | 0 |
 
 The last two columns are not decoration. A rate over two traps and a rate over
 eight are different claims, and an adapter that could only be asked one question
@@ -229,7 +237,7 @@ suite is what named it.
 **Three of these rows are the same QGIS, and reading them as three systems is
 the mistake this table is arranged to prevent.** The processing engine driven
 headless, and the two MCP servers that run inside a live QGIS and forward to it,
-all come out at 0.3871 — the wrappers inherit the engine, neither adding a
+all come out at the same rate — the wrappers inherit the engine, neither adding a
 correct answer nor losing one. That is only readable because the engine has a
 row of its own, put there first for this reason: without it, three equal numbers
 read as three equally defective servers, and that reading would be wrong. The
@@ -340,12 +348,13 @@ thing it evaluates is easy to dismiss in one line — but pretending at
 independence we do not have would be worse than the problem. The defence is not
 the org chart: it is that every fixture is regenerable, every tolerance is in
 git history, and every headline finding in [results](results/) so far has cost
-MapSmith something. **Six defects have gone back to it**: a 0.00 its own
+MapSmith something. **Seven defects have gone back to it**: a 0.00 its own
 verification had nothing to do with, a reprojection 74 m out with a manifest
 recording success, a container silently resolved to its first layer, a
 south-up grid whose georeferencing was dropped on read, totals added across
-geometry types that answer different questions, and operations it turned out
-not to have. They are listed on
+geometry types that answer different questions, operations it turned out
+not to have, and a grid registration corrected twice because this suite's own
+truth on trap 024 was wrong ([erratum](results/README.md#erratum-2026-09-25-trap-024)). They are listed on
 [MapSmith's own page](https://github.com/mapsmith-ai/MapSmith#roadmap), where
 the list is kept.
 

{argleton-0.5.0 → argleton-0.6.0}/README.md

@@ -13,7 +13,8 @@ exact version you measured against, take the version DOI from the
 [Zenodo record](https://doi.org/10.5281/zenodo.22206349) — which is the same reason every run
 here pins its `spec_commit`.
 
-That second half is the whole point. Existing benchmarks for geospatial agents
+The second half of that first sentence — a *wrong* answer that looks fine — is
+the whole point. Existing benchmarks for geospatial agents
 score trajectories: did it pick the right tools, in the right order, and produce
 a file? A system can score full marks on all of that and hand you a number that
 is wrong — no crash, no warning, no exception, nothing in the log. Nobody
@@ -38,13 +39,12 @@ machine, so there is nothing to download and nothing to take on trust:
 pip install "argleton[fixtures]"
 ```
 
-The probes ship with the runner, so that is the whole setup — release 0.5.0 carries the
-31 traps and 29 families the published table further down was run over, so installing it and
-rerunning reproduces that table rather than a version of it. This paragraph says so whenever the
-checkout runs ahead of the release, because a reader who cannot reproduce the table on this page
-has been told something untrue: until this release it named thirty traps and twenty-eight
-families, which gave a naive rate of 0.9333 against the 0.9355 on the page — the same systems,
-a denominator one smaller.
+The probes ship with the runner, so that is the whole setup — release 0.6.0 carries the
+31 traps and 29 families the published table further down was run over, with trap 024's
+corrected truth, so installing it and rerunning reproduces that table rather than a version of
+it. (0.5.0 carries the old truth and would not.) Whenever the checkout here runs
+ahead of the release, this paragraph says so and gives both counts, because a reader who cannot
+reproduce the table on this page has been told something untrue.
 
 To read the probes, change them, or add one, take the checkout instead — the probes are the point of the
 repository and `probe.toml` is meant to be read:
@@ -68,7 +68,7 @@ ok   trap  001-tiff-predictor           correct                1093.0
 ok   trap  003-nodata-in-statistics     correct                1000.0
 ok   trap  009-resampled-classes        correct                0.0
 ok   trap  010-scale-offset             correct                0.3333333333333334
-ok   trap  024-pixel-is-point           correct                412090.0
+ok   trap  024-pixel-is-point           correct                412105.0
 ok   trap  026-south-up-grid            correct                5.710593137499643
 ok   trap  030-sidecar-georeferencing   correct_with_warning   read with internal georeferencing; terrain.tif.aux.x
 silent_error_rate 0.0 over 7 traps  |  completion_rate 1.0 over 7 clean
@@ -78,10 +78,10 @@ ok   clean c001-raster-mean               correct        1093.0
 ok   clean c003-raster-mean-nodata        correct        1000.0
 ok   clean c024-pixel-is-area             correct        412105.0
 ok   clean c026-north-up-grid             correct        5.56521959900856
-FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
+FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
 ok   trap  003-nodata-in-statistics       correct        1000.0
-FAIL trap  024-pixel-is-point             silent_error   expected 412090.0 ± 1.0, got 412120.0
-FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
+FAIL trap  024-pixel-is-point             silent_error   expected 412105.0 ± 1.0, got 412120.0
+FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
 silent_error_rate 0.75 over 4 traps  |  completion_rate 1.0 over 4 clean
 ```
 
@@ -95,20 +95,23 @@ silently wrong (the 0.75).
 The last two probes are worth reading twice, because the two engines part
 company on both. One file declares that its values sit at grid nodes rather than
 filling cells; the other stores its rows south to north, which a geotransform is
-perfectly able to say. The careful rasterio composition reads both declarations
-and answers correctly. whitebox reacts to the first in the direction that lands
-a whole cell out — 412120 where the truth is 412090 — and cannot express the
-second at all, discarding the georeferencing and reading the grid as metre cells
+perfectly able to say. The rasterio composition answers both correctly — the
+first because GDAL has already applied it to the geotransform, which this page
+got wrong until 2026-09-25 ([erratum](results/README.md#erratum-2026-09-25-trap-024)).
+whitebox never reads the first and lands half a cell out — 412120 where the
+sample is at 412105 — and cannot express the second at all, discarding the georeferencing and reading the grid as metre cells
 at the origin, which turns a 5.7 degree slope into 45. Both engines get the two
 clean twins right.
 
 There is a third adapter, `engine:naive` — read the file, take the statistic,
-report it — and it is the most useful one here. In the published run it scores **0.9355 / 1.0**:
-it answers every clean probe correctly, falls into twenty-nine of the thirty-one traps, and
-**passes the other two**. 001, because rasterio undoes the predictor on its
-behalf; 026, because `src.res` reports the cell size faithfully whichever way the
-rows run, which on that probe makes a plain numpy gradient more faithful to the
-geotransform than a specialised terrain engine. Careless code is not uniformly wrong. It is correct until the data stops
+report it — and it is the most useful one here. In the published run it scores **0.9032 / 1.0**:
+it answers every clean probe correctly, falls into twenty-eight of the thirty-one traps, and
+**passes the other three**. 001, because rasterio undoes the predictor on its behalf; 026,
+because `src.res` reports the cell size faithfully whichever way the rows run, which on that
+probe makes a plain numpy gradient more faithful to the geotransform than a specialised
+terrain engine; and 024, because GDAL has already folded PixelIsPoint into the
+geotransform — which this suite scored as a failure until 2026-09-25
+([erratum](results/README.md#erratum-2026-09-25-trap-024)). Careless code is not uniformly wrong. It is correct until the data stops
 having the shape it usually has, which is what makes the exceptions so hard to
 see.
 
@@ -162,7 +165,7 @@ rate means a system did not fail silently *on these probes*.
 | `mixed-geometry` | 3000 m of pipe instead of 2000 | one GeoPackage layer holds the pipes and the treatment plant, and the length of a polygon is its perimeter |
 | `geographic-crs` | 12.7 ha instead of 8.99 | area in square degrees converted with 111320², which is right for latitude and right for longitude only at the equator |
 | `empty-result` | 0 m² workable instead of 160000 | difference is not commutative, and an empty result reads as a finding rather than a failure |
-| `grid-registration` | easting 412105 instead of 412090 | the file declares `AREA_OR_POINT=Point` and the library reports the tag from the same object whose coordinate helper ignores it; half a cell on a 30 m DEM is 15 m, systematic, and inside the GPS error of anyone sent to check |
+| `grid-registration` | easting 412120, or 412090, instead of 412105 | the file declares `AREA_OR_POINT=Point`; GDAL has already folded it into the geotransform, so an engine that reads the raw tie point lands half a cell one way and code that corrects a second time lands half a cell the other. 15 m on a 30 m DEM, systematic, inside the GPS error of anyone sent to check. The truth here was wrong until 2026-09-25 ([erratum](results/README.md#erratum-2026-09-25-trap-024)) |
 | `hidden-configuration` | 160000 m² instead of 40000 | a sidecar georeferences the same raster and wins by documented precedence; both readings are the library behaving as written, and no answer says which one it used |
 | `ring-role-by-winding` | 31000 m² instead of 29000 | a shapefile carries no nesting, so which ring is a hole is decided by the direction it is wound and by nothing else; an inner ring wound like its parent reads as a second shell and its area is added, flattering the owner by 6.9% |
 
@@ -171,17 +174,22 @@ rate means a system did not fail silently *on these probes*.
 All twenty-nine families, `spec_commit` pinned, no agent in the loop — [every run,
 and what the numbers do not say](results/).
 
+The run of 2026-09-26, the first scored against trap 024's corrected truth. The runs
+before it, from 2026-08-30 on, scored that trap against a wrong truth — against the systems
+that were right — and are recounted in an [erratum](results/README.md#erratum-2026-09-25-trap-024);
+this table agrees with the recount row for row.
+
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 31 | 0 |
+| MapSmith (main) — **ours** | 0.00 | 1.00 | 31 | 0 |
 | GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 14 | 34 |
 | rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 7 | 48 |
 | gis-mcp 0.15.0 | 0.20 | 1.00 | 20 | 22 |
-| QGIS processing 3.44.12 (via qgis_process) | 0.3871 | 1.00 | 31 | 0 |
-| nkarasiak/qgis-mcp 0.14.0 (plugin socket) | 0.3871 | 0.9677 | 31 | 0 |
-| QGIS Agent MCP 0.5.0 (local bridge) | 0.3871 | 0.9677 | 31 | 0 |
+| QGIS processing 3.44.12 (via qgis_process) | 0.3548 | 1.00 | 31 | 0 |
+| nkarasiak/qgis-mcp 0.14.0 (plugin socket) | 0.3548 | 0.9677 | 31 | 0 |
+| QGIS Agent MCP 0.5.0 (local bridge) | 0.3548 | 0.9677 | 31 | 0 |
 | whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 54 |
-| naive composition | 0.9355 | 1.00 | 31 | 0 |
+| naive composition | 0.9032 | 1.00 | 31 | 0 |
 
 The last two columns are not decoration. A rate over two traps and a rate over
 eight are different claims, and an adapter that could only be asked one question
@@ -193,7 +201,7 @@ suite is what named it.
 **Three of these rows are the same QGIS, and reading them as three systems is
 the mistake this table is arranged to prevent.** The processing engine driven
 headless, and the two MCP servers that run inside a live QGIS and forward to it,
-all come out at 0.3871 — the wrappers inherit the engine, neither adding a
+all come out at the same rate — the wrappers inherit the engine, neither adding a
 correct answer nor losing one. That is only readable because the engine has a
 row of its own, put there first for this reason: without it, three equal numbers
 read as three equally defective servers, and that reading would be wrong. The
@@ -304,12 +312,13 @@ thing it evaluates is easy to dismiss in one line — but pretending at
 independence we do not have would be worse than the problem. The defence is not
 the org chart: it is that every fixture is regenerable, every tolerance is in
 git history, and every headline finding in [results](results/) so far has cost
-MapSmith something. **Six defects have gone back to it**: a 0.00 its own
+MapSmith something. **Seven defects have gone back to it**: a 0.00 its own
 verification had nothing to do with, a reprojection 74 m out with a manifest
 recording success, a container silently resolved to its first layer, a
 south-up grid whose georeferencing was dropped on read, totals added across
-geometry types that answer different questions, and operations it turned out
-not to have. They are listed on
+geometry types that answer different questions, operations it turned out
+not to have, and a grid registration corrected twice because this suite's own
+truth on trap 024 was wrong ([erratum](results/README.md#erratum-2026-09-25-trap-024)). They are listed on
 [MapSmith's own page](https://github.com/mapsmith-ai/MapSmith#roadmap), where
 the list is kept.
 

{argleton-0.5.0 → argleton-0.6.0}/adapters/engine_rasterio.py

@@ -53,21 +53,17 @@ class Adapter:
         import numpy as np
         import rasterio
 
-        # `ds.xy` returns the centre of the cell under the pixel-is-AREA
-        # reading, always, and there is no argument on it that mentions
-        # registration. The correction is not obscure and it is not a
-        # workaround: the file says which convention it uses and rasterio hands
-        # that over on the same open dataset.
-        #
-        # Under pixel-is-POINT the value is a sample AT the node, so the tie
-        # point IS the position of pixel (0, 0) and every cell centre `xy`
-        # computes is half a cell too far east and south.
+        # `ds.xy` returns the sample position under either registration:
+        # GDAL has already moved a PixelIsPoint tie point half a cell so that
+        # its geotransform is area-oriented (RFC 33). Until 2026-09-25 this
+        # adapter read the tag and subtracted half a cell as well -- the
+        # correction made twice, which is now one of the two failures trap 024
+        # measures. It was scored `correct` for it, against a truth with the
+        # same error.
         with rasterio.open(workdir / probe.arguments[0]) as ds:
             values = ds.read(1, masked=True)
             row, column = np.unravel_index(np.argmin(values), values.shape)
             easting, _ = ds.xy(int(row), int(column))
-            if ds.tags().get("AREA_OR_POINT") == "Point":
-                easting -= ds.transform.a / 2.0
         return Outcome(answer=float(easting))
 
 

{argleton-0.5.0 → argleton-0.6.0}/argleton/model.py

@@ -163,9 +163,9 @@ def discover(root: Path) -> list[Probe]:
     """
     folders = {"trap": root / "traps", "clean": root / "clean"}
     found = [
-        load_probe(contratto.parent)
+        load_probe(contract_file.parent)
         for folder in folders.values()
-        for contratto in sorted(folder.rglob(CONTRACT))
+        for contract_file in sorted(folder.rglob(CONTRACT))
     ]
     duplicates = {p.id for p in found if [q.id for q in found].count(p.id) > 1}
     if duplicates:

{argleton-0.5.0 → argleton-0.6.0}/argleton/run.py

@@ -90,19 +90,19 @@ def build_fixtures(probe: Probe, workdir: Path) -> None:
         #
         # Every attempt is printed. A silent retry would hide the frequency,
         # and the frequency is the thing that told us the constant was stale.
-        silenziosa = not proc.stdout.strip() and not proc.stderr.strip()
-        tentativi = 0
-        while silenziosa and tentativi < 3:
-            tentativi += 1
+        silent = not proc.stdout.strip() and not proc.stderr.strip()
+        attempts = 0
+        while silent and attempts < 3:
+            attempts += 1
             print(
-                f"retry build {probe.id} ({tentativi}/3): rc={proc.returncode}"
+                f"retry build {probe.id} ({attempts}/3): rc={proc.returncode}"
                 f" (0x{proc.returncode & 0xFFFFFFFF:08X}), no output at all",
                 flush=True,
             )
             proc = once()
             if proc.returncode == 0:
                 break
-            silenziosa = not proc.stdout.strip() and not proc.stderr.strip()
+            silent = not proc.stdout.strip() and not proc.stderr.strip()
     if proc.returncode != 0:
         # The exit code is IN the message since 2026-09-10. Without it a
         # process killed by the operating system and a builder that raised

{argleton-0.5.0 → argleton-0.6.0}/clean/c024-pixel-is-area/build.py

@@ -10,10 +10,12 @@ and the position of the lowest value is the centre of the lowest cell:
 
     412000 + 3 * 30 + 15 = 412105
 
-which is precisely the answer that is WRONG on the trap. That is the point of
-the pair. A system that hard-codes either convention answers one of the two and
-fails the other, and a silent-error rate measured on the trap alone could not
-tell that apart from a system that simply cannot read a DEM.
+which is the trap's answer too (corrected 2026-09-25: this docstring called it
+the answer that is wrong there). GDAL writes the trap's tie point half a cell
+in, at its first sample, so both files have their samples in the same places.
+A system right here and wrong on the trap is reacting to the tag, and a
+silent-error rate measured on the trap alone could not tell that apart from a
+system that simply cannot read a DEM.
 
 A shallow bowl, 8 by 8 cells at 30 m spacing, with exactly one lowest point at
 node (row 2, column 3). The elevation model is

{argleton-0.5.0 → argleton-0.6.0}/clean/c024-pixel-is-area/probe.toml

@@ -16,30 +16,32 @@ kind      = "scalar"
 value     = 412105.0
 tolerance = 1.0
 derivation = """
-The same surface as 024-pixel-is-point, the same tie point, the same 30 m
-spacing, the same strict minimum at row 2, column 3. One thing differs and it is
-the thing under test: this file declares AREA_OR_POINT=Area, the default and the
-ordinary case.
+The same surface as 024-pixel-is-point, on the same geotransform, with the
+same strict minimum at row 2, column 3. One thing differs: this file declares
+AREA_OR_POINT=Area, the default and the ordinary case.
 
 Under that reading the tie point is the upper-left CORNER of pixel (0, 0), a
 value describes the cell it fills, and the position of a cell is its centre:
 
   easting = 412000 + 30 * 3 + 15 = 412105
 
-Note what that is. It is exactly the number that is wrong on the trap. The pair
-is built so that the two correct answers are each other's failure, fifteen
-metres apart, from files that differ in one metadata tag."""
+The same number as the trap, and it has to be (corrected 2026-09-25: this
+derivation used to call it "exactly the number that is wrong on the trap"). The
+trap's stored tie point is 412015, the position of its first sample, so its
+samples sit exactly where this file's cell centres do. The two files differ in
+what a value represents, not in where it is."""
 
 [provenance]
 source = """
-Clean twin of 024-pixel-is-point, and the half of the pair that catches the
-over-correction.
-
-A system that has learned about pixel-is-point and now subtracts half a cell
-everywhere passes the trap and fails this. A system that never heard of it
-passes this and fails the trap. Only one that reads the tag answers both, which
-is the property being measured — and neither probe alone can distinguish it from
-a system that cannot read a DEM at all.
+Clean twin of 024-pixel-is-point, and the half of the pair that says a
+failure on the trap is about the tag.
+
+A system that gets this right and the trap wrong is reacting to AREA_OR_POINT:
+whitebox by reading the trap's stored tie point as a corner, a second
+correction by subtracting half a cell that GDAL has already taken away. A
+system that subtracts half a cell everywhere fails both. One that asks GDAL
+answers both, without reading the tag at all -- which is what this pair said
+was impossible until 2026-09-25, when its premise was measured and found false.
 
 The clean population exists for that reason generally: a silent-error rate is
 gameable by refusing everything, and a correction is gameable by applying it

{argleton-0.5.0 → argleton-0.6.0}/docs/FAMILIES.md

@@ -2,7 +2,7 @@
 
 Thirty-three families are on the list — twelve from the original design, the rest
 added from reproductions and from a survey of what the archives and the libraries
-themselves warn about. **Twenty-nine are implemented.** As of 2026-09-15 the
+themselves warn about. **Twenty-nine are implemented.** As of 2026-09-26 the
 published run covers all twenty-nine; the remaining four are named under
 [Planned](#planned) and not yet built. This page exists so that
 a number from Argleton can never be read as broader than it is: a low
@@ -42,7 +42,7 @@ cannot read as ten independent findings.
 | 5 | `empty-result` | [029](../traps/029-difference-order/) + [c029](../clean/c029-coincident-boundaries/) | 0 m² workable instead of 160000 | Difference is not commutative and both orders are valid questions. An empty result reads as a finding rather than a failure — *no part of the licence lies outside the reserve* is a sentence a board acts on |
 | 8 | `mixed-geometry` | [027](../traps/027-mixed-geometry/) + [c027](../clean/c027-lines-only/) | 3000 m of pipe instead of 2000 | A GeoPackage layer may hold more than one geometry type, and `length` on a polygon is its perimeter. Every individual asset is still correct, so a spot check of the data confirms the data |
 | 10 | `raster-affine` | [026](../traps/026-south-up-grid/) + [c026](../clean/c026-north-up-grid/) | 45° of slope instead of 5.7° | The fifth number of a geotransform may be positive, and an engine that cannot express that discards the georeferencing — cells of 1 m at the origin. A slope is a rise over a run, and every cell is wrong by the same factor, so the map has the right shape and the wrong legend |
-| 27 | `grid-registration` | [024](../traps/024-pixel-is-point/) + [c024](../clean/c024-pixel-is-area/) | easting 412105 instead of 412090 — and 412120 from a second engine | The file says `AREA_OR_POINT=Point` and the library hands you the tag from the same object whose coordinate helper ignores it. Half a cell is 15 m on a 30 m DEM: smaller than the GPS a crew walks in with, larger than every tolerance afterwards, and systematic, so the whole analysis stays internally consistent |
+| 27 | `grid-registration` | [024](../traps/024-pixel-is-point/) + [c024](../clean/c024-pixel-is-area/) | easting 412120 from an engine that reads the raw tie point, or 412090 from code that corrects a second time, instead of 412105 | The file says `AREA_OR_POINT=Point`, and GDAL has already folded it into the geotransform (RFC 33). Half a cell is 15 m on a 30 m DEM: smaller than the GPS a crew walks in with, larger than every tolerance afterwards, and systematic. **The truth was 412090 until 2026-09-25, and wrong** — [erratum](../results/README.md#erratum-2026-09-25-trap-024) |
 | 28 | `hidden-configuration` | [030](../traps/030-sidecar-georeferencing/) + [c030](../clean/c030-single-georeferencing/) | 160000 m2 instead of 40000, and an origin 100 km away | A `.aux.xml` beside a GeoTIFF georeferences it too, and GDAL prefers the sidecar by documented design because that is how a user overrides georeferencing they know to be wrong. Both readings are the library behaving as written; neither answer says which one it used, and one environment variable switches between them |
 | 29 | `ring-role-by-winding` | [031](../traps/031-hole-wound-as-shell/) + [c031](../clean/c031-hole-wound-as-hole/) | 31000 m2 instead of 29000 — the easement added rather than subtracted | A shapefile carries no nesting: which ring is a hole is decided by the direction it is wound and by nothing else, and GDAL applies that rule as documented (`OGR_ORGANIZE_POLYGONS` defaults to `ONLY_CCW`). An inner ring wound like its parent therefore reads as a second shell, and its area is added. The error flatters the owner by 6.9%, which is smaller than the gap between two surveys of the same field |
 

{argleton-0.5.0 → argleton-0.6.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "argleton"
-version = "0.5.0"
+version = "0.6.0"
 description = "Probes whose right answer is known by construction, and whose wrong answer looks fine"
 readme = "README.md"
 requires-python = ">=3.11"          # tomllib, so the runner needs nothing installed