argleton 0.1.0__py3-none-any.whl

argleton/probes/traps/004-mismatched-crs-join/README.md

@@ -0,0 +1,65 @@
+# 004 — Two individually valid CRS, and a count of zero that reads as a finding
+
+## The files
+
+`zone.gpkg` holds one rectangle in **EPSG:4326**: longitude 12.30–12.42,
+latitude 41.80–41.95. `points.gpkg` holds forty points in **EPSG:32633** — the
+UTM zone this longitude band belongs to, an entirely ordinary choice for field
+data. Each file on its own is impeccable: valid geometry, declared and correct
+CRS. They just do not share a frame.
+
+## The right answer, on paper
+
+Both layers are built from the same longitude/latitude definitions, so
+containment is decided by interval comparison before any projection exists.
+Twelve points sit on the grid {12.33, 12.36, 12.39} × {41.83, 41.86, 41.89,
+41.92} — inside the rectangle with at least 0.03° (≈ 2.5 km) of margin to every
+edge. The other 28 sit at longitude 13.2 or greater, at least 0.78° (≈ 64 km)
+east of the rectangle: outside on the longitude interval alone.
+
+**The count is 12.** The projection step cannot move it: correct transforms
+between EPSG:32633 and EPSG:4326 agree to well under a metre, and reading the
+rectangle's edges as parallels and meridians or as projected chords displaces
+an edge by a few metres — three orders of magnitude below the margins. An
+integer with no room for legitimate disagreement, so the tolerance is 0.
+
+## The wrong answer
+
+Read both files, test containment on the raw coordinates: **0**.
+
+The points are UTM eastings and northings — every easting above 278 000 — while
+the polygon spans x in [12.30, 12.42]. The predicate is false forty times out
+of forty, exactly, for every algorithm, with no exception and no warning.
+GeoPandas ships a dedicated UserWarning for frames that disagree
+(`_crs_mismatch_warn`, in `geopandas/array.py`), which is how endemic this
+class is — and it cannot fire here, because tested against a bare geometry
+there is no second CRS to disagree with.
+
+## Why it is admitted
+
+Zero is the most data-shaped answer a spatial question can return. "No wells
+fall inside the protected zone" is a finding — often the one somebody was
+hoping for — not an error signal. An empty result is a valid, well-formed
+output that downstream code consumes without objection: it becomes an empty
+report section, a zero in a total, a green light. The only wrong thing is that
+two individually right frames were never brought into the same one.
+
+## Observed
+
+| adapter | answer | |
+|---|---|---|
+| `engine:geopandas` — aligns the frames, then tests | 12 | ✓ |
+| `adapters.mapsmith` — `spatial_join`, which reprojects and records the decision in `crs_decisions` | 12 | ✓ |
+| `engine:naive` — tests containment on raw coordinates | 0 | ✗ |
+
+Worth noting: on family 1 the naive composition passed by accident, because
+rasterio undoes the predictor on its behalf. Here there is no library to be
+saved by — the frames either get aligned by something that read both CRS, or
+the answer is 0.
+
+## Clean twin
+
+`clean/c004-points-in-polygon` — the same counting task with both layers in
+EPSG:32633 and a different count (9 of 36), so the pair cannot be passed by
+memorising a number. A system that answers the control and returns 0 on the
+trap has told us exactly one thing: it never read the second CRS.

argleton/probes/traps/004-mismatched-crs-join/build.py

