Public documentation v0.1.0
Conditional disposable profile validation
When to use disposable test profiles, and when static reviewer checks are sufficient.
Default path: static review
Use reviewer/static inspection by default for low-risk docs-only, comment-only, typo, or wording changes that do not change role behavior. Static review is also sufficient when a reviewer can verify the result from source and generated artifacts alone. A human may still explicitly request disposable validation; when requested, treat it as required for that change.
Required path: behavior-risk validation
Use disposable validation when a change affects behavior or operating boundaries, including SOUL or profile behavior changes, behavior-changing skills, Kanban protocol or task-routing changes, profile install/delete/config/model/provider guidance, role authority changes, credential or environment-variable loading behavior, remote-sprite or runtime-adjacent workflows, or areas that previously failed after rollout.
Required validation chain
For required disposable validation, PM creates a focused chain: source-control the guidance change, run a source reviewer gate, install randomly suffixed disposable profiles from the reviewed candidates, run focused acceptance checks with non-secret evidence, allow at most two remediation iterations, require a reviewer/evidence gate, publish and install only after green gates, then prune the disposable profiles unless a human records retention.
Performance guardrail
Disposable validation has real cost: install/setup, isolated task execution, evidence review, cleanup, and possible remediation loops. Run it for behavior risk or explicit human request; keep low-risk static-sufficient changes lightweight and document the static-review decision. Reviewers should reject both skipping PM-required validation and over-applying disposable validation to every small docs/comment/typo change.
Public-safe lessons
Validate command shape before mutating profiles, preserve evidence before cleanup, keep cleanup or explicit retention in the chain, and publish concepts rather than internals. Public docs may describe the workflow and summarized validation outcomes; they must not expose raw task logs, local workspaces, private profile state, credentials, private environment files, or private runtime URLs.