sage-goad-reset

Files (27)

• SKILL.md
• openai.yaml · agents/
• _sage_relaunch.py · scripts/
• archive_runtime_dbs.py · scripts/
• bh_reset.py · scripts/
• check_cross_forest_laps_bridge.py · scripts/
• docker_request_meter.py · scripts/
• liveness.py · scripts/
• ludus.py · scripts/
• mcp_check.py · scripts/
• migrate_operation_memory.py · scripts/
• mythic_reset.sh · scripts/
• pkinit_padata_probe.py · scripts/
• range_profile.py · scripts/
• readiness_contract.py · scripts/
• reset_orchestrator.py · scripts/
• sage_deployment.py · scripts/
• sage_restart.sh · scripts/
• sage_stop.sh · scripts/
• sync_range_time.py · scripts/
• test_docker_request_meter.py · tests/
• test_ludus.py · tests/
• test_range_profile.py · tests/
• test_readiness_contract.py · tests/
• test_reset_orchestrator.py · tests/
• test_sage_deployment_parity.py · tests/
• test_sync_range_time.py · tests/

SKILL.md (first lines)

# Sage GOAD Reset

Use from the repository root. Sage runs locally in the `sage` tmux session for this workflow, not in a
Docker/Mythic Sage container. Mythic remains Docker-backed and is managed through `mythic-cli`. Do not delete
runtime databases or retained archives.

## Invocation

In Codex, use:

```text
$sage-goad-reset full reset
```

Treat `full reset`, `reset everything`, or an equivalent request as the entire workflow below, including Sage
chat verification, fresh Apollo creation, and Samwell callback establishment through `$sage-callback-bootstrap`. A Ludus-only rollback
must be requested explicitly as a range-only or GOAD-only reset.

For repeatable operator execution, use the resumable orchestrator. Previewing the plan is read-only:

```bash
.venv/bin/python skills/sage-goad-reset/scripts/reset_orchestrator.py plan --snapshot <exact-snapshot> --callback-host <mythic-callback-url>
```

Start the live reset only with explicit authorization:

```bash
.venv/bin/python skills/sage-goad-reset/scripts/reset_orchestrator.py start --snapshot <exact-snapshot> --callback-host <mythic-callback-url> --yes
```

The orchestrator composes the existing helpers in canonical order, writes an atomic redacted checkpoint under
`.sage_engagement/reset_runs/`, and pauses at `await-operator-foothold-launch`. It never deploys or launches the
payload itself. Checkpoint load and write validate the exact phase order, legal state progression, command
derivation, operator boundary, terminal state, and zero-task observation lineage; malformed or ambiguous state
fails closed before another phase can run. After the operator completes the documented interactive RDP launch:

```bash
.venv/bin/python skills/sage-goad-reset/scripts/reset_orchestrator.py resume --checkpoint <checkpoint.json> --operator-foothold-launched --yes
```

It establishes an observed Mythic task-count baseline immediately after Mythic reset and requires an exact zero
delta after bootstrap, operator payload launch, post-callback preflight, and final readiness. A nonzero delta
blocks completion.

The orchestrator defaults to `--no-prepare-chat`, leaving operation and chat creation to the operator. Pass
`--prepare-chat` only when the empty `Sage GOAD Ready` channel is wanted. The standalone `bootstrap-reset`
command retains its historical prepare-chat default.

## Range Source and Lifecycle

For reusable AD ranges intended for publication or transfer, keep the portable definition in DreadGOAD format and
use Ludus as the runtime/reset substrate. A Sage-only benchmark fixture may be Ludus-first in
`ludus/sage-purpose-ranges/` when portability is not a goal. This skill operates on runtime state; it does not
prove that a source definition is publishable or that a range is ready for evidence.

- If the range should be reusable outside Sage, author the portable source in DreadGOAD format and keep a verified
  Ludus execution path.
- If the range exists only as a Sage-specific benchmark fixture, prefer the standalone
  `ludus/sage-purpose-ranges/` pattern.
- In both cases, use Ludus state for reset/readiness claims and report source format separately from runtime state.

Use these state labels in updates: `defined`, `provisioned`, `snapshotted`, `callback-ready`, `countable`,
`burned`, and `complete`. Do not say a range is ready or deployed when only the source exists or provisioning has
started. After a burned attempt, stop-loss, or completed tranche, power down any range not needed for the next
operation before leaving the lab idle.

### Custom DreadGOAD Purpose-Range Workflow

For a custom DreadGOAD-format purpose range, keep source validation and runtime targeting separate:

- `dreadgoad config show` is not sufficient proof that the custom lab's playbook sequence is the one provisioning
  will resolve. Validate through the actual provision resolver with a deliberate sentinel such as
  `dreadgoad provision --from __not_a_playbook__` before the long run, then require the returned playbook list to
  be the intended custom sequence.
- DreadGOAD acts against the current Ludus default range for the API-key user. Before `dreadgoad infra apply` or
  `dreadgoad provision`, create the isolated Ludus range object for the purpose range, set it as that user's
  default, verify the selected range identity, and keep unrelated ranges powered off.
- DreadGOAD does not consume Sage's `.mcp.json` automatically. Pass the intended `LUDUS_URL` and `LUDUS_API_KEY`
  explicitly from the correct local credential source for every infra/provision command.
- For cross-forest ACL/bootstrap scripts, do not assume ambient `NTAccount.Translate()` or one forest's AD cmdlets
  can resolve a foreign principal. Validate the exact auth context before the long playbook; when needed, perform an
  explicit least-privileged SID lookup in the principal's home domain and apply the ACL locally with that SID.

## Order

Before step 1, select and retain the bootstrap mode from
`skills/sage-mythic-payload-deploy/SKILL.md`:

- A pre-staged Apollo snapshot plus imported retained callback metadata uses the interactive
  `launch_apollo_foothold.sh` → `launch-existing` path and performs no Mythic payload download.
- A clean baseline without staged Apollo uses a newly built, verified-downloadable Mythic payload and `deploy`.
- `sage-foothold-launch` is the batch-logon path only when the operation explicitly accepts that token type and
  the selected Mythic payload has real downloadable bytes.

Record the snapshot, payload source, token type, launcher, download expectation, settle window, and callback
uniqueness rule before live allocation. Retain bounded launcher output on failure. Do not infer bootstrap mode from
the caller being interactive or headless.

For the qualified Trust Walker retained foothold, use the complete immutable fixture named in
`skills/sage-mythic-payload-deploy/SKILL.md`. Validate its snapshot, config hash, payload UUID, task state,
executable path, and executable hash together before starting the task.

1. Stop local Sage before moving its databases:

```bash
/bin/bash skills/sage-goad-reset/scripts/sage_stop.sh
```

An absent `sage` tmux session is an idempotent already-stopped state. A present Sage process that survives the
bounded interrupt sequence remains a hard failure.

2. Archive the active databases. The helper moves them beside their originals as
   `sage_YYYYMMDD-HHMM.db` and `phoenix_YYYYMMDD-HHMM.db`. It never overwrites an existing archive:

```bash
.venv/bin/python skills/sage-goad-reset/scripts/archive_runtime_dbs.py
```

3. Reset and restart Mythic. This uses the Docker-backed Mythic CLI without `sudo`:

From MythicAgents/sage, GPL-3.0.

More from MythicAgents/sage