rethink

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md — vocabulary mapping, domain context
2. Use vocabulary.notes for the notes folder name
3. Use vocabulary.note for the note type name in output
4. Use vocabulary.rethink for the command name in output
5. Use vocabulary.topic_map for MOC references
6. Use vocabulary.cmd_reflect for connection-finding references

1. ops/config.yaml — thresholds, processing preferences
2. self_evolution.observation_threshold: number of pending observations before suggesting rethink (default: 10)
3. self_evolution.tension_threshold: number of pending tensions before suggesting rethink (default: 5)

1. ops/methodology/ — existing methodology notes (read all to understand current system self-knowledge)

If these files don't exist (pre-init invocation or standalone use), use universal defaults.

The command name itself transforms per domain. The derivation manifest maps the universal name to domain-native language. If no manifest exists, use "rethink" as the command name.

EXECUTE NOW

Target: $ARGUMENTS

Parse immediately:

• If target is empty: run full six-phase rethink (Phase 0 drift check + five evidence phases) on all pending observations and tensions
• If target is "triage": run Phase 1 only (triage and methodology updates, no pattern detection)
• If target is "patterns": skip triage, run Phases 3-5 only (analyze existing evidence for patterns)
• If target is "drift": run Phase 0 only (drift check without triage or pattern detection)
• If target is a specific observation or tension filename: triage that single item interactively

START NOW. Reference below defines the six-phase workflow.

Philosophy

The system is not sacred. Evidence beats intuition.

Every rule in the context file, every workflow in a skill, every assumption baked into the architecture was a hypothesis at some point. Hypotheses need testing against reality. Observation notes in ops/observations/ capture friction from actual use. Tension notes in ops/tensions/ capture unresolved conflicts. Rethink first triages these individually (some become {DOMAIN:notes}, some become methodology updates, some get archived), then compares remaining evidence against what the system assumes and proposes changes when patterns emerge.

This is the scientific method applied to knowledge systems: hypothesize, implement, observe, revise.

Without this loop, generated systems ossify — they accumulate friction that never gets addressed, contradictions that never get resolved, and methodology learnings that never get elevated to system-level changes. /rethink is the immune system that prevents calcification.

Phase 0: Drift Check

Rule Zero: ops/methodology/ is the canonical specification of how this system operates. Before triaging observations, check whether the system has drifted from what the methodology says it should do.

0a. Load Methodology State

# Get all methodology notes with their metadata
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  head -20 "$f"  # frontmatter with category, created, updated, status
  echo ""
done

Read all methodology notes fully. Extract:

• Each note's category, created date, updated date, status
• The behavioral assertions each note makes (the "What to Do" sections)

0b. Load System Configuration

Read:

• ops/config.yaml — current configuration state
• The context file (CLAUDE.md) — current behavioral instructions
• ops/derivation-manifest.md — vocabulary and feature state

0c. Compare Across Three Drift Types

Type 1: Staleness

# Compare config.yaml modification time vs newest methodology note
CONFIG_MTIME=$(stat -f %m ops/config.yaml 2>/dev/null || stat -c %Y ops/config.yaml 2>/dev/null || echo 0)
NEWEST_METH=$(ls -t ops/methodology/*.md 2>/dev/null | head -1)
METH_MTIME=$(stat -f %m "$NEWEST_METH" 2>/dev/null || stat -c %Y "$NEWEST_METH" 2>/dev/null || echo 0)

If CONFIG_MTIME > METH_MTIME: config has changed since methodology was last updated. Flag as staleness drift.

Type 2: Coverage Gap

For each active feature in config.yaml (features with enabled: true or features present in the active configuration), check whether a corresponding methodology note exists. Features without methodology coverage represent gaps — the system does things it cannot explain to itself.

Check these feature areas:

• Processing pipeline (is there a methodology note about processing behavior?)
• Maintenance conditions (methodology notes about when maintenance triggers?)
• Session rhythm (methodology notes about session workflow?)
• Domain-specific behaviors (methodology notes about domain vocabulary and patterns?)

Type 3: Assertion Mismatch

For each methodology note that makes a behavioral assertion ("What to Do" section), check:

• Does the context file contain instructions that align with or contradict this directive?
• Does config.yaml contain settings that align with or contradict this directive?
• Are there other methodology notes that contradict this one?

Report: which assertions align, which contradict, which have no corresponding system element.

0d. Create Drift Observations

For each drift finding, create an observation note in ops/observations/:

---
description: [specific drift finding]
category: drift
status: pending
observed: {today's date}
related_notes: ["[[methodology note]]", "[[config element]]"]
---
# [drift finding as prose sentence]

**Drift type:** staleness | coverage-gap | assertion-mismatch
**Methodology note:** [[affected note]]
**System element:** [config.yaml field, context file section, or missing coverage]
**Discrepancy:** [what the methodology says vs what the system does]

Resolution: update methodology note | update system config | flag for human review

0e. Report and Proceed

Output drift status summary:

Drift Check:
  Staleness: [N findings — config changed, methodology not updated]
  Coverage gaps: [N features without methodology notes]
  Assertion mismatches: [N contradictions between methodology and system]
  Total drift observations created: [N]

If drift observations were created, they join the pool of pending observations for Phase 1 triage. Proceed to Phase 1.

Phase 1: Triage

1a. Gather Pending Evidence

OBS_PENDING=$(grep -rl '^status: pending' ops/observations/ 2>/dev/null)
OBS_COUNT=$(echo "$OBS_PENDING" | grep -c . 2>/dev/null || echo 0)
TENSION_PENDING=$(grep -rl '^status: pending\|^status: open' ops/tensions/ 2>/dev/null)
TENSION_COUNT=$(echo "$TENSION_PENDING" | grep -c . 2>/dev/null || echo 0)

Read each pending item fully. These are small atomic notes — load all of them. Understanding the full content is required for accurate triage. If zero pending items, report clean state and exit early.

Also read ops/methodology/ to understand existing methodology notes — this prevents creating duplicates and informs whether new observations should extend existing methodology rather than create new notes.

1b. Classify Each Item

Assign exactly one disposition per observation or tension:

| Disposition | Meaning | When to Apply | Action | |-------------|---------|---------------|--------| | PROMOTE | Reusable insight worth keeping as a permanent {DOMAIN:note} | General principle across sessions. Would work as a claim note. Crystallized insight, not operational guidance. | Create {DOMAIN:note} in {vocabulary.notes}/, set observation status: promoted, add promoted_to: [[title]] | | IMPLEMENT | Operational guidance that should change the system | "System should do X differently." Points to a concrete improvement in context file, template, or skill. | Update the specific file, set status: implemented, add implemented_in: [filepath] | | METHODOLOGY | Friction pattern that should inform agent behavior | Behavi