Skip to content

AI Continuity

github-actions[bot] edited this page Aug 9, 2026 · 6 revisions

AI Continuity

XCSV uses an isolated continuity lane named XCSV_AI_CONTINUITY.

Runtime state root: D:\CAGE\xcsv-ai-continuity

Tracked operator entrypoint: D:\XCSV\tools\xcsv-continuity.ps1

Hermes profile: xcsvcontinuity

OpenClaw profile: xcsvcontinuity

The lane carries only the active baton: work item, authority, source/runtime state, evidence, unknowns, blockers, and one bounded next action. It must not store chat transcripts or previous-worker summaries as authority.

Commands

Create or update the current baton:

D:\XCSV\tools\xcsv-continuity.ps1 checkpoint

Show the current baton:

D:\XCSV\tools\xcsv-continuity.ps1 show

Hydrate a continuation summary:

D:\XCSV\tools\xcsv-continuity.ps1 hydrate

Show worker policy:

D:\XCSV\tools\xcsv-continuity.ps1 workers

Verify basic isolation:

D:\XCSV\tools\xcsv-continuity.ps1 verify-isolation

Run the simulated worker-exhaustion check:

D:\XCSV\tools\xcsv-continuity.ps1 failure-test

Isolation Rules

XCSV handoffs, logs, receipts, prompts, worker histories, routing state, and authority envelopes stay under D:\CAGE\xcsv-ai-continuity or tracked XCSV repo files.

Do not store XCSV baton state in Hermes default state, Hermes sovran-command-deck, OpenClaw default state, or any SOVRAN project directory.

Gauntlet Loop (XCSV AI workforce)

The Gauntlet Loop routes one bounded claim to a primary worker, then to critics drawn from different providers, and loops findings back for repair before any verdict is accepted.

ARCHITECT -> XCSV Work ID -> Hermes durable baton -> router (worker selection)
          -> worker (bounded authority) -> evidence -> baton update
          -> independent critic -> repair loop -> verdict

Tools (runtime root D:\CAGE\xcsv-ai-continuity\tools):

Tool Purpose
xcsv-workers.ps1 Worker invocation + SOVRAN credential scrub + authority flags
xcsv-gauntlet.ps1 Router, critic separation, durable baton writes
xcsv-failure-tests.ps1 Nine real failure/exhaustion scenarios
xcsv-gauntlet-run.ps1 The XCSV-ORCH-001 acceptance run

Routing degrades OpenAI -> Anthropic -> OpenCode -> local Ollama -> BLOCKED. A critic may never share a provider with the implementer it reviews; provider identity, not worker id, is the separation key.

Isolation: two real defects found and repaired (2026-08-09)

1. Shared OpenClaw approval token. exec-approvals.json in the XCSV profile carried a socket token byte-identical to the default/SOVRAN-era profile. The socket paths differed but the shared secret did not. Repaired by rotating the XCSV token only; the default profile was left untouched.

2. cmd.exe AutoRun re-injecting SOVRAN state. HKCU\Software\Microsoft\Command Processor\AutoRun points at the SOVRAN shell landing script. Because every npm-installed worker (codex.cmd, gemini.cmd, opencode.cmd) launches through cmd.exe, the landing script re-injected SOVRAN_* into each worker after the environment scrub and prepended its banner to worker stdout. Repaired by always invoking cmd.exe /d, which disables AutoRun for that invocation only and leaves the SOVRAN shell landing fully intact for SOVRAN's own use.

Verified after repair: a real child process sees 0 SOVRAN_* / OPENCLAW_SECRET_* / SMTP_* variables, no banner in stdout, and the positive markers XCSV_PROJECT / XCSV_STATE_ROOT / XCSV_ESTATE_ISOLATED.

The shared shell profile itself is classified HARMLESS_SHARED_SHELL_PROFILE: it sets three workspace-root variables, prints a banner, and changes directory. It carries no credentials, baton, or model configuration.

Current Status

Status is PARTIAL for automated failover and HANDOFF_READY_MANUAL_FAILOVER for the XCSV baton.

