test(architecture): add contested trigger probes for four map skills

.changes/architecture/test-13050-map-probes-df2265bd.md

@@ -0,0 +1,5 @@
+---
+bump: none
+---
+
+Adds contested trigger probes for four map skills; no shipped behavior changes.

.changes/skill-quality/test-13050-map-probes-7c41e9a2.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Changed
+
+- Invocation probes reference: records that contested probes and cross-plugin rivals did not make four `architecture` skills' description controls drop.

plugins/architecture/probes/map-data.json

@@ -6,7 +6,9 @@
   "competitors": [
     "architecture:map-containers",
     "architecture:map-dependencies",
-    "architecture:map-deployment"
+    "architecture:map-deployment",
+    "visualization:visualize",
+    "discovery:explore"
   ],
   "queries": [
     {
@@ -116,6 +118,60 @@
       "split": "validation",
       "expect_trigger": false,
       "request": "Show the events passed between services."
+    },
+    {
+      "id": "pos-contested-01",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Our Prisma models and the old SQL migrations have drifted apart. Draw how the tables connect and tell me where the two sources conflict."
+    },
+    {
+      "id": "pos-contested-02",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Give me a crow's-foot picture of the tables in this repo. I have no credentials for any DB, so work only from what's checked in."
+    },
+    {
+      "id": "pos-contested-03",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "We have OnModelCreating HasMany/WithOne config and a migrations folder. How are Order, Customer and Invoice related, one-to-many or many-to-many, and which source should I believe if they differ?"
+    },
+    {
+      "id": "pos-contested-04",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Which foreign keys link Customer to Invoice according to the migrations in the repo? I can't reach the server and don't need row counts."
+    },
+    {
+      "id": "pos-contested-05",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Does prisma/schema.prisma agree with the EF Core configuration on how Order and LineItem relate?"
+    },
+    {
+      "id": "pos-contested-06",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "This system has three stores. I don't need to know which services bind to them; for the Orders store, show me its tables and their relationships from the checked-in definitions."
+    },
+    {
+      "id": "neg-contested-01",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Sketch the table layout we just talked through above as a quick ASCII picture. It's only a proposal, nothing is in the repo yet."
+    },
+    {
+      "id": "neg-contested-02",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Before I change the Order table, explore what code reads and writes it and what tests cover it."
+    },
+    {
+      "id": "neg-contested-03",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Which databases and brokers does each deployable in this system bind to in its config?"
     }
   ]
 }

plugins/architecture/probes/map-deployment.json

@@ -6,7 +6,9 @@
   "competitors": [
     "architecture:map-containers",
     "architecture:map-landscape",
-    "architecture:map-context"
+    "architecture:map-context",
+    "visualization:visualize",
+    "discovery:explore"
   ],
   "queries": [
     {
@@ -116,6 +118,60 @@
       "split": "validation",
       "expect_trigger": false,
       "request": "Show the modules inside the web app."
+    },
+    {
+      "id": "pos-contested-01",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Compare staging and prod from our Bicep files: which services land on which hosts in each, and where do they diverge?"
+    },
+    {
+      "id": "pos-contested-02",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Going only by the Terraform in this repo, which Kubernetes node pool hosts the orders API in prod? Don't query Azure."
+    },
+    {
+      "id": "pos-contested-03",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Draw prod's infrastructure from the checked-in Helm charts and Bicep: clusters, app services, and which workloads are placed on each."
+    },
+    {
+      "id": "pos-contested-04",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Dev uses docker-compose and prod uses Kubernetes manifests, and they look nothing alike. Give me a diagram of how each environment is hosted and call out the gaps."
+    },
+    {
+      "id": "pos-contested-05",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "We already know what runs in this system. Now show me, per environment, what hosts each of those services according to the infra code."
+    },
+    {
+      "id": "pos-contested-06",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "I don't need who talks to our system. I want a C4 view of the infra nodes our services are placed on in prod, from the manifests in the repo."
+    },
+    {
+      "id": "neg-contested-01",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "What deployables does this system have, and which databases and brokers does each one bind to?"
+    },
+    {
+      "id": "neg-contested-02",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "What external systems does this system talk to, going by its connection strings and base URLs, and who uses it?"
+    },
+    {
+      "id": "neg-contested-03",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Turn the rollout plan we just discussed into a quick diagram."
     }
   ]
 }

plugins/architecture/probes/map-events.json

