ultimate-pi 0.1.2 → 0.1.4

package/vault/wiki/sources/github-sub-issues-docs.md

@@ -0,0 +1,51 @@
+---
+type: source
+status: ingested
+source_type: documentation
+title: "GitHub Sub-Issues — Official Documentation"
+author: GitHub Docs
+date_published: 2025-04-11
+url: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues
+confidence: high
+key_claims:
+  - "Sub-issues allow breaking larger issues into smaller tasks, available since April 2025"
+  - "Up to 100 sub-issues per parent issue and up to 8 levels of nested sub-issues"
+  - "Parent issues and sub-issue progress is available in GitHub Projects (filter, group, views)"
+  - "Sub-issues can themselves contain sub-issues (full hierarchies)"
+  - "Cross-repository sub-issues supported"
+  - "Requires at least triage permissions"
+tags:
+  - github
+  - issues
+  - sub-issues
+  - project-management
+related:
+  - "[[Research: GitHub Issues as Harness Spec Storage]]"
+created: 2026-05-02
+updated: 2026-05-02
+
+---# GitHub Sub-Issues — Official Documentation
+
+GitHub's official documentation for the sub-issues feature, launched in April 2025.
+
+## Key Capabilities
+
+- **Parent-child hierarchies**: Break larger issues into manageable tasks
+- **Depth**: Up to 8 levels of nesting
+- **Breadth**: Up to 100 sub-issues per parent
+- **Cross-repo**: Sub-issues can live in different repositories
+- **Projects integration**: Progress fields, filters, grouping by parent issue
+- **Two creation modes**: Create new sub-issue inline, or add existing issue as child
+
+## API Layer
+
+Sub-issues are exposed through GitHub's GraphQL API with dedicated fields:
+- `subIssues` — list of child issues
+- `parent` — parent issue reference
+- `subIssuesSummary` — aggregate progress (total, completed, not_planned)
+
+The REST API also supports sub-issue relationships through the issues endpoint with parent/child fields.
+
+## Relevance to Harness
+
+This is the canonical cloud storage mechanism for spec decomposition. Each hardened spec (L1) becomes a parent issue; each task from structured planning (L2) becomes a sub-issue. Progress auto-rolls up from children to parent.

package/vault/wiki/sources/gitingest.md

@@ -0,0 +1,91 @@
+---
+type: source
+source_type: tool
+name: Gitingest
+author: coderamp-labs
+date_published: 2025
+url: https://gitingest.com
+repo: https://github.com/coderamp-labs/gitingest
+confidence: high
+key_claims:
+  - "Turn any Git repository into a simple text digest of its codebase"
+  - "Replace 'hub' with 'ingest' in any GitHub URL for prompt-friendly text"
+  - Supports public and private repos (via PAT)
+  - Pattern include/exclude filtering, file size limits
+  - Python package (`pip install gitingest`), CLI, Chrome extension, web UI
+  - Output: summary + directory tree + file contents with clear delimiters
+tags:
+  - codebase-ingestion
+  - llm-context
+  - tool
+created: 2026-04-30
+updated: 2026-04-30
+status: ingested
+title: "Gitingest"
+
+---# Gitingest
+
+## What It Is
+
+Gitingest converts a Git repository into structured plaintext suitable for feeding into an LLM. It clones the repo, extracts all files, and produces a three-part output:
+
+1. **Summary**: Natural language description of the repo
+2. **Directory tree**: Hierarchical view of file structure
+3. **File contents**: Every file wrapped in `=== FILE: path ===` markers
+
+## How It Works
+
+- Clones the repository (or reads local directory)
+- Applies pattern filters (include/exclude globs)
+- Applies file size limits (skip files above threshold)
+- Generates summary based on repo metadata and structure
+- Outputs as structured plaintext
+
+For private repos, a GitHub Personal Access Token (PAT) is used once for cloning and then discarded. Cloned repos are deleted after processing.
+
+## Output Format
+
+```
+===============================================
+SUMMARY
+===============================================
+[Repository description]
+
+===============================================
+DIRECTORY STRUCTURE
+===============================================
+repo/
+├── src/
+│   ├── main.py
+│   └── utils.py
+├── tests/
+└── README.md
+
+===============================================
+FILE: src/main.py
+===============================================
+[file contents]
+===============================================
+FILE: README.md
+===============================================
+[file contents]
+```
+
+## Integration Surface
+
+- **Python API**: `from gitingest import ingest` → `(summary, tree, content)`
+- **CLI**: `gitingest <url> -o - | your_ai_processor`
+- **Web**: https://gitingest.com/owner/repo
+- **Async**: `from gitingest import ingest_async` for Jupyter/async contexts
+- **Environment variables**: `GITHUB_TOKEN`, `GITINGEST_SENTRY_ENABLED`
+
+## Stack
+
+- Backend: FastAPI + Jinja2
+- Frontend: Tailwind CSS
+- Token estimation: tiktoken
+- Analytics: PostHog
+
+## Relevance to ultimate-pi
+
+Direct fit for the harness's need to ingest external codebases as context. Currently the harness uses lean-ctx to read individual files. Gitingest provides bulk codebase ingestion in a format already optimized for LLM context windows.

