[codex] Implement Phases 74-76 conversation recall

.spec/decisions/jido_code.conversation_history_long_term_capture.md

@@ -8,6 +8,10 @@ affects:
   - architecture.memory_capture_plane
   - architecture.memory_graph_product_adoption
   - architecture.factory_control_plane
+  - architecture.memory_graph_surface_rollout_and_governance_actions
+  - architecture.memory_graph_workflow_and_operator_expansion
+  - architecture.operator_surface_information_architecture
+  - architecture.run_governance
 related:
   - jido_code.interruptible_conversation_orchestration
   - jido_code.memory_capture_plane_and_insertion_seams
@@ -77,6 +81,9 @@ The product shall therefore prefer:
   and work item produced later governed work
 - bounded projections that let workflows and operator surfaces inspect
   conversation-derived origin context without reading raw graph internals
+- route-owned recall cards on repo-detail memory and governed-run follow-up
+  surfaces that reopen the canonical repository conversation when an operator
+  needs full transcript continuity
 - explicit adoption paths when a conversation outcome should become a durable
   `Fact`, `Decision`, `Convention`, `KnownIssue`, `LessonLearned`,
   `OpenQuestion`, `Pattern`, or similar memory class

.spec/specs/collaboration.spec.md

@@ -6,7 +6,7 @@ This subject defines the repository collaboration and local work-management cont
 id: collaboration.workflow
 kind: policy
 status: active
