Clarify INTENT.md: sand-boxer self-sufficiency and sibling boundaries

Document that sand-boxer is self-sustained without wise-validator, that
validation is an optional downstream consumer, and update near-term outcomes
to reflect completed SAND-WP-0002 work.

INTENT.md

@@ -1,7 +1,7 @@
 ---
 domain: infotech
 repo: sand-boxer
-updated: "2026-06-22"
+updated: "2026-06-23"
 ---
 
 # INTENT
@@ -68,6 +68,30 @@ hosting on Railiance01.
 
 ---
 
+## Self-sufficiency
+
+sand-boxer is **self-sustained**. It ships a complete establishment surface —
+profiles, extensions, CLI, lifecycle registration, and host telemetry (canary
+self-deploy) — without depending on wise-validator or any other sibling project.
+
+| sand-boxer does | sand-boxer does not require |
+|-----------------|----------------------------|
+| Provision and teardown sandboxes | wise-validator to exist or run |
+| Prove reachability (`ready`) | Repo `e2e/e2e.yml` or test contracts |
+| Emit sandbox lifecycle to State Hub | Validation pass/fail from another service |
+| Dogfood via `profile.sandbox-canary` | Cross-repo use-case orchestration |
+
+**wise-validator is an optional downstream consumer**, not a co-requisite. If
+wise-validator were never built, sand-boxer would still provision agent dev
+environments, compose stacks, and operator smoke paths. Conversely, wise-validator
+**depends on** sand-boxer (or a compatible establishment API) for environments —
+never the reverse.
+
+Other peers (glas-harness, snuggle-inventor, activity-core, CI) are equally
+optional consumers of the same API.
+
+---
+
 ## The OpenRouter analogy
 
 | OpenRouter | sand-boxer |
@@ -105,17 +129,27 @@ glas-harness configures *when* tools run in a sandbox (OpenClaw-style
 `mode` / `scope` / `workspaceAccess`). sand-boxer provides the sandbox handle
 and reachability descriptor.
 
-### wise-validator — e2e test and health
+### wise-validator — cross-repo use-case validation (optional consumer)
 
-**Owns:** Validation workflows, health check semantics, test orchestration,
+**wise-validator owns:** Use-case validation orchestration across the Coulomb
-pass/fail interpretation, structured result reporting to State Hub and CI.
+ecosystem — health check semantics, test execution, pass/fail interpretation,
+structured validation results to State Hub and CI. It stabilizes **use cases that
+may not run daily** by detecting silent degeneration (dependency drift, host
+changes, cross-repo breakage) before someone depends on a stale path again.
 
-**Does not own:** Remote host provisioning, compose lifecycle, port isolation,
+**sand-boxer does not own:** Any of the above. sand-boxer does not parse
-sandbox teardown.
+`e2e/e2e.yml`, poll HTTP health endpoints, run `test_command`, or emit validation
+pass/fail. That boundary is intentional so establishment stays independent of
+validation.
 
-wise-validator replaces the validation half of `the-custodian/e2e-framework/`.
+**Relationship:** wise-validator is a **separate project** that may call sand-boxer
-It requests `profile.compose-e2e` (or successors), runs tests inside the
+to obtain environments (`profile.compose-e2e`, etc.), then runs the validation
-established environment, and owns the `e2e.yml` contract.
+story inside them. sand-boxer establishes the box; wise-validator proves use cases
+still work. sand-boxer neither waits for nor requires wise-validator.
+
+Lineage: wise-validator replaces the **validation half** of
+`the-custodian/e2e-framework/`; sand-boxer already owns the provision/teardown
+half (`ext.compose-ssh`).
 
 ### snuggle-inventor — code generation
 
@@ -316,13 +350,14 @@ follows evidence.
 
 ## Near-term outcomes
 
-1. **Charter and research** — `INTENT.md`, `research/`, profile schema draft
+1. ~~**Charter and research**~~ — done (`INTENT.md`, `research/`, meta-framework spec)
-2. **First self-hosted extension** — `ext.compose-ssh` from e2e-framework lineage
+2. ~~**First self-hosted extension**~~ — done (`ext.compose-ssh`, SAND-WP-0002)
-3. **Unified API v0** — create / get / destroy / recreate + State Hub registration
+3. ~~**Unified API v0**~~ — done (CLI + HTTP stub, State Hub lifecycle)
-4. **First profile** — `profile.compose-e2e` for wise-validator migration
+4. ~~**Profile catalog start**~~ — `profile.compose-e2e`, `profile.sandbox-canary`
-5. **Registry entry** — `capability.execution.sandbox-provision` via reuse-surface
+5. ~~**Registry entry**~~ — `capability.execution.sandbox-provision`
-6. **Extension SDK sketch** — contract for P1 backends (vm-packer, Daytona OSS)
+6. ~~**Sibling integration notes**~~ — `docs/integrations/`
-7. **Sibling integration notes** — glas-harness, wise-validator, snuggle-inventor API expectations documented
+7. **Extension SDK sketch** — contract for P1 backends (vm-packer, Daytona OSS)
+8. **wise-validator** — separate repo/workplan (SAND-WP-0003); not a sand-boxer dependency
 
 ---
 
@@ -331,7 +366,7 @@ follows evidence.
 A mature sand-boxer is Coulomb's **default way to establish any sandbox**:
 
 - glas-harness requests agent dev sandboxes without choosing Docker vs Modal vs SSH
-- wise-validator requests validation environments without owning provisioners
+- wise-validator *may* request validation environments; sand-boxer does not depend on it
 - snuggle-inventor requests build sandboxes with setup metadata and secret refs
 - activity-core and CI request bounded venues with consistent lifecycle visibility
 - Operators route spend across self-hosted and SaaS with one credits model