package/vault/wiki/sources/gitreverse.md

@@ -0,0 +1,63 @@
+---
+type: source
+source_type: tool
+name: GitReverse
+author: filiksyos
+date_published: 2025
+url: https://gitreverse.com
+repo: https://github.com/filiksyos/gitreverse
+confidence: high
+key_claims:
+  - "Turn a GitHub repository into a plain-language coding agent prompt"
+  - "Reverse engineer a codebase into a prompt that likely created it"
+  - Uses OpenRouter LLM to generate synthetic user prompts from repo metadata
+  - Replace 'hub' with 'reverse' in any GitHub URL
+  - Has "Deep Reverse" mode for more detailed prompts
+  - Public repos only
+tags:
+  - prompt-generation
+  - repo-analysis
+  - llm-tool
+created: 2026-04-30
+updated: 2026-04-30
+status: ingested
+title: "GitReverse"
+
+---# GitReverse
+
+## What It Is
+
+GitReverse takes a public GitHub repo URL and generates a synthetic user prompt — a prompt someone might paste into Cursor, Claude Code, or Codex to "vibe code" the project from scratch.
+
+## How It Works
+
+1. Fetches repo metadata via GitHub API: description, topics, language breakdown, file tree, README
+2. Sends metadata + README to an LLM via OpenRouter
+3. LLM generates a synthetic user prompt describing what the repo does and how to build it
+4. Output: 3-5 paragraphs of natural language prompt
+
+**Crucially, it does NOT read the actual source code files.** It only uses metadata and README. This means the generated prompt is a high-level description, not a code-level specification.
+
+## Features
+
+- **Quick Reverse**: Basic prompt from metadata + README
+- **Deep Reverse**: More detailed prompt (likely uses more metadata or a different LLM prompt)
+- **Library**: Browse previously generated prompts
+- **History**: Personal prompt generation history
+- **Manual control**: Toggle for manual parameter adjustment
+- **Shareable URLs**: `/owner/repo` route pattern
+
+## Output Example (for gitreverse repo itself)
+
+> Build me a simple web app that can "reverse engineer" a GitHub repository. The main idea is to take a public repo's URL and generate a synthetic prompt. The user interface should be clean and straightforward: just a single page with an input box. On the backend, it will need to use the GitHub API to fetch the repo's metadata, its root file tree, and the README content. Then, it should pass all that context to a large language model using OpenRouter to generate the final prompt. Let's build this with Next.js using the App Router, React, and TypeScript. For styling, please use Tailwind CSS.
+
+## Stack
+
+- Next.js (App Router), React, TypeScript
+- Tailwind CSS
+- OpenRouter for LLM access
+- GitHub API for repo metadata
+
+## Relevance to ultimate-pi
+
+**Low direct relevance.** GitReverse generates prompts FROM repos — it helps a USER figure out what prompt to write. The ultimate-pi harness is an AGENT that already receives prompts. The harness doesn't need to generate prompts from repos; it needs to ingest repos as context. GitReverse solves the inverse problem.

package/vault/wiki/sources/google-antigravity-official-blog.md

