From 9054d33e46b3a046270c95c0ccdda695f29d733e Mon Sep 17 00:00:00 2001 From: tegwick Date: Tue, 23 Jun 2026 21:23:39 +0200 Subject: [PATCH] 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 | 69 +++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 52 insertions(+), 17 deletions(-) diff --git a/INTENT.md b/INTENT.md index d665aad..c6c43b4 100644 --- a/INTENT.md +++ b/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, -pass/fail interpretation, structured result reporting to State Hub and CI. +**wise-validator owns:** Use-case validation orchestration across the Coulomb +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, -sandbox teardown. +**sand-boxer does not own:** Any of the above. sand-boxer does not parse +`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/`. -It requests `profile.compose-e2e` (or successors), runs tests inside the -established environment, and owns the `e2e.yml` contract. +**Relationship:** wise-validator is a **separate project** that may call sand-boxer +to obtain environments (`profile.compose-e2e`, etc.), then runs the validation +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 -2. **First self-hosted extension** — `ext.compose-ssh` from e2e-framework lineage -3. **Unified API v0** — create / get / destroy / recreate + State Hub registration -4. **First profile** — `profile.compose-e2e` for wise-validator migration -5. **Registry entry** — `capability.execution.sandbox-provision` via reuse-surface -6. **Extension SDK sketch** — contract for P1 backends (vm-packer, Daytona OSS) -7. **Sibling integration notes** — glas-harness, wise-validator, snuggle-inventor API expectations documented +1. ~~**Charter and research**~~ — done (`INTENT.md`, `research/`, meta-framework spec) +2. ~~**First self-hosted extension**~~ — done (`ext.compose-ssh`, SAND-WP-0002) +3. ~~**Unified API v0**~~ — done (CLI + HTTP stub, State Hub lifecycle) +4. ~~**Profile catalog start**~~ — `profile.compose-e2e`, `profile.sandbox-canary` +5. ~~**Registry entry**~~ — `capability.execution.sandbox-provision` +6. ~~**Sibling integration notes**~~ — `docs/integrations/` +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