feat: mem v2 - PR2 (#11365)

# Memories migration plan (simplified global workflow)

## Target behavior

- One shared memory root only: `~/.codex/memories/`.
- No per-cwd memory buckets, no cwd hash handling.
- Phase 1 candidate rules:
- Not currently being processed unless the job lease is stale.
- Rollout updated within the max-age window (currently 30 days).
- Rollout idle for at least 12 hours (new constant).
- Global cap: at most 64 stage-1 jobs in `running` state at any time
(new invariant).
- Stage-1 model output shape (new):
- `rollout_slug` (accepted but ignored for now).
- `rollout_summary`.
- `raw_memory`.
- Phase-1 artifacts written under the shared root:
- `rollout_summaries/<thread_id>.md` for each rollout summary.
- `raw_memories.md` containing appended/merged raw memory paragraphs.
- Phase 2 runs one consolidation agent for the shared `memories/`
directory.
- Phase-2 lock is DB-backed with 1 hour lease and heartbeat/expiry.

## Current code map

- Core startup pipeline: `core/src/memories/startup/mod.rs`.
- Stage-1 request+parse: `core/src/memories/startup/extract.rs`,
`core/src/memories/stage_one.rs`, templates in
`core/templates/memories/`.
- File materialization: `core/src/memories/storage.rs`,
`core/src/memories/layout.rs`.
- Scope routing (cwd/user): `core/src/memories/scope.rs`,
`core/src/memories/startup/mod.rs`.
- DB job lifecycle and scope queueing: `state/src/runtime/memory.rs`.

## PR plan

## PR 1: Correct phase-1 selection invariants (no behavior-breaking
layout changes yet)

- Add `PHASE_ONE_MIN_ROLLOUT_IDLE_HOURS: i64 = 12` in
`core/src/memories/mod.rs`.
- Thread this into `state::claim_stage1_jobs_for_startup(...)`.
- Enforce idle-time filter in DB selection logic (not only in-memory
filtering after `scan_limit`) so eligible threads are not starved by
very recent threads.
- Enforce global running cap of 64 at claim time in DB logic:
- Count fresh `memory_stage1` running jobs.
- Only allow new claims while count < cap.
- Keep stale-lease takeover behavior intact.
- Add/adjust tests in `state/src/runtime.rs`:
- Idle filter inclusion/exclusion around 12h boundary.
- Global running-cap guarantee.
- Existing stale/fresh ownership behavior still passes.

Acceptance criteria:
- Startup never creates more than 64 fresh `memory_stage1` running jobs.
- Threads updated <12h ago are skipped.
- Threads older than 30d are skipped.

## PR 2: Stage-1 output contract + storage artifacts
(forward-compatible)

- Update parser/types to accept the new structured output while keeping
backward compatibility:
- Add `rollout_slug` (optional for now).
- Add `rollout_summary`.
- Keep alias support for legacy `summary` and `rawMemory` until prompt
swap completes.
- Update stage-1 schema generator in `core/src/memories/stage_one.rs` to
include the new keys.
- Update prompt templates:
- `core/templates/memories/stage_one_system.md`.
- `core/templates/memories/stage_one_input.md`.
- Replace storage model in `core/src/memories/storage.rs`:
- Introduce `rollout_summaries/` directory writer (`<thread_id>.md`
files).
- Introduce `raw_memories.md` aggregator writer from DB rows.
- Keep deterministic rebuild behavior from DB outputs so files can
always be regenerated.
- Update consolidation prompt template to reference `rollout_summaries/`
+ `raw_memories.md` inputs.

Acceptance criteria:
- Stage-1 accepts both old and new output keys during migration.
- Phase-1 artifacts are generated in new format from DB state.
- No dependence on per-thread files in `raw_memories/`.

## PR 3: Remove per-cwd memories and move to one global memory root

- Simplify layout in `core/src/memories/layout.rs`:
- Single root: `codex_home/memories`.
- Remove cwd-hash bucket helpers and normalization logic used only for
memory pathing.
- Remove scope branching from startup phase-2 dispatch path:
- No cwd/user mapping in `core/src/memories/startup/mod.rs`.
- One target root for consolidation.
- In `state/src/runtime/memory.rs`, stop enqueueing/handling cwd
consolidation scope.
- Keep one logical consolidation scope/job key (global/user) to avoid a
risky schema rewrite in same PR.
- Add one-time migration helper (core side) to preserve current shared
memory output:
- If `~/.codex/memories/user/memory` exists and new root is empty,
move/copy contents into `~/.codex/memories`.
- Leave old hashed cwd buckets untouched for now (safe/no-destructive
migration).

Acceptance criteria:
- New runs only read/write `~/.codex/memories`.
- No new cwd-scoped consolidation jobs are enqueued.
- Existing user-shared memory content is preserved.

## PR 4: Phase-2 global lock simplification and cleanup