@@ -0,0 +1,47 @@
+---
+type: source
+source_type: engineering-blog
+title: "Build with Google Antigravity, our new agentic development platform"
+author: "Google Antigravity Team"
+date_published: 2025-11-20
+url: "https://developers.googleblog.com/build-with-google-antigravity-our-new-agentic-development-platform/"
+confidence: high
+status: ingested
+created: 2026-05-01
+updated: 2026-05-01
+tags:
+  - antigravity
+  - google
+  - agentic-coding
+  - harness-design
+key_claims:
+  - "Antigravity combines AI-powered IDE with agent-first Manager Surface"
+  - "Agents autonomously plan, execute, and verify complex tasks across editor, terminal, and browser"
+  - "Artifacts (task lists, implementation plans, screenshots, browser recordings) replace raw tool call logs"
+  - "Agents learn from past work via knowledge base"
+  - "Free public preview with Gemini 3 Pro, Claude Sonnet 4.5, and GPT-OSS support"
+  - "Cross-platform: macOS, Windows, Linux"
+
+---# Build with Google Antigravity (Official Announcement)
+
+Google's official announcement blog post for Antigravity, published November 20, 2025.
+
+## Summary
+
+Antigravity is an **agentic development platform** that introduces two distinct interfaces:
+
+- **Editor View**: Traditional AI-powered IDE with tab completions and inline commands
+- **Manager Surface**: Dedicated interface to spawn, orchestrate, and observe multiple agents working asynchronously
+
+The platform is built around four design tenets: trust, autonomy, feedback, and self-improvement.
+
+## Key Details
+
+- **Artifacts**: Tangible deliverables replacing raw tool call logs. Developers comment directly on artifacts (Google Docs-style) and agents incorporate feedback without stopping execution.
+- **Learning**: Core primitive. Agents save useful context and code snippets to knowledge base for future tasks.
+- **Pricing**: Free public preview for individuals with generous rate limits on Gemini 3 Pro.
+- **Models**: Gemini 3 Pro, Anthropic Claude Sonnet 4.5, OpenAI GPT-OSS.
+
+## Relevance to Harness
+
+This is the primary source for understanding Antigravity's architecture. The Artifact system, Manager View, and learning knowledge base are the three innovations most relevant to our harness design.

package/vault/wiki/sources/google-antigravity-wikipedia.md

@@ -0,0 +1,53 @@
+---
+type: source
+source_type: encyclopedia
+title: "Google Antigravity - Wikipedia"
+author: "Wikipedia contributors"
+date_published: 2025-11-18
+url: "https://en.wikipedia.org/wiki/Google_Antigravity"
+confidence: high
+status: ingested
+created: 2026-05-01
+updated: 2026-05-01
+tags:
+  - antigravity
+  - google
+  - reference
+key_claims:
+  - "Announced November 18, 2025 alongside Gemini 3 release"
+  - "Heavily modified fork of Visual Studio Code (debate: direct fork or Windsurf fork)"
+  - "Supports Gemini 3.1 Pro, Gemini 3 Flash, Claude Sonnet 4.6/Opus 4.6, GPT-OSS-120B"
+  - "Free public preview, cross-platform (Windows, macOS, Linux)"
+  - "Editor view + Manager view for agent orchestration"
+  - "Artifacts: verifiable deliverables replacing raw tool calls"
+
+---# Google Antigravity - Wikipedia
+
+Wikipedia entry for Google Antigravity. Last updated April 24, 2026.
+
+## Key Facts
+
+- **Release**: November 18, 2025 (public preview, currently v1.23.2 as of April 2026)
+- **Platform**: 64-bit Windows 10+, macOS Monterey 12+, 64-bit Linux
+- **License**: Proprietary (free during preview)
+- **Origin**: Heavily modified VS Code fork. Debate exists whether it's a direct fork or a Windsurf fork (Google hired Windsurf team + licensed tech for $2.4B in July 2025)
+
+## Features
+
+- **Agent-first paradigm**: Shifts from AI assistance to AI agents operating with autonomy
+- **Editor view**: Standard IDE interface with agent sidebar
+- **Manager view**: Control center for orchestrating multiple agents in parallel
+- **Artifacts**: Verifiable deliverables (task lists, implementation plans, screenshots, browser recordings)
+- **Agent access**: Direct editor, terminal, and integrated browser control
+- **Learning**: Agents learn from previous interactions
+
+## Model Support
+
+- Gemini 3.1 Pro (primary)
+- Gemini 3 Flash
+- Anthropic Claude Sonnet 4.6 and Opus 4.6
+- OpenAI GPT-OSS-120B (open-source variant)
+
+## Relevance to Harness
+
+Provides authoritative timeline, version history, and architectural origin. The Windsurf acquisition context is significant: Antigravity represents Google's $2.4B bet on agent-first development.

