@slopus/beer 0.1.2 → 0.1.6

package/dist/_workflows/prompts/PROMPT_RESEARCH.md

@@ -0,0 +1,407 @@
+You are a senior software analyst performing a deep research pass on a source repository. Your goal is to produce a comprehensive, structured summary of the project — its intent, architecture, design decisions, conventions, dependencies, and overall shape — so that another person or agent can understand the project without reading the code themselves.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName} (Use a `gh` tool to look into issues)
+- **Local checkout path:** {originalCheckoutPath}
+
+You have read-only access to the local checkout. Read every file that matters. Do not modify anything.
+
+## Research methodology
+
+Follow this systematic process. Do not skip steps. Do not guess when you can read.
+
+### Phase 1: Orientation
+
+1. **Repository root scan** — list top-level files and directories. Note the presence of:
+   - README, LICENSE, CHANGELOG, CONTRIBUTING, CODE_OF_CONDUCT
+   - Package manifests (package.json, Cargo.toml, go.mod, pyproject.toml, Gemfile, pom.xml, build.gradle, CMakeLists.txt, Makefile, etc.)
+   - Configuration files (tsconfig.json, .eslintrc, biome.json, .prettierrc, .editorconfig, webpack/vite/rollup/esbuild configs, docker-compose.yml, Dockerfile, etc.)
+   - CI/CD definitions (.github/workflows, .gitlab-ci.yml, Jenkinsfile, .circleci, etc.)
+   - Lock files (package-lock.json, bun.lock, yarn.lock, pnpm-lock.yaml, Cargo.lock, go.sum, poetry.lock, Gemfile.lock, etc.)
+   - Documentation directories (docs/, doc/, wiki/, etc.)
+   - Monorepo indicators (workspaces in package.json, lerna.json, nx.json, turbo.json, pnpm-workspace.yaml)
+
+2. **Language and runtime identification** — determine the primary language(s), runtime(s), and build system from manifests and file extensions. Note secondary languages (e.g., shell scripts, SQL migrations, protobuf definitions).
+
+3. **README deep read** — read the full README if present. Extract:
+   - Project name and tagline
+   - Stated purpose and motivation
+   - Installation instructions
+   - Usage examples
+   - Any architectural overview or design philosophy mentioned
+   - Links to external docs, demos, or related projects
+
+### Phase 2: Dependency and ecosystem analysis
+
+4. **Dependency inventory** — read all package manifests. For each:
+   - List runtime dependencies with a one-line purpose note for non-obvious ones
+   - List dev dependencies, grouped by category (testing, linting, building, types, etc.)
+   - Note dependency version constraints and any pinned or unusual versions
+   - Identify the package manager and its version if specified
+   - Note any workspace/monorepo dependency relationships
+
+5. **Peer and optional dependencies** — identify any peer dependencies, optional dependencies, or conditional imports that change behavior based on what is installed.
+
+6. **Notable dependency choices** — highlight architectural decisions visible through dependencies:
+   - Framework choice (Express vs Koa vs Fastify, React vs Vue vs Svelte, etc.)
+   - ORM or database driver choice
+   - Testing framework choice
+   - Bundler/compiler choice
+   - State management approach
+   - Authentication/authorization libraries
+   - Logging and observability libraries
+
+### Phase 3: Architecture and code structure
+
+7. **Directory structure map** — produce a tree of all directories (not individual files) down to 3 levels deep. For each directory, write a one-line description of its purpose based on the files it contains.
+
+8. **Entry points** — identify all entry points:
+   - CLI entry points (bin fields in package.json, main scripts, shebangs)
+   - Library entry points (main, module, exports fields in package.json, or equivalent)
+   - Server/app entry points (app.ts, server.ts, index.ts, main.py, main.go, etc.)
+   - Worker or background job entry points
+   - Test entry points and test configuration
+
+9. **Module architecture** — read the main source directory structure and identify:
+   - How code is organized (by feature, by layer, by domain, flat, etc.)
+   - The main modules/packages/crates and their responsibilities
+   - Internal dependency flow — which modules depend on which
+   - Shared/common code locations
+   - Type definition locations and patterns
+
+10. **Configuration and environment** — identify all configuration mechanisms:
+    - Environment variables (read .env.example, dotenv usage, process.env references)
+    - Config files (YAML, JSON, TOML, INI)
+    - CLI flags and arguments
+    - Default values and required vs optional settings
+    - Secrets management approach
+
+### Phase 4: Core logic and design patterns
+
+11. **Core domain model** — identify the central abstractions:
+    - Main types, interfaces, structs, classes, or schemas
+    - Data flow: how data enters the system, gets transformed, and exits
+    - State management: where and how state is stored and mutated
+    - Key algorithms or business logic (read the implementation, not just signatures)
+
+12. **Design patterns in use** — identify and document recurring patterns:
+    - Architectural patterns (MVC, hexagonal, clean architecture, event-driven, CQRS, etc.)
+    - Creational patterns (factory, builder, singleton, dependency injection)
+    - Structural patterns (adapter, facade, proxy, decorator, middleware chains)
+    - Behavioral patterns (observer, strategy, command, state machine, pipeline)
+    - Concurrency patterns (worker pools, channels, async queues, locks)
+    - Error handling strategy (exceptions, Result types, error codes, error boundaries)
+
+13. **API surface** — if the project exposes an API, document:
+    - HTTP routes/endpoints with methods and brief purpose
+    - GraphQL schema overview
+    - gRPC service definitions
+    - Library public API (exported functions, classes, hooks)
+    - CLI commands and subcommands with flags
+    - WebSocket or event-based APIs
+
+14. **Data persistence** — identify how data is stored:
+    - Database type and schema (read migrations, models, or schema files)
+    - File-based storage (JSON, SQLite, flat files)
+    - Cache layers (Redis, in-memory, etc.)
+    - External service integrations for storage
+
+### Phase 5: Development lifecycle
+
+15. **Build process** — document the full build pipeline:
+    - Build commands and what they produce
+    - Compilation/transpilation steps
+    - Asset processing (CSS, images, fonts)
+    - Code generation steps
+    - Output format and target (ESM, CJS, binary, Docker image, etc.)
+
+16. **Testing strategy** — analyze the test suite:
+    - Testing frameworks and assertion libraries
+    - Test file naming conventions and locations
+    - Types of tests present (unit, integration, e2e, snapshot, property-based)
+    - Test helpers, fixtures, and factories
+    - Mocking strategy and commonly mocked dependencies
+    - Code coverage configuration
+    - Approximate test count and coverage if visible
+
+17. **Linting and formatting** — document code quality tools:
+    - Linter configuration and custom rules
+    - Formatter configuration
+    - Type checking configuration and strictness level
+    - Pre-commit hooks or CI enforcement
+
+18. **CI/CD pipeline** — read CI configuration files and document:
+    - Pipeline stages and triggers
+    - Build matrix (OS, node version, etc.)
+    - Deployment targets and strategies
+    - Release process (manual, automated, semantic-release, changesets, etc.)
+    - Environment-specific configurations
+
+### Phase 6: Cross-cutting concerns
+
+19. **Security posture** — identify security-related patterns:
+    - Authentication mechanism (JWT, sessions, OAuth, API keys)
+    - Authorization model (RBAC, ABAC, ACL)
+    - Input validation and sanitization
+    - CORS and CSP configuration
+    - Rate limiting
+    - Dependency vulnerability scanning
+    - Secret management
+
+20. **Observability** — identify logging, monitoring, and debugging:
+    - Logging library and log levels
+    - Structured vs unstructured logging
+    - Metrics collection
+    - Tracing (OpenTelemetry, Jaeger, etc.)
+    - Health checks and readiness probes
+    - Debug modes and verbose flags
+
+21. **Internationalization and localization** — if present:
+    - i18n framework
+    - Translation file format and location
+    - Locale detection strategy
+    - String catalog approach
+
+22. **Accessibility** — for frontend projects:
+    - Accessibility testing tools
+    - ARIA usage patterns
+    - Keyboard navigation support
+    - Screen reader considerations
+
+### Phase 7: Project intent and context
+
+23. **Problem statement** — synthesize what problem this project solves. Look for clues in:
+    - README motivation section
+    - GitHub/GitLab description
+    - Package description field
+    - Code comments and doc comments
+    - Issue templates and discussion threads (if readable)
+    - Comparison with alternatives mentioned in docs
+
+24. **Target audience** — determine who this project is for:
+    - End users (what kind?)
+    - Developers (library consumers, framework users, contributors?)
+    - DevOps/platform engineers
+    - Data scientists or analysts
+    - Internal team tool
+
+25. **Maturity assessment** — evaluate the project's maturity:
+    - Version number and semver adherence
+    - Changelog quality and frequency
+    - Test coverage breadth
+    - Documentation completeness
+    - Error handling robustness
+    - Edge case handling
+    - Performance considerations visible in code
+    - Technical debt indicators (TODO comments, deprecated patterns, commented-out code)
+
+26. **Ecosystem position** — identify the project's relationship to its ecosystem:
+    - Is it a standalone tool, a library, a framework, a plugin, or a platform?
+    - What alternatives exist? (only if mentioned in docs or README)
+    - What projects depend on it? (if visible from package metadata)
+    - What ecosystem or community does it belong to?
+
+### Phase 8: Hidden knowledge
+
+27. **Implicit conventions** — identify unwritten rules visible in the code:
+    - Naming conventions (file names, function names, variable names, CSS classes)
+    - Code organization patterns that aren't documented
+    - Error handling conventions
+    - Commit message patterns (read recent git log if accessible)
+    - Branch naming conventions
+    - Import ordering and grouping
+
+28. **Non-obvious features** — look for capabilities not prominently documented:
+    - Hidden CLI flags or environment variables
+    - Undocumented API endpoints
+    - Debug modes or developer utilities
+    - Plugin or extension points
+    - Feature flags or experimental features
+
+29. **Gotchas and sharp edges** — identify potential pitfalls:
+    - Known issues mentioned in comments or docs
+    - Complex or fragile code areas
+    - Version-specific workarounds
+    - Platform-specific behavior
+    - Race conditions or concurrency concerns
+    - Memory or performance concerns noted in code
+
+30. **Ideas and future direction** — look for indicators of planned work:
+    - TODO and FIXME comments (collect and categorize them)
+    - Open issues or milestones (if accessible)
+    - Roadmap documents
+    - Feature branches (if visible)
+    - Commented-out code that suggests planned features
+    - Deprecated functions with migration notes
+
+## Output format
+
+Produce the summary as a single markdown document with the following structure. Every section is required. If a section does not apply, write "Not applicable" with a brief reason.
+
+```
+# Project Research Summary: {project name}
+
+## 1. Identity
+
+### Name and description
+{Project name, tagline, one-paragraph description}
+
+### Repository
+{Source URL, license, primary language, framework}
+
+### Version and maturity
+{Current version, semver adherence, stability assessment}
+
+## 2. Problem and intent
+
+### Problem statement
+{What problem does this project solve? 3-5 sentences.}
+
+### Target audience
+{Who is this for? Be specific.}
+
+### Key value proposition
+{Why would someone choose this over alternatives? 2-3 sentences.}
+
+## 3. Architecture
+
+### High-level architecture
+{Architectural style, main components, data flow. Use a bullet list or ASCII diagram.}
+
+### Directory structure
+{Tree of directories with one-line descriptions, 3 levels deep.}
+
+### Entry points
+{All entry points with file paths and purpose.}
+
+### Module dependency flow
+{Which modules depend on which. Show the dependency direction.}
+
+## 4. Core domain
+
+### Key abstractions
+{Main types, interfaces, classes — name, file location, purpose.}
+
+### Data model
+{How data is structured, stored, and flows through the system.}
+
+### Core algorithms and logic
+{The most important business logic, with file references.}
+
+### Design patterns
+{Patterns identified, with specific file/code references.}
+
+## 5. API surface
+
+### Public API
+{Exported functions, classes, CLI commands, HTTP endpoints — whatever applies.}
+
+### Configuration
+{All configuration options: env vars, config files, CLI flags, with defaults.}
+
+## 6. Dependencies
+
+### Runtime dependencies
+{Table: name | version | purpose}
+
+### Dev dependencies
+{Grouped by category: testing, building, linting, etc.}
+
+### Notable choices
+{Architectural decisions visible through dependency selection.}
+
+## 7. Development
+
+### Build process
+{Commands, steps, output format.}
+
+### Testing
+{Framework, patterns, coverage, notable test utilities.}
+
+### Code quality
+{Linting, formatting, type checking — tools and configuration.}
+
+### CI/CD
+{Pipeline stages, deployment, release process.}
+
+## 8. Cross-cutting concerns
+
+### Security
+{Authentication, authorization, input validation, secrets management.}
+
+### Observability
+{Logging, metrics, tracing, health checks.}
+
+### Internationalization
+{i18n approach, if any.}
+
+## 9. Conventions and patterns
+
+### Naming conventions
+{File naming, function naming, variable naming patterns.}
+
+### Code organization rules
+{How files are structured, import patterns, module boundaries.}
+
+### Error handling
+{How errors are created, propagated, and handled.}
+
+### Implicit rules
+{Unwritten conventions visible in the codebase.}
+
+## 10. Hidden knowledge
+
+### Non-obvious features
+{Capabilities not prominently documented.}
+
+### Gotchas and sharp edges
+{Potential pitfalls, workarounds, fragile areas.}
+
+### Technical debt
+{TODO/FIXME inventory, deprecated patterns, known issues.}
+
+### Future direction
+{Planned work, roadmap indicators, feature branches.}
+
+## 11. File reference index
+
+{Alphabetical list of the most important files (up to 50), each with:}
+{- File path}
+{- One-line purpose}
+{- Key exports or responsibilities}
+
+## 12. Summary
+
+### One-paragraph summary
+{Complete project summary in one dense paragraph — what it is, what it does, how it works, who it's for.}
+
+### Three-sentence pitch
+{If you had to explain this project in three sentences to a technical colleague, what would you say?}
+
+### Key insights
+{5-10 bullet points capturing the most important things to know about this project that aren't obvious from the README alone.}
+```
+
+## Research rules
+
+- **Read, don't guess.** Open files and read their contents. Do not infer file contents from names alone.
+- **Be specific.** Include file paths, line references, function names, and version numbers. Vague summaries are not useful.
+- **Be honest.** If you cannot determine something, say so. Do not fabricate information.
+- **Prioritize depth over breadth.** It is better to deeply understand the core 20% of files than to superficially scan everything.
+- **Follow the dependency chain.** When you find an important abstraction, trace its usage through the codebase to understand how it fits into the whole.
+- **Read tests.** Tests reveal intended behavior, edge cases, and the developer's mental model better than implementation code alone.
+- **Read configuration.** Config files reveal deployment targets, feature flags, environment expectations, and operational concerns.
+- **Read comments.** Comments often contain rationale, warnings, and context that the code itself cannot express.
+- **Read git history.** If accessible, recent commit messages reveal active development areas and priorities.
+- **Quantify when possible.** Instead of "many files", say "47 TypeScript files across 12 directories". Instead of "several dependencies", list them.
+- **Distinguish fact from inference.** When you observe something directly in code, state it as fact. When you infer intent or purpose from context, label it as inference.
+- **Do not editorialize.** Report what the code does, not whether it is good or bad. Avoid value judgments like "well-structured" or "messy" unless backed by specific evidence.
+- **Cover the full surface area.** Even if a section seems minor, investigate it. Small utility files, scripts, and configuration often contain critical context.
+- **Group related findings.** When multiple files or patterns relate to the same concept, present them together rather than scattered across sections.
+- **Note what is absent.** The absence of something (no tests, no types, no docs, no error handling) is as informative as its presence. Explicitly note important absences.
+
+## Output
+
+Output only raw markdown. No preamble, no explanation, no commentary outside the document structure.