- Replace multi-scope dispatch with a single global consolidation claim
path:
- Either reuse jobs table with one fixed key, or add a tiny dedicated
lock helper; keep 1h lease.
- Ensure at most one consolidation agent can run at once.
- Keep heartbeat + stale lock recovery semantics in
`core/src/memories/startup/watch.rs`.
- Remove dead scope code and legacy constants no longer used.
- Update tests:
- One-agent-at-a-time behavior.
- Lock expiry allows takeover after stale lease.

Acceptance criteria:
- Exactly one phase-2 consolidation agent can be active cluster-wide
(per local DB).
- Stale lock recovers automatically.

## PR 5: Final cleanup and docs

- Remove legacy artifacts and references:
- `raw_memories/` and `memory_summary.md` assumptions from
prompts/comments/tests.
- Scope constants for cwd memory pathing in core/state if fully unused.
- Update docs under `docs/` for memory workflow and directory layout.
- Add a brief operator note for rollout: compatibility window for old
stage-1 JSON keys and when to remove aliases.

Acceptance criteria:
- Code and docs reflect only the simplified global workflow.
- No stale references to per-cwd memory buckets.

## Notes on sequencing

- PR 1 is safest first because it improves correctness without changing
external artifact layout.
- PR 2 keeps parser compatibility so prompt deployment can happen
independently.
- PR 3 and PR 4 split filesystem/scope simplification from locking
simplification to reduce blast radius.
- PR 5 is intentionally cleanup-only.

codex-rs/core/templates/memories/consolidation.md

@@ -2,11 +2,11 @@
 Consolidate Codex memories in this directory: {{ memory_root }}
 
 Phase-1 inputs already prepared in this same directory:
-- `raw_memories/` contains per-thread raw memory markdown files.
-- `memory_summary.md` contains a compact routing map from short summary -> thread id.
+- `rollout_summaries/` contains per-thread rollout summary markdown files (`<thread_id>.md`).
+- `raw_memories.md` contains merged raw memory content from recent stage-1 outputs.
 
 Consolidation goals:
-1. Read `memory_summary.md` first to route quickly, then open the most relevant files in `raw_memories/`.
+1. Read `rollout_summaries/` first to route quickly, then cross-check details in `raw_memories.md`.
 2. Resolve conflicts explicitly:
    - prefer newer guidance by default;
    - if older guidance has stronger evidence, keep both with a verification note.
@@ -23,5 +23,5 @@ Expected outputs for this directory (create/update as needed):
 - `skills/<skill-name>/...`: optional skill folders when there is clear reusable procedure value.
 
 Do not rewrite phase-1 artifacts except when adding explicit cross-references:
-- keep `raw_memories/` as phase-1 output;
-- keep `memory_summary.md` as the compact map generated from the latest summaries.
+- keep `rollout_summaries/` as phase-1 output;
+- keep `raw_memories.md` as the merged stage-1 raw-memory artifact.

codex-rs/core/templates/memories/stage_one_input.md

@@ -1,4 +1,4 @@
-Analyze this rollout and produce `rawMemory` and `summary` as JSON.
+Analyze this rollout and produce `raw_memory`, `rollout_summary`, and optional `rollout_slug` as JSON.
 
 rollout_context:
 - rollout_path: {{ rollout_path }}

codex-rs/core/templates/memories/stage_one_system.md

@@ -2,8 +2,9 @@
 You are given one rollout and must produce exactly one JSON object.
 
 Return exactly one JSON object with this schema:
-- rawMemory: a detailed markdown raw memory for this rollout only.
-- summary: a concise summary suitable for shared memory aggregation.
+- raw_memory: a detailed markdown raw memory for this rollout only.
+- rollout_summary: a concise summary suitable for shared memory aggregation.
+- rollout_slug: optional stable slug for the rollout (accepted but currently ignored).
 
 Input contract:
 - The user message contains:
@@ -20,7 +21,7 @@ Global writing rules:
 - Do not include markdown fences around the JSON object.
 - Output only the JSON object and nothing else.
 
-Outcome triage guidance for `Outcome:` labels in `rawMemory`:
+Outcome triage guidance for `Outcome:` labels in `raw_memory`:
 - Use `success` for explicit user approval or clear verification evidence.
 - Use `partial` when there is meaningful progress but incomplete or unverified completion.
 - Use `fail` for explicit dissatisfaction/rejection or hard failure.
@@ -28,7 +29,7 @@ Outcome triage guidance for `Outcome:` labels in `rawMemory`:
 - If the user switched topics without explicit evaluation, usually use `uncertain`.
 - If only assistant claims success without user confirmation or verification, use `uncertain`.
 
-`rawMemory` structure requirements:
+`raw_memory` structure requirements:
 - Start with `# <one-sentence summary>`.
 - Include:
   - `Memory context: ...`
@@ -42,7 +43,7 @@ Outcome triage guidance for `Outcome:` labels in `rawMemory`:
   - `Pointers and references (annotate why each item matters):`
 - Prefer more, smaller task sections over one broad mixed section.
 
-`summary` requirements:
+`rollout_summary` requirements:
 - Keep under 120 words.
 - Capture only the most reusable and actionable outcomes.
 - Include concrete paths/commands/errors when high-signal.