motusos 0.4.0

Local work-packet and event-ledger kernel with evidence, receipts, and adapter-friendly projections

Motus CLI

The Motus CLI is the reference local interface for the work-packet and event-ledger kernel. The local Store records durable run/event facts; work packets, evidence, decisions, and receipts are projections over those facts.

1. define or select a work item,
2. claim active ownership,
3. attach evidence while the work happens,
4. release with a terminal receipt,
5. inspect that receipt directly.

Install

pip install motusos
motus --help

First Local Loop

motus install
motus init --empty --path .
motus doctor
LEASE_ID=$(motus work claim ADHOC-QUICKSTART-001 --intent "First local work item" --json | python3 -c 'import json,sys; print(json.load(sys.stdin)["lease_id"])')
motus work evidence "$LEASE_ID" test_result --passed 1 --failed 0
motus work release "$LEASE_ID" success
motus work receipt "$LEASE_ID"

What this proves:

• the CLI is installed,
• the local workspace is initialized,
• a work item can be claimed,
• evidence can be attached,
• a terminal receipt can be emitted and inspected directly.

Light Path Vs Governed Path

Use the light path for routine bounded work:

motus work claim ...
motus work evidence ...
motus work release ...
motus work receipt ...

Use the governed packet path only when the consequence of the work justifies the extra structure, for example:

• a release decision needs explicit scope, review, and closeout,
• another actor must inherit the proof and acceptance boundary,
• the work needs a stricter final receipt than the light loop provides.

Reference Release Workflow

Motus also includes a bounded compiled release workflow surface for consequential release work:

motus release scaffold --release-id 0.4.0
motus release sync --release-id 0.4.0
motus release validate --release-id 0.4.0
motus release finalize --release-id 0.4.0

When running from the source tree instead of an installed CLI, bind to the repo package explicitly:

PYTHONPATH=src python3 -m motus.cli release scaffold --release-id 0.4.0
PYTHONPATH=src python3 -m motus.cli release sync --release-id 0.4.0
PYTHONPATH=src python3 -m motus.cli release validate --release-id 0.4.0
PYTHONPATH=src python3 -m motus.cli release finalize --release-id 0.4.0

That workflow forms the release as explicit work:

• one authored release-source.json,
• one generated workflow manifest,
• six generated stage packets,
• one generated receipt template,
• one generated metrics template,
• one strict final-receipt.json.

Workspace layout:

.motus/releases/{release-id}/
  release-source.json
  generated/
    workflow.json
    packets/*.json
    receipt-template.json
    metrics-template.json
  final-receipt.json

Rules:

• release_id must be a slug using only letters, digits, ., _, or -.
• release-source.json is the only authored release-instance surface.
• generated outputs are disposable and are rebuilt by sync.
• validate is no-write and fails closed on drift.
• finalize emits one immutable final receipt.

It is a reference workflow surface, not a hidden orchestration engine. The packets route to capability classes and keep runtime-brand decisions behind the adapter boundary.

Read Next

• Operator Guide
• First Real Workflow
• Evidence and Receipts
• Using the Work Ledger
• Release Workflow Tutorial
• Release Workflow Reference
• Architecture
• Specification Status
• CLI Reference
• Docs Index