v0.3.1 — cross-run result seeding
Cross-run result seeding — --seed-from <runId>
When you edit a workflow file, resume correctly refuses the changed hash — and until now, every completed agent in the old run had to be re-run from scratch. Their results were sitting in the old run's journal. Now:
flowition run edited.workflow.js --seed-from flo_a1b2c3d4- Loads the settled source run's journal read-only (never repaired) and reuses its final completed agent results as a candidate cache. Derived agent keys hash branch position + prompt + canonical keyed spec — no run id, seed, or file hash — so unchanged calls match across runs while edited calls miss and run fresh.
- Weaker than resume, on purpose: key equality identifies the same call shape, not the same world. It's operator-authorized cache reuse for research/pure-result agents, never a freshness guarantee.
- Never seeded:
step()results (a completed step proves a side effect in the old world), explicit-keyagents (an explicit key matches even a rewritten call),ask()answers, provider sessions, usage baselines, and any source key that ever accepted steering mail. Target-side steering around a seeded call drops with a warning, like same-run cache replay. - Durable: a hit is written into the target journal (with
seededprovenance: source run id, index, usage) before it's returned — the target resumes normally even after the source run is deleted. Chained seeding (source → target → target) names the immediate source but keeps surfacing the original provider cost. - Zero double-billing: seeded hits add nothing to the new run's provider spend or
--budget; imported source usage is exposed separately as provenance. - Refused loudly for missing/live/corrupt/self/key-version-mismatched sources, and cannot combine with
--resume(fresh runs only). Detached runs prevalidate the source before spawning. - Surfaces everywhere:
flowition run --seed-from, MCPflowition_runseedFrom,seeded from run …in status output, and aseededFromannotation in the viewer's shared fold.
Fit zoom fix — the timeline no longer scrolls at "Fit"
Fit zoom promised no horizontal scrollbar but grew one on any run with a real span: the trailing duration/replay tag deliberately hangs past the bar it describes, so a lane ending at ~100% of the track pushed its tag beyond the edge. The timeline plot now reserves a 130px trailing meta gutter — the bar and its tag always land inside the viewport at Fit; fixed zooms (200%, 400%, …) keep scrolling by design. Pinned by a Playwright regression that drives a real-span run in a real browser.
Both changes ship with full evidence: 11 acceptance tests for seeding, a browser regression for Fit proven to bite (fails with the gutter removed), regenerated §3.7 screenshot captures, and rebound perf fingerprints. Root suite 484 tests, viewer suite 1137, Playwright 21.