package/vault/wiki/sources/gsd-codecentric-deep-dive.md

@@ -0,0 +1,57 @@
+---
+type: source
+source_type: engineering-blog
+title: "GSD for Claude Code: A Deep Dive into the Workflow System (codecentric)"
+author: "Felix Abele"
+date_published: 2026-03-03
+date_accessed: 2026-05-05
+url: "https://www.codecentric.de/en/knowledge-hub/blog/the-anatomy-of-claude-code-workflows-turning-slash-commands-into-an-ai-development-system"
+confidence: high
+tags:
+  - gsd
+  - architecture
+  - claude-code
+  - spec-driven-development
+key_claims:
+  - "GSD relies entirely on native Claude Code features — no proprietary runtime, no framework"
+  - "Architecture: Slash Commands (WHAT), Workflow Files (HOW), References (reusable knowledge), Templates (output formats)"
+  - "@-file references for context injection: commands reference workflows which reference templates"
+  - "AskUserQuestion tool used for interactive decision points with gates and feedback loops"
+  - "Parallel research orchestration: 4 researchers → Synthesizer → Roadmapper, in waves"
+  - "Two agent spawning patterns: general-purpose with manual role assignment vs registered agent type"
+  - "Bash scripts (gsd-tools.cjs) used for deterministic project state capture — queries that LLMs would do unreliably"
+  - "Hooks: SessionStart (update check), PostToolUse (auto-formatting), statusLine (context usage progress bar)"
+  - "GSD designed for small to medium projects; not for every use case"
+---
+
+# GSD Architecture Deep Dive (codecentric, March 2026)
+
+## Summary
+
+This is the most detailed public architectural analysis of GSD. It walks through the `/gsd:new-project` command step-by-step, showing how Claude Code's native features (skills, agents, hooks, AskUserQuestion, @-file references) are composed into a full software development lifecycle system.
+
+## Architectural Layers
+
+### 1. Slash Commands (Skills)
+Each command is a markdown file in `claude/commands/gsd/` with:
+- **Frontmatter:** name, description, argument-hint, allowed-tools
+- **Prompt body:** XML-structured (`<objective>`, `<execution_context>`, `<process>`) with @-file references
+
+### 2. Workflow Files
+The actual logic lives in workflow files (e.g., `workflows/new-project.md`). Slash commands are thin wrappers that declare permissions and reference the workflow.
+
+### 3. Agent Orchestration
+- **Wave 1:** 4 parallel researchers (stack, features, architecture, pitfalls) — each writes to its own file
+- **Wave 2:** Synthesizer reads all 4 files → `SUMMARY.md`
+- **Wave 3:** Roadmapper reads synthesis + requirements → creates roadmap
+
+### 4. Deterministic Tooling
+`gsd-tools.cjs` is a Node.js CLI that returns project state as JSON. Avoids the LLM doing unreliable file-existence checks, config loading, or phase number calculations.
+
+### 5. Cross-Session Memory
+All state persisted in `.planning/` files (PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md). After every completed step, a git commit is performed. `/gsd-resume-work` reconstructs previous state.
+
+## Limitations Noted
+- Designed for small to medium projects
+- May not go deep enough in some places
+- Once you understand the workflow structure, building your own specific systems is straightforward

package/vault/wiki/sources/gsd-github-repo.md