@@ -0,0 +1,65 @@
+"""Build two individually impeccable layers that never meet.
+
+The zone is a rectangle in EPSG:4326. The points are stored in EPSG:32633 —
+the UTM zone this longitude band belongs to, an entirely ordinary choice for
+field data. Twelve of the forty points lie inside the rectangle, by
+construction in the shared lon/lat domain; whether a consumer finds them
+depends on exactly one thing: bringing the two frames together before testing
+containment.
+"""
+
+from __future__ import annotations
+
+import os
+import sys
+from pathlib import Path
+
+# GeoPackage stamps the write time into `gpkg_contents.last_change`, so two
+# builds of the same data differ byte for byte unless the clock is pinned.
+os.environ.setdefault("OGR_CURRENT_DATE", "2026-08-24T00:00:00.000Z")
+
+import geopandas as gpd
+from pyproj import Transformer
+from shapely.geometry import Point, Polygon
+
+ZONE_LON = (12.30, 12.42)
+ZONE_LAT = (41.80, 41.95)
+# Inside: a 3x4 grid with at least 0.03 degrees of margin to every edge.
+INSIDE_LON = (12.33, 12.36, 12.39)
+INSIDE_LAT = (41.83, 41.86, 41.89, 41.92)
+# Outside: everything at longitude 13.2 or greater — at least 0.78 degrees
+# east of the zone, outside on the longitude interval alone.
+OUTSIDE_LON = (13.2, 13.7, 14.2, 14.9)
+OUTSIDE_LAT = (40.4, 40.9, 41.4, 42.4, 42.9, 43.4, 43.9)
+
+ZONE_CRS = "EPSG:4326"
+POINTS_CRS = "EPSG:32633"  # UTM zone 33N, which covers 12-18 degrees east
+
+
+def main(destination: Path) -> int:
+    destination.mkdir(parents=True, exist_ok=True)
+
+    rectangle = Polygon([
+        (ZONE_LON[0], ZONE_LAT[0]),
+        (ZONE_LON[1], ZONE_LAT[0]),
+        (ZONE_LON[1], ZONE_LAT[1]),
+        (ZONE_LON[0], ZONE_LAT[1]),
+    ])
+    gpd.GeoDataFrame(
+        {"zone_id": ["Z-1"]}, geometry=[rectangle], crs=ZONE_CRS
+    ).to_file(destination / "zone.gpkg", layer="zone", driver="GPKG")
+
+    lonlat = [(x, y) for x in INSIDE_LON for y in INSIDE_LAT]
+    lonlat += [(x, y) for x in OUTSIDE_LON for y in OUTSIDE_LAT]
+    forward = Transformer.from_crs(ZONE_CRS, POINTS_CRS, always_xy=True)
+    points = [Point(*forward.transform(x, y)) for x, y in lonlat]
+    gpd.GeoDataFrame(
+        {"well_id": [f"W-{i + 1}" for i in range(len(points))]},
+        geometry=points,
+        crs=POINTS_CRS,
+    ).to_file(destination / "points.gpkg", layer="points", driver="GPKG")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(Path(sys.argv[1] if len(sys.argv) > 1 else ".")))

argleton/probes/traps/004-mismatched-crs-join/probe.toml

