The first 12-prompt × 2-model × 2-variant sweep (48 API calls) ran 29 minutes before I killed it. A Kimi call on the 10th prompt hung indefinitely — no client-side timeout — and the harness writes scores.jsonl + report.md ONLY at the end, so partial progress was unrecoverable. Lost 9/12 completed prompts because the aggregate step never ran. Two fixes: 1. openai-compat.ts: AbortController with default 120s timeout (overridable via AB_CORPUS_CALL_TIMEOUT_MS env). When a call exceeds the budget, the harness catches the abort, records it as __HARNESS_ERROR__ (routing=garbage, M1=false), and moves on. Verified by dialing the timeout to 60s — GLM-5.1's first call took >60s, got aborted cleanly, run continued to completion instead of hanging. 2. run.ts: append each ScoreRow to scores.jsonl immediately after scoring. Truncate at start (so re-runs overwrite). Lost-work window now bounded to "the currently-executing API call," not "everything since the run started." report.md and report.json still write once at the end (aggregate needs the full set) but scores.jsonl alone is enough for any partial-run analysis. Post-hardening validation (live 方舟 CP runs): - mobile-upload-dropzone → add_upload_dropzone_v0 ✓ right-tool - dashboard-dark-modal → add_modal_shell_v1 (theme=dark) ✓ Second one is the first end-to-end proof that the v1 theme-aware tool family routes correctly with a real LLM — GLM-5.1 inferred \`theme: "dark"\` from the natural-language prompt. |
||
|---|---|---|
| .. | ||
| ab-corpus | ||
| bundle-skill.ts | ||
| ensure-agent-native.cjs | ||
| patch-srvx-bun.ts | ||
| publish-beta.sh | ||
| unpublish.sh | ||