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-mapregistry. - Any change with ecosystem blast radius should trigger the change-impact workflow.
Release Synergy Loop
- Implement change in runtime or surface owner app.
- Run change-impact workflow against
content-sync-map. - Apply required updates across affected web surfaces and docs nodes.
- Publish with synchronized docs/status/training references.
Next: use Change Impact Workflow to turn this into a file-level checklist.