42 lines
1.2 KiB
Markdown
42 lines
1.2 KiB
Markdown
|
# activity-core integration
|
||
|
|
|
||
|
|
activity-core schedules bounded work on Railiance01. sand-boxer provides
|
||
|
|
**sandbox venues** with TTL enforcement; activity-core owns **when** expire runs.
|
||
|
|
|
||
|
|
## Scheduled TTL reap
|
||
|
|
|
||
|
|
Run periodically (cron, Temporal activity, or CI):
|
||
|
|
|
||
|
|
```bash
|
||
|
|
sandboxer expire --apply
|
||
|
|
```
|
||
|
|
|
||
|
|
HTTP equivalent:
|
||
|
|
|
||
|
|
```http
|
||
|
|
POST /v1/sandboxes/expire?apply=true
|
||
|
|
```
|
||
|
|
|
||
|
|
Returns a list of `ExpireActionResult` entries (`dry-run`, `destroyed`, `failed`).
|
||
|
|
|
||
|
|
## Lifecycle events
|
||
|
|
|
||
|
|
Each expired sandbox emits a State Hub progress event:
|
||
|
|
|
||
|
|
- `state`: `expired` (`event_type`: `milestone`)
|
||
|
|
- Followed by `destroying` → `destroyed`
|
||
|
|
|
||
|
|
Event `detail` includes `ttl`, `expires_at`, and reachability fields.
|
||
|
|
|
||
|
|
## What sand-boxer does not do
|
||
|
|
|
||
|
|
- No Temporal workflows or activity-core code in this repo
|
||
|
|
- No push webhook to activity-core on expiry (poll/schedule only in v0)
|
||
|
|
- TTL parsing and destroy orchestration live in sand-boxer
|
||
|
|
|
||
|
|
## Consumer pattern
|
||
|
|
|
||
|
|
1. activity-core activity provisions via `sandboxer create` (or HTTP)
|
||
|
|
2. Work runs in the sandbox (glas-harness, wise-validator, etc.)
|
||
|
|
3. Scheduled `sandboxer expire --apply` reaps past-TTL sandboxes
|
||
|
|
4. State Hub records full lifecycle for audit
|