@@ -0,0 +1,75 @@
+id         = "004-mismatched-crs-join"
+population = "trap"
+family     = "mismatched-crs"
+title      = "Two individually valid CRS, and a count of zero that reads as a finding"
+surface    = ["engine", "agent"]
+
+[task]
+call   = "points_in_polygon_count(points.gpkg, zone.gpkg)"
+prompt = """
+How many of the points in points.gpkg fall inside the polygon in zone.gpkg?
+Answer with the count."""
+
+[truth]
+kind      = "count"
+value     = 12
+tolerance = 0
+derivation = """
+Both layers are built from the same longitude/latitude definitions. The zone is
+the rectangle [12.30, 12.42] x [41.80, 41.95] in EPSG:4326. The 40 points are
+defined in longitude/latitude and stored reprojected to EPSG:32633: twelve on
+the grid {12.33, 12.36, 12.39} x {41.83, 41.86, 41.89, 41.92}, inside the
+rectangle by interval comparison with at least 0.03 degrees (about 2.5 km) of
+margin to every edge; the other 28 at longitudes 13.2 or greater, at least 0.78
+degrees (about 64 km) east of the rectangle, outside on the longitude interval
+alone. Containment is therefore decided on paper, in the lon/lat domain, before
+any projection exists.
+
+The projection step cannot move the answer: correct transforms between
+EPSG:32633 and EPSG:4326 agree to well under a metre, and reading the
+rectangle's edges as parallels and meridians or as projected chords displaces
+an edge by a few metres at most - three orders of magnitude below the margins.
+The answer is an integer with no room for legitimate disagreement, so the
+tolerance is 0."""
+
+[naive_failure]
+description = """
+Both files are read and the containment test runs on the raw coordinates. The
+points are UTM eastings and northings - every easting above 278 000, every
+northing above 4 470 000 - while the polygon spans x in [12.30, 12.42] and y in
+[41.80, 41.95]. No point can fall inside, so the count comes back 0: exactly,
+for every algorithm, with no exception and no warning. GeoPandas ships a
+dedicated UserWarning for frames that disagree, but it cannot fire here -
+tested against a bare geometry, there is no second CRS to disagree with."""
+observed_value = 0
+plausible      = true
+why_plausible  = """
+Zero is the most data-shaped answer a spatial question can return. "No wells
+fall inside the protected zone" is a finding - often the one somebody was
+hoping for - and an empty result is a valid, well-formed output that downstream
+code consumes without objection. Each file on its own is impeccable: valid
+geometry, declared and correct CRS. The only wrong thing is that two
+individually right frames were never brought into the same one."""
+derivation = """
+Closed form: containment in the raw coordinate plane requires
+12.30 <= x <= 12.42, and every point's x is a UTM easting greater than 278 000.
+The predicate is false 40 times out of 40; the count is exactly 0."""
+
+[refusal]
+accept_if_mentions = ["crs", "coordinate reference", "spatial reference", "reproject", "projection", "32633", "4326"]
+
+[provenance]
+source = """
+Endemic enough that GeoPandas carries a guard for exactly this class:
+_crs_mismatch_warn in geopandas/array.py warns "CRS mismatch between the CRS of
+left geometries and the CRS of right geometries" whenever two geometry arrays
+disagree (verified in geopandas 1.1.4). The guard exists upstream because the
+empty join from mismatched frames is the canonical first question of spatial
+debugging - and the composition measured here slips past it, because a bare
+geometry has no CRS to compare."""
+found_by = "mapsmith"
+date     = "2026-08-24"
+
+[provenance.engine_versions]
+geopandas = "1.1.4 - warns on array-vs-array mismatch, silent against a bare shapely geometry"
+shapely = "planar containment on raw coordinates, CRS-unaware by design"

argleton/probes/traps/005-bowtie-area/README.md

@@ -0,0 +1,63 @@
+# 005 — A self-intersecting parcel whose area is computed anyway
+
+## The file
+
+`parcel.gpkg` holds one polygon in **EPSG:32632** whose ring crosses itself: a
+bowtie with two unequal lobes. Nothing refuses to store it — GeoPackage writes
+it, every reader reads it back unchanged, and it renders as two filled
+triangles that look like an ordinary odd-shaped parcel. Invalid rings are
+endemic in real cadastral and digitised data, which is why every serious
+engine ships a repair function.
+
+## The right answer, on paper
+
+The ring is A=(0,0), B=(0,100), C=(120,20), D=(120,80) in local metres. Edges
+B→C and D→A cross at X=(75,50), splitting the figure into two triangles:
+
+```
+(A, B, X): 100 · 75 / 2 = 3750 m²
+(C, D, X):  60 · 45 / 2 = 1350 m²        total: 5100 m²
+```
+
+**5100 is the only defensible answer.** Both fill rules (even-odd and nonzero
+winding) fill both lobes — which is also what any renderer draws — and
+repairing the ring with `make_valid` yields exactly the two triangles as a
+MultiPolygon of area 5100. A refusal that names the self-intersection is also
+accepted: repairing and refusing-with-reason are both careful behaviours.
+
+## The wrong answer
+
+Read the file, take `.area`, report it: **2400**.
+
+That is the shoelace sum over the ring, in which the two lobes carry opposite
+orientation and partially cancel: |3750 − 1350| = 2400 — a number that matches
+no definition of a region at all. And it arrives more quietly than the
+library's own manual predicts: Shapely's documentation says of self-crossing
+rings that "exceptions will be raised when they are operated on" — for the
+area, nothing is raised. No exception, no warning, a plausible number.
+
+## Why it is admitted
+
+2400 m² and 5100 m² are both entirely ordinary parcels. The file is well
+formed, the CRS is declared and metric, the geometry renders. The only wrong
+thing is that a ring crosses itself and nothing in the composition ever asked
+`is_valid` — the repair function exists in every engine, and a repair function
+that is never called protects nobody.
+
+## Observed
+
+| adapter | answer | |
+|---|---|---|
+| `engine:geopandas` — checks validity, repairs with `make_valid`, **and says so** | 5100.0, `correct_with_warning` | ✓ |
+| `engine:naive` — sums `.area` | 2400.0 | ✗ |
+
+The careful adapter's verdict is worth a note: it is scored
+`correct_with_warning`, not plain `correct`, because it *communicated* the
+repair. Measuring after a silent repair would be trading one silence for
+another.
+
+## Clean twin
+
+`clean/c005-polygon-area` — a valid L-shaped parcel, same CRS, same question,
+area 7600 m² by decomposition on paper. The trap and its control differ in
+exactly one thing: whether the ring crosses itself.

