Next

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md — vocabulary mapping, domain context

   • Use vocabulary.notes for the notes folder name
   • Use vocabulary.inbox for the inbox folder name
   • Use vocabulary.note for the note type name in output
   • Use vocabulary.topic_map for MOC references
   • Use vocabulary.cmd_reduce for process/extract command
   • Use vocabulary.cmd_reflect for connection-finding command
   • Use vocabulary.cmd_reweave for backward-pass command
   • Use vocabulary.rethink for rethink command name

2. ops/config.yaml — thresholds, processing preferences

   • self_evolution.observation_threshold (default: 10)
   • self_evolution.tension_threshold (default: 5)

If these files don't exist, use universal defaults and generic command names.

EXECUTE NOW

INVARIANT: /next recommends, it does not execute. Present one recommendation with rationale. The user decides what to do. This prevents cognitive outsourcing where the system makes all work decisions and the user becomes a rubber stamp.

Execute these steps IN ORDER:

Step 1: Read Vocabulary

Read ops/derivation-manifest.md (or fall back to ops/derivation.md) for domain vocabulary mapping. All output must use domain-native terms. If neither file exists, use universal terms (notes, inbox, topic map, etc).

Step 2: Reconcile Maintenance Queue

Before collecting state, evaluate all maintenance conditions and reconcile the queue. This ensures maintenance tasks are current before the recommendation engine runs.

Read queue file (ops/queue/queue.json or ops/queue.yaml). If schema_version < 3, migrate:

• Add maintenance_conditions section with default thresholds
• Add priority field to existing tasks (default: "pipeline")
• Set schema_version: 3

For each condition in maintenance_conditions:

1. Evaluate the condition:

2. If condition exceeds threshold AND no pending task with this condition_key exists:

Create maintenance task:

TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
MAINT_MAX=$(jq '[.tasks[] | select(.id | startswith("maint-")) | .id | ltrimstr("maint-") | tonumber] | max // 0' ops/queue/queue.json)
NEXT_MAINT=$((MAINT_MAX + 1))

jq --arg id "maint-$(printf '%03d' $NEXT_MAINT)" \
   --arg priority "{priority}" \
   --arg key "{condition_key}" \
   --arg target "{description}" \
   --arg action "{recommended command}" \
   --arg ts "$TIMESTAMP" \
   '.tasks += [{"id": $id, "type": "maintenance", "priority": $priority, "status": "pending", "condition_key": $key, "target": $target, "action": $action, "auto_generated": true, "created": $ts}]' \
   ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json

3. If condition is satisfied AND a pending task with this condition_key exists:

Auto-close it:

TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
jq --arg key "{condition_key}" --arg ts "$TIMESTAMP" \
   '(.tasks[] | select(.condition_key == $key and .status == "pending")).status = "done" |
    (.tasks[] | select(.condition_key == $key and .status == "pending")).completed = $ts' \
    ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json

4. If condition fires AND a pending task already exists:

Update the target description (specifics may have changed):

jq --arg key "{condition_key}" --arg target "{new description}" \
   '(.tasks[] | select(.condition_key == $key and .status == "pending")).target = $target' \
   ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json

Step 3: Collect Vault State

Gather all signals. Run independent checks in parallel where possible. Record each signal even if the check returns zero — absence of signal is itself informative.

Adaptation rules:

• Directory names adapt to domain vocabulary (e.g., {vocabulary.inbox} instead of hardcoded "inbox")
• Skip checks silently for directories that do not exist — do not report "ops/sessions/ not found"
• A missing directory means that feature is not active, which is valid state

Signal collection commands:

# Inbox pressure (adapt path to vocabulary)
INBOX_COUNT=$(find {vocabulary.inbox}/ -name "*.md" -maxdepth 2 2>/dev/null | wc -l | tr -d ' ')
OLDEST_INBOX=$(find {vocabulary.inbox}/ -name "*.md" -maxdepth 2 -exec stat -f "%m %N" {} \; 2>/dev/null | sort -n | head -1)

# Note count
NOTE_COUNT=$(ls -1 {vocabulary.notes}/*.md 2>/dev/null | wc -l | tr -d ' ')

# Pending observations
OBS_COUNT=$(grep -rl '^status: pending' ops/observations/ 2>/dev/null | wc -l | tr -d ' ')

# Pending tensions
TENSION_COUNT=$(grep -rl '^status: pending\|^status: open' ops/tensions/ 2>/dev/null | wc -l | tr -d ' ')

# Unmined sessions
SESSION_COUNT=$(grep -rL '^mined: true' ops/sessions/*.md 2>/dev/null | wc -l | tr -d ' ')

Step 4: Classify by Consequence Speed

Evaluate every signal against consequence speed — how fast does inaction degrade the system?

Threshold rule: 10+ pending observations OR 5+ pending tensions is ALWAYS session-priority. Recommend {DOMAIN:rethink} in this case.

Signal interaction rules:

• Task stack items ALWAYS override automated recommendations (user-set priorities beat system-detected urgency)
• Multiple session-priority signals: pick the one with highest impact (most items affected)
• If inbox pressure AND queue backlog: recommend reducing inbox first (pipeline needs input before it can process)

Step 5: Generate Recommendation

Select the SINGLE most valuable action. The recommendation must be specific enough to execute immediately — a concrete command invocation, not a vague suggestion.

Priority cascade:

1. Task Stack First

If ops/tasks.md has open items, recommend from the task stack. User-set priorities override all automated recommendations because:

• The user has context the system does not
• Ignoring explicit priorities erodes trust
• Task stack items represent deliberate decisions, not automated detection

Format: Recommend the specific task with context about why it was in the stack.

1.5. Session-Priority Maintenance Tasks

Read queue for maintenance tasks with priority: "session" and status: "pending". These represent vault health conditions that degrade THIS session.

Pick the highest-impact one:

• orphan_notes: "{N} notes invisible to traversal"
• dangling_links: "{N} broken links confusing navigation"
• inbox_pressure: "{N} items aging in inbox"

Recommend the action field from the queue entry.

2. Session-Priority Signals

If no task stack items, pick the highest-impact session-priority signal:

When recommending inbox processing: Choose the specific inbox item that aligns best with current goals or has the most connection potential to existing notes. Recommend a concrete file, not "process some inbox."