ultimate-pi 0.1.2 → 0.1.4

package/vault/wiki/sources/ts-best-practices-2025-devto.md

@@ -0,0 +1,42 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Mitu M"
+date_published: 2025-03-01
+url: "https://dev.to/mitu_mariam/typescript-best-practices-in-2025-57hb"
+confidence: medium
+key_claims:
+  - "Prefer `unknown` over `any` for unknown types with safer narrowing"
+  - "Enable `strictNullChecks` in tsconfig"
+  - "Use mapped types, template literal types, and conditional types for advanced patterns"
+  - "ESLint + Prettier for consistent code quality"
+  - "Nx for monorepo management with built-in TypeScript support"
+tags:
+  - typescript
+  - best-practices
+  - eslint
+  - tooling
+created: 2026-05-02
+updated: 2026-05-02
+
+---# TypeScript Best Practices in 2025
+
+Source: Mitu M (DEV Community), March 2025.
+
+## Summary
+
+Broad overview of TypeScript best practices for 2025. Covers type safety, type inference, advanced types, performance optimization, framework integration, and tooling. Written for frontend developers but applicable to full-stack.
+
+## Key Recommendations
+
+- **Type safety**: Use explicit types, prefer `unknown` over `any`, enable `strictNullChecks`
+- **Type inference**: Let TypeScript infer where possible; use `const` for immutable narrowing
+- **Advanced types**: Mapped types (`Readonly<...>`), template literal types, conditional types
+- **Performance**: Dynamic imports (`import()`) for code splitting; use Vite or ESBuild
+- **Linting**: ESLint with `plugin:@typescript-eslint/recommended` + Prettier
+- **Monorepo**: Nx for managing multiple TS projects with dependency graphs
+
+## Confidence
+
+Medium. Broad overview article with limited depth on any single topic. Serves as a good checklist but lacks detailed examples or benchmarks. Multiple claims align with other sources in this research.

package/vault/wiki/sources/ts-folder-structure-mingyang.md

@@ -0,0 +1,58 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Mingyang Li"
+date_published: 2024-01-05
+url: "https://mingyang-li.medium.com/production-grade-node-js-typescript-folder-structure-for-2024-f975edeabefd"
+confidence: medium
+key_claims:
+  - "Backend folders should be named by technical capability (Onion/Clean Architecture), not by feature"
+  - "Separate database logic into its own layer (repositories) distinct from services"
+  - "Separate 3rd-party SDK/API wrappers into their own folder (libs)"
+  - "Centralize environment variable access in one file for validation and autocompletion"
+  - "Feature-based structure (Vertical Slice) works better for frontend than backend"
+tags:
+  - typescript
+  - folder-structure
+  - nodejs
+  - architecture
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Production-Grade Node.js & TypeScript Folder Structure
+
+Source: Mingyang Li (Medium), January 2024.
+
+## Summary
+
+Practical guide to structuring Node.js/TypeScript backend projects. Recommends the Onion/Clean Architecture approach — folders named by technical capability rather than business feature. Covers separation of concerns and conventions for production codebases.
+
+## Recommended Structure
+
+```
+src/
+  routes/       — REST API route definitions (keep short)
+  controllers/  — Receive/return data to routes
+  services/     — Core business logic
+  repositories/ — Database logic only (data-in/data-out)
+  models/       — DB schema definitions (optional)
+  constants/    — Static project values
+  libs/         — 3rd-party SDK/API wrappers (Stripe, Shopify, etc.)
+  middlewares/  — Error parsing, auth, caching
+  types/        — Type definitions
+  validators/   — Input validation
+  common/       — Shared utilities
+```
+
+## Key Rules
+
+1. Keep code files separate from config files (`/src` vs root)
+2. Name folders by technical capability, not feature — business requirements change
+3. Separate DB logic into repositories (not in services)
+4. Isolate 3rd-party API/SDK code in `/libs`
+5. Centralize `env.ts` for validated, autocompleted environment variables
+
+## Confidence
+
+Medium. Single author, opinion piece. Concepts align with Clean Architecture but opinionated choice of technical over feature-based structure is contested.

