Start from the operator’s question
The architecture is easier to understand as a set of jobs than as one large assistant. The CLI coordinates local startup and session launch. Execution crosses an adapter to an external task runtime. PM metadata, workflow transitions, structured context, chronicle history, and retrieval each retain distinct owners.
This is designed to keep the source of a view visible. A search result, a transport acknowledgment, and a completed workflow transition answer different questions.
A practical map of the layers
| Question | Relevant component | Boundary |
|---|---|---|
| How does a session begin? | Dopemux CLI | Startup and operator control, not every downstream authority. |
| What is the project ticket? | Leantime | PM metadata, distinct from legal workflow transitions. |
| What phase can the work enter? | Task Orchestrator | Distinguish MCP workflow tools from the Python coordination API. |
| Why did we choose this? | ConPort | Structured decisions and context. |
| What happened before? | Dope-memory | Historical chronicle, not current PM status. |
| Where is the relevant source? | Dope-context | Derived retrieval, not source truth. |
| How does information move? | Dopecon-bridge | Transport and proxying, not ownership of carried data. |
| Who performs the execution? | External dopetask runtime | Separate execution effects and prerequisites. |
Follow context without flattening it
A local session snapshot can point you back to a branch and recent files. A structured decision can explain a constraint. Retrieval can find the implementation. A chronicle entry can record what happened during the investigation.
Those records can support the same task without becoming one interchangeable memory store. ConPort uses PostgreSQL for structured persistence; dope-memory’s canonical chronicle is SQLite; dope-context uses derived retrieval indexes. Caches and optional mirrors have narrower roles.
A handoff is more than a routed message
- Establish scope and context.Identify the current task and relevant source.
- Coordinate the next action.Use the appropriate workflow and operator tools.
- Cross the execution boundary.Invoke the separately configured runtime only within the task’s authority.
- Retain and verify evidence.Record history, inspect actual outputs, and verify acceptance separately.
Cross-service events may be best-effort rather than atomic. An originating write can succeed while downstream delivery or consumer persistence still needs verification.
Scope and status remain component-specific
Separate worktrees do not prove isolated databases, event streams, credentials, or fixed ports. A catalog’s lifecycle label does not prove a running service. A healthy shim does not prove MCP-tool availability.
Known source ambiguities include two Task Orchestrator surfaces, Serena’s transport disagreement, narrower current facade tooling, and PAL’s health-only HTTP path. Their detail pages preserve those distinctions rather than choosing a convenient interpretation.
Read Alpha status for the website’s exact evidence vocabulary.
Source evidence
Inspected source at the pinned reference revision. Source presence does not establish runtime health.