## Jess Memory/Runtime Architecture — Consolidated Plan Snapshot (2026-03-02 23:55 EST)

Purpose: preserve the complete "small memory brain + large main brain" and state-machine validation plan in one place.

### 1) Core architecture intent
- Keep Jess main responder on large local model (`qwen3.5-35b-a3b-q8`) for user-facing quality.
- Keep memory orchestration lightweight and deterministic:
  - `jess_memory_manager.py` handles summarize/cleanup cadence.
  - `jess_keeper` handles scoring / RAG record generation.
- Explicitly discussed selecting a *small local model* for keeper-like tool-use tasks (memory summarize + RAG ranking), while preserving Jess large model for primary responses.

### 2) Reliability constraints and rules
- Jess must run solo on llama.cpp path (no concurrent session pileups for local agent).
- Cron nudges should target cloud agents; avoid local-agent contention path.
- Context pressure is managed by timers + policy, not manual babysitting.
- State-machine evidence, not intuition, is required before closeout.

### 3) What was planned/tested for state-machine work (card-6319c3)
- Build Runtime State Machine in Memory Ops panel.
- Validate legal states/edges: BOOTING, IDLE_READY, PROCESSING, MEMORY_MAINTENANCE, DEGRADED, RECOVERY.
- Capture live evidence artifacts repeatedly in `workspace-codex/artifacts/`.
- Include synthetic degraded injection and prove transition path:
  - `DEGRADED -> RECOVERY -> IDLE_READY`
- Require desktop + mobile panel verification before declaring done.

### 4) Execution artifacts and validation stream (high level)
- Scripted check path added and run repeatedly:
  - `scripts/validate_memory_ops_state_machine.sh`
  - `scripts/memory_ops_state_machine_check.js`
- Multiple captured artifacts document live runs and transition checks.
- Browser-side checks were run against `:8090/20-memory-ops` for UI evidence rendering.

### 5) Adjacent Jess autonomy/research track
- Jess completed board/comms proficiency gates (`card-dcfb01`, `card-b8e740`).
- Jess moved through implementation cards (`card-002` complete, `card-003` in progress).
- AI-Scientist path remains planned (`card-e456ed` todo) for downtime autonomous research infra.

### 6) Current known gaps to finish
- Final, clean proof bundle for state-machine transition coverage in one review package.
- Remaining DM unread/render mismatch in `main_q35` thread path.
- Decide whether keeper should be strictly heuristic/rule-based or small-model-assisted by default.


## Backfill Timeline — Jess Plan/Validation (Requested: 2026-03-02, ~16:00–21:00 EST)

### 16:00–16:30 window
- Codex repeatedly ran live state-machine validation on `card-6319c3` using `/jess/manager` triggers.
- Evidence artifacts captured proving MEMORY_MAINTENANCE signal wiring and fresh manager activity:
  - `artifacts/memory-ops-transition-check-2026-03-02-161034.log`
  - `artifacts/memory-ops-transition-check-20260302-162302.jsonl`
- Focus: prepare for explicit DEGRADED->RECOVERY transition proof.

### 19:30 window
- q35/Jess resumed delivery work and grabbed `card-002` (priority tag rendering) in-progress.

### 21:30–21:57 window (key proof period)
- Codex induced synthetic keeper-error conditions and captured live transition sequence:
  - `DEGRADED -> RECOVERY -> IDLE_READY`
  - artifact: `artifacts/memory-ops-degraded-recovery-20260302-213247.jsonl`
- Browser-side verification on `:8090/20-memory-ops` confirmed state-machine edge strip + transition log rendering with local-time evidence.
- Additional validator run captured `MEMORY_MAINTENANCE -> IDLE_READY` without degraded signals.

### What this confirms from that period
- Plan was broader than generic memory hygiene: it included live fault-injection, legal-edge validation, and UI evidence rendering for Jess runtime state-machine behavior.
- The "small memory helper + large main brain" direction remained active context (keeper-model-selection thread + large q35 responder path) while reliability proofing continued.


## Backfill Correction — March 1 (16:00–21:00 EST) Jess Memory/Plan Context

You requested this specific window; key items from that period:

1) Reliability root-cause + operating rule (ops channel)
- Jess had an unresponsive incident caused by concurrent isolated cron sessions competing for local llama.cpp resources.
- Operational rule set: no concurrent local-agent cron session pileups; q35 runs solo; cron nudges target cloud agents.
- Context was reduced to 64K to mitigate SWA full reprocessing cost.

2) Keeper architecture intent (projects channel)
- Explicit statement: jess-keeper is a lightweight Python scoring helper and does not run as heavy model inference by default.
- Explicit planning ask: select a *small local model* for keeper tasks (memory summarize + RAG ranking/tool-use) with tradeoff analysis.

3) "Small helper brain + larger main brain" discussion signal (general channel)
- Jess responded with keeper-model tradeoff guidance (small footprint/tool-use vs faster but less tool-compliant options), reinforcing the split-brain architecture discussion.

4) Board/process and execution plan context for Jess
- Board system launched in this same window and became required execution path.
- Jess-specific onboarding and workflow support were requested by Pat and acknowledged, then converted into explicit board/comms operating steps.

5) Why this matters for current design
- This window is where the architectural split was formed:
  - large q35 runtime for primary response quality,
  - lightweight memory/keeper pipeline with optional small-model assistance,
  - strict anti-contention constraints for local runtime stability.


## Backfill Extension — Day Before (2026-02-28) Relevant Jess Context

From available records, 2026-02-28 contains setup/orientation context (not the full keeper-model debate yet):

1) Jess baseline identity/path already established
- Jess mapped as local q35 agent in workspace-q35 with model path intent set to qwen3.5-35b-a3b-q8.

2) Team-wide infra groundwork was laid
- Shared docs/skills/memory scaffolding and collaboration tooling were distributed to all agents, including Jess.
- This matters because the next day’s memory/keeper architecture work built directly on that shared infra.

3) Early known failure mode context (captured in q35 history)
- Ollama path for qwen3.5 q8 was failing; move toward llama.cpp (`q35cpp`) became the durable direction.
- Large carried contexts were already recognized as a response-latency risk.

Interpretation:
- 2026-02-28 is the setup day that enabled 2026-03-01’s explicit architecture split discussion.
- The concrete "small helper memory path + large responder runtime" wording appears on 2026-03-01, but 2026-02-28 contains the precursor constraints and infrastructure.