One Soot. One job. Clear evidence.

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.

01 · Pick an outcome before installing

Our running example: Marketing drafts three product posts from brand-guide, without publication. Acceptance means three on-brand drafts, each with source URI/ID/revision, no invented features and no publication effect. For a first practice run, use the clearly labeled TEST brand-guide fixture. For real work, use an owner-approved source; a model answer is not brand policy.

Choose an approved source. For Data Pool, record its source URI, document ID and current revision returned by the service. For a file or Skill, record the actual filepath plus a reviewed Git commit, content hash or version; do not invent pool metadata. Start with read access to that source. Drafting does not require full-host shell access, social-media credentials or write access to brand-guide.

02 · Check the actual installation path

Open Get Soot. Use only an installer the current manifest actually supplies for your platform, checking its version and digest/receipt. Preview installers are unsigned; Mac builds are not notarized. If it is unavailable, ask the distributor for the artifact or use a source build if you have repository and private dependency access. There is no guaranteed universal installation command for every machine. Check that the installed preview version supports Soot creation and the advanced validation/saving/activation/testing workflow described below, plus the selected Data Pool capabilities; an available installer does not guarantee compatibility with every chapter.

Once the executable is available on PATH:

soot version --json
soot spawn my-soot
cd my-soot
soot check --show --secrets

spawn my-soot creates a general workspace and starts a managed background runtime on its own loopback port. The general preset includes write and host-shell grants; it is not zero-access or read-only. For a read-only first task, have the operator remove unnecessary grants or start with --empty. Inspect effective configuration with check --show and narrow it to this job. General selects browser-use; soot-nest is installed but not granted to the project. Missing Pack/dependency acquisition is a prerequisite to fix, not a reason to bypass validation.

For a blank Soot, replace spawn with soot spawn my-soot --empty; do not run both against the same target. --no-start creates files only. check validates and, with --secrets, checks credential availability; it does not execute tools or call a model, and does not print secret values. Do not paste private configuration into chat.

03 · Keep three initialization paths distinct

The product target must be new. Explicitly start its runtime using the maintained CLI, then implement backend authentication using product integration. Do not mix general and product commands just because both use Soot.

04 · Prepare a provider without exposing credentials

Inspect the actual provider/model policy available on your host. For OAuth, soot login <provider> uses a real supported/configured provider ID; consult soot login --help and Models, not a copied placeholder ID. A headless --no-browser flow runs on the runtime host; hosted Nest cannot make a remote VM's loopback callback local to your laptop.

Provider keys/OAuth vaults serve model calls. Operator keys connect Nest. Tool credentials bind to permitted operations. These are not interchangeable. Give the agent only operator-managed private file/store references; never paste values into chat, URLs, command argv or source. Soot does not automatically load .env.

Without a real provider you can still validate and run demo/scripted checks, but label real AI verification unverified. Readiness, a healthy image and a scripted answer cannot replace this step.

05 · Define the profile and compose only what you need

Soul describes stable working behavior; mission defines responsibility and boundaries. A Skill is reusable knowledge or an SOP to read when relevant. A tool performs an operation. A Pack groups capabilities containing skills/tools; the host chooses explicit selectors and credential bindings. Source content cannot expand authority.

Marketing mission:
Draft communications from the operator-selected brand-guide.
Read only granted sources. Cite Data Pool URI/ID/current revision, or actual filepath + reviewed commit/hash/version.
Do not publish, modify brand-guide or invent missing claims.
Stop and report missing sources or permissions; never request secret values.
Acceptance: three drafts + citations + uncertainties + no publish effect.

If you need Data Pool, prepare its service and scopes separately; the Pack does not include a running Meilisearch service or company data. With a file/Skill, use the host-permitted read path and record its actual filepath plus reviewed Git commit/hash/version, not invented pool fields. Data Pool is not required for your first real Test.

06 · Create Marketing in Nest, then activate

soot nest

Open the Nest installation you prepared; select the intended runtime and inspect its endpoint, authenticated identity and operator scope. Browser Nest needs trusted HTTPS with an exact allowed origin, or a fixed loopback same-origin proxy. Do not substitute a backend/product or provider key for an operator key. The Nest operator browser keeps its operator key in page memory only; refresh requires reauthentication. Native Nest uses its private connection store. Trusted product/backend runtime keys belong on the backend, never in a public product frontend or bundle. soot nest does not publish a hosted web app.

The creation wizard uses Soots → Tạo Soot → Vai trò → Chọn Pack → Xem lại (create → role → choose Pack → review):

