feat(explore): plan-reviewen kan besvares over DAGER (U12 + asynkron U13, rad 3)
F4 gjorde "be om svar, BRUKE svarene" naabar, men bare SYNKRONT: terminal_plan_reviewer
blokkerer loekka paa et menneske ved en terminal, saa svaret maa komme mens prosessen lever.
Maalbilde §3s tidsskala er den andre - eksperten svarer dager senere, i en prosess som aldri
saa kjoeringen.
--checkpoint-dir PARKERER reviewen (FileCheckpointStorage + {run_id}-plan-review.json) og
avslutter; --resume <run_id> leser svaret fra --review-inbox i en fersk interpreter. Det
eneste som krysser prosessgrensen er disk.
MAALT FELLE (Verifiseringsloven ansikt 4): list_checkpoints (_checkpoint.py:386-388) svelger
en blokkert deserialisering til en logger.warning og returnerer TOM liste. Uten BEGGE
MagenticPlanReviewRequest/Response i allowed_checkpoint_types feiler en resume som et FRAVAER,
ikke som en feil. _ALLOWED_CHECKPOINT_TYPES har derfor EN kopi, checkpoint_storage er eneste
konstruksjonssted, og en tom listing ved park raiser CheckpointUnreadable i stedet for aa
skrive et spoersmaal ingen kan besvare.
Budsjettet og revisjons-capen spenner over suspensjonen (meter.charge(parked.tokens_spent) +
trace.ledger.extend), ellers faar hver park et helt budsjett paa nytt. Fail-closed paa
ekspertens egen fil: request_id-mismatch, ord utenfor vokabularet og revise uten innhold
refuseres alle ved navn. hitl.pending_plan_reviews er registeret over hvem som venter.
Load-bearing MAALT: 17 tester, TRETTEN mutasjoner alle roede mot HELE suiten, groenn kontroll
1059 passed / 5 skipped, golden demo-transcript.stdout byte-uendret
(ea8c534773acdbe41ae68f2c55724d69aaf8be4f).
EN MUTASJON FALSIFISERTE SUITEN (vakuoes-gate-klassen, tiende gang): detach av
trace.plan_reviews.extend(parked.plan_reviews) lot HELE suiten staa groenn - capen leser
parked.plan_reviews DIREKTE, saa den binder uansett, og de to foerste legene er identiske
under begge implementasjoner. Gaten maatte bli det TREDJE leget, der artefaktet ellers taper
dag 1s revisjon og to ulike planer deler indeks 1. Ny test skrevet mot mutasjonen foerst.
Aerlighets-grenser: hostet flate NEKTER fortsatt (synkron review ville blokkert baade
requesten og event-loekka som svarer /readiness); en park midt i loepet etter en stall har
ingen naabar sti under det skriptede manuset, saa carry-overen som betjener den drives gjennom
en CRAFTED parkert tilstand.
Ordre 20260825T114645Z-6622513622-from-portfolio-optimiser.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
6020f4453d
commit
c08ae91809
7 changed files with 1754 additions and 91 deletions
31
README.md
31
README.md
|
|
@ -461,6 +461,37 @@ when the seam is detached, so the loop cannot silently degrade into theater.
|
|||
— blocking an HTTP request on a human would also block the event loop that answers
|
||||
`/readiness`.
|
||||
|
||||
**Answering it days later (`--checkpoint-dir` / `--resume`).** A domain expert is rarely at the
|
||||
terminal when the loop reaches the plan, so the same review can be *parked* to disk instead.
|
||||
`--checkpoint-dir` writes the suspended workflow there and the open question to
|
||||
`{run_id}-plan-review.json`, and the process exits. Whenever the expert gets to it — another
|
||||
day, in a process that never saw the run — they drop `{run_id}-plan-review-answer.json` into a
|
||||
review inbox, and `--resume` picks it up:
|
||||
|
||||
```bash
|
||||
# day 1 — park the review and exit
|
||||
uv run python -m portfolio_optimiser.run FV42-GSV-E1 --docs-dir <docs> --bundle-dir <bundle> \
|
||||
--explore "Find the cheapest saving worth testing here" --explore-config exploration.json \
|
||||
--checkpoint-dir checkpoints --outbox-dir out --run-id r1
|
||||
|
||||
# day N — a fresh process, resuming from what is on disk and nothing else
|
||||
uv run python -m portfolio_optimiser.run FV42-GSV-E1 --docs-dir <docs> --bundle-dir <bundle> \
|
||||
--outbox-dir out --checkpoint-dir checkpoints --review-inbox inbox --resume r1
|
||||
```
|
||||
|
||||
A `revise` answered this way does the same thing it does at the terminal: the manager replans
|
||||
and asks again about the **new** plan. The answer names the `request_id` it answers, and a
|
||||
mismatch is refused rather than applied — two reviews of one run share a file name, so an answer
|
||||
left over from the previous round would otherwise sign off a plan the expert never saw. The
|
||||
vocabulary is the same closed one, anything outside it is refused rather than read as approval,
|
||||
and `revise` with nothing to revise is refused too. `hitl.pending_plan_reviews(outbox, inbox)`
|
||||
lists every review still waiting on somebody.
|
||||
|
||||
The budget and the revision cap span the suspension — the resumed leg starts from what the
|
||||
parked one already spent, so a park never hands back a fresh budget. `--plan-review` and
|
||||
`--checkpoint-dir` are refused together (two doors onto one review), as are `--resume` and
|
||||
`--explore` (two sources of one exploration).
|
||||
|
||||
`--explore` is refused together with `--mandate` — they are two sources of one mandate, and
|
||||
merging would silently overwrite what you wrote. To seed an exploration with a domain expert's
|
||||
own hypotheses, use `explore(..., seed_approaches=[Approach(...)])`; seeds are always preserved
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue