@accelerationguy/accel 1.0.0

package/modules/ignition/terminal.svg

@@ -0,0 +1,74 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 740 480" width="740" height="480">
+  <!-- Window shadow -->
+  <rect x="4" y="8" width="736" height="472" rx="12" fill="rgba(0,0,0,0.4)"/>
+
+  <!-- Window background -->
+  <rect width="736" height="472" rx="12" fill="#13131f"/>
+
+  <!-- Title bar -->
+  <rect width="736" height="40" rx="12" fill="#1e1e30"/>
+  <rect y="28" width="736" height="12" fill="#1e1e30"/>
+
+  <!-- Traffic lights -->
+  <circle cx="24" cy="20" r="7" fill="#ff5f57"/>
+  <circle cx="48" cy="20" r="7" fill="#febc2e"/>
+  <circle cx="72" cy="20" r="7" fill="#28c840"/>
+
+  <!-- Terminal label -->
+  <text x="368" y="25" text-anchor="middle" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="12" fill="#4a4a6a">Terminal</text>
+
+  <!-- Prompt line -->
+  <text x="24" y="68" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#4a4a6a">~ $ </tspan><tspan fill="#c0c0d8">/ignition</tspan>
+  </text>
+
+  <!-- Ignition logo - green -->
+  <text x="24" y="96"  fill="#4dde80" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ███████╗███████╗███████╗██████╗ </text>
+  <text x="24" y="113" fill="#4dde80" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ██╔════╝██╔════╝██╔════╝██╔══██╗</text>
+  <text x="24" y="130" fill="#3dd870" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ███████╗█████╗  █████╗  ██║  ██║</text>
+  <text x="24" y="147" fill="#3dd870" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ╚════██║██╔══╝  ██╔══╝  ██║  ██║</text>
+  <text x="24" y="164" fill="#28a745" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ███████║███████╗███████╗██████╔╝</text>
+  <text x="24" y="181" fill="#28a745" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13" xml:space="preserve">  ╚══════╝╚══════╝╚══════╝╚═════╝ </text>
+
+  <!-- Name + version -->
+  <text x="24" y="207" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#4dde80" font-weight="bold">Ignition</tspan><tspan fill="#4a4a6a"> v0.1.0</tspan>
+  </text>
+  <text x="24" y="224" fill="#7b8cde" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">Structured Evaluation &amp; Engineering Design</text>
+
+  <!-- Divider -->
+  <line x1="24" y1="238" x2="712" y2="238" stroke="#1e1e30" stroke-width="1.5"/>
+
+  <!-- Greeting -->
+  <text x="24" y="258" fill="#4dde80" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">Ignition loaded.</text>
+
+  <!-- Commands -->
+  <text x="24" y="283" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#c0c0d8">  -</tspan><tspan fill="#4dde80"> Ideate</tspan>
+    <tspan fill="#4a4a6a">    — Shape a new project idea (default)</tspan>
+  </text>
+  <text x="24" y="300" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#c0c0d8">  -</tspan><tspan fill="#4dde80"> Graduate</tspan>
+    <tspan fill="#4a4a6a">  — Move to apps/ with git repo</tspan>
+  </text>
+  <text x="24" y="317" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#c0c0d8">  -</tspan><tspan fill="#4dde80"> Launch</tspan>
+    <tspan fill="#4a4a6a">    — Graduate + initialize Drive</tspan>
+  </text>
+  <text x="24" y="334" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#c0c0d8">  -</tspan><tspan fill="#4dde80"> Status</tspan>
+    <tspan fill="#4a4a6a">    — See projects in the pipeline</tspan>
+  </text>
+  <text x="24" y="351" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#c0c0d8">  -</tspan><tspan fill="#4dde80"> Add Type</tspan>
+    <tspan fill="#4a4a6a">  — Create a custom project type</tspan>
+  </text>
+
+  <!-- Prompt -->
+  <text x="24" y="383" fill="#c0c0d8" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">What are you building?</text>
+
+  <!-- Cursor -->
+  <text x="24" y="420" font-family="'SF Mono','Fira Code','Courier New',monospace" font-size="13">
+    <tspan fill="#4a4a6a">~ $ </tspan><tspan fill="#4dde80">▊</tspan>
+  </text>
+</svg>

