feat: watcher fault isolation (ADR-002), nightly consolidation, migration --review, prompt versioning

Watcher hardening:
- Event handlers catch exceptions — one bad file never stalls the indexer
- vec0 writes use delete-then-insert (virtual tables don't support OR REPLACE)
- ADR-002 documents the design decision and extensibility pattern

Nightly consolidation:
- run_nightly() — lightweight daily pass, UPDATE/SUPERSEDE only
- NightlyConfig in config with lookback_days and allowed_ops
- palinode consolidate --nightly (CLI + API)
- Dedicated nightly-consolidation.md prompt

OpenClaw migration:
- Scoring-based type detection (heading weighted 3x over body)
- --review flag for interactive type confirmation before writing
- review_callback for programmatic use

Prompt versioning:
- palinode prompt list/show/activate CLI commands
- API endpoints for prompt management
- Frontmatter-based versioning with active flag

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: Paul Kyle

ADR-001-tools-over-pipeline.md

@@ -0,0 +1,72 @@
+# ADR-001: Tools Over Pipeline
+
+**Status:** Accepted
+**Date:** 2026-04-01
+**Context:** Claude Mythos announcement, Nate B Jones "compensating complexity" framework
+
+## Decision
+
+Palinode's primary value is its **17 MCP tools + file-based storage + git versioning**, not its 4-phase injection pipeline. The pipeline is scaffolding for current models. The tools survive any model upgrade.
+
+## Context
+
+Nate B Jones' framework distinguishes:
+- **Outcome specs** — what you want (survives model upgrades)
+- **Procedures** — how to do it (breaks on model upgrades)
+- **Tools** — capabilities the model can use (survives)
+- **Compensating complexity** — workarounds for model limitations (disposable)
+
+Applied to Palinode:
+
+### What survives any model
+- `palinode_search` — find relevant memories
+- `palinode_save` — store typed memories
+- `palinode_session_end` — capture session outcomes
+- `palinode_list/read` — browse the memory directory
+- `palinode_diff/blame/rollback/push` — git operations
+- `palinode_history/timeline` — file-level provenance
+- `palinode_trigger` — prospective recall
+- `palinode_entities` — entity graph
+- `palinode_consolidate` — trigger compaction
+- `palinode_lint` — structural health checks
+- `palinode_ingest` — capture from URLs
+- `palinode_status` — system health
+- Deterministic executor (validates LLM output, applies ops)
+- Markdown files as source of truth
+- Git versioning
+- Security scanning (business rule)
+
+### What's compensating complexity (today's scaffolding)
+- 4-phase auto-injection (Phase 1-4) — compensates for models that don't know to search
+- Trivial message skip list — compensates for models that can't judge query relevance
+- Layer split keyword heuristics — compensates for models that can't classify by content
+- `json_repair` — compensates for models that output malformed JSON
+- Explicit JSON format instructions in compaction prompt — same
+
+## Consequences
+
+### Positioning
+Lead with: "17 tools + a memory directory your agent uses however it wants."
+Not: "4-phase injection pipeline."
+
+The pipeline is an implementation detail. The tools are the interface.
+
+### Architecture evolution
+1. **v0.5 (now):** Pipeline + tools. Pipeline does automatic injection. Tools available for explicit use.
+2. **v1.0:** Pipeline becomes optional/configurable. Default to tools-first for capable models. Pipeline as fallback.
+3. **v2.0:** Tools-only mode. Model decides what to retrieve, when to consolidate. Pipeline removed or opt-in legacy.
+
+### What stays regardless of version
+- MCP tool interface (the API contract)
+- File-based storage (markdown + git)
+- Deterministic executor (LLM proposes, executor disposes)
+- Security guardrails
+- `core: true` flagging (user intent, not model workaround)
+
+### What to audit on each model upgrade
+Run the compaction pipeline with prompt sections deleted. Measure what gets worse vs what stays the same. Remove what the new model makes unnecessary.
+
+## References
+- Nate B Jones, "Every workaround you built for the last model is now breaking the next one" (April 2026)
+- Internal design discussion on tools-first architecture
+- Cursor's Planner-Worker-Judge convergence (same structural pattern across Anthropic, DeepMind, OpenAI)

ADR-002-watcher-fault-isolation.md

@@ -0,0 +1,82 @@
+# ADR-002: Fault Isolation in the Indexing Layer
+
+**Status:** Accepted
+**Date:** 2026-04-06
+**Deciders:** Paul Kyle
+
+## Decision
+
+Palinode's indexing layer treats every file event as an independent unit of work. A failure to index one file must never prevent indexing of subsequent files. Database write operations against SQLite virtual tables (`vec0`, `fts5`) use explicit delete-then-insert rather than relying on conflict-resolution clauses.
+
+## Motivation
+
+Palinode's value proposition depends on a simple invariant: **if a file exists in `PALINODE_DIR`, it is searchable.** The file watcher daemon is the component responsible for maintaining this invariant. It runs unattended, often as a systemd service, processing file events indefinitely.
+
+Daemons that process streams of independent events have a well-known fragility: if one event raises an unhandled exception, the processing thread dies while the main process stays alive. The system appears healthy — the PID exists, the port responds, the service status is green — but no new work is being done. This is the worst class of failure because it is **silent and persistent**.
+
+The indexing layer must therefore be designed around two principles:
+
+1. **Event isolation** — each file event is processed in its own error boundary
+2. **Defensive writes** — database operations use patterns that work reliably across all SQLite table types, including virtual tables with non-standard semantics
+
+## Design
+
+### Event isolation
+
+Every watchdog event handler wraps its processing in a catch-all that logs and continues:
+
+```
+on_modified / on_created → try _process_file() except log + continue
+on_deleted              → try delete_chunks() except log + continue
+```
+
+A failed file is skipped. It will be retried automatically on the next modification, or manually via `palinode ingest`. The invariant is temporarily broken for that one file but holds for everything else.
+
+### Defensive virtual table writes
+
+SQLite virtual tables implement their own storage engines via `xUpdate`. The SQLite documentation notes that virtual tables "may or may not" support conflict resolution in INSERT statements. In practice:
+
+- **`vec0`** (sqlite-vec) does not reliably handle `INSERT OR REPLACE` — it can raise a UNIQUE constraint error on an existing primary key instead of replacing the row
+- **`fts5`** has similar limitations with external-content tables
+
+The safe pattern for any virtual table upsert:
+
+```sql
+DELETE FROM virtual_table WHERE id = ?;   -- no-op if absent
+INSERT INTO virtual_table (id, ...) VALUES (?, ...);
+```
+
+This is two statements instead of one. The cost is negligible — embedding generation dominates the write path by orders of magnitude.
+
+### Extensibility
+
+These patterns apply to any new index type added to Palinode. If a future version adds a graph index, a keyword index, or a secondary vector store, the same rules hold:
+
+- Wrap writes in the event handler's error boundary (already provided by the catch-all)
+- Use delete-then-insert for any virtual table or extension-managed storage
+- Use `INSERT OR REPLACE` only for regular SQLite tables where it is guaranteed
+
+No per-index error handling is needed in calling code — the event boundary catches everything.
+
+## Trade-offs
+
+| | Benefit | Cost |
+|---|---|---|
+| **Event isolation** | One bad file never stalls the daemon | A persistently failing file logs on every modification until root-caused |
+| **Delete-then-insert** | Works on all table types, past and future | One extra statement per write (negligible) |
+| **Catch-all in handlers** | Maximum availability | Broad exception handling can mask programming errors in development |
+
+The catch-all is acceptable because the watcher is a **production daemon**, not application logic. Availability takes priority over fail-fast. Errors are always logged with the file path and exception, so they remain debuggable.
+
+## Consequences
+
+- The indexing layer is resilient by default — new indexes inherit fault isolation without additional code
+- Watcher logs contain structured error lines for any failed file, enabling monitoring and alerting
+- The `chunks`, `chunks_fts`, and `chunks_vec` write paths are now consistent in their error-handling strategy
+- No schema changes or migrations required
+
+## References
+
+- [SQLite Virtual Table Interface — xUpdate](https://www.sqlite.org/vtab.html#xupdate)
+- [sqlite-vec](https://github.com/asg017/sqlite-vec) — the `vec0` virtual table extension
+- [watchdog](https://github.com/gorakhargosh/watchdog) — filesystem event library

examples/CLAUDE.md

@@ -30,3 +30,7 @@ This project uses Palinode for persistent memory (MCP server: palinode).
 - Raw code (git handles that)
 - Step-by-step debug logs (save the resolution, not the journey)
 - Trivial changes ("fixed typo" — not worth a memory)
+
+### If MCP is not connected:
+- Use CLI equivalents: `palinode search "query"`, `palinode save "content" --type Decision`
+- Check connection: `palinode status` or `palinode_status()`