-
Notifications
You must be signed in to change notification settings - Fork 0
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.
Create or update the current baton:
D:\XCSV\tools\xcsv-continuity.ps1 checkpointShow the current baton:
D:\XCSV\tools\xcsv-continuity.ps1 showHydrate a continuation summary:
D:\XCSV\tools\xcsv-continuity.ps1 hydrateShow worker policy:
D:\XCSV\tools\xcsv-continuity.ps1 workersVerify basic isolation:
D:\XCSV\tools\xcsv-continuity.ps1 verify-isolationRun the simulated worker-exhaustion check:
D:\XCSV\tools\xcsv-continuity.ps1 failure-testXCSV 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.
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.
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.
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 hydratereads the active XCSV baton. -
D:\XCSV\tools\xcsv-continuity.ps1 verify-isolationreturnsPASS_BASIC_ISOLATION. -
D:\XCSV\tools\xcsv-continuity.ps1 failure-testreturnsPASS_FAILURE_DOES_NOT_MUTATE_HANDOFF. -
openclaw --profile xcsvcontinuity config validatereports the isolated config valid. -
openclaw --profile xcsvcontinuity sessions list --jsonreports zero sessions underC:\Users\Architect\.openclaw-xcsvcontinuity\agents\main\sessions\sessions.json. -
openclaw --profile xcsvcontinuity plugins list --json --enabledloads 32 enabled bundled plugins with no registry diagnostics. -
openclaw --profile xcsvcontinuity skills list --json --eligiblesucceeds; unavailable optional skills were disabled byopenclaw --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.
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.
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 --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.