board: note the self-inflicted build-dir race that mimicked a flaky test

campaign/board.md

@@ -266,3 +266,4 @@ Status flow: `backlog → in-progress → mapped → verified` (or `blocked`).
 | g_CurrentClientIndex is a STACK POINTER | objects | verified | high | 100% | 2026-09-08 | Not an index. Two writers only, Push/PopCurrentClient 0x00578020/40, and StrategyAIAgent::OnEvent BRACKETS THE WHOLE AI TURN in them - that is how every cl_* call lands on the right client AND the right per-client RNG. Also: AI1's one inferred hop is now READ TO THE CALL at 0x006b395b (Broadcast -> OnAIPacket), push order matching the thunk exactly; lane-ai1.json's Broadcast and g_CurrentClientIndex upgraded mapped -> verified in place |
 | AI2 corrections to AI1 | meta | verified | high | 100% | 2026-09-08 | **31 task classes, not 34** - slot-1 x slot-8 across 31 vtables gives a gapless type enum 0..0x20 with two retired ids. **26 order methods, not 21.** **7 pure virtuals, not 8** - named: GetTypeId, GetTargetA/B, Execute(agent,pass), IsFinished(agent), GetTypeName, Describe. Also a test expectation was wrong on first run (ColonizeAt 1300 outranks NodeBore 1275) and lane AI2 FIXED THE TEST, NOT THE CODE |
 | AI2 boundary | meta | verified | high | 100% | 2026-09-08 | Slots 11/12/13 UNNAMED. The nine tasks with no reachable order method are INFERRED to be goal/planner tasks - bodies unread. The two-pass meaning is INFERENCE. The reachability table is a DIRECT-CALL CLOSURE = lower bound (rule 16 bites hard in a vtable system). **The StrategyApp+0x1c ENQUEUE SITE WAS NOT FOUND, so AI-stepping order is still open** - and that matters because ModCount is a count. The .data invade tunables 0x00a1795c/60 have no traced loader. NOTHING RAN UNDER AN INSTRUMENT; four falsifiable predictions with symptoms are in the finding |
+| INTEGRATOR NOTE: do not share a build dir with a background gate | meta | verified | high | 100% | 2026-09-08 | I read "98% tests passed, 1 failed" and started hunting a flaky test in a DETERMINISM project - a serious thing to chase. It was my own error: I ran an ad-hoc ctest against the same CT111 build directory while the BACKGROUND gate job was still writing binaries into it. The gate itself reported 47/47 and the shim built; 13 further clean runs (5 serial, 8 at -j4) confirm. RULE: one build directory per gate invocation, and do not query a dir while a background job owns it - the failure mode looks exactly like nondeterminism in the engine, which is the one thing this project must never misdiagnose |