Fresh checks on 2026-08-08 proved the existing continuity lane is usable for a manual baton and read-only sidecar critics:

  • D:\XCSV\tools\xcsv-continuity.ps1 hydrate reads the active XCSV baton.
  • D:\XCSV\tools\xcsv-continuity.ps1 verify-isolation returns PASS_BASIC_ISOLATION.
  • D:\XCSV\tools\xcsv-continuity.ps1 failure-test returns PASS_FAILURE_DOES_NOT_MUTATE_HANDOFF.
  • openclaw --profile xcsvcontinuity config validate reports the isolated config valid.
  • openclaw --profile xcsvcontinuity sessions list --json reports zero sessions under C:\Users\Architect\.openclaw-xcsvcontinuity\agents\main\sessions\sessions.json.
  • openclaw --profile xcsvcontinuity plugins list --json --enabled loads 32 enabled bundled plugins with no registry diagnostics.
  • openclaw --profile xcsvcontinuity skills list --json --eligible succeeds; unavailable optional skills were disabled by openclaw --profile xcsvcontinuity doctor --fix --non-interactive --yes.
  • The default and profile OpenClaw approval files remain distinct by SHA256 after repair.
  • ollama run qwen3-4b-instruct "Reply exactly: XCSV local fallback OK" returned the requested phrase.

Do not upgrade this to automatic failover authority yet. Hermes profile isolation is file-proven, but no hermes executable is currently on PATH and the xcsvcontinuity profile has no API keys. OpenClaw profile initialization previously migrated the default C:\Users\Architect\.openclaw\exec-approvals.json into the new profile and archived the default file as .migrated; the default file was restored. Treat OpenClaw as collision-sensitive and read-only until profile operations are covered by a stronger before/after hash test that wraps real OpenClaw commands.

2026-08-08 EXILE-DB-001 Checkpoint

Active extDB3 SQL_CUSTOM file is proven as E:\arma3server\@ExileServer\sql_custom\exile.ini. Proof: launcher runs from E:\arma3server with -servermod=@ExileServer; RPT loaded E:\arma3server\@ExileServer\extDB3_x64.dll; extDB3 logs are written under @ExileServer\logs; local runbooks and extDB3 staging tools identify @ExileServer\sql_custom\exile.ini as the live SQL_CUSTOM file. The @ExileServer\extDB\sql_custom\exile.ini copy is a byte-identical compatibility mirror.

EXILE-DB-001 repaired four $CUSTOM_1$ query templates: insertConstruction, insertContainer, updateContainer, and createTerritory. The repair uses NULLIF(?, 'NULL'); updateContainer and createTerritory require non-sequential SQL1_INPUTS so the former $CUSTOM_1$ argument remains bound to the nullable column.

OpenClaw remains collision-sensitive. The XCSV profile reports zero sessions at C:\Users\Architect\.openclaw-xcsvcontinuity\agents\main\sessions\sessions.json, but its approval file copied shared authorization material from the default profile. Manual failover via the XCSV baton is the allowed continuity path until OpenClaw profile initialization is fully characterized.

2026-08-09 XCSV-ORCH-001 — Gauntlet acceptance

Verdict: PASS_VERIFIED for the Gauntlet Loop, MANUAL_ONLY for OpenClaw.

Four claims were routed to four distinct providers, each on its first lane:

Claim Role Worker Provider
C1 primary analyst codex-cli OpenAI (gpt-5.5)
C2 independent critic claude-cli Anthropic
C3 second critic opencode-cli OpenCode (deepseek-v4-flash-free)
C4 offline lane ollama-qwen3-4b-instruct Ollama (local)
C5 replacement worker codex-cli OpenAI

The critic loop did real work. The claim under test was "the tracked XCSV continuity artifacts have drifted from runtime, and the correct reconciliation is runtime -> tracked". C1 returned PARTIAL; C2 and C3 both CONFIRMed that the direction was unproven and that a 5x/23x size replacement would destroy tracked-only content unreviewed.

They were right. D:\XCSV\tools\xcsv-continuity.ps1 is a deliberate 378-byte delegating wrapper that invokes the runtime tool, not a stale copy of it. Because the runtime script derives its state root from its own location, copying runtime over tracked would have silently created a second continuity state root under D:\XCSV. The reconciliation was therefore changed from copy to curated update, and the wrapper was left untouched.

Handoff was proven without transcript: a fresh codex-cli process given only CURRENT_HANDOFF.json correctly restated the work item, the next exact action, and a prohibition it was under.

OpenClaw: failed closed, deliberately

openclaw --profile xcsvcontinuity agent --local reaches the agent lane but returns ProviderAuthError: No API key found for provider "openai". OpenClaw's own remedy text suggests copying auth profiles from the main agentDir — which is exactly what produced the original approval-token collision. That path was refused. OpenClaw stays MANUAL_ONLY; routing authority remains with the deterministic XCSV router until ARCHITECT supplies XCSV-scoped credentials.

Clone this wiki locally