Repair Architect Session peer-status reconciliation

ARCHITECT_SESSION.md

@@ -70,8 +70,25 @@ Knowledge lifecycle/certification remains owned by the Knowledge Base.
 
 ## Read order: peer authorities
 
-Use the checked-out and remote `main` revisions, recording the SHA/date used
-when a conclusion depends on them.
+Resolve time-sensitive peer authority through the **Peer Authority Freshness
+Contract** before drawing a current-status conclusion. A local peer checkout,
+including its filesystem timestamp, is never current authority merely because
+it is present on the host.
+
+```text
+PEER_AUTHORITY_FRESHNESS_CONTRACT
+1. Refresh the peer remote repository state.
+2. Resolve that peer's current `origin/main`.
+3. Record repository, exact SHA and UTC observation timestamp.
+4. Treat every previously observed SHA as HISTORICAL observation evidence.
+5. If refresh or resolution fails, set PEER_AUTHORITY_FRESHNESS = UNVERIFIED
+   and do not present time-sensitive peer status as current.
+```
+
+Use the resolved remote `origin/main` revision, recording its SHA and UTC
+observation time whenever a conclusion depends on peer state. The session may
+read a matching isolated worktree for convenience only after pinning it to that
+resolved SHA.
 
 | Peer | Read first | Authority to preserve |
 | --- | --- | --- |
@@ -136,14 +153,15 @@ Reconstruct faithfully, without reinterpretation:
 Label the result `CANONICAL_AS_DOCUMENTED`. Implementation evidence is not
 automatically architecture authority, and a pending PR is not merged authority.
 
-### Pass 2 — architecture reconciliation
+### Pass 2 — evidence reconciliation
 
 Test whether the sources reconstructed in Pass 1 remain mutually coherent.
 Do not automatically mutate a roadmap, DAG, or peer truth from this analysis.
 Classify a finding first, investigate repository evidence where it can resolve
 the question, and route only the appropriate durable result to its owner.
 
-For every important reported critical-path dependency, answer:
+For every important reported current capability or critical-path dependency,
+answer:
 
 ```text
 DEPENDENCY =
@@ -153,7 +171,9 @@ EVIDENCE =
 DOCUMENTED_STATUS =
 IMPLEMENTED =
 QUALIFIED =
+COMPLETION_EVIDENCE =
 AVAILABLE_TO_CONSUMER =
+CURRENT_RECONCILED_STATUS =
 CLASSIFICATION =
 RATIONALE =
 ```
@@ -166,10 +186,23 @@ canonical source, or proposed for change in a pending PR. Ask whether the whole
 umbrella gate is needed or only a bounded producer capability inside it, and
 whether the edge is an authority requirement rather than historic sequencing.
 
-Always distinguish `ARCHITECTURE_REQUIRED`, `IMPLEMENTED`, `QUALIFIED`,
-`AVAILABLE_TO_CONSUMER`, and `DOCUMENTED_STATUS`. None implies another. For
-example, a capability may be required but implemented, implemented but not
-qualified, or qualified while a roadmap projection remains stale.
+Always distinguish `ARCHITECTURE_REQUIRED`, `DOCUMENTED_STATUS`,
+`IMPLEMENTED`, `QUALIFIED`, `COMPLETION_EVIDENCE`, `AVAILABLE_TO_CONSUMER` and
+`CURRENT_RECONCILED_STATUS`. None implies another. A merged closure or
+qualification record must be checked to ensure it applies to the same
+capability. If it does and a roadmap/DAG/status projection still says
+`ACTIVE`, `PLANNED` or `INCOMPLETE`, classify the finding
+`STALE_PROJECTION_SUSPECTED = TRUE`; roadmap ordering is not stronger than
+owning-repository completion evidence. Repair the owning projection when the
+authority permits, but never promote implementation alone to qualification.
+
+Pass 2 compares sources **within each owning repository** as well as across
+product boundaries: roadmap, DAG/status projection, completion and
+qualification evidence, implementation evidence, and merged history where it
+is canonical evidence. Classify each discrepancy as `NO_CONFLICT`,
+`STALE_PROJECTION_SUSPECTED`, `PENDING_RECONCILIATION`, or
+`REAL_AUTHORITY_CONFLICT`. `CURRENT_STATUS_IS_EVIDENCE_RECONCILED = TRUE` is
+valid only after this comparison.
 
 ## Reconstructing Project Context and analyzing the primary objective
 
@@ -230,6 +263,14 @@ implementation may show a subset exists, and a pending Forge PR may propose a
 new consumer dependency. Record this as a reconciliation finding; do not
 resolve peer capability truth by editing Forge documentation alone.
 
