bc-mcp.agent.md v4: document customers + QA test-iteration tools

Live tool audit found the businesscentral MCP server exposes 19 tools,
4 undocumented: List_Customers_PAG50045 and the
List/Create/Modify_TestIteration_PAG6102911 trio. Michael confirmed
both are wanted:

- customers (PAG50045): read-only, restricted in practice to `no` +
  `microsoftTenantId` even though the schema also exposes `name`/
  `tenantCompanyName` (CURABIS-BCMCP-010).
- testIterations (PAG6102911): activates the QA test-iteration flow
  designed 2026-08-09 (Ready for Test trigger, Robert/Linh manual
  testing on top of automated tests, defect dedup by shared root
  cause). Dedup grouping must come from a separate fresh-context
  agent, never the implementing agent grading its own defect count
  (CURABIS-BCMCP-009).

Also resolves the open question from the 2026-08-09 design: the older
CUR Sub Task informal bug-tracking fields (Error type / Error related
to task) are a dead pattern at CURABIS and are not being unified with
the new table. Corrected a stale tool-count claim (14 -> 19) along the
way.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

custom/setup/templates/bc-mcp.agent.md

@@ -1,17 +1,17 @@
 ---
 kind: action-skill
 id: curabis-bc-mcp
-version: 3
+version: 4
 title: CURABIS Business Central MCP usage
-description: How to use the CURABIS Business Central MCP server to read project-management work from BC and write GitHub dev status back. Company-default workflow for syncing Claude Code / GitHub work with BC tasks. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 14 directly-named tools replace the old search/describe/invoke indirection. v3 (2026-08-03) - task-comment state checkpoints for resumability across machine/operator changes.
+description: How to use the CURABIS Business Central MCP server to read project-management work from BC and write GitHub dev status back. Company-default workflow for syncing Claude Code / GitHub work with BC tasks. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 15 directly-named tools replace the old search/describe/invoke indirection. v3 (2026-08-03) - task-comment state checkpoints for resumability across machine/operator changes. v4 (2026-08-17) - customers (PAG50045) and QA test-iteration tracking (PAG6102911) added; server now exposes 19 tools.
-inputs: [project-no, task-no, branch, dev-status, comment]
+inputs: [project-no, task-no, branch, dev-status, comment, test-iteration]
-outputs: [task-list, updated-task, posted-comment]
+outputs: [task-list, updated-task, posted-comment, posted-test-iteration]
 bc-version: [all]
 technologies: [al, mcp]
 countries: [w1]
 application-area: [all]
 domain: integration
-keywords: [mcp, business-central, project, subtask, github, branch, dev-status, comment, triage, sync]
+keywords: [mcp, business-central, project, subtask, github, branch, dev-status, comment, triage, sync, qa, test-iteration, customers]
 ---
 
 # CURABIS Business Central MCP usage
@@ -82,7 +82,7 @@ not setup. Load only what the task needs — see the table below for the full se
 
 ## Tools (BC MCP, Static Tool Mode)
 
-The `businesscentral` MCP server exposes **14 directly-named tools**, one per
+The `businesscentral` MCP server exposes **19 directly-named tools**, one per
 BC action, each with its own typed schema reflecting exactly which fields that
 page allows you to write. No discovery step, no per-call reverification — call
 the tool by name directly, matching the convention `List_<Entity>_PAG<id>` (read),
