fix(ms-ai-architect): §9.15-rettelse — «45» var et gulv, og min egen sveip bar defekten den nettopp navnga

Sveipen som produserte 45 krevde at feltetiketten selv inneholder «MCP». En
telling hvis etikett mangler ordet er usynlig for den — nøyaktig dialekt-blindheten
§9.15 har som hovedlærdom, i sveipen som skulle rette den.

Etikett-fri sveip + haandklassifisering: 2 falske positive, 3 ekte til. Pluss
ai-risk-taxonomy-classification.md:458, en sifferloes overskrift («### MCP Calls
Summary») hvis telling staar i BLOKK-form under — en strukturell form ingen
linjebasert sveip kan enumerere.

Korrigert: >= 48 ekte linjer, og tallet er et GULV, ikke en maaling. Tre former
slapp unna: telling under etikett uten «MCP» (**Totalt:**), telling i blokk under
sifferloes overskrift, telling gjentatt i prosa.

To funn som endrer neste oekts oppdrag:
- Slettingen er ikke selv-fullfoerende. inferencing-optimization-caching.md
  oppgir 12 i footeren og GJENTAR det i prosa 24 linjer under. Kontrollert for
  denne oekten: ingen av de sju filene har slik rest. Men formen maa heretter
  kreve et rest-soek per fil.
- «Alle avvik gaar samme vei» har naa en kandidat-motsigelse.
  chain-of-thought-prompting.md:500 oppgir 4 over en liste med 3 verktoeykall —
  oppgitt > enumerert, motsatt vei, og utenfor populasjonen som ga «aatte av
  aatte». Retningsargumentet maa re-maales foer det siteres igjen.

Ogsaa: idx-26l sin stempel-paastand var UMAALT da den ble skrevet. Naa maalt og
den holder (ingen seksjonsterminale stempler i fila; de fire markoerene er
**Last updated:** paa l.5, inline *(Verified MCP 2026-04)* paa 729/738/739 knyttet
til enkeltkilder, og en overskrift paa 758 som staar ETTER footeren). Ordlyden er
strammet til aa foere maalingen, og at den kom i etterkant er navngitt — en
resolved entry er unntatt ankersjekk, saa ingenting ville noen gang fanget en
falsk faktapaastand inni en.

Suite: 15/15 paa g7-queue.

scripts/kb-eval/data/g7-review-queue.json

@@ -268,7 +268,7 @@
       "anchors": [
         "**MCP calls:** 6 (microsoft_docs_search: 3, microsoft_docs_fetch: 3, microsoft_code_sample_search: 2)"
       ],
-      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 6 (microsoft_docs_search: 3, microsoft_docs_fetch: 3, microsoft_code_sample_search: 2)'. This is the only file of the seven where the line stood as its OWN PARAGRAPH (blank line above and below), so the deletion took the line AND one adjacent blank, exactly as 088cf06 did in stakeholder-communication-ai-decisions.md. The other six sit inside a tight block where the line alone goes. A deletion correct on the string and wrong on the whitespace would leave a broken paragraph, which is a defect the anchor check cannot see.\nWHAT REMAINS IN THE FOOTER WAS CHECKED, NOT ASSUMED: the block's only other field is '**Dato for siste verifikasjon:** 2026-04-10', which is a date, not a count - it carries no denominator and states nothing this session can falsify (the three MCP-verified source annotations in the same section all read 'Verified MCP 2026-04'). Nothing else in the block is a counting claim, so nothing was kept-and-verified here and nothing was left unmeasured.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse.\nNo re-dating decision required: the footer sits under no section stamp. '**Last updated:**' untouched, per the precedent of all thirteen prior ratified corpus edits."
+      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 6 (microsoft_docs_search: 3, microsoft_docs_fetch: 3, microsoft_code_sample_search: 2)'. This is the only file of the seven where the line stood as its OWN PARAGRAPH (blank line above and below), so the deletion took the line AND one adjacent blank, exactly as 088cf06 did in stakeholder-communication-ai-decisions.md. The other six sit inside a tight block where the line alone goes. A deletion correct on the string and wrong on the whitespace would leave a broken paragraph, which is a defect the anchor check cannot see.\nWHAT REMAINS IN THE FOOTER WAS CHECKED, NOT ASSUMED: the block's only other field is '**Dato for siste verifikasjon:** 2026-04-10', which is a date, not a count - it carries no denominator and states nothing this session can falsify (the three MCP-verified source annotations in the same section all read 'Verified MCP 2026-04'). Nothing else in the block is a counting claim, so nothing was kept-and-verified here and nothing was left unmeasured.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse.\nNo re-dating decision required, and the stamp position was MEASURED - after the resolution was first drafted rather than before it, which is named here rather than quietly ratified, because a resolved entry is exempt from the anchor check and nothing would ever catch a false factual claim inside one. Ground truth: this file carries no section-terminal stamp anywhere. The four date markers are line 5 (**Last updated:** 2026-06-24), inline *(Verified MCP 2026-04)* annotations attached to individual source entries at lines 729, 738 and 739, and a section HEADING at 758 that postdates the footer. The footer stood at 741-743, between an inline source annotation and a rule, under no stamp - the same finding idx-26j reached about its own source 8, where an inline per-source marker was held not to be a section stamp. '**Last updated:**' untouched, per the precedent of all thirteen prior ratified corpus edits."
     },
     {
       "id": "idx-26m",