Skip to content

ROLLING-REFLECTION-24H.md

Latest commit

 

History

History
133 lines (102 loc) · 5.41 KB

ROLLING-REFLECTION-24H.md

File metadata and controls

133 lines (102 loc) · 5.41 KB
Raw

Rolling Reflection — bounded 24-hour local monitor

Status: DESIGN; test output is MEASURED_LIRIS_LOCAL only after the tests run. The stale fabric/canon fallback does not affirm a live system deployment.

The monitor reads one existing response-Rime INDEX.hbi and at most the 60 most recent *-CENTER.hbp files. It never opens *.notepad response files. Each cycle verifies the center commitments and creates:

  • an oldest-to-newest FORWARD root over the observed window;
  • a newest-to-oldest BACKWARD root over that same observed window;
  • a domain-separated SELF_REDUCTION root over both directions;
  • one fsync'd exclusive cycle HBP, then individually replaced rolling HBI and status HBP files.

Those three artifacts are not one atomic multi-file transaction. Verification fails closed on an orphan receipt, stale .next, missing file, or HBI/status mismatch.

Every source center and generated receipt/HBI/status keeps these coordinates distinct:

CENTER_MEMBERSHIP(NULLSPACE=0)={HBI,HBP,SHA,SH,HASH}
CENTER_TRAVERSAL=HBI->HBP->SH->HASH->SHA

FORWARD means traversal of levels already present in the observed window. It does not predict, generate, or commit to future messages:

SCOPE=OBSERVED_WINDOW_ONLY
FABRICATED_FUTURE=0
RAW_MESSAGES_READ=0

The default foreground duration is 86,400 seconds (24 hours), with a 60-second poll interval. Duration cannot exceed 24 hours; each run and repository has hard byte, level, receipt, and cycle ceilings. 60 or more new levels between polls creates a discontinuity and fails closed because append-only overlap can no longer be verified.

Explicit start and status

The CLI does not install a daemon, scheduled task, hook, or network service. By default it examines ~/.codex/response-rime and proceeds only when exactly one real session-* directory contains INDEX.hbi:

python tools/rolling_reflection_24h.py start

With multiple Stop-hook sessions, select one by its exact directory name or give an explicit source directory:

python tools/rolling_reflection_24h.py start \
  --session-id session-EXACT-ID

python tools/rolling_reflection_24h.py start \
  --source-dir /explicit/response-rime/session-directory

A short bounded duration is available for controlled tests. It can never receive the COMPLETE_24H state:

python tools/rolling_reflection_24h.py start \
  --session-id session-EXACT-ID \
  --duration-seconds 2 \
  --poll-seconds 1

Status verifies the HBI, every bounded receipt, the receipt chain, and the status HBP without starting a run. It uses the same exact-one auto-discovery unless an explicit monitor directory is supplied:

python tools/rolling_reflection_24h.py status

python tools/rolling_reflection_24h.py status \
  --monitor-dir /explicit/monitor-directory

RUNNING in the status file records the last clean transition written by an explicit foreground run. It is not a process-liveness claim; every status row sets runtime_live_inferred=0.

Every written status records requested_duration_seconds, elapsed_monotonic_seconds, clock_basis, and completion_reason. Completion states are deliberately distinct:

  • COMPLETE_24H requires the real monotonic clock, the requested 86,400 seconds, and DURATION_REACHED with at least that elapsed time;
  • COMPLETE_SHORT_RUN records a shorter real-clock duration;
  • COMPLETE_CYCLE_LIMIT records a real-clock cycle ceiling reached first;
  • COMPLETE_TEST_CLOCK records any injected/fake clock, with duration versus cycle-limit outcome retained in completion_reason.

Fail-closed partial-write recovery

The cycle receipt, rolling HBI, and status HBP are separate files. A power loss or write error can therefore leave a durable partial set even though each individual replacement is fsync'd or atomic at the file boundary. The monitor leaves that set intact and requires an explicit held-for-review recovery path.

Recovery is additive and preserves evidence:

  1. Stop the exact foreground monitor process and confirm it no longer owns the directory.
  2. Preserve a byte-for-byte copy and hashes of the entire failed monitor directory.
  3. Move the whole failed directory to a HELD_FOR_REVIEW name outside the active monitor path; retain its orphan, .next, HBI, status, and lock files unchanged.
  4. Start a new empty monitor directory from the independently verified source INDEX.hbi. The new directory begins a new GENESIS receipt chain.
  5. Keep the held chain and the new chain as separate evidence strata. Any later in-place salvage requires its own reviewed recovery tool and receipt.

Automatic lock release is narrower than recovery: it applies only to the exact monitor-owned transient ROLLING.lock successfully acquired by that invocation. Project files, source response-Rime files, receipts, HBI rows, status files, and unowned locks remain untouched.

Security boundary

The implementation rejects symbolic links, path-escaping center names, malformed or non-UTF-8 tuple text, stale transactions, concurrent locks, rewritten overlap, orphan receipts, and commitment mismatches. It contains no network, subprocess, or shell execution path.

SHA commitments provide tamper evidence against accidental change and actors who cannot rewrite the whole local account. They are not authentication against an attacker who controls the same account, all files, and the interpreter. OS access control and protected keyed attestations remain separate security layers.