@@ -97,8 +97,10 @@ the tool by name directly, matching the convention `List_<Entity>_PAG<id>` (read
 | newTasks (6102905) | `List_NewTasks_PAG6102905`, `Create_NewTask_PAG6102905` | create new task | `status` — always Created on insert, never change it |
 | taskComments (6102902) | `List_TaskComments_PAG6102902`, `Create_TaskComment_PAG6102902`, `Modify_TaskComment_PAG6102902` | create a comment, edit `comment`/`date`/`lineType` | delete |
 | consultants (PAG50009) | `List_Consultants_PAG50009` | **read-only** | any write; no Modify/Create tool exists |
+| customers (PAG50045) | `List_Customers_PAG50045` | **read-only** | any write; no Modify/Create tool exists. Schema also exposes `name`/`tenantCompanyName`, but company policy is to surface only `no` + `microsoftTenantId` — don't select or print the other two |
 | projectAIScores (6102906) | `List_ProjectAIScores_PAG6102906`, `Create_ProjectAIScore_PAG6102906` | **Edison only** — insert one score entry per eval iteration | modify, delete (immutable posting table — no such tool exists); any other agent inserting here |
 | projectWeberScores (6102908) | `List_ProjectWeberScores_PAG6102908`, `Create_ProjectWeberScore_PAG6102908` | **Weber only** — insert one classification per sub-task coached | modify, delete (immutable posting table — no such tool exists); any other agent inserting here |
+| testIterations (6102911) | `List_TestIterations_PAG6102911`, `Create_TestIteration_PAG6102911`, `Modify_TestIteration_PAG6102911` | insert one row per QA iteration (see "QA test-iteration workflow" below) | grade/dedupe your own defect count if you were the implementing agent; edit `entryNo`/`iterationNo` |
 
 `consultants` was previously documented here as `users (6102903)` — that entity does not exist
 in the BC MCP action catalog under any name. The real page is `List_Consultants_PAG50009`
@@ -161,6 +163,46 @@ Follow ALL steps — do not skip any:
 The `gitHubRepository` on a project is set via `projectRepositories` (PAG6102904) — the agent
 may write it. Never write it on the projects page (PAG6102901).
 
+## QA test-iteration workflow (PAG6102911)
+
+Built 2026-08-09 in ProjectMgmt365app to give the dev↔QA test loop the same kind of
+signal-ratio measurement Edison already gives BCQuality rules. Robert and Linh
+(Support+Test) test manually on top of the automated suite; this is where their
+findings get recorded so the loop is measured, not vibes.
+
+1. **Trigger.** The one hard trigger a QA iteration hangs off is `gitHubDevStatus`
+   moving to `Ready for Test` on `activeTasks` — chosen specifically so developer-side
+   testing (inherent to coding) and tester-side testing (the measured checkpoint) never
+   need a case-by-case judgment call.
+2. **Testing happens.** Robert/Linh execute manual scenarios against the task. Any bug
+   found becomes a new Claude-authored **failing test** (TDD red) — the implementing
+   session does not auto-fix it in the same breath; that stays a deliberate separate step.
+3. **Dedup the defects — never by the implementer.** Group found defects by shared root
+   cause (three failing tests from one changed function = one defect), not raw
+   failing-test count — raw count punishes testers for writing more scenarios. The
+   grouping proposal must come from a **separate agent with fresh context**, working from
+   the diff/call-graph (code-causality), and Robert/Linh confirm scenario-equivalence
+   (do the fixes still feel like one user-facing problem). The agent that implemented the
+   fix must never grade its own defect count — same self-scoring conflict Edison's
+   read-only design avoids elsewhere. See CURABIS-BCMCP-009.
+4. **Post the iteration.** Call `Create_TestIteration_PAG6102911` with `projectNo`,
+   `taskNo`, `readyForTestDateTime`, `testedBy`, `testCompletedDateTime`,
+   `defectsFoundRaw`, `defectsFoundDeduped`, `dependencyEvidence` (the causality
+   reasoning from step 3), `result` (`Passed`/`Failed`). `iterationNo`/`entryNo` are
+   server-computed (`GetNextLineNo` pattern, mirrors `Create_TaskComment_PAG6102902`) —
+   never set them yourself.
+5. **Don't conflate iteration sequences.** `testIterations.iterationNo` counts QA
+   round-trips. `projectAIScores.iterationNo` (PAG6102906) counts AI hill-climbing
+   attempts. They are deliberately separate counters on separate tables — a task can be
+   on AI-score iteration 4 and QA iteration 1 at the same time.
+
+**Dead pattern — do not resurrect:** `CUR Sub Task` (307) also has an older, informal
+bug-tracking pattern (`Error type` = QA-Environment/Customer test/Live Database, `Error
+related to task`, FlowField counts). It covers **post-delivery** bugs, a different scope
+from this pre-klarmelding dev↔QA loop, and per Michael (2026-08-17) CURABIS never
+actually uses it. Don't propose unifying the two — there's nothing live on the other side
+to unify with.
+
 ## Developer identity (under S2S)
 
 Because the MCP runs as `BC_DevelopmentMCP`, BC cannot see which developer is working.
@@ -199,3 +241,10 @@ CURABIS-BCMCP-004 Read is safe, write is deliberate. Reading tasks/projects/comm
   fine unprompted; any write-back must be something the user asked for or clearly intends.
 CURABIS-BCMCP-005 Don't guess data. If the server is unavailable or a task isn't found,
   report it - never fabricate task numbers, branches, or statuses.
+CURABIS-BCMCP-009 The agent/session that implemented a fix must never grade or dedupe its
+  own defect count when posting to `testIterations` (PAG6102911). The code-causality
+  grouping must come from a separate, fresh-context agent; testers confirm
+  scenario-equivalence before `Create_TestIteration_PAG6102911` is called.
+CURABIS-BCMCP-010 `customers` (PAG50045) is read-only and even though the schema exposes
+  `name`/`tenantCompanyName`, only ever select/surface `no` + `microsoftTenantId` — never
+  print or log the other two fields.