1. Open Tạo Soot. In Vai trò, name it Marketing and enter the mission above. Start blank/minimum-scope where appropriate.
2. In Chọn Pack, explicitly select only the source-reading capability from the installed, reviewed Pack. For Data Pool, the host must also bind Marketing's own read operation credential and grant read on the test pool.
3. In Xem lại, review the selected capabilities and effective scopes, then select the final Tạo Soot (or Lưu Soot when editing). The host checks the configuration before saving; the wizard has no separate Validate or Activate button.
4. Select Marketing and open Nâng cao (advanced). This separate view offers Kiểm tra (validate without saving) and Lưu bản nháp (save); if changing a draft there, validate the same candidate you intend to save. Inspect the shared saved/active acknowledgement. Use Áp dụng (apply) when offered and permitted by the current host/build, then wait for its acknowledged active revision; some hosts apply managed changes after active runs finish.
5. Only after that acknowledgement, open Thử cấu hình đang chạy and select Chạy thử (Test) for Marketing, not the general workspace Soot.

The running fixture's Soot ID is marketing. A display name is not an ID: inspect the host-reported ID and substitute your actual ID in CLI commands. General spawn does not create Marketing automatically. Saving does not call a model or commit Git, and Save alone does not prove active. Test stays guarded while saved differs from active or activation is pending; pending/restart-required/rejected is not an active acknowledgement. Test creates a fresh conversation pinned to the acknowledged active revision; admitted runs keep their earlier revision.

Conflicts retain the draft. Read the new revision and explicitly rebase, rather than repeatedly submitting the save action. Selecting a management runtime does not move old chats. Settings owns configuration/providers/connections; Data Pool owns data management.

07 · Run a real read-only task

In the permitted Test or a new conversation assigned to the intended Soot, send this brief after replacing the revision placeholder with the current revision returned when you save the test fixture:

Objective: draft 3 product posts, each 120–180 words.
Source: urn:example:brand-guide, document brand-guide, revision [current service revision].
This is TEST DATA for fictional Pebble Studio, not Soot product policy.
Allowed: read granted sources and draft in the answer.
Prohibited: publish, modify sources, run shell or add permissions.
Output: 3 drafts; source URI/ID/revision on each;
list unsupported claims and observed tool effects.
Acceptance: guide-consistent voice, no invented features, no external writes.
Stop and ask the operator if the source is inaccessible or conflicting.

The CLI can also submit a focused task through the selected runtime:

soot run --soot marketing "Read the granted TEST brand-guide (urn:example:brand-guide, ID brand-guide). Report its current revision, test brand voice and support window. Do not modify or publish."

run is an API client, not a second model loop or store. This command selects the fixture actually created with ID marketing; verify the host-reported ID and intended connection first. --soot cannot create a Soot or grant it access. When the host advertises groups.auto.v1 and the Soot has automatic_groups: true, the current CLI automatically requests group_id: auto; choose one Soot, not a required group picker. The same automatic conversation can handle work in A, then B, then A. Existing pinned chats and app/client pins stay fixed; omitting group_id on the legacy API retains the old/default resolution. See automatic scoped delegation. For a file/Skill instead, adapt the brief to its real filepath and reviewed commit/hash/version.

08 · Verify success and denial

Check citations against the source, inspect tool history/effects, provider/model, run state and config revision. “Done” is not evidence an operation occurred. Follow the fixture verification and safe denial procedure. In that authorized fixture, Marketing write must be DENIED and Support read must be DENIED despite a selected read capability and its own read credential; Support has no pool grant. Do not test destructive writes on production documents. Revoke access and prove read denial. A UI actor label is not authentication.

In Overview, distinguish queue time from execution time. Tokens and known cost estimates cover observed usage; null cost is unknown, not free. Fresh run detail can appear before numeric totals based on closed UTC-hour buckets.

09 · Operate daily before renting a VM

Keep one conversation for one objective; start a new one for a new objective/assignment. Turn repeated SOPs into Skills and keep reusable sources in Data Pool instead of repeating giant prompts. Compare model/effort choices within small budgets using quality and known usage, not the largest model by default.

Stop fences new effects and late publication; it does not undo completed actions. If a POST/effect loses its response, retain original request/run/receipt IDs and inspect/watch/GET the outcome. Do not create a new request to blindly try again.

Your local path now has evidence. Continue with operation; optional 2server starts only after local verification and operator review of infrastructure, costs, persistence, authentication and backup.