ultimate-pi 0.1.2 → 0.1.3

package/vault/wiki/entities/gsd-get-shit-done.md

@@ -0,0 +1,56 @@
+---
+type: entity
+entity_type: project
+title: "GSD (Get Shit Done)"
+created: 2026-05-05
+updated: 2026-05-05
+tags:
+  - gsd
+  - spec-driven-development
+  - meta-prompting
+  - claude-code
+  - agent-harness
+related:
+  - "[[gsd-github-repo]]"
+  - "[[gsd-codecentric-deep-dive]]"
+  - "[[gsd-hn-discussion]]"
+  - "[[Research: how GSD fits into our coding harness setup]]"
+---
+
+# GSD (Get Shit Done)
+
+## What It Is
+A lightweight meta-prompting, context engineering, and spec-driven development system by TÂCHES (@glittercowboy). 60.1K GitHub stars, MIT License, v1.40.0 (May 2026).
+
+## Core Insight
+Fights context rot by externalizing project state into files (`.planning/`) and executing each task in a fresh subagent context window. The orchestrator remains light; all heavy work happens in spawned subagents.
+
+## Architecture
+- **59 slash commands** (consolidated from 86 in v1.40)
+- **33 subagents** for research, planning, execution, verification
+- **Node.js CLI helper** (`gsd-tools.cjs`) for deterministic operations
+- **TypeScript SDK** (`gsd-sdk`) for headless automation
+- **15+ supported runtimes:** Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Cursor, Windsurf, Antigravity, Augment, Trae, Qwen Code, Hermes Agent, Cline, CodeBuddy
+
+## Pipeline: discuss → plan → execute → verify → ship
+1. **Discuss:** Shape implementation preferences (CONTEXT.md)
+2. **Plan:** Research + create atomic task plans + verify (RESEARCH.md, PLAN.md)
+3. **Execute:** Run plans in waves (parallel where independent), commit atomically
+4. **Verify:** Manual user acceptance testing, automated diagnosis
+5. **Ship:** Create PR from verified work
+
+## Key Patterns
+- **Filesystem as message bus:** All agent communication through `.planning/` files
+- **Fresh context per task:** Each executor gets a clean 200K context window
+- **Deterministic logic in code:** `gsd-tools.cjs` for operations LLMs do unreliably
+- **Model profiles:** quality/balanced/budget/inherit — tiered model selection per agent type
+
+## Limitations (from community feedback)
+- Token-heavy — burns through Claude Max limits quickly
+- Slow compared to native plan mode
+- Degrades on large existing codebases
+- Difficult to pivot mid-phase
+- Verification uses simple lexical tools, not AST-aware analysis
+
+## Relationship to Our Harness
+GSD is **downstream** — it builds applications. Our harness is **upstream** — it controls agent behavior before code generation. They address different layers of the agentic coding stack. See [[Research: how GSD fits into our coding harness setup]].

package/vault/wiki/entities/javascript-runtimes.md

@@ -0,0 +1,48 @@
+---
+type: entity
+status: developing
+tags:
+  - javascript
+  - runtimes
+  - nodejs
+  - deno
+  - bun
+related:
+  - "[[ts-runtimes-comparison-betterstack]]"
+  - "[[Research: TypeScript Best Practices and Codebase Structure]]"
+created: 2026-05-02
+updated: 2026-05-02
+
+---# JavaScript Runtimes (Node.js, Deno, Bun)
+
+Three major JavaScript/TypeScript runtimes for server-side development, as of 2026.
+
+## Node.js
+
+- **Established**: 2009, V8 engine, OpenJS Foundation
+- **TS support**: Experimental (`--experimental-strip-types`), limited to inline type annotations
+- **Performance**: Slowest (13K req/s Express benchmark)
+- **Ecosystem**: Largest — 2M+ npm packages
+- **Best for**: Production stability, broad deployment support, largest talent pool
+
+## Deno
+
+- **Released**: 2020, created by Node.js original author (Ryan Dahl), Rust + V8
+- **TS support**: First-class, auto-transpiles, REPL supports TS
+- **Performance**: Mid-tier (22K req/s)
+- **Key differentiator**: Security-first with permissions model and sandbox. Best built-in tooling (linter, formatter, test runner, REPL).
+- **Best for**: Security-sensitive applications, teams that want integrated tooling
+
+## Bun
+
+- **Released**: 2021, Zig + JavaScriptCore (WebKit)
+- **TS support**: First-class, auto-transpiles
+- **Performance**: Fastest (52K req/s) — designed as drop-in Node.js replacement
+- **Key differentiator**: Speed, built-in SQLite, binary lockfile, dual CJS/ESM support
+- **Best for**: Performance-critical applications, new greenfield projects
+
+## Decision Framework
+
+- **Stay with Node.js** if you have existing production systems — features from Bun/Deno are being backported
+- **Choose Bun** for new projects where raw performance and built-in SQLite matter
+- **Choose Deno** if security and integrated tooling are top priorities

