START WITH ONE BOUNDED LOOP

Build.

Start local. Install the CLI, claim one bounded work item, attach evidence, release it, and inspect the close record. Then see how that same packet survives handoff, review, and later reuse.

install
install, init, doctor
loop
claim -> evidence -> release
packet
handoff, evidence, receipt
WHAT YOU ARE ACTUALLY DOING

From concept to one portable packet.

Motus is not asking you to learn random commands. Each command pins one part of the work packet so the work can survive handoff, retry, review, and later inspection.

the path

I understand the concept. Now I want to know what each step buys me.

claim
temporary ownership and one active close handle
evidence
proof stays attached while the work happens
release
close is explicit instead of implied in chat or tickets
handoff
execution envelope for the next actor or attempt
receipt
accepted close record the next step can trust
READ THE MAP ONCE

Use the site in this order.

If you are new to Motus, do not try to memorize every term at once. Start with the first loop on this page, then use the other pages when you need more precision.

site order

I need to know where to start, what to read next, and what each page is for.

Build
start here if you want the first working loop: install, claim, evidence, release, inspect
Control
read next if you want the why: what problem Motus solves and what the packet model is
Define
use this when the work needs an explicit contract before execution starts
Verify
use this when you need to understand gates, acceptance, and what a trusted close looks like
Access
use this only if you want the preview path or direct support; it is not required for a self-serve first run
PREREQUISITES

What you need.

Python 3.9+, git, and a repo. That is it.

Motus does not replace your stack. It does not require a hosted account, a service boundary, or a new database. Contracts live in your repo. Receipts export as JSON. The CLI runs locally.

You choose where data lives. You choose what to surface. You choose how to integrate. This is ownership by design, not missing features.

python3
3.9 or later
git
any recent version
a repo
where you want workflow discipline
no hosted lock-in
contracts and receipts are yours
INSTALL

Get the CLI.

Install the CLI, install Motus defaults, then init in your repo. If it is not useful, you can stop here without unwinding a hosted tooling decision.

install

One command. If it breaks, I have not lost anything.

# install the CLI
$ pip install motusos
$ motus --help

# install Motus defaults
$ motus install

# init in your repo
$ cd your-repo
$ motus init --lite --path .
$ motus doctor
FIRST WORKFLOW

Claim, evidence, release.

One workflow end to end. This is the pattern you will repeat for every bounded unit of work whether the actor is you, CI, or an agent.

core loop

I want to see the full loop before I customize anything.

# set your agent ID
$ export MC_AGENT_ID=you-local

# claim work (day1 ad hoc)
$ LEASE_ID=$(motus work claim ADHOC-DAY1-001 --intent "Day1 smoke" | awk -F': ' '/^Lease ID:/ {print $2}')

# make your change, then attach evidence
$ motus work evidence "$LEASE_ID" test_result --passed 1 --failed 0

# inspect the active packet before close
$ motus work status "$LEASE_ID" --json

# release
$ motus work release "$LEASE_ID" success
WHY THE LEASE EXISTS

Lease means temporary ownership, not bureaucracy.

The lease is the active handle for one attempt at one work item. It prevents hidden parallel ownership and gives evidence and close decisions one place to attach.

If the work changes hands, the handoff moves with it. If the work closes, the lease ends and the close record is explicit. That is what keeps the packet portable instead of fragile.

one owner
who owns the active attempt right now
one evidence path
proof attaches to the same active lease
one close handle
release closes the exact attempt you claimed
# what claim gives back
{
  "decision": "GRANTED",
  "reason_code": "GRANTED_OK",
  "lease_id": "lease-20260403-360e8b5e",
  "message": "Access granted."
}
WHAT YOU WILL SEE

Motus leaves concrete local surfaces behind.

The first run should produce visible state you can point to. If you cannot show the lease, the evidence, and the close result, do not scale the workflow yet.

physical view

I need to know what actually appears on my machine after each step.

~/.motus/
machine-local defaults and coordination state
.motus/
repo-local Motus state for the workspace you initialized
lease ID
the exact active handle returned by claim
status output
proof attached to the active lease before close
release response
the explicit terminal result that proves the loop closed
# what changes after the first loop
$ ls -d ~/.motus .motus
~/.motus
.motus

$ motus work status "$LEASE_ID" --json
{
  "lease_id": "lease-20260403-360e8b5e",
  "lease_status": "active",
  "evidence": [
    {
      "evidence_type": "test_result",
      "test_results": {"passed": 1, "failed": 0, "skipped": 0}
    }
  ]
}
ONE PACKET IN MOTION

See what actually happens from first claim to accepted close.