argleton/probes/traps/005-bowtie-area/build.py

@@ -0,0 +1,41 @@
+"""Build one self-intersecting parcel — a bowtie with unequal lobes.
+
+The ring is A -> B -> C -> D -> A with two edges crossing once. Nothing refuses
+to store it: GeoPackage writes it, every reader reads it back byte-identical,
+and the polygon renders as two filled triangles that look like an ordinary odd
+parcel. The coordinates are ordinary UTM 32N metres.
+"""
+
+from __future__ import annotations
+
+import os
+import sys
+from pathlib import Path
+
+# GeoPackage stamps the write time into `gpkg_contents.last_change`, so two
+# builds of the same data differ byte for byte unless the clock is pinned.
+os.environ.setdefault("OGR_CURRENT_DATE", "2026-08-24T00:00:00.000Z")
+
+import geopandas as gpd
+from shapely.geometry import Polygon
+
+CRS = "EPSG:32632"
+E0, N0 = 400_000.0, 5_000_000.0  # ordinary coordinates for the zone
+
+# Local shape: A=(0,0), B=(0,100), C=(120,20), D=(120,80). Edges B->C and D->A
+# cross at X=(75,50); the lobes are the triangles (A,B,X) = 3750 m2 and
+# (C,D,X) = 1350 m2. Offsets do not change areas.
+RING = [(0.0, 0.0), (0.0, 100.0), (120.0, 20.0), (120.0, 80.0)]
+
+
+def main(destination: Path) -> int:
+    destination.mkdir(parents=True, exist_ok=True)
+    bowtie = Polygon([(E0 + x, N0 + y) for x, y in RING])
+    gpd.GeoDataFrame(
+        {"parcel_id": ["A-1"]}, geometry=[bowtie], crs=CRS
+    ).to_file(destination / "parcel.gpkg", layer="parcel", driver="GPKG")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(Path(sys.argv[1] if len(sys.argv) > 1 else ".")))

argleton/probes/traps/005-bowtie-area/probe.toml

