> 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/docs/legacy-consolidation.md). # Legacy Consolidation ## Planning Baseline The archived planning baseline is: * `docs/PRD.md` for functional product requirements. * `docs/PRD_UX.md` for experience requirements. * Phase PRDs and session specs for implementation planning. * Current source code, tests, README files, and stable docs for implemented behavior. Historical extraction files are evidence, not product authority. ## Historical Inputs | Path | Role | | -------------------------------------------- | ---------------------------------------------------------------------------------------- | | `EXAMPLES/findings/` | Historical API, event, architecture, service, prompt, and extraction inventories. | | `EXAMPLES/1st-pass-artifacts/` | Historical hooks, manifests, skills, templates, Docker recipe, and copied package files. | | `EXAMPLES/REPORT.md`, `EXAMPLES/REPORT.html` | Historical extraction reports moved out of tracked `docs/`. | | `docs/PROGRESS.md` | Historical build ledger. | | `EXAMPLES/` | Gitignored quarantined media and build-output intake source. | ## Disposition Vocabulary Each unique historical feature, contract, risk, or decision should eventually receive one of these dispositions: * `shipped` * `planned` * `backlog` * `pending-review` * `obsolete` * `explicitly-rejected` Rejections need a rationale. Deletions need stable-doc coverage. ## Deletion Gates Do not delete historical material until: 1. Unique product requirements are captured in the PRD, UX PRD, stable docs, tests, or this consolidation record. 2. API, event, hook, adapter, and service contracts needed for implementation are represented outside the historical file. 3. License, privacy, hosted-service, and media-provenance risks are captured without repeating raw tokens or sensitive probe output. 4. Phase 08 release-hardening criteria explicitly allow the deletion. ## Current State The old Phase 00 session folder has been consolidated into stable docs. It is no longer the source of truth for current planning. Retained value now lives in this file, `docs/api/event-api-hook-contracts.md`, `docs/media/media-assets.md`, `docs/release.md`, `docs/README_docs.md`, the PRD, and the UX PRD. Session 01 produced the historical source map and traceability rules. The retained value is: | Area | Retained value | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Source groups | `EXAMPLES/findings/`, `EXAMPLES/1st-pass-artifacts/`, `EXAMPLES/REPORT.*`, `docs/PROGRESS.md`, stable README evidence, and quarantined `EXAMPLES/`. | | Review policy | Historical files are evidence only until their value is captured in the PRD, UX PRD, stable docs, tests, this file, or an explicit rejection note. | | Safety policy | Do not copy raw token values, OAuth IDs, probe output, prompt bodies, full command output, or sensitive local paths from historical material into stable docs. | | Follow-up owners | API/event/hook contracts belong in API docs; media provenance belongs in `docs/media/media-assets.md`; deletion gates belong in `docs/release.md`; runtime hardening belongs to Phase 01. | The archived Session 01 validation recorded a documentation-only pass, ASCII/LF checks, `git diff --check`, privacy-sensitive copy checks, and an `npm test` pass at that point in time. Treat that as historical validation of the traceability package, not a current repository test result. Session 02 produced the current contract package: | Area | Retained value | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical contract | `docs/api/event-api-hook-contracts.md` owns source-backed REST, `/event`, WebSocket, protocol, hook, historical-source, and Phase 01 hardening details. | | Historical comparison | Broad route inventories are not shipped local-server parity; unsupported local paths should remain 501-stubbed unless implemented. | | OpenClaw compatibility | Historical `type`-only payloads are unsupported as written. They need supported `eventName`/`hook` values or deliberate Phase 01 compatibility work. | | Hardening gaps | Auth, CORS, WebSocket origin, runtime schemas, hook mapping, redaction, export privacy, hook reliability, and route-parity tests remain Phase 01 work. | Session 02 also aligned `docs/api/README_api.md`, `apps/server/README_server.md`, and `apps/hooks/README_hooks.md` to point to the canonical contract instead of duplicating historical inventories. The review concluded that `/event` dispatches from `eventName` or `hook`, not `type` alone; broad historical local-server paths should remain unsupported or 501-stubbed unless implemented; several protocol events are typed-only or planned; and hook-specific payload types stay generic `tool_use` or `mission_event` frames until a future session adds first-class mapping. The archived Session 02 validation recorded a documentation-only pass, focused Vitest coverage for protocol events and server route/permission/export/LLM suites, a full `npm test` pass at that point in time, ASCII/LF checks, and a security review confirming no raw tokens, OAuth IDs, probe output, prompt bodies, sensitive local paths, or long historical excerpts were copied. Session 03 produced the current stable-documentation alignment package: | Area | Retained value | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Stable doc authority | `docs/PRD.md`, `docs/PRD_UX.md`, `docs/api/README_api.md`, package READMEs, `docs/CONVENTIONS.md`, and `docs/SECURITY-COMPLIANCE.md` should be preferred over historical reports. | | Status vocabulary | Stable docs should distinguish shipped, planned, deferred, stubbed, historical evidence, and quarantined material. | | Cleanup candidates | Phase 08 cleanup candidates are listed below and in `docs/release.md`; they are not deletion approvals. | Session 03 replaced old phase-led stable-doc wording with concise current capability summaries, clarified shipped versus planned or stubbed surfaces, aligned the license posture with the root `LICENSE`, and made historical reports and progress ledgers evidence-only. It also clarified that War Room has a shipped optional Worker backend but not full web-panel federation, adapters are outbound-only, hosted services and analytics are optional or future surfaces, and ignored `EXAMPLES/` media remains quarantined and reference-only. Use it to capture standards and implementation gaps; do not import, copy, transform, or promote those files directly into product paths. The archived Session 03 validation recorded documentation link/path checks, stale wording checks, privacy-sensitive copy checks, ASCII/LF checks, `git diff --check`, a security review for documentation changes, and a root `npm test` pass in the validation record. Treat those as historical validation of that documentation alignment, not a current repository test result. Phase 01 produced the current local runtime contract package. Retained value is captured in stable docs rather than left in historical intake files: | Session | Retained value | Stable owner | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | 01 Event Ingest Contract Reconciliation | Source-backed `/event` compatibility, protocol updates, current hook mapping, and unsupported historical payload boundaries. | `docs/api/event-api-hook-contracts.md`, `docs/api/README_api.md`, `packages/protocol/README_protocol.md` | | 02 Hook Runtime Safety | Quiet hook failure behavior, bounded POSTs, sanitized diagnostics, listener lifecycle, spool posture, and atomic local state writes. | `apps/hooks/README_hooks.md`, `apps/cli/README_cli.md`, `docs/privacy-and-security.md` | | 03 CLI Lifecycle Parity | Current-workspace start/open/stop lifecycle, PID/project metadata, status/doctor diagnostics, uninstall boundaries, and local state privacy. | `README.md`, `apps/cli/README_cli.md`, `docs/development.md` | | 04 Server Routes and Authorization Boundaries | Loopback bind default, CORS/Origin/token auth, high-risk route validation, unsupported-route 501 classifications, and local server security defaults. | `apps/server/README_server.md`, `docs/api/event-api-hook-contracts.md`, `docs/privacy-and-security.md` | | 05 WebSocket Hydration and Archive Export Privacy | Hydration/client-message contracts, malformed socket handling, duplicate approval guards, export/archive/replay redaction, and privacy headers. | `docs/api/event-api-hook-contracts.md`, `packages/protocol/README_protocol.md`, `apps/server/README_server.md`, `docs/privacy-and-security.md` | | 06 LLM Fallback and Scan Privacy | Deterministic fallback behavior, two-level provider-transfer opt-in, scan root allowlists, redacted memory output, and LLM privacy headers. | `apps/server/README_server.md`, `docs/api/README_api.md`, `docs/privacy-and-security.md` | | 07 Runtime Contract Documentation | Final stable-doc alignment and Phase 01 traceability closeout. | This file, `README.md`, package READMEs, and `docs/ARCHITECTURE.md` | Phase 01 source-intake coverage is summarized below. The source paths remain traceability evidence only; current source, tests, and stable docs are the user contract. | Source group | Phase 01 disposition | Remaining dependency | | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `EXAMPLES/findings/api-routes.txt` | Current local REST routes are classified as tested-shipped, stubbed, planned, unsupported, or separate-surface. Unsupported routes return deterministic 501 payloads. | Future phases implement file/git/terminal/task queue/collaboration route families. | | `EXAMPLES/findings/websocket-events.txt` | Current hydration frames and client messages are tested; additional historical event names remain typed-only, planned, or unsupported. | Future orchestration/collaboration phases decide which remaining events become runtime producers. | | `EXAMPLES/findings/claude-hook-contract.md` | Current Claude hook map and selected compatibility payloads are tested and documented. | Deeper historical payload variants need deliberate protocol and `/event` work. | | `EXAMPLES/findings/architecture.md` | Current package map, optional services, War Room separation, LLM engines, archive/memory posture, and local-first boundaries are reflected in stable docs. | Agent orchestration, media pipeline, hosted analytics, and final cleanup remain future phases. | | `EXAMPLES/findings/BUILD_LINKS.md` | Retained as pointer evidence; stale claims are superseded by Phase 01 docs and tests. | Phase 08 can reduce or delete after remaining source groups are captured. | | `EXAMPLES/findings/llm-prompts/` | Current LLM plan/analyze/scan/idle/memory fallbacks and provider-transfer boundaries are documented and tested. | Future orchestration may expand prompt surfaces and agent-template affordances. | | `EXAMPLES/1st-pass-artifacts/*` package, hook, listener, CLI, and template files | Current hook install, listener, CLI lifecycle, and local state behavior are captured where implemented; unsupported remote/control behavior is not shipped. | Agent templates, spawn/resume/stop/fork/handoff, Docker isolation, and skill catalog work remain later phases. | ## Phase 02 Product Surface Handoff Phase 02 Session 01 captures browser-facing requirements from current source and stable docs without promoting historical artifacts into product behavior. The retained product-surface value is: | Area | Retained value | Stable owner | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Cockpit shell, navigation, overlays, and commands | Current React source, focused tests, and UX requirements define shipped and Phase 02 behavior. Historical screenshots or bundles can identify gaps only. | `.spec_system/PRD/PRD.md`, `.spec_system/PRD/PRD_UX.md`, `.spec_system/archive/phases/phase_02/product_surface_gap_matrix.md` | | Hero, mission, permission, and plan workflows | Current web components and protocol/server contracts define the supported local workflow. Historical orchestration or remote-control records remain deferred unless a later phase implements them. | Web source, `docs/api/README_api.md`, Phase 02 gap matrix | | 2D battlefield and public demo | Current generated battlefield assets, app source, public demo source, and media records define the approved asset set and interaction contract. | `docs/battlefield.md`, `docs/media/media-assets.md`, `docs/public-demo-code-sharing.md` | | Settings, replay, notifications, exports, and scan UX | Phase 01 privacy boundaries and current browser source define safe local behavior. Hosted replay, analytics, and broad sharing stay deferred. | `docs/privacy-and-security.md`, `docs/api/README_api.md`, UX PRD | | Phase 02 validation closeout | App and public demo desktop/mobile browser evidence, quality gates, security closeout, and remaining-gap handoff define Phase 02 readiness for the validate workflow. | `.spec_system/archive/sessions/phase02-session07-product-surface-validation-and-documentation-closeout/` | | Historical product and media material | `EXAMPLES/`, extraction reports, copied bundles, and `docs/PROGRESS.md` are evidence only. They can be cited by path for traceability, standards, and explicit rejection notes, but not copied, imported, transformed, or shipped. | This file, `docs/media/media-assets.md`, `docs/release.md` | Product-surface docs may preserve conclusions from historical material, but must not preserve raw prompts, raw probe output, sensitive local paths, token values, OAuth IDs, copied bundle code, copied media, or direct generation inputs from quarantined files. Deletion approval remains a Phase 08 release gate. Session 07 also records one retained UI lesson for later cleanup and release work: screenshot review is a real gate, not just a file artifact. The Phase 02 public demo mobile header overlap was fixed in current source, and the service-worker cache version is now `factionos-demo-v9` after Phase 04 media and public-demo validation. This is retained as product-surface and media closeout evidence; it is not approval to delete historical artifacts or promote quarantined media. ## Phase 03 Orchestration Handoff Phase 03 Session 01 captures orchestration routing in `.spec_system/archive/phases/phase_03/orchestration_gap_matrix.md`. The retained orchestration value from current source and historical intake is: | Area | Retained value | Stable owner | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Task queue and agent templates | Shipped local, in-memory, non-executing queue entries and source-owned template contracts are owned by protocol, server, web, and API docs. Broad historical queue/session/suggestion routes remain unsupported or planned. | Phase 03 Session 02, `packages/protocol/README_protocol.md`, API docs | | Subagent lineage and mission graph | Shipped typed lineage and mission graph state is produced when safe hook identifiers exist; missing or malformed identifiers degrade to bounded summaries. | Phase 03 Session 03, event/API docs, hook docs | | Guarded local actions | Shipped guarded-action proposals and decisions are local, bounded, duplicate-guarded, and non-executing unless a safe executor exists. File, git, terminal, remote, and container execution remain deferred or excluded. | Phase 03 Session 04, server/API docs | | Web and CLI orchestration controls | Shipped web controls and CLI diagnostics summarize queue, template, lineage, guarded-action, hook/listener, spool, and server posture without exposing raw local payloads. Recovery is limited to stale listener PID files and malformed spool JSON. | Phase 03 Sessions 05-06, web and CLI docs | | Later-phase boundaries | War Room federation, hosted collaboration, inbound chat commands, public sharing, analytics, Docker isolation, broad remote execution, and final decommission remain deferred or excluded. | Phase 05, Phase 07, Phase 08, future approved scope | Phase 03 Session 07 validates and documents the shipped local subset. It does not approve deletion of historical material, hosted sharing, Worker federation, media promotion, Docker isolation, remote execution, or release decommission work. Historical orchestration evidence in `EXAMPLES/` may be cited by path for traceability, but stable docs must not copy raw prompts, command bodies, terminal output, token-like values, OAuth IDs, probe output, sensitive local paths, copied bundled code, or media. The matrix is a routing artifact, not a deletion approval. ## Phase 04 Media Handoff Phase 04 Session 01 routes media work through `.spec_system/archive/phases/phase_04/media_gap_matrix.md`. The retained media value is: | Area | Retained value | Stable owner | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Current runtime media | Approved battlefield WebP runtime set, generated PNG references, app portraits, brand/showcase files, public demo speech/music, icons, manifest, and service-worker behavior are identified by current paths and release blockers. | `docs/media/media-assets.md`, media gap matrix | | Catalog and promotion work | Typed catalog contracts, promotion tooling, metadata cleanup, byte budgets, and docs checks remain later Phase 04 sessions. | Phase 04 Sessions 02-03 | | Audio and music | Public demo MP3s are artifact-local and conditional; full app file-backed audio remains planned. Legacy MP3s are taxonomy evidence only. | Phase 04 Sessions 04-05 | | Accessibility, privacy, performance | Captions, visible equivalents, fallback states, metadata stripping, lazy-loading, service-worker cache rules, sensitive-path minimization, and size budgets are release blockers. | Phase 04 Session 06 | | Historical media | GUI/HUD, achievements, icons, models, textures, screenshots, bundled chunks, and speech in `EXAMPLES/` stay prototype-only, rejected, or deferred evidence. | This file, `docs/media/media-assets.md`, release decommission gates | This handoff does not approve direct promotion from `EXAMPLES/`, deletion of historical artifacts, hosted media transfer, public replay/media hosting, or War Room/collaboration media work. ## Source Group Ownership | Source group | Current disposition | Stable owner or gate | | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Historical route, event, hook, listener, OpenClaw, and build-link findings | Captured for contract purposes; unsupported behavior remains unsupported. | `docs/api/event-api-hook-contracts.md`, Phase 01 hardening, release decommission gates. | | Historical package manifests, hook configs, skills, templates, Docker recipe, and copied package evidence | Mixed captured, planned, obsolete, or pending-review depending on the child group. | Package READMEs, PRD future phases, security register, release decommission gates. | | Historical service-discovery, hosted-service, token, OAuth, probe, prompt, and path evidence | Quarantined or summarized as posture only. | `docs/SECURITY-COMPLIANCE.md`, `docs/privacy-and-security.md`, and release decommission gates. | | Historical asset inventory, bundle manifests, `characterModels.*`, frontend/PWA asset references, and `EXAMPLES/` | Quarantined reference-only media intake. | `docs/media/media-assets.md`; no direct runtime promotion from `EXAMPLES/`. | | Phase 04 media gap matrix | Source-backed routing for current, planned, prototype-only, rejected, unknown, and deferred media groups. | `.spec_system/archive/phases/phase_04/media_gap_matrix.md`; later Phase 04 sessions must resolve blockers before release expansion. | | Historical reports and progress ledger | Cleanup candidates after retained value is captured or explicitly rejected. | `docs/release.md` and Phase 08 release-hardening gate. | ## Phase 01 Handoff The retained cleanup handoff for Phase 01 is to harden the local server trust boundary, `/event` ingest, WebSocket validation, hook-specific event mapping, hook reliability, export privacy, LLM scan privacy, dependency reproducibility, and shared redaction for prompts, paths, command previews, adapters, analytics, archives, replay buffers, and federation. ## Phase 08 Candidates These are cleanup candidates, not deletion approvals: | Candidate | Likely action | Required gate | | -------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `docs/PROGRESS.md` | Delete after stable docs and Git history cover retained milestones. | Release decommission matrix plus Phase 08 release gate. | | `EXAMPLES/REPORT.md`, `EXAMPLES/REPORT.html` | Keep ignored or delete locally after unique findings are captured. | Stable-doc coverage for API, event, service, license, and media findings. | | `EXAMPLES/findings/` | Keep ignored or delete locally after inventories are captured or rejected. | Contracts, prompts, service posture, and risks represented in stable docs or this file. | | `EXAMPLES/1st-pass-artifacts/` | Keep ignored or reduce locally after copied evidence is captured. | Hooks, manifests, templates, Docker recipe, package evidence, and token hygiene resolved. | | `EXAMPLES/` | Keep ignored as reference-only standards and gap evidence. | Reference inventory plus generated or owned replacements with rights, attribution, optimization, metadata, and size-budget decisions. | The initial Session 01 candidate inventory lives in `.spec_system/archive/phases/phase_08/decommission_approval_matrix.md`. It is not an approval record. Session 07 must assign final dispositions and rerun affected release, media, quarantine, sensitive-output, docs, whitespace, ASCII, and LF gates before deletion, reduction, or archive actions. Do not preserve duplicate historical detail inside new stable docs. Preserve the decision, contract, risk, or requirement; then remove the old evidence only after the relevant gate approves it. ## Phase 08 Session 07 Decommission Review Session 07 moves the candidate list into final-review tracking without making destructive cleanup the default. The controlling action record is `.spec_system/archive/phases/phase_08/legacy_decommission_media_release_gate.md`. Current stable-doc coverage: | Historical value | Stable replacement | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Route families, unsupported local paths, WebSocket hydration, `/event` dispatch, hook mappings, and OpenClaw compatibility lessons. | `docs/api/event-api-hook-contracts.md`, `docs/api/README_api.md`, `apps/server/README_server.md`, `apps/hooks/README_hooks.md`, `packages/protocol/README_protocol.md` | | Local-first package map, optional Worker boundary, hosted-service no-claim wording, erasure boundaries, and privacy posture. | `docs/ARCHITECTURE.md`, `docs/hosted-services.md`, `docs/privacy-and-security.md`, `docs/environments.md` | | Hook install, listener, CLI lifecycle, manifest, template, Docker/isolation, package, and token-hygiene lessons from copied first-pass artifacts. | Package READMEs, `docs/isolation-and-sandbox.md`, `docs/development.md`, this file | | Media provenance conclusions, approved battlefield runtime records, conditional public-demo media, generated drafts, unknown-provenance media, and quarantine policy. | `docs/media/media-assets.md`, ADR 0004, Phase 04 media gap matrix, `assets/generated/phase04/draft-generation-manifest.json` | | Release cleanup gates, sensitive-output guardrails, no-overclaim wording, and final closeout ownership. | `docs/release.md`, Phase 08 routing/risk matrices, Session 07 action record | | Milestone chronology and previous phase context. | PRD phase history, archived session specs and validations, Git history, and retained `docs/PROGRESS.md` | Session 07 final-review outcomes: | Candidate group | Outcome | Reason | | --------------------------------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `EXAMPLES/findings/` | Retain ignored evidence. | Stable docs preserve current conclusions, and ignored findings remain useful traceability unless a release record proves release copy no longer depends on them. | | `EXAMPLES/1st-pass-artifacts/` | Retain ignored evidence. | Copied code and bundles are not stable docs, but package/hook/template/Docker lessons still benefit from local reference during final closeout. | | `EXAMPLES/REPORT.md` and `EXAMPLES/REPORT.html` | Retain ignored evidence. | Unique migration rationale is summarized in stable docs; reports can stay ignored rather than be deleted by release automation. | | `docs/PROGRESS.md` | Retain tracked evidence. | PRD and archive history cover current planning, but the ledger remains useful resume context unless final release-candidate documentation sync records a different decision. | | Ignored `EXAMPLES/` media and build output | Block release promotion; retain ignored reference evidence. | Source, rights, attribution, metadata, fallback, accessibility, privacy, and budget blockers remain open for historical media. | | Generated media drafts and provider staging | Retain tracked manifest; block raw staging promotion. | Draft records are redacted and non-runtime; raw provider outputs stay ignored and out of stable docs. | | Historical service-discovery and sensitive evidence | Block raw evidence; retain posture conclusions only. | Stable docs preserve no-claim and reserved-variable lessons without raw values, probes, prompts, or path evidence. | | Archived spec-system records | Retain. | Archive records remain validation and handoff evidence. | No Session 07 stable doc should quote historical report bodies, copied bundle code, raw prompts, probe output, token values, OAuth values, command output, sensitive local paths, generated provider payloads, or quarantined media excerpts. If a future cleanup session wants deletion or archive movement, it must start from the Session 07 action record and rerun the affected gates. ## Phase 08 Session 08 Release-Candidate Closeout Session 08 keeps the Session 07 decommission dispositions intact. Local release gates and docs sync can record retained evidence paths and conclusions, but they do not approve destructive cleanup of ignored `EXAMPLES/` content, raw provider staging, copied build output, historical service-discovery material, archived spec records, or `docs/PROGRESS.md`. Production-hosted smoke blockers and final no-overclaim review are release-copy constraints, not automatic deletion approval. If a later cleanup session removes or archives retained evidence, it must cite the release-candidate validation record, rerun affected media/sensitive-output gates, preserve stable docs coverage first, and avoid copying raw prompts, tokens, OAuth values, probe output, local paths, command output, provider payloads, or quarantined media excerpts into the cleanup record. --- # 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/docs/legacy-consolidation.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.