argleton 0.4.0__tar.gz → 0.5.0__tar.gz

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

@@ -82,13 +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.9333 = 28 of 30 traps caught. TWO still pass, unchanged: 001,
+          # 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.931
-          # on 2026-08-31 when trap 030 added family 28: the naive adapter falls
-          # into it, so both numerator and denominator went up by one. Before
+          # geotransform than a specialised terrain engine is. 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
+          # denominator went up by one. Before that 0.931 on 2026-08-31 when
+          # trap 030 added family 28, the same way. Before
           # that 0.96 when traps 026 to 029 closed the original family list, and
           # 0.9583, 0.9565 and 0.9545 as traps 025, 024 and 023 landed.
           # Each time the denominator changed and the numerator changed with
@@ -96,5 +99,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.9333, 1.0) else 1)
+          sys.exit(0 if (r["silent_error_rate"], r["completion_rate"]) == (0.9355, 1.0) else 1)
           PY

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

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

argleton-0.5.0/CHANGELOG.md

@@ -0,0 +1,111 @@
+# Changelog
+
+All notable changes to Argleton are documented here, in the format of
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/). This project follows
+[semantic versioning](https://semver.org/).
+
+This file starts at 0.5.0. Releases before it are described by their tags and
+by the dated sections of [`results/README.md`](results/README.md), which is
+where this project's findings have always been written — the omission was that
+a reader had nowhere to see, in one place, what changed between two versions of
+the suite itself.
+
+## [Unreleased]
+
+Nothing yet.
+
+## [0.5.0] - 2026-09-21
+
+Thirty-one commits since 0.4.0. The headline is that a third-party system was
+measured against the engine it wraps, for the first time, and the result is
+that the wrapper is not the thing to blame.
+
+### Added
+
+- **Three QGIS rows, and they are the same QGIS.** The processing engine driven
+  headless through `qgis_process`, and the two MCP servers that run inside a
+  live QGIS and forward to it — `nkarasiak/qgis-mcp` 0.14.0 over its plugin
+  socket, QGIS Agent MCP 0.5.0 over its local bridge. All three answer **every
+  one of the thirty-one traps**, nothing unsupported, and all three come out at
+  the same silent-error rate of **0.3871**.
+
+  That equality is the finding, and it is only readable because the engine has
+  a row of its own: the wrappers inherit it, neither adding a correct answer
+  nor losing one. Without the engine's row, three equal numbers read as three
+  equally defective servers, and that reading would be wrong. The engine's row
+  was built first for exactly this reason.
+
+  The chains are shared by all three adapters in one file, so a difference
+  between the rows can only come from the system rather than from a chain that
+  drifted between copies.
+
+- **`gis-mcp` 0.15.0**, the first system here whose defects are not ours to
+  fix, published on 2026-09-10 after its maintainer was told first.
+
+- **Family 29, `ring-role-by-winding`.** 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: 31000 m² where the truth is 29000, +6.9% in the owner's
+  favour, with the right bounding box, the right CRS and no warning.
+
+### Changed
+
+- **`argleton.__version__` is derived instead of written.** It answered
+  `0.1.0.dev0` while 0.4.0 was on PyPI, across four releases, because the
+  number lived in two places and only one was on a checklist. Nothing inside
+  the package read it, so nothing caught it. It now comes from the installed
+  distribution, or from `pyproject.toml` when running from a checkout, and a
+  test compares the two.
+
+- **The naive baseline pin moves to 0.9355**, which is the pin doing its job
+  rather than a number being adjusted: the denominator grew when the suite
+  reached thirty-one traps.
+
+- **A fixture build that dies with no output is retried on its signature, not
+  on a count.** One retry had been calibrated against 370 builds, where a
+  doubled failure is about one in a thousand. At nine adapters and 558 builds
+  the same doubled failure is about one in twenty. The constant was not wrong
+  when it was written; it went wrong when the table grew, and nothing was
+  watching it. The retry now keys on what the death looks like — both output
+  streams empty, because the process never ran — which is stricter than what it
+  replaces: a builder that fails while saying something now fails on the first
+  attempt.
+
+### Fixed
+
+- **The site sorted both QGIS MCP servers below the naive baseline**, the row
+  that exists to be the worst line on the page, because neither matched a
+  prefix in the ordering list and an unmatched row sorts last. The comment
+  above that list had named their correct place two months earlier — beside
+  `gis-mcp`, with the engine they call directly underneath. A rule stated in a
+  comment and not executed by code is not a rule; a test covers it now.
+
+- **The site said "every system here completes every clean probe"** directly
+  under a column showing two systems that do not.
+
+- **Three surfaces said every number comes from calling code in the same
+  process rather than over a transport.** Two rows are a TCP socket and a local
+  bridge into a live QGIS, which is what their own labels say.
+
+- **The results page said we had "found nothing of its own" about one wrapper**,
+  seven lines after describing a property of that wrapper. The true sentence is
+  "nothing that makes an answer wrong", and the notification rule is restated
+  around it.
+
+- **"In opposite directions" described two rows with the same probe, the same
+  verdict and the same completion rate.** They differ in how they fail.
+
+- **`FAMILIES.md` published four false sentences about its own count** while
+  two guards on counts were green, because they watched three other sentence
+  shapes. The numbers are derived now, and an unexplained spelled-out number in
+  that file is a failure rather than a gap.
+
+- **The results index counts its own rows** instead of only checking the ones
+  that happen to be listed, and the tool count is asked of the server rather
+  than written down.
+
+- **`publish_run.py`** — in the private workspace, but its effects are here —
+  refuses to publish an adapter whose failures all carry one message: that is a
+  system we could not reach, not a system that got things wrong. A run was
+  minutes from publishing `completion 0.2258` for a third-party server whose
+  62 probes had all failed to connect.

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

@@ -5,10 +5,15 @@ type: software
 authors:
   - name: "The Argleton project"
 repository-code: "https://github.com/argleton/argleton"
+doi: "10.5281/zenodo.22206349"
+identifiers:
+  - type: doi
+    value: "10.5281/zenodo.22206349"
+    description: "Concept DOI — always resolves to the latest release"
 url: "https://argleton.org"
 license: Apache-2.0
-version: "0.4.0"
-date-released: "2026-08-31"
+version: "0.5.0"
+date-released: "2026-09-21"
 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.4.0 → argleton-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: argleton
-Version: 0.4.0
+Version: 0.5.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
@@ -42,6 +42,13 @@ known by construction, and every trap has a *wrong* answer that looks fine.
 **[argleton.org](https://argleton.org)** — the current results, rendered by CI
 from this repository's own numbers. Nothing on that page is typed in by hand.
 
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22206349.svg)](https://doi.org/10.5281/zenodo.22206349)
+
+Cite it as `10.5281/zenodo.22206349`, which always resolves to the current release. To cite the
+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
 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
@@ -67,10 +74,13 @@ 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.4.0 carries the
-30 traps and 28 families the results below were produced from. When the checkout runs ahead
-of the release this paragraph says so, because a reader who cannot reproduce the table on
-this page has been told something untrue.
+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.
 
 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:
@@ -83,19 +93,21 @@ pip install -e ".[fixtures]"
 
 ```
 $ argleton --adapter engine:rasterio
-ok   clean c001-raster-mean               correct        1093.0
-ok   clean c003-raster-mean-nodata        correct        1000.0
-ok   clean c009-native-resolution-classes correct        900.0
-ok   clean c010-physical-values           correct        0.5000000093132254
-ok   clean c024-pixel-is-area             correct        412105.0
-ok   clean c026-north-up-grid             correct        5.710593137499643
-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  026-south-up-grid              correct        5.710593137499643
-silent_error_rate 0.0 over 6 traps  |  completion_rate 1.0 over 6 clean
+ok   clean c001-raster-mean             correct                1093.0
+ok   clean c003-raster-mean-nodata      correct                1000.0
+ok   clean c009-native-resolution-classes correct                900.0
+ok   clean c010-physical-values         correct                0.5000000093132254
+ok   clean c024-pixel-is-area           correct                412105.0
+ok   clean c026-north-up-grid           correct                5.710593137499643
+ok   clean c030-single-georeferencing   correct_with_warning   read with internal georeferencing
+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  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
 
 $ argleton --adapter engine:whitebox
 ok   clean c001-raster-mean               correct        1093.0
@@ -127,8 +139,8 @@ 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. It scores **0.931 / 1.0**: it
-answers every clean probe correctly, falls into twenty-seven of the twenty-nine traps, and
+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
@@ -154,7 +166,7 @@ Side by side, one glance tells you which you are looking at.
 
 ## What is covered
 
-Twenty-eight families of twenty-eight, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
+Twenty-nine families of thirty-three, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
 number from here can never be read as broader than it is. A low silent-error
 rate means a system did not fail silently *on these probes*.
 
@@ -188,19 +200,24 @@ rate means a system did not fail silently *on these probes*.
 | `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 |
 | `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% |
 
 ## Results
 
-Engine tier, twenty-seven families — the published runs predate the twenty-eighth — `spec_commit` pinned — [every run, and what the
-numbers do not say](results/).
+All twenty-nine families, `spec_commit` pinned, no agent in the loop — [every run,
+and what the numbers do not say](results/).
 
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 29 | 0 |
-| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 13 | 32 |
-| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 6 | 46 |
-| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 50 |
-| naive composition | 0.931 | 1.00 | 29 | 0 |
+| MapSmith (main) | 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 |
+| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 54 |
+| naive composition | 0.9355 | 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
@@ -209,6 +226,33 @@ before this one, three of MapSmith's probes were `unsupported` — it had no are
 operation at all, which is a gap in a catalog rather than a bug in code, and the
 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
+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
+two completion rates below 1.00 are one clean probe that neither wrapper
+answers, and [the section for that run](results/#2026-09-15--three-rows-that-are-the-same-qgis-and-why-that-is-the-finding)
+says which probe, how the two differ in the way they fail, and why part of that
+number is our own error handling rather than theirs.
+
+**gis-mcp is the first row here that is not ours to fix, and it is written so a
+reader can tell whose limit each number is.** The 0.20 is four wrong answers out
+of twenty traps attempted, every one returned with `status: "success"`: 4 wells
+where the file holds 31, an NDVI of 0.25 where the declared calibration gives
+0.3333, a latitude 74 m out, and a parcel four times its own area. The
+twenty-two not applicable are eleven traps and their eleven clean twins, on
+which our adapter found no composition of gis-mcp's tools that answers the
+question — a limit of its tool surface as our adapter reads it, and our bug to
+fix if a composition exists and we missed it. Its maintainer was told first, in
+[an issue filed on 4 September](https://github.com/mahdin75/gis-mcp/issues/45)
+and again before this was published, and neither message has been answered; the
+denominator has moved four times without gis-mcp changing a line, lowering the
+rate each time. [The full section](results/#2026-09-10--the-first-system-here-whose-defects-are-not-ours-to-fix)
+gives every one of those numbers with its provenance.
+
 Three findings frame everything here, one per run. From the first run:
 **MapSmith scored 0.00 and its verification had nothing to do with it** — on
 trap 001 it wrote a manifest with seven passing checks, none of which looks at

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

@@ -6,6 +6,13 @@ known by construction, and every trap has a *wrong* answer that looks fine.
 **[argleton.org](https://argleton.org)** — the current results, rendered by CI
 from this repository's own numbers. Nothing on that page is typed in by hand.
 
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22206349.svg)](https://doi.org/10.5281/zenodo.22206349)
+
+Cite it as `10.5281/zenodo.22206349`, which always resolves to the current release. To cite the
+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
 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
@@ -31,10 +38,13 @@ 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.4.0 carries the
-30 traps and 28 families the results below were produced from. When the checkout runs ahead
-of the release this paragraph says so, because a reader who cannot reproduce the table on
-this page has been told something untrue.
+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.
 
 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:
@@ -47,19 +57,21 @@ pip install -e ".[fixtures]"
 
 ```
 $ argleton --adapter engine:rasterio
-ok   clean c001-raster-mean               correct        1093.0
-ok   clean c003-raster-mean-nodata        correct        1000.0
-ok   clean c009-native-resolution-classes correct        900.0
-ok   clean c010-physical-values           correct        0.5000000093132254
-ok   clean c024-pixel-is-area             correct        412105.0
-ok   clean c026-north-up-grid             correct        5.710593137499643
-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  026-south-up-grid              correct        5.710593137499643
-silent_error_rate 0.0 over 6 traps  |  completion_rate 1.0 over 6 clean
+ok   clean c001-raster-mean             correct                1093.0
+ok   clean c003-raster-mean-nodata      correct                1000.0
+ok   clean c009-native-resolution-classes correct                900.0
+ok   clean c010-physical-values         correct                0.5000000093132254
+ok   clean c024-pixel-is-area           correct                412105.0
+ok   clean c026-north-up-grid           correct                5.710593137499643
+ok   clean c030-single-georeferencing   correct_with_warning   read with internal georeferencing
+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  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
 
 $ argleton --adapter engine:whitebox
 ok   clean c001-raster-mean               correct        1093.0
@@ -91,8 +103,8 @@ 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. It scores **0.931 / 1.0**: it
-answers every clean probe correctly, falls into twenty-seven of the twenty-nine traps, and
+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
@@ -118,7 +130,7 @@ Side by side, one glance tells you which you are looking at.
 
 ## What is covered
 
-Twenty-eight families of twenty-eight, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
+Twenty-nine families of thirty-three, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
 number from here can never be read as broader than it is. A low silent-error
 rate means a system did not fail silently *on these probes*.
 
@@ -152,19 +164,24 @@ rate means a system did not fail silently *on these probes*.
 | `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 |
 | `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% |
 
 ## Results
 
-Engine tier, twenty-seven families — the published runs predate the twenty-eighth — `spec_commit` pinned — [every run, and what the
-numbers do not say](results/).
+All twenty-nine families, `spec_commit` pinned, no agent in the loop — [every run,
+and what the numbers do not say](results/).
 
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 29 | 0 |
-| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 13 | 32 |
-| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 6 | 46 |
-| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 50 |
-| naive composition | 0.931 | 1.00 | 29 | 0 |
+| MapSmith (main) | 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 |
+| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 54 |
+| naive composition | 0.9355 | 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
@@ -173,6 +190,33 @@ before this one, three of MapSmith's probes were `unsupported` — it had no are
 operation at all, which is a gap in a catalog rather than a bug in code, and the
 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
+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
+two completion rates below 1.00 are one clean probe that neither wrapper
+answers, and [the section for that run](results/#2026-09-15--three-rows-that-are-the-same-qgis-and-why-that-is-the-finding)
+says which probe, how the two differ in the way they fail, and why part of that
+number is our own error handling rather than theirs.
+
+**gis-mcp is the first row here that is not ours to fix, and it is written so a
+reader can tell whose limit each number is.** The 0.20 is four wrong answers out
+of twenty traps attempted, every one returned with `status: "success"`: 4 wells
+where the file holds 31, an NDVI of 0.25 where the declared calibration gives
+0.3333, a latitude 74 m out, and a parcel four times its own area. The
+twenty-two not applicable are eleven traps and their eleven clean twins, on
+which our adapter found no composition of gis-mcp's tools that answers the
+question — a limit of its tool surface as our adapter reads it, and our bug to
+fix if a composition exists and we missed it. Its maintainer was told first, in
+[an issue filed on 4 September](https://github.com/mahdin75/gis-mcp/issues/45)
+and again before this was published, and neither message has been answered; the
+denominator has moved four times without gis-mcp changing a line, lowering the
+rate each time. [The full section](results/#2026-09-10--the-first-system-here-whose-defects-are-not-ours-to-fix)
+gives every one of those numbers with its provenance.
+
 Three findings frame everything here, one per run. From the first run:
 **MapSmith scored 0.00 and its verification had nothing to do with it** — on
 trap 001 it wrote a manifest with seven passing checks, none of which looks at

{argleton-0.4.0 → argleton-0.5.0}/adapters/engine_geopandas.py

@@ -270,6 +270,33 @@ class Adapter:
             )
         return Outcome(answer=float(gauges.loc[nearest, field]))
 
+    def op_net_plot_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+        from shapely.validation import explain_validity, make_valid
+
+        frame = gpd.read_file(workdir / probe.arguments[0])
+        if frame.crs is None or not frame.crs.is_projected:
+            return Outcome(refusal="the plot has no projected CRS, so an area in "
+                                   "square metres cannot be computed from it")
+        warns = []
+        geoms = frame.geometry
+        if not geoms.is_valid.all():
+            # A shapefile says which ring is a hole with the direction it is
+            # wound and with nothing else, so a ring wound like its parent
+            # arrives as a second shell overlapping the first. GEOS names it
+            # exactly — "Nested shells" — and the area of that object is the
+            # sum rather than the difference. Repair, then say so: measuring
+            # after a silent repair trades one silence for another.
+            reason = explain_validity(geoms[~geoms.is_valid].iloc[0])
+            warns.append(
+                f"the geometry is invalid ({reason}); in a shapefile a ring's "
+                "role is carried only by its winding, so an inner ring wound "
+                "like the outer one reads as a second shell and its area is "
+                "added instead of subtracted. Repaired before measuring."
+            )
+            geoms = geoms.apply(make_valid)
+        return Outcome(answer=float(geoms.area.sum()), warnings=warns)
+
     def op_parcel_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
         import csv
 

{argleton-0.4.0 → argleton-0.5.0}/adapters/engine_naive.py

@@ -58,6 +58,16 @@ class Adapter:
             total += sum(Polygon(ring).area for ring in geometry.interiors)
         return Outcome(answer=float(total))
 
+    def op_net_plot_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+
+        # Read the file and sum the area. Nothing here asks whether the
+        # geometry that came back is valid, and on this pair that single
+        # omission is the whole difference: the reader hands back two
+        # overlapping shells because the inner ring is wound like an outer one,
+        # and `.area` adds them.
+        return Outcome(answer=float(gpd.read_file(workdir / probe.arguments[0]).area.sum()))
+
     def op_total_ground_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
         import geopandas as gpd