Skip to content

Quick Start

This walks through the full mission lifecycle against the deterministic mock adapter: register a project, create a mission, run it, inspect findings and synthesis, resolve a human decision, and read the audit trail. Every command and every output shown below was executed against the real CLI in a throwaway temporary directory before publishing this page.

1. Set up a project to govern

Any Git repository can be a managed project. This example uses a fresh one:

mkdir demo-project && cd demo-project
git init
git add . && git commit --allow-empty -m "init"

2. Initialize Assync in it

assync init .

Success: Initialized Assync at /path/to/demo-project/.assync

This scaffolds .assync/ (manifest, rules, boot protocol, handoff templates) — the marker Assync's CLI looks for, walking upward from the current directory, before it will run mission commands.

3. Register the project

assync project register --name "My Project" --repository-path "$(pwd)"

Registered: project_my_project -> /path/to/demo-project

4. Inspect the role pool

assync role list

Prints all 27 built-in executable roles (plus the non-executable Human Governance Authority) with category, risk level, and executability — see Built-in Roles for the full table.

5. Create a mission

assync mission create --project-id project_my_project \
  --title "Add rate limiting to the API" \
  --objective "Add a basic rate limiter to the public API and cover it with tests" \
  --required-role lead_programmer --required-role qa_engineer \
  --acceptance-criterion "tests pass"

Created: mission_20260728t194346_8e047ff4 (state=READY)

The default risk level is medium, which adds technical_reviewer to the selected roles automatically — see the workflow section of Mission Orchestrator. Every selected role needs an adapter entry in the run config below, including roles the orchestrator added on its own.

6. Configure adapters and start the mission

run_config.json
{
  "lead_programmer": {"adapter": "mock", "scenario": "approval"},
  "qa_engineer": {"adapter": "mock", "scenario": "blocking_security_finding"},
  "technical_reviewer": {"adapter": "mock", "scenario": "non_blocking_finding"}
}

assync mission start mission_20260728t194346_8e047ff4 \
  --run-config run_config.json --actor you

Mission mission_20260728t194346_8e047ff4 -> WAITING_FOR_AUTHORIZATION
Overall recommendation: BLOCK
Decisions requiring human review: ['decision_20260728t194413_038cd757']

The qa_engineer role's mock run reports a blocking high-severity security finding, so the deterministic synthesis engine recommends BLOCK and the mission moves to WAITING_FOR_AUTHORIZATION instead of COMPLETED — see Synthesis Engine.

7. Inspect findings and synthesis

assync finding list --mission-id mission_20260728t194346_8e047ff4

Lists both findings from this run: the blocking high/security finding from qa_engineer and a non-blocking low/quality finding from technical_reviewer.

assync synthesis show mission_20260728t194346_8e047ff4

Returns the full SynthesisResult: overall_recommendation: BLOCK, the conflicting role recommendations (lead_programmer=APPROVE, qa_engineer=BLOCK, technical_reviewer=APPROVE_WITH_CONDITIONS), the blocking finding, and recommended_next_authorization: DECISION_GO — synthesis never resolves this on its own.

8. Resolve the human decision

assync decision list --mission-id mission_20260728t194346_8e047ff4

Shows one PENDING decision: "One or more blocking findings remain open — accept, remediate, or reject before this mission can proceed."

assync decision approve decision_20260728t194413_038cd757 \
  --actor you --rationale "Accepted risk; will remediate in a follow-up mission."

decision_20260728t194413_038cd757 -> APPROVED

Approving a decision does not, by itself, complete the mission

This MVP has no automatic mission-state re-evaluation after a decision resolves — the mission stays in WAITING_FOR_AUTHORIZATION until a separate mission-level action is taken. See Decision Queue — MVP Limitations. assync mission abort <id> --reason ... --actor ... is the only other mission-level transition exposed by the CLI today.

9. Read the audit trail

assync audit show --mission-id mission_20260728t194346_8e047ff4

Prints the complete, append-only sequence for this mission: mission created → state transition READY → ACTIVE → each role's run completing → each finding created → the decision created → the state transition ACTIVE → WAITING_FOR_AUTHORIZATION → the decision resolved APPROVED with its recorded rationale. Nothing in this log is ever edited after the fact — see the atomicity section of Runtime Storage.

Where to go next