@@ -0,0 +1,51 @@
+---
+type: source
+source_type: github-repo
+title: "GitHub - gsd-build/get-shit-done"
+author: "TÂCHES (@glittercowboy)"
+date_published: 2025-12-15
+date_accessed: 2026-05-05
+url: "https://github.com/gsd-build/get-shit-done"
+confidence: high
+tags:
+  - gsd
+  - meta-prompting
+  - spec-driven-development
+  - context-engineering
+  - claude-code
+key_claims:
+  - "GSD is a lightweight meta-prompting, context engineering, and spec-driven development system for Claude Code (and 15+ other runtimes)"
+  - "Solves context rot — the quality degradation that happens as LLMs fill their context window"
+  - "60.1k GitHub stars, 5.1k forks, 2,367 commits, 143 contributors (May 2026)"
+  - "v1.40.0 released May 3, 2026; MIT License"
+  - "Built entirely on Claude Code native features: skills, agents, hooks — ~50 markdown files + a Node.js CLI helper"
+  - "Core workflow: discuss → plan → execute → verify → ship (phase-based)"
+  - "Multi-agent orchestration: thin orchestrator spawns specialized agents with fresh context per plan"
+  - "Atomic git commits per task; wave execution (parallel where independent, sequential where dependent)"
+  - "Model profiles: quality/balanced/budget/inherit across planning/execution/verification"
+  - "86 skills + 33 subagents full install; --minimal flag cuts to 6 core skills (~700 token overhead vs ~12K)"
+  - "Skill consolidation v1.40: 86→59 commands via grouped skills (capture, phase, config, workspace)"
+  - "GSD-2 standalone version being built on pi.dev"
+---
+
+# GSD (Get Shit Done) — GitHub Repository
+
+## Summary
+
+GSD is the most popular spec-driven development harness in the Claude Code ecosystem. It is a set of ~50 markdown files (skills, agents, workflows), a Node.js CLI helper (`gsd-tools.cjs`), and hooks that install into Claude Code's `.claude/` directory via `npx get-shit-done-cc@latest`. No proprietary runtime — all orchestration uses Claude Code's native Task tool for subagent spawning, file-based state for cross-session memory, and structured XML plans for execution.
+
+## Architecture
+
+- **Skills (59 shipped):** Slash commands like `/gsd-new-project`, `/gsd-plan-phase`, `/gsd-execute-phase`. Each is a markdown file with frontmatter (allowed-tools, description) + XML-structured prompt body.
+- **Subagents (33):** Specialized agents for research (4 parallel: stack, features, architecture, pitfalls), planning (planner + plan-checker), execution (executors in waves), verification (verifier + debuggers).
+- **Hooks:** SessionStart (update check), PostToolUse (auto-formatting with Prettier), statusLine (context usage + active task).
+- **State files:** `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` — file-based persistent memory across sessions.
+- **SDK:** TypeScript ESM package (`gsd-sdk`) for headless CLI with init + auto commands.
+- **Security:** Prompt injection detection, path traversal prevention, CI security scanning.
+
+## Key Design Decisions
+
+1. **Deterministic logic in code, not prompts.** The `gsd-tools.cjs` CLI handles file existence checks, config loading, phase numbering — operations where scripts are more reliable than LLM prompts.
+2. **Fresh context per plan.** Plans are small enough to execute in a clean 200K context window. No accumulated garbage.
+3. **Filesystem as message bus.** Agent-to-agent communication happens exclusively through files in `.planning/`.
+4. **Two spawning patterns:** General-purpose agents with manual role assignment (researchers share one definition) vs registered agent types (planner, verifier have unique definitions).

package/vault/wiki/sources/gsd-hn-discussion.md