Use one concrete task: align the onboarding docs for new operators. The work starts with one lease and accumulates evidence. It can hand off without changing scope and closes with a receipt the next actor can trust.

packet in motion

I do not just want the nouns. I want to know what the work looks like while it moves.

# example work item
$ LEASE_ID=$(motus work claim DOCS-ONBOARDING-001 --intent "Clarify first-run path" | awk -F': ' '/^Lease ID:/ {print $2}')

# attach proof while the work happens
$ motus work evidence "$LEASE_ID" test_result --passed 3 --failed 0

# inspect the active packet
$ motus work status "$LEASE_ID" --json

# if another actor needs to continue, handoff says:
# - objective
# - scope
# - required validation
# - expected receipt
# - failure route

# when accepted, the close record becomes the next starting point
$ motus work release "$LEASE_ID" success --json
# what the next actor trusts
handoff:
  objective: clarify first-run path
  scope: docs + build page only
  required_validation: smoke + website gates
  expected receipt: released close with accepted source state
  evidence_required: smoke transcript + gate report
  failure_route: stop and open follow-up CR if CLI must change

receipt:
  work_item_id: DOCS-ONBOARDING-001
  target_ref: refs/heads/main
  verified_source_state: refs/heads/main @ <accepted-commit-sha>
  evidence_run_hash: sha256:<evidence-bundle-hash>
  verified_by: ci@gate-public-surface
  verified_at: 2026-04-06T13:46:00Z
claim
one owner for the active attempt
evidence
proof is attached before anyone has to review or hand off
handoff
the next actor knows the target, scope, checks, and stop condition
receipt
later routing starts from accepted state instead of reconstruction
stays local
scratch notes and rough experiments help you, but they do not become packet truth
moves forward
handoff and receipt are the durable surfaces the next actor should trust
CLOSE AND INSPECT

See the actual close surface.

Day 1 starts with a small local close response. Governed workflows add richer receipts that bind source state, evidence hashes, and verifier identity. Start with the small loop, then add the heavier receipt when another actor or promotion step needs the result.

verify

I need proof I can point to. For myself, first.

# day-1 JSON surfaces
$ motus work claim ADHOC-DAY1-001 --intent "Day1 smoke" --json
{
  "decision": "GRANTED",
  "reason_code": "GRANTED_OK",
  "lease_id": "lease-20260403-360e8b5e",
  "message": "Access granted."
}

$ motus work status "$LEASE_ID" --json
{
  "lease_id": "lease-20260403-360e8b5e",
  "lease_status": "active",
  "outcomes": [],
  "evidence": [
    {
      "evidence_id": "evidence-20260403-61fb7d8e",
      "evidence_type": "test_result",
      "test_results": {"passed": 1, "failed": 0, "skipped": 0}
    }
  ],
  "decisions": []
}

$ motus work release "$LEASE_ID" success --json
{
  "decision": "GRANTED",
  "reason_code": "RELEASED_OK",
  "message": "Lease released successfully.",
  "lease_status": "released"
}
# governed receipt shape
{
  "version": "0.1.0",
  "work_item_id": "CR-MOTUS-ONBOARDING-ALIGN-1",
  "to_state": "released",
  "target_ref": "refs/heads/main",
  "verified_source_state": {
    "vcs": "git",
    "commit_sha": "<accepted-commit-sha>",
    "dirty": false
  },
  "evidence_run_id": "run-20260406-onboarding-align",
  "evidence_run_hash": "sha256:<evidence-bundle-hash>",
  "verified_by": "ci@gate-public-surface",
  "verified_at": "2026-04-06T13:46:00Z"
}

The example uses placeholders on purpose. A real receipt stores the accepted commit and evidence hash, but the shape matters more than a copied literal.

work item
which packet closed
target ref
where the accepted result belongs
source state
the exact commit or source surface the verifier accepted
evidence binding
the evidence run ID and hash that justified the close
verifier
who accepted it and when
WORK CONTRACTS

Define what must be true.

A work contract specifies scope, required checks, required evidence, and ownership before execution begins. The contract locks the decision so execution can move without reopening what was already settled.

why contracts

I need to define what done looks like before anyone starts.

scope
what paths can change, what files are in bounds
checks
what must pass: tests, lint, security scan, custom gates
evidence
what must exist: test results, coverage, screenshots, sign-off
ownership
who decides acceptance, who can release
# example work contract
work_id: TASK-042
scope:
  paths: ["src/auth/**", "tests/auth/**"]
checks:
  - pytest tests/auth
  - ruff check src/auth
evidence:
  - test_result: passed > 0, failed = 0
  - coverage: >= 80%
owner: @security-team
HANDOFF

