Skip to content

Documentation scope (EDOS workspace)

Audience: Agent + operator

This document defines what the EDOS documentation set is responsible for covering, and what it deliberately excludes. It is aimed at readers and coding agents that need to modify existing projects or add new ones without treating the workspace as a monorepo.

What this workspace is

The edos directory aggregates multiple standalone projects in one place so the ecosystem can be described and navigated coherently. Each top-level folder is its own unit of build, test, and release unless a later doc states a deliberate coupling.

Projects present at this scope definition (names only; per-project detail comes in later phases):

Folder Role (high level)
api-cache-server HTTP API service (Bun/Elysia/Prisma under api/); UI may exist alongside per project layout.
elite-dangerous-event-types TypeScript types for journal file events (published package name in that project’s package.json).
elite-dangerous-local-journal-reader Intended local journal access; TODO: Verify entrypoints if your checkout is empty — see TODO.md.
elite-dangerous-remote-journal-reader Hosted journal reader UI (Quasar); local files via File System Access API — see ARCHITECTURE.md.
elite-dangerous-surface-map Surface map UI and related logic (Quasar/Vue app under ui/).
inter-frame-messenger Cross-context messaging (e.g. host ↔ embedded web UI).
docs Documentation for the ecosystem (this tree).

Some folders may be incomplete in a given clone (sparse checkout, submodule, or work in progress). See REPOS.md for build/run entrypoints and TODO.md for known gaps.

In scope

  • Architecture of how these projects fit together: data flow from journal files through readers to UIs and auxiliary services; use of shared types; caching and external APIs where relevant.
  • Inter-process / embedding integration: how native or shell hosts talk to web UIs (postMessage, origins, WebView assumptions), building on themes in original-concept.md and grounding them in actual code.
  • Operational expectations: how to build and run each project, environment assumptions, and compatibility notes for community tools (e.g. modern WebView vs legacy).
  • Fair use of community HTTP APIs: routing third-party requests through the API cache server so volunteer-run services are not overloaded (see ARCHITECTURE.md).
  • Extension guidance: where to plug in features, how to add a new project that participates in the same patterns without merging repos into a monorepo.
  • Agent-oriented playbooks: checklists, invariants, and “do not break” rules for IPC and journal handling.

Out of scope

  • Turning this workspace into a monorepo (single root package, unified CI for all projects, or forced shared versioning). Docs may recommend patterns; they will not assume a monorepo layout.
  • Frontier / game internals beyond what community tools observe via journal and public APIs.
  • Official Elite Dangerous support or endorsement; this is third-party/community documentation.
  • Duplicating upstream reference docs (full journal schema encyclopedia) where a link plus project-specific usage notes suffices—unless a maintainer explicitly wants a local mirror.
  • User-facing tutorials for playing the game, unless they are needed to explain a specific tool’s behavior.

Boundaries

  • Documentation may live in a separate repository later; scope is the same: describe the ecosystem and contracts, not “only what lives in one git root.”
  • Per-project deep dives belong in docs/apps/PROJECT_SLUG.md (see DOC_CONVENTIONS.md), not in this file.

Revision

When new top-level projects are added to the workspace, update the table in this file and, if needed, DOC_CONVENTIONS.md naming examples.

Documentation index

Full table of contents: README.md.