+Forge owns a consumer dependency's required capability and its consequence for
+Forge work (`FORGE_OWNED_DEPENDENCY`). EP owns whether an EP capability is
+implemented, qualified, complete or currently available
+(`EP_OWNED_STATUS`). A Forge roadmap/DAG may retain a source-pinned observed
+peer fact as historical evidence, but a fresh EP `origin/main` resolution is
+required before it is reported as current; that fact is never independent
+Forge status authority.
+
 ## Governance and parallel work
 
 Within an already authorized functional engineering envelope, ordinary
@@ -276,6 +317,11 @@ contract references; remove contradictions rather than creating duplicate
 authority. Add an ADR only for a durable architectural decision needing decision
 history, not for status.
 
+A stale current-status projection normally routes autonomously to the owning
+roadmap/status/DAG projection. A peer capability truth routes only to the peer;
+Forge may update only its own consumer dependency semantics and its
+source-pinned observation. Do not create a second peer-status register here.
+
 ## Completion check
 
 Before ending, re-run the relevant documentation/DAG tests and verify links.
@@ -292,11 +338,12 @@ dependencies without chat history.
 
 Every substantive Architect response ends with a compact ASCII progress report.
 It is a read-time evidence projection, not a fourth roadmap or an independent
-status register. Derive the shared rows afresh from the current owning
-repository `main` authorities, their exact SHA/date where material, canonical
-producer evidence, and open-PR head/qualification state. Name those sources in
-`SOURCES`; never copy a peer's status into this file or silently promote a
-`PENDING_PR` to canonical truth.
+status register. Derive the shared rows afresh from current remote owning
+authorities, their exact SHA/UTC observation time, canonical producer evidence,
+and open-PR head/qualification state. Name those sources in `SOURCES`; never
+copy a peer's status into this file or silently promote a `PENDING_PR` to
+canonical truth. If peer freshness is unverified, say so and omit
+time-sensitive peer status instead of estimating it.
 
 Use capability/evidence rows only — a status is never inferred from ordering,
 elapsed time, or an approximate percentage. Every row must use exactly one of:
@@ -310,8 +357,12 @@ The report must include both shared sections and this product-specific section:
 
 ```text
 ARCHITECT PROGRESS
-SOURCES: Forge main=<SHA/date>; EP main=<SHA/date>; Workspace main=<SHA/date>;
-         pending=<PR/head/check state or none>
+SOURCES
+Forge origin/main=<SHA>@<observed-at>
+EP origin/main=<SHA>@<observed-at>
+Workspace origin/main=<SHA>@<observed-at>
+PEER_AUTHORITY_FRESHNESS=VERIFIED | UNVERIFIED
+pending=<PR/head/check state or none>
 
 AUTONOMY CUTOVER
 <status> <capability> — <producer/qualification evidence and classification>

docs/architecture/FORGE_EP_V1_MIGRATION_CONTINUITY.md

@@ -2,32 +2,45 @@
 
 **AUTHORITY = DERIVED. EP_NODE_AUTHORITY = ENGINEERING_PLATFORM.** This is a Forge readiness projection, not EP allocation authority. EP roadmap/architecture and qualification evidence decide EP sequencing.
 
-## Reconciled baseline — 2026-09-06
+## Consumer dependency semantics and source-pinned observation
 
 The previous version of this projection was stale: it still described P-TRANSPORT PR #33 as open and placed the entire historical P-QUEUE/Phase-S/B8E chain in front of standalone verification. Current owner decisions and EP evidence supersede that projection.
 
-Current facts:
+Forge owns the consumer requirements below, not the current EP status of their
+producer capabilities. For an Architect-session status report, resolve fresh
+EP `origin/main` and apply the `PEER_AUTHORITY_FRESHNESS_CONTRACT` in
+`ARCHITECT_SESSION.md`. This document's EP facts are an observed source
+snapshot, never a locally authoritative EP status register.
+
+**Observed EP evidence:** `origin/main=222ff52a00499f2113f1df5bdd621394c12a66c5`
+at `2026-09-06T20:11:58Z`; P-NEUTRAL closure
+`b44af0914622dd57c5c5c2266ee2caf9b31d9007` is its ancestor. EP's closure
+register proves the same neutral platform-authority capability and the EP
+roadmap/status repair is owned by EP.
+
+Observed facts at that snapshot:
 
 - P-TRANSPORT PR #33 is merged; P-TRANSPORT is closed.
 - P-TRANSPORT provides HTTP, installed CLI and Server-owned File Inbox as three canonical submission transports normalized through Server/CENTRAL authority.
-- P-NEUTRAL is the active EP critical-path increment.
+- P-NEUTRAL is a completed EP predecessor, preserving its historical and
+  forensic evidence.
+- P-INSTALLER-V1 is the observed EP current frontier.
 - B8R project/repository identity is declared by the Canonical Project Authority Repository and validated by EP; Workspace is not required to manufacture logical project identity.
 - Broader Agent separation/general dispatch/multi-host/multi-repository productization is follow-on work by default.
 - `EP::STANDALONE_EP_VERIFIED` should be reached through the minimum installed one-run execution proof, not by assuming every broader future queue/Agent/B8E capability is a prerequisite.
 - Any queue/lease/recovery/finalization/B8E capability that the real installed canary actually requires becomes a bounded prerequisite based on evidence.
 
-## Current EP frontier
+## Consumer-gate interpretation
 
 ```text
 completed:
   EP::LOCAL_CONSUMER_API_V1
   EP::P_TRANSPORT_V1