Keep the handoff small and explicit.

The handoff is not a second contract. It is the execution envelope for the current actor or attempt. It says what the objective is, what is in scope, and what must pass. It also says what a valid close looks like and what to do if the work blocks.

You do not need this for every solo day-1 run. You add it when another person, CI job, or agent must continue the work without guessing.

A good handoff should let the next actor continue without opening a DM, a ticket thread, or your scratchpad. If they still have to guess, the handoff is too weak.

# starter handoff
Objective:
- align the onboarding surfaces so a zero-context operator can install Motus,
  run doctor, claim work, and close it with a receipt

In scope:
- packages/cli/docs/implementation/README.md
- site/build.html

Required validation:
- clean-home smoke: install -> init -> doctor -> claim -> evidence -> release
- python -m pytest packages/cli/tests/test_work_cmd.py
- bash scripts/run_gates.sh

Expected receipt:
- local day-1 close: JSON release response with decision=GRANTED and lease_status=released
- governed close: receipt with accepted source state, evidence bundle, verifier, and verification time

Evidence required:
- clean-home smoke transcript
- passing CLI test output
- website gate report

Failure route:
- if the docs require a CLI or schema change, stop and open a follow-up CR
# decorative handoff (too weak)
"Continue the onboarding docs and run the normal checks."

# useful handoff
"Align the onboarding docs and build page so a zero-context operator can run
install -> init -> doctor -> claim -> evidence -> release.
Only docs and website copy are in scope.
Run the clean-home smoke, pytest packages/cli/tests/test_work_cmd.py, and
bash scripts/run_gates.sh.
Successful close must include a released lease response, smoke transcript,
and website gate report.
If the docs require a CLI or schema change, stop and open a follow-up CR."
objective
the acceptance target for this attempt
scope
the exact surfaces allowed to change
validation
what the next actor must rerun before trust
expected receipt
what successful close must emit before the work can route forward
evidence
which artifacts must exist before anyone should trust the close
failure route
how to stop without widening the packet
GATES

Two options to start.

Gates are userland policy. You have two practical paths: use the built-in policy runner or create a custom script.

gates

I need checks that cannot be bypassed.

policy
motus policy run (fastest to start)
custom
repo gate script (recommended for team ownership)
# Option A: Motus policy gate
$ motus policy plan --repo . --files README.md --json
$ motus policy run --repo . --files README.md --json
# deterministic evidence bundle output
# Option B: Custom gate script
# scripts/gates/gate-001-no-todo.sh
#!/usr/bin/env bash
set -euo pipefail
if grep -RInE 'TODO|FIXME' . --exclude-dir=.git --exclude-dir=.motus --exclude='*.md' >/dev/null; then
  echo "FAIL: TODO/FIXME markers found in code."
  exit 1
fi
echo "PASS: no TODO/FIXME markers in code."
CI WIRING

Wire gates into your pipeline.

Gates run in CI like any other check. The verifier runs from a pinned reference so execution cannot modify the rules it is judged by.

ci

I need this wired into my existing pipeline, not a new system.

# .github/workflows/gate-001.yml
name: gate-001
on:
  pull_request:
    branches: [main]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run gate-001
        run: ./scripts/gates/gate-001-no-todo.sh
# commit your gate + workflow
$ git add scripts/gates/gate-001-no-todo.sh .github/workflows/gate-001.yml
$ git commit -m "gate: add no-todo gate and CI workflow"
GITHUB GOVERNANCE

Leverage GitHub correctly.

Motus complements GitHub governance. It does not replace it. Configure these controls in your repo settings.

github

I need Motus to work with what I already have, not replace it.

protect main
require PR, require checks, block force-push
require gates
make your gate workflows required status checks
code scanning
enable code scanning and secret scanning
CODEOWNERS
require approval from owners for sensitive paths
human approval
require human sign-off for high-impact merges
SECURITY MODEL

What Motus secures. What you secure.

Motus is open source and local-first. Local acceptance is authoritative. You own security and controls. Motus gives workflow discipline and evidence structure. It is not a security appliance.

security

I need to know what is my job and what is Motus's job.

motus secures
acceptance boundary, pinned verification, receipts, provenance
you secure
IAM, credentials, endpoint hardening, network policy, secrets, branch protections, audit retention, incident response
threat model
Motus closes self-judging and self-attested compliance
not a runtime
Motus is not an execution sandbox, agent framework, or transport
ledger optional
Motus works without the Ledger; the Ledger only stamps receipts
NEXT

Open the implementation guide and run the loop.

The implementation guide takes the same path shown here and expands it into the exact command flow, examples, and next-step logic.