coulomb/sand-boxer
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Bernd Worsch
2026-06-23 21:23:39 +02:00
parent 45029ec66f
commit 9054d33e46
1 changed files with 52 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
INTENT.md
View File

@@ -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