02 / Initialization
The INITIALIZATION session
Design a Soot you can explain and test. The goal is not a larger toolbox; it is a clear responsibility with a verifiable execution path.
01 · Agree a work contract
Write the outcome, authoritative sources, minimum read scopes, output format, acceptance and ask/stop criteria before choosing a Pack. “Help with marketing” is too broad; “three drafts from an approved brand-guide revision, no publication” can be checked.
Before creating an agent, propose a mission for exactly one outcome.
List required sources and minimum read scopes.
State prohibited effects, acceptance criteria and stop conditions.
Reuse existing configuration if it already fits; do not duplicate blindly.
Do not expand grants or provision infrastructure before operator review.02 · Choose the right workspace
General: soot spawn my-soot, then cd my-soot. Its preset already has permissions; inspect and narrow them. Blank: replace general spawn with --empty. File-only: add --no-start. Product: soot spawn --product my-product creates support with empty grants and scripted AI, without starting. Nest: soot nest is the operator workspace, not an agent or cloud service.
Source and durable state have separate roles. Only one runtime process opens a store. Never clone a running runtime against the same state to “try quickly,” or delete history/checkpoints/receipts to force model migration.
03 · Assign ownership correctly
| Component | The question it answers | Owner |
|---|---|---|
| Soul | How should it work consistently? | Soot definition |
| Mission | What job and boundaries? | Soot definition |
| Skill | Which SOP/knowledge to read? | Pack capability |
| Tool | Which operation can execute? | Capability + host binding |
| Provider/vault/policy | Models, secrets and limits? | Runtime host |
| Conversation/run/state | Objective, execution and receipts? | Durable runtime store |
Packs do not own identity, schedules, routes or credentials. interface.tool_area is presentation for already-granted tools. Installation does not select capabilities or start ingress/backends. Host shell runs with host OS access; a workspace is not a sandbox.
04 · Validate → save → activate → verify
These are lifecycle concepts, not four creation-wizard buttons. Create through Soots → Tạo Soot → Vai trò → Chọn Pack → Xem lại: enter the name/mission, select minimum capabilities and review the scopes. Finish with Tạo Soot (or Lưu Soot when editing); the host checks the configuration before saving. Inspect the host-reported ID rather than inferring it from the display name.
soot version --json
soot check --show --secretsCheck does not call a model. Separately, the Soot's Nâng cao (advanced) view exposes host-supported editable fields and actions: Kiểm tra validates without saving; Lưu bản nháp saves the draft. Validate the same candidate you intend to save. Both paths share the host's saved/active acknowledgement; Save alone does not prove active. Inspect those revisions and use Áp dụng when offered and permitted by the current host/build; explicit application checks saved and expected active revisions. Some hosts apply managed changes after active runs finish. Await the host's acknowledged active revision before a read-only Chạy thử (Test) under Thử cấu hình đang chạy. Test stays guarded during pending activation or saved/active mismatch; pending/restart-required/rejected is not an active acknowledgement. Test uses a fresh conversation pinned to that revision.
Conflict: retain draft → read current source/revision → review differences → explicitly rebase → deliberately submit. Uncertain save: fence writes and GET the original transaction receipt, never automatically replay POST. Admitted runs keep their accepted revision.
05 · Your initialization evidence
- Verified version, workspace and intended runtime identity.
- One mission and a Data Pool source URI/ID/current revision, or actual file/Skill filepath plus reviewed Git commit/hash/version.
- Minimum effective scopes, provider availability and operation credential bindings.
- Saved matches active; Test pins that revision.
- One real permitted model run, correct citations and a denied-scope check.
See quick-start prerequisites for installer/version/source-access requirements. Missing provider: operator setup using Models. Missing Pack/service: prepare dependencies, review source/manifest and explicitly grant. Missing backend: follow product integration, keep trusted product/backend runtime keys out of public product frontend code. Nest operator browser keys stay in page memory only; native Nest uses its private store. Each missing prerequisite is a concrete blocker, not permission to invent completion.
Content reviewed: 2026-10-09