Quickstart

The shortest path from zero to a working Syncropel loop. Eight commands. About five minutes.

Prefer hosted? Skip install entirely — sign up at syncropel.com/sign-up and follow Hosted instance signup. Same protocol, same CLI, no machine to maintain.

In a hurry — just the commands

# 1. Install
curl -sSf https://get.syncropic.com/spl | sh           # Linux / macOS / WSL — Windows: irm https://get.syncropic.com/spl.ps1 | iex

# 2. Initialize
spl init

# 3. Start the instance
spl serve

# 4. Add → start → complete → approve a task
spl task add "Read the Syncropel quickstart" --priority high --domain meta
spl task start TASK-0001
spl task done TASK-0001 --summary "Read it. Set up local Syncropel." --domain meta
SPL_ACTOR=did:sync:agent:reviewer spl task approve TASK-0001 --domain meta --notes "Quickstart complete"

# 5. See your first trust evidence
spl trust

If those eight commands ran clean, you're done. The rest of this page explains what each step did and where to go next.

What just happened

You produced four immutable, content-addressed records on a thread, accumulated trust evidence in the meta domain (where Syncropel groups infrastructure/process/onboarding work), and proved the loop works. Every other Syncropel feature — federation, AI agent dispatch, CEL automation, namespaces — composes on top of this primitive.

spl thread records TASK-0001 shows all four; spl trust shows the evidence the verdict produced.

Why a separate actor for approve?

Syncropel's trust model gates self-evaluation: a record's evaluator must be a different actor than its emitter. The SPL_ACTOR=did:sync:agent:reviewer shown above is just an example evaluator actor — any DID different from the emitter works. For solo work, a dedicated reviewer actor is the canonical evaluator; for team work, real reviewers approve their teammates' work.

The trust function wilson_lb(success, total) rejects evaluations where executor == evaluator with the CUSUM detector. Trying to self-approve raises an explicit error message; the env-var workaround above is the documented single-user pattern.

Common pitfalls

spl serve says ready, but spl status shows nothing. The instance may have failed to bind port 9100. Check ~/.syncro/logs/spl.log — most common cause is a previous instance still bound. Use pgrep -af "spl serve" and kill <pid> to clean up, then retry.

spl task done complains about uncommitted git changes. The task-completion gate refuses to attribute completion when the working tree is dirty (so wrong commits don't get tied to the wrong task). Either git commit first, or pass --force if the changes are unrelated.

spl stop says "not running" but an instance clearly is. The PID file got orphaned (rare but real). Use pgrep -af "spl serve" then kill <pid> directly. See Operator Runbook → orphan PID recovery for the full procedure.

What to do next

You now have a running instance, a completed task, a trust score, and an understanding of records → threads → trust. The natural next paths:

• Tutorials — guided 15-30-minute walkthroughs (first task, first thread, first workspace)
• Concepts — why records are 8 fields, how the dial scales from REPLAY to CREATE, what trust really measures
• Guides — task management, search, namespaces, debugging, SDKs, backup-restore
• Operator runbook — backup discipline, recovery, in-place upgrades when this becomes real work
• FAQ — common questions about vocabulary, hosted vs self-hosted, federation, troubleshooting

Or jump back to the docs home and pick by what you actually want to build.