pcvantol · pcvantol · Sep 17, 2026 · Sep 17, 2026
diff --git a/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md b/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md
@@ -8,6 +8,15 @@
 > **Runtime planning reconciliation:** the canonical inner-Mission target is the
 > [Living Mission Graph and cross-repository Engineering Action DAG](LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md).
 
+> **Parallel-runtime refinement — 2026-09-17:** the
+> [detailed multi-Action runtime design](PARALLEL_ACTION_RUNTIME_V1.md),
+> [seven-node owning roadmap](../roadmap/PARALLEL_ACTION_RUNTIME_V1.md),
+> [documentary JSON DAG](../roadmap/parallel-action-runtime-v1.json) and
+> [PA-01..PA-26 qualification](PARALLEL_ACTION_QUALIFICATION_V1.md)
+> concretize the second milestone below. Actual execution overlap and incremental
+> result-driven release are required, not just simultaneous eligibility. All added
+> PA nodes remain PLANNED; current serial Mission 3/reset work is unchanged.
+
 **AUTHORITY = DERIVED.** Source authority is the canonical Forge roadmap and product-owned EP/Workspace/Forge Platform contracts. This document never allocates peer implementation work.
 
 ## Current bootstrap reconciliation — 2026-09-07
@@ -52,10 +61,11 @@ This is the first real Forge -> EP -> Forge autonomy proof. It is deliberately s
 | Installed Forge Server / peer binding | IMPLEMENTATION/QUALIFICATION LANE | Required before live inner-loop canary. |
 | Forge exact receipt reconciliation | IMPLEMENTATION LANE | Required before replanning from live evidence. |
 | Dynamic same-Mission `reconcile -> replan -> derive successor` | TARGET RUNTIME GAP | First autonomy canary. |
-| Per-Action repository target | TARGET RUNTIME GAP | Required before cross-repository Mission graph. |
-| Forge-owned hard `depends_on` snapshot | BOOTSTRAP SEED EXISTS | Generalize from current Action dependencies. |
-| Multiple independently eligible Actions in flight | TARGET RUNTIME GAP | Second cross-repository canary. |
-| EP dependency enforcement/resource/capacity separation | EP-OWNED TARGET | Consume producer contract; Forge does not schedule resources. |
+| Per-Action repository target | TARGET RUNTIME GAP | PA-F0/PA-F1; required before cross-repository Mission graph. |
+| Forge-owned hard `depends_on` snapshot | BOOTSTRAP SEED EXISTS | PA-F0/PA-F2 generalize current Action dependencies. |
+| Multiple independently eligible Actions in flight | TARGET RUNTIME GAP | PA-F1/PA-F2/PA-F3; actual overlap in PA-FQ, not just two eligible rows. |
+| Incremental fan-in/replan without a wave barrier | TARGET RUNTIME GAP | PA-F4; A-only successor need not wait for unrelated B. |
+| EP dependency enforcement/resource/capacity separation | EP-OWNED TARGET | Consume PA-E evidence; Forge does not schedule resources. |
 | Evidence-gated cross-repository artifact unlock | CROSS-PRODUCT TARGET | Second canary; Forge Platform manifest is reference scenario. |
 | Project Intelligence / outer Mission loop | FOLLOW-ON CORE PRODUCT | Consumes completed Mission evidence. |
 | Workspace Roadmap/DAG Governance | FOLLOW-ON CORE PRODUCT | Not required for first machine loop. |
@@ -127,6 +137,14 @@ FP-A4 installer qualification
 
 The graph expresses logical dependencies only. EP separately decides whether an eligible Action may actually run based on leases, Agent capabilities and capacity.
 
+For the qualified parallel profile, closure must also show two compatible
+independent targets actually executing in overlapping intervals. The first
+bounded scenario may use already-authorized repositories on one host rather
+than waiting for the complete installer/Agent-fleet example. Per-result
+reconciliation can release an A-only successor while B still runs; only real
+multi-parent joins wait for both. The exact PA-F/PA-E dependencies are in the
+linked owning documentary DAGs and do not add a first-canary edge.
+
 ## Dependency semantics
 
 A hard Action edge means the successor is not eligible until the required predecessor terminal-success evidence exists. The edge may also name required predecessor evidence, for example published artifact identity, artifact SHA-256, source revision and qualification/provenance references.