-summary: jido_code uses Beadwork for local durable agent state and GitHub issues plus pull requests for shared collaboration, while keeping the repo AGENTS guide aligned with the current local Spec Led handoff flow and repo-owned contributor conventions such as the LiveView-plus-LiveVue frontend boundary, product-oriented frontend fallback wording, repository-scoped semantic source graph and memory graph usage guidance, and the `mix memory.verify` plus `mix semantic.verify` contributor expectations for semantic changes.
+summary: jido_code uses Beadwork for local durable agent state and GitHub issues plus pull requests for shared collaboration, while keeping the repo AGENTS guide aligned with the current local Spec Led handoff flow and repo-owned contributor conventions such as the LiveView-plus-LiveVue frontend boundary, product-oriented frontend fallback wording, repository-scoped semantic source graph and memory graph usage guidance, the rule that conversation-derived long-term recall stays provenance-first and transcript browsing remains on canonical conversation surfaces, and the `mix memory.verify` plus `mix semantic.verify` contributor expectations for semantic changes.
 surface:
   - AGENTS.md
 ```

.spec/specs/conversation_orchestration.spec.md

@@ -1,6 +1,6 @@
 # Conversation Orchestration
 
-<!-- current_truth.reconciled_with_branch: repo detail now acts as the canonical conversation host through a route-owned `Conversations` family with bounded repo intake, governed work-item roster, route-owned runtime readiness and snapshot continuity panels, blocked runtime states now linking back to the same route's repo-scoped workspace-repair surface instead of pointing operators toward setup defaults, the blocked conversation-runtime notice now carrying that repair jump inline instead of hiding it only in pane footer chrome, that runtime panel now using the same repo-scoped workspace-binding vocabulary as semantic, memory, and workflow surfaces, Workbench plus run detail plus dashboard reuse shared conversation supervision language, dashboard `Work > Overview` plus `/workbench` now project that bounded conversation follow-up through the shared managed-repository inventory model instead of keeping dashboard overview intentionally empty, and those conversation-hosting signed-in routes now share one product-wide operator navigation layer through shared LiveView-owned helpers with `/workbench` and run detail both adopting the shared proportional breadcrumb-and-pane shell instead of bespoke top-level chrome. -->
+<!-- current_truth.reconciled_with_branch: repo detail now acts as the canonical conversation host through a route-owned `Conversations` family with bounded repo intake, governed work-item roster, route-owned runtime readiness and snapshot continuity panels, blocked runtime states now linking back to the same route's repo-scoped workspace-repair surface instead of pointing operators toward setup defaults, the blocked conversation-runtime notice now carrying that repair jump inline instead of hiding it only in pane footer chrome, that runtime panel now using the same repo-scoped workspace-binding vocabulary as semantic, memory, and workflow surfaces, repo-detail memory plus governed run detail now project bounded conversation-origin recall back to the canonical conversation route instead of rehosting transcript history, those recall cards now using stable route-owned DOM ids and browser-covered canonical conversation links, Workbench plus run detail plus dashboard reuse shared conversation supervision language, dashboard `Work > Overview` plus `/workbench` now project that bounded conversation follow-up through the shared managed-repository inventory model instead of keeping dashboard overview intentionally empty, and those conversation-hosting signed-in routes now share one product-wide operator navigation layer through shared LiveView-owned helpers with `/workbench` and run detail both adopting the shared proportional breadcrumb-and-pane shell instead of bespoke top-level chrome. -->
 
 This subject defines how productive coding conversations are coordinated across
 durable work scope, interruptible execution, and event-driven UI delivery.
@@ -9,7 +9,7 @@ durable work scope, interruptible execution, and event-driven UI delivery.
 id: architecture.conversation_orchestration
 kind: feature
 status: active
-summary: Jido.Code treats productive coding conversations as managed-repository hosted, canonically work-item-scoped mixed-initiative sessions coordinated through explicit control and work commands, deterministic product-owned workflow routing, append-only sequenced event streams, durable snapshots, bounded shared context, optional provenance-first long-term semantic recall, cancellable tool jobs, real LLM-backed turn execution through product-owned runtime boundaries with explicit repo and conversation LLM provider/model selection, and event-driven LiveView plus PubSub delivery with reconnectable degraded fallbacks, including repo-detail as the canonical conversation host surface through a dedicated route-owned `Conversations` family, repo-scoped pre-work intake, multiple active work-item conversations per repository, bounded Workbench plus run-detail plus dashboard projection, dashboard conversation supervision now bounded inside a dedicated authenticated sidebar-selected dashboard conversation concern while dashboard `Work > Overview` plus `/workbench` reuse the shared managed-repository inventory surface to preview the same bounded conversation follow-up instead of keeping overview empty, route-local workspace-readiness repair from blocked runtime panels using the same repo-scoped binding language as adjacent runtime surfaces with inline repair actions on blocked repo-detail notices, `/workbench` and governed run detail now adopting the shared proportional breadcrumb-and-pane shell for those follow-up route bodies, and one shared signed-in operator navigation layer over those routes through LiveView-owned helpers rather than bespoke route headers, while clarification on ambiguous workflow intent replaces snapshot polling, fake timer-driven turn simulation, ad hoc FIFO chat handling, AI-decided specialist self-selection, abstract model-tier routing, or one repo-global productive thread.
+summary: Jido.Code treats productive coding conversations as managed-repository hosted, canonically work-item-scoped mixed-initiative sessions coordinated through explicit control and work commands, deterministic product-owned workflow routing, append-only sequenced event streams, durable snapshots, bounded shared context, optional provenance-first long-term semantic recall, cancellable tool jobs, real LLM-backed turn execution through product-owned runtime boundaries with explicit repo and conversation LLM provider/model selection, and event-driven LiveView plus PubSub delivery with reconnectable degraded fallbacks, including repo-detail as the canonical conversation host surface through a dedicated route-owned `Conversations` family, repo-scoped pre-work intake, multiple active work-item conversations per repository, bounded Workbench plus run-detail plus dashboard projection, dashboard conversation supervision now bounded inside a dedicated authenticated sidebar-selected dashboard conversation concern while dashboard `Work > Overview` plus `/workbench` reuse the shared managed-repository inventory surface to preview the same bounded conversation follow-up instead of keeping overview empty, repo-detail memory plus governed run detail using bounded conversation-origin recall only as a cross-linked origin summary back to the canonical conversation route rather than a second transcript host and proving that route handoff through stable surface ids plus browser coverage, route-local workspace-readiness repair from blocked runtime panels using the same repo-scoped binding language as adjacent runtime surfaces with inline repair actions on blocked repo-detail notices, `/workbench` and governed run detail now adopting the shared proportional breadcrumb-and-pane shell for those follow-up route bodies, and one shared signed-in operator navigation layer over those routes through LiveView-owned helpers rather than bespoke route headers, while clarification on ambiguous workflow intent replaces snapshot polling, fake timer-driven turn simulation, ad hoc FIFO chat handling, AI-decided specialist self-selection, abstract model-tier routing, or one repo-global productive thread.
 decisions:
   - jido_code.conversation_history_long_term_capture
   - jido_code.factory_control_plane_and_runtime_overlay

.spec/specs/factory_control_plane.spec.md

@@ -1,6 +1,6 @@
 # Factory Control Plane
 
-<!-- current_truth.reconciled_with_branch: repo detail now keeps one canonical managed-repository route while organizing overview, conversations, semantic inspection, memory/provenance inspection, and workflow launch into route-owned families, overview now exposing repo-scoped workspace inspection and repair on the canonical managed-repository route, conversation plus semantic plus memory plus workflow readiness now sharing one repo-scoped workspace-binding story and repair path with the blocked conversation-runtime notice exposing its repair jump inline, dashboard now keeps one canonical authenticated landing route with the shared post-onboarding subject-tree shell landed on dashboard and repo detail, dashboard `Work` now carrying the primary signed-in repository-inventory role in current truth while `/workbench` remains a bounded dense specialist mode that still projects canonical control-plane records, signed-in control-plane routes now share one product-wide operator navigation layer through shared LiveView-owned helpers, `/workbench`, `/repos`, `/workflows`, `/agents`, and governed run detail now use proportional shared-shell framing instead of bespoke route-local chrome, settings now uses the same shell primitives through route-owned child-subject navigation with pane footers rendered only when the selected settings concern owns an action, adjacent LiveView plus browser coverage now proving those control-plane routes read as one workspace, and setup import now persists repo-scoped workspace binding directly even when local repositories do not share one parent directory and the signed-in `/settings/github` add-repository flow routes later GitHub additions through the same canonical managed-repository import boundary instead of stopping at settings-only GitHub rows. -->
+<!-- current_truth.reconciled_with_branch: repo detail now keeps one canonical managed-repository route while organizing overview, conversations, semantic inspection, memory/provenance inspection, and workflow launch into route-owned families, overview now exposing repo-scoped workspace inspection and repair on the canonical managed-repository route, conversation plus semantic plus memory plus workflow readiness now sharing one repo-scoped workspace-binding story and repair path with the blocked conversation-runtime notice exposing its repair jump inline, repo-detail memory plus governed run follow-up now projecting bounded conversation-origin recall cards that reopen the canonical repository conversation instead of turning control-plane routes into transcript browsers, dashboard now keeps one canonical authenticated landing route with the shared post-onboarding subject-tree shell landed on dashboard and repo detail, dashboard `Work` now carrying the primary signed-in repository-inventory role in current truth while `/workbench` remains a bounded dense specialist mode that still projects canonical control-plane records, signed-in control-plane routes now share one product-wide operator navigation layer through shared LiveView-owned helpers, `/workbench`, `/repos`, `/workflows`, `/agents`, and governed run detail now use proportional shared-shell framing instead of bespoke route-local chrome, settings now uses the same shell primitives through route-owned child-subject navigation with pane footers rendered only when the selected settings concern owns an action, adjacent LiveView plus browser coverage now proving those control-plane routes read as one workspace, and setup import now persists repo-scoped workspace binding directly even when local repositories do not share one parent directory and the signed-in `/settings/github` add-repository flow routes later GitHub additions through the same canonical managed-repository import boundary instead of stopping at settings-only GitHub rows. -->
 
 This subject defines `Jido.Code` as a governed software-factory control plane for
 Git-backed repositories.
@@ -9,7 +9,7 @@ Git-backed repositories.
 id: architecture.factory_control_plane
 kind: policy
 status: active
-summary: Jido.Code centers the product on a governed software-factory control plane whose primary managed repository object is `ManagedRepo`, whose durable loop turns repo demand into governed work, whose repository-scoped source-code, memory, and workflow-provenance insights may inform operator understanding, dashboard summaries, governed history, canonical follow-up staging, and work synthesis through canonical managed-repository and governed-record surfaces while preserving explicit freshness, recovery, provenance, cross-graph consistency, and durable-memory adoption metadata when those findings rejoin governed product records, whose governed product records now also have a first-class semantic model and typed repository-scoped references for cross-graph linking, whose semantic workflow and governed-adoption boundaries now emit typed governed references at the capture-envelope seam rather than generic artifact naming, whose semantic workflow and governed-adoption boundaries may emit supporting workflow provenance and intentionally classify durable coding memory without turning graph-local activity into alternate control-plane truth, whose canonical managed-repository detail route keeps route-owned operator families plus one shared repo-scoped workspace-repair path, whose authenticated dashboard remains one canonical landing route, whose `Work` subject now owns the primary signed-in managed-repository inventory and triage role, whose signed-in routes now share one LiveView-owned product navigation layer across dashboard, `/workbench`, settings, repository inventory, governed run detail, and deep follow-up routes, whose specialist, governed-run, and inventory routes now adopt proportional shared-shell framing rather than bespoke chrome, whose settings route now reuses shared shell primitives for its real local concerns, and whose accepted post-onboarding operator shell keeps `/workbench` as a bounded dense specialist mode or alias rather than a competing top-level product surface, while the signed-in `/settings/github` route sends later GitHub additions through the same managed-repository import boundary instead of creating settings-only product truth and repo-native or runtime-derived analysis layers inform but do not replace Ash-backed product truth.
+summary: Jido.Code centers the product on a governed software-factory control plane whose primary managed repository object is `ManagedRepo`, whose durable loop turns repo demand into governed work, whose repository-scoped source-code, memory, and workflow-provenance insights may inform operator understanding, dashboard summaries, governed history, canonical follow-up staging, work synthesis, and bounded conversation-origin recall through canonical managed-repository and governed-record surfaces while preserving explicit freshness, recovery, provenance, cross-graph consistency, route-owned conversation continuity, and durable-memory adoption metadata when those findings rejoin governed product records, whose governed product records now also have a first-class semantic model and typed repository-scoped references for cross-graph linking, whose semantic workflow and governed-adoption boundaries now emit typed governed references at the capture-envelope seam rather than generic artifact naming, whose semantic workflow and governed-adoption boundaries may emit supporting workflow provenance and intentionally classify durable coding memory without turning graph-local activity into alternate control-plane truth, whose canonical managed-repository detail route keeps route-owned operator families plus one shared repo-scoped workspace-repair path, whose authenticated dashboard remains one canonical landing route, whose `Work` subject now owns the primary signed-in managed-repository inventory and triage role, whose signed-in routes now share one LiveView-owned product navigation layer across dashboard, `/workbench`, settings, repository inventory, governed run detail, and deep follow-up routes, whose specialist, governed-run, and inventory routes now adopt proportional shared-shell framing rather than bespoke chrome, whose settings route now reuses shared shell primitives for its real local concerns, and whose accepted post-onboarding operator shell keeps `/workbench` as a bounded dense specialist mode or alias rather than a competing top-level product surface, while the signed-in `/settings/github` route sends later GitHub additions through the same managed-repository import boundary instead of creating settings-only product truth and repo-native or runtime-derived analysis layers inform but do not replace Ash-backed product truth.
 decisions:
   - jido_code.compatibility_era_removal_and_canonical_cutover
   - jido_code.internal_domain_and_execution_canonicalization