Frequently Asked Questions

1. Install the RL4 extension in Cursor (or VSCode). 2. Create your RL4 account. 3. Open the RL4 Webview. 4. Click "ReSync MCP" to connect your workspace. That's it. No manual setup required.

RL4 creates a folder at your workspace root: {workspace_root}/.rl4/ This folder contains: - Snapshots - Timeline (timeline.md) - Evidence logs - Project skills (Rl4-Skills.mdc) - Structured metadata You do not need to edit or touch these files manually. RL4 manages everything automatically. Think of it as your project's structured brain.

Use MCP (headless) or the Webview (manual). Run your first Snapshot: "SINCE FIRST PROMPT". RL4 will: - Retrieve your entire historical chat from Cursor - Capture relevant IDE activity - Build your first structured Timeline - Generate initial project Skills Your past work becomes structured memory instantly.

Start coding normally. When you finish your first session, run a Snapshot: "SINCE FIRST PROMPT". RL4 will: - Capture everything that happened - Create your first Timeline entries - Generate project skills based on real activity From that moment on, your project has continuity.

A Snapshot is not just a save. It: 1. Captures IDE activity 2. Captures chat history (Cursor + Claude CLI) 3. Structures events into evidence 4. Updates your development journal (timeline.md) 5. Updates your project-specific skills (Rl4-Skills.mdc) 6. Produces a compact memory layer usable by any LLM Run a Snapshot whenever you want to: patch your LLM's memory with what was actually done, sync multiple chats into one coherent state, freeze a stable checkpoint, or prepare to switch models or sessions.

Each Snapshot enriches: {workspace_root}/.rl4/timeline.md This file acts as a structured development journal. It allows you to: follow your progress day by day, see what changed and why, track major decisions, replay the evolution of your project. It's not a commit log. It's a reasoning-aware timeline. You can read it anytime — but RL4 maintains it automatically.

Each Snapshot also updates: {workspace_root}/.cursor/rules/Rl4-Skills.mdc This file contains: DO rules, DON'T rules, architectural constraints, lessons extracted from real regressions, guardrails derived from actual mistakes. This is how RL4 prevents your AI from repeating the same errors. Instead of manually writing rules, RL4 builds them from evidence. When your LLM runs through MCP, these skills are injected automatically. Over time, your assistant aligns with your project.

RL4 works with: Cursor, VSCode, Claude Code CLI. You can: switch chats, switch sessions, switch LLM providers. Your project memory remains intact. All structured memory lives in {workspace_root}/.rl4/. The memory belongs to the project — not the model.

**Manual (Webview):** Click buttons, run Snapshots manually, inspect memory. **Headless (via MCP):** Use tool calls like run_snapshot(), search_context(). This allows agents to: retrieve structured context, query timeline and evidence, operate with full project awareness. Headless mode turns RL4 into a reasoning middleware.

Yes. Because RL4 uses structured snapshots and a content store, it can: reconstruct a workspace state, replay what happened, provide proof-based explanations. It's not just logs. It's a replayable memory layer.

No. RL4 observes, structures, and stores metadata. It does not alter your source files. Your code remains untouched.

Yes. All core memory lives locally inside {workspace_root}/.rl4/. You are not locked into a cloud memory box. The memory moves with your repository.

Git tracks diffs. RL4 tracks: decisions, context, reasoning, regressions, constraints, chat history, IDE activity. Git tells you what changed. RL4 tells you what happened — and why.

Recommended moments: after completing a feature, after fixing a bug, before switching LLM, before refactoring, at the end of a session, before handing work to another agent. Think of Snapshot as: "Synchronize memory with reality."

RL4 turns your project into: a persistent memory system, a replayable timeline, a proof-based reasoning ledger, a constraint-aware AI environment — without requiring you to manage any files manually.

RL4 Cursor builds an RCEP™ snapshot from your selected Cursor chat history. It extracts: - Topics discussed with weights - Decisions made with timestamps - Constraints and rules established - Timeline summary - Evidence Pack: file events, IDE activity signals, workspace state

It scans Cursor local storage (workspace/global DB when available) and can fall back to an exported cursor-aiService.generations.json if needed. The scan is read-only and doesn't modify your Cursor data.

Yes — that's the core value. Generate a snapshot in Cursor, then paste it into Claude, ChatGPT, Gemini, or any other LLM. The new model receives your full context: what you built, what you decided, what constraints apply.

