Work with one small Soot

Read https://trysoot.com/docs/quick-start/index.md and its relevant references. First inspect the user's existing Soot installation, version, workspace/config and your permissions; do not overwrite configuration. If an installer, provider, Pack or backend is missing, identify the exact prerequisite and how an operator can prepare it. Agree ONE measurable outcome; create ONE focused Soot with a clear mission, acceptance criteria and minimum scopes, starting read-only. Validate → save → activate → verify the active revision; connect Nest to the intended runtime. Run a real permitted Test using a real provider, report Data Pool source URI/ID/current revision, or file/Skill filepath plus reviewed Git commit/hash/version, tool effects, run/config revision, outcome and a denied-scope check; demo/scripted is not AI verification. Refer to credentials only by operator-managed private file/store paths, never values in chat or argv. Do not provision infrastructure, extend grants or publish. For optional deployment, present source/image, state, secret references, costs and a backup/rollback plan for review before infrastructure effects. Reconcile uncertain outcomes with the original receipt/request/run IDs, never blindly resubmit.

One path, two sessions

INITIALIZATION turns an intention into one Soot with a mission, sources and explicit permissions. OPERATION turns runs into visible, repeatable work you can review and improve. You do not need a swarm or a VM to start.

1. Quick start: intention to a real Test — the continuous end-to-end walkthrough.
2. Initialization — workspace choice, mission, validation and activation.
3. Operation — task briefs, Nest and evidence review.
4. Data Pool — shared sources, separate permissions.
5. Automatic collaboration — one conversation, permitted specialists and reusable group templates.
6. Optional deployment — after local verification.
7. Reference & troubleshooting — terms, symptoms and maintained sources.

Small responsibility, clear ownership

A Soot owns one focused responsibility. The runtime host owns policy, providers/models, vaults, limits, tool bindings and durable state. Nest is the operator workspace for conversations, management and observation. Soot Forge distributes Packs composing Skills and tools; a Pack name is not permission to execute.

You → Nest / CLI → Soot runtime
Soot runtime → Model call → Host-selected provider
Soot runtime → Selected Skill + granted tool → Source / Data Pool
Host owns policy, tool bindings, provider keys and durable conversations.

This is an illustrative responsibility diagram, not a product screenshot or proof that services are installed. Installing ≠ granting ≠ backend start. A workspace and host shell are not an OS sandbox.

What will you finish with?

One Soot reads an approved source, produces cited drafts, passes a real-model Test and is denied outside its scope. You know which active revision produced the result and which prerequisites still need an operator. That is stronger evidence than a healthy container with no provider call.