OpenProgram Docs
OpenProgram implementation navigation
Use this page to find the current owner of a design and its implementation evidence. It does not certify an integration branch, release, or installed application.
Designs explain intended behavior; implementation notes locate code and verification. Historical review results remain in Git history.
Find the implementation documentation
| Area | Design | Supporting documentation | What to inspect |
|---|---|---|---|
| Repository ownership | Design | Implementation context | Application roots, compatibility surfaces and verification. |
| Execution control | Design | Implementation context | Pause, resume, cancellation, recovery and surface synchronization. |
| Goal execution | Design | Implementation context | Controller lifecycle, persistence and remaining acceptance. |
| Sessions and DAG | Design | Implementation context | Graph semantics, storage and session operations. |
| Permissions and sandbox | Design | Implementation context | Authority, approvals and execution boundaries. |
| Memory | Design | Implementation context | Memory ownership, recall and implementation boundaries. |
| Web integration | Design | Implementation context | Browser integration and its implementation evidence. |
| Record and replay | Design | Implementation context | Provider recording, replay and failure handling. |
| MCP server | Design | Implementation context | Server exposure and MCP integration. |
| Distribution | Design | Implementation context | Packaging, activation, updates and release acceptance. |
| Testing | Design | Implementation context | Verification layers and source-layout checks. |
For other areas, use the subsystem index. The framework feature comparison has a separate comparison scope; it is not a release acceptance report.
Read implementation status precisely
| State | Required meaning |
|---|---|
| Implemented | The described contract has an implementation and the required verification evidence. State the verified boundary explicitly. |
| Partial | Some paths exist, but named implementation or acceptance requirements remain. |
| Unimplemented | The design specifies behavior for which implementation is still required. |
| Out of scope | The behavior is excluded from the current design; it is not an implicit implementation task. |
| Not reverified | Existing evidence has not been checked against the current source or target environment. Do not convert it into a current pass. |
What each implementation document contains
- Public entry points and the observable behavior they provide.
- Source owners and links to the implementation, including compatibility entry points.
- Data ownership, state transitions and persistence boundaries.
- Failure, cancellation and recovery behavior where applicable.
- Reproducible verification commands and the specific contract each checks.
- An implementation-status appendix listing remaining work and acceptance gaps.
Maintain architectural rationale in the topic's design. Keep implementation notes focused on the source mapping and verification. Use Git history for migration chronology and previous review output rather than duplicating them across pages.
Implementation status
This navigation update does not rerun subsystem tests or establish publication, deployment or installed-App acceptance. Consult the linked topic for its evidence and reverify the affected contract before changing its status.