Quick options include: - "Since first prompt ever" — Full history - "Since last snapshot end" — Incremental capture - "Last 30 min" / "Today" — Recent work only You can also filter by specific threads if you only want certain conversations.

- **Compact** (recommended): Smallest structured snapshot, fastest to generate. Works for 90% of cases. - **Ultra+**: Compact + a "meaning layer" with mini summary and checklist. More context for complex projects. - **Full Transcript**: Complete conversation history. Only for short threads — can be too large for most LLMs.

A thread is a single Cursor chat conversation. - **Mono-thread**: One thread per snapshot. Cleanest, most focused. - **Multi-thread**: Bundle multiple conversations into one snapshot. Useful when your work spans several chat sessions.

IDE sessions are long, technical, and messy (refactors, regressions, silent changes). ProofLayer reduces drift by grounding handoffs in concrete evidence: what files actually changed, what the IDE did, and what the workspace looked like when the snapshot was generated. This helps the next LLM understand not just what you discussed, but what you actually implemented.

- **File events** (append-only): save, create, delete, rename — with timestamps and SHA-256 hashes - **IDE activity**: which files were open/focused - **Causal links**: correlations between chat messages and file changes - **Burst patterns**: detected activity types (feature, fix, refactor, test) - **Daily timelines**: day-by-day reconstruction of what happened

Hot files are the files with the most modifications during your captured period. They represent your implementation spine — the ground truth of what you actually built, not just what you discussed. If you discussed a topic but there's no corresponding hot file, that's a GAP: an intention that wasn't implemented.

Yes by design. Events are only added, never modified or deleted. This improves traceability and helps detect drift. It's not cryptographically tamper-proof (they're local files), but it reduces ambiguity significantly.

No. Evidence tracking begins when you install RL4. It cannot reconstruct file events from before installation. For full evidence coverage, install RL4 at the start of your project.

The SHA-256 checksum proves the snapshot wasn't accidentally modified after generation. It's tamper-evidence, not tamper-proof. It does NOT prove: - That the content is true - Who authored it - That the LLM will follow it correctly

Yes. Recompute the checksum from the canonicalized payload and compare it to the included value. If they match, the snapshot hasn't been modified since generation.

No. Integrity + evidence provide tamper-evidence and traceability — not factual correctness. Models can still be wrong. RL4 helps them stay consistent with your project state and constraints, but it doesn't guarantee accuracy.

Some LLMs try to helpfully reformat or summarize the snapshot. Tell it explicitly: "Do not modify the RL4 package. Read it and use it as context only." The snapshot is for the model, not for you to read — let it parse the structure directly.

No. RL4 Cursor is local-only by design. Your snapshots, transcripts, evidence logs, and code never leave your machine. The only data sent (optionally, for Beta) is your snapshot count — not the content.

It hashes some files (SHA-256) for evidence signals and tracks file events. It's designed to skip noisy directories (node_modules, build outputs, .git) and large/binary assets. The hashes are for verification, not for reading content.

Everything stays on your machine: - Extension storage (snapshots, state) - Workspace folder: .rl4/ (evidence logs, timeline, snapshots) - Workspace folder: .cursor/rules/ (Rl4-Skills.mdc, RL4.Cursor.Extension.mdc) No cloud sync. No remote backup.

1. Uninstall the extension 2. Delete the .rl4/ folder in your workspace 3. Delete .cursor/rules/Rl4-Skills.mdc and .cursor/rules/RL4.Cursor.Extension.mdc (or rl4-*.mdc) 4. Clear extension storage in Cursor settings if needed Nothing persists on RL4 servers because nothing was sent there.

No by default. The Beta program tracks snapshot count (a number, not content) to unlock rewards. Any future telemetry will be opt-in and clearly documented.

Yes. No RL4 backend is required. Generate and copy snapshots completely offline as long as Cursor and your local data are available.

That depends on your company's policies. Technically, RL4 is 100% local and doesn't transmit code or chats. But you should still follow your organization's rules for browser extensions and data handling tools.

- **End of day**: Capture progress before you forget context - **Before switching models**: Prepare for Claude → ChatGPT transitions - **Before Cursor updates**: Updates can sometimes affect chat history - **Before renaming/moving folders**: Prevents orphaned workspace issues - **Weekly on active projects**: Regular captures ensure continuity

Instead of capturing everything from the beginning each time, select "Since last snapshot end" to capture only new conversations since your last snapshot. This creates smaller, focused captures without duplicating old context.