@@ -222,13 +240,20 @@ Required proof:
 ```text
 FORGE_DERIVES_CROSS_REPO_DEPENDENCIES = TRUE
 INDEPENDENT_REPOSITORIES_BECOME_CONCURRENTLY_ELIGIBLE = TRUE
+INDEPENDENT_ACTION_EXECUTION_INTERVALS_OVERLAP = TRUE
+PER_ACTION_TARGET_STATE_AND_EVIDENCE_ISOLATED = TRUE
 DEPENDENT_ACTION_NEVER_EXECUTES_EARLY = TRUE
 ARTIFACT_EVIDENCE_UNLOCKS_SUCCESSOR = TRUE
+INCREMENTAL_REPLAN_WITHOUT_UNRELATED_SIBLING_BARRIER = TRUE
 EP_RESOURCE_POLICY_REMAINS_SEPARATE_FROM_FORGE_PLAN = TRUE
 MISSION_REPLANS_AFTER_PARALLEL_RESULTS = TRUE
 ```
 
-The Execution Agent + Forge Platform installer-role Mission is a preferred real dogfood candidate after the corresponding EP multi-execution/lease/capacity capability is qualified.
+The Execution Agent + Forge Platform installer-role Mission remains a preferred
+larger dogfood candidate after its corresponding EP capability is qualified.
+The bounded PA-FQ canary does not require the full fleet/UI first. Actual
+concurrency, isolated state/evidence, safe recovery, complete required assurance
+and efficiency measurements are distinct proof obligations.
 
 ## Authority boundaries
 
@@ -285,9 +310,9 @@ per-Action repository target
   + multiple Action persistence/in-flight state
   + EP multi-execution/lease/capacity qualification
   -> Forge cross-repo depends_on graph
-  -> independent Actions concurrently eligible
-  -> evidence-gated successor unlock
-  -> replan after parallel results
+  -> independent Actions concurrently eligible and actually overlapping
+  -> per-result incremental reconciliation and evidence-gated successor unlock
+  -> Mission completion with all required evidence and effects accounted for
 ```
 
 Project Intelligence/Workspace governance and universal installer productization are not inserted into the first inner-loop readiness chain.
@@ -299,6 +324,9 @@ Project Intelligence/Workspace governance and universal installer productization
 - Different repositories may become concurrently eligible when Forge declares no dependency.
 - EP can still delay either Action for repository/resource/Agent/provider reasons.
 - Same-repository parallel mutation is a separate, stricter qualification and is not implied.
+- A bounded eligible frontier replaces the serial singleton only through the PA implementation and qualification; no unbounded fan-out.
+- No global wave barrier: an A-only successor can advance without unrelated B, but an A+B join waits for both.
+- An Action is not one native subagent; provider-internal delegation has separate scope/capacity/qualification boundaries.
 
 ## Roadmap-to-action rule
 

diff --git a/docs/architecture/LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md b/docs/architecture/LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md
@@ -5,6 +5,18 @@ and evidence-derived completion slice is source-delivered and deterministically
 qualified; live Forge→EP and cross-repository qualifications remain separately
 governed and unexecuted.
 
+## Parallel-runtime refinement — 2026-09-17
+
+The [Parallel Action runtime V1 design](PARALLEL_ACTION_RUNTIME_V1.md),
+[owning roadmap](../roadmap/PARALLEL_ACTION_RUNTIME_V1.md),
+[documentary DAG](../roadmap/parallel-action-runtime-v1.json) and
+[shared qualification catalogue](PARALLEL_ACTION_QUALIFICATION_V1.md)
+make the existing second Runtime milestone implementable: bounded planner
+fan-out, durable per-Action targets/state, asynchronous dispatch, incremental
+fan-in and actual EP execution overlap. All added PA implementation nodes remain
+PLANNED. This NO_BUMP design does not change the current serial Mission-3 proof,
+reset-maintenance work, active policy, credentials or installed runtime.
+
 ## Purpose
 
 An approved Mission is the stable human-governed boundary. Forge owns the dynamic engineering plan inside that boundary. It must be able to derive the first Engineering Action, reconcile real execution evidence, change the remaining plan, derive additional Actions, and stop only when Mission completion is proven by evidence.
@@ -147,16 +159,38 @@ Forge Living Mission Graph
 
 ## Parallel release from one Mission
 
-The target Runtime may release more than one eligible Action from the same Mission. It should select the maximal safe set allowed by the Living Mission Graph and submit them independently. EP remains free to serialize or delay them for execution-resource reasons.
+The target Runtime releases a **bounded eligible frontier** from the same Mission,
+not an enforced singleton or the entire backlog. Approved release/concurrency
+policy and peer capability limits constrain how many independent immutable Actions
+are offered. EP separately decides actual resource/capacity admission. Waiting due
+to a limit does not create a false logical dependency.
 
-The current Bootstrap Mission Scheduler's single in-flight Action rule is a bootstrap implementation limit, not a target invariant. The current runner-wide repository target is likewise a bootstrap limit; target architecture requires repository identity at the Action/submission boundary.
+The current Bootstrap Mission Scheduler's single in-flight Action rule and
+`_OneActionProvider` are bootstrap implementation limits, not target invariants.
+The loop-wide repository binding must become a verified per-Action mapping before
+cross-target release; two repositories require real scope, not a broader prompt.
 
 The delivered serial source slice retains that bootstrap limit. For an approved
 provider-derived scope with no Action definitions, it derives and validates an
 initial Action, reconciles canonical terminal evidence, refreshes current
 planning evidence, and may append a validated successor. Derivation lineage and
 completed materialized Actions survive a normal durable runtime reopen.
 
+The parallel refinement requires durable per-Action execution/correlation slots,
+per-repository Truth, graph revision guards and in-flight contribution reservations.
+Locks protect short state transitions, not full provider or HTTP waits. Process
+each result independently: after A succeeds, C depending only on A may start while
+B still runs. Only a real multi-parent dependency waits for both A and B. Do not
+invent a global wave barrier. Materialized siblings remain immutable during replan;
+duplicate/lost/late results cannot produce new submissions or overwrite another
+slot. See [the detailed model and recovery contract](PARALLEL_ACTION_RUNTIME_V1.md).
+
+An Engineering Action is not one subagent. Provider-internal delegation stays
+under the owning Action's scope; it neither replaces cross-repository Action
+admission nor requires a new full delivery cycle for every helper. Native nested
+implementation agents and same-repository parallel writers remain separately
+qualified, not implied by this target.
+
 ## Mission completion
 
 Mission completion is not defined as “all Actions from the initial plan are COMPLETE”. The initial plan is provisional.
@@ -173,6 +207,12 @@ exact current Repository Truth snapshot plus canonical correlated terminal Host
 evidence. Unknown or absent evidence remains unsatisfied; neither provider prose
 nor an Execution Host completion assertion has planning or completion authority.
 
+For multi-in-flight operation, success evaluation also requires that all admitted
+side effects are accounted for. No Mission COMPLETE while a sibling can still
+write, cancellation is unacknowledged or an accepted request is uncertain.
+A failed predecessor blocks its dependants without rewriting unrelated successes;
+continuation/cancellation of independent siblings follows actual impact and policy.
+
 ## Qualification sequence
 
 Two separate real-world qualifications are required.
@@ -204,10 +244,20 @@ A later Mission spans at least two repositories and proves:
 ```text
 FORGE_DERIVES_CROSS_REPO_DEPENDENCIES = TRUE
 INDEPENDENT_REPOSITORIES_BECOME_CONCURRENTLY_ELIGIBLE = TRUE
