Workspace lanes

Steelmoth’s autonomous and human-driven work share a single git working tree (the morpheus_workspace named volume — same .git directory mounted into the worker container at /home/steelmoth/morpheus-repo). Branches are the unit of isolation.

The branch namespaces

Prefix	Owner	Created by	Cleanup
main	canonical	upstream / merges	live deployments rebuild from this; never edit directly on the morpheus volume
morpheus/T<id>-<slug>	autonomous codex drain	_run_drain_cycle_body via branch_for_todo(todo_id, content) (default prefix)	merged via gh pr create then deleted upstream
human/<feature>	operator manual work	operator runs git checkout -B human/<feature> origin/main themselves	operator merges or deletes

main is canonical. Live deployments rebuild from main. During init, steelmoth-morpheus-init fetches origin and resets/cleans only when the workspace is checked out on MORPHEUS_REPO_BASE and the matching origin/MORPHEUS_REPO_BASE ref exists; active lane branches are left intact. When both the remote base branch and local Git fallback are unavailable, the init service can bootstrap a local Git worktree from the read-only host snapshot so the private stack keeps booting. After init, the service can remain alive as a periodic fetch loop every MORPHEUS_SYNC_INTERVAL_S seconds (default 300), but that loop fetches refs only and never resets or cleans the working tree.

How a routed todo lands on its lane branch

1. Operator tags a todo with #morpheus (required by the drain selection allowlist), routing it to the codex lane.
2. Endless dreaming picks the todo and calls morpheus_drain.run_drain_cycle.
3. The v2 pipeline creates morpheus/T<id>-<slug> from fresh origin/main and walks planning → coding → smoke → browser → pr-open phases.

How an operator works manually

For ad-hoc manual work without a routed todo:

git checkout -B human/<feature> origin/main
# ... edit, claude, commit ...
git push -u origin human/<feature>

Never edit main directly in the shared workspace. The init-time refresh path resets main to origin/main and runs clean -fd when the workspace starts on MORPHEUS_REPO_BASE; uncommitted edits on main can be lost on service bring-up. Lane branches are the safe place for in-flight work.

Landing a human/<feature> branch into main (solo workflow)

Default solo workflow (operator is the only reviewer): one-liner sequence that auto-opens a PR and auto-merges it with squash + branch delete, so the audit trail lives on GitHub but no manual review step blocks the ship.

git push -u origin human/<feature>
gh pr create --fill --base main
gh pr merge --squash --delete-branch

Within ~5 minutes the steelmoth-morpheus-init periodic-fetch loop pulls the new main into the shared workspace, so the next routed morpheus/... task starts from your latest code automatically.

For trivial typo / wiki edits the operator may push directly to main (skipping branch + PR), but never for code that runs in containers, schema changes, deploy scripts, or anything covered by a HARD RULE — those keep the PR record even when the operator is the only reviewer.

Cross-UID write access

The shared workspace is owned by UID 1000 (steelmoth in the worker container, ubuntu on the host). Inside the worker image, /etc/gitconfig carries safe.directory '*' so git accepts the workspace regardless of file ownership UID.

Known Unknowns

• Repo files show the worker image contains git/gh tooling and that morpheus-init writes a repo-local credential helper, but they do not prove the current container has usable GitHub auth. Inspect live auth state before claiming push or PR creation works from the worker container.