Both work. For existing projects, RL4 will capture whatever chat history Cursor still has locally. For new projects, install RL4 from day one to get: - Full Evidence tracking from the start - Complete chat history coverage - Better causal links between chats and code changes

Always finalize before copying the final prompt. The finalize step extracts lessons learned (patterns to follow, mistakes to avoid) that enrich your context and get stored in .cursor/rules/Rl4-Skills.mdc for future sessions.

Cursor doesn't officially document retention periods. In practice: - Recent chats (< 1 month): Usually available - Older chats: May be purged without warning - Privacy Mode affects what's stored The safest approach: make regular snapshots so you don't depend on Cursor's retention.

There's no fixed limit in RL4 itself. RL4 exports whatever Cursor still has locally. If Cursor purged old conversations, RL4 can't recover them. The UI shows "Earliest recovered item" so you know what's actually available.

⚠️ This creates a new workspace ID in Cursor. Your old conversations become orphaned — they still exist but Cursor can't find them. **Always make a snapshot BEFORE renaming or moving.** If you already renamed, the old data might be recoverable manually from workspaceStorage/.

Sometimes, yes. Updates can change how Cursor indexes conversations or migrates data. Some users report losing access to history after updates. **Make a snapshot before major Cursor updates.** Also consider backing up ~/Library/Application Support/Cursor/User/ (macOS) periodically.

- Renaming or moving the project folder - Cursor updates (sometimes) - Clearing cache/data (Clear Application Data) - Reinstalling Cursor - Using cleanup tools (CleanMyMac, CCleaner) - Switching machines (no cloud sync) **Prevention**: Regular snapshots + periodic backup of Cursor's User folder.

Common causes: - Cursor already purged older conversations - Your selected time range is too narrow - Thread filtering is enabled (try disabling it) - You're in a different workspace than expected - Project was renamed/moved (check History disclaimer)

No. Even if you only use Cursor's built-in Claude, RL4 helps when: - Your thread gets long and starts forgetting decisions - You hit token/context limits - You want to start a fresh chat without re-explaining everything - You need to audit what happened last week

Yes. Copy the final snapshot prompt and share it via Slack, email, or docs. Any team member can paste it into their LLM to get the same context. This is useful for: - Onboarding new developers - Handing off tasks - Pair programming with shared context

You can ask for summaries manually. RL4 adds: - **Consistency**: Same structured format every time - **Evidence**: Links to actual file changes, not just chat - **Lessons**: Extracted patterns (DO/DONT) from your decisions - **Portability**: Works across any LLM without re-formatting - **One action**: Click → copy → paste, no prompt engineering

Typically 10-100x depending on your conversation length and mode. A 50k token thread might compress to 5k tokens of structured context. The metadata shows exact stats after generation.

RL4 keeps: goals, constraints, key decisions, important references, timeline. It trims: repetitive explanations, minor tangents, verbose back-and-forth, redundant context. Compression is explicit, not lossless. The summary shows what was captured.

For XXL conversations (>450k chars): - Full transcript mode is auto-disabled - Use Compact mode (handles any size) - Narrow your time range - Filter to specific threads - Make more frequent incremental snapshots

- **Basic**: Compact only, mono-thread, 7-day window, last snapshot only - **Pro**: + Ultra+ mode, custom time range, multi-thread, full history - **Ultra**: + Full Evidence Pack, all compression modes Pricing unlocks local features. No cloud sync. No data sent to RL4 servers.

No. Pricing gates local features only. Your data stays on your machine regardless of plan. Think of it as unlocking capabilities inside the extension, not paying for cloud storage.

Basic limits your selectable time range to the last 7 days. You can still capture conversations within that window, but you can't select "Since first prompt ever" for older history. Note: This doesn't override Cursor's own retention — if Cursor already purged data, no plan can recover it.

1. Ensure you're in a real workspace folder (not an empty window) 2. Check you have at least one Cursor chat in this workspace 3. Verify the project wasn't recently renamed/moved 4. Try the Pick exported JSON option 5. Check if sqlite3 or Python is available The Debug section (appears on empty scan) shows more diagnostics.

- Widen time range (try Since first prompt ever) - Disable thread filtering (or select correct threads) - Rescan and regenerate - Check History disclaimer — Cursor may have purged older data - Verify you're in the correct workspace

RL4 tries sqlite3 CLI first, then falls back to Python's built-in sqlite module. If neither works: - macOS/Linux: sqlite3 is usually pre-installed - Windows: Install Python or sqlite3 tools - Alternative: Use Pick exported JSON option

