Sol documentation index

August 2, 2026 · View on GitHub

  • Class: index
  • Status: current
  • Dispatch: no. Follow the authority order below.
  • Owner: Sol roadmap

Sol owns the OpenAgents roadmap that uses implementation results. Omega, a tracked Zed fork, is the primary Desktop and IDE destination. Omega is also the primary company workroom destination. It implements useful Buzz outcomes as native GPUI panes. Existing configured agents attach through explicit adapters and keep their custody boundaries.

The separate Buzz installation and standalone relay and forge program are canceled. The current Electron application remains the supported release and rollback source until the Omega cutover gates pass.

The accepted Desktop Codex Workroom baseline retains its proof records and owner-approved packet ledgers. The 2026-08-02 live snapshot has no active roadmap:sol product issue. Current work must come from another exact live issue or owner-accepted packet. The three 2026-07-17 surface ProductSpecs are results that agree with the roadmap. Exact issues and packets continue to control dispatch.

Managed-sandbox epic #9023 and its projected leaves are closed. Portable movement and cross-machine Full Auto admission remain closed. Autonomous provider policy, fleet policy, voice, and settlement also remain closed. An owner must separately approve these expansions. This index points to the authorities. It does not store the roadmap revision or issue count.

Controlled language status

The 17 active Sol records use ASD-STE100 and the controlled agent compact profile. The compact profile permits reviewed density only when it improves fast and precise agent use. It does not weaken authority, safety, evidence, or ambiguity controls.

The Sol document manifest classifies current, historical, evidence, redirect, and tombstone records. The P5 receipt in docs/ste records the conversion set.

Dispatch-safe reading order

When documents disagree, use this order:

  1. AGENTS.md and INVARIANTS.md for repository law.
  2. Owning schemas, behavior contracts, product promises, and runtime policy for enforceable behavior.
  3. MASTER_ROADMAP.md for current owner decisions, priority, gates, issue disposition, and execution order.
  4. Live roadmap:sol issues and CLAIM_PROTOCOL.md for current work, ownership, and collision avoidance.
  5. Current code, tests, deployments, release records, and indexed receipts for factual proof state.
  6. Dated analyses and teardowns only as pinned historical evidence.

Never dispatch from a revision number, issue count, current-state paragraph, or copy/paste prompt in a dated analysis. Refresh the authorities above.

Current authorities and contracts

Evidence and historical baselines

These documents explain decisions or preserve point-in-time evidence. They are not current queues:

Backroom keeps the July 9 Sol argument corpus as exact, non-dispatch evidence. It has a two-way archive manifest. The July 10 execution diary remains pinned historical evidence. Neither is in this safe dispatch path.

Proof and receipt rule

Preserve the distinction between:

  1. code landed.
  2. fixture or model proven.
  3. deployed or distributed.
  4. live proven.
  5. owner accepted.
  6. closed.

A later receipt can supersede an intermediate statement in an earlier receipt. This change does not make the earlier evidence false. Use the file's final disposition and the canonical roadmap. Do not promote an intermediate rung to current truth.

Documentation maintenance

Every new or changed Sol artifact should:

  1. declare its class, snapshot, dispatch status, and owner.
  2. separate durable contract from transient implementation state.
  3. link to live issue authority instead of an open count.
  4. avoid hard-coded master revisions in active documents.
  5. name the proof rung and final disposition for receipts.
  6. move authoritative conclusions out of historical analysis.
  7. preserve owner decisions, failures, contracts, and non-revival tombstones.
  8. use Backroom for fully obsolete narrative only after conclusion extraction, link migration, and a pushed provenance manifest.
  9. run the Sol documentation gate before you land a roadmap or proof document. The offline test scripts/check-sol-docs.test.ts and pnpm run check:sol-docs must be green. The pre-push check:fast profile does not run this gate, so run it by hand before a docs-only or proof-document push. The gate checks the MASTER_ROADMAP.md line budget, internal links, and the document manifest.

The target is one small dispatch surface surrounded by indexed evidence, not a freshened copy of every old plan.