@@ -0,0 +1,59 @@
+---
+type: source
+source_type: discussion-thread
+title: "Hacker News: Get Shit Done — meta-prompting, context engineering and spec-driven dev system"
+author: "HN Community (submitted by stefankuehnel)"
+date_published: 2026-03-18
+date_accessed: 2026-05-05
+url: "https://news.ycombinator.com/item?id=47417804"
+confidence: high
+tags:
+  - gsd
+  - community-feedback
+  - tool-comparison
+  - token-usage
+key_claims:
+  - "473 points, 254 comments on HN — high engagement"
+  - "Consensus: GSD is good for greenfield/small projects, degrades on large existing codebases"
+  - "Multiple users report burning through Claude Max weekly limits in 1-2 days"
+  - "Plan mode (native Claude Code) often sufficient; GSD overkill for simple tasks"
+  - "Spec-driven tools debated: natural language specs are ambiguous vs. executable tests are precise"
+  - "Community comparison: GSD vs Superpowers — both overengineered; Superpowers better for brainstorming, GSD better for state tracking"
+  - "Key insight from user DIVx0: GSD agents start leaving orphans in large codebases; verification stages use simple lexical tools, not AST-aware analysis"
+  - "User paddy_m described ideal system: plan → adversarial review → test implementation → adversarial PR review, with web UI and git reset on failure"
+  - "Several users built custom harnesses after finding GSD too slow or opaque"
+  - "GSD-2 standalone version being built on pi.dev"
+---
+
+# GSD Hacker News Discussion (473 points, March 2026)
+
+## Community Consensus
+
+### Positive
+- Works well for greenfield projects and solo developers
+- State tracking across sessions is genuinely useful
+- Helps non-technical users build functional apps
+- The discuss → plan → execute → verify pipeline produces better results than raw prompting
+
+### Negative
+- **Token burner:** Multiple users hit Claude Max weekly limits within 1-2 days
+- **Too slow:** "hours instead of minutes" compared to native plan mode
+- **Degrades on large codebases:** Agents leave orphaned code; verification uses lexical tools, not AST-aware analysis
+- **Over-engineered:** Many users stripped it back to 30% or built their own simpler versions
+- **Black box:** Hard to understand what's happening inside the pipeline
+- **Waterfall feel:** Difficult to adjust phases/plans mid-execution when bugs or requirement changes arise
+
+### Key Comparisons
+| Tool | Strength | Weakness |
+|------|----------|----------|
+| GSD | State tracking, session memory | Token-heavy, slow |
+| Superpowers | Brainstorming, exploration | Overzealous, writes code into plans |
+| BMAD | Deep elicitation, adversarial review | Steep learning curve, heavy artifacts |
+| OpenSpec | Delta specs, parallel work | Opinionated directory structure |
+| Native Plan Mode | Fast, simple | No cross-session memory |
+
+### Notable Quotes
+- "These frameworks are great for fire-and-forget tasks, especially when there is some research involved but they burn 10x more tokens"
+- "The spec-driven approach is underrated. Treating the spec as a living artifact the AI can reference across sessions"
+- "I prefer move fast and start over if anything goes off track"
+- "Spec-Driven Development is a curious term — it suggests it is in the tradition of TDD but goes in the opposite direction"

package/vault/wiki/sources/guido-python-design-philosophy.md

@@ -0,0 +1,56 @@
+---
+type: source
+source_type: interview-blog
+title: "Python's Design Philosophy — Guido van Rossum"
+author: "Guido van Rossum"
+date_published: 2009-01-13
+url: "http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html"
+confidence: high
+key_claims:
+  - "Borrow ideas from elsewhere whenever it makes sense"
+  - "Things should be as simple as possible, but no simpler (Einstein)"
+  - "Do one thing well (Unix philosophy)"
+  - "Don't fret too much about performance — plan to optimize later"
+  - "Don't try for perfection because 'good enough' is often just that"
+  - "It's okay to cut corners sometimes, especially if you can do it right later"
+  - "The Python implementation should not be tied to a particular platform"
+  - "Errors should not be fatal. At the same time, errors should not pass silently"
+  - "A bug in the user's Python code should never lead to undefined behavior of the interpreter"
+tags: [python, guido-van-rossum, language-design, zen-of-python]
+also_see:
+  - "[[guido-van-rossum-2025-interview]]"
+---
+
+# Python's Design Philosophy — Guido van Rossum
+
+## Timesaving Rules (from Python's origin as skunkworks project)
+
+- Borrow ideas from elsewhere whenever it makes sense.
+- "Things should be as simple as possible, but no simpler." (Einstein)
+- Do one thing well (The Unix Philosophy).
+- Don't fret too much about performance — plan to optimize later when needed.
+- Don't fight the environment and go with the flow.
+- Don't try for perfection because "good enough" is often just that.
+- It's okay to cut corners sometimes, especially if you can do it right later.
+
+## Design Principles
+
+- The Python implementation should not be tied to a particular platform.
+- Don't bother users with details that the machine can handle.
+- Support and encourage platform-independent user code, but don't cut off access to platform capabilities.
+- A large complex system should have multiple levels of extensibility.
+- Errors should not be fatal. User code should be able to recover.
+- Errors should not pass silently (led to exceptions throughout).
+- A bug in user code should never lead to undefined interpreter behavior; a core dump is never the user's fault.
+
+## The Zen of Python (Tim Peters)
+
+Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Readability counts. Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. There should be one — and preferably only one — obvious way to do it. If the implementation is hard to explain, it's a bad idea. Namespaces are one honking great idea.
+
+## Deliberate Departures from ABC
+
+The ABC group (where van Rossum worked before Python) strived for perfection, used optimal algorithms for asymptotically large collections (bad for small ones), isolated users from the "big bad world of computers," and created a closed system. Python deliberately went opposite: pragmatic, evolutionary, open, and welcoming of user participation in design.
+
+## Guido's 2025 Perspective on Type Hints
+
+"Type hints are useful above about 10,000 lines of code — below that, it's of diminishing value since a developer can keep enough of it in their head. I wouldn't foist them upon beginners." (Source: [[guido-van-rossum-2025-interview]])

