use lineages for foreach now

docs/current_roadmap.md

@@ -57,9 +57,11 @@ implementation state.
   lineage progress includes ordered `StateWrite` records, `LineageStateView`,
   foreach item `lineage_id`s, nested foreach lineage identity, root
   `RuntimeScope` / `LineageState` storage, scope-aware reads, and non-root write
-  buffering. Current direct commits are still root-frame-only via an explicit
-  helper; native subgraph completion should replace that shortcut with an
-  explicit scope/lineage commit target.
+  buffering. New concurrent foreach item writes are stored in
+  `RunState.lineages`, while `ForeachBarrierState` keeps scheduling/result
+  metadata and compatibility patches. Current direct commits are still
+  root-frame-only via an explicit helper; native subgraph completion should
+  replace that shortcut with an explicit scope/lineage commit target.
 - **Persistent run history**: add a run store before adding stable `run_id`,
   `inspect_run`, or `read_run_trace(run_id, range)` APIs. Current traces are
   returned directly from immediate run responses.

docs/superpowers/plans/2026-05-24-lineage-state-runtime.md

@@ -29,6 +29,9 @@ the compatibility subset needed before native subgraphs:
   including nested foreach frames.
 - `RunState` has root scope/lineage storage, scope-aware state views, and
   generic non-root node writes buffer into `RunState.lineages`.
+- New concurrent foreach item writes are stored in `RunState.lineages`.
+  `ForeachBarrierState` now keeps scheduling/result metadata plus compatibility
+  patches for old serialized barrier data.
 
 Direct commits currently go through `is_root_lineage_frame(frame)`, which is the
 migration shortcut for root scope/root lineage. The eventual better shape is an
@@ -36,10 +39,9 @@ explicit scope/lineage commit target, feasible once native subgraph completion
 can declare whether child writes commit to child scope, parent lineage, or only
 through boundary output bindings.
 
-Remaining work should avoid jumping straight to native subgraphs. The next
-small slice is to migrate foreach pending patch storage from
-`ForeachBarrierState` into `RunState.lineages`, or defer that and start native
-subgraph scaffolding using the current scope/lineage primitives.
+Remaining work should avoid jumping straight into a broad rewrite. The next
+small slice can start native subgraph scaffolding using the current
+scope/lineage primitives.
 
 ---
 
@@ -556,10 +558,10 @@ Expected: pass.
 
 ## Task 5: Migrate Concurrent Foreach to Lineages
 
-Status: partially implemented. Concurrent foreach child frames now have lineage
-ids, nested item lineages are tested, and pending item results persist
-`lineage_id`. Patch ownership still lives in `ForeachBarrierState`, not in a
-global lineage store.
+Status: implemented for new concurrent foreach results. Concurrent foreach
+child frames have lineage ids, nested item lineages are tested, item writes are
+stored in `RunState.lineages`, and pending item results persist `lineage_id`.
+`ForeachBarrierState.patch` remains as a compatibility fallback.
 
 **Files:**
 

docs/superpowers/specs/2026-05-24-lineage-state-runtime-design.md

@@ -26,11 +26,13 @@ The first compatibility slices are implemented:
 - Frames and runtime context carry `scope_id`, `lineage_id`, and
   `parent_lineage_id`.
 - Generic non-root frame writes are buffered into `RunState.lineages`.
+- New concurrent foreach item writes are stored in `RunState.lineages`;
+  `ForeachBarrierState` keeps item result metadata plus compatibility patches
+  for old serialized barrier data.
 
-The full `RuntimeScope` / `LineageState` store is not implemented yet.
-Currently, foreach still owns pending write storage through
-`ForeachBarrierState`; the lineage ids are identity and diagnostics, not yet the
-primary storage key.
+The full native subgraph use of `RuntimeScope` is not implemented yet.
+`ForeachBarrierState` still owns scheduling/barrier metadata, but no longer has
+to be the primary write store for new concurrent foreach item results.
 
 Direct node commits currently use the explicit root-frame helper
 `is_root_lineage_frame(frame)`. That helper still means "root scope plus root