docs: reorganize research files into structured subfolders

- Moved v2 model responses to docs/research/v2-responses/
- Moved v3-v6 responses to docs/research/v3-responses/
- Moved context dumps to docs/research/context-files/
- Moved prompt templates to docs/research/prompts/
- Fixed relative links in multi-model-code-review-analysis.md
- Added Deep Think v3 multi-model prompt
- Generated v3 context files (signatures + full)

Author: igorls

docs/research/Babysitter v0.0.166.md

@@ -0,0 +1,115 @@
+Based on the structural AST analysis of the babysitter monorepo, here is a deep-dive assessment of the architecture, security posture, code quality, and strategic recommendations.
+
+### ---
+
+**Part 1: Architecture Assessment**
+
+**1\. Monorepo Structure & Responsibilities**
+
+* **The "Core" Misnomer**: The prompt describes packages/babysitter as the core agent runtime, but the AST reveals it is merely a 264-byte CLI wrapper (bin/babysitter.js). The true core orchestration engine—containing the runtime, replay engine, storage, and tasks—lives entirely inside packages/sdk.  
+* **Leaky Domain Logic**: packages/catalog (the Next.js UI) implements deep compiler-level logic inside src/lib/parsers/ (parsing ASTs, JSDoc, and directory structures). A UI package should not be responsible for source-code traversal.  
+* **Duplication**: Because catalog hoards the AST parsing logic, packages/vscode-extension is forced to reinvent the exact same wheel in src/core/processCatalog.ts to extract function signatures and exports via the TypeScript compiler API.
+
+**2\. Plugin System (plugins/)**
+
+* **Imperative Proliferation**: The methodologies/ directory is an architectural red flag. Files like rup.js (2,565 lines), shape-up.js (1,569 lines), and waterfall.js (1,409 lines) are monolithic.  
+* **Copy-Paste Explosion**: Based on the function signatures, almost all methodologies redundantly declare identical localized tasks (e.g., agentPlanningTask, executeTask, validateTask, qualityScoringTask). The 530K lines mentioned in your prompt are largely imperative boilerplate. The platform lacks a declarative State-Machine or DAG abstraction, forcing developers to manually reinvent execution loops and state transitions for every methodology.
+
+**3\. Package Boundaries**
+
+* Package boundaries are frequently bypassed. Instead of communicating through stable API contracts exposed by the sdk, the vscode-extension directly reads the SDK's internal .a5c storage files from disk (e.g., core/runDiscovery.ts, core/runDetailsSnapshot.ts). This tightly couples the IDE extension to the SDK's internal storage layout; if the SDK changes its journal or cache format, the extension will silently break.
+
+**4\. Entry Points & Startup Flow**
+
+* breakpoints/bin/breakpoints.js has a clean startup flow, properly delegating to discrete command functions.  
+* sdk/src/cli/main.ts is a massive **"God File"** (1,552 lines, 75 functions). It hand-rolls its own CLI parsing (parseArgs, expectFlagValue) and handles everything from routing to journal repair and state rebuilding in a single file instead of leveraging a robust CLI framework like commander or yargs.
+
+### ---
+
+**Part 2: Security Review**
+
+**1\. API Surface**
+
+* **Path Traversal (LFI) Risks**: breakpoints/api/routes.js serves files via resolveContextPath(requestedPath). While the naming implies normalization (rootWithSep), serving local disk files via an HTTP API based on user input is inherently dangerous if the path-normalization logic allows ../ escaping or symlink following.  
+* **Unauthenticated DoS/SSRF**: catalog/src/app/api/reindex/route.ts exposes a POST method that accepts a baseDir from the request body to trigger runFullIndex(baseDir). Without authentication, an attacker can force the server to index arbitrary directories (e.g., /etc or \~/.ssh), causing CPU/Disk exhaustion (Denial of Service) and exposing host file metadata to the search API.
+
+**2\. Database Layer**
+
+* **breakpoints/api/db.js**: Safely wraps raw sqlite3 driver queries using parameterized arrays (run(db, sql, params \= \[\])), preventing basic SQL injection.  
+* **catalog/src/lib/db/queries.ts**: Utilizes a custom QueryBuilder class (879 lines). Custom ORMs are historically risky, but the API utilities (catalog/src/lib/api/utils.ts) use safe allowlists (mapSortField, buildOrderClause) to strictly validate sorting keys before injecting them into ORDER BY clauses.
+
+**3\. Extension System (Telegram)**
+
+* breakpoints/extensions/telegram.js handles long-polling webhooks and caches user configurations (persistUser(db, config, chatId, userId)). This indicates Telegram Bot tokens and user chat IDs are stored in plaintext in the local SQLite DB. If the DB is compromised via the aforementioned path traversal, the bot credentials are leaked.
+
+**4\. Python Scripts (.a5c/orchestrator\_scripts/)**
+
+*(Inferred based on architectural context for LLM orchestrators):*
+
+* **JSON Repair Vectors**: If the scripts use eval() or ast.literal\_eval() on unescaped LLM outputs to fix broken JSON, it introduces a critical Arbitrary Code Execution (ACE) vulnerability. json.loads must be strictly enforced.  
+* **Prompt Injection**: If prompt rendering uses standard f-strings or .format() to concatenate untrusted LLM outputs or codebase contents, it opens the engine to prompt injection. Safe templating (like Jinja2) with strict separation of context and instructions is required.
+
+### ---
+
+**Part 3: Code Quality**
+
+**1\. Complexity Hotspots (God Files)**
+
+* **vscode-extension/src/extension/runDetailsView.ts**: **2,571 lines**. A severe anti-pattern that mixes VS Code Webview HTML generation, IPC message routing, file-system watching, and state management in one file.  
+* **catalog/src/app/search/page.tsx**: **1,130 lines**. A massive frontend component hoarding state management, debouncing, API querying, and UI rendering.  
+* **catalog/src/lib/db/indexer.ts**: **856 lines**. Deeply nested file-system traversal mixed with SQLite batch inserts.
+
+**2\. Naming Conventions**
+
+* Function and class naming are highly consistent (camelCase for variables/functions, PascalCase for React components/classes).  
+* File naming is slightly fragmented: kebab-case dominates catalog and plugins (process-library-catalog.js), while camelCase is used in the sdk (commitEffectResult.ts).
+
+**3\. Type Safety**
+
+* **Strong**: sdk, catalog, and vscode-extension are written in rigorous TypeScript with strict interfaces.  
+* **Weak (High Risk)**: breakpoints and the \~1,900 files in plugins/ are written in **plain JavaScript**. Given that breakpoints handles async worker queues and HTTP payloads, and plugins orchestrate the complex state machine, the lack of static typing here guarantees runtime TypeError crashes when the SDK's state shape inevitably evolves.
+
+**4\. Test Coverage**
+
+* **Excellent**: sdk and vscode-extension have phenomenal test coverage visible in the AST (deterministic testing harnesses, snapshot testing, fake resolvers).  
+* **Gaping Holes**: catalog, breakpoints, and plugins have **zero visible test files**. The highly complex 850-line custom file system indexer in the catalog and the background worker queue in breakpoints are completely untested by automated suites.
+
+### ---
+
+**Part 4: Strategic Recommendations**
+
+Top 5 highest-impact improvements, ranked by (Value × Feasibility):
+
+#### **1\. Consolidate AST & File System Logic into a Shared Package**
+
+* **Problem**: Both the catalog UI and vscode-extension implement custom compiler-level logic to crawl the filesystem, parse source code for JSDoc, and extract AST metadata.  
+* **Design**: Extract catalog/src/lib/parsers and vscode-extension/src/core/processCatalog.ts into a new @babysitter/parser (or @babysitter/core) package. Both tools should consume this unified API.  
+* **Complexity**: **Medium** (Surgical imports/exports; high payoff for maintainability).
+
+#### **2\. Secure the Catalog Reindex API & Breakpoints Path Traversal**
+
+* **Problem**: POST /api/reindex takes an unsanitized baseDir (DoS/Arbitrary File Indexing), and Breakpoints serves local files via HTTP.  
+* **Design**:  
+  1. Remove baseDir from the Catalog API payload; rely strictly on a server-side environment variable (e.g., BABYSITTER\_WORKSPACE). Add basic authentication to Next.js mutation routes.  
+  2. In breakpoints, ensure resolveContextPath strictly validates path.resolve(requestedPath).startsWith(repoRoot).  
+* **Complexity**: **Small** (Immediate security win with \< 50 lines of code).
+
+#### **3\. Decompose the "God Files" (runDetailsView.ts & cli/main.ts)**
+
+* **Problem**: runDetailsView.ts (2.5k lines) and cli/main.ts (1.5k lines) paralyze feature additions and cause constant merge conflicts.  
+* **Design**:  
+  * **CLI**: Adopt the Command Pattern using commander or yargs (split into commands/runCreate.ts, commands/runStatus.ts).  
+  * **VS Code**: Separate the Webview into three distinct layers: a React/UI app compiled separately, a MessageBridge for RPC calls, and a filesystem StateController.  
+* **Complexity**: **Medium**
+
+#### **4\. Abstract Process Methodologies into a Declarative Framework**
+
+* **Problem**: 530K lines of imperative, copy-pasted JS across methodologies (rup.js, agile.js) make the plugin ecosystem unmaintainable and highly prone to runtime bugs.  
+* **Design**: Move away from imperative monolithic JS files. Create a declarative DAG (Directed Acyclic Graph) or State Machine engine inside the SDK. Methodologies should become lightweight YAML/JSON configs (or typed TS builders) that simply compose strictly typed tasks from a shared @babysitter/skills registry.  
+* **Complexity**: **Large** (Requires runtime refactoring, but drastically reduces maintenance burden and repository size).
+
+#### **5\. Migrate breakpoints to TypeScript & Add Tests**
+
+* **Problem**: The debugging infrastructure (API, Worker queue, Telegram webhook) handles external inputs and DB concurrency but is written in plain JS with zero tests.  
+* **Design**: Incrementally rename .js to .ts. Share DTO types with the SDK to strongly type SQLite schemas, worker jobs, and HTTP requests. Add baseline unit tests for the worker/queue.js state machine.  
+* **Complexity**: **Medium**