package/vault/wiki/sources/hejlsberg-7-learnings.md

@@ -0,0 +1,48 @@
+---
+type: source
+source_type: interview-blog
+title: "7 Learnings from Anders Hejlsberg: Architect Behind C# and TypeScript"
+author: "Aaron Winston, GitHub Blog"
+date_published: 2026-01-27
+url: "https://github.blog/developer-skills/programming-languages-and-frameworks/7-learnings-from-anders-hejlsberg-the-architect-behind-c-and-typescript/"
+confidence: high
+key_claims:
+  - "Fast feedback loops matter more than elegance"
+  - "Scaling software means letting go of personal preferences"
+  - "TypeScript succeeded because it extended JavaScript instead of replacing it"
+  - "Visibility is part of what makes open source work — develop in the open"
+  - "Behavioral compatibility often matters more than architectural purity"
+  - "In an AI-driven workflow, grounding matters more than generation — type systems as guardrails"
+  - "Leaving JavaScript as implementation language for Go was a necessary break for performance"
+tags: [anders-hejlsberg, typescript, csharp, language-design, ai-coding]
+---
+
+# 7 Learnings from Anders Hejlsberg
+
+## 1. Fast feedback matters more than almost anything else
+
+Turbo Pascal's impact came from shortening the feedback loop — edit, compile, run without touching disk. "When you typed your code, you wanted to run it immediately." TypeScript's value comes from tooling: incremental checking, fast partial results, language services that respond quickly even on large codebases. Fast feedback changes behavior: developers experiment more, refactor more confidently, catch problems closer to introduction.
+
+## 2. Scaling software means letting go of personal preferences
+
+"You have to accept that things get done differently than you would have preferred. Fixing it would not really change the behavior anyway." The goal shifts from code that looks the way you'd write it to code that many people can understand, maintain, and evolve together.
+
+## 3. TypeScript extended JavaScript instead of replacing it
+
+Creating a brand-new language in 2012 would have required years of investment in editors, debuggers, and community adoption. TypeScript worked with constraints developers already had. "Meaningful progress often comes from making the systems you already depend on more capable instead of trying to start over."
+
+## 4. Visibility is part of what makes open source work
+
+2014 move to GitHub transformed TypeScript. Design debates, rejected ideas, and tradeoffs remain accessible. "12 years of history captured in our project."
+
+## 5. Leaving JavaScript as implementation language was a necessary break
+
+TypeScript compiler ported to Go for performance and concurrency. Not a rewrite — semantic fidelity was the goal. "The new compiler needed to behave exactly like the old one, including quirks and edge cases."
+
+## 6. AI workflow: grounding matters more than generation
+
+Hejlsberg skeptical of AI-first programming languages. The risk: "plausible, confident code that lacks enough grounding in the realities of a codebase." Strong type systems, reliable refactoring tools, and accurate semantic models become essential guardrails. "The most valuable tools in an AI-assisted workflow aren't the ones that generate the most code, but the ones that constrain it correctly."
+
+## 7. Open collaboration builds institutional memory
+
+"Years of discussion, decisions, and tradeoffs remain searchable and visible. That history does not disappear into private email threads or internal systems."