package/modules/mission-control/CONTEXT-CONTINUITY-SPEC.md

@@ -0,0 +1,293 @@
+# Context Continuity Protocol — Spec & Planning Doc
+
+A mid-session context refresh system for 1M token Claude Code sessions. Maintains output quality across the full window by synthesizing context at threshold checkpoints, re-injecting critical behavioral rules, and forcing PSMM hygiene — without interrupting the session flow.
+
+---
+
+## The Problem
+
+### Quality Degradation in Long Sessions
+
+Claude Code sessions with 1M token windows experience measurable quality degradation around the 200-250k token mark. This manifests as:
+
+- Drift from established behavioral patterns (CLAUDE.md rules ignored)
+- Forgetting earlier decisions made in the same session
+- Losing the "why" behind current work
+- Repeating mistakes that were already corrected
+- Defaulting to generic behavior instead of personalized patterns
+
+### Why This Happens: Attention and Recency
+
+The context window is not a flat memory. Attention distributes unevenly:
+
+**High attention zones:**
+- System prompt (very beginning of context) — initial CLAUDE.md, system instructions
+- Most recent content (last ~50k tokens) — recent tool results, recent prompts/responses, recent system-reminder injections
+
+**Low attention zone ("the middle"):**
+- Everything between the system prompt and recent content
+- By 200k tokens, the system prompt content is buried under 200k tokens of conversation
+- Decisions, corrections, and context from prompts 1-20 are in the middle by prompt 40
+
+**Key mechanism: Recency creates signal strength.** Content that was recently read (via Read tool), recently injected (via hook), or recently written (in the current response) has stronger influence than content from 100k tokens ago — even if the older content is more important.
+
+**Re-injection does NOT create noise.** Injecting the same content again at a later position in the window creates recency, not duplication. The original copy fades in attention; the new copy replaces it functionally. This is reinforcement, not redundancy.
+
+### Why 200k Token Sessions Worked Well
+
+The previous 200k token session limit was accidentally a feature:
+
+- Forced session handoffs and fresh starts
+- Every new session put CLAUDE.md at the top of a clean window
+- Behavioral rules were always at full attention strength
+- No middle-of-context drift was possible — the session ended before it could happen
+- Users who maintained continuity across 200k sessions got the best output consistently
+
+The 1M window removed this forcing function without replacing it. Sessions now drift past the quality cliff without any mechanism to recover.
+
+---
+
+## The Solution: Context Continuity Protocol
+
+### Overview
+
+At a configurable token threshold (default: 200k tokens used), a hook fires that triggers a structured mid-session context refresh. This is NOT a compaction (which discards context). It's a synthesis — extracting signal from the accumulated context while that context still exists in the window.
+
+### Trigger Conditions
+
+| Condition | Action |
+|-----------|--------|
+| Window size < 500k (e.g., 200k window) | Exit silently — handoffs and resumes handle short windows |
+| Window size >= 500k AND tokens used >= 200k | Fire context continuity protocol |
+| Already fired this session | Track via session file — fire again at next 200k increment (400k, 600k, 800k) |
+
+**Only for 1M+ token windows.** For 200k windows, handoffs and session resumes are the right pattern. This protocol exists because 1M windows need a continuity mechanism that 200k windows got for free from their size constraint.
+
+### Sequence
+
+```
+1. Hook detects threshold crossed (200k tokens used)
+2. Hook injects <context-continuity-trigger> signal
+3. Claude generates Session Continuity Document (SCD)
+4. Claude immediately Reads the SCD back
+5. During Read, Claude checks for inconsistencies
+6. If inconsistencies found: update SCD, re-Read
+7. If gaps exist: explicitly state them, ask operator to fill in
+8. Hook re-injects full CLAUDE.md
+9. PSMM checkpoint: review and log any missed entries
+10. Resume work with refreshed context
+```
+
+---
+
+## Component 1: The Hook
+
+### `context-continuity-hook.py`
+
+**Trigger:** UserPromptSubmit
+**Input:** Context percentage from `input_data.context.tokensUsed` and `tokensRemaining`
+**Logic:**
+
+```python
+WINDOW_THRESHOLD = 500000      # Only fire for windows >= 500k
+CONTINUITY_INTERVAL = 200000   # Fire every 200k tokens used
+SESSION_TRACKER_KEY = "continuity_checkpoints"  # Track in session file
+
+# Calculate tokens used
+tokens_used = total - remaining
+
+# Skip if window is too small
+if total < WINDOW_THRESHOLD:
+    sys.exit(0)
+
+# Check if we've crossed a new 200k boundary
+checkpoint_number = tokens_used // CONTINUITY_INTERVAL  # 0, 1, 2, 3, 4...
+if checkpoint_number < 1:
+    sys.exit(0)  # Haven't hit 200k yet
+
+# Check session file for last completed checkpoint
+last_checkpoint = session.get(SESSION_TRACKER_KEY, 0)
+if checkpoint_number <= last_checkpoint:
+    sys.exit(0)  # Already handled this checkpoint
+
+# Fire the trigger
+# Update session tracker after output
+```
+
+**Output:** Two injections:
+1. `<context-continuity-trigger>` — instructions for generating the SCD
+2. Full CLAUDE.md content re-injection
+
+### CLAUDE.md Re-injection
+
+The full CLAUDE.md is re-injected as-is. No trimming, no summarizing. If the CLAUDE.md is too large for this, the CLAUDE.md needs auditing — not this protocol.
+
+The re-injection puts CLAUDE.md content at the most recent system-reminder position — high attention, maximum behavioral influence. This is the single most impactful part of the protocol for maintaining behavioral consistency.
+
+---
+
+## Component 2: The Session Continuity Document (SCD)
+
+### What It Is
+
+A structured document written by Claude at the 200k checkpoint that synthesizes the session into focused, actionable context. This is NOT a transcript or log. It's a distillation — the signal extracted from 200k tokens of noise (tool outputs, verbose responses, exploratory conversation, dead ends).
+
+### Why Writing + Reading Matters
+
+**Writing** forces Claude to synthesize. The act of generating the document requires reviewing accumulated context and making judgments about what matters. This is valuable but not sufficient.
+
+**Reading it back** is the critical step. A Read tool result arrives as fresh content in a high-attention position. Without the Read-back, the SCD is just something Claude wrote — with it, it's something Claude is actively processing as input. The difference in attention weight is significant.
+
+**The Read also enables self-correction.** During the Read-back, Claude can spot inconsistencies between what it wrote and what it actually knows from context. If a decision was summarized incorrectly or a correction was missed, the Read-back is when Claude catches and fixes it.
+
+### SCD Template
+
+The prompt instructions in the `<context-continuity-trigger>` must produce this exact structure:
+
+```markdown
+# Session Continuity Document
+**Generated at:** [timestamp]
+**Checkpoint:** [1st, 2nd, 3rd, 4th] (at ~[200k, 400k, 600k, 800k] tokens)
+**Session ID:** [uuid]
+
+## Session Intent
+[One paragraph: what did we set out to do this session? What was the opening
+context? Has the intent shifted since session start?]
+
+## Trajectory
+[Chronological key moments — not everything, just the pivots and milestones.
+Format: timestamp-ish → what happened → why it mattered]
+
+## Decisions Made
+[Every decision made this session. Format: decision → rationale → still valid?
+If uncertain about any decision, flag it with ⚠️ for operator confirmation.]
+
+## Corrections Received
+[Every time the operator corrected an approach, assumption, or behavior.
+These are the highest-signal items — they represent calibration.]
+
+## Active Constraints
+[Rules, mandates, or patterns the operator established during this session.
+Example: "parallel build mandate — never modify live files"]
+
+## Current State
+[What's done, what's in progress, what's next. Precise — file paths,
+line numbers, specific status.]
+
+## Open Questions / Gaps
+[Anything uncertain, fuzzy, or assumed. Be honest — if you don't remember
+something clearly, say so. The operator can fill gaps and WILL happily do
+so if it means the next 200k tokens are top quality instead of degraded.]
+
+## PSMM Review
+[Review: were there DECISION/CORRECTION/INSIGHT/COMMITMENT moments that
+should have been logged but weren't? List them. Log them now via
+vector_psmm_log or direct psmm.json edit.]
+```
+
+### SCD Prompting Requirements
+
+The instructions delivered by the hook must be explicit about:
+
+1. **Honesty over completeness.** If Claude doesn't remember something clearly, it must say "I'm uncertain about X — operator should confirm." Fabricating details is worse than admitting gaps, because fabricated details become load-bearing context after the Read-back and will actively mislead the rest of the session.
+
+2. **Corrections are highest priority.** Operator corrections represent calibration — moments where Claude's default behavior was wrong and was fixed. These MUST be captured accurately because they're the most likely things to drift in long sessions.
+
+3. **Chronological trajectory matters.** Not just "here's where we are" but "here's how we got here." The path preserves the *why* behind decisions. Without trajectory, Claude loses the reasoning and may revisit or contradict earlier work.
+
+4. **The Read-back is for verification, not just recall.** During Read-back, Claude should actively check: "Does this match what I know? Did I get any decision wrong? Did I miss a correction?" If inconsistencies are found, update the document immediately and re-Read.
+
+5. **Gaps invite operator participation.** Explicitly listing gaps gives the operator a chance to fill in details that are fuzzy at this point. The operator is present and willing to help — they want the next 200k tokens to be high quality. Flagging gaps is not weakness, it's collaboration.
+
+6. **Max output efficiency, not winging it.** This document needs Claude to think as hard as possible on the first draft. Analyze the full context window. Be precise about file paths, decision rationale, correction details. A sloppy first draft that gets Read back becomes sloppy load-bearing context.
+
+---
+
+## Component 3: PSMM Checkpoint
+
+### Integrated into the SCD
+
+The PSMM review is the last section of the SCD. At the 200k checkpoint, Claude reviews the session for unlogged meta moments:
+
+- **DECISION**: Any architectural or design decisions that weren't logged
+- **CORRECTION**: Any operator corrections to behavior or approach
+- **INSIGHT**: Any realizations about how systems work or should work
+- **COMMITMENT**: Any commitments made to the operator
+
+After identifying unlogged entries, Claude logs them immediately via `vector_psmm_log` or direct `psmm.json` edit. This prevents the "I got too busy executing to log" problem that was identified during the Mission Control Phase 4 session.
+
+---
+
+## Component 4: Checkpoint Cadence
+
+### Multi-checkpoint Sessions
+
+For 1M token sessions, the protocol fires at every 200k increment:
+
+| Checkpoint | Tokens Used | What Happens |
+|-----------|-------------|-------------|
+| 1st | ~200k | Full SCD + CLAUDE.md re-inject + PSMM review |
+| 2nd | ~400k | Updated SCD (references 1st) + CLAUDE.md re-inject + PSMM review |
+| 3rd | ~600k | Updated SCD (references 1st + 2nd) + CLAUDE.md re-inject + PSMM review |
+| 4th | ~800k | Updated SCD + CLAUDE.md re-inject + strong recommendation to wrap up or handoff |
+
+Each subsequent SCD references prior ones. The 2nd checkpoint document says "At 200k we established X, since then we've done Y, and now Z." Layered continuity — each document builds on the last.
+
+At the 4th checkpoint (800k), the protocol should strongly recommend wrapping up or creating a handoff. The last 200k of a 1M window is the lowest-quality zone and the most likely to produce errors.
+
+---
+
+## Implementation Plan
+
+### Files to Create
+
+| File | Purpose |
+|------|---------|
+| `.accel/momentum/hooks/context-continuity.py` | Hook — detects threshold, injects trigger + CLAUDE.md |
+| `.vector/vector.json` (add GLOBAL rule) | Rule instructing Claude how to respond to the trigger |
+| SCD template | Reference for the document structure (embedded in hook output) |
+
+### Settings Integration
+
+Add to `~/.claude/settings.json` UserPromptSubmit hooks. The hook needs:
+- Access to context token data from `input_data`
+- Access to session tracking (via `.vector/sessions/` or `.accel/momentum/data/`)
+- Ability to read and inject CLAUDE.md content
+
+### Configuration
+
+```json
+{
+  "context_continuity": {
+    "enabled": true,
+    "window_minimum": 500000,
+    "interval": 200000,
+    "claudemd_reinject": true,
+    "psmm_checkpoint": true,
+    "scd_path": ".accel/momentum/data/session-continuity/",
+    "max_checkpoints": 4
+  }
+}
+```
+
+---
+
+## Open Questions
+
+1. **SCD storage location.** Should SCDs live in `.accel/momentum/data/session-continuity/{session-id}-checkpoint-{N}.md`? Or in a temp location that gets cleaned up? They're session-specific and potentially useful for post-session review, but could accumulate.
+
+2. **Operator interruption.** Should the protocol pause for operator confirmation before generating the SCD? ("Context refresh checkpoint — ready to generate continuity document?") Or should it fire automatically? Automatic is lower-friction but the operator might be mid-thought.
+
+3. **SCD token cost.** The SCD itself will be ~1-2k tokens to write + ~1-2k tokens in the Read-back + ~500 tokens for CLAUDE.md re-injection + PSMM logging. Total: ~4-5k tokens per checkpoint. Over 4 checkpoints: ~20k tokens. 2% of 1M window for continuity insurance. Worth it, but should be measured.
+
+4. **Interaction with context compaction.** If Claude Code's automatic compaction fires before the 200k threshold, the hook might not see accurate token counts. Need to understand how compaction affects the `tokensUsed` / `tokensRemaining` values in hook input data.
+
+5. **Multi-session continuity.** If a session with a checkpoint 1 SCD gets `--continue`'d into a new session, should the new session's first checkpoint reference the prior session's SCD? This could bridge session boundaries.
+
+---
+
+## Why This Matters
+
+The 1M token window is a capability that currently degrades into a liability past 200k tokens. Most users don't know their output quality is dropping — they just notice "Claude seems dumber" in long sessions and restart. The Context Continuity Protocol turns the full 1M window into usable, high-quality context by applying the same hygiene that 200k sessions enforced by constraint.
+
+This is context engineering at the infrastructure level — not prompt tricks, not workarounds, but a system that maintains the quality contract between the AI and the operator across the full session lifecycle.