@@ -0,0 +1,73 @@
+id         = "005-bowtie-area"
+population = "trap"
+family     = "invalid-geometry"
+title      = "A self-intersecting parcel whose area is computed anyway"
+surface    = ["engine", "agent"]
+
+[task]
+call   = "planar_area_m2(parcel.gpkg)"
+prompt = """
+What is the area of the parcel in parcel.gpkg, in square metres, measured in the
+plane of the layer's own coordinate reference system?"""
+
+[truth]
+kind      = "scalar"
+value     = 5100.0
+tolerance = 0.01
+derivation = """
+The ring is A=(0,0), B=(0,100), C=(120,20), D=(120,80) in local metres
+(EPSG:32632, offset 400000/5000000 - offsets do not change areas). Edges B->C
+(y = 100 - 2x/3) and D->A (y = 2x/3) cross at X=(75,50). The two lobes are the
+triangles (A,B,X), area 100*75/2 = 3750, and (C,D,X), area 60*45/2 = 1350. The
+region the ring encloses is therefore 3750 + 1350 = 5100 square metres.
+
+WHY 5100 IS THE ONLY CORRECT ANSWER. Every point-set reading of "the area of
+this parcel" agrees: both the even-odd and the nonzero winding rule fill both
+lobes, which is also what any renderer draws, and repairing the ring
+(make_valid) yields exactly the two triangles as a MultiPolygon of area 5100.
+The other number in play, 2400, corresponds to no definition of a region at
+all - it is the signed shoelace sum, in which the two lobes carry opposite
+orientation and partially cancel (see naive_failure). A refusal naming the
+self-intersection is also accepted: repairing and refusing-with-reason are
+both careful behaviours; reporting the artifact is the only wrong one."""
+
+[naive_failure]
+description = """
+Read the file, take `.area`, report it. On a self-intersecting ring Shapely
+returns the shoelace sum - lobes with opposite orientation partially cancel -
+with no exception and no warning. That is quieter than the library's own
+manual, which says of self-crossing rings that "exceptions will be raised when
+they are operated on": for the area, nothing is raised. The answer comes back
+2400."""
+observed_value = 2400.0
+plausible      = true
+why_plausible  = """
+2400 m2 is an entirely ordinary parcel, and so is the true 5100 m2 - neither
+looks out of place in a report or a total. Nothing objects along the way: the
+file writes and reads cleanly, the geometry renders as two filled triangles,
+and the area call returns a number rather than raising. Invalid rings are
+endemic in real cadastral and digitised data, which is why every serious
+engine ships a repair function - and a repair function that exists but is not
+called protects nobody."""
+derivation = """
+Closed form: the shoelace sum over A,B,C,D is 0 - 12000 + 7200 + 0 = -4800,
+so the reported area is |-4800|/2 = 2400 - exactly |3750 - 1350|, the larger
+lobe minus the smaller one."""
+
+[refusal]
+accept_if_mentions = ["invalid", "self-intersect", "self intersection", "bowtie", "make_valid", "not valid"]
+
+[provenance]
+source = """
+Shapely manual (fetched 2026-08-24): "Operations on invalid features may
+fail." and, of self-crossing rings, "Shapely will not prevent the creation of
+such rings, but exceptions will be raised when they are operated on" - yet
+`.area` on this ring raises nothing and returns the artifact (verified on
+shapely 2.1.2). GEOS, PostGIS (ST_MakeValid) and Shapely all ship a repair
+function because invalid rings are endemic in real data; this probe measures
+the composition that never calls it."""
+found_by = "mapsmith"
+date     = "2026-08-24"
+
+[provenance.engine_versions]
+shapely = "2.1.2 - .area returns the signed-shoelace artifact on a self-intersecting ring, no exception, no warning"

argleton/probes/traps/006-default-layer/README.md