-
-active:
   EP::P_NEUTRAL_V1
 
-next critical target:
-  minimum installed governed execution
+EP-owned current frontier at the observed source snapshot:
+  EP::P_INSTALLER_V1
+  -> minimum installed governed execution
   -> EP::STANDALONE_EP_VERIFIED
 
 follow-on unless proven required by the canary:
@@ -40,19 +53,21 @@ follow-on unless proven required by the canary:
 
 `P_TRANSPORT_STATUS = MERGED_CLOSED`
 
-`CURRENT_EP_MIGRATION_FRONTIER = P_NEUTRAL`
+`FORGE_OWNED_DEPENDENCY = EP installed execution/result producer`
+
+`EP_OWNED_STATUS = RESOLVE_FRESH_EP_ORIGIN_MAIN`
 
 `GENERAL_AGENT_SEPARATION_BLOCKS_STANDALONE = FALSE`
 
 ## Producer-to-consumer continuity
 
-| EP producer/capability | Current availability | Forge consequence | Workspace consequence |
+| EP producer/capability | EP-owned status | Forge consequence | Workspace consequence |
 | --- | --- | --- | --- |
-| Local Consumer API/auth foundation | Qualified | consumer/auth/read foundation | consumer/auth/read foundation |
-| P-TRANSPORT HTTP submission | Qualified transport | canonical Forge machine submission target | future permitted-intent transport; no Workspace ownership |
-| Installed one-run execution/finalization/result evidence | Qualification gap | blocks first real Forge execution/reconciliation | later execution projection |
-| B8R project identity/attachment runtime | Current EP architecture | Forge may target canonical declared repo identity | Workspace may project identity; not source of EP topology authority |
-| `EP::STANDALONE_EP_VERIFIED` | Next major gate | unlocks live Forge F3/F4 canary integration | allows later installed control-plane integration |
+| Local Consumer API/auth foundation | resolve fresh from EP | consumer/auth/read foundation | consumer/auth/read foundation |
+| P-TRANSPORT HTTP submission | resolve fresh from EP | canonical Forge machine submission target | future permitted-intent transport; no Workspace ownership |
+| Installed one-run execution/finalization/result evidence | resolve fresh from EP | blocks first real Forge execution/reconciliation until qualified | later execution projection |
+| B8R project identity/attachment runtime | resolve fresh from EP | Forge may target canonical declared repo identity | Workspace may project identity; not source of EP topology authority |
+| `EP::STANDALONE_EP_VERIFIED` | resolve fresh from EP | unlocks live Forge F3/F4 canary integration | allows later installed control-plane integration |
 | Rich Engineering Contract Foundation | Follow-on producer hardening | long-term L0/F4 richness | quality/governance projection |
 | Generalized Agent/dispatch/multi-host | Follow-on | scale/resilience, not first-canary prerequisite | later operations UX |
 

docs/architecture/FORGE_V1_IMPLEMENTATION_DAG.md

@@ -6,7 +6,7 @@
 
 ```text
 Forge Action-Derivation foundation (qualified)
-  -> EP P-NEUTRAL closure
+  -> 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
@@ -25,6 +25,8 @@ Forge Action-Derivation foundation (qualified)
 ## 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.
@@ -45,8 +47,8 @@ Forge Action-Derivation foundation (qualified)
 | --- | --- | --- |
 | 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 | ACTIVE | Current EP critical path. |
-| EP P-INSTALLER-V1 | REQUIRED NEXT | Reproducible server-only installed product. |
+| 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. |
@@ -60,7 +62,7 @@ Forge Action-Derivation foundation (qualified)
 ## Critical execution DAG
 
 ```text
-                         EP P-NEUTRAL
+                  EP P-NEUTRAL (completed)
                               |
                               v
                        P-INSTALLER-V1
@@ -219,8 +221,8 @@ Autonomous Mission execution is now:
 ```text
 approved Mission + Planner/Living Graph       PROVEN
 EP P-TRANSPORT HTTP                           AVAILABLE
-P-NEUTRAL                                     ACTIVE EP GAP
-P-INSTALLER-V1                                EP INSTALLED-PRODUCT GAP
+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
@@ -237,7 +239,8 @@ Project Intelligence/Workspace governance productization is deliberately not ins
 
 - 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-NEUTRAL proceeds now, followed by P-INSTALLER-V1.
+- 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.