package/vault/wiki/entities/jesse-vincent.md

@@ -0,0 +1,38 @@
+---
+type: entity
+status: active
+created: 2026-05-05
+tags:
+  - person
+  - creator
+  - open-source
+related:
+  - "[[superpowers-github-repo]]"
+  - "[[superpowers-release-blog]]"
+  - "[[superpowers-methodology]]"
+---
+
+# Jesse Vincent
+
+Creator of Superpowers (`obra/superpowers`). Founder of Prime Radiant.
+
+## Background
+- Created Request Tracker (RT) in the 1990s — widely-used open-source ticketing system
+- Managed Perl 6 development (2005-2008)
+- Co-founded Keyboardio (hardware company)
+- Built K-9 Mail for Android, later acquired by Mozilla and rebranded as Thunderbird for Android
+- The thread: builds infrastructure others rely on, obsesses over workflow
+
+## Contribution to Agent Skills
+Created Superpowers in October 2025 as a response to AI coding agents being capable but undisciplined. The framework grew from practical experience using Claude Code for serious development. Identified that agents respond to structure and explicit step-by-step workflows — not verbal best-practice advice.
+
+Key innovations:
+- Hard-gate enforcement in skills (not suggestions)
+- Subagent-driven development with fresh context per task
+- TDD for skills (pressure-test skills with subagents under realistic scenarios)
+- Cross-agent skill portability via plain Markdown
+
+Superpowers reached 179K GitHub stars by May 2026 and was accepted into Anthropic's official Claude Code plugin marketplace in January 2026.
+
+## Philosophy
+"Treat your AI agent like a powerful but undisciplined junior engineer. Give it the process guardrails that turn juniors into seniors."

package/vault/wiki/entities/lean-ctx.md