@@ -0,0 +1,65 @@
+# 006 — A two-layer container that answers a question nobody asked
+
+## The file
+
+`project.gpkg` holds two layers, both valid, both honestly named: `zones`
+(4 polygons, written first — which makes it the container's **default**) and
+`wells` (31 points, written second). GeoPackage is explicitly a multi-layer
+format; a single project container holding zones and wells together is its
+normal, documented use. Nothing about this file is unusual.
+
+## The right answer, on paper
+
+The question names the layer: *how many features are in the `wells` layer?*
+By construction, `wells` holds W-1 through W-31. **The count is 31**, an
+integer with no room for disagreement; the tolerance is 0.
+
+## The wrong answer
+
+Read the file, count the rows: **4**.
+
+`read_file(path)` with no layer argument returns the container's default
+layer — `zones`. This one is not fully mute, and the honest description says
+so: pyogrio emits a UserWarning naming the default (*"More than one layer
+found in 'project.gpkg': 'zones' (default), 'wells'. Specify layer parameter
+to avoid this warning."*). But the warning goes to stderr, the returned frame
+is perfectly well formed, and nothing in the **result** carries any trace of
+it. A pipeline that logs-and-forgets — the overwhelming default, and the only
+option in most agent stacks, where stderr never reaches the model — reports 4.
+
+## Why it is admitted
+
+"4 wells" is an entirely ordinary count, and a count carries no fingerprint of
+the layer it came from. The person who asked about wells receives a number
+computed on zones, and no property of the number says so. The one signal that
+exists is attached to a stream, not to a result — and a signal nothing
+downstream can see is not a defence, it is a description of the defect.
+
+## Observed
+
+| adapter | answer | |
+|---|---|---|
+| `engine:geopandas` — passes the layer the question names | 31 | ✓ |
+| `engine:naive` — reads "the file" | 4 | ✗ |
+| `adapters.mapsmith` — `describe_dataset`, which takes a path and nothing else | 4 | ✗ **silent error** |
+
+The third row is the reason this probe exists, and it is about the suite's own
+author: MapSmith's reader resolved a multi-layer container to its default
+layer **silently** — its inspection result said `feature_count: 4` with no
+warning field at all, quieter than the bare pyogrio call it wraps. Filed as
+[MapSmith issue #29](https://github.com/mapsmith-ai/MapSmith/issues/29) before
+this trap was published, and that number is in the published
+[2026-08-25 run](../../results/2026-08-25-six-families/).
+
+**After the fix** (MapSmith `ebea7d0`, the same day, in that order on
+purpose): operations refuse a container with no chosen layer, naming the
+layers; `describe_dataset` describes every layer so the caller can choose; and
+this adapter's composition now answers **31, correct**. The row above is the
+regression test with a date on it — both dates.
+
+## Clean twin
+
+`clean/c006-named-layer` — one layer, honestly named, 17 points, same
+question. With a single layer there is nothing to choose wrongly: a system
+that answers the control and returns 4 on the trap has told us exactly one
+thing — it never chose a layer at all.

argleton/probes/traps/006-default-layer/build.py

@@ -0,0 +1,55 @@
+"""Build one GeoPackage holding two layers, neither of them wrong.
+
+``zones`` is written first (4 polygons) and therefore becomes the container's
+default layer; ``wells`` (31 points) is written second. Every reader that is
+handed the file without a layer name gets zones — the question the caller
+asked names wells. Both layers are valid, ordinary and honest; the only trap
+is that the container can answer a question nobody asked.
+"""
+
+from __future__ import annotations
+
+import os
+import sys
+from pathlib import Path
+
+# GeoPackage stamps the write time into `gpkg_contents.last_change`, so two
+# builds of the same data differ byte for byte unless the clock is pinned.
+os.environ.setdefault("OGR_CURRENT_DATE", "2026-08-25T00:00:00.000Z")
+
+import geopandas as gpd
+from shapely.geometry import Point, Polygon
+
+CRS = "EPSG:32632"
+N_ZONES = 4
+N_WELLS = 31
+
+
+def main(destination: Path) -> int:
+    destination.mkdir(parents=True, exist_ok=True)
+    container = destination / "project.gpkg"
+
+    zones = gpd.GeoDataFrame(
+        {"zone_id": [f"Z-{i}" for i in range(1, N_ZONES + 1)]},
+        geometry=[
+            Polygon([
+                (i * 100.0, 0.0), (i * 100.0 + 80.0, 0.0),
+                (i * 100.0 + 80.0, 80.0), (i * 100.0, 80.0),
+            ])
+            for i in range(N_ZONES)
+        ],
+        crs=CRS,
+    )
+    zones.to_file(container, layer="zones", driver="GPKG")
+
+    wells = gpd.GeoDataFrame(
+        {"well_id": [f"W-{i}" for i in range(1, N_WELLS + 1)]},
+        geometry=[Point(10.0 + i * 7.0, 200.0 + (i % 5) * 11.0) for i in range(N_WELLS)],
+        crs=CRS,
+    )
+    wells.to_file(container, layer="wells", driver="GPKG")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(Path(sys.argv[1] if len(sys.argv) > 1 else ".")))

argleton/probes/traps/006-default-layer/probe.toml

@@ -0,0 +1,63 @@
+id         = "006-default-layer"
+population = "trap"
+family     = "ambiguous-layer"
+title      = "A two-layer container that answers a question nobody asked"
+surface    = ["engine", "agent"]
+
+[task]
+call   = "feature_count(project.gpkg, layer=wells)"
+prompt = """
+How many features are in the `wells` layer of project.gpkg? Answer with the
+count."""
+
+[truth]
+kind      = "count"
+value     = 31
+tolerance = 0
+derivation = """
+By construction: project.gpkg holds exactly two layers, `zones` written first
+(4 polygons) and `wells` written second (31 points, W-1 through W-31). The
+question names the layer, so the answer is the number of features in `wells`:
+31. An integer with no room for disagreement; the tolerance is 0."""
+
+[naive_failure]
+description = """
+Read the file, count the rows: `read_file(path)` with no layer argument
+returns the container's DEFAULT layer, which is `zones` — the count comes back
+4. This is not fully mute: pyogrio emits a UserWarning naming the default
+("More than one layer found... 'zones' (default)"). But the warning goes to
+stderr, the returned frame is well formed, and nothing in the RESULT carries
+any trace of it — a pipeline that logs-and-forgets, which is the overwhelming
+default, reports 4. Measured on a system that wraps the same reader: its
+inspection result said `feature_count: 4` with no warning field at all."""
+observed_value = 4
+plausible      = true
+why_plausible  = """
+"4 wells" is an entirely ordinary count, and nothing about the container
+pushes back: both layers are valid and honestly named, the CRS is declared,
+the file opens everywhere. The person who asked about wells receives a number
+computed on zones, and no property of the number says so — a count carries no
+fingerprint of the layer it came from. The one signal that exists is a
+UserWarning on a stream nobody reads in production, attached to no result."""
+derivation = """
+Closed form: the default layer is the first one written into the container —
+`zones`, with exactly 4 features. A bare read counts those: 4."""
+
+[refusal]
+accept_if_mentions = ["layer", "multi-layer", "multilayer", "ambiguous", "more than one", "default"]
+
+[provenance]
+source = """
+The guard exists upstream because the mistake is endemic: pyogrio warns "More
+than one layer found in '...': '...' (default)... Specify layer parameter to
+avoid this warning" on every bare read of a multi-layer source (verified,
+pyogrio 0.11/geopandas 1.1.4). GeoPackage is explicitly a multi-layer format,
+and single-file project containers are its normal use. Found while designing
+this probe: the reader of a provenance-first geoprocessing server swallowed
+the same warning and reported the default layer's count with no trace — filed
+there as issue #29 before this trap was published."""
+found_by = "mapsmith"
+date     = "2026-08-25"
+
+[provenance.engine_versions]
+geopandas = "1.1.4/pyogrio - bare read returns the first layer and warns on stderr; the result object carries nothing"

argleton/probes/traps/007-buffer-in-degrees/README.md

@@ -0,0 +1,57 @@
+# 007 — A distance of 500, applied in the layer's units instead of the question's
+
+## The file
+
+`wells.gpkg` holds 25 wells in **EPSG:4326**. W-1 sits at (12.40, 41.90); three
+wells lie within 400 metres of it, the other 21 lie kilometres away. Everything
+about the file is honest — valid points, declared CRS — and so is the number
+500 in the question. What is implicit is the unit it gets applied in.
+
+## The right answer, on paper
+
+In the local metric at 41.9°N (1° of latitude = 111.1 km, 1° of longitude =
+82.9 km), the three near wells sit at ~300 m, ~398 m and ~359 m from W-1; the
+nearest excluded well is at 6,932 m. **The count is 3.** The margins carry the
+derivation: at these distances a flat-earth approximation, a geodesic and a
+UTM-planar distance agree to within centimetres, while the included/excluded
+gap is three orders of magnitude wider than any method disagreement.
+Tolerance 0.
+
+## The wrong answer
+
+Buffer W-1 by 500, count the wells inside: **24 — every single one**.
+
+Shapely, GeoPandas and PostGIS all buffer in the layer's own units by design,
+and none of them can know the caller meant metres. A buffer of 500 *degrees*
+spans longitudes −487.6 to 512.4: the whole coordinate space of the file, and
+then the planet, repeatedly. No exception, no warning — the buffer is a
+perfectly valid polygon, just an absurd one that nothing downstream ever looks
+at. Only the count survives, and the count looks fine.
+
+## Why it is admitted
+
+This family's classic demonstration — "the buffered *area* is planet-sized" —
+is loud, and a loud failure belongs in an ordinary test suite. The trap plants
+the quiet variant: a **count**. "24 wells within half a kilometre" is an
+ordinary number for a dense urban wellfield, and a count carries no trace of
+the geometry that produced it. The figure 500 is exactly what the question
+said; the only implicit thing was the unit.
+
+## Observed
+
+| adapter | answer | |
+|---|---|---|
+| `engine:geopandas` — projects to the local UTM zone, then measures | 3 | ✓ |
+| `adapters.mapsmith` — `buffer_layer`, whose contract is metres (auto-UTM on geographic layers, decision recorded), then a within-join | 3 | ✓ |
+| `engine:naive` — buffers 500 in the layer's units | 24 | ✗ |
+
+The MapSmith pass is earned the same way family 4's was: not by a library that
+happens to save the caller, but by a tool contract that names the unit
+(*metres, always*) and records the reprojection decision in the manifest.
+
+## Clean twin
+
+`clean/c007-distance-in-metres` — the same question on a layer already in
+EPSG:32633: five wells within 460 m (offsets exact by Pythagoras), the rest at
+2.5 km or more. The trap and its control differ in exactly one thing: whether
+the layer's unit is the one the question uses.

argleton/probes/traps/007-buffer-in-degrees/build.py

@@ -0,0 +1,42 @@
+"""Build a wells layer in EPSG:4326 where "within 500 metres" is the question.
+
+W-1 sits at (12.40, 41.90). Three wells lie within 400 metres of it; the other
+21 lie kilometres away. The layer is honest — valid points, declared CRS — and
+the number 500 is honest too. What is implicit is the unit it gets applied in.
+"""
+
+from __future__ import annotations
+
+import os
+import sys
+from pathlib import Path
+
+# GeoPackage stamps the write time into `gpkg_contents.last_change`, so two
+# builds of the same data differ byte for byte unless the clock is pinned.
+os.environ.setdefault("OGR_CURRENT_DATE", "2026-08-25T00:00:00.000Z")
+
+import geopandas as gpd
+from shapely.geometry import Point
+
+CRS = "EPSG:4326"
+LON, LAT = 12.40, 41.90  # W-1
+
+# ~300 m north, ~398 m east, ~359 m south-west of W-1 (local metric at 41.9N).
+INSIDE = [(LON, LAT + 0.0027), (LON + 0.0048, LAT), (LON - 0.0036, LAT - 0.0018)]
+# Everything else at least ~4 km away (>= 0.05 degrees in both axes).
+OUTSIDE = [(LON + 0.05 + 0.01 * i, LAT + 0.05 + 0.007 * (i % 7)) for i in range(21)]
+
+
+def main(destination: Path) -> int:
+    destination.mkdir(parents=True, exist_ok=True)
+    points = [Point(LON, LAT)] + [Point(*c) for c in INSIDE] + [Point(*c) for c in OUTSIDE]
+    gpd.GeoDataFrame(
+        {"well_id": [f"W-{i + 1}" for i in range(len(points))]},
+        geometry=points,
+        crs=CRS,
+    ).to_file(destination / "wells.gpkg", layer="wells", driver="GPKG")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(Path(sys.argv[1] if len(sys.argv) > 1 else ".")))