1.9 KiB
1.9 KiB
Phase 6 — relabel API execution and wave scheduling
Goal
Execute Phase 5 batch artifacts against the configured LLM provider, schedule them in parallel waves against a shared pre-wave queue snapshot, and persist execution outcomes for later evaluation without applying names yet.
Script
scripts/execute-relabel-batches.js
Shared terms
- a batch is one model request containing one or more work items
- a wave is a set of batches executed in parallel against the same queue snapshot and reconciled only after execution and retries for that wave finish
Inputs
runs/<run-id>/queue.sqlite- Phase 5 batch-ready request artifacts
- provider and model configuration
- wave concurrency configuration
- transport retry and rate-limit configuration
Execution rules
- Phase 6 owns outbound API execution; Phase 5 stops at persisted batch artifacts and queue state
- execute batches in waves so all batches in one wave see the same pre-wave queue snapshot
- restrict each wave to one model/config in MVP
- support multiple concurrent batch requests within a wave, subject to configurable concurrency and provider rate limits
- retries for transport or provider failures should occur before the wave is closed, within configured retry limits
- transport and provider failures must be tracked separately from semantic naming failures
Outputs
- persisted wave execution metadata
- persisted batch transport outcomes and retry records
runs/<run-id>/batches/<batchId>/request.jsonruns/<run-id>/batches/<batchId>/response.json- updated artifact references in
runs/<run-id>/queue.sqlite
Verification
- confirm waves execute batches in parallel against one pre-wave snapshot
- confirm one wave uses one model/config in MVP
- confirm request and response artifacts are persisted for each executed batch
- confirm transport failures and semantic failures are recorded separately
- confirm retry handling completes before wave reconciliation closes