@@ -6,7 +6,10 @@
   "competitors": [
     "architecture:map-flow",
     "architecture:map-deployment",
-    "architecture:map-containers"
+    "architecture:map-containers",
+    "event-storming:methodology",
+    "visualization:visualize",
+    "discovery:explore"
   ],
   "queries": [
     {
@@ -116,6 +119,60 @@
       "split": "validation",
       "expect_trigger": false,
       "request": "Show the project reference graph."
+    },
+    {
+      "id": "pos-contested-01",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "OrderShipped gets sent from a few places in our C# code. Which handlers actually receive it, going by what's registered in the repo?"
+    },
+    {
+      "id": "pos-contested-02",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Find any MassTransit messages we send that nothing consumes, and any consumers whose message nobody ever sends."
+    },
+    {
+      "id": "pos-contested-03",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "We have Billing.Contracts.OrderPlaced and Shipping.Contracts.OrderPlaced. Draw what sends and receives each, and keep them separate."
+    },
+    {
+      "id": "pos-contested-04",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Draw the async wiring between our services from the C# code only: which bus messages go out from where and which classes handle them."
+    },
+    {
+      "id": "pos-contested-05",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "No workshop, just read the code: what messages pass between the Orders and Billing modules over the bus, and where are their handlers registered?"
+    },
+    {
+      "id": "pos-contested-06",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "OrdersController calls Publish<OrderShipped> at the end. I don't care about the call path up to there; which consumers pick it up?"
+    },
+    {
+      "id": "neg-contested-01",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Run a Big Picture workshop with us to discover the domain and bounded contexts of our returns process."
+    },
+    {
+      "id": "neg-contested-02",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Walk me through what happens step by step when POST /orders hits OrdersController, down to the repository call."
+    },
+    {
+      "id": "neg-contested-03",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Draw the message retry policy we just decided on as a quick diagram."
     }
   ]
 }

plugins/architecture/probes/map-flow.json

@@ -6,7 +6,10 @@
   "competitors": [
     "architecture:map-events",
     "architecture:map-components",
-    "architecture:map-dependencies"
+    "architecture:map-dependencies",
+    "discovery:explore",
+    "visualization:visualize",
+    "debugging:debug"
   ],
   "queries": [
     {
@@ -116,6 +119,60 @@
       "split": "validation",
       "expect_trigger": false,
       "request": "Generate API documentation for the controllers."
+    },
+    {
+      "id": "pos-contested-01",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Show me the hops from OrdersController.Create down to the repository as a picture of who calls whom in order, with file and line for each call."
+    },
+    {
+      "id": "pos-contested-02",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Draw the lifelines for RefundsController.Issue from the checked-in code. Each arrow should point to the line it came from."
+    },
+    {
+      "id": "pos-contested-03",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Follow CheckoutController.Submit call by call, and don't guess through IPaymentGateway: if a hop goes through an interface, leave it marked unknown."
+    },
+    {
+      "id": "pos-contested-04",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "InvoiceJob.Run resolves a handler from the service provider partway through. Lay out the chain of calls from that method, with a citation per step and an honest gap where the code can't tell you statically."
+    },
+    {
+      "id": "pos-contested-05",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Before I chase the 500 from POST /refunds, draw the ordered calls that endpoint makes in the C# code, citing each one. I'm not asking you to diagnose it yet."
+    },
+    {
+      "id": "pos-contested-06",
+      "split": "validation",
+      "expect_trigger": true,
+      "request": "Diagram the ordered calls from ShipmentsController.Confirm up to where it hands OrderShipped to the bus, and stop there. Don't work out who receives it."
+    },
+    {
+      "id": "neg-contested-01",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "Who publishes OrderShipped and which consumers are registered for it across the solution?"
+    },
+    {
+      "id": "neg-contested-02",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "POST /orders started throwing a NullReferenceException after yesterday's release. Why is it broken?"
+    },
+    {
+      "id": "neg-contested-03",
+      "split": "validation",
+      "expect_trigger": false,
+      "request": "What exists for refund handling in this codebase, and what tests cover it, before I change it?"
     }
   ]
 }

plugins/skill-quality/reference/invocation-probes.md

@@ -153,6 +153,20 @@ elimination. Competitors did take near-miss should-not probes on both sides
 no `knowledge` skill was called. Its probe set needs should-trigger queries that a
 neighboring skill could plausibly take, frozen before any description cut.
 
+Those queries and cross-plugin rivals are not always enough. On 2026-11-04 (Claude Code 2.1.318,
+Opus 5.5, 3 runs per probe, all passes VALID, every rival on the init line) four
+`architecture` skills got 6 blind should-trigger probes each, written to contest a named rival:
+
+| Skill | Rival plugins added | Should-trigger fired, shipped / control |
+|---|---|---|
+| `architecture:map-data` | discovery, visualization | 18/18 / 18/18 |
+| `architecture:map-events` | discovery, event-storming, visualization | 18/18 / 18/18 |
+| `architecture:map-flow` | debugging, discovery, visualization | 18/18 / 18/18 |
+| `architecture:map-deployment` | discovery, visualization | 18/18 / 18/18 |
+
+All four are unmeasurable, so they keep the before text. What makes the control fire was not
+tested: the listing always keeps a skill's name, which the generic description leaves in place.
+
 ## Outside the marketplace checkout
 
 The shipped seed probes name skills of this marketplace checkout (`plugins/skill-quality/...`