diff --git a/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md b/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md index ecab528..188aa2a 100644 --- a/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md +++ b/docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md @@ -2,272 +2,280 @@ > **Deployment reconciliation:** the installed Forge Server/storage migration, > pinned EP binding and restart recovery are a minimum autonomy seam. Full LAN -> discovery, Workspace Client and installer productization are parallel/post- +> discovery, Workspace Client and installer productization remain parallel/post- > autonomy nodes; see [Forge Server deployment target](FORGE_SERVER_DEPLOYMENT_TARGET.md). -**AUTHORITY = DERIVED.** Source authority is the canonical Forge roadmap and product-owned EP/Workspace contracts. This document never allocates EP or Workspace work. +> **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). -## Current bootstrap reconciliation — 2026-09-06 +**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 ```text -Forge Action-Derivation foundation (qualified) - -> EP P-NEUTRAL closure (completed predecessor; EP-owned evidence) - -> EP P-INSTALLER-V1 server-only qualification - -> DJConnect declaration + CENTRAL attachment - -> first real DJConnect EP Action - -> EP::STANDALONE_EP_VERIFIED - -> real EP self-development Action through CENTRAL - -> EP::SELF_HOSTED_ENGINEERING_VERIFIED - -> Forge repository direct-EP dogfood Action - -> Forge F3/F4 materialization/admission - -> canonical EP P-TRANSPORT HTTP submission - -> EP run/finalization/result evidence - -> Forge observation/reconciliation - -> first Forge -> EP -> Forge governed canary - -> autonomous next-Mission loop +Forge Action-Derivation foundation + -> installed EP producer + assurance + -> installed Forge Server/EP consumer + -> one approved Mission + -> Forge derives Action A + -> EP executes/finalizes A + -> Forge reconciles A + -> Forge replans same Mission from evidence + -> Forge derives successor B without owner relay + -> EP executes B + -> optional B2/C from new evidence + -> evidence-proven Mission completion ``` +This is the first real Forge -> EP -> Forge autonomy proof. It is deliberately stronger than a predeclared `A -> B` scheduler script. + ## Critical corrections -- P-TRANSPORT is merged/closed and provides HTTP, installed CLI and Server-owned File Inbox submission transports. Forge reuses HTTP. -- P-NEUTRAL is a completed EP predecessor; its closure evidence and any later - status are EP-owned and must be resolved from fresh EP `origin/main`. -- The earlier read-only Local Consumer API and later P-TRANSPORT HTTP mutation ingress are distinct. -- P-INSTALLER-V1 is a server-only installed-product qualification gate before real-project execution; it does not install Forge, Workspace or generalized Agent productization. -- B8R identity comes from committed `.engineering-platform/repository.json`, not Workspace/runtime/path inference. -- Workspace is not a runtime prerequisite for first standalone or Forge autonomy canaries. -- General Agent separation, generalized dispatch, multi-host scheduling and multi-repository parallel mutation are follow-on unless a real canary proves a concrete dependency. -- Broad P-QUEUE/B8E labels are not blanket blockers; only concrete execution/finalization/evidence gaps discovered by the canaries block progress. -- Real-project proofs deliberately separate execution-product qualification from Forge orchestration: DJConnect proves standalone, EP proves self-development, Forge direct dogfood proves EP can engineer Forge, then Forge orchestrates EP. - -`P_TRANSPORT_STATUS = MERGED_CLOSED` -`P_INSTALLER_V1_ON_CRITICAL_PATH = TRUE` -`WORKSPACE_ON_FIRST_FORGE_AUTONOMY_CRITICAL_PATH = FALSE` -`GENERAL_AGENT_SEPARATION_ON_STANDALONE_CRITICAL_PATH = FALSE` -`P_TRANSPORT_HTTP_SUBMISSION_REUSED_BY_FORGE = TRUE` +- Forge owns the Mission, Action derivation, per-Action repository target and hard logical dependency graph. +- EP owns admission, execution-resource scheduling, repository/resource leases, Agent/provider capacity, validation/review/repair, finalization and canonical execution evidence. +- EP may persist/enforce the producer-supplied dependency snapshot; it does not invent engineering dependencies. +- Workspace is not a runtime prerequisite for the first inner-Mission canary. +- General Agent fleet/distributed execution and multi-repository parallel mutation do not block the first inner-Mission canary. +- Multi-repository Action DAG execution is nevertheless a core follow-on Runtime qualification, not a replacement for the first serial proof. +- Mission completion is derived from current success evidence, not from completion of the initial Action list. + +`OWNER_SUPPLIES_APPROVED_MISSION_NOT_ACTION_SCRIPT = TRUE` +`MISSION_COMPLETION_IS_EVIDENCE_DERIVED = TRUE` +`ROADMAP_DAG_IS_NOT_LIVING_MISSION_GRAPH = TRUE` ## Capability inventory | Capability | Current status | Disposition | | --- | --- | --- | -| Forge governance/Mission/Action-Derivation foundation | QUALIFIED | KEEP; on hold for live execution integration. | -| EP P-TRANSPORT submission transport | AVAILABLE | Reuse HTTP; no duplicate transport. | -| EP P-NEUTRAL | COMPLETED predecessor (EP-owned evidence) | No longer a current Forge projection frontier. | -| EP P-INSTALLER-V1 | EP-owned current frontier at source-pinned observation | Reproducible server-only installed product. | -| DJConnect real-project standalone canary | REQUIRED AFTER INSTALLER | Earns `EP::STANDALONE_EP_VERIFIED`. | -| EP self-development through CENTRAL | REQUIRED POST-STANDALONE PRODUCER PROOF | Earns `EP::SELF_HOSTED_ENGINEERING_VERIFIED`. | -| Forge direct-EP repository dogfood | REQUIRED BEFORE/DURING FORGE INTEGRATION | Proves EP can engineer Forge without Forge orchestration. | -| Forge Action materialization + execution admission | FORGE GAP | Resume after producer proofs. | -| Forge EP observation/reconciliation | FORGE GAP | Resume with live installed producer. | -| Project Intelligence architecture seams | PREPARATION | Non-blocking contracts may be stabilized early. | -| Workspace Roadmap/DAG Governance | FOLLOW-ON CORE PRODUCT | Not required for first machine loop; consumes Forge project intelligence. | -| Workspace direct EP dogfood | FOLLOW-ON | Useful but non-blocking for first Forge autonomy. | -| General Agent/dispatch/multi-host/multi-repo | EP FOLLOW-ON | Not first-canary blockers by default. | - -## Critical execution DAG +| Forge governance/Mission/Action-Derivation foundation | QUALIFIED FOUNDATION | Keep; feed live Runtime integration. | +| EP submission/readback/terminal evidence | PRODUCER CAPABILITY | Reuse canonical authenticated HTTP. | +| 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. | +| 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. | + +## First autonomy DAG — dynamic inner Mission loop ```text - EP P-NEUTRAL (completed) - | - v - P-INSTALLER-V1 - | - v - DJConnect B8R declaration + approved Mission + | + v + Forge Mission Planner + | + v + derive Action A + | + v + immutable materialization + | + v + EP + execute/review/repair/finalize + | + v + terminal evidence A + | + v + Forge exact reconcile + | + v + refresh Project Context + | + v + evaluate Mission success + / \ + complete work remains + | | + v v + Mission COMPLETE replan graph | v - real DJConnect EP Action + derive B / B2 / C | - v - STANDALONE_EP_VERIFIED - | - v - real EP self-development - | - v - SELF_HOSTED_ENGINEERING_VERIFIED - | - v - Forge direct EP dogfood - | - +----------------------+------------------+ - | | - v v -Forge planning/derivation installed EP producer -(already qualified) proven on real repos - | | - +----------------------+------------------+ - v - Forge materialize + admit - | - v - P-TRANSPORT HTTP - | - v - EP execute/finalize - | - v - Forge reconcile result - | - v - first Forge -> EP -> Forge - | - v - autonomous next Mission + +----> EP ... ``` +Qualification must prove that the owner does not predeclare B and sends no message between A and the successor decision. + +## Second autonomy DAG — cross-repository dependencies and parallel eligibility + +```text +Mission Planner / Living Mission Graph + | + +--> EP-A2 target=engineering-platform -----+ + | | + +--> FP-A2 target=forge-platform --------+ | independent => concurrently eligible + | | +EP-A5 publish qualified EP artifacts <------------+---+ + | + | hard evidence dependency + v +FP-A3 final component manifest + target=forge-platform + depends_on=[EP-A5, FP-A2] + | + v +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. + +## 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. + +Do not infer hard dependencies from project/repository membership. Do not use Action dependencies to encode execution-resource exclusion or capacity. + +A materialized dependency snapshot is immutable. Forge may change only not-yet-materialized future graph nodes/edges after new evidence. + ## Project Intelligence planning DAG -The execution DAG above is separate from the dynamic project-intelligence loop. The latter may be prepared in parallel without blocking first execution autonomy. +The Roadmap/Project Intelligence loop is separate from the Living Mission Graph: ```text - canonical Project Context - | - v - Forge Knowledge - | - v - dynamic inference - / \ - v v - Expected Missions Roadmap/DAG Insights - | | - v v - Mission Candidates Roadmap Change Proposals - | | - | v - | Workspace role-aware governance - | | - +----+-----+ - | - v - governed Mission - | - v - EP - | - evidence - | - v - refreshed Project Context +canonical Project Context + | + v +dynamic inference + / \ +Expected Missions Roadmap/DAG Insights + | | +Mission Candidates Roadmap Change Proposals + \ / + governed decisions + | + v + approved Mission + | + v + Living Mission Graph + | + v + EP + | + evidence + | + v + refreshed Project Context ``` Canonical distinctions: - Roadmap/Capability DAG = approved project direction; -- Expected Mission = dynamic non-canonical likely future work inferred from current Project Context; -- Mission Candidate = advisory concrete possible next Mission; +- Expected Mission = dynamic non-canonical likely future work; +- Mission Candidate = advisory possible next Mission; - Mission = governed canonical work; -- Roadmap/DAG Insight = Forge interpretation about plan structure; -- Roadmap Change Proposal = governed before/after changeset, advisory until approved. - -Expected Missions may appear/disappear as project knowledge changes and never become hidden backlog authority. Mission Candidates are not approved work. Forge never silently mutates canonical roadmap/DAG state. +- Living Mission Graph = dynamic Intent/Action dependency graph inside one Mission; +- Roadmap Change Proposal = governed before/after Roadmap changeset. ## V1 architecture preparation seams -Prepare these seams early enough to avoid incompatible later implementations, but do not block the first Forge -> EP -> Forge canary on their full UI/productization: - ```text -stable roadmap/capability node IDs - | -stable dependency-edge IDs +stable Mission/Intent/Action identities | -Project Context snapshot/digest provenance - | -Expected Mission identity/classification +per-Action target repository + write scope | -Mission Candidate identity/classification +hard dependency edge identity + predecessor evidence requirement | -Roadmap Change Proposal identity + before/after diff +immutable materialized Action/dependency snapshot | -evidence references +Project Context snapshot/digest provenance | -decision type / required-role metadata +exact EP receipt/artifact identity | -FACT / INFERENCE / FORECAST / RECOMMENDATION / DECISION semantics +evidence-driven Mission completion ``` -Full completion forecasting, interactive DAG editing, scenario simulation, automatic reorder proposals and multi-role Workspace approval UI are follow-on capabilities unless a concrete dependency emerges. +These seams are required before the Runtime can safely generalize beyond the first serial canary. -## Real-project qualification contracts +## Real qualification contracts -### DJConnect standalone canary +### Dynamic inner-loop canary -Required chain: P-INSTALLER-V1-qualified install -> committed declaration -> attachment -> submission -> admission -> real mutation -> canonical validation -> finalization -> immutable receipt/result/provenance -> observation. One project, one Action, serial execution. +One approved Mission enters Forge. Forge itself derives A, EP executes A, Forge reconciles A and derives a successor only if evidence says work remains. The sequence continues until Forge can prove Mission completion. -### EP self-hosted engineering canary +Required proof: -A real bounded change to `pcvantol/engineering-platform` is executed by the installed CENTRAL EP. This proves the execution product can maintain its own source repository without Forge and without legacy DJConnect execution authority. +```text +FORGE_DERIVES_ACTION_A = TRUE +FORGE_RECONCILES_A_AND_REPLANS = TRUE +FORGE_DERIVES_SUCCESSOR_WITHOUT_OWNER_MESSAGE = TRUE +SUCCESSOR_MAY_DIFFER_FROM_INITIAL_FORECAST = TRUE +FORGE_CAN_INSERT_NEW_ACTION_AFTER_NEW_EVIDENCE = TRUE +OWNER_IS_NOT_ACTION_MESSAGE_BUS = TRUE +MISSION_COMPLETION_DECIDED_FROM_EVIDENCE = TRUE +``` -### Forge direct-EP dogfood +### Cross-repository DAG canary -A real bounded change to `pcvantol/forge` is executed through EP directly, before or during Forge's orchestration integration. This avoids circular evidence: Forge does not prove its own ability to call EP using an EP path that has never independently engineered Forge. +A later approved Mission spans at least two repositories. Forge derives per-Action targets and hard dependencies. At least two independent Actions become concurrently eligible, while a dependent successor remains closed until predecessor evidence exists. -### Workspace dogfood +Required proof: -A real Workspace development Action may be added after the above. It is not a prerequisite for the first Forge autonomy loop. +```text +FORGE_DERIVES_CROSS_REPO_DEPENDENCIES = TRUE +INDEPENDENT_REPOSITORIES_BECOME_CONCURRENTLY_ELIGIBLE = TRUE +DEPENDENT_ACTION_NEVER_EXECUTES_EARLY = TRUE +ARTIFACT_EVIDENCE_UNLOCKS_SUCCESSOR = 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. ## Authority boundaries | Boundary | Owner | | --- | --- | -| Project Intelligence / Mission & roadmap reasoning | Forge | -| Canonical roadmap mutation | Existing governed project authority after applicable decision | -| Human decision UX / role-specific evidence projection | Workspace | -| Project/repository declaration | Canonical Project Authority Repository, validated by EP | -| Submission/admission/run/finalization/receipt | EP | -| HTTP submission transport | EP P-TRANSPORT | -| Run/status/evidence projection | EP | +| Mission objective/boundary governance | Applicable human governance | +| Mission/Intent/Action reasoning and hard logical dependencies | Forge | +| Per-Action repository target/write scope planning | Forge | +| Immutable submission/admission/run/finalization/receipt | EP | +| Dependency enforcement of the submitted snapshot | EP | +| Repository/resource locks and execution capacity | EP | +| Execution artifact publication | Producing product/repository through EP delivery | +| Forge Platform component composition/manifest | Forge Platform | +| Human projection and decisions | Workspace | ## Readiness chain -Autonomous Mission execution is now: - ```text -approved Mission + Planner/Living Graph PROVEN -EP P-TRANSPORT HTTP AVAILABLE -P-NEUTRAL COMPLETED PREDECESSOR (EP-owned) -P-INSTALLER-V1 EP INSTALLED-PRODUCT GAP / observed frontier -DJConnect real execution EP QUALIFICATION GAP -STANDALONE_EP_VERIFIED EP GATE -EP self-development EP PRODUCER CONFIDENCE GAP -Forge direct EP dogfood CROSS-BOUNDARY QUALIFICATION GAP -Action materialization/admission FORGE GAP -EP observation/reconciliation FORGE GAP -first Forge -> EP -> Forge canary QUALIFICATION GAP -autonomous next-Mission repetition FINAL EXECUTION AUTONOMY GAP +FIRST INNER-MISSION CANARY: +installed Forge/EP readiness + -> derive A + -> EP A + -> reconcile/replan + -> derive successor without owner relay + -> evidence-proven Mission completion + +SECOND CROSS-REPO CANARY: +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 ``` -Project Intelligence/Workspace governance productization is deliberately not inserted into this execution readiness chain. +Project Intelligence/Workspace governance and universal installer productization are not inserted into the first inner-loop readiness chain. ## Safe parallelism -- Forge may stabilize Project Context / Expected Mission / Roadmap Change Proposal contracts while live execution integration is on hold. -- Forge should not invent installed EP readiness/execution contracts ahead of real installed evidence. -- P-INSTALLER-V1 follows the completed P-NEUTRAL predecessor; resolve its live - status from fresh EP authority before reporting it as active. -- DJConnect/EP/Forge declarations and real Actions are serial qualification proofs; this does not require multi-project concurrent scheduling. -- Workspace Roadmap/DAG Governance architecture can mature separately and remain non-blocking for first machine autonomy. -- General Agent separation/dispatch/multi-host/multi-repository productization follows the first real loops unless a canary proves it necessary. - -## First Forge execution canary - -After the real-project producer proofs: - -1. create/select one new low-risk executable Mission; -2. materialize one immutable Action snapshot; -3. persist execution-admission/submission intent with idempotency/correlation; -4. POST once through existing P-TRANSPORT HTTP; -5. observe exact canonical EP run/result evidence; -6. reconcile idempotently; -7. refresh Project Context from canonical outcome evidence; -8. stop after the first canary; -9. only then activate automatic next-Mission selection. - -Forge never writes the target repository directly and never reconstructs EP authority from logs, Console state, filesystem state or direct Agent control. +- The first dynamic Mission canary may remain serial; it proves intelligence/replanning, not parallelism. +- The second canary must separate logical dependency from execution-resource constraints. +- 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. ## Roadmap-to-action rule -A derived node becomes ready only when its actual producer evidence exists. Historical phase labels cannot create artificial blockers, transport availability cannot be promoted to execution qualification, and Expected Missions/Mission Candidates cannot be promoted to approved roadmap or execution authority. Owner gates apply at genuine authority expansion points rather than every engineering repair/validation iteration. +A derived node becomes ready only when its actual producer evidence exists. A source merge is not automatically a published artifact. A published artifact without required qualification evidence is not automatically a satisfied hard dependency. Expected Missions/Mission Candidates are not executable authority. -Reconcile this DAG whenever canonical Forge, EP or Workspace roadmap authority changes. +Reconcile this DAG whenever canonical Forge, EP, Forge Platform or Workspace authority changes. 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 new file mode 100644 index 0000000..7d9300e --- /dev/null +++ b/docs/architecture/LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md @@ -0,0 +1,185 @@ +# Living Mission Graph and cross-repository Engineering Action DAG + +**Status:** target Forge architecture; canonical when merged. Implementation and qualification remain separately governed. + +## 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. + +The active plan is the **Living Mission Graph**: a mutable planning graph of current Intents and not-yet-completed Engineering Actions. It is not the Roadmap DAG and it is not an EP scheduling queue. + +```text +approved Mission + -> Forge plan / Living Mission Graph + -> materialized Engineering Action + -> EP execution + -> terminal receipt / repository evidence / findings + -> Forge reconcile + Project Context refresh + -> Mission completion evaluation + -> complete, or + -> replan / add, split, supersede, reorder or retire remaining work + -> next eligible Action(s) +``` + +`OWNER_DEFINES_MISSION_BOUNDARY = TRUE` +`FORGE_DEFINES_AND_REDEFINES_ACTION_PLAN = TRUE` +`EP_EXECUTES_ACTIONS = TRUE` +`EVIDENCE_DRIVES_REPLAN = TRUE` + +## Dynamic inner Mission loop + +Forge must not require the owner to predeclare Action A, B, C or relay execution results between them. A Mission can begin with only its objective, constraints and success criteria. Forge may forecast likely work, but forecast work is not immutable backlog. + +After every material terminal result Forge: + +1. verifies and reconciles the exact EP result; +2. refreshes repository/project truth and relevant quality findings; +3. evaluates the Mission success criteria and unresolved constraints; +4. revises the Living Mission Graph when evidence changes the required work; +5. materializes only bounded eligible Actions; +6. continues without another owner message while remaining inside the approved Mission boundary. + +A result may therefore cause `A -> B -> B2 -> C`, even when `B2` was not known before B executed. A forecast successor may also disappear when the new evidence proves it unnecessary. + +A change to the Mission objective, approved scope, constitutional constraints, destructive authority or security authority remains a governance change rather than ordinary replanning. + +## Engineering Action target and immutability + +The normal V1 planning unit is **one Engineering Action targeting one repository**. The Action snapshot carries the repository identity and bounded write scope required by EP admission. Cross-repository outcomes are normally decomposed into separate Actions connected by dependency edges rather than one opaque multi-repository prompt. + +Conceptually an Action snapshot must be able to carry: + +```text +EngineeringAction + id / revision + mission_id / mission_revision + intent_id / intent_revision + target_repository_id + write_scope + objective + acceptance / expected evidence + depends_on[] + dependency evidence requirements +``` + +A planned node may change before materialization. Once an Action is materialized for submission, its execution identity, target, objective, dependency snapshot and expected evidence are immutable. New evidence creates a new/revised successor Action or graph edge; Forge never rewrites historical execution identity. + +`UNMATERIALIZED_PLAN_MAY_CHANGE = TRUE` +`MATERIALIZED_ACTION_IS_IMMUTABLE = TRUE` + +## Hard dependencies + +`depends_on` means a **hard logical execution dependency**: the successor is not eligible for dispatch until the required predecessor completion evidence exists and satisfies the dependency requirement. + +Hard dependencies are planned by Forge. EP may durably persist and enforce the supplied dependency snapshot, but EP must not invent product or engineering dependencies. + +A hard edge may exist within one repository or across repositories. Cross-repository edges are first-class because product delivery often spans independently owned repositories. + +Do not overload `depends_on` with scheduling preference, forecast likelihood, shared-repository exclusion or Agent capacity. Those are separate concerns. + +## Logical dependency, resource exclusion and capacity are separate + +Three independent mechanisms determine whether work can run now: + +1. **Logical dependency — Forge-owned plan.** Example: final installer manifest depends on published qualified EP artifacts. +2. **Repository/resource exclusion — EP-owned execution safety.** Independent Actions may still serialize when they require the same exclusive repository lease or other execution resource. +3. **Agent/provider capacity — EP-owned admission/placement.** Independent, lock-compatible Actions may still wait when no qualified execution capacity is available. + +Consequently two Actions in different repositories with no dependency should be eligible for parallel execution when EP has safe capacity. Different repositories do not imply independence, and the same project does not imply serialization. + +## Evidence-gated cross-repository unlock + +A dependency can require a concrete producer artifact rather than merely a predecessor status flag. The predecessor Action DoD defines the evidence required to unlock the successor. + +Example Mission: **make Engineering Platform Execution Agents production-ready and installable through Forge Platform**. + +```text +EP-A1 Agent contract + |\ + | +--> EP-A2 Agent runtime -------------------+ + | | + +----> EP-A3 Server <-> Agent protocol ------+--> EP-A4 qualification/package + | + v + EP-A5 publish qualified artifacts + server wheel + agent wheel + source revision + artifact SHA-256 + | + +-------------------------+ + | +FP-A1 installer Agent role/model --> FP-A2 installer support -----------------+--> FP-A3 final component manifest + | + v + FP-A4 installer qualification +``` + +`EP-A2/EP-A3` work and `FP-A1/FP-A2` work can advance in parallel when their own dependencies and EP execution resources permit. `FP-A3` has hard dependencies on both the installer implementation and `EP-A5`. It cannot finalize the component manifest until qualified artifacts actually exist. + +The artifact-producing predecessor should expose at least the installable artifact identity, artifact digest, source revision and relevant qualification/provenance references. A source commit alone is not sufficient proof of the bytes the installer will install. + +## Dispatch and EP enforcement boundary + +Forge determines which Actions exist, their repository target and their `depends_on` graph. Forge should normally submit only currently eligible Actions. The immutable submission also carries enough predecessor identity/evidence requirements for EP to fail closed if an ineligible successor is presented. + +EP owns admission, repository leases, execution capacity, run state, validation/review/repair and terminal evidence. A dependency check by EP enforces the producer-supplied plan; it does not transfer planning authority to EP. + +```text +Forge Living Mission Graph + -> eligible Action snapshot + dependency requirements + -> EP admission + hard predecessor evidence satisfied? + repository/resource lease available? + qualified Agent/provider capacity available? + -> dispatch or durable wait +``` + +## 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 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. + +## Mission completion + +Mission completion is not defined as “all Actions from the initial plan are COMPLETE”. The initial plan is provisional. + +After reconciliation Forge must prove that the approved Mission success criteria are satisfied from current evidence and that no unresolved required work remains inside the Mission boundary. Only then may it mark the Mission complete. + +A complete set of initially forecast Actions is insufficient if evidence exposes new required work. Conversely, Forge must not execute forecast work that is no longer necessary merely because it once existed in the graph. + +`MISSION_COMPLETION_IS_EVIDENCE_DERIVED = TRUE` +`INITIAL_ACTION_LIST_IS_NOT_COMPLETION_AUTHORITY = TRUE` + +## Qualification sequence + +Two separate real-world qualifications are required. + +### Dynamic inner-loop canary + +Input is one approved Mission, not a predeclared A/B script. Qualification proves: + +```text +FORGE_DERIVES_ACTION_A = TRUE +ACTION_A_EXECUTED_BY_EP = TRUE +FORGE_RECONCILES_A_AND_REPLANS = TRUE +FORGE_DERIVES_SUCCESSOR_WITHOUT_OWNER_MESSAGE = TRUE +SUCCESSOR_MAY_DIFFER_FROM_INITIAL_FORECAST = TRUE +FORGE_CAN_INSERT_NEW_ACTION_AFTER_NEW_EVIDENCE = TRUE +MISSION_COMPLETION_DECIDED_FROM_EVIDENCE = TRUE +OWNER_IS_NOT_ACTION_MESSAGE_BUS = TRUE +``` + +### Cross-repository DAG canary + +A later Mission spans at least two repositories and proves: + +```text +FORGE_DERIVES_CROSS_REPO_DEPENDENCIES = TRUE +INDEPENDENT_REPOSITORIES_BECOME_CONCURRENTLY_ELIGIBLE = TRUE +DEPENDENT_ACTION_NEVER_EXECUTES_EARLY = TRUE +ARTIFACT_EVIDENCE_UNLOCKS_SUCCESSOR = 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. diff --git a/docs/architecture/engineering-action.md b/docs/architecture/engineering-action.md index 57eb936..c752ae6 100644 --- a/docs/architecture/engineering-action.md +++ b/docs/architecture/engineering-action.md @@ -1,4 +1,4 @@ -# Forge Engineering Action Architecture 1.11 +# Forge Engineering Action Architecture 1.12 ## Purpose and boundary @@ -7,76 +7,165 @@ the executable unit for one bounded change, documentation update, repair, qualification step, or Runtime Prompt production. It is contained by one dynamic Engineering Intent; an Intent may contain one or more Actions. -Bootstrap Mission Scheduler 2.0 implements the local Action contract, -deterministic scheduling, and Action provenance in Runtime Prompt generation. -It still adds no Action storage, authoring workflow, Runtime, provider, -Execution Host, or execution implementation. +The target semantics for cross-repository dependencies and evidence-driven +replanning are defined in +[Living Mission Graph and cross-repository Engineering Action DAG](LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md). + +Bootstrap Mission Scheduler 2.0 implements an earlier local Action contract, +deterministic scheduling, dependencies and Action provenance in Runtime Prompt +generation. Its single-in-flight and runner-wide repository assumptions are +bootstrap implementation limits, not target invariants. ## Canonical hierarchy +The established Action boundary remains explicit inside the richer feedback +loop: + ```text -Vision → Architecture → Roadmap → Mission → Mission Planner → Engineering Intent → -Engineering Action → Runtime Prompt → Execution Host → Repository → Evidence → +Mission + ↓ governs Mission Planner + ↓ creates and reconciles +Engineering Intent + ↓ contains +Engineering Action + ↓ produces +Runtime Prompt +``` + +The full evidence-driven target loop is: + +```text +Vision → Architecture → Roadmap → Mission → Mission Planner / Living Mission Graph +→ Engineering Intent → Engineering Action → Runtime Prompt → Execution Host +→ Repository → Evidence → Mission Planner / Living Mission Graph ``` | Level | Responsibility | Must not do | | --- | --- | --- | -| Mission | Is the Architect-approved contract for objective, boundaries, success criteria, and constitutional constraints. | Predeclare Intents or become executable. | -| Mission Planner | Iteratively creates and reconciles dynamic Intents from repository evidence. | Replace human governance or execute an Action. | +| Mission | Is the Architect-approved contract for objective, boundaries, success criteria, and constitutional constraints. | Predeclare an immutable Action list or become executable. | +| Mission Planner / Living Mission Graph | Iteratively creates/reconciles Intents, Actions and hard dependencies from evidence. | Replace human governance or execute work. | | Engineering Intent | Preserves tactical rationale, boundaries, validation, evidence, and traceability as a dynamic planning artifact. | Generate a Runtime Prompt directly or execute itself. | -| Engineering Action | States the smallest intentional executable unit within an Intent. | Expand its Intent, replace governance, or redefine architecture. | -| Runtime Prompt | Carries the provider-specific execution artifact generated from an Action. | Become canonical engineering knowledge. | -| Execution Host | Performs released bounded work in an execution environment. | Redefine the Action, Intent, or architecture. | -| Repository | Holds the implementation reality created by execution. | Authorize or plan work. | +| Engineering Action | States one bounded executable outcome, target repository/write scope and hard predecessor requirements. | Expand its Intent/Mission, own execution resources, or redefine architecture. | +| Runtime Prompt | Carries the provider-specific execution artifact generated from a materialized Action. | Become canonical engineering knowledge. | +| Execution Host / EP | Performs admitted bounded work and returns canonical execution evidence. | Invent Forge planning dependencies. | +| Repository | Holds implementation reality created by execution. | Authorize or plan work. | | Evidence | Records assessable repository outcomes for future planning. | Authorize or execute work. | +## Action target + +The normal V1 Action targets exactly one repository. The materialized Action +snapshot must carry the stable target repository identity and bounded write +scope needed by EP admission. Cross-repository outcomes should normally be +decomposed into independent repository-targeted Actions connected by hard +`depends_on` edges. + +This makes execution evidence, locks/leases, ownership and retries explicit. +A future atomic multi-repository Action requires a separately qualified contract +and is not implied by this model. + +Conceptual target fields include: + +```text +id / revision +mission_id / mission_revision +intent_id / intent_revision +target_repository_id +write_scope +objective +acceptance / expected_evidence +depends_on[] +dependency_evidence_requirements +``` + +## Hard `depends_on` semantics + +`depends_on` expresses a **Forge-owned hard logical dependency**. A successor is +not execution-eligible until each required predecessor has terminal success and +the predecessor evidence required by the edge exists. + +Dependencies may cross repository boundaries. Examples include: + +- an installer manifest Action waiting for a producer's qualified artifact; +- a documentation/client Action waiting for a versioned API contract; +- a release Action waiting for package publication and validation evidence. + +`depends_on` does not mean: + +- “same repository”; +- “same project”; +- preferred ordering; +- Agent/provider capacity; +- repository lock contention; +- forecast likelihood. + +Those concerns remain separate. Forge plans logical dependencies. EP owns +admission, execution-resource exclusion and capacity. + +## Materialization and immutability + +An unmaterialized graph node may be changed, split, superseded, reordered or +removed by Forge as new evidence arrives. Once an Action is materialized for +submission its execution identity, target, objective, dependency snapshot and +expected evidence are immutable. + +If evidence changes the required work, Forge creates/revises future graph nodes +or edges. It never rewrites an already materialized or executed Action to make +history fit the new plan. + ## Why the Action boundary exists An Intent preserves tactical meaning across a coherent body of engineering: why it exists, its boundaries, how it is validated, expected evidence, and its architectural traceability. That scope can legitimately include several -independent changes. Treating an Intent as one executable prompt collapses -tactical meaning into provider wording and forces a false one-to-one mapping. +independent changes, including changes in different repositories. + +Treating an Intent as one executable prompt collapses tactical meaning into +provider wording and prevents the Runtime from expressing safe parallel work +and precise hard dependencies. Actions are therefore the graph nodes that +cross the planning-to-execution boundary. -An Action therefore has one bounded outcome that can be released for execution -without silently selecting or enlarging adjacent Intent work. It is the stable -handoff from tactical planning to a transient Runtime Prompt while retaining -the distinction between canonical knowledge and provider-specific material. +## Scheduler and EP boundary -## Relationships and scheduler impact +Forge may release more than one dependency-eligible Action from one Mission. +Each Action is submitted independently with its immutable repository/dependency +snapshot. EP validates the producer-supplied predecessor requirements, then +applies its own admission, repository/resource lease, Agent capability and +capacity rules. + +A dependency wait and a resource wait are different facts: ```text -Mission - ↓ governs -Mission Planner - ↓ creates and reconciles -Engineering Intent - ↓ contains -Engineering Action - ↓ produces -Runtime Prompt - ↓ guides -Execution Host - ↓ changes -Repository - ↓ provides -Evidence - ↓ informs -Mission Planner +WAITING_DEPENDENCY -> Forge-planned predecessor evidence is absent +WAITING_RESOURCE/LEASE -> plan allows execution but EP cannot safely admit it yet +WAITING_CAPACITY -> plan allows execution but qualified execution capacity is unavailable +``` + +EP enforcing a submitted dependency does not make EP the planner. + +## Evidence-gated successor example + +For a Mission that makes EP Execution Agents installable, Forge may derive: + +```text +EP-A5 publish qualified server/agent artifacts + -> evidence: artifact identity + SHA-256 + source revision + qualification refs + +FP-A3 final Forge Platform component manifest + depends_on = [EP-A5, FP-A2-installer-support] ``` -The Bootstrap Mission Scheduler coordinates released Engineering Actions, -not Engineering Intents. Releasing an Action is the only scheduling operation -implied here; it does not approve an Intent, generate a prompt, operate a -provider, execute a repository change, or assess evidence. +`FP-A3` may not finalize merely because EP source is merged. It requires the +actual installable artifact evidence specified by `EP-A5`. -## Compatibility and next increment +## Compatibility and next increments -Earlier direct Intent-to-prompt wording is historical architecture and must not -be extended as the canonical future path. A future migration, if needed, -requires a separately authorized capability. +The existing `EngineeringAction.dependencies` field is the bootstrap seed for +this graph, but the current scheduler permits only one in-flight Action and the +current runner binds one repository to the whole runner. Target implementation +must move repository identity to the Action/submission boundary and support +multiple independently eligible in-flight Actions. -The recommended next increment is the first AI-assisted Mission Planner. It -may propose new Engineering Intents from repository evidence within explicit -human-governed Mission boundaries, without executing work. +First qualify dynamic evidence-driven Action derivation inside one Mission. +Then qualify cross-repository dependencies and safe parallel eligibility using +real EP execution evidence. diff --git a/docs/architecture/engineering-mission.md b/docs/architecture/engineering-mission.md index 185b3f1..42323d5 100644 --- a/docs/architecture/engineering-mission.md +++ b/docs/architecture/engineering-mission.md @@ -8,6 +8,10 @@ architectural boundaries, success criteria, and constitutional constraints for a coherent outcome. A Mission does not prescribe individual Engineering Intents, an Intent sequence, Runtime Prompts, or execution steps. +The target runtime semantics for evidence-driven replanning, cross-repository +Action dependencies and parallel eligibility are defined in +[Living Mission Graph and cross-repository Engineering Action DAG](LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md). + This is an architecture reconciliation only. It introduces no Mission Planner implementation, scheduler, storage migration, Runtime, provider, Execution Host, Studio, repository operation, or autonomous execution. @@ -35,7 +39,7 @@ Roadmap ↓ Mission ↓ -Mission Planner +Mission Planner / Living Mission Graph ↓ Engineering Intent ↓ @@ -49,50 +53,60 @@ Repository ↓ Evidence ↓ -Mission Planner +Mission Planner / Living Mission Graph ``` -The loop is deliberate: repository evidence continuously informs the Mission -Planner's next planning decision. It is not a claim that any of these future -runtime capabilities is implemented. +The loop is deliberate: repository and execution evidence continuously informs +the Mission Planner's next planning decision. The approved Mission remains +stable while the remaining Intent/Action plan may change. ## Mission and human governance Humans approve Missions and remain responsible for governance. They do not -approve every Engineering Intent. The approved Mission is the stable human -contract; Forge is responsible for the iterative engineering planning that -operates within that contract. Evidence never broadens a Mission's objective, -boundaries, success criteria, or constitutional constraints without further -human governance. In the Solo profile, a shared Business Owner and Platform -Architect identity still creates distinct auditable approval records before -Engineering; migration to a profile with separate people needs no Mission -migration. +approve every Engineering Intent or every ordinary Action iteration inside the +approved boundary. The approved Mission is the stable human contract; Forge is +responsible for iterative engineering planning inside it. Evidence never +broadens a Mission's objective, boundaries, success criteria, destructive +authority, security authority, or constitutional constraints without further +human governance. + +In the Solo profile, a shared Business Owner and Platform Architect identity +still creates distinct auditable approval records before Engineering; migration +to a profile with separate people needs no Mission migration. ## Mission Intake **Mission Intake** is the CLI-owned admission step for an approved Mission Document. It validates the approved contract and transforms it into Mission State for deterministic execution. It is not Mission Planner: Mission Planner -remains the future Forge planning responsibility for dynamic Intents within an +is Forge planning responsibility for dynamic Intents and Actions within an approved Mission. Intake neither creates executable Missions nor grants Business or Architecture Approval. The operational placement and later autonomous recommendation loop are canonical in the [Runtime Evolution Roadmap](runtime-evolution-roadmap.md). -## Mission Planner +## Mission Planner and Living Mission Graph + +The **Mission Planner** owns engineering planning, sequencing, dependency +management, progress evaluation, creation of Engineering Intents and Actions, +and reprioritisation. Its active plan is the **Living Mission Graph**. -The **Mission Planner** is Forge's future planning responsibility between an -approved Mission and dynamic Engineering Intents. It owns engineering planning, -sequencing, dependency management, progress evaluation, creation of -Engineering Intents, and reprioritisation. It continuously evaluates -repository evidence and may create, supersede, merge, split, or retire active -Intents while preserving the Mission contract. +The Planner evaluates real execution/repository evidence after every material +Action result. It may create, supersede, merge, split or retire remaining +Intents; derive new Actions; insert new hard dependency edges; remove no-longer +required planned work; and release more than one independent eligible Action. +It must preserve the Mission contract. -The Mission Planner is not a scheduler, does not execute Actions, does not -operate a repository, does not approve Missions, and does not weaken human -governance. It also never changes a Mission objective. This document defines -the responsibility only; implementation is explicitly deferred. +A human owner therefore supplies the approved Mission boundary rather than a +predeclared Action script. Forge may derive `A`, reconcile A, then determine +that `B`, `B2` and `C` are required without the owner relaying each result or +approving ordinary replanning. + +The Mission Planner is not an execution scheduler, does not operate a +repository, does not approve Missions and does not weaken human governance. EP +owns actual admission, execution-resource scheduling, locks/leases, Agent +capacity and execution evidence. ## Dynamic Engineering Intents @@ -107,25 +121,48 @@ disappear. A historical Intent remains immutable: historical records preserve the exact planning decision and its provenance, rather than being rewritten to fit a later plan. -## Actions, prompts, repositories, and evidence +## Actions, dependencies, repositories, and evidence An Engineering Action is the smallest intentional executable engineering unit. -An Action produces a provider-specific Runtime Prompt. The Execution Host uses -that prompt; the Repository records the resulting implementation reality; and -Evidence makes that reality assessable by the Mission Planner. Engineering -Intents do not directly produce Runtime Prompts. +The normal Action targets one repository and may declare hard dependencies on +other Actions, including Actions in other repositories. Forge owns those +logical dependency decisions; EP may persist and enforce the submitted +predecessor requirements during admission but does not invent the plan. + +A materialized Action produces a provider-specific Runtime Prompt. The +Execution Host uses that prompt; the target Repository records the resulting +implementation reality; and Evidence makes that reality assessable by the +Mission Planner. Engineering Intents do not directly produce Runtime Prompts. -The temporary Engineering Platform 1.5 Genesis runner is an external Execution +A materialized/submitted Action is immutable. Evidence changes the future graph +by creating or revising successor Actions; it never rewrites historical Action +identity or execution evidence. + +## Mission completion + +Mission completion is evidence-derived. It is not equivalent to completion of +the Actions that happened to be present in the first plan. + +After each reconciliation Forge evaluates the approved Mission success +criteria against current evidence. If required work remains, Forge replans. If +new evidence makes forecast work unnecessary, Forge must not execute it merely +because it once existed. Only when the success criteria are actually satisfied +and no unresolved required work remains inside the approved boundary may the +Mission become complete. + +The temporary Engineering Platform bootstrap runner is an external Execution Host during bootstrap. It does not become Forge's planner, Runtime, repository owner, or governance authority. -## Compatibility and next increment +## Compatibility and qualification Earlier Mission and Intent contracts preserve historical bootstrap provenance. Their fixed membership and direct Intent-to-prompt language is not the -canonical future architecture and must not be extended. A separately governed -migration may reconcile implementation contracts later. - -The recommended next increment is the **Bootstrap Mission Scheduler**. It -should schedule released Engineering Actions, retain Mission and Intent context, -and preserve the non-executing boundary established here. +canonical target architecture and must not be extended. + +Qualification proceeds in two steps: first one Mission proving dynamic +`Action -> evidence -> replan -> successor` without owner relay; then a later +cross-repository Mission proving Forge-derived dependency edges, parallel +eligibility for independent repositories, evidence-gated successor release and +continued replanning. The detailed proof is defined in the Living Mission Graph +architecture document. diff --git a/docs/architecture/forge-v1-bootstrap-scheduler-contract.json b/docs/architecture/forge-v1-bootstrap-scheduler-contract.json index ed393c1..370ebb6 100644 --- a/docs/architecture/forge-v1-bootstrap-scheduler-contract.json +++ b/docs/architecture/forge-v1-bootstrap-scheduler-contract.json @@ -3,381 +3,33 @@ "authority": "DERIVED", "dag_schema_version": 1, "bootstrap_coordination": "NOT_A_CANONICAL_EXECUTION_LEASE", - "dispatch_requires": [ - "SEMANTIC_READY", - "DEPENDENCY_SAFE", - "REPOSITORY_SAFE", - "APPROVED_MISSION_BOUND", - "OPERATOR_BOOTSTRAP_AUTHORIZATION" - ], + "dispatch_requires": ["SEMANTIC_READY", "DEPENDENCY_SAFE", "REPOSITORY_SAFE", "APPROVED_MISSION_BOUND", "OPERATOR_BOOTSTRAP_AUTHORIZATION"], "node_contracts": { - "F1": { - "write_scopes": [ - "RUNTIME_SERVICE", - "OPERATIONAL_STORE" - ], - "read_scopes": [ - "ARCHITECTURE_CONTRACT" - ], - "exclusive_scopes": [ - "RUNTIME_SERVICE", - "OPERATIONAL_STORE" - ], - "integration_scopes": [ - "API_SCHEMA" - ], - "dor": [ - "ARCHITECTURE_DECISION" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI" - ], - "merge_gate": [ - "ARCHITECTURE_DECISION", - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "ELEVATED" - }, - "F2": { - "write_scopes": [ - "API_SCHEMA", - "ARCHITECTURE_CONTRACT" - ], - "read_scopes": [ - "RUNTIME_SERVICE" - ], - "exclusive_scopes": [ - "API_SCHEMA", - "ARCHITECTURE_CONTRACT" - ], - "integration_scopes": [ - "RUNTIME_SERVICE" - ], - "dor": [ - "PREDECESSOR_DONE:F1", - "ARCHITECTURE_DECISION", - "SECURITY_DECISION" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI", - "SECURITY_GATE" - ], - "merge_gate": [ - "ARCHITECTURE_DECISION", - "SECURITY_DECISION", - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "HIGH" - }, - "F3": { - "write_scopes": [ - "CROSS_PRODUCT_CONTRACT", - "RUNTIME_SERVICE" - ], - "read_scopes": [ - "API_SCHEMA", - "EP_PRODUCER" - ], - "exclusive_scopes": [ - "CROSS_PRODUCT_CONTRACT" - ], - "integration_scopes": [ - "EP_ATTACHMENT" - ], - "dor": [ - "PREDECESSOR_DONE:F1", - "PREDECESSOR_DONE:F2", - "EXTERNAL_GATE" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI", - "CROSS_PRODUCT_GATE" - ], - "merge_gate": [ - "OWNER_AUTHORIZATION", - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE", - "CROSS_PRODUCT_GATE" - ], - "risk_class": "ELEVATED" - }, - "F4": { - "write_scopes": [ - "RUNTIME_SERVICE", - "CROSS_PRODUCT_CONTRACT" - ], - "read_scopes": [ - "API_SCHEMA", - "EP_PRODUCER" - ], - "exclusive_scopes": [ - "RUNTIME_SERVICE", - "CROSS_PRODUCT_CONTRACT" - ], - "integration_scopes": [ - "EP_RECEIPT" - ], - "dor": [ - "PREDECESSOR_DONE:F1", - "PREDECESSOR_DONE:F2", - "EXTERNAL_GATE" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI", - "CROSS_PRODUCT_GATE" - ], - "merge_gate": [ - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE", - "CROSS_PRODUCT_GATE" - ], - "risk_class": "HIGH" - }, - "F5": { - "write_scopes": [ - "PORTFOLIO", - "FORECAST" - ], - "read_scopes": [ - "API_SCHEMA" - ], - "exclusive_scopes": [ - "FORECAST" - ], - "integration_scopes": [ - "API_SCHEMA" - ], - "dor": [ - "PREDECESSOR_DONE:F2" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI" - ], - "merge_gate": [ - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "NORMAL_LOW" - }, - "F6": { - "write_scopes": [ - "REFINEMENT_SESSION", - "PORTFOLIO" - ], - "read_scopes": [ - "API_SCHEMA" - ], - "exclusive_scopes": [ - "REFINEMENT_SESSION" - ], - "integration_scopes": [ - "API_SCHEMA" - ], - "dor": [ - "PREDECESSOR_DONE:F2", - "BUSINESS_DECISION", - "ARCHITECTURE_DECISION" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI" - ], - "merge_gate": [ - "BUSINESS_DECISION", - "ARCHITECTURE_DECISION", - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "ELEVATED" - }, - "F7": { - "write_scopes": [ - "QUALITY" - ], - "read_scopes": [ - "API_SCHEMA", - "EP_RECEIPT" - ], - "exclusive_scopes": [ - "QUALITY" - ], - "integration_scopes": [], - "dor": [ - "PREDECESSOR_DONE:F2", - "PREDECESSOR_DONE:F4" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI" - ], - "merge_gate": [ - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "NORMAL_LOW" - }, - "F8": { - "write_scopes": [ - "KNOWLEDGE" - ], - "read_scopes": [ - "API_SCHEMA", - "EP_RECEIPT" - ], - "exclusive_scopes": [ - "KNOWLEDGE" - ], - "integration_scopes": [ - "KB_CONTRACT" - ], - "dor": [ - "PREDECESSOR_DONE:F2", - "PREDECESSOR_DONE:F4", - "EXTERNAL_GATE" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI", - "CROSS_PRODUCT_GATE" - ], - "merge_gate": [ - "HUMAN_MERGE" - ], - "post_merge": [ - "POST_MERGE_GATE" - ], - "risk_class": "ELEVATED" - }, - "F9": { - "write_scopes": [ - "PACKAGING", - "CROSS_PRODUCT_CONTRACT" - ], - "read_scopes": [ - "API_SCHEMA", - "RUNTIME_SERVICE", - "FORECAST", - "REFINEMENT_SESSION" - ], - "exclusive_scopes": [ - "PACKAGING", - "CROSS_PRODUCT_CONTRACT" - ], - "integration_scopes": [ - "WORKSPACE_ONBOARDING", - "INSTALLED_PRODUCT" - ], - "dor": [ - "PREDECESSOR_DONE:F2", - "PREDECESSOR_DONE:F3", - "PREDECESSOR_DONE:F4", - "PREDECESSOR_DONE:F5", - "PREDECESSOR_DONE:F6", - "EXTERNAL_GATE" - ], - "pre_merge": [ - "LOCAL_TEST", - "HOSTED_CI", - "BROWSER_GATE", - "CROSS_PRODUCT_GATE" - ], - "merge_gate": [ - "HUMAN_UI_REVIEW", - "HUMAN_MERGE" - ], - "post_merge": [ - "INSTALLED_PRODUCT_CANARY", - "POST_MERGE_GATE", - "CROSS_PRODUCT_GATE" - ], - "risk_class": "HIGH" - } + "F1": {"write_scopes": ["RUNTIME_SERVICE", "OPERATIONAL_STORE"], "read_scopes": ["ARCHITECTURE_CONTRACT"], "exclusive_scopes": ["RUNTIME_SERVICE", "OPERATIONAL_STORE"], "integration_scopes": ["API_SCHEMA"], "dor": ["ARCHITECTURE_DECISION"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI"], "merge_gate": ["ARCHITECTURE_DECISION", "HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "ELEVATED"}, + "F2": {"write_scopes": ["API_SCHEMA", "ARCHITECTURE_CONTRACT"], "read_scopes": ["RUNTIME_SERVICE"], "exclusive_scopes": ["API_SCHEMA", "ARCHITECTURE_CONTRACT"], "integration_scopes": ["RUNTIME_SERVICE"], "dor": ["PREDECESSOR_DONE:F1", "ARCHITECTURE_DECISION", "SECURITY_DECISION"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "SECURITY_GATE"], "merge_gate": ["ARCHITECTURE_DECISION", "SECURITY_DECISION", "HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "HIGH"}, + "F3": {"write_scopes": ["CROSS_PRODUCT_CONTRACT", "RUNTIME_SERVICE"], "read_scopes": ["API_SCHEMA", "EP_PRODUCER"], "exclusive_scopes": ["CROSS_PRODUCT_CONTRACT"], "integration_scopes": ["EP_ATTACHMENT"], "dor": ["PREDECESSOR_DONE:F1", "PREDECESSOR_DONE:F2", "EXTERNAL_GATE"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "CROSS_PRODUCT_GATE"], "merge_gate": ["OWNER_AUTHORIZATION", "HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE", "CROSS_PRODUCT_GATE"], "risk_class": "ELEVATED"}, + "F4": {"write_scopes": ["RUNTIME_SERVICE", "CROSS_PRODUCT_CONTRACT"], "read_scopes": ["API_SCHEMA", "EP_PRODUCER"], "exclusive_scopes": ["RUNTIME_SERVICE", "CROSS_PRODUCT_CONTRACT"], "integration_scopes": ["EP_RECEIPT"], "dor": ["PREDECESSOR_DONE:F1", "PREDECESSOR_DONE:F2", "EXTERNAL_GATE"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "CROSS_PRODUCT_GATE"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE", "CROSS_PRODUCT_GATE"], "risk_class": "HIGH"}, + "F5": {"write_scopes": ["PORTFOLIO", "FORECAST"], "read_scopes": ["API_SCHEMA"], "exclusive_scopes": ["FORECAST"], "integration_scopes": ["API_SCHEMA"], "dor": ["PREDECESSOR_DONE:F2"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "NORMAL_LOW"}, + "F6": {"write_scopes": ["REFINEMENT_SESSION", "PORTFOLIO"], "read_scopes": ["API_SCHEMA"], "exclusive_scopes": ["REFINEMENT_SESSION"], "integration_scopes": ["API_SCHEMA"], "dor": ["PREDECESSOR_DONE:F2", "BUSINESS_DECISION", "ARCHITECTURE_DECISION"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI"], "merge_gate": ["BUSINESS_DECISION", "ARCHITECTURE_DECISION", "HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "ELEVATED"}, + "F7": {"write_scopes": ["QUALITY"], "read_scopes": ["API_SCHEMA", "EP_RECEIPT"], "exclusive_scopes": ["QUALITY"], "integration_scopes": [], "dor": ["PREDECESSOR_DONE:F2", "PREDECESSOR_DONE:F4"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "NORMAL_LOW"}, + "F8": {"write_scopes": ["KNOWLEDGE"], "read_scopes": ["API_SCHEMA", "EP_RECEIPT"], "exclusive_scopes": ["KNOWLEDGE"], "integration_scopes": ["KB_CONTRACT"], "dor": ["PREDECESSOR_DONE:F2", "PREDECESSOR_DONE:F4", "EXTERNAL_GATE"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "CROSS_PRODUCT_GATE"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["POST_MERGE_GATE"], "risk_class": "ELEVATED"}, + "F9": {"write_scopes": ["PACKAGING", "CROSS_PRODUCT_CONTRACT"], "read_scopes": ["API_SCHEMA", "RUNTIME_SERVICE", "FORECAST", "REFINEMENT_SESSION"], "exclusive_scopes": ["PACKAGING", "CROSS_PRODUCT_CONTRACT"], "integration_scopes": ["WORKSPACE_ONBOARDING", "INSTALLED_PRODUCT"], "dor": ["PREDECESSOR_DONE:F2", "PREDECESSOR_DONE:F3", "PREDECESSOR_DONE:F4", "PREDECESSOR_DONE:F5", "PREDECESSOR_DONE:F6", "EXTERNAL_GATE"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "BROWSER_GATE", "CROSS_PRODUCT_GATE"], "merge_gate": ["HUMAN_UI_REVIEW", "HUMAN_MERGE"], "post_merge": ["INSTALLED_PRODUCT_CANARY", "POST_MERGE_GATE", "CROSS_PRODUCT_GATE"], "risk_class": "HIGH"}, + "F10": {"write_scopes": ["RUNTIME_SERVICE", "OPERATIONAL_STORE"], "read_scopes": ["API_SCHEMA", "EP_RECEIPT", "PORTFOLIO"], "exclusive_scopes": ["RUNTIME_SERVICE", "OPERATIONAL_STORE"], "integration_scopes": ["EP_RECEIPT"], "dor": ["PREDECESSOR_DONE:F3", "PREDECESSOR_DONE:F4", "PREDECESSOR_DONE:F6"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "CROSS_PRODUCT_GATE", "SECURITY_GATE"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["INSTALLED_PRODUCT_CANARY", "POST_MERGE_GATE", "CROSS_PRODUCT_GATE"], "risk_class": "HIGH"}, + "F11": {"write_scopes": ["RUNTIME_SERVICE", "CROSS_PRODUCT_CONTRACT"], "read_scopes": ["API_SCHEMA", "EP_PRODUCER", "EP_RECEIPT"], "exclusive_scopes": ["RUNTIME_SERVICE", "CROSS_PRODUCT_CONTRACT"], "integration_scopes": ["EP_PARALLEL_EXECUTION", "ARTIFACT_COMPOSITION"], "dor": ["PREDECESSOR_DONE:F10", "EXTERNAL_GATE"], "pre_merge": ["LOCAL_TEST", "HOSTED_CI", "CROSS_PRODUCT_GATE", "SECURITY_GATE"], "merge_gate": ["HUMAN_MERGE"], "post_merge": ["INSTALLED_PRODUCT_CANARY", "POST_MERGE_GATE", "CROSS_PRODUCT_GATE"], "risk_class": "HIGH"} }, "governance": { "programme_authorization": { "model": "HYBRID", - "record_required": [ - "authorization_id", - "programme_id", - "programme_version", - "dag_digest", - "approved_main_sha", - "approved_node_set", - "productization_contract_version", - "architecture_refs", - "allowed_repositories", - "allowed_write_scopes", - "exclusions", - "human_gates", - "external_gates", - "approved_by", - "approved_at", - "supersession_revocation" - ], - "stale_on": [ - "DAG_NODE_SET_CHANGE", - "NODE_OBJECTIVE_CHANGE", - "ARCHITECTURE_BOUNDARY_CHANGE", - "PRODUCTIZATION_DECISION_CHANGE", - "SECURITY_CONTRACT_CHANGE", - "WRITE_SCOPE_EXPANSION", - "EXTERNAL_PRODUCER_CHANGE", - "NEW_HUMAN_GATE", - "MISSION_OBJECTIVE_EXPANSION" - ] + "record_required": ["authorization_id", "programme_id", "programme_version", "dag_digest", "approved_main_sha", "approved_node_set", "productization_contract_version", "architecture_refs", "allowed_repositories", "allowed_write_scopes", "exclusions", "human_gates", "external_gates", "approved_by", "approved_at", "supersession_revocation"], + "stale_on": ["DAG_NODE_SET_CHANGE", "NODE_OBJECTIVE_CHANGE", "ARCHITECTURE_BOUNDARY_CHANGE", "PRODUCTIZATION_DECISION_CHANGE", "SECURITY_CONTRACT_CHANGE", "WRITE_SCOPE_EXPANSION", "EXTERNAL_PRODUCER_CHANGE", "NEW_HUMAN_GATE", "MISSION_OBJECTIVE_EXPANSION"] }, - "dispatch_authority": [ - "PROGRAMME_AUTHORIZED", - "NODE_IN_AUTHORIZED_SET", - "DOR_PASS", - "PREDECESSORS_DONE", - "EXTERNAL_GATES_PASS", - "DEPENDENCY_SAFE", - "REPOSITORY_SAFE", - "NO_UNRESOLVED_HUMAN_GATE", - "AUTHORIZATION_NOT_STALE" - ], + "dispatch_authority": ["PROGRAMME_AUTHORIZED", "NODE_IN_AUTHORIZED_SET", "DOR_PASS", "PREDECESSORS_DONE", "EXTERNAL_GATES_PASS", "DEPENDENCY_SAFE", "REPOSITORY_SAFE", "NO_UNRESOLVED_HUMAN_GATE", "AUTHORIZATION_NOT_STALE"], "scope_expansion_auto_accepted": false, "owner_authorization": { "risk_mapping": { - "NORMAL_LOW": [ - "documentation", - "isolated_non_security_logic" - ], - "ELEVATED": [ - "persistence_schema", - "cross_product_contract", - "repository_governance" - ], - "HIGH": [ - "security_auth", - "credential", - "execution_or_lease_authority", - "installer_or_update", - "remote_access", - "autonomous_mutation" - ] + "NORMAL_LOW": ["documentation", "isolated_non_security_logic"], + "ELEVATED": ["persistence_schema", "cross_product_contract", "repository_governance"], + "HIGH": ["security_auth", "credential", "execution_or_lease_authority", "installer_or_update", "remote_access", "autonomous_mutation"] }, "applicability": { "NORMAL_LOW": "NO_SEPARATE_OWNER_AUTHORIZATION", @@ -389,32 +41,8 @@ "merge_policy": { "auto_merge": false, "human_merge_required": true, - "merge_ready_requires": [ - "IMPLEMENTATION_COMPLETE", - "LOCAL_QUALIFICATION_PASS", - "EXACT_HEAD_HOSTED_CI_PASS", - "REVIEWS_RESOLVED", - "HUMAN_GATES_PASS", - "OWNER_AUTHORIZATION_IF_REQUIRED", - "NO_STALE_CONTRACT", - "MERGEABLE", - "NODE_AUTHORITY_VALID" - ], - "decision_packet": [ - "NODE", - "PR", - "EXACT_HEAD", - "RISK_CLASS", - "DOR", - "DOD", - "CI", - "REVIEWS", - "HUMAN_GATES", - "OWNER_AUTHORIZATION", - "WRITE_SCOPE", - "DEPENDENTS_UNLOCKED_AFTER_MERGE", - "KNOWN_RISKS" - ], + "merge_ready_requires": ["IMPLEMENTATION_COMPLETE", "LOCAL_QUALIFICATION_PASS", "EXACT_HEAD_HOSTED_CI_PASS", "REVIEWS_RESOLVED", "HUMAN_GATES_PASS", "OWNER_AUTHORIZATION_IF_REQUIRED", "NO_STALE_CONTRACT", "MERGEABLE", "NODE_AUTHORITY_VALID"], + "decision_packet": ["NODE", "PR", "EXACT_HEAD", "RISK_CLASS", "DOR", "DOD", "CI", "REVIEWS", "HUMAN_GATES", "OWNER_AUTHORIZATION", "WRITE_SCOPE", "DEPENDENTS_UNLOCKED_AFTER_MERGE", "KNOWN_RISKS"], "parallel_merge_reevaluation": true }, "autonomous_repair_enabled": false diff --git a/docs/architecture/forge-v1-implementation-dag.json b/docs/architecture/forge-v1-implementation-dag.json index 334d43c..a6b7942 100644 --- a/docs/architecture/forge-v1-implementation-dag.json +++ b/docs/architecture/forge-v1-implementation-dag.json @@ -6,6 +6,7 @@ "product-model", "FORGE_PRODUCTIZATION_RECONCILIATION", "FORGE_V1_PRODUCTIZATION_DECISION_CONTRACT", + "LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG", "knowledge/bootstrap/10_ROADMAP.md", "FORGE_WORKSPACE_V1_CROSS_PRODUCT_DEPENDENCIES", "FORGE_EP_V1_MIGRATION_CONTINUITY" @@ -19,9 +20,7 @@ "external_gates": [], "dor": "decision contract", "dod": "installed store, identity, migration and restart tests", - "human_gates": [ - "ARCHITECTURE_DECISION" - ], + "human_gates": ["ARCHITECTURE_DECISION"], "parallelism": "A", "v1_classification": "V1_REQUIRED" }, @@ -29,16 +28,11 @@ "id": "F2", "owner": "Forge", "state": "CONTRACT_ONLY", - "predecessors": [ - "F1" - ], + "predecessors": ["F1"], "external_gates": [], "dor": "F1", "dod": "versioned query/intent/event/error contract tests", - "human_gates": [ - "ARCHITECTURE_DECISION", - "SECURITY_DECISION" - ], + "human_gates": ["ARCHITECTURE_DECISION", "SECURITY_DECISION"], "parallelism": "B", "v1_classification": "V1_REQUIRED" }, @@ -46,18 +40,11 @@ "id": "F3", "owner": "Forge", "state": "PARTIALLY_IMPLEMENTED", - "predecessors": [ - "F1", - "F2" - ], - "external_gates": [ - "EP::PROJECT_ATTACHMENT_AND_ADMISSION_V1" - ], + "predecessors": ["F1", "F2"], + "external_gates": ["EP::PROJECT_ATTACHMENT_AND_ADMISSION_V1"], "dor": "attachment contract and qualified EP producer", - "dod": "idempotent attach/drift/recovery qualification", - "human_gates": [ - "OWNER_AUTHORIZATION" - ], + "dod": "idempotent attach/drift/recovery plus immutable repository-targeted Action/submission qualification", + "human_gates": ["OWNER_AUTHORIZATION"], "parallelism": "A", "v1_classification": "V1_REQUIRED" }, @@ -65,18 +52,11 @@ "id": "F4", "owner": "Forge", "state": "PARTIALLY_IMPLEMENTED", - "predecessors": [ - "F1", - "F2" - ], - "external_gates": [ - "EP::ENGINEERING_CONTRACT_FOUNDATION_V1_QUALIFIED" - ], + "predecessors": ["F1", "F2"], + "external_gates": ["EP::ENGINEERING_CONTRACT_FOUNDATION_V1_QUALIFIED"], "dor": "qualified EP engineering-contract producer", - "dod": "receipt reconciliation/restart/negative tests", - "human_gates": [ - "NO_HUMAN_GATE" - ], + "dod": "receipt reconciliation/restart/negative tests with evidence-driven Project Context refresh", + "human_gates": ["NO_HUMAN_GATE"], "parallelism": "E", "v1_classification": "V1_REQUIRED" }, @@ -84,15 +64,11 @@ "id": "F5", "owner": "Forge", "state": "CONTRACT_ONLY", - "predecessors": [ - "F2" - ], + "predecessors": ["F2"], "external_gates": [], "dor": "service contracts", "dod": "Roadmap DAG and materialized Forecast provenance tests", - "human_gates": [ - "NO_HUMAN_GATE" - ], + "human_gates": ["NO_HUMAN_GATE"], "parallelism": "C", "v1_classification": "V1_REQUIRED" }, @@ -100,16 +76,11 @@ "id": "F6", "owner": "Forge", "state": "PARTIALLY_IMPLEMENTED", - "predecessors": [ - "F2" - ], + "predecessors": ["F2"], "external_gates": [], "dor": "session contract", "dod": "proposal/decision/resume/audit tests", - "human_gates": [ - "BUSINESS_DECISION", - "ARCHITECTURE_DECISION" - ], + "human_gates": ["BUSINESS_DECISION", "ARCHITECTURE_DECISION"], "parallelism": "D", "v1_classification": "V1_REQUIRED" }, @@ -117,16 +88,11 @@ "id": "F7", "owner": "Forge", "state": "CONTRACT_ONLY", - "predecessors": [ - "F2", - "F4" - ], + "predecessors": ["F2", "F4"], "external_gates": [], "dor": "Action evidence contract", "dod": "observer/proposal/no-auto-policy tests", - "human_gates": [ - "NO_HUMAN_GATE" - ], + "human_gates": ["NO_HUMAN_GATE"], "parallelism": "F", "v1_classification": "V1_OPTIONAL" }, @@ -134,18 +100,11 @@ "id": "F8", "owner": "Forge", "state": "CONTRACT_ONLY", - "predecessors": [ - "F2", - "F4" - ], - "external_gates": [ - "KB::GOVERNED_LIFECYCLE" - ], + "predecessors": ["F2", "F4"], + "external_gates": ["KB::GOVERNED_LIFECYCLE"], "dor": "KB export contract", "dod": "redaction/lineage/no-certification tests", - "human_gates": [ - "NO_HUMAN_GATE" - ], + "human_gates": ["NO_HUMAN_GATE"], "parallelism": "G", "v1_classification": "POST_V1" }, @@ -153,28 +112,43 @@ "id": "F9", "owner": "Forge", "state": "CONTRACT_ONLY", - "predecessors": [ - "F2", - "F3", - "F4", - "F5", - "F6" - ], - "external_gates": [ - "Workspace::ONBOARDING_CONTROL_PLANE_V1" - ], + "predecessors": ["F2", "F3", "F4", "F5", "F6"], + "external_gates": ["Workspace::ONBOARDING_CONTROL_PLANE_V1"], "dor": "consumer contracts", "dod": "installed control-plane Goldens", - "human_gates": [ - "HUMAN_UI_REVIEW" - ], + "human_gates": ["HUMAN_UI_REVIEW"], "parallelism": "H", "v1_classification": "V1_REQUIRED" + }, + { + "id": "F10", + "owner": "Forge", + "state": "CONTRACT_ONLY", + "predecessors": ["F3", "F4", "F6"], + "external_gates": [], + "dor": "installed Forge/EP execution path plus one approved Mission boundary", + "dod": "Forge derives A, reconciles real EP evidence, replans the same Mission, derives successor without owner relay, and completes only from evidence", + "human_gates": ["NO_HUMAN_GATE"], + "parallelism": "I", + "v1_classification": "V1_REQUIRED" + }, + { + "id": "F11", + "owner": "Forge", + "state": "CONTRACT_ONLY", + "predecessors": ["F10"], + "external_gates": ["EP::MULTI_REPOSITORY_PARALLEL_EXECUTION_VERIFIED"], + "dor": "F10 plus per-Action repository targets and qualified EP multi-execution/lease/capacity capability", + "dod": "Forge derives cross-repository hard dependencies, independent repositories become concurrently eligible, predecessor artifact evidence unlocks dependent work, and Forge replans after parallel results", + "human_gates": ["NO_HUMAN_GATE"], + "parallelism": "J", + "v1_classification": "V1_REQUIRED" } ], "external_gates": [ "EP::PROJECT_ATTACHMENT_AND_ADMISSION_V1", "EP::ENGINEERING_CONTRACT_FOUNDATION_V1_QUALIFIED", + "EP::MULTI_REPOSITORY_PARALLEL_EXECUTION_VERIFIED", "Workspace::ONBOARDING_CONTROL_PLANE_V1", "KB::GOVERNED_LIFECYCLE" ], @@ -183,26 +157,13 @@ "id": "EP::PROJECT_ATTACHMENT_AND_ADMISSION_V1", "owner": "engineering-platform", "producer_capability": "idempotent canonical project registration refresh, repository/Agent attachment and admission-ready project", - "qualification_gate": "clean-install, fresh-registration, idempotency, project-routing and first-governed-execution evidence", - "current_state": "WAITING_EP_IMPLEMENTATION", - "prerequisite_trace": [ - "EP::LOCAL_CONSUMER_API_V1 (AVAILABLE_FROM_EP_MAIN)", - "EP::STANDALONE_EP_VERIFIED", - "EP::PHASE3_STANDALONE_PACKAGE_AND_INSTALL_QUALIFICATION_V1", - "EP::P_TRANSPORT_V1 (COMPLETED_PREDECESSOR; EP_OWNED_EVIDENCE)", - "EP::P_QUEUE_V1", - "EP::P_NEUTRAL_V1 (COMPLETED_PREDECESSOR; EP_OWNED_EVIDENCE)", - "EP::P_INSTALLER_V1", - "EP::P_RELEASE_V1", - "EP::PHASE_P_REAUDIT_V1", - "EP::PD_INSTALLED_PRODUCT_GOLDENS_V1", - "EP::PHASE_S_EXECUTION_PROTOCOL_FOUNDATION_V1", - "EP::B8E_ZERO_LOSS_PASS" - ], + "qualification_gate": "clean-install, fresh-registration, idempotency, project-routing and governed-execution evidence", + "current_state": "RESOLVE_FROM_FRESH_EP_AUTHORITY", + "prerequisite_trace": ["EP::P_TRANSPORT_V1", "EP installed producer"], "readiness_scope": "REQUIRES_SPECIFIC_EP_PRODUCER_ONLY", "source_provenance": { - "ep_main_sha": "222ff52a00499f2113f1df5bdd621394c12a66c5", - "observed_at": "2026-09-06T20:11:58Z", + "ep_main_sha": "d53b0eadd1385b6a208886294584aa73dfce19c8", + "observed_at": "2026-09-07", "observation_classification": "HISTORICAL_SOURCE_PIN", "current_status_resolution": "RESOLVE_FRESH_EP_ORIGIN_MAIN" } @@ -210,28 +171,29 @@ { "id": "EP::ENGINEERING_CONTRACT_FOUNDATION_V1_QUALIFIED", "owner": "engineering-platform", - "producer_capability": "capability classification, Effective DoR/DoD, proof requirements, Human Gates, immutable Action snapshots and evidence projection", + "producer_capability": "immutable Action/submission contract, validation/assurance/finalization evidence and authenticated readback", "qualification_gate": "installed-artifact contract, negative-admission, recovery and evidence-projection tests", - "current_state": "WAITING_EP_IMPLEMENTATION", - "prerequisite_trace": [ - "EP::LOCAL_CONSUMER_API_V1 (AVAILABLE_FROM_EP_MAIN)", - "EP::STANDALONE_EP_VERIFIED", - "EP::PHASE3_STANDALONE_PACKAGE_AND_INSTALL_QUALIFICATION_V1", - "EP::P_TRANSPORT_V1 (COMPLETED_PREDECESSOR; EP_OWNED_EVIDENCE)", - "EP::P_QUEUE_V1", - "EP::P_NEUTRAL_V1 (COMPLETED_PREDECESSOR; EP_OWNED_EVIDENCE)", - "EP::P_INSTALLER_V1", - "EP::P_RELEASE_V1", - "EP::PHASE_P_REAUDIT_V1", - "EP::PD_INSTALLED_PRODUCT_GOLDENS_V1", - "EP::PHASE_S_EXECUTION_PROTOCOL_FOUNDATION_V1", - "EP::B8E_ZERO_LOSS_PASS", - "EP::ENGINEERING_CONTRACT_FOUNDATION_V1" - ], + "current_state": "RESOLVE_FROM_FRESH_EP_AUTHORITY", + "prerequisite_trace": ["EP installed producer", "EP run quality assurance"], "readiness_scope": "REQUIRES_SPECIFIC_EP_PRODUCER_ONLY", "source_provenance": { - "ep_main_sha": "222ff52a00499f2113f1df5bdd621394c12a66c5", - "observed_at": "2026-09-06T20:11:58Z", + "ep_main_sha": "d53b0eadd1385b6a208886294584aa73dfce19c8", + "observed_at": "2026-09-07", + "observation_classification": "HISTORICAL_SOURCE_PIN", + "current_status_resolution": "RESOLVE_FRESH_EP_ORIGIN_MAIN" + } + }, + { + "id": "EP::MULTI_REPOSITORY_PARALLEL_EXECUTION_VERIFIED", + "owner": "engineering-platform", + "producer_capability": "durable multiple execution state, repository/resource exclusion, dependency eligibility, Agent/provider capacity and isolated evidence across independent repository lanes", + "qualification_gate": "independent repository Actions may execute concurrently while hard predecessor dependencies, resource exclusion, restart recovery and evidence isolation remain fail-closed", + "current_state": "FOLLOW_ON_EP_QUALIFICATION", + "prerequisite_trace": ["EP standalone execution", "EP multi-execution runtime", "EP repository lease/admission", "EP Agent capacity"], + "readiness_scope": "REQUIRED_FOR_F11_NOT_F10", + "source_provenance": { + "ep_main_sha": "d53b0eadd1385b6a208886294584aa73dfce19c8", + "observed_at": "2026-09-07", "observation_classification": "HISTORICAL_SOURCE_PIN", "current_status_resolution": "RESOLVE_FRESH_EP_ORIGIN_MAIN" } @@ -240,17 +202,11 @@ "id": "Workspace::ONBOARDING_CONTROL_PLANE_V1", "owner": "workspace", "producer_capability": "onboarding control plane", - "qualification_gate": "Workspace UX/accessibility/no-secondary-authority proof plus qualified EP attachment producer", - "current_state": "WAITING_CROSS_PRODUCT_QUALIFICATION", - "prerequisite_trace": [ - "EP::PROJECT_ATTACHMENT_AND_ADMISSION_V1", - "Forge::L1_BOOTSTRAP_EVIDENCE_CONTRACT for managed bootstrap only" - ], - "readiness_scope": "REQUIRES_SPECIFIC_EP_PRODUCER_ONLY", + "qualification_gate": "Workspace UX/accessibility/no-secondary-authority proof plus qualified producer contracts", + "current_state": "RESOLVE_FROM_FRESH_WORKSPACE_AUTHORITY", + "prerequisite_trace": ["Forge and EP consumer contracts"], + "readiness_scope": "NOT_FIRST_INNER_MISSION_CANARY", "source_provenance": { - "workspace_main_sha": "8c651550a46b0ed431e3f4e3acd9133d885f508f", - "observed_at": "2026-09-06T20:11:51Z", - "observation_classification": "HISTORICAL_SOURCE_PIN", "current_status_resolution": "RESOLVE_FRESH_WORKSPACE_ORIGIN_MAIN" } }, diff --git a/knowledge/bootstrap/10_ROADMAP.md b/knowledge/bootstrap/10_ROADMAP.md index 270fabf..554d79b 100644 --- a/knowledge/bootstrap/10_ROADMAP.md +++ b/knowledge/bootstrap/10_ROADMAP.md @@ -41,194 +41,153 @@ Foundation is complete. Self Engineering is underway. Runtime and Production rem The immediate objective is the shortest safe route to a real autonomous Forge operating loop, not completion of every future EP/Workspace productization capability. -`AUTONOMY_BOOTSTRAP_DONE` is earned only when Forge selects real work, -materializes a bounded Action, submits it through the installed canonical EP -machine boundary, and EP persists/adopts it, performs a real repository -mutation, validates/reviews/finalizes it, and exposes canonical terminal -evidence. Forge must then observe and exactly reconcile that result, unlock or -select a successor, and continue through repairable bounded failures without -the owner relaying prompts or results. The critical dogfood proof is -`FORGE_CAUSES_REAL_FORGE_REPOSITORY_CHANGE_VIA_EP = TRUE`. +`AUTONOMY_BOOTSTRAP_DONE` is earned only when one approved Mission enters Forge, Forge itself derives a bounded Engineering Action, submits it through the installed canonical EP machine boundary, and EP persists/adopts it, performs a real repository mutation, validates/reviews/finalizes it, and exposes canonical terminal evidence. Forge must then observe and exactly reconcile that result, re-evaluate the same Mission, derive any required successor work, and continue without the owner relaying prompts or results until Mission completion is evidence-proven. The critical dogfood proof remains `FORGE_CAUSES_REAL_FORGE_REPOSITORY_CHANGE_VIA_EP = TRUE`; the stronger autonomy proof is `OWNER_IS_NOT_ACTION_MESSAGE_BUS = TRUE`. Current qualified Forge foundation includes canonical governance persistence, Mission Intake/amendment lineage, Action-Derivation evidence, G011/provider boundaries, token-preflight binding, governed reattempt lineage, a real Action-Derivation provider canary, post-canary Security qualification and immutable canary closure. PR #40 is merged; this foundation must not be reopened without regression evidence. -Forge is intentionally **on hold for execution integration** while EP proves the external execution producer. The current critical path is: +The current critical path is: ```text -EP P-NEUTRAL closure - -> EP P-INSTALLER-V1 server-only installed-product qualification - -> DJConnect real-project declaration + CENTRAL attachment - -> one real governed DJConnect EP Action - -> EP::STANDALONE_EP_VERIFIED - -> EP self-development through CENTRAL - -> EP::SELF_HOSTED_ENGINEERING_VERIFIED - -> direct EP dogfood on Forge repository - -> Forge materialization + execution admission - -> existing EP P-TRANSPORT HTTP submission ingress - -> EP canonical run/finalization/result evidence - -> Forge result observation + reconciliation - -> first Forge -> EP -> Forge governed execution canary - -> autonomous next-Mission selection/repetition +installed EP producer + assurance evidence + -> installed Forge Server execution consumer + -> one approved Mission enters Forge + -> Forge derives Action A + -> EP executes/reviews/repairs/finalizes A + -> Forge reconciles A + refreshes Project Context + -> Forge re-evaluates the same Mission + -> Forge derives successor B without owner message when work remains + -> EP executes B + -> Forge may insert B2/C or retire forecast work from new evidence + -> Mission completion proven from evidence ``` +The outer Portfolio/Mission-Candidate loop follows this inner-Mission autonomy proof; it is not a substitute for it. + ### Critical-path corrections -1. **P-TRANSPORT is merged/closed.** EP already owns three canonical submission transports: HTTP, installed CLI and Server-owned File Inbox. Forge must reuse canonical HTTP submission ingress. -2. **Local Consumer API read-only foundation and P-TRANSPORT submission HTTP are distinct.** Describing all installed EP HTTP integration as read-only is stale. -3. **P-INSTALLER-V1 is now a required producer gate.** It qualifies only the standalone EP Server-side installed product required by the first real canary. It excludes Forge, Workspace and generalized Agent productization. -4. **Workspace is not required for the first autonomy canary.** Workspace remains human/project control plane and later projection/onboarding consumer. -5. **B8R project identity supersedes the older Workspace-ID assumption.** Durable identity is declared in `.engineering-platform/repository.json` and validated by EP. -6. **Broader Agent separation/generalized dispatch is follow-on work.** Multi-host, multi-Agent and generalized dispatch/scheduling are not default prerequisites. -7. **Queue/B8E work is evidence-driven, not blanket blocking.** Only concrete capabilities required by the installed real-project canary are immediate prerequisites. -8. **Real-project dogfooding precedes Forge orchestration.** DJConnect proves standalone; EP proves self-development; Forge then proves it can be engineered directly by EP before Forge itself orchestrates EP. -9. **Owner gates are reserved for genuine authority expansion.** Engineering repair/validation/re-review inside an approved boundary should run autonomously. - -`P_TRANSPORT_STATUS = MERGED_CLOSED` -`P_INSTALLER_V1_ON_CRITICAL_PATH = TRUE` -`P_INSTALLER_V1_SERVER_ONLY = TRUE` -`WORKSPACE_ON_FIRST_AUTONOMY_CRITICAL_PATH = FALSE` -`GENERAL_AGENT_SEPARATION_ON_FIRST_AUTONOMY_CRITICAL_PATH = FALSE` +1. **P-TRANSPORT is merged/closed.** EP already owns canonical HTTP submission/readback surfaces; Forge reuses them. +2. **Workspace is not required for the first autonomy canary.** Workspace remains human/project control plane and later projection/onboarding consumer. +3. **Owner gates are reserved for genuine authority expansion.** Engineering repair/validation/re-review and ordinary Action replanning inside an approved Mission should run autonomously. +4. **The first Forge canary is one dynamic Mission, not a predeclared A/B script.** The owner supplies Mission objective/boundary/success criteria; Forge derives and revises the Action plan. +5. **Mission completion is evidence-derived.** Finishing an initial Action list is not sufficient if new evidence exposes additional required work. +6. **Cross-repository parallelism is a separate follow-on qualification.** It must not delay the first dynamic inner loop, but it is a core Runtime capability rather than optional architecture trivia. + `P_TRANSPORT_HTTP_IS_CANONICAL_FORGE_SUBMISSION_TARGET = TRUE` -`FORGE_EXECUTION_INTEGRATION_ON_HOLD_UNTIL_EP_REAL_PROJECT_PROOFS = TRUE` +`WORKSPACE_ON_FIRST_AUTONOMY_CRITICAL_PATH = FALSE` +`OWNER_SUPPLIES_APPROVED_MISSION_NOT_ACTION_SCRIPT = TRUE` +`MISSION_COMPLETION_IS_EVIDENCE_DERIVED = TRUE` ## Installed Forge Server and peer discovery — target-productization lane -The canary's smallest Forge-owned prerequisite is an installed headless Forge -Server with central product storage outside Git, stable instance identity, -versioned HTTP application boundary, a pinned authenticated EP binding and -restart-safe migration/recovery. The legacy repository-bound runtime must -relocate without resetting grants, Missions or budgets and without dual -writers. This is architecture-defined in -[Forge Server deployment and peer-binding target](../../docs/architecture/FORGE_SERVER_DEPLOYMENT_TARGET.md). +The canary's smallest Forge-owned prerequisite is an installed headless Forge Server with central product storage outside Git, stable instance identity, versioned HTTP application boundary, a pinned authenticated EP binding and restart-safe migration/recovery. The legacy repository-bound runtime must relocate without resetting grants, Missions or budgets and without dual writers. This is architecture-defined in [Forge Server deployment and peer-binding target](../../docs/architecture/FORGE_SERVER_DEPLOYMENT_TARGET.md). + +LAN DNS-SD/mDNS candidate discovery, configured/unicast/tailnet bootstrap, Workspace peer binding and universal installer choreography are valid later productization work. They do not block the first Forge→EP→Forge loop; discovery never authorizes a peer or silently retargets an existing binding. -LAN DNS-SD/mDNS candidate discovery, configured/unicast/tailnet bootstrap, -Workspace peer binding and universal installer choreography are valid later -productization work. They do not block the first Forge→EP→Forge loop; discovery -never authorizes a peer or silently retargets an existing binding. +## Dynamic Living Mission Graph — first Runtime autonomy milestone -## Governance-minimal producer bootstrap +The canonical target is defined in [Living Mission Graph and cross-repository Engineering Action DAG](../../docs/architecture/LIVING_MISSION_GRAPH_AND_CROSS_REPOSITORY_ACTION_DAG.md). -Forge expects EP to run steps from P-NEUTRAL through self-hosted engineering under a single bounded bootstrap authority envelope wherever repository policy permits. +Forge owns the active Intent/Action dependency graph inside an approved Mission. After each terminal EP result it reconciles evidence, refreshes Project Context, evaluates Mission success criteria, and may add, split, supersede, reorder or retire not-yet-materialized work. A materialized/submitted Action remains immutable. -That means no owner micro-gates between: +The first real qualification must prove: ```text -P-NEUTRAL implementation/qualification - -> P-INSTALLER-V1 implementation/installed qualification - -> DJConnect declaration/attachment - -> DJConnect real Action - -> STANDALONE_EP_VERIFIED evidence - -> EP declaration/attachment - -> EP self-development real Action - -> SELF_HOSTED_ENGINEERING_VERIFIED evidence +FORGE_DERIVES_ACTION_A = TRUE +ACTION_A_EXECUTED_BY_EP = TRUE +FORGE_RECONCILES_A_AND_REPLANS = TRUE +FORGE_DERIVES_SUCCESSOR_WITHOUT_OWNER_MESSAGE = TRUE +FORGE_CAN_INSERT_NEW_ACTION_AFTER_NEW_EVIDENCE = TRUE +MISSION_COMPLETION_DECIDED_FROM_EVIDENCE = TRUE +OWNER_IS_NOT_ACTION_MESSAGE_BUS = TRUE ``` -Implementation defects, CI failures, installer issues, schema/host findings, -fixture/coverage corrections, bounded security-review findings and exact-head -changes caused by those bounded repairs are engineering repair loops, not owner -decisions. Evidence milestones are not owner approvals by themselves. Manual -owner input is reserved for actual authority expansion, destructive operation, -wider write scope, weakened security invariants, materially ambiguous product -decisions or a repository merge policy that explicitly requires owner merge -authorization. +This replaces a weaker canary that would predeclare Action A/B and prove only automatic scheduling. -`BOOTSTRAP_MICRO_APPROVALS_EXPECTED = FALSE` -`EP_ENGINEERING_REPAIR_LOOP_AUTONOMOUS = TRUE` -`SECURITY_REVIEW_IS_QUALIFICATION_NOT_OWNER_GATE = TRUE` - -## EP real-project producer proof required by Forge +## Cross-repository Action DAG — second Runtime autonomy milestone -### Gate 0 — `EP::P_INSTALLER_V1_QUALIFIED` +After the single-Mission inner loop is qualified, Forge must support Actions in multiple repositories with Forge-owned hard `depends_on` edges and per-Action repository targets. -Before trusting real-project execution evidence, EP must prove a reproducible installed Server product: canonical runtime/CENTRAL, Server lifecycle, canonical HTTP/CLI/File-Inbox submission transports and applicable Console/relay components. P-INSTALLER-V1 does not install Forge, Workspace or generalized Project-Agent productization. +Independent Actions in different repositories become concurrently eligible when the Living Mission Graph permits it. EP independently applies repository/resource leases, Agent capability and provider capacity. Different repositories do not imply independence; a hard cross-repository dependency remains closed until predecessor evidence satisfies its contract. -### Gate A — `EP::STANDALONE_EP_VERIFIED` - -DJConnect is the mandatory first physical project canary: +Qualification must prove: ```text -P-INSTALLER-V1-qualified installed EP - -> committed DJConnect .engineering-platform/repository.json - -> EP validates + attaches repository to CENTRAL - -> canonical P-TRANSPORT submission - -> admission/run - -> real provider/repository mutation - -> DJConnect canonical validation - -> finalization - -> immutable receipt/result/provenance - -> canonical observation +FORGE_DERIVES_CROSS_REPO_DEPENDENCIES = TRUE +INDEPENDENT_REPOSITORIES_BECOME_CONCURRENTLY_ELIGIBLE = TRUE +DEPENDENT_ACTION_NEVER_EXECUTES_EARLY = TRUE +ARTIFACT_EVIDENCE_UNLOCKS_SUCCESSOR = TRUE +EP_RESOURCE_POLICY_REMAINS_SEPARATE_FROM_FORGE_PLAN = TRUE +MISSION_REPLANS_AFTER_PARALLEL_RESULTS = TRUE ``` -### Gate B — `EP::SELF_HOSTED_ENGINEERING_VERIFIED` +A suitable dogfood Mission is: make Engineering Platform Execution Agents production-ready and installable through Forge Platform. EP implementation/package Actions and Forge Platform installer-role work may advance in parallel, while the final platform component-manifest Action must depend on actual publication of qualified EP Server/Agent artifacts and their artifact digests/source revisions. -Immediately after standalone, the installed EP executes one real bounded Engineering Platform repository change through CENTRAL. This proves EP can maintain its own product source through the same authority it exposes to consumers. +## Governance-minimal execution -### Gate C — Forge repository direct-EP dogfood +Within an approved Mission boundary, ordinary implementation, validation, quality/security review, bounded repair, exact-head requalification, evidence reconciliation and Action replanning are engineering iterations rather than new owner decisions. Manual owner input remains reserved for actual authority expansion, destructive operation, wider write scope, weakened security invariants or materially ambiguous product decisions. -Before or during Forge's execution-integration increment, the Forge repository receives its own committed B8R declaration and one real direct EP-governed development Action. This proves “EP can engineer Forge” independently from “Forge can orchestrate EP”. +`BOOTSTRAP_MICRO_APPROVALS_EXPECTED = FALSE` +`EP_ENGINEERING_REPAIR_LOOP_AUTONOMOUS = TRUE` +`FORGE_ACTION_REPLAN_INSIDE_MISSION_AUTONOMOUS = TRUE` + +## EP producer proof required by Forge -Workspace may receive the same real-project dogfood later, but it is not blocking for the first Forge autonomy loop. +Forge trusts installed EP producer capability only through explicit producer/installed evidence. The first dynamic Mission canary requires an installed EP Server with authenticated submission/readback, terminal evidence, quality/security assurance and bounded repair semantics. General Agent fleet productization and multi-repository parallel execution are not prerequisites to the first inner-loop canary. ## Immediate executable Forge slice -After the EP producer proofs above, Forge should implement/qualify one narrow F3/F4 slice: +The immediate Forge execution-integration slice is now: -1. one new low-risk Mission; -2. one immutable Action snapshot/materialization; -3. one execution-admission record with exact repository/write-scope/human-gate bindings; +1. preserve one approved Mission objective/boundary/success criteria; +2. let Forge derive the first bounded Action A from current Mission/Project Context; +3. materialize an immutable Action snapshot with exact repository/write-scope/dependency/provenance bindings; 4. persist intended submission identity/idempotency/correlation before the EP call; -5. submit once through canonical EP P-TRANSPORT HTTP; -6. observe the exact EP run through canonical status/result/evidence projections; +5. submit through canonical EP HTTP; +6. observe exact canonical EP run/result/evidence; 7. reconcile terminal evidence idempotently in Forge; -8. stop after the first real canary; -9. only then add autonomous next-Mission selection/repetition. +8. refresh Project Context and evaluate Mission completion; +9. when work remains, let Forge derive/materialize successor B without an owner message; +10. repeat evidence-driven replanning until the Mission success criteria are proven. Forge never writes the target repository directly and never reconstructs EP execution authority from logs, Console state or local process state. ## Project Intelligence and dynamic roadmap planning -Forge's existing Mission Candidate concept is the beginning of a dynamic planning layer, but it must not become a hidden second roadmap. The canonical architecture is defined in `docs/architecture/PROJECT_INTELLIGENCE_AND_DYNAMIC_PLANNING.md`. - Forge distinguishes: - **Roadmap / Capability DAG** — approved canonical direction, milestones and dependencies; -- **Expected Mission** — dynamic, confidence-bearing inference from Forge Knowledge + current Project Context about likely future work; never canonical backlog authority; +- **Expected Mission** — dynamic, confidence-bearing inference from current Project Context; never canonical backlog authority; - **Mission Candidate** — advisory concrete possible next Mission; - **Mission** — governed canonical work; +- **Living Mission Graph** — dynamic Intent/Action dependency graph inside one approved Mission; - **Roadmap/DAG Insight** — Forge inference that the approved plan may need structural change; - **Roadmap Change Proposal** — explicit before/after changeset requiring applicable governance before canonical mutation. -Expected Missions are recalculated dynamically from project context and may appear or disappear without becoming cancelled roadmap items. Mission Candidate generation should consider canonical roadmap state, architecture, completed/active Missions, EP execution evidence, business priorities, current blockers and high-confidence Expected Missions. - -Every projected intelligence claim must preserve the semantic distinction between `FACT`, `INFERENCE`, `FORECAST`, `RECOMMENDATION` and `DECISION`. +Expected Missions and Roadmap DAG are not the Living Mission Graph. The Roadmap DAG concerns approved Mission/product sequencing; the Living Mission Graph concerns dynamic engineering work inside one Mission. ### Early architecture seams to establish -These contracts are worth stabilizing before the full Workspace governance UI is built: - - stable roadmap/capability/DAG node and dependency identities; - Project Context snapshot/digest provenance; -- Expected Mission / Mission Candidate / Mission identity and lifecycle separation; -- immutable Roadmap Change Proposal identity and before/after diff semantics; +- Expected Mission / Mission Candidate / Mission identity separation; +- Living Mission Graph node/edge identity and immutable materialized Action snapshot; +- per-Action repository target and write scope; +- hard Action dependency semantics and dependency evidence requirements; - evidence references usable by Workspace; - decision type / required role metadata seam; - semantic claim classification (`FACT / INFERENCE / FORECAST / RECOMMENDATION / DECISION`). ### Not on the first execution critical path -The first Forge -> EP -> Forge canary does **not** require interactive DAG editing, probabilistic completion forecasting, automatic roadmap reordering, multi-role Workspace approval UI or automatic low-risk roadmap mutation. Those become follow-on product capabilities after the basic execution/reconciliation loop unless real evidence creates a dependency. - -### Project Completion Model — follow-on - -Forge should ultimately provide Business Workspace with a semantic project-completion and forecast projection based on weighted outcomes/capabilities, critical-path work, active Missions, high-confidence Expected Missions, historical delivery evidence and uncertainty. Forecasts should expose ranges/confidence rather than false precision. This is a core product direction, not a V1 execution gate. +The first dynamic Forge -> EP -> Forge Mission canary does **not** require interactive DAG editing, probabilistic completion forecasting, automatic Roadmap reordering, full Workspace UI, LAN discovery, universal installer completion or multi-repository parallel execution. Those remain follow-on capabilities unless real evidence creates a dependency. ## Forge + Workspace V1 implementation programme -The V1 programme is dependency/capability driven. Cross-product milestones do not allocate another repository's implementation work. Derived DAG/dependency documents are indexes/projections, not product authority. Future productization must not be promoted onto the bootstrap critical path without evidence. +The V1 programme is dependency/capability driven. Cross-product milestones do not allocate another repository's implementation work. Derived DAG/dependency documents are indexes/projections, not product authority. ## L0 — Engineering Contract Foundation -Long-term L0 remains an EP-produced rich contract for packaged baselines, capability classification, Effective DoR/DoD, readiness, proof requirements, Human Gates, workflow projection, completion enforcement and immutable Action snapshots. The first bootstrap canary consumes the minimum already-proven contracts and exposes genuinely missing producer capabilities as bounded gaps. +Long-term L0 remains an EP-produced rich contract for packaged baselines, capability classification, Effective DoR/DoD, readiness, proof requirements, Human Gates, workflow projection, completion enforcement and immutable Action snapshots. The dynamic Mission Graph adds Forge-owned repository/dependency planning semantics; it does not move execution authority from EP. ## L1 / L1-R — Bootstrap evidence and Managed repository governance @@ -240,7 +199,7 @@ Observe eligible Action outcomes and propose governed hardening after a reliable ## L4 — Workspace Quality Governance -Workspace-owned dependency marker. Workspace presents governed projections and permitted human intent; it does not become runtime authority and does not block the first Forge -> EP -> Forge machine loop. +Workspace presents governed projections and permitted human intent; it does not become runtime authority and does not block the first Forge -> EP -> Forge machine loop. ## L4-AI / L5–L10 @@ -248,34 +207,42 @@ AI exposure, Knowledge Learning, continuous dual learning and effectiveness/dist ## Authority and state rules -- Forge owns why/what: roadmap reasoning, Mission, Action intent, planning dependencies and governance proposals. -- EP owns how: submission/admission, execution lifecycle, queue/lease where applicable, provider execution, finalization, receipts and canonical execution evidence. -- Workspace owns human/project UX, role-aware decision routing and evidence projections, never execution lifecycle or Forge reasoning authority. -- Canonical Project Authority Repository declares project/repository identity; EP validates it. -- Forge records intended Action/submission identity before EP submission; EP persists canonical submission/run evidence; Forge reconciles by correlation/run identity. +- Forge owns why/what: Mission semantics, Action derivation, repository targets, logical dependencies, replanning, completion reasoning and governance proposals. +- EP owns how: submission/admission, execution lifecycle, durable dependency enforcement of the producer-supplied snapshot, repository/resource leases, Agent/provider capacity, validation/review/repair, finalization, receipts and canonical execution evidence. +- Workspace owns human/project UX and evidence projections, never execution lifecycle or Forge reasoning authority. +- A materialized Action is immutable; the not-yet-materialized Living Mission Graph may change from evidence. +- Forge records intended Action/submission identity before EP submission; EP persists canonical submission/run evidence; Forge reconciles by exact identity. - A retry never invents a second submission when the first POST outcome is ambiguous. - Provider output is never directly executable authority. - Reports, logs, browser selection and current checkout are not lifecycle authority. -- Forge inference, forecast or recommendation never silently becomes canonical roadmap state. +- Forge inference, forecast or recommendation never silently becomes canonical Roadmap state. ## Dependency guidance ```text -CURRENT EP PRODUCER BOOTSTRAP: -P-NEUTRAL - -> P-INSTALLER-V1 - -> DJConnect real Action - -> STANDALONE_EP_VERIFIED - -> EP self-development real Action - -> SELF_HOSTED_ENGINEERING_VERIFIED - -> Forge repository direct-EP dogfood - -FORGE RESUMES: -materialization/admission - -> existing P-TRANSPORT HTTP - -> result observation/reconciliation - -> first Forge -> EP -> Forge canary - -> autonomous next-Mission loop +FIRST INNER-MISSION AUTONOMY: +approved Mission + -> Forge derives A + -> EP executes A + -> Forge reconciles + replans + -> Forge derives B without owner relay + -> optional B2/C from new evidence + -> evidence-proven Mission completion + +SECOND CROSS-REPOSITORY DAG QUALIFICATION: +one Mission spanning >= 2 repositories + -> Forge derives per-Action repository targets + depends_on + -> independent Actions concurrently eligible + -> EP enforces resource/capacity separately + -> predecessor artifact/evidence unlocks dependent Action + -> Forge reconciles parallel results + replans + -> Mission completion + +OUTER LOOP: +completed Mission evidence + -> Project Intelligence / Portfolio / Roadmap + -> Mission Candidate / governance + -> next approved Mission PROJECT INTELLIGENCE PREPARATION (non-blocking): Project Context contracts @@ -283,23 +250,16 @@ Project Context contracts -> Mission Candidate reasoning -> Roadmap Change Proposal contracts -> Workspace role-aware governance projections - -FOLLOW-ON EP PRODUCTIZATION: -broader Agent separation / generalized dispatch / multi-host / multi-repository - -FOLLOW-ON CROSS-PRODUCT: -Workspace Roadmap/DAG Governance; completion forecasting; L1/L1-R hardening; Quality/AI/Knowledge maturity ``` ## Non-goals and authority constraints -- Forge does not become a second execution engine. -- EP does not become a planner or autonomously rewrite Forge policy. +- Forge does not become a second execution engine or repository-lock manager. +- EP does not become a planner or autonomously invent Forge dependency edges. - Workspace does not become Forge planning or EP execution authority. -- Forge must not duplicate the existing P-TRANSPORT submission transport. -- P-INSTALLER-V1 must not absorb Forge, Workspace or generalized Agent productization. -- Broader Agent/queue architecture must not be inserted onto the bootstrap critical path without evidence that the minimum installed canary needs it. -- Real-project dogfood does not authorize parallel multi-project mutation; serial execution is sufficient for these proofs. +- Forge must not duplicate the existing EP submission/readback transport. +- Full Agent fleet/distributed productization must not be inserted onto the first inner-loop critical path. +- Multi-repository parallelism is a later explicit qualification, not an implication of the first serial canary. - Expected Missions and Mission Candidates are not approved backlog or execution authority. - Roadmap Change Proposals require applicable governance before canonical mutation. - Product upgrades do not silently rewrite project/repository policy.