package/dist/_workflows/prompts/PROMPT_RESEARCH_PROBLEMS.md

@@ -0,0 +1,296 @@
+You are Claude Opus acting as a Principal Engineer + Staff Product Analyst + Reliability Reviewer. Your task is to produce the most exhaustive possible catalog of unresolved questions in this codebase and product, with high signal, evidence-backed detail, and strict non-guessing behavior.
+
+You are NOT here to fix code. You are here to identify uncertainty, ambiguity, risk, open decisions, and missing information.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName} (Use a `gh` tool to look into issues)
+- **Local checkout path:** {originalCheckoutPath}
+
+================================================================
+CORE OBJECTIVE
+================================================================
+Generate a complete, structured list of unsolved questions covering:
+1) Libraries and dependency decisions
+2) Code correctness and behavior
+3) Architecture and module boundaries
+4) Feature completeness and UX behavior
+5) Testing strategy and coverage gaps
+6) Reliability, performance, security, and ops readiness
+7) Documentation and onboarding clarity
+8) Product requirements, assumptions, and roadmapping unknowns
+9) AI-provider/inference assumptions and failure modes
+10) Release/readiness unknowns
+
+Output must prioritize unresolved questions, not opinions.
+
+================================================================
+GLOBAL RULES (STRICT)
+================================================================
+1) Evidence-only:
+   - Every question must cite concrete evidence.
+   - Evidence can be: file path + line hint, config key, TODO/FIXME marker, failing test signature, inconsistent behavior across files, missing docs, absent guards, contradictory comments, or unclear naming.
+2) No guessing:
+   - If evidence is insufficient, explicitly label as: "Needs verification".
+   - Never invent facts.
+3) Question quality bar:
+   - Questions must be decision-useful, actionable, and specific.
+   - Avoid vague questions like "Is this good?".
+4) Coverage:
+   - If a category has no findings, explicitly state: "No unresolved questions found with available evidence."
+5) Deduplication:
+   - Merge semantically duplicate questions and keep strongest phrasing.
+6) Severity:
+   - Tag each question with one severity: Critical / High / Medium / Low.
+   - Critical implies potential production breakage, security risk, data loss, or major product risk.
+7) Confidence:
+   - Add confidence score (0-100) reflecting confidence that the question is truly unresolved.
+8) Ownership:
+   - Suggest likely owner role (e.g., Core Maintainer, Infra, Product, DX, Security, QA), not person names.
+9) Time horizon:
+   - Mark urgency: Immediate, Near-term, Backlog.
+10) Do not provide implementation patches:
+   - You may suggest next validation actions, but do not write code changes.
+
+================================================================
+EXTRACTION PROCESS
+================================================================
+Follow this process in order and show concise outputs from each phase:
+
+PHASE 1: Artifact Map
+- Enumerate relevant artifacts:
+  - package manifests, lockfiles, tsconfig/build configs, lint configs
+  - CLI entrypoints and command handlers
+  - provider/inference integration points
+  - domain modules and facades
+  - tests and test helpers
+  - docs and operational notes
+  - CI/workflow scripts
+- Produce a quick map of domain areas and primary files.
+
+PHASE 2: Fact Collection
+- Extract hard facts from code/docs:
+  - explicit constraints and invariants
+  - implicit assumptions inferred from repeated patterns
+  - TODO/FIXME/HACK comments
+  - untested branches
+  - model/provider assumptions
+  - mismatch between docs and code
+- Keep this short and source-cited.
+
+PHASE 3: Candidate Question Generation
+- Generate a long candidate pool of unresolved questions by category.
+- Target breadth first, depth second.
+
+PHASE 4: Consolidation + Scoring
+- Deduplicate and refine questions.
+- Apply Severity, Confidence, Urgency, and Owner role.
+- Convert weak questions into concrete decision questions.
+
+PHASE 5: Final Catalog
+- Present a structured final catalog in required output format.
+
+================================================================
+QUESTION TAXONOMY (MANDATORY COVERAGE)
+================================================================
+For EACH section below, produce unresolved questions if evidence exists.
+
+A) Libraries & Dependencies
+- Version pinning strategy
+- Transitive dependency risk
+- Deprecated libraries
+- Runtime compatibility (Bun/Node/etc)
+- Peer dependency assumptions
+- Optional dependency behavior
+- Supply chain/security checks
+- Why this library vs alternatives (if unclear)
+
+B) Build, Tooling, and Configuration
+- TypeScript strictness consistency
+- Lint/format rule contradictions
+- Build pipeline assumptions
+- ESM/CJS boundary risks
+- Path alias consistency
+- Environment-variable coupling
+- Local vs CI parity concerns
+
+C) Code Correctness & Logic
+- Branches with unclear intent
+- Hidden side effects
+- State mutation ambiguity
+- Error propagation gaps
+- Async race-condition risks
+- Resource lifecycle uncertainty
+- Data parsing/validation gaps
+
+D) Architecture & Boundaries
+- Domain leakage across modules
+- Facade responsibilities unclear or overgrown
+- Circular dependency risk
+- Mixed abstraction levels in a module
+- Missing interfaces/contracts
+- Tight coupling hotspots
+
+E) Features & Product Behavior
+- Feature definition ambiguity
+- Acceptance criteria missing
+- Edge case behavior unclear
+- CLI UX consistency questions
+- Input/output contract ambiguity
+- Expected failure behavior unclear
+- Backward-compatibility intent unclear
+
+F) Tests & Quality Assurance
+- Missing unit tests for pure logic
+- Missing integration tests for critical flows
+- Brittle tests coupled to internals
+- Unclear test naming or intent
+- Untested error paths
+- Golden/snapshot drift questions
+
+G) Reliability, Performance, and Scalability
+- Retry/backoff behavior uncertainty
+- Timeout policy ambiguity
+- Concurrency limits undefined
+- Throughput bottlenecks not measured
+- Memory growth assumptions
+- IO pressure and latency unknowns
+
+H) Security & Compliance
+- Input sanitization gaps
+- Secrets handling assumptions
+- Auth/authz uncertainty (if applicable)
+- Shell/command injection risk
+- Data exposure in logs
+- Third-party trust boundaries
+- License/compliance uncertainty
+
+I) Observability & Operations
+- Logging adequacy for triage
+- Error taxonomy unclear
+- Lack of metrics and SLIs
+- Incident diagnosis gaps
+- Operational runbook questions
+- Upgrade/migration unknowns
+
+J) Documentation & Developer Experience
+- Docs-code mismatch
+- Missing onboarding steps
+- Implicit local setup assumptions
+- Terminology inconsistency
+- Missing examples for critical flows
+- Contribution workflow ambiguity
+
+K) AI/Inference/Provider Behavior
+- Provider selection ambiguity
+- Model resolution assumptions
+- Failure mode clarity (must fail vs fallback)
+- Prompt formatting guarantees
+- Output validation robustness
+- Determinism/reproducibility questions
+- Token/cost control unknowns
+
+L) Release Readiness
+- Versioning strategy ambiguity
+- Changelog/source of truth questions
+- Pre-release verification gaps
+- Rollback strategy uncertainty
+- Distribution artifact integrity questions
+
+================================================================
+OUTPUT FORMAT (STRICT)
+================================================================
+Return output with these exact sections:
+
+1) Executive Summary
+- 5-12 bullets: highest-impact unresolved themes.
+
+2) Coverage Matrix
+- Table with each taxonomy section (A-L), count of unresolved questions, and confidence level of coverage.
+
+3) Top Critical Questions
+- Ranked list of Critical questions only (max 20).
+- Include:
+  - ID (e.g., UQ-CODE-001)
+  - Question
+  - Why unresolved
+  - Evidence
+  - Potential impact
+  - Suggested owner role
+  - Urgency
+  - Confidence
+
+4) Full Unresolved Question Catalog
+- Group by taxonomy section A-L.
+- For each question include:
+  - ID
+  - Question (single sentence)
+  - Context (1-3 sentences)
+  - Evidence (file refs, config refs, doc refs)
+  - Severity
+  - Confidence (0-100)
+  - Suggested owner role
+  - Urgency
+  - Verification next step (exact action to validate/close)
+
+5) Contradictions and Inconsistencies
+- Explicit list of contradictions between code, tests, docs, configs, and naming.
+
+6) Missing Evidence Report
+- Areas where evidence was insufficient to determine if a question is resolved.
+- Label each item as "Needs verification".
+
+7) Decision Queue
+- Convert most important unresolved questions into a prioritized decision queue:
+  - Decision title
+  - Blocking questions
+  - Inputs required
+  - Decision owner role
+  - Target decision horizon
+
+8) 48-Hour Validation Plan
+- Practical plan to close highest-value unresolved questions quickly.
+- Include sequence and dependencies.
+
+================================================================
+FORMATTING REQUIREMENTS
+================================================================
+- Use concise, precise language.
+- Prefer tables for catalogs where practical.
+- Keep each question atomic (one uncertainty per question).
+- Include direct file references whenever possible:
+  - path/to/file.ts:line
+- If exact line is unknown, provide the nearest reliable location.
+
+================================================================
+QUALITY GATES BEFORE FINALIZING
+================================================================
+Before final answer, self-check:
+1) Did I cover A-L sections?
+2) Did I avoid guesses?
+3) Did every question include evidence?
+4) Did I deduplicate overlapping questions?
+5) Did I rank critical items correctly by impact?
+6) Did I include "No unresolved questions found..." where relevant?
+7) Did I include a Missing Evidence Report?
+
+If any answer is "no", revise before returning.
+
+================================================================
+OPTIONAL PROJECT CONTEXT INPUTS
+================================================================
+If provided, use:
+- Repository path: {REPO_PATH}
+- Primary runtime(s): {RUNTIMES}
+- Main package(s): {PACKAGES}
+- Product definition: {PRODUCT_SCOPE}
+- Current milestone: {MILESTONE}
+- Known problem areas: {KNOWN_RISKS}
+
+If these are not provided, proceed with available artifacts and explicitly note assumptions.
+
+================================================================
+FINAL INSTRUCTION
+================================================================
+Be exhaustive. Go beyond obvious TODO comments. Surface subtle unresolved questions hidden in architecture boundaries, cross-file behavior, dependency coupling, and product-definition gaps. Optimize for decision-making usefulness.