Platform View

Documentation is adapted for macOS.

Shell commands, launchd paths, and Apple runtime guidance

CLI Version Context

Installed CLI: 1.1.0 (latest compatibility profile)

Support Bundle

Capture a complete diagnostics artifact for support triage.

macos
OUT=~/Desktop/opta-support-$(date +%Y%m%d-%H%M%S).txt; { echo "# Opta Support Bundle"; echo "# Generated: $(date -u +%Y-%m-%dT%H:%M:%SZ)"; echo; opta doctor; echo; opta daemon status; echo; opta daemon logs --lines 200; echo; opta config list; } > "$OUT" && echo "Saved $OUT"
Support FAQ

Learn About

Deep workflow guides aligned to this documentation section.

Browse all Opta Learn guides

Synergies

Synergy in Opta Local means each app stays in its role while amplifying adjacent layers: runtime contracts stay centralized, and web surfaces stay synchronized.

Why Synergies Matter

Most regressions in a multi-app ecosystem are not isolated code bugs. They are mismatch bugs: one app changed but adjacent docs, status surfaces, or onboarding flows did not. Synergy work prevents that drift.

Runtime Synergies

The runtime layer has strong, intentional couplings:

  • 1D (CLI/daemon) defines control-plane behavior and session semantics.
  • 1M (LMX) owns inference/runtime semantics and discovery contract.
  • 1P (Code) consumes daemon contracts rather than reimplementing orchestration logic.
  • 1O (Init) handles lifecycle and distribution of runtime components.
  • 1L (Dashboard) is an operational client of LMX APIs.

Healthy runtime synergy means shared contracts, shared terminology, and explicit ownership.

Runtime + Web Synergies

Web surfaces should reflect runtime truth across support, marketing, status, and learning. Examples include feature status alignment, updated setup paths, and accurate API/port references after release changes.

Opta Help (this app) sits in the web surfaces layer and should mirror runtime authority, not compete with it.

Boundary Rules

  • Runtime contract changes originate from runtime-layer authorities.
  • Web surfaces consume and communicate those contracts.
  • Cross-surface updates are tracked through the content-sync-map registry.
  • Any change with ecosystem blast radius should trigger the change-impact workflow.
Practical check
Before shipping, ask: "Did I update only my app, or did I update the ecosystem surfaces that describe my app?" If unsure, run the change-impact workflow.

Release Synergy Loop

  1. Implement change in runtime or surface owner app.
  2. Run change-impact workflow against content-sync-map.
  3. Apply required updates across affected web surfaces and docs nodes.
  4. Publish with synchronized docs/status/training references.

Next: use Change Impact Workflow to turn this into a file-level checklist.