> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase19-session07-provider-diagnostics/spec.md). # Session Specification **Session ID**: `phase19-session07-provider-diagnostics` **Phase**: 19 - Orchestration Command Center Execution **Status**: Not Started **Created**: 2026-06-26 **Package**: null **Package Stack**: mixed TypeScript/JavaScript *** ## 1. Session Overview This session turns provider, setup, runtime, and orchestration health into visible command-center readiness. It adds a source-owned diagnostics contract, server-owned probes, CLI summaries, and a web diagnostics panel so operators can see why Claude Code, Codex, OpenCode, Cursor, Bedrock, Vertex, hooks, models, IDE integration, setup, scan roots, and local services are ready, degraded, or unavailable. It is next because Phase 19 Sessions 01 through 06 completed the command-center contracts, server backbone, web shell, campaign workbench, attention and permission decision paths, and executor registry. Before Session 08 adds file and Git execution families, the cockpit needs provider and environment readiness that can explain disabled states and provide exact repair paths without silently enabling external transfer or executor behavior. The scope remains local-first and conservative. This session reports readiness, syncs compact diagnostic records, supports narrow server-owned cleanup for stale listener and malformed spool state, and creates or links "needs setup" task sources. It does not install providers, manage hosted credentials, start remote services, run IDE automation, or make Bedrock, Vertex, Cursor, OpenCode, terminal, Docker, or hosted execution claims. *** ## 2. Objectives 1. Add shared provider diagnostics contracts for provider capability matrices, setup readiness, runtime health, recovery actions, and redacted environment reporting. 2. Add a server diagnostics manager that probes providers, hooks, models, setup docs, package commands, env examples, scan roots, running services, listener PID health, spool health, queue posture, template availability, graph degradation, guarded-action expiry, and isolation posture. 3. Add root and `/api` diagnostics routes plus CLI doctor/status integration that expose compact repair guidance and only perform tested safe recovery actions. 4. Add a web diagnostics and recovery surface with product-facing capability matrix copy, loading/empty/error/offline states, duplicate-trigger guards, and setup task creation through the existing task queue. *** ## 3. Prerequisites ### Required Sessions * [x] `phase19-session01-protocol-and-events` - Provides command-center diagnostic records, executor capability vocabulary, update events, and compact REST/event conventions. * [x] `phase19-session02-server-backbone` - Provides command-center manager state, diagnostics counts, route aliases, WebSocket hydration, and local server wiring. * [x] `phase19-session03-web-shell-and-store` - Provides typed web API helpers, command-center store slices, tabs, drawer state, and broad UI normalization. * [x] `phase19-session04-campaign-workbench` - Provides queue and campaign mutation patterns plus task-source creation that setup readiness can reuse. * [x] `phase19-session05-attention-and-permissions` - Provides audited local permission and attention state used when diagnostics become actionable. * [x] `phase19-session06-executor-registry` - Provides registry-gated provider diagnostic executor capability records and run-history boundaries. ### Required Tools Or Knowledge * Node 26.2.0+ and npm 11.16.0 workspace commands. * Current provider and hook posture code in `apps/cli/src/lib/providerPosture.js`, `apps/cli/src/commands/doctor.js`, and `apps/cli/src/commands/status.js`. * Current diagnostics routes in `apps/server/src/routes/diagnostics.ts`, `apps/server/src/lib/orchestrationDiagnostics.ts`, and `apps/server/src/lib/runtimeDiagnostics.ts`. * Current command-center diagnostics and executor records in `packages/protocol/src/orchestrationCommandCenter.ts` and `apps/server/src/managers/orchestrationCommandCenter.ts`. * Current web diagnostics tab, API helpers, and UI helpers in `apps/web/src/components/orchestration/CommandCenterPanes.tsx`, `apps/web/src/lib/orchestrationApi.ts`, and `apps/web/src/lib/commandCenterUi.ts`. ### Environment Requirements * Run from the repository root with dependencies installed. * No Anthropic/OpenAI/provider credentials, Cloudflare credentials, hosted accounts, IDE automation bridge, Docker runtime, remote access, database, or production server is required. * Tests should use injected filesystem, environment, process, and service-probe fixtures instead of reading or mutating real user provider config except where existing CLI posture tests already isolate temp homes. *** ## 4. Scope ### In Scope (MVP) * Operators can inspect provider readiness - show installed, hook installed, model list, manual permission mode, plan mode, fork support, handoff support, isolation support, IDE/open-file readiness, disabled reason, and repair command metadata for Claude Code, Codex, OpenCode, Cursor, Bedrock, and Vertex. * Operators can inspect setup readiness - show setup doc presence, package manager, install/dev/test commands, env example coverage, scan root posture, running local services, and a "needs setup" task source when setup is missing. * Operators can inspect runtime diagnostics - surface server connection, listener PID health, spool health, queue capacity, template availability, graph degradation, guarded-action expiry, provider readiness, and isolation posture in the command center. * Safe recovery is actionable - server-owned recovery may remove stale listener PID files and malformed spool entries only; provider setup, env updates, hook install, IDE work, and service startup are rendered as exact CLI/operator commands. * Web and CLI output stays redacted - report variable names, presence labels, counts, docs paths, provider labels, and compact commands only; never return raw env values, tokens, URLs, absolute paths, command bodies, prompts, terminal output, file contents, provider payloads, transcripts, logs, backups, or hosted account data. ### Out Of Scope (Deferred) * Installing or enabling missing providers - Reason: this session reports readiness and repair commands only. * External provider transfer or model calls - Reason: provider transfer remains two-level opt-in and is not needed for readiness diagnostics. * IDE automation or opening files from the browser - Reason: this session reports IDE/open-file readiness metadata only. * File, Git, terminal, container, remote, Worker, hosted, channel, hero lifecycle, mission, or handoff execution - Reason: later Phase 19 sessions own those executor families behind separate gates. * Database persistence or migrations - Reason: project conventions say no database layer is configured; diagnostics are manager-owned runtime records and command-center snapshots. * Importing, copying, transforming, or shipping `EXAMPLES/` artifacts - Reason: Phase 19 keeps historical material as traceability evidence only. *** ## 5. Technical Approach ### Architecture Add `packages/protocol/src/providerDiagnostics.ts` as a focused shared contract for provider diagnostics, setup readiness, runtime health, recovery commands, recovery request and response shapes, blocked payload categories, parsers, and compact error envelopes. Export it through `packages/protocol/src/index.ts` so server, CLI, and web consumers do not duplicate provider, setup, recovery, or status vocabularies. Keep existing `CommandCenterDiagnostic` and `provider_diagnostic` executor records as the broad command-center integration path. Add `apps/server/src/managers/diagnosticsManager.ts` as the server-owned probe boundary. It should use injected filesystem, environment, process, package metadata, service probe, queue, template, graph, guarded-action, command-center, and isolation dependencies so tests can cover every branch without touching real user homes. The manager builds provider/setup snapshots, redacts all environment values, bounds command labels, and maps raw local state into command-center diagnostic records and provider diagnostic capability refreshes. Extend `apps/server/src/routes/diagnostics.ts` with `GET /diagnostics/provider-readiness` and `POST /diagnostics/orchestration/recover`, mounted through the existing root and `/api` route aliases in `apps/server/src/server.ts`. The recovery route accepts only schema-validated, idempotent requests for narrow cleanup actions already supported by CLI diagnostics: stale listener PID files and malformed spool entries. Every other recovery action returns exact operator-run commands such as `factionos doctor --recover-orchestration`, `factionos init --cli codex`, or documented setup commands without running them. Extend CLI diagnostics helpers so `factionos status` and `factionos doctor` can fetch and print compact provider/setup readiness alongside current orchestration, isolation, and hosted-operation posture. Existing local-only loopback checks, bearer auth handling, timeout handling, and redaction helpers should be reused. On the web side, add a `ProviderCapabilityMatrix` plus `DiagnosticsRecoveryPanel` under `apps/web/src/components/orchestration/`. The Diagnostics tab should render provider/setup/runtime health, recovery command chips, narrow recovery actions, and a "needs setup" task action using the existing task queue create path with `source: "system"`. All state-mutating actions need duplicate-trigger prevention, loading/error/offline states, and product-facing copy only. ### Design Patterns * Protocol-first contract: shared provider/setup/recovery types live in `packages/protocol` before server, CLI, or web wiring. * Manager-owned diagnostics: the server diagnostics manager owns probe normalization, redaction, recovery eligibility, and command-center diagnostic record generation. * Capability-first readiness: every provider and setup item reports status and disabled reason before any later executor can claim active behavior. * Exact-command recovery: actions that cannot be safely repaired by the server become bounded CLI/operator command labels, not background mutations. * Pure web normalization: web API and UI helpers reject malformed or blocked diagnostic payloads before updating command-center UI state. *** ## 6. Deliverables ### Files To Create | File | Purpose | Est. Lines | | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | `packages/protocol/src/providerDiagnostics.ts` | Shared provider/setup/runtime diagnostics contracts, status vocabularies, parsers, recovery request/response shapes, and blocked payload guards | \~340 | | `packages/protocol/tests/providerDiagnostics.test.ts` | Fixture and parser coverage for provider matrices, setup readiness, recovery requests, redacted env reporting, and blocked payload rejection | \~220 | | `apps/server/src/managers/diagnosticsManager.ts` | Server-owned provider/setup/runtime probe manager, command-center diagnostic mapper, and narrow recovery boundary | \~460 | | `apps/server/tests/providerDiagnostics.test.ts` | Unit tests for probe normalization, redaction, setup detection, service status, recovery eligibility, idempotency, and command-center diagnostic mapping | \~320 | | `apps/cli/src/lib/providerDiagnostics.js` | CLI fetch, compacting, sanitization, and formatting helpers for provider/setup readiness snapshots | \~220 | | `apps/cli/tests/providerDiagnostics.test.js` | CLI helper tests for loopback-only fetches, malformed responses, redaction, timeout, recovery command labels, and disabled reasons | \~200 | | `apps/web/src/components/orchestration/ProviderCapabilityMatrix.tsx` | Dense provider capability matrix with status labels, model/setup support, disabled reasons, and accessibility labels | \~220 | | `apps/web/src/components/orchestration/DiagnosticsRecoveryPanel.tsx` | Diagnostics recovery surface with provider/setup/runtime health, recovery actions, setup task action, and loading/empty/error/offline states | \~340 | | `apps/web/tests/DiagnosticsRecoveryPanel.test.tsx` | Component tests for provider readiness, setup missing, safe recovery, command-only repairs, offline states, duplicate triggers, and redaction | \~260 | ### Files To Modify | File | Changes | Est. Lines | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | `packages/protocol/src/index.ts` | Export provider diagnostics contracts and parsers | \~10 | | `apps/server/src/routes/diagnostics.ts` | Add provider-readiness and orchestration-recover routes with validation, compact errors, root and `/api` aliases, and command-center event emission | \~150 | | `apps/server/src/lib/orchestrationDiagnostics.ts` | Include provider/setup readiness counts and recovery availability without raw probe payloads | \~100 | | `apps/server/src/managers/orchestrationCommandCenter.ts` | Add helper for replacing diagnostics-manager records and refreshing provider diagnostic capabilities deterministically | \~90 | | `apps/server/src/server.ts` | Instantiate and inject the diagnostics manager with queue, template, graph, guarded-action, command-center, env, and state-root dependencies | \~50 | | `apps/server/tests/orchestrationDiagnostics.test.ts` | Cover provider/setup counts, recovery availability, and compact diagnostics output | \~120 | | `apps/server/tests/routes.test.ts` | Cover provider-readiness and recovery route aliases, auth boundary inheritance, validation errors, and no raw env/path echo | \~160 | | `apps/cli/src/lib/orchestrationDiagnostics.js` | Reuse local-only diagnostics fetch plumbing for provider readiness and recovery responses | \~120 | | `apps/cli/src/commands/doctor.js` | Print provider/setup readiness, disabled reasons, safe recovery results, and exact operator commands | \~100 | | `apps/cli/src/commands/status.js` | Print compact provider/setup posture without raw env values, paths, or provider payloads | \~80 | | `apps/cli/tests/orchestrationDiagnostics.test.js` | Cover provider diagnostics fetch integration, compacting, malformed payloads, auth, and redaction | \~120 | | `apps/cli/tests/cliRuntime.test.js` | Cover status and doctor output for provider readiness and narrow recovery guidance | \~100 | | `apps/web/src/lib/orchestrationApi.ts` | Add provider diagnostics fetch, recovery POST, and setup task helper wiring with timeout/offline/stale/malformed error mapping | \~160 | | `apps/web/src/lib/commandCenterUi.ts` | Add provider matrix, setup readiness, runtime health, recovery action, and diagnostics summary view helpers with redaction filtering | \~180 | | `apps/web/src/components/orchestration/CommandCenterPanes.tsx` | Replace the generic Diagnostics pane with `DiagnosticsRecoveryPanel` and pass setup/recovery callbacks | \~100 | | `apps/web/src/components/orchestration/OrchestrationHeader.tsx` | Add compact provider/setup capability matrix summary to the header without increasing layout instability | \~70 | | `apps/web/src/components/orchestration/index.ts` | Export provider diagnostics components for tests and stable imports | \~10 | | `apps/web/tests/orchestrationApi.test.ts` | Cover provider diagnostics fetch, recovery POST, setup task wiring, duplicate guard, timeout, and redacted errors | \~120 | | `apps/web/tests/commandCenterUi.test.ts` | Cover provider matrix summaries, disabled reason copy, recovery view helpers, blocked payload filtering, and setup task action state | \~140 | | `apps/web/tests/commandCenterStore.test.ts` | Cover provider diagnostic WebSocket reducers, malformed frames, and in-flight recovery cleanup | \~80 | | `apps/web/tests/OrchestrationPanel.test.tsx` | Cover Diagnostics tab integration, header summary, keyboard access, focus behavior, loading, empty, error, and product-facing copy states | \~150 | | `docs/api/README_api.md` | Document provider-readiness and orchestration-recover routes, response boundaries, and root plus `/api` aliases | \~120 | | `docs/api/event-api-hook-contracts.md` | Document provider diagnostic command-center updates, recovery event boundaries, and blocked payload categories | \~100 | | `apps/server/README_server.md` | Document diagnostics manager policy, safe recovery limits, and redacted provider/setup readiness | \~90 | | `apps/cli/README_cli.md` | Document provider readiness output and exact recovery command behavior | \~80 | | `apps/web/README_web.md` | Document the Diagnostics tab, capability matrix, setup task action, and no raw payload rendering | \~90 | *** ## 7. Success Criteria ### Functional Requirements * [ ] The shared protocol exports provider diagnostics contracts for provider matrices, setup readiness, runtime health, recovery actions, and recovery route shapes. * [ ] The server returns provider/setup/runtime readiness from `GET /diagnostics/provider-readiness` and `/api/diagnostics/provider-readiness` without raw env values, provider payloads, absolute paths, command bodies, prompts, terminal output, file contents, transcripts, logs, backups, or hosted account data. * [ ] `POST /diagnostics/orchestration/recover` and `/api/diagnostics/orchestration/recover` perform only tested narrow cleanup for stale listener PID files and malformed spool entries, with idempotency and compact audit output. * [ ] Unsupported provider, setup, IDE, external transfer, hosted, and service startup repairs render exact operator-run commands or docs links instead of running automatically. * [ ] CLI `status` and `doctor` show provider/setup readiness and disabled reasons with loopback-only fetches and redacted output. * [ ] The web Diagnostics tab explains disabled provider, hook, IDE, setup, runtime, queue, template, graph, guarded-action, and isolation states, and can create or link a "needs setup" task source through the existing task queue. ### Testing Requirements * [ ] Protocol tests cover valid snapshots, rejected blocked payloads, recovery request validation, and compact error parsing. * [ ] Server tests cover probe normalization, redacted env reporting, route aliases, recovery guards, idempotency, command-center diagnostic mapping, and compact orchestration diagnostics. * [ ] CLI tests cover loopback-only fetch behavior, bearer auth, malformed route responses, status/doctor formatting, disabled reasons, recovery commands, and redaction. * [ ] Web API, UI helper, store, component, and Orchestration panel tests cover loading, empty, error, offline, duplicate-trigger, setup missing, recovery success, command-only repair, malformed frame, keyboard, and focus states. * [ ] `npm --workspace packages/protocol run typecheck` passes. * [ ] `npm --workspace apps/server run typecheck` passes. * [ ] `npm --workspace apps/web run typecheck` passes. * [ ] Focused protocol, server, CLI, and web Vitest or Node test targets pass for provider diagnostics and orchestration diagnostics. ### Non-Functional Requirements * [ ] Provider diagnostics stay local-first and do not add hosted transfer, provider model calls, IDE automation, terminal execution, Docker execution, remote access, or provider installation. * [ ] Diagnostic snapshots are bounded, deterministic, redacted, and sorted for repeatable REST, CLI, WebSocket, store, and UI behavior. * [ ] Recovery and setup task actions prevent duplicate triggers while in flight and remain idempotent on retry. * [ ] Web diagnostics controls are keyboard-accessible, screen-reader labeled, focus-safe, and product-facing. ### Quality Gates * [ ] All files ASCII-encoded * [ ] Unix LF line endings * [ ] Code follows project conventions * [ ] Primary user-facing surfaces contain product-facing copy only *** ## 8. Implementation Notes ### Working Assumptions * Package context is cross-cutting, so `Package: null` is intentional. The analyzer reports this candidate as `package: null`, the session stub names `apps/server`, `apps/cli`, and `apps/web`, and project conventions require shared contracts to land in `packages/protocol` before app wiring. Planning can proceed because the work is coherently cross-package. * A focused protocol module is required even though existing command-center diagnostic records already exist. Current `CommandCenterDiagnostic` records are broad list items, while the session needs a structured provider/setup/recovery REST contract shared by server, CLI, and web. Adding `providerDiagnostics.ts` avoids duplicate app-local vocabularies without changing unrelated command-center contracts. * Provider readiness should report current observable posture and explicit unavailable states rather than adding provider support. Current CLI provider code supports Claude and Codex hook posture, while the Phase 19 target names OpenCode, Cursor, Bedrock, and Vertex. Planning can proceed by returning disabled or unavailable reasons and exact repair/docs commands for providers that are not implemented in current source. * Safe recovery is limited to stale listener PID and malformed spool cleanup. Existing CLI diagnostics already support this narrow repair through `factionos doctor --recover-orchestration`, and the PRD explicitly says provider/setup repairs should become exact commands when the server cannot safely repair in process. ### Conflict Resolutions * The session stub says "provider, model, IDE, setup, and runtime readiness," while master PRD carry-forward boundaries prohibit external transfer and real executors without explicit gates. The chosen interpretation is readiness-only: report provider and model capability metadata, disabled reasons, and operator-run repair commands without provider calls, credentials, IDE automation, or executor behavior. * The Phase 19 appendix references historical Cursor/OpenCode/Bedrock/Vertex routes, while current source marks historical settings/model routes as unsupported. The chosen interpretation is to define current provider diagnostics routes under `/diagnostics/provider-readiness` and keep historical route families unsupported until a later source-backed session implements them. * The diagnostics target mentions recovery actions, but security guidance keeps full trusted erasure and broad state cleanup as no-claim. The chosen interpretation is narrow recovery only: stale listener PID and malformed spool cleanup may run; all broader cleanup remains manual, documented, or no-claim. ### Key Considerations * Diagnostics must explain why a capability is disabled without suggesting unavailable providers or hosted services are active. * Recovery output must distinguish "performed safely" from "operator command available" so UI copy does not overclaim mutation. * Environment readiness can name expected variables and example files, but must never echo values. * Setup task creation should use the existing task queue and source `system`, not a new task subsystem. ### Potential Challenges * Provider probe code can accidentally read too much local state: Mitigate with injected probes, allowlisted file names, bounded labels, and redaction tests. * Web diagnostics can become a debug dump: Mitigate with view helpers that convert snapshots into product-facing status rows and command chips only. * Recovery could be mistaken for trusted erasure: Mitigate with explicit copy, protocol fields, tests, and docs stating it is narrow diagnostics cleanup only. * CLI and web could drift on disabled reason labels: Mitigate by sharing protocol vocabularies and parser fixtures. ### Relevant Considerations * \[P03] **Real executors remain unimplemented by design**: This session reports readiness and recovery guidance without launching file, git, terminal, remote, container, or provider executors. * \[P03-packages/protocol] **Protocol leads cross-package work**: Shared provider diagnostics shapes should be defined before server, CLI, and web consume them. * \[P03-apps/server] **Local server boundary must stay conservative**: New diagnostics routes must inherit local auth, validation, rate limits, body caps, CORS/origin checks, and compact errors. * \[P07] **Redaction is boundary-specific**: Provider snapshots, env summaries, recovery responses, command-center diagnostics, CLI output, web cards, and docs each need explicit minimization. * \[P18-apps/server] **Manager-owned persistence and snapshot emission**: Diagnostics manager output should flow through command-center manager helpers so counts and broadcasts remain aligned. * \[P18-apps/web] **Pure normalization before store mutation**: Provider diagnostics payloads should be parsed and filtered before Zustand state changes or component rendering. * \[P18-apps/web] **Pointer and keyboard actions should share store methods**: Recovery actions and setup task creation should use shared in-flight keys for pointer and keyboard triggers. ### Behavioral Quality Focus Checklist active: Yes Top behavioral risks for this session: * A disabled provider or missing setup item could be presented as active readiness. * Recovery controls could mutate local state twice or imply broad erasure. * Environment, provider, path, command, or log values could leak through diagnostics snapshots, CLI output, WebSocket frames, or UI details. *** ## 9. Testing Strategy ### Unit Tests * Test provider diagnostics protocol parsers for valid providers, disabled reasons, setup readiness, recovery actions, compact errors, and blocked raw fields in `packages/protocol/tests/providerDiagnostics.test.ts`. * Test diagnostics manager provider probes, model list normalization, env-name-only reporting, package manager detection, setup doc detection, scan root labels, service status, recovery eligibility, idempotency keys, command-center record mapping, and redaction in `apps/server/tests/providerDiagnostics.test.ts`. * Test CLI compacting, loopback-only fetches, malformed payload handling, timeout handling, bearer auth, output redaction, and exact repair command formatting in `apps/cli/tests/providerDiagnostics.test.js`. * Test web provider matrix summaries, disabled reason copy, recovery action availability, setup task action state, and blocked payload filtering in `apps/web/tests/commandCenterUi.test.ts`. ### Integration Tests * Test `GET /diagnostics/provider-readiness` and `POST /diagnostics/orchestration/recover` at both root and `/api` prefixes with invalid bodies, duplicate idempotency keys, auth-protected local server behavior, compact errors, and no raw env/path echo. * Test orchestration diagnostics include provider/setup counts and recovery availability without embedding raw provider snapshots. * Test `factionos status` and `factionos doctor` render provider readiness, disabled reasons, recovery commands, and no secret/path values from fixture diagnostics. * Test `DiagnosticsRecoveryPanel`, `ProviderCapabilityMatrix`, and the Orchestration Diagnostics tab for loading, empty, offline, unavailable, degraded, recovery-success, command-only repair, setup-missing, duplicate-trigger, keyboard, and focus states. ### Runtime Verification * Run `npm --workspace packages/protocol run typecheck`. * Run `npm --workspace apps/server run typecheck`. * Run `npm --workspace apps/web run typecheck`. * Run focused tests for provider diagnostics protocol, server diagnostics manager, diagnostics routes, CLI diagnostics, orchestration API, command-center UI, command-center store, diagnostics recovery panel, and Orchestration panel. * Run `npm run lint`, `npm run format:check`, `git diff --check`, and ASCII/LF validation on touched files. ### Edge Cases * Provider config file exists but is malformed. * Provider binary is absent but hooks appear installed. * Model discovery is unsupported or times out. * Env example exists while runtime env values are missing. * Env values contain tokens, URLs, absolute paths, or webhook-like strings. * Scan roots are absent, invalid, duplicated, or outside approved roots. * Listener PID files are stale, invalid, alive, or unreadable. * Spool entries are valid, malformed, empty, or unreadable. * Recovery request repeats an idempotency key after partial cleanup. * Setup task action is triggered while offline or already in flight. * Web diagnostics snapshot disappears while the panel is open. *** ## 10. Dependencies ### Other Sessions * Depends on: `phase19-session01-protocol-and-events`, `phase19-session02-server-backbone`, `phase19-session03-web-shell-and-store`, `phase19-session04-campaign-workbench`, `phase19-session05-attention-and-permissions`, `phase19-session06-executor-registry` * Depended by: `phase19-session08-file-and-git`, `phase19-session09-heroes-and-lineage`, `phase19-session10-mission-artifacts`, `phase19-session11-templates-and-planning-context`, `phase19-session12-terminal-and-containers`, `phase19-session13-collaboration-and-handoff`, `phase19-session14-channels-and-scope`, and `phase19-session15-metrics-and-notifications` *** ## Next Steps Run the `implement` workflow step to begin implementation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase19-session07-provider-diagnostics/spec.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.