package/modules/mission-control/CONTEXT-ENGINEERING-GUIDE.md

@@ -0,0 +1,282 @@
+# Context Engineering Guide — Vector + Mission Control Ecosystem
+
+Hard-won insights from building and tuning a context reinforcement layer for Claude Code across 40+ prompt sessions, measured with real token data and honest compliance reporting.
+
+---
+
+## Framework Token Cost
+
+| Signal | Per-prompt tokens | Notes |
+|--------|------------------|-------|
+| `<vector-rules>` full injection | ~2,000 | 15 rules + 5 decisions + devmode + available domains |
+| `<vector-status>` dedup signal | ~72 | Fires ~80% of prompts |
+| `<active-awareness>` | ~600 | 12 items with status/blocked/deadline |
+| `<backlog-awareness>` | ~400 | 9 items with review_by |
+| `<base-pulse>` | ~50 | Drift score + stale areas |
+| `<decisions>` summary | ~80 | Domain counts, not full text |
+| `<calendar>` | ~100 | Today's events |
+| `<current-time>` | ~50 | Timestamp |
+| `<machine>` | ~30 | Workstation context |
+| `📊 Context` | ~15 | Token usage % |
+| **Total (full inject)** | **~3,400** | 0.34% of 1M window |
+| **Total (dedup prompt)** | **~1,400** | 0.14% of 1M window |
+
+**Over a 30-prompt session:** ~50,000 tokens total injection. 5% of 1M window.
+
+**Verdict:** Very low overhead, very high upside. The entire framework costs less than a single large file read.
+
+---
+
+## DEVMODE — What It Is and Why It Matters
+
+DEVMODE is a compact debug section appended to every response. It serves one purpose: **show the user which parts of their context ecosystem shaped the AI's understanding and response.**
+
+**Why it exists:**
+- The user can't see what the AI received or how it processed context signals
+- Without visibility, tuning Vector rules is guesswork
+- DEVMODE closes the feedback loop between context engineering and observed AI behavior
+
+**What it reports:**
+- Which Vector domains injected this prompt (or dedup status)
+- Total rules/decisions received vs. how many actually influenced the response
+- Which context signals (pulse, active, backlog, calendar, etc.) shaped behavior
+- Tools used and gaps identified
+
+**What it costs:** ~450 tokens on full injection, ~0 on dedup prompts (instruction is in prior context). Across a session: ~3,700 tokens total. 0.37% of 1M window.
+
+**Format — keep it under 8 lines:**
+```
+🔧 Vector DEVMODE
+Vector: [injected domains + rule count, or 'dedup (prompt N)']
+Rules: [total] | applied: [count + citations, or 0]
+Decisions: [total] | applied: [count, or 0]
+Signals: [tags received]
+Applied: [which signals shaped response, or 'none']
+Tools: [tools used, or 'none']
+Gaps: [one-line, or 'none']
+```
+
+---
+
+## Vector Domain Best Practices
+
+### Rule Count Sweet Spot
+
+| Domain type | Max rules | Why |
+|-------------|----------|-----|
+| GLOBAL (always-on) | 9 | Fires every prompt. Each rule competes for attention. After ~9, later rules get diminished compliance. |
+| Workflow domains (DEVELOPMENT, PROJECTS, BACKLOG) | 7-9 | Broader scope but still focused. Benefits from contextual loading. |
+| Project domains (CASEGATE, HUNTER-EXOTICS) | 3-5 | Narrow context. Mostly decisions, few rules needed. |
+
+**9 is the cutoff.** Not 10, not 12, not 15. If a domain has more than 9 rules, split it or move lower-priority rules to a more specific domain where they fire contextually.
+
+**Front-load important rules.** Rules 0-4 get the strongest compliance. Put your highest-value, most-violated rules first. The tail end of any rule list gets progressively less attention.
+
+### Writing Effective Rules
+
+**Brief. Explicit. One sentence.**
+
+| Pattern | Example | Compliance |
+|---------|---------|------------|
+| Short + absolute | "NEVER create browser alert dialogs — use modals" | Near-perfect |
+| Short + specific trigger | "Before CSS changes, verify element classes in markup first" | High |
+| Medium + conditional | "When drift score is 15+, recommend grooming" | Good |
+| Long + judgment-dependent | "When a significant meta moment occurs, log it via PSMM..." | Inconsistent |
+
+**Rules that work:**
+- One clear action
+- Obvious trigger (when does this apply?)
+- No judgment calls (what counts as "significant"?)
+- Strong language for critical rules (NEVER, ALWAYS, NON-NEGOTIABLE)
+
+**Rules that drift:**
+- Multiple conditions in one rule
+- Require the AI to assess "significance" or "relevance"
+- Paragraph-length explanations baked into the rule text
+- Vague triggers ("when appropriate", "if needed")
+
+**Fix for complex rules:** Write the rule as one line, reference a spec file for details.
+
+Bad:
+```
+PSMM keeps session context hot. When a significant meta moment occurs
+(design decision, user correction, context shift, key insight, commitment
+made), use vector_psmm_log(session_id, type, text) where type is
+DECISION|CORRECTION|SHIFT|INSIGHT|COMMITMENT. If vector_psmm_log is not
+available, fall back to editing psmm.json directly...
+```
+
+Good:
+```
+Log significant meta moments via vector_psmm_log — see PSMM spec for types and criteria
+```
+
+### The Anti-Pattern Hack (Near-Perfect Adherence)
+
+**Negative framing with absolute language gets near-perfect compliance.**
+
+```
+NEVER create browser alert dialogs — ALWAYS use modals
+NEVER use framer-motion — ALWAYS use motion package
+NEVER use CSS linear-gradient for dark backgrounds
+NEVER mark tasks complete without validation
+```
+
+Why this works: The wrong action is unambiguous. There's no judgment call. The AI can check its own output against the rule with zero interpretation. It's a binary — did I do the forbidden thing or not?
+
+**Compare to positive framing:**
+```
+Use modals for user notifications (compliance: good, not perfect)
+Prefer motion package over framer-motion (compliance: moderate — "prefer" leaves room)
+Consider using solid backgrounds instead of gradients (compliance: weak — "consider" is ignorable)
+```
+
+**The pattern:** `NEVER [wrong action] — ALWAYS [right action]`
+
+If you can frame a rule as "never do X," it will be followed more reliably than "always do Y." Prohibition is clearer than prescription.
+
+### Recall Phrase Best Practices
+
+**Use natural phrases, not single keywords.**
+
+Bad:
+```
+DEVELOPMENT_RECALL=code,build,fix,create
+```
+These fire on almost everything. "Fix" matches "fix this bug" but also "fix the strategy doc." Single keywords create false positives.
+
+Good:
+```
+DEVELOPMENT_RECALL=write code for,fix this bug,implement this feature,build this component,refactor this,programming task
+```
+
+**Write phrases the user would actually say.** Not technical triggers, not file names — natural language as spoken.
+
+**Multi-word phrases prevent false positives.** "check skool" won't false-fire on "check the schedule." "fix this bug" won't false-fire on "fix the strategy."
+
+**If two domains could match the same phrase, make one more specific.** CONTENT and SKOOL could both match "skool" — so CONTENT excludes it: `CONTENT_EXCLUDE=content backlog,post backlog`
+
+### Context Dedup Tuning
+
+**Force full re-injection every 5 prompts** (not 10). At 10, rules drift ~30k tokens back in context. At 5, they stay within ~15k tokens — better reinforcement with negligible cost (~400 extra tokens per session).
+
+```python
+FORCE_EMIT_EVERY_N = 5
+```
+
+The dedup system only suppresses when the context signature (bracket + devmode + loaded domains) is unchanged. Any domain change triggers immediate full injection regardless of the interval.
+
+---
+
+## Key Insight: Contextual Loading > Always-On Bloat
+
+A rule that fires **only when relevant** hits harder than one that's **always there.** GLOBAL rules become background noise over time. Domain-matched rules arrive at the moment of action.
+
+If a rule only matters during coding, put it in DEVELOPMENT. If it only matters when managing projects, put it in PROJECTS. Reserve GLOBAL for truly universal behaviors that must apply to every single prompt regardless of context.
+
+**The test:** "Does this rule need to influence my response when the user asks about their calendar?" If no, it's not GLOBAL.
+
+---
+
+## The Optimal Vector Setup — Target Token Budget
+
+### The Problem
+
+The current framework token cost table shows raw per-prompt numbers, but doesn't answer: **what's the ideal setup that maximizes impact per token?** We need a target mean token usage for a 20-prompt session that represents the best-engineered Vector configuration.
+
+### Variables to Optimize
+
+| Variable | Current | Target | Why |
+|----------|---------|--------|-----|
+| GLOBAL rules | 15 | 9 | Past 9, later rules get diminished compliance |
+| GLOBAL rule length | Mixed (1-5 lines) | 1 line each | Short + absolute = highest compliance |
+| Dedup interval | 5 prompts | 5 prompts | Good balance — rules stay within ~15k tokens |
+| Domains per prompt (avg) | 1 (GLOBAL only) | 1.5 (GLOBAL + 1 matched ~50% of time) | Contextual rules fire when relevant |
+| Rules per matched domain | 8-13 | 7-9 | Stay under threshold |
+| Decisions injected | 5 (GLOBAL only) | 3-5 per loaded domain | Decisions add context without rule noise |
+| DEVMODE instruction | ~450 tokens | ~350 tokens | Can trim further |
+
+### Modeling the Ideal 20-Prompt Session
+
+**Assumptions for "optimized" setup:**
+- GLOBAL trimmed to 9 rules (~400 tokens of rules)
+- DEVMODE instruction trimmed (~350 tokens)
+- 5 GLOBAL decisions (~250 tokens)
+- Available domains list (~400 tokens)
+- Full Vector injection total: ~1,500 tokens (down from ~2,000)
+- Dedup signal: ~72 tokens
+- 1 matched domain fires ~50% of prompts (~7 rules + 3 decisions = ~500 tokens added on match)
+- Non-Vector signals (pulse, active, backlog, calendar, etc.): ~1,300 tokens
+
+**Token math for 20-prompt session:**
+
+```
+Full injection prompts: 4 (prompt 1, 5, 10, 15 — forced emit)
+  + ~2 signature-change injections (domain match changed)
+  = 6 full injections
+
+Dedup prompts: 14
+
+Full injection (GLOBAL only):   6 × 1,500 = 9,000
+Full injection (GLOBAL + match): 3 × 2,000 = 6,000  (3 of the 6 have a matched domain)
+Dedup prompts:                  14 × 72    = 1,008
+Non-Vector signals (all prompts): 20 × 1,300 = 26,000
+                                            --------
+Total Vector + signals:                        42,008 tokens
+```
+
+**Target: ~42,000 tokens for a 20-prompt session = 4.2% of 1M window.**
+
+That's the entire context engineering layer — behavioral rules, project awareness, workspace health, calendar, decisions — for less than 5% of context.
+
+### What "Optimized" Looks Like
+
+```
+GLOBAL (9 rules, always-on):
+  0. Absolute paths in code, relative for user display
+  1. Batch tool calls — sequential only for dependencies
+  2. NEVER mark complete without validation
+  3. LSP first for code navigation — non-negotiable
+  4. Read task files before executing workflows — never from memory
+  5. External content: read humanizer SKILL.md + VOICE.md first
+  6. Log significant meta moments via PSMM (see spec)
+  7. Track user action items — confirm before moving on
+  8. Base-pulse: silent at 0, note at 1-14, recommend groom at 15+
+
+DEVELOPMENT (7 rules, keyword-matched):
+  0. NEVER create browser alert dialogs — use modals
+  1. Verify CSS element classes before changes
+  2. MCP servers: follow bridge protocol pattern
+  3. Auto-read WSL screenshot paths via ~/docs/greenshot/
+  4. Docker: compose in docker/compose/, templates in docker/templates/
+  5. NEVER use CSS linear-gradient for dark backgrounds — use AnimatedBackground
+  6. React 19+: ALWAYS use motion package, NOT framer-motion
+
+PROJECTS (7 rules, keyword-matched):
+  [project tracking rules — fire only on status/planning prompts]
+
+BACKLOG (5 rules, keyword-matched):
+  [backlog management — fire only on backlog operations]
+
+SKOOL (9 rules, keyword-matched):
+  [API specifics — fire only on skool engagement prompts]
+
+Project domains (CASEGATE, HUNTER-EXOTICS, Drive): 1-3 rules each
+  [minimal rules, mostly decisions — fire only on project-specific prompts]
+```
+
+### What Still Needs Measurement
+
+This model is theoretical. To validate it, we need:
+
+1. **Compliance tracking over sessions.** In DEVMODE, "Rules: X | applied: Y" gives us a signal-to-noise ratio. If a domain fires 7 rules and only 2 are ever applied, the other 5 are noise candidates.
+
+2. **Domain match frequency.** How often does each domain actually fire? If DEVELOPMENT fires 80% of sessions but OBSIDIAN fires 5%, the token investment in OBSIDIAN rules is disproportionate.
+
+3. **Rule-level hit rate.** Which specific rules get cited in "applied" most often? Those are the load-bearing rules. Which never get cited? Those are demotion candidates.
+
+4. **Optimal dedup interval.** We moved from 10 to 5 based on reasoning. Need to measure whether compliance actually improves at 5 vs 10 vs 3.
+
+5. **Session-level token audit.** Run a full session with DEVMODE on, export all system-reminder content, count actual tokens consumed by the framework. Compare to the theoretical model.
+
+**This data comes from using DEVMODE honestly over multiple sessions and tracking patterns.** The guide will evolve as measurement catches up to theory.