package/vault/wiki/sources/ts-monorepo-koerselman.md

@@ -0,0 +1,44 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Thijs Koerselman"
+date_published: 2023-12-26
+date_updated: 2026-04-22
+url: "https://thijs-koerselman.medium.com/my-quest-for-the-perfect-ts-monorepo-62653d3047eb"
+confidence: high
+key_claims:
+  - "Two strategies for internal packages: built-package (with bundler) vs internal-packages (source-only)"
+  - "Turborepo + TypeScript project references provide fast, deterministic builds"
+  - "ESM is the future; CJS cannot import from ESM at top level"
+  - "Bundlers eliminate the need for `.js` extensions on relative imports"
+  - "Type definition map files (`.d.ts.map`) are needed for IDE go-to-definition across packages"
+tags:
+  - typescript
+  - monorepo
+  - turborepo
+  - esm
+created: 2026-05-02
+updated: 2026-05-02
+
+---# My Quest for the Perfect TS Monorepo
+
+Source: Thijs Koerselman (Medium), published December 2023, updated with 2026 addendum.
+
+## Summary
+
+Deep-dive into monorepo patterns for TypeScript projects. Covers build orchestration with Turborepo, ESM vs CJS challenges, internal package strategies, deployment isolation for Firebase, IDE go-to-definition setup, and live code updates.
+
+## Key Insights
+
+**Internal packages — two approaches**:
+1. **Built-package**: Build/bundle TS → JS, point `main` to output. Benefits: efficient caching, path aliases work, ESM output cleanly. Downsides: more config.
+2. **Internal-packages**: Point `main` to TS source directly, no build step. Benefits: simple, live updates. Downsides: no caching, slower builds, path aliases tricky.
+
+**Author's preference**: Built-package with bundler. Treat each package as self-contained unit.
+
+**ESM rules**: CJS cannot import ESM at top level (synchronous vs asynchronous). ESM requires file extensions on relative imports. `moduleResolution: "bundler"` allows `.ts` extensions.
+
+**IDE go-to-definition**: Use `declarationMap: true` + `tsc --emitDeclarationOnly` after bundler for type definition map files.
+
+**Works with**: [mono-ts boilerplate](https://github.com/0x80/mono-ts) (PNPM/NPM branches), Turborepo v2 watch mode, Firebase via `isolate-package`.

package/vault/wiki/sources/ts-result-error-handling-kkalamarski.md

@@ -0,0 +1,52 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Krzysztof Kalamarski"
+date_published: 2022-07-25
+url: "https://kkalamarski.me/a-declarative-approach-to-error-handling-in-typescript"
+confidence: medium
+key_claims:
+  - "Result<Ok, Err> monad treats errors as values, not exceptions"
+  - "wrap early, unwrap late — keep values in Result until display time"
+  - "Once a Result is Err, all subsequent map/flatMap operations are skipped"
+  - "match() method provides pattern matching for safe unwrapping"
+tags:
+  - typescript
+  - error-handling
+  - functional-programming
+  - result-monad
+created: 2026-05-02
+updated: 2026-05-02
+
+---# A Declarative Approach to Error Handling in TypeScript
+
+Source: Krzysztof Kalamarski (kkalamarski.me), July 2022.
+
+## Summary
+
+Introduces the Result monad pattern for declarative error handling in TypeScript. Instead of try-catch blocks scattered throughout code, wrap fallible operations in `Result<Ok, Err>` and compose transformations with `map`/`flatMap`. Unwrap at the boundary with `match`.
+
+## Core Pattern
+
+```typescript
+// Wrap: return Ok(value) or Err(error)
+const parseJson = (json: string): Result<User, Error> => {
+  try { return Ok(JSON.parse(json)); }
+  catch (e) { return Err(e); }
+};
+
+// Compose: operations only run on Ok values
+parseJson(input)
+  .map(user => user.name)
+  .match({
+    Ok: name => `Hello, ${name}`,
+    Err: error => 'Hello, Stranger'
+  });
+```
+
+**Key principle**: Once a Result is `Err`, all subsequent `map`/`flatMap` calls are no-ops. The error propagates without additional try-catch.
+
+## Confidence
+
+Medium. Pattern is well-established in functional programming (Rust, Haskell, Elm). Implementation is sound but the source is a single developer blog from 2022.

package/vault/wiki/sources/ts-runtimes-comparison-betterstack.md

@@ -0,0 +1,42 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Stanley Ulili"
+date_published: 2026-01-30
+url: "https://betterstack.com/community/guides/scaling-nodejs/nodejs-vs-deno-vs-bun/"
+confidence: high
+key_claims:
+  - "Bun handles 52,479 req/s vs Deno 22,286 vs Node.js 13,254 in Express benchmarks"
+  - "Deno leads in built-in tooling (REPL, linter, formatter, test runner)"
+  - "Node.js has experimental TypeScript support via `--experimental-strip-types`"
+  - "Deno is most secure by default with permissions model"
+  - "Bun excels in interoperability as drop-in Node.js replacement"
+tags:
+  - typescript
+  - runtimes
+  - nodejs
+  - deno
+  - bun
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Node.js vs Deno vs Bun: Comparing JavaScript Runtimes
+
+Source: Better Stack Community, Stanley Ulili, updated January 2026.
+
+## Summary
+
+Detailed comparison of the three major JavaScript/TypeScript runtimes across 12 dimensions: performance, dependency management, tooling, TypeScript support, security, community, web platform APIs, data storage, deployment, and interoperability. Includes benchmark data and feature comparison tables.
+
+## Key Findings
+
+**Performance**: Bun (52.5K req/s) > Deno (22.3K) > Node.js (13.3K) on Express benchmarks.
+
+**TypeScript**: Deno and Bun have first-class TS support (transpile automatically). Node.js v22+ has experimental `--experimental-strip-types` flag — limited, no enums/namespaces, requires `type` keyword for type imports.
+
+**Tooling**: Deno leads (built-in REPL, linter, formatter, test runner, debugger). Node.js has test runner and debugger. Bun has test runner, debugger, executables, but no REPL.
+
+**Security**: Deno has comprehensive permissions model + sandbox. Node.js v20+ has experimental permissions. Bun has minimal security features.
+
+**Recommendation**: Node.js remains best choice for production stability and ecosystem. Switch only if specific Bun/Deno features are critical.

package/vault/wiki/sources/ts-strict-mode-rishikc.md

@@ -0,0 +1,43 @@
+---
+type: source
+status: ingested
+source_type: article
+author: "Rishi Kumar Chawda"
+date_published: 2021-06-15
+date_updated: 2026-04-09
+url: "https://rishikc.com/articles/typescript-strict-mode-best-practices/"
+confidence: high
+key_claims:
+  - "`strict: true` enables 8+ compiler checks that prevent production bugs"
+  - "`strictNullChecks` is the single most impactful setting"
+  - "Incremental migration to strict mode is practical for existing codebases"
+  - "Strict mode has negligible compilation performance impact"
+  - "Pair strict mode with ESLint `@typescript-eslint/recommended-type-checked` for defense-in-depth"
+tags:
+  - typescript
+  - strict-mode
+  - type-safety
+created: 2026-05-02
+updated: 2026-05-02
+
+---# TypeScript Strict Mode: Best Practices for Production Code
+
+Source: Rishi Kumar Chawda, published 2021, updated April 2026.
+
+## Summary
+
+Comprehensive guide to TypeScript strict mode compiler options. Covers all 8+ sub-flags enabled by `"strict": true`, with code examples showing the difference between loose and strict configurations. Provides a practical migration strategy for existing codebases and pairs strict mode with ESLint rules for maximum type safety.
+
+## Key Contributions
+
+**Strict mode sub-flags**: `noImplicitAny`, `strictNullChecks`, `strictFunctionTypes`, `strictPropertyInitialization`, `noImplicitThis`, `useUnknownInCatchVariables`, `alwaysStrict`, `strictBindCallApply`, `strictBuiltinIteratorReturn` (TS 5.6+).
+
+**Migration pattern**: Enable strict checks one at a time, fix errors per module, move on. Two weeks covers core business logic with minimal disruption.
+
+**Strict mode + ESLint**: Combine with `@typescript-eslint/no-explicit-any`, `no-non-null-assertion`, `explicit-function-return-types`, `no-floating-promises`.
+
+**Gotchas**: Optional (`?`) vs nullable (`| null`) are different concepts; strict mode doesn't catch floating promises — needs ESLint; `as` assertions are temporary escape hatches, not permanent solutions.
+
+## Confidence
+
+High. Multiple TypeScript compiler docs and community sources agree on these settings. Author demonstrates production experience with migrations.

package/vault/wiki/sources/unix-philosophy.md

@@ -0,0 +1,48 @@
+---
+type: source
+source_type: encyclopedia
+title: "Unix Philosophy"
+author: "Wikipedia contributors; originating from Ken Thompson, Dennis Ritchie, Doug McIlroy"
+date_published: 2025
+url: "https://en.wikipedia.org/wiki/Unix_philosophy"
+confidence: high
+key_claims:
+  - "Write programs that do one thing and do it well"
+  - "Write programs to work together"
+  - "Write programs to handle text streams, because that is a universal interface"
+  - "The power of a system comes more from the relationships among programs than from the programs themselves"
+  - "Everything was small... What can we throw out?"
+  - "Prototype software before polishing it"
+tags: [unix, philosophy, composability, pipes, minimalism]
+---
+
+# Unix Philosophy
+
+## Core Tenets (Doug McIlroy, 1978)
+
+1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
+2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information.
+3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away clumsy parts and rebuild them.
+4. Use tools in preference to unskilled help to lighten a programming task.
+
+## The 1994 Summary (Peter Salus, crediting McIlroy)
+
+- Write programs that do one thing and do it well.
+- Write programs to work together.
+- Write programs to handle text streams, because that is a universal interface.
+
+## Eric Raymond's 17 Unix Rules (The Art of Unix Programming, 2003)
+
+Key rules: Build modular programs. Write readable programs. Use composition. Separate mechanisms from policy. Write simple programs. Write small programs. Write transparent programs. Write robust programs. Make data complicated when required, not the program. Value developer time over machine time. Prototype before polishing.
+
+## McIlroy's Critique of Linux Bloat
+
+Douglas McIlroy: "Adoring admirers have fed Linux goodies to a disheartening state of obesity. Everything was small... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option."
+
+## Worse is Better (Richard P. Gabriel)
+
+Unix embodied "worse is better": simplicity of interface and implementation matters more than correctness, consistency, and completeness. This design style has key evolutionary advantages.
+
+## The Pipes Breakthrough
+
+The vertical bar (`|`) emerged from Doug McIlroy's long-standing desire for program composition. Ken Thompson implemented it. The notation "just clicked instantly." Within days, there was a "frenzy of going in and fixing up programs so that they would work properly in pipelines." Sort was repackaged to read stdin and write stdout — a pattern now used daily by millions.

package/vault/wiki/sources/vectara-chunking-vs-embedding-naacl2025.md

@@ -0,0 +1,39 @@
+---
+type: source
+status: ingested
+source_type: research-paper
+author: Vectara Research Team
+date_published: 2024-10-16
+url: https://arxiv.org/abs/2410.13070
+confidence: high
+key_claims:
+  - "Chunking configuration influences retrieval quality as much as or more than embedding model selection"
+  - "Tested 25 chunking configurations with 48 embedding models"
+  - "Published at NAACL 2025 (peer-reviewed)"
+  - "Recursive 512-token splitting with 10-20% overlap is benchmark-validated default for general RAG"
+tags:
+  - chunking
+  - embedding-models
+  - rag
+  - retrieval-quality
+  - naacl
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Vectara NAACL 2025: Chunking Strategy vs Embedding Model
+
+## Summary
+
+Peer-reviewed paper (NAACL 2025, arXiv:2410.13070) from Vectara evaluating the relative impact of chunking strategy vs embedding model choice on RAG retrieval quality. Massive study: 25 chunking configurations × 48 embedding models.
+
+## Key Finding
+
+**Chunking configuration had as much or more influence on retrieval quality as the choice of embedding model.** This means teams that obsess over embedding model selection while ignoring chunking strategy are optimizing the wrong variable.
+
+## Practical Defaults
+- Recursive 512-token splitting with 10-20% overlap is the benchmark-validated default for general RAG
+- Chunking is the highest-leverage optimization most teams underinvest in
+
+## Relevance to Our Implementation
+
+Validates that our AST-aware chunking strategy is the right investment. We should prioritize chunking quality over embedding model selection. Even MiniLM-L6-v2 with good chunking can outperform larger models with poor chunking.

package/vault/wiki/sources/vectara-guardian-agents.md

@@ -0,0 +1,79 @@
+---
+type: source
+status: ingested
+source_type: blog
+title: "Guardian Agents Benchmark"
+author: Vishal Naik, Chenyu Xu (Vectara)
+date_published: 2025-11-21
+url: https://www.vectara.com/blog/guardian-agents-benchmark
+confidence: high
+key_claims:
+  - "Platform-agnostic benchmark with ~900 real-world scenarios across 6 domains"
+  - "Overall Correct rate only 5-59% across platforms (LlamaIndex, LangChain; GPT-5, Claude Sonnet 4.5)"
+  - "Most failures from missing required tool calls and incorrect tool selection"
+  - "Guardian Agents: pre-execution safety layer validating tools, arguments, and sequencing"
+  - "Repeated tool calls are a significant failure category"
+tags:
+  - source
+  - guardian-agents
+  - benchmark
+  - agent-reliability
+  - vectara
+related:
+  - "[[Research: Meta-Agent Context Drift Detection]]"
+  - "[[guardian-agent-pattern]]"
+  - "[[context-drift-in-agents]]"
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Vectara Guardian Agents Benchmark
+
+## Summary
+
+Vectara built a platform-agnostic benchmark evaluating agents in their actual operating environments (not simulated sandboxes). Across 907 real-world scenarios and 6 domains, overall correct rate ranged from 5-59% — even when response quality appeared high, tool-call correctness was low. Introduces Guardian Agents as a pre-execution safety layer that validates proposed tool calls before they run.
+
+## What It Contributes
+
+Provides hard numbers on agent tool-call reliability: the gap between response quality (often 50%+) and overall correctness (5-59%) is enormous. Validates that repeated tool calls and incorrect tool selection are dominant failure modes. The Guardian Agent concept (pre-execution validation) is a complementary approach to the meta-agent (post-execution detection + pruning).
+
+## Benchmark Design
+
+- **Scenario engine**: LLM-driven pipeline generating test scenarios with happy paths and adversarial variations
+- **Dual evaluation**: Response Correctness (did the answer use tool outputs correctly?) + Action Trace Correctness (did the agent select/sequence/parameterize tools correctly?)
+- **Failure taxonomy**: Incorrect tool selection, invalid/missing parameters, missing required tool calls, repeated tool calls, incorrect sequencing
+
+## Six Domains
+
+Email, Calendar, Financial Analysis, Customer Service, Internal Knowledge Retrieval, Business Intelligence
+
+## Key Results
+
+| Configuration | Response Correct | Action Trace Correct | Overall Correct |
+|--------------|-----------------|---------------------|-----------------|
+| GPT-5 + LangChain | ~70% | ~30% | ~25% |
+| Claude Sonnet 4.5 + LangChain | ~65% | ~25% | ~20% |
+| GPT-5 + LlamaIndex | ~55% | ~15% | ~10% |
+| Claude Sonnet 4.5 + LlamaIndex | ~60% | ~10% | ~5% |
+
+Action trace correctness is the bottleneck — agents produce fluent answers but execute tools incorrectly.
+
+## Failure Distribution
+
+- Missing required tool calls: 35-45% of failures
+- Incorrect tool selection: 25-35%
+- Repeated tool calls: 10-15%
+- Invalid parameters: 10-15%
+- Incorrect sequencing: 5-10%
+
+## Guardian Agents
+
+Pre-execution safety layer with three checks:
+1. **Unnecessary tools**: Blocks irrelevant/unsafe actions
+2. **Missing required tools**: Ensures plan includes all needed tools
+3. **Argument validation**: Checks correctness, presence, structure of arguments
+
+Feedback aggregated and sent back to agent for plan revision. Capped retries to avoid infinite loops.
+
+## Relevance to Meta-Agent Concept
+
+Vectara's Guardian Agents validate proactively (before execution). The meta-agent detects reactively (after stuck pattern emerges). These are complementary: Guardian Agents as first line of defense, meta-agent as recovery mechanism when the agent gets past the guardian but still gets stuck. The failure taxonomy validates that repeated tool calls (10-15% of failures) are a real problem worth detecting.

package/vault/wiki/sources/vgrep-semantic-search.md

@@ -0,0 +1,76 @@
+---
+type: source
+source_type: official-documentation
+title: "vgrep: Privacy-First Semantic Search Engine"
+author: CortexLM
+date_published: 2025
+url: https://github.com/CortexLM/vgrep
+confidence: medium
+key_claims:
+  - "vgrep is a fully local semantic search engine using vector embeddings"
+  - "Client-server architecture for fast repeated searches"
+  - "GPU acceleration via CUDA, Metal, and Vulkan"
+  - "Runs entirely on your machine with no external API calls"
+tags:
+  - code-search
+  - semantic-search
+  - embeddings
+  - privacy
+  - rust
+related:
+  - "[[vgrep-tool]]"
+  - "[[Research: semantic code search tools]]"
+created: 2026-04-30
+updated: 2026-04-30
+status: ingested
+
+---# vgrep: Privacy-First Semantic Search Engine
+
+## Summary
+
+vgrep (CortexLM/vgrep, 144 ⭐) is a Rust-based client-server semantic search engine that uses vector embeddings to search code, documents, and text by meaning. It runs entirely locally with optional GPU acceleration.
+
+## What It Contributes
+
+vgrep is the strongest architectural alternative to ck: client-server model (daemon + CLI) means repeated searches are fast without re-indexing. GPU acceleration (CUDA/Metal/Vulkan) can provide 10x speedup for embedding generation. However, it lacks grep-compatible flags and MCP integration (as of April 2026).
+
+## Key Capabilities
+
+| Capability | Details |
+|---|---|
+| **Semantic Search** | Vector embedding-based, search by intent not keywords |
+| **Client-Server** | Daemon maintains index in memory; CLI queries are instant |
+| **GPU Acceleration** | CUDA, Metal, Vulkan for 10x faster embeddings |
+| **Privacy** | 100% local, no telemetry, no external services |
+| **Multi-format** | Code, documents, text — not limited to code |
+| **Custom Models** | Supports different embedding models |
+
+## Setup
+
+```bash
+vgrep init              # ~1GB model download
+vgrep models download   # additional models
+# Then: vgrep server start && vgrep search "query"
+```
+
+## System Requirements
+
+| Component | Minimum | Recommended |
+|-----------|---------|-------------|
+| RAM | 2 GB | 4+ GB |
+| Disk | 1 GB | 2+ GB |
+| CPU | 4 cores | 8+ cores |
+| GPU | Optional | CUDA/Metal |
+
+## Limitations (Observed)
+
+1. **No grep compatibility**: Not a drop-in replacement. Different CLI syntax entirely.
+2. **No MCP integration**: No built-in MCP server. Would need custom wrapper for AI agent use.
+3. **Smaller community**: 144 stars vs ck's 1,572. Less documentation, fewer contributors.
+4. **Model download required**: Initial setup requires ~1GB download. ck downloads models on first use.
+5. **No hybrid (lexical+semantic) search**: Pure embedding search. No BM25/RRF fusion.
+6. **No editor integration**: CLI-only. No VSCode/Cursor extension.
+
+## Confidence Assessment
+
+**Medium confidence** — documentation is thinner than ck's. Key architectural claims (client-server, GPU acceleration) are verifiable from the Rust codebase. The absence of MCP integration is a significant gap for AI agent use cases. Community size and update frequency suggest a side project, not an actively maintained product.

package/vault/wiki/sources/vitest-official.md

@@ -0,0 +1,41 @@
+---
+type: source
+status: ingested
+source_type: official-documentation
+author: "Vitest Contributors / VoidZero Inc."
+date_published: 2026
+url: "https://vitest.dev/"
+confidence: high
+key_claims:
+  - "Vite-native test runner that reuses Vite config, resolve, and transform pipelines"
+  - "Jest-compatible API (expect, snapshots, coverage) for easy migration"
+  - "Smart watch mode: only rerun related changes, like HMR for tests"
+  - "Out-of-box ESM, TypeScript, and JSX support powered by Oxc"
+  - "Current version: v4.1.5"
+tags:
+  - typescript
+  - testing
+  - vitest
+  - vite
+created: 2026-05-02
+updated: 2026-05-02
+
+---# Vitest: Next Generation Testing Framework
+
+Source: Official Vitest documentation (vitest.dev), 2026.
+
+## Summary
+
+Vitest is a Vite-native testing framework designed for modern JavaScript/TypeScript projects. It integrates with Vite's config and plugin ecosystem, provides Jest-compatible APIs, and supports ESM, TypeScript, and JSX out of the box.
+
+## Key Features
+
+- **Vite-powered**: Reuses Vite config, plugins, resolve/transform pipelines. Works without Vite too.
+- **Jest compatible**: `expect`, `describe`/`it`, snapshots, coverage — familiar API.
+- **Smart watch mode**: Only reruns tests affected by code changes (HMR for tests).
+- **ESM + TypeScript**: Native support via Oxc transpiler. No additional config needed.
+- **Current version**: v4.1.5 (2026). Maintained by VoidZero Inc. and community.
+
+## When to Use
+
+Primary choice for projects already using Vite. Also suitable for non-Vite Node.js backends. Migration from Jest is straightforward due to compatible API.

package/vault/wiki/sources/vscode-pi-community-extension.md

@@ -0,0 +1,40 @@
+---
+type: source
+source_type: marketplace-listing
+title: "pi Agent for VS Code"
+author: "Cem Dervis"
+date_published: 2026-04-14
+date_accessed: 2026-05-05
+url: "https://marketplace.visualstudio.com/items?itemName=cdervis.vscode-pi"
+confidence: high
+tags:
+  - pi-agent
+  - vscode
+  - extension
+  - community
+  - rpc
+key_claims:
+  - "Community-built unofficial VS Code extension for Pi"
+  - "352 installs, version 0.13.0, last updated 2026-05-03"
+  - "Runs local pi binary in RPC mode and presents VS Code-native chat workflow"
+  - "Supports prompts, skills, extensions, model switching, compaction, and rich tool rendering"
+  - "Explicitly states not affiliated with or endorsed by official Pi project"
+---
+
+# Community VS Code Pi Extension (cdervis.vscode-pi)
+
+## Summary
+
+This source captures the strongest community alternative to the official pi0 extension. It provides a full sidebar/chat UX, rich rendering, session controls, and RPC-driven integration with local Pi binary.
+
+## Key Details
+
+- Install count: 352
+- Version: 0.13.0
+- Released: 2026-04-14
+- Last updated: 2026-05-03
+- Positioning: Unofficial, community-built, prerelease phase
+
+## Why This Matters for Topic
+
+When users ask for "vcc extension" or "pi coding agent extension", they may mean the best UX extension in practice, not only official extension. This listing shows ecosystem plurality and compatibility tradeoffs.