Six ways to keep your bearings.

Return after an interruption

Use a manual checkpoint when you know the next unresolved question. It is most useful when the note names an action someone can verify.

1. Leave a breadcrumb.Save a note such as “Next: verify the failing parser case.”
2. Inspect the available sessions.Use dopemux restore --list to choose a stored record.
3. Resume in the intended project.Restore a named record or launch with dopemux start --session <saved-session-id>.
4. Compare with current state.Check the branch and files before continuing.

The local snapshot is a starting point. Exact editor restoration and timed background autosave are not implemented in the inspected path. Read the full context guide.

Start a second branch deliberately

When a new request is distinct from the current change, begin by inspecting the existing workspaces rather than repurposing a busy checkout.

dopemux worktrees list
dopemux worktrees current

During another supported startup, review the worktree creation prompt and select the intended branch. Confirm the resulting directory before editing. Separate local files help keep changes distinct, but do not establish isolation of shared services or external effects.

Explore branch-workspace behavior.

Choose a focused tool configuration

1. List what exists.Run dopemux profile list.
2. Read the profile.Use profile show <name> to understand its configuration.
3. Validate before applying.Use profile validate <name>.
4. Apply deliberately.profile use <name> writes settings; inspect the active profile and live dependencies afterward.

Choose a name present in your own installation. A profile does not grant every available tool action or prove client compatibility. This guide avoids the optional restart path because its flag compatibility was not established.

Read how profiles are applied.

Leave a project-linked handoff note

Capture the next action and the unresolved boundary in ordinary language:

dopemux capture note "Parser investigation: inspect empty-input handling next" --tag handoff

The manual capture path writes an activity record with project and event identity. Inspect the ledger and capture policy when retention matters. An identical sentence written later is not necessarily the same event ID.

When execution is required, inspect the external runtime’s requirements through dopemux kernel --help. Keep execution authorization, historical notes, and workflow transitions distinct. Explore the handoff boundary.

Investigate an unfamiliar repository

Start with a focused code or documentation question through the configured retrieval tools. Follow each useful result into the actual source. If the question requires a broader evidence pass, preview the canonical extraction plan:

dopemux rte run --pipeline-version v5 --phase ALL --dry-run

Review the source scope, selected pipeline, promptset, providers, and preflight requirements before separately authorizing execution. Dry-run is not a filesystem no-op guarantee, and output remains derived evidence.

Read about retrieval and extraction.

Diagnose setup before requesting repair

dopemux routing freeflow routes --json
dopemux routing freeflow doctor --offline --json
dopemux health --detailed

Read these as separate signals. Routes report configured decisions; offline doctor avoids live backend probes; service health inspects local dependencies. None independently proves that a model request will be admitted or that a downstream workflow succeeded.

Investigate the failing dependency before authorizing repair. Do not add repair or cleanup flags to the first diagnostic step. Attention data that is unavailable should remain unavailable rather than being interpreted as a score.

Understand routing infrastructure. Review the setup sequence.