package/vault/wiki/sources/ironclaw-drift-monitor.md

@@ -0,0 +1,80 @@
+---
+type: source
+status: ingested
+source_type: github-issue
+title: "ironclaw DriftMonitor — Anti-Drift Self-Checks in Agentic Loop"
+author: ilblackdragon (nearai)
+date_published: 2026-03-25
+url: https://github.com/nearai/ironclaw/issues/1634
+confidence: high
+key_claims:
+  - "Rule-based DriftMonitor detects 5 stuck patterns without additional LLM calls"
+  - "Corrections injected as system messages into LLM context"
+  - "Integrates via existing delegate hook system, no agentic_loop.rs changes"
+  - "Prior art: RuFlo's Continue Gate (checkpoint, rework ratio, budget slope)"
+tags:
+  - source
+  - drift-detection
+  - agent-loop
+  - ironclaw
+  - guardian-agent
+related:
+  - "[[Research: Meta-Agent Context Drift Detection]]"
+  - "[[context-drift-in-agents]]"
+  - "[[agent-loop-detection-patterns]]"
+created: 2026-05-02
+updated: 2026-05-02
+
+---# ironclaw DriftMonitor
+
+## Summary
+
+GitHub issue proposing a lightweight, rule-based `DriftMonitor` for the ironclaw agentic loop. Detects common failure patterns (repetition loops, failure spirals, tool cycling, silence drift, rework churn) and injects corrective system messages — without requiring additional LLM calls. This is the closest existing implementation to the meta-agent context drift detection concept.
+
+## What It Contributes
+
+This is the **primary prior art** for the meta-agent context drift detection concept. It implements detection + injection but does NOT implement context pruning or session restart. The proposed meta-agent extends this by adding pruning heuristics and escalation levels.
+
+## Five Detection Rules
+
+1. **Repetition** — Same tool + same param hash ≥3 times in last 10 calls → inject correction
+2. **Failure spiral** — ≥4 consecutive tool failures → inject "reassess approach"
+3. **Tool cycling** — A-B-A-B-A-B pattern in last 6 calls → inject "state what's blocking you"
+4. **Silence drift** — ≥15 iterations since last text response → inject "provide progress update"
+5. **Rework detection** — Same file written ≥3 times → inject "review before writing again"
+
+## Design Details
+
+- `DriftMonitor` struct with `original_goal`, `tool_history` (VecDeque), `IterationMetrics`, `DriftConfig`
+- `ToolCallRecord` has `name`, `params_hash` (u64), `succeeded`, `iteration`
+- Corrections injected as system messages (same pattern as existing `TOOL_INTENT_NUDGE`)
+- Configurable via env vars (`IRONCLAW_DRIFT_*`) or disabled entirely
+- Config struct: `enabled`, `repetition_window`, `repetition_threshold`, `max_consecutive_failures`, `cycle_detection_window`, `silence_threshold`, `max_file_rewrites`, `checkpoint_interval`
+
+## Future Extensions (Not in Scope)
+
+- **Semantic drift detection** — LLM-based check comparing current context to original goal
+- **Plan adherence** — Compare actual tool sequence to planned sequence
+- **Budget slope analysis** — Linear regression over token consumption windows
+- **Escalation levels** — Soft nudge → stronger → early loop exit
+
+## Integration Points
+
+| File | Change |
+|------|--------|
+| `src/agent/drift_monitor.rs` | **New** — struct + detection rules |
+| `src/agent/dispatcher.rs` | Add field, call check() in before_llm_call() |
+| `src/worker/job.rs` | Same integration for JobDelegate |
+| `src/agent/mod.rs` | Module declaration |
+
+No changes to `agentic_loop.rs` — delegates already own the hooks.
+
+## Relevance to Meta-Agent Concept
+
+The ironclaw DriftMonitor is detection + injection. The meta-agent concept adds:
+- **Context pruning**: Removing dead-end entries, not just injecting corrections
+- **Session restart**: Clean context after pruning
+- **Escalation model**: Soft → strong → forced restart
+- **Model-adaptive behavior**: Different detection frequencies per model profile
+
+The DriftMonitor validates that rule-based detection is feasible and effective. The missing piece — context pruning — is the novel contribution.