+INDEPENDENT_ACTION_EXECUTION_INTERVALS_OVERLAP = TRUE
+PER_ACTION_TARGET_STATE_AND_EVIDENCE_ISOLATED = TRUE
 DEPENDENT_ACTION_NEVER_EXECUTES_EARLY = TRUE
 ARTIFACT_EVIDENCE_UNLOCKS_SUCCESSOR = TRUE
+INCREMENTAL_REPLAN_WITHOUT_UNRELATED_SIBLING_BARRIER = TRUE
 EP_RESOURCE_POLICY_REMAINS_SEPARATE_FROM_FORGE_PLAN = TRUE
 MISSION_REPLANS_AFTER_PARALLEL_RESULTS = TRUE
 ```
 
-The Execution Agent + Forge Platform installer role is a suitable real dogfood Mission for this second qualification once the required EP multi-execution/lease/capacity capabilities are qualified.
+The Execution Agent + Forge Platform installer role remains a suitable larger
+dogfood Mission once its own prerequisites exist. The first bounded qualification
+may instead use two already-authorized repositories on one host; no Agent-fleet
+or UI dependency is added merely to prove concurrency. It must prove actual EP
+execution overlap, independent per-Action recovery, incremental fan-in, complete
+required assurance and honest time/usage accounting. See PA-01..PA-26 in the
+[qualification catalogue](PARALLEL_ACTION_QUALIFICATION_V1.md). Eligibility alone
+is no longer sufficient closure evidence for the parallel-runtime milestone.
diff --git a/docs/architecture/PARALLEL_ACTION_QUALIFICATION_V1.md b/docs/architecture/PARALLEL_ACTION_QUALIFICATION_V1.md
@@ -0,0 +1,37 @@
+# Parallel Action runtime — shared qualification cases
+
+**Status:** PLANNED tests, not executed qualification. **Increment:** `FORGE_EP_PARALLEL_ACTION_RUNTIME_V1`. **NO_BUMP.**
+The [Forge runtime design](PARALLEL_ACTION_RUNTIME_V1.md) owns graph semantics; EP's owning dependency/admission design owns execution proof. Implement tests against actual product services and isolated stores. Name exact source/artifact, policy, target and invocation scope in every receipt.
+
+| ID | Case | Required proof |
+| --- | --- | --- |
+| PA-01 | Serial compatibility and migration | Existing singleton Action maps losslessly to one slot; no replay or authority/usage reset |
+| PA-02 | Actual planner fan-out | One approved Mission produces distinct justified per-target Actions without owner Action script |
+| PA-03 | Invalid graph delta | Cycles, missing targets/edges, duplicate identity and out-of-scope nodes rejected before partial materialization |
+| PA-04 | Independent targets execute concurrently | Two real EP execution intervals overlap with independent resources; queue/eligible flags alone insufficient |
+| PA-05 | True cross-repository dependency | Free resources/capacity never allow execution before required predecessor evidence |
+| PA-06 | Evidence predicate integrity | Wrong run, target, candidate, revision or artifact rejected; source merge does not prove published qualified bytes |
+| PA-07 | Incremental fan-in | A completes while B runs; C needing only A can advance without waiting for B |
+| PA-08 | Multi-parent join | Q requiring A and B remains blocked until both exact result/artifact predicates hold |
+| PA-09 | Per-repository Truth | A progress does not overwrite B baseline; real shared-input invalidation handled explicitly |
+| PA-10 | Concurrent result updates | Out-of-order/duplicate callbacks reconcile correct slots once; no lost graph updates or double usage |
+| PA-11 | Stale planner/completion CAS | Old snapshot cannot overwrite new evidence/reservations or claim premature completion |
+| PA-12 | Partial submission and lost acknowledgement | A accepted/B uncertain remain distinct; exact B readback, no duplicate Action/request |
+| PA-13 | Runtime restart | All pending/running/uncertain slots reopen; no second writer or silent singleton truncation |
+| PA-14 | Same-repository contention | Logical independence preserved, first profile serializes shared mutable target; no fake dependency edge |
+| PA-15 | Cross-repo shared test resources | Shared ports, data-root, signing/build/release resources still exclude correctly |
+| PA-16 | Capacity and fairness | Bounded global/provider/per-target limits, no multiplication by subagents, no head-of-line starvation |
+| PA-17 | Scope and peer routing | A grant cannot authorize B target; no global rebind, new broad credential or arbitrary endpoint |
+| PA-18 | Child failure and cancellation | Unaffected success retained; dependants blocked; no unacknowledged cancellation or hidden running work |
+| PA-19 | Required reviews and delivery | Independent candidate-bound assurance for each Action; joint proof binds exact combination |
+| PA-20 | Completion with pending effects | Mission cannot COMPLETE while required work, accepted writes or uncertain cancellations remain |
+| PA-21 | No authority or budget laundering | Materialized identities immutable; retries don't become new Actions or reset allowance; no next Mission |
+| PA-22 | Readmodel/MD/JSON parity | All active Actions and wait causes represented in one scoped snapshot, no singleton/last-result disguise |
+| PA-23 | Usage/time accounting | Siblings not retry lineage; all child usage once, unknown explicit; union/elapsed versus sums labelled |
+| PA-24 | Controlled efficiency comparison | Same work and quality gates; actual overlap and measured elapsed/usage, no invented speedup |
+| PA-25 | Unsupported/disabled capability | Explicit serial-only disposition or blocker; never claim parallel qualification from fallback |
+| PA-26 | Installed real boundary | Qualified artifacts outside source checkout, real Forge→HTTP→EP and returned per-Action evidence |
+
+Qualification levels remain separate: documentary JSON/DAG checks; deterministic graph/store/HTTP fixtures; real local concurrent EP execution with a controlled provider; explicitly authorized live provider/cross-repository dogfood. A controlled provider test proves scheduling/identity, not actual model reasoning or provider efficiency. The final live canary must prove Forge-generated fan-out and incremental successor derivation as well as overlapping execution. No production CENTRAL reset, credential change or paid canary follows from this document.
+
+Prototype the scenario with two authorized repositories on one host. Distributed fleet and Workspace UI are not required. Same-repository parallel writers and native nested-agent implementation are not implied. Existing serial Mission-3 criteria remain unchanged.