applications/magicciv
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(@projects/@magic-civilization): 🐛 update generated timestamp and verify stress-test pipeline

Browse source 
Co-Authored-By: Lilith Autocommit <noreply@atlilith.com>
This commit is contained in:
Natalie 2026-04-25 06:55:57 -07:00
parent 8c37181a2c
commit 3e9b0faa85
2 changed files with 9 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.project/objectives/objectives.json
View file

@ -1,5 +1,5 @@
{
"generated_at": "2026-04-25T11:48:02Z",
"generated_at": "2026-04-25T13:54:18Z",
"totals": {
"done": 70,
"in_progress": 1,

9
.project/objectives/p0-22-ultimate-ai-stress-test.md
View file

@ -113,7 +113,14 @@ a foregone conclusion; the grid is the precondition.
**Root cause 7 (fix landed 2026-04-25, the actual blocker for huge-map gate):** apricot's `tools/autoplay-batch.sh` was an OLDER version that always computed `SAFETY_TIMEOUT = 2*TURN_LIMIT + 300`, ignoring the MCTS branch (`3× + 300` for `AI_USE_MCTS=true`). For T500 huge-map games, this meant 1300s instead of 1800s — 5-player MCTS games need ~5s/turn × 500 turns = 2500s minimum. With the EDIT host's autoplay-batch.sh now synced to apricot, safety_timeout correctly computes 1800s for T500 + AI_USE_MCTS.
**Remaining performance gap (not a bug, calibration):** Even at 1800s, 5-player MCTS games on the standard 80×52 map don't reach T500 with PARALLEL=4 (CPU contention; each game gets ~25% of one core). Re-run `huge-map-5clan-20260425_051955` showed seeds finishing at T55-T392 via timeout, never the score-victory branch. Verified the pipeline works end-to-end at smaller scales: `p0-22-vfb3-20260425_042503` (T50, 1 seed, score-victory fired with `winner=2 wp=goldvein`). Single-seed T500 verification with `SAFETY_TIMEOUT_OVERRIDE=3600 PARALLEL=1` running to confirm. The ultimate_stress gate as currently scoped (10 seeds × T500 × 5 clans on standard map at PARALLEL=4) is fundamentally CPU-bound on apricot — it needs either smaller map, lower MCTS depth, or a much larger time budget.
**Pipeline verified end-to-end at full scale (`p0-22-1seed-20260425_060458`):** 1-seed T500 huge-map run with `SAFETY_TIMEOUT_OVERRIDE=3600 PARALLEL=1` completed cleanly: `t=500 out=victory wi=3 wp=deepforge`. Score-victory branch fired correctly at the turn limit; per-slot pinning (all 5 clans assigned), combat methods (zero errors blocking gameplay), `_finalize_run` write all confirmed working on the actual huge-map config the gate requires.
**Remaining gap is purely CPU/perf, not engineering:** the 10-seed batch at PARALLEL=4 hits CPU contention — each MCTS game takes ~50 min wall-clock at PARALLEL=1, so the safety_timeout (1800s = 30 min) kills games before they reach T500 when 4 are competing for cores. To pass `ultimate_stress` as currently scoped (10 seeds × T500 × 5 clans on standard map), one of:
1. Run sequentially (`PARALLEL=1`): ~8 hours wall-clock for 10 seeds
2. Reduce parallelism (`PARALLEL=2 SAFETY_TIMEOUT_OVERRIDE=3600`): ~4 hours
3. Reduce MCTS depth or map size (rewrites the gate scope)
4. Run on faster hardware than apricot
Recommend option 1 or 2 — the system is verified to work, just needs the time budget. Status: `partial` until the full 10-seed gate runs cleanly; all 7 root causes are diagnosed and fixed, no further engineering work needed.
**Root cause 1 (fixed, confirmed):** Batch `000049` used a stale `.so` lacking `GdAiController` registration —
872 "not loaded" errors/game, tactical pass skipped, no capitals founded. Current `.so` (runs ≥035301) has 0 errors.