check_run:
  id: ARCH-007
  status: partial
  evidence_collected: 7
  evidence_required: 2
  findings:
    - "The aggregate is real and genuinely avoids a second round trip. src/swisstopo_mcp/oereb.py:305 `oereb_at()` calls `_fetch_egrid_features()` (oereb.py:325) and `_first_egrid()` internally, then at oereb.py:347-351 calls `get_oereb_extract(...)` as a plain Python coroutine with a constructed `GetOerebExtractInput`. It does not re-enter the MCP tool layer and it returns no intermediate EGRID for the model to feed back. One tool call in, a complete answer out."
    - "Its empty path is also correct: oereb.py:331-345 returns match_type=\"none\" with an actionable `note` naming swisstopo_municipality_at as the next step — the ARCH-003 pattern applied at the site that most needs it."
    - "The precedence rule is in the instructions string as claimed: src/swisstopo_mcp/server.py:70-76 — «PRECEDENCE for point questions — prefer the direct tool over the generic one: Bauzone → swisstopo_zoning_at ... Gemeinde/BFS-Nummer → swisstopo_municipality_at. ÖREB-Beschränkungen → swisstopo_oereb_at (swisstopo_get_egrid only when the parcel ID itself is wanted).»"
    - "CROSS-REFERENCE CLAIM IS FALSE FOR THE ÖREB PAIR. The remediation asserts the rule «is cross-referenced from the competing tool descriptions» and that get_egrid's «description no longer bills it as a precursor». Runtime introspection contradicts both: src/swisstopo_mcp/server.py:496 still reads `<use_case>Vorstufe zu swisstopo_get_oereb_extract: Koordinaten → EGRID.</use_case>` — «Vorstufe» is precisely «precursor» — and src/swisstopo_mcp/server.py:516 still reads «EGRID via swisstopo_get_egrid ermitteln». Neither description mentions swisstopo_oereb_at at all. A model reading only those two descriptions is still steered into the two-call chain."
    - "The cross-reference IS present for the other two clusters, so the claim is half-true rather than wholly wrong: swisstopo_identify_features (server.py, runtime description) states «Für Bauzone bzw. Gemeinde gibt es direkte Tools (swisstopo_zoning_at, swisstopo_municipality_at) — dieses Tool nur nutzen, wenn zusätzliche Rohattribute gebraucht werden»."
    - "Both READMEs still document the superseded chain as current. README.md:470-471 «Cadastre: `swisstopo_geocode` → `swisstopo_get_egrid` → `swisstopo_get_oereb_extract`» and README.de.md:464-465 (identical). Neither «Tool workflows» section mentions swisstopo_oereb_at, so the README contradicts the README's own tool-budget section 100 lines earlier (README.md:351-355), which says the pair «has been collapsed»."
    - "Criterion 2 (parallelisation where aggregation happens) is unmet: `asyncio.gather` appears nowhere in src/ — the only asyncio call is `asyncio.sleep` at src/swisstopo_mcp/api_client.py:274. The concrete miss is src/swisstopo_mcp/geodata.py:460-478, where `swisstopo_query_geodata` loops over discovered geodienste collections issuing one `request_with_retry` per collection sequentially. That is the check's named anti-pattern «Aggregations-Tools intern sequentiell statt parallel»."
  gaps:
    - "Criterion «Tool-Beschreibungen erwähnen explizit den aggregierten Charakter» holds for swisstopo_oereb_at and swisstopo_query_geodata but the competing older tools do not point at them (server.py:496, :516)."
    - "Criterion «Tools liefern gedanklich abgeschlossene Resultate (nicht nur IDs/Pointer)» still fails for swisstopo_get_egrid (returns an EGRID only, oereb.py:145-152) and swisstopo_search_layers (returns layer IDs only). Both are deliberate and both are now shadowed by an aggregate, which is the right shape — but the pointer-only tools remain exposed and, per the previous item, still self-describe as chain steps."
    - "No parallelisation anywhere; the one place it would pay (geodata.py:460) is sequential."
  evaluator_notes: |
    The parent asked two things. First: does the aggregate really avoid a second
    round trip? Yes — verified in source, it is an in-process coroutine call,
    not a tool re-entry. Second: is the precedence rule cross-referenced from
    the competing tool descriptions? No, not for the ÖREB pair, which is the
    exact pair the aggregate was built to supersede. The remediation note makes
    a specific factual claim («its description no longer bills it as a
    precursor») that the runtime tool manifest falsifies — server.py:496 still
    says «Vorstufe». Since instructions strings are, by the remediation's own
    reasoning, «not reliably consulted per selection decision», the description
    layer is where the rule has to live, and there it is missing. Add the stale
    README workflow sections and the absent parallelisation, and this is
    partial: genuine, well-built progress on the aggregate itself, with the
    surrounding steering work claimed but not done.
