Repository navigation
Conversation
…ith capacity Adds z0int.dispatch (and `z0int dispatch`): a stdlib-only dispatcher that takes typed jobs (kind, size, required quality, privacy, deadline) and assigns lanes from Kerdoios capacity. - Shadow-price cost: under-burn subscriptions inside their hourly headroom are filled first (their quota perishes at reset), free lanes add speed, the capped Nous plan is kept for checks, avoided/throttled pools are infeasible. - Hard rules: code only on opus/sol, privacy never above the provider's data policy, quality bar per job, QA never on the family it checks. - Ledger (SQLite) of every decision with alternatives and rejection reasons, every outcome, and burn-pace/Nous snapshots per batch. Quality priors and per-job subscription cost are learned from it; throttles are forwarded to Kerdoios so the lane cools down for every caller. - plan (dry run over a horizon), assign (slots now, runner ceilings), record, qa, batch, report.
…ors teach nothing A runner restart re-sent 'batch start' and replaced the burn-pace baseline, which would hide the batch's real subscription spend. Outcomes marked harness_error (a runner bug, not the model) are excluded from quality priors.
…spend A read-only Opus repo scan costs about $0.32 API-equivalent, and Hermes alone logged $520 of Claude usage this week at 52% used, so one scan is at most 0.032% of the weekly window. The old 0.05% guess held Opus to about nine scans an hour while the pool was under-burning.
…shots Batch start/end snapshots of the Nous cap notice give dollars spent; divided by the batch's finished haiku/luna jobs this replaces the per-job prior (the first QA batch measured $0.09 per Luna QA against a $0.06 prior).
…ground burn The proof batch's Claude window moved 52% -> 57% over 2.1 h while 36 Opus jobs ran, but other sessions were already burning about 1.7-1.9 %/h. Batch start now stores Kerdoios' recent burn rate per pool and the learner subtracts it, which gives about 0.03% per scan instead of 0.14%.
|
N27-REV-Z0I-178 Reviewed exact head: Acceptance criteria: The PR body does not explicitly link a numbered implementation issue. Assessment below uses its stated dispatch acceptance promises, plus the related capacity RFC #131 P1 / hard invariants as context, not as a claim that this PR implements the entire RFC.
Correctness bugs and minimal repairs (priority order):
Missing exact tests (add to Overlaps / integration: #179 is explicitly stacked on this exact head and modifies Exact-head CI, not independently executed here: Core unit passed its offline-suite jobs on Python 3.11/3.13 (3.13 log: 1177 passed, 6 skipped, 5 deselected). Evidence receipt failed: missing exact-head YAML evidence block. Claimed live batch measurements are not reverified by these results. Commands to run after fixing: Verdict: NEEDS-FIX — CLI/selection baseline exists and offline tests pass, but unleased stale-capacity dispatch, unauthenticated quality/QA feedback, dropped throttle fallback and the failing evidence receipt prevent safe promotion. Do not merge. |
What
z0int dispatch(src/z0int/dispatch.py, stdlib-only; docs indocs/dispatch.md): assigns typed factory jobs (kind scan|label|qa|review|test|code, size, required quality, privacy, deadline, avoid_family) to the cheapest lane that is good enough and has capacity now, from Kerdoioskerdoios.capacity.v1.plan(dry run),assign(slots now, runner ceilings),record,qa,batch,report.Proof (real batch, 2026-10-20)
88 jobs via the OSS-factory kitchen runner: 34/40 repo re-scans done at 10:40Z (Opus, paced at ~14/h by hourly headroom; DeepSeek/GLM free were spent), 40/40 labels (Groq 20, NIM 11, MiniMax 7, Opus 2), 6 QA (Luna, $0.54). 12 throttle events, no storm. Claude 52%→57% (batch share ≈1%), Nous $152.63→$153.17. Report:
workspace/zer0/data/operations/kitchen/scan-wave3/REPORT.md(private host path).Tests
PYTHONPATH=src pytest tests/test_dispatch.py→ 13 passed; CLI/posture/receipt/backend suites unaffected (114 passed).Draft; do not merge without the owner.