If you renamed/moved your project, old conversations might still exist. Two options: **Easy way (recommended):** 1. Enable Debug Mode in Step 0 2. Click "Scan for Orphans" to find lost workspaces 3. Click "Scan This" on any orphan to recover its history **Manual way:** 1. Navigate to ~/Library/Application Support/Cursor/User/workspaceStorage/ (macOS) 2. Search workspace.json files for your old project path 3. Use Custom Scan Path in Debug Mode to scan that folder

No. RL4 is designed to be lightweight: - Evidence collection is budgeted (max time, max files) - No continuous background processing - Heavy work only happens at scan/snapshot time - Skips large directories (node_modules, builds)

- **Cursor retention**: RL4 can only export what Cursor still has locally - **Evidence not retroactive**: Tracking starts at installation - **Compression is lossy**: Important context preserved, details trimmed - **Integrity ≠ truth**: Checksums verify tampering, not accuracy - **XXL sessions**: May need narrower windows or Compact mode - **No cloud sync**: Everything is local-only

Two reasons: 1. **Cursor retention**: If Cursor already purged old data, no plan can recover it 2. **Evidence budgets**: For performance, evidence collection has time/size limits Ultra improves quality and depth of what's available — it doesn't magically recover deleted data.

No. RL4 reads what Cursor has stored. If Cursor deleted/purged conversations, they're gone. This is why regular snapshots matter — they're your insurance against data loss.

Debug Mode is a collapsible section in Step 0 that reveals advanced troubleshooting tools. It's hidden by default to keep the main workflow clean, but it provides powerful recovery and diagnostic features when things go wrong. Tools include: Custom Scan Path, Orphan Workspace Recovery, Export Snapshot, and Database Repair.

Custom Scan Path lets you manually specify a workspaceStorage folder or state.vscdb file to scan. Use it when: - Automatic detection fails - You want to scan an orphaned workspace - You're recovering data from a backup You can paste a path or use Browse to pick a file.

Orphan workspaces are leftover folders in Cursor's workspaceStorage that point to projects that no longer exist (renamed, moved, or deleted). The Orphan Workspace Scanner finds: - Workspaces with missing folder paths - Duplicate workspace IDs for the same project Once found, you can scan them to recover old conversations that would otherwise be lost.

Export Snapshot saves your current snapshot as a portable JSON file. Use it for: - Backup before risky operations - Sharing context with teammates - Archiving important project milestones - Debugging (inspect the raw snapshot structure) The button is enabled only after generating a snapshot.

Repair Database runs SQLite maintenance on Cursor's databases: - **Integrity check**: Verifies database isn't corrupted - **VACUUM**: Reclaims unused space and defragments Use it if: - Scans are slow or failing - Database errors appear - Cursor feels sluggish It shows before/after file sizes so you can see space recovered.

Yes. Debug Mode tools are read-only or explicitly approved: - Scans don't modify your data - Repair Database only runs standard SQLite maintenance - Export creates a copy, doesn't touch originals The only destructive operation is VACUUM, which is a safe, well-tested SQLite command that reclaims space without data loss.

Developers who: - Use AI assistants daily in Cursor - Work on complex, multi-day projects - Hit context limits and lose continuity - Switch between different LLMs - Need to hand off context to teammates - Want audit trails of their AI-assisted work If your projects are short or you rarely hit context issues, you might not need it yet.

Then it's not for you right now — and that's okay. RL4 solves a specific pain: context loss during AI-assisted development. If your current workflow feels fine, you don't need to change it. Come back when you feel the pain.

RL4 Cursor builds an RCEP™ snapshot from selected Cursor chat history (threads + time range). Depending on your plan, it also includes an Evidence Pack summary: append‑only file events, lightweight IDE activity signals, and a workspace hash index snapshot.

No. RL4 Cursor is local‑only by design. Snapshots, transcripts (when stored), and evidence logs stay on your machine.

IDE sessions are long, technical, and messy (refactors, regressions, silent changes). ProofLayer reduces drift by grounding handoffs in concrete evidence: what files changed, what the IDE did, and what the workspace looked like when the snapshot was generated.

Yes. The flow is: scan → generate snapshot → copy finalization prompt → paste RL4 BLOCKS reply back → finalize → copy final handoff prompt.

It scans Cursor local storage (workspace/global DB when available) and can fall back to an exported `cursor-aiService.generations.json` if needed.

