verify

## Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. **`ops/derivation-manifest.md`** — vocabulary mapping, platform hints
   - Use `vocabulary.notes` for the notes folder name
   - Use `vocabulary.note` / `vocabulary.note_plural` for note type references
   - Use `vocabulary.verify` for the process verb in output
   - Use `vocabulary.topic_map` for MOC references
   - Use `vocabulary.templates` for the templates folder path
   - Use `vocabulary.cmd_reflect` for redirect when missing connections found

2. **`ops/config.yaml`** — processing depth, verification settings
   - `processing.depth`: deep | standard | quick
   - `processing.verification.description_test`: true | false
   - `processing.verification.schema_check`: true | false
   - `processing.verification.link_check`: true | false

If these files don't exist, use universal defaults.

**Processing depth adaptation:**

| Depth | Verification Behavior |
|-------|-----------------------|
| deep | Full verification: cold-read prediction, complete schema check, exhaustive link verification, MOC coverage, orphan risk analysis, content staleness detection, bundling analysis |
| standard | Balanced: cold-read prediction, schema check, link verification, MOC coverage |
| quick | Basic: schema check, link verification only. Skip cold-read prediction and health analysis |

## EXECUTE NOW

**Target: $ARGUMENTS**

Parse immediately:
- If target contains a note name: verify that specific note
- If target contains `--handoff`: output RALPH HANDOFF block at end
- If target is "all" or "recent": verify recently created/modified notes
- If target is empty: ask which note to verify

## Anti-Shortcut Warning

Before marking verification as passed, you MUST complete ALL four categories:

1. COMPLETE description quality test — cold-read the title + description,
   predict what the note contains, compare against actual content.
   A description that merely restates the title FAILS.

2. COMPLETE schema validation — check ALL required fields from the
   template schema, verify ALL enum values are valid, confirm ALL
   constraints are met. A single missing required field FAILS.

3. COMPLETE link verification — confirm ALL wiki links in the note
   resolve to existing files. A single dangling link FAILS.

4. COMPLETE {DOMAIN:topic map} integration — verify the note appears in at least
   one {DOMAIN:topic map}'s Core Ideas section with a context phrase.
   A note with no {DOMAIN:topic map} mention FAILS.

Do NOT declare success after checking only one or two categories.
ALL FOUR must pass.

**Execute these steps IN ORDER:**

### Step 0: INDEX FRESHNESS CHECK

Before any retrieval tests, verify the semantic search index is current:

1. Try `mcp__qmd__vector_search` with a simple test query to confirm MCP availability
2. If MCP is unavailable (tool fails or returns error), try qmd CLI (`qmd status`) to confirm local CLI availability
3. If either MCP or qmd CLI is available, proceed to Step 1
4. If neither MCP nor qmd CLI is available: note "retrieval test will be deferred" and proceed — do NOT let index issues block verification

The index freshness check prevents false retrieval failures on recently created notes. If the index is stale, retrieval test results should be interpreted with that context.

### Step 1: RECITE (cold-read prediction test)

**CRITICAL: Do NOT read the full note yet. Only read frontmatter.**

This step tests whether the title + description alone enable an agent to predict the note's content. The cold-read constraint is the entire point — reading the note first contaminates the prediction.

**1. Read ONLY title + description**

Use Read with a line limit to get just the first few lines of frontmatter. Extract:
- Title (the filename without .md)
- Description (the description field)

Do NOT scroll past the frontmatter closing `---`.

**2. Form prediction**

Before reading further, write out what you expect:
- Core argument: what claim does this note make?
- Mechanism: what reasoning or evidence does it use?
- Scope: what boundaries does the argument have?
- Likely connections: what other notes would it reference?

Write this prediction explicitly in your output. It must be specific enough to be wrong.

**3. Read full note content**

NOW read the complete note. Compare against your prediction.

**4. Score prediction accuracy (1-5)**

| Score | Meaning | Threshold |
|-------|---------|-----------|
| **5** | Perfect — description fully captured the argument | Pass |
| **4** | Strong — minor details missed, core predicted | Pass |
| **3** | Adequate — general area right, missed key aspects | Pass (minimum) |
| **2** | Weak — significant mismatch between prediction and content | FAIL |
| **1** | Failed — note argued something different than expected | FAIL |

**Passing threshold: 3 or above.**

**5. Run semantic retrieval test**

Test whether the description enables semantic retrieval:

- Tier 1 (preferred): `mcp__qmd__vector_search` with query = "[the note's description text]", collection = "{vocabulary.notes_collection}", limit = 10
- Tier 2 (CLI fallback): `qmd vsearch "[the note's description text]" --collection {vocabulary.notes_collection} -n 10`
- Tier 3: if both MCP and qmd CLI are unavailable, report "retrieval test deferred (semantic search unavailable)" — do NOT skip silently

Check where the note appears in results:
- Top 3: description works well for semantic retrieval
- Position 4-10: adequate but could improve
- Not in top 10: flag — description may not convey the note's meaning

**Why vector_search specifically:** Agents find notes via semantic search during reflect and reweave. Testing with keyword search tests the wrong retrieval method. Full hybrid search with LLM reranking compensates for weak descriptions — too lenient. vector_search tests real semantic findability without hiding bad descriptions behind reranking.

**6. Draft improved description if needed