@@ -0,0 +1,32 @@
+---
+type: entity
+title: "lean-ctx"
+created: 2026-04-30
+updated: 2026-04-30
+status: seed
+tags: [#entity, #tool]
+sources: 
+  - "[[leanctx-website]]"
+related:
+  - "[[Research: context-mode vs lean-ctx]]"
+---
+
+# lean-ctx
+
+> [!stub] This is a stub page. See [[leanctx-website]] for the source documentation.
+
+lean-ctx (pi-lean-ctx) is the Context Runtime for AI Agents — a tool that compresses LLM context by up to 99% through structured file reading, tree-sitter AST parsing, and advanced shell output compression.
+
+## What it provides
+
+- 46+ MCP tools for agent context management
+- 10 reading modes (signatures, maps, full reads)
+- 90+ shell patterns for command output compression
+- Tree-sitter AST for 18 languages
+- Native Pi package integration
+
+## Key pages
+
+- [[leanctx-website]] — source: leanctx.com
+- [[Research: context-mode vs lean-ctx]] — comparison with context-mode
+- [[2026-04-30-pi-lean-ctx-native]] — ADR: adopting pi-lean-ctx native package

package/vault/wiki/entities/opendev.md

@@ -0,0 +1,41 @@
+---
+type: entity
+entity_type: project
+url: https://github.com/opendev-to/opendev
+tags:
+  - coding-agent
+  - open-source
+  - terminal
+  - context-engineering
+related:
+  - "[[Entity: Pi Coding Agent (pi-mono)]]"
+  - "[[sources/opendev-arxiv-2603.05344v1]]"
+---
+
+# OpenDev
+
+Open-source, command-line AI coding agent by Nghi D. Q. Bui. First comprehensive technical report for a terminal-native interactive coding agent (arXiv:2603.05344v1, March 2026).
+
+## Architecture
+
+Four-layer system:
+1. **Entry & UI**: CLI, TUI (Textual), Web UI (FastAPI + WebSockets)
+2. **Agent**: MainAgent (single class, parameterized), Planner subagent, 8 specialized subagent types
+3. **Tool & Context**: 35 built-in tools across 12 handler categories, MCP integration, staged compaction
+4. **Persistence**: Session storage (JSON + JSONL), operation log/undo, configuration hierarchy, provider cache
+
+## Key Features
+
+- **Compound AI system**: 5 model roles (action, thinking, critique, vision, compact)
+- **Extended ReAct loop**: Thinking phase → Action phase → Decision with doom-loop detection
+- **Adaptive Context Compaction**: 5 graduated stages (70%→80%→85%→90%→99%)
+- **Defense-in-depth safety**: 5 independent layers
+- **Dual-memory architecture**: Episodic + Working memory
+- **Event-driven reminders**: 24 templates, 8 event detectors
+- **9-pass fuzzy edit matching**: Absorbs LLM formatting imprecision
+- **LSP integration**: Semantic code analysis for 30+ languages
+- **Shadow git snapshots**: Per-step undo without interfering with user's git
+
+## Relevance
+
+OpenDev's architecture paper is the most comprehensive reference for building terminal coding agents. Its context engineering, safety, and orchestration patterns are directly applicable to our harness. The paper's "Lessons Learned" section (Section 3) provides transferable engineering principles validated through production use.

package/vault/wiki/entities/ops-codegraph-tool.md

@@ -0,0 +1,18 @@
+---
+type: entity
+title: "ops-codegraph-tool"
+created: 2026-04-30
+updated: 2026-04-30
+status: seed
+tags: [#entity, #tool, #code-search]
+related:
+  - "[[Research: semantic code search tools]]"
+---
+
+# ops-codegraph-tool
+
+> [!stub] Minimal entity stub.
+
+Python dependency graph engine + semantic search + boundary enforcement (41 ⭐). Combines code dependency analysis with semantic search capabilities.
+
+Mentioned in [[Research: semantic code search tools]] as a secondary alternative to [[ck-tool]].

package/vault/wiki/entities/pi-coding-agent.md

@@ -0,0 +1,53 @@
+---
+type: entity
+entity_type: project
+url: https://github.com/badlogic/pi-mono
+tags:
+  - pi-agent
+  - coding-agent
+  - open-source
+  - terminal
+related:
+  - "[[Entity: disler (IndyDevDan)]]"
+  - "[[Entity: OpenDev]]"
+  - "[[sources/disler-pi-vs-claude-code]]"
+---
+
+# Pi Coding Agent (pi-mono)
+
+Open-source AI agent toolkit by Mario Zechner (libGDX creator). 11.3K GitHub stars.
+
+## Components
+
+- **Coding Agent CLI**: Terminal-native agentic coding assistant
+- **Unified LLM API**: Single interface across multiple providers
+- **TUI and Web UI libraries**: Terminal and browser interfaces
+- **Slack bot**: Agent accessible via chat
+- **vLLM pods**: Self-hosted model infrastructure
+
+## Key Differentiators
+
+- **<1000 token system prompt**: Fully customizable, minimal by design
+- **Model agnostic**: Supports OpenAI, Anthropic, Google, OpenRouter, and many others
+- **Extension system**: TypeScript SDK for customizing UI, adding tools, hooking events
+- **Event lifecycle**: 15+ events including session_start, tool_call, agent_start, turn_end, message_update
+- **Extension composability**: Multiple `-e` flags stack extensions
+
+## Extension API
+
+Extensions are TypeScript files that hook into Pi's event system:
+```typescript
+// Minimal extension pattern
+export default function(pi) {
+  pi.on('session_start', (ctx) => { /* ... */ });
+  pi.on('tool_call', (ctx) => { /* intercept/modify */ });
+}
+```
+
+Built-in tools available to extensions: `read`, `bash`, `edit`, `write`.
+
+## Architecture Relevance
+
+Pi's extension API is the foundation for building agentic orchestration pipelines. The event system provides hooks at every lifecycle stage. The tool interface enables custom tool creation. Extensions compose without modifying core code.
+
+Our harness sits on top of Pi's extension API — we implement orchestration, safety, and context engineering as extensions rather than core modifications.

package/vault/wiki/entities/sentrux.md

@@ -0,0 +1,54 @@
+---
+type: entity
+title: "sentrux (tool)"
+created: 2026-05-03
+tags:
+  - code-quality
+  - static-analysis
+  - rust
+  - developer-tools
+  - ai-coding
+related:
+  - "[[Quality Signal (sentrux)]]"
+  - "[[Five Root Cause Metrics (sentrux)]]"
+  - "[[sentrux Rules Engine]]"
+  - "[[sentrux MCP Integration]]"
+sources:
+  - "[[sentrux-github-repo]]"
+  - "[[sentrux-dev-landing]]"
+---
+
+# sentrux (tool)
+
+An open-source (MIT), real-time architectural sensor for AI-agent-written code. Built in Rust, single binary, no runtime dependencies.
+
+## Core Identity
+"The sensor that helps AI agents close the feedback loop. Recursive self-improvement of code quality."
+
+## Key Stats
+- **First release:** March 11, 2026
+- **Latest version:** v0.5.7 (March 18, 2026)
+- **GitHub:** 1.9k stars, 168 forks
+- **Codebase:** ~36K lines of Rust, 87.5% Rust
+- **Languages supported:** 52 (via tree-sitter plugins)
+- **License:** MIT (free), BSL (Pro source-available)
+- **Pricing:** Free / Pro $15/month / Team $40/month/seat
+
+## Creators
+- **yjing** (primary author, GitHub: sentrux)
+- Contributors: claude (likely AI-generated), v1b3coder, trevorsilence
+
+## Technology
+- Pure Rust, egui + wgpu for GUI rendering
+- tree-sitter for multi-language parsing
+- MCP (Model Context Protocol) for AI agent integration
+- Ed25519 for Pro license validation
+- Squarified treemap layout with spatial index for O(1) hit testing
+
+## Philosophy
+1. Human-in-the-loop is non-negotiable
+2. Verification is more valuable than generation
+3. Good systems make good outcomes inevitable
+
+## Critical Reception
+Mixed. Reddit launch (r/rust, March 2026) drew both praise for the concept (human-in-the-loop, feedback loop) and criticism for rapid development pace (17 releases in one day), "vibe-coded" appearance, and unclear practical value. The tool gave its own repo a "D" rating.

package/vault/wiki/entities/vgrep-tool.md

@@ -0,0 +1,57 @@
+---
+type: entity
+entity_type: tool
+status: active
+created: 2026-04-30
+updated: 2026-04-30
+tags:
+  - code-search
+  - semantic-search
+  - embeddings
+  - rust
+  - privacy
+related:
+  - "[[vgrep-semantic-search]]"
+  - "[[ck-tool]]"
+  - "[[Research: semantic code search tools]]"
+title: "vgrep"
+
+---# vgrep
+
+**Repository**: [CortexLM/vgrep](https://github.com/CortexLM/vgrep)  
+**Stars**: 144 | **Language**: Rust | **License**: TBD
+
+Vector embedding-based semantic search engine with client-server architecture. Fully local, privacy-first. GPU acceleration via CUDA, Metal, and Vulkan. Searches code, documents, and text by semantic similarity.
+
+## Architecture
+
+```
+User Query → vgrep CLI → vgrep daemon (in-memory index) → Results
+```
+
+The daemon maintains the embedding index in memory for fast repeated searches. The CLI is a thin client that sends queries to the daemon.
+
+## Key Commands
+
+```bash
+vgrep init               # Download models (~1GB)
+vgrep models download    # Additional models
+vgrep server start       # Start daemon
+vgrep search "query"     # Semantic search
+```
+
+## Gap Analysis (vs ck)
+
+| Feature | vgrep | ck |
+|---------|-------|-----|
+| grep-compatible | ❌ | ✅ |
+| MCP server | ❌ (planned) | ✅ |
+| Hybrid search | ❌ | ✅ (BM25+embeddings) |
+| GPU acceleration | ✅ | ❌ |
+| Client-server | ✅ | ❌ (CLI only) |
+| Editor integration | ❌ | ✅ (VSCode) |
+| TUI | ❌ | ✅ |
+
+## Recommendation
+
+Not recommended as primary tool for AI coding harness due to lack of MCP integration and grep compatibility. Worth watching if MCP support ships and the project gains traction.

package/vault/wiki/entities/vitest.md

@@ -0,0 +1,41 @@
+---
+type: entity
+status: developing
+tags:
+  - testing
+  - vitest
+  - vite
+  - typescript
+related:
+  - "[[vitest-official]]"
+  - "[[Research: TypeScript Best Practices and Codebase Structure]]"
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Vitest
+
+Vitest is a next-generation testing framework for JavaScript and TypeScript, designed as a Vite-native alternative to Jest.
+
+## Key Facts
+
+- **Current version**: v4.1.5 (2026)
+- **Maintainer**: VoidZero Inc. + open-source community
+- **Engine**: Vite-powered (reuses Vite config, plugins, and transform pipeline)
+- **Compatibility**: Jest-compatible API (`expect`, `describe`/`it`, snapshots, coverage)
+- **TypeScript**: Native support via Oxc transpiler — zero config
+
+## Core Features
+
+- **Smart watch mode**: Only reruns tests affected by code changes (HMR for tests)
+- **ESM native**: No transforms needed for ES module syntax
+- **JSX/TSX**: Built-in support for React, Vue, Svelte, Solid, and others
+- **Works without Vite**: Can be used in non-Vite Node.js backends
+- **Concurrent test execution**: Worker threads for parallelism
+
+## When to Use
+
+Primary choice for Vite-based projects (React, Vue, Svelte). Also recommended for new projects replacing Jest — migration is straightforward. Not ideal for legacy projects with heavy Jest-specific plugin dependencies.
+
+## Ecosystem Position
+
+Vitest has largely replaced Jest as the default test runner for new frontend and full-stack TypeScript projects in the Vite ecosystem. Official recommendation from the Vite team.

package/vault/wiki/flows/harness-wiki-pipeline.md

@@ -0,0 +1,204 @@
+---
+type: flow
+title: Harness-Wiki Pipeline
+status: active
+created: "2026-04-28"
+updated: "2026-04-28"
+tags: [flow, harness, wiki, pipeline, integration, read-first, write-after]
+sources:
+  - "[[adr-010]]"
+  - "[[harness-wiki-skill-mapping]]"
+related:
+  - "[[harness]]"
+  - "[[persistent-memory]]"
+  - "[[wiki-query-interface]]"
+  - "[[schema-orchestration]]"
+---
+
+# Harness-Wiki Pipeline
+
+The exact data flow between the harness pipeline and the wiki vault. Implements [[adr-010]]: read-first, write-after, no-staleness.
+
+## Core Contract
+
+```
+┌─────────────────────────────────────────────────┐
+│              HARNESS LAYER ACTION                 │
+│                                                   │
+│   ┌──────────┐    ┌──────────┐    ┌──────────┐   │
+│   │ READ WIKI │ →  │  LAYER   │ →  │ WRITE    │   │
+│   │ (query)   │    │  LOGIC   │    │ WIKI     │   │
+│   └──────────┘    └──────────┘    └──────────┘   │
+│         ↑                              ↓         │
+│    ADRs, specs,              Decisions, patterns, │
+│    patterns, status           events, statuses   │
+└─────────────────────────────────────────────────┘
+```
+
+**Invariant**: No layer acts without reading. No layer completes without writing.
+
+## Read-First Protocol
+
+Before any layer executes, the following wiki reads happen:
+
+### Session Bootstrap (once per session)
+
+| Step | Skill | Target | Purpose |
+|------|-------|--------|---------|
+| 1 | `wiki-query` quick | `hot.md` | Load recent context (~500 tokens) |
+| 2 | `wiki-query` quick | `index.md` | Know what pages exist (~1000 tokens) |
+| 3 | `wiki-query` standard | ADRs in `decisions/` | Load active constraints |
+| 4 | `compress` | If hot.md > 600 words | Trim to stay under token budget |
+
+### Per-Layer Read
+
+| Layer | Mandatory Wiki Reads | Skill | Depth |
+|-------|---------------------|-------|-------|
+| L1 | `decisions/adr-008`, `modules/spec-hardening`, any existing spec for feature | `wiki-query` standard | Standard |
+| L2 | `flows/plan-*`, `modules/structured-planning`, all ADRs from L1 | `wiki-query` deep | Deep |
+| L3 | `hot.md` (current checkpoint state), `flows/plan-{feature}` | `wiki-query` quick | Quick |
+| L4 | `decisions/adr-008`, `modules/adversarial-verification`, L1 spec | `wiki-query` standard | Standard |
+| L5 | `modules/automated-observability`, L1 spec | `wiki-query` standard | Standard |
+| L6 | Per depth table in [[persistent-memory]] | `wiki-query` | Variable |
+| L7 | `modules/schema-orchestration`, `flows/plan-*` | `wiki-query` standard | Standard |
+| L8 | Per depth table in [[wiki-query-interface]] | `wiki-query` | Variable |
+
+**Failure mode**: If `wiki-query` returns no relevant ADR for a layer that requires one, the layer MUST halt and request the user create the missing ADR before proceeding.
+
+## Write-After Protocol
+
+After every state transition, the following wiki writes happen:
+
+### Per-Layer Write Matrix
+
+| Layer | Event | Wiki Write | Skill | Target Page |
+|-------|-------|-----------|-------|-------------|
+| L1 | Spec hardened | Decision + callout | `wiki-save` | `decisions/spec-{feature}.md` |
+| L1 | Ambiguity resolved | Decision | `wiki-save` | `decisions/spec-{feature}.md` |
+| L2 | Plan approved | Flow page | `wiki-save` | `flows/plan-{feature}.md` |
+| L2 | Plan rejected | Failure pattern | `wiki-save` | `modules/{feature}.md` with `> [!contradiction]` |
+| L3 | Checkpoint passed | Log entry + hot.md | `wiki-ingest` + `wiki-save` | `log.md` + `hot.md` |
+| L3 | Drift detected | Failure pattern | `wiki-save` | `modules/{feature}.md` with `> [!contradiction]` |
+| L4 | Subtask verified | Success pattern | `wiki-save` | `modules/{feature}.md` with `status: mature` |
+| L4 | Subtask failed | Failure pattern | `wiki-save` | `modules/{feature}.md` with `> [!contradiction]` |
+| L4 | QA test results | Decision + metrics | `wiki-save` | `decisions/qa-{feature}.md` |
+| L5 | Observability defined | Decision | `wiki-save` | `decisions/observability-{feature}.md` |
+| L5 | Metric verified | Module update | `wiki-ingest` | `modules/automated-observability.md` |
+| L6 | Memory write | Per event hooks table | `wiki-save` / `wiki-ingest` | Per [[persistent-memory]] mapping |
+| L7 | Wave completed | Orchestration status | `wiki-ingest` | `modules/schema-orchestration.md` |
+| L7 | Replan triggered | Log entry + flow update | `wiki-ingest` | `log.md` + `flows/plan-{feature}.md` |
+| L8 | Deep query answered | Synthesis page | `wiki-save` | `questions/research-{topic}.md` |
+
+### Session Shutdown (once per session)
+
+| Step | Skill | Target | Purpose |
+|------|-------|--------|---------|
+| 1 | `wiki-save` | `hot.md` | Update recent context for next session |
+| 2 | `wiki-ingest` | `log.md` | Append shutdown entry |
+| 3 | `wiki-lint` | Full vault | Catch staleness, orphans, dead links |
+| 4 | `wiki-fold` | `wiki/folds/` | If 8+ entries since last fold, run fold |
+
+## Staleness Elimination Rules
+
+These rules guarantee no wiki page goes stale:
+
+### Rule 1: Status Propagation
+When a module's implementation status changes (e.g., `status: developing` → `status: active`), the module page frontmatter MUST be updated in the same pipeline step.
+
+### Rule 2: Decision Referencing
+When a new ADR supersedes or modifies an existing one:
+- The new ADR MUST have `supersedes: old-adr` in frontmatter
+- The old ADR MUST have `superseded_by: new-adr` and `status: superseded` updated
+- `index.md` MUST reflect the change
+
+### Rule 3: Cross-Reference Integrity
+When `wiki-save` creates a new page, it MUST:
+- Add wikilinks to all related pages mentioned in frontmatter
+- Add a backlink entry in each referenced page (or flag for `wiki-lint` to catch)
+- Update `index.md` with the new entry
+
+### Rule 4: Contradiction Resolution
+When `wiki-lint` detects a contradiction between pages:
+- Both pages get `> [!contradiction]` callouts
+- A `questions/contradiction-{topic}.md` page is created
+- The next L7 orchestration step MUST resolve it before proceeding
+
+### Rule 5: Hot Cache Freshness
+`hot.md` is overwritten completely at:
+- Session start (read from wiki state)
+- Every L3 checkpoint (update with current state)
+- Session shutdown (write final state)
+
+Hot.md MUST never be older than the last completed L3 checkpoint.
+
+### Rule 6: Lint Schedule
+`wiki-lint` runs:
+- After every 10-15 wiki writes (counter tracked by L7)
+- At session shutdown
+- On explicit user request
+
+Lint output goes to `wiki/meta/lint-report-YYYY-MM-DD.md`.
+
+### Rule 7: Index Synchronization
+`index.md` is updated:
+- After every `wiki-save` that creates a new page
+- After every `wiki-ingest` batch
+- After every `wiki-lint` that removes or merges pages
+- Never manually — always through skills
+
+## Extension Hook Implementation
+
+Each `extensions/harness-*.ts` file implements this pattern:
+
+```typescript
+// Pre-action: read wiki
+const wikiContext = await wikiQuery({
+  depth: 'standard',
+  targets: ['decisions/', `modules/${layerName}`],
+});
+
+// Validate: ensure we have the ADRs we need
+if (requiredADRs.some(adr => !wikiContext.hasADR(adr))) {
+  throw new HarnessError('MISSING_ADR', 'Required ADR not found in wiki');
+}
+
+// Execute: layer logic
+const result = await layerLogic(input, wikiContext);
+
+// Post-action: write wiki
+await save({
+  type: result.writeType,
+  title: result.writeTitle,
+  content: result.writeContent,
+  related: result.relatedPages,
+});
+
+// Update: hot cache if significant
+if (result.affectsHotCache) {
+  await updateHotCache(result);
+}
+
+// Increment: write counter for lint scheduling
+writeCounter++;
+if (writeCounter >= 10) {
+  await wikiLint();
+  writeCounter = 0;
+}
+```
+
+## Token Budget Impact
+
+| Activity | Tokens | Frequency |
+|----------|--------|-----------|
+| Session bootstrap reads | ~3,000 | 1/session |
+| Per-layer reads | ~500-3,000 | Per subtask x layers |
+| Per-layer writes | ~500-1,500 | Per subtask x events |
+| Lint runs | ~2,000 | Every 10-15 writes |
+| Hot cache updates | ~500 | Per checkpoint |
+| Fold runs | ~1,000 | After 8+ log entries |
+| **Added per subtask** | **~3,000-6,000** | On top of existing ~17,500 |
+
+New total per subtask: **~20,500-23,500 tokens**.
+New total for 5-subtask plan: **~102,500-117,500 tokens** overhead.
+
+This is a ~20-35% increase over the pre-integration budget, but eliminates the risk of design drift and wiki staleness entirely.