There’s no fixed “days” limit in RL4 itself. RL4 can only export what Cursor still has locally for that workspace, plus whatever you select via time range.

Common causes: - Cursor retention/windowing (older items not present locally) - Your selected time range is too narrow - Thread filtering is enabled but you didn’t select the right threads

A “thread” is a logical Cursor chat stream. - Mono‑thread: 1 thread per snapshot (cleanest, most deterministic). - Multi‑thread: bundle multiple threads into one coherent handoff (ordering preserved).

- Basic: Compact only, mono‑thread, rolling last‑7‑days window, last snapshot only (local). - Pro: Compact + UltraPlus, custom time range, multi‑thread, full snapshot history (local). - Ultra: all modes + full Evidence Pack tracking + custom range + multi‑thread + full local history. Pricing is a local feature gate: it unlocks modes/retention/evidence depth on-device. It does not mean your data is synced to a cloud or sent to RL4 servers.

Basic constrains snapshot generation to a rolling 7‑day window. Practically: when you generate a snapshot, the selectable time range is limited to the last 7 days for that workspace. This keeps payloads tight and reduces drift/noise, but it can’t override Cursor retention—if Cursor no longer has older items locally, RL4 can’t export them.

- Compact: smallest structured snapshot (fastest). - UltraPlus: Compact + a small “meaning layer” (mini summary + checklist/gates). - Transcript mode (plan‑gated): stores/verifies a full transcript reference locally for XXL cases instead of bloating the handoff payload. Which modes you can use is plan‑gated (Basic/Pro/Ultra). Even when Transcript mode is enabled, it’s still local storage—not a backend upload.

Typically: - Recent file events (append‑only): save/create/delete/rename - A partial workspace hash index (budgeted) - Minimal IDE activity signals (open/focused files, lint count if available) - Explicit “partial” flags when budgets/timeouts were hit

Yes by design. This improves traceability. It’s not “tamper‑proof” (it’s local files), but it helps detect drift and reduces ambiguity.

No. Integrity + evidence provide tamper‑evidence and traceability—not factual correctness. Models can still be wrong; RL4 helps them stay consistent with your project state and constraints.

It proves the payload (and/or evidence pack) wasn’t accidentally modified after generation (via deterministic canonicalization + hashing). It does not prove authorship or “truth”.

Yes. Recompute the checksum from the canonicalized payload and compare it to the included value.

It may hash some files (SHA‑256) for proof signals and track file events. It’s designed to avoid hashing noisy/heavy directories (like `node_modules`, build outputs, VCS dirs) and large/binary assets.

Locally, inside the extension storage. Depending on your plan/mode, RL4 may also store transcripts locally in a content‑addressed store (chunked blobs + index) for XXL cases.

Uninstall the extension and remove its extension storage data. If you enabled local transcript storage/history, deleting extension storage removes that too.

No. Pricing gates local features (modes, retention, evidence depth, mono vs multi‑thread, and time‑range controls). No RL4 account is required for core operation. Think of it as unlocking capabilities inside the extension/CLI while keeping data local‑only.

No by default. If telemetry ever exists, it must be opt‑in and documented.

No RL4 backend is required. You can generate/copy snapshots offline as long as Cursor and your local data are available.

RL4 can use `sqlite3` CLI when available and may fall back to Python’s built‑in sqlite support. If neither is available, use the exported `cursor-aiService.generations.json`.

Because RL4 can only export what Cursor retains locally, and evidence/hash computations are budgeted for performance. Ultra reduces risk (deeper tracking + richer Evidence Pack) but it cannot override Cursor retention. In other words: paying for Ultra increases the *quality and traceability* of what’s available locally—it doesn’t magically recover history Cursor no longer has.

It’s designed to be lightweight. Evidence is budgeted (max time, max bytes, max files/events). The heaviest work happens at snapshot time, not continuously.

- Ensure you’re in a real workspace folder (not an empty window) - Retry scan - Provide an exported `cursor-aiService.generations.json` - Install `sqlite3` or ensure Python is available

- Widen time range - Disable thread filtering (or select the correct threads) - Rescan and regenerate - Check the “history disclaimer” (Cursor retention window)

Tell it explicitly: “Do not modify the package. Read it and use it as context only.”

- Cursor local retention/windowing can limit older history - Evidence is budgeted (may be partial) - Integrity ≠ truth - XXL sessions may require Transcript mode or narrower windows