pan-wizard 3.35.0 → 3.37.0

package/docs/decisions/ADR-0008-map-codebase-mermaid-togaf.md

@@ -0,0 +1,80 @@
+# ADR-0008: Enhance map-codebase with Mermaid Diagrams and TOGAF Structure
+
+## Status
+Superseded by [ADR-0021](ADR-0021-codebase-mapper-v2.md) — the mapper-v2 redesign folded in and replaced this proposal.
+
+## Context
+`/pan:map-codebase` produces 7 text-only markdown files describing a codebase.
+Developers and AI agents struggle to quickly understand system structure from
+prose alone. Visual diagrams communicate architecture 10x faster than text.
+The current 7-file structure (STACK, INTEGRATIONS, ARCHITECTURE, STRUCTURE,
+CONVENTIONS, TESTING, CONCERNS) was designed pragmatically without mapping to
+any standard architecture framework.
+
+TOGAF's Architecture Development Method provides a proven taxonomy (Business,
+Application, Data, Technology architecture domains) that would give the codebase
+map principled coverage. Mermaid diagrams (text-based, renders natively in GitHub,
+VS Code, GitLab, and Obsidian) would add visual communication without introducing
+any runtime dependency.
+
+## Decision
+1. Add Mermaid diagram blocks to 5 of 7 codebase document templates
+2. Restructure document sections to align with TOGAF architecture domains
+3. Keep all 7 existing filenames unchanged (backward compatibility)
+4. Update mapper agent prompts to generate diagrams as part of exploration
+5. Never use Mermaid `click` directives (security)
+6. Never include credentials or tokens in diagram labels (security)
+
+### Diagram Types Per Document
+- ARCHITECTURE.md: Flowchart (component relationships) + Sequence diagram (request lifecycle)
+- STRUCTURE.md: Flowchart TD (directory hierarchy)
+- INTEGRATIONS.md: Flowchart (external services) + ER diagram (data entities, if DB detected)
+- STACK.md: Flowchart (deployment topology)
+- CONCERNS.md: Quadrant chart (risk assessment)
+
+### TOGAF Domain Mapping (without renaming files)
+- Business Architecture → ARCHITECTURE.md (new section)
+- Application Architecture → ARCHITECTURE.md + STRUCTURE.md (existing, restructured)
+- Data Architecture → INTEGRATIONS.md (new section)
+- Technology Architecture → STACK.md (new header)
+- Cross-Cutting → CONVENTIONS.md, TESTING.md, CONCERNS.md (unchanged)
+
+Mermaid was chosen over PlantUML (requires Java runtime), D2 (fewer renderers),
+and PNG/SVG generation (adds runtime dependency via mmdc CLI).
+
+## Consequences
+
+### Positive
+- Visual architecture diagrams generated automatically by mapper agents
+- TOGAF alignment ensures no architecture layer is accidentally omitted
+- Renders in GitHub markdown preview with zero additional tooling
+- AI agents can parse Mermaid syntax for better planning context
+- Zero new runtime dependencies (Mermaid is text, not a dependency)
+- Graceful degradation in terminals (Mermaid blocks display as readable text)
+
+### Negative
+- Mapper agents use slightly more tokens generating diagrams (~10-15% more)
+- Templates become longer (more examples for agents to follow)
+- Users on plain terminals see raw Mermaid syntax instead of diagrams
+
+### Neutral
+- Existing consumers (plan-phase, exec-phase) continue working unchanged
+- Same 4 mapper agents, same workflow orchestration, same 7 filenames
+- Same init.cjs cmdInitMapCodebase() output — no JSON schema changes
+
+## Options Considered
+1. **PNG/SVG generation with mmdc CLI** — rejected (adds runtime dependency, violates zero-dep constraint)
+2. **Separate .mmd diagram files** — rejected (consumers load .md files by name, extra files = confusion)
+3. **PlantUML** — rejected (requires Java runtime)
+4. **D2 (Terrastruct)** — rejected (fewer rendering targets, less AI familiarity)
+5. **Mermaid in existing markdown** — chosen (zero deps, native rendering, AI-friendly)
+6. **Full TOGAF ADM process** — rejected (too heavyweight for codebase mapping)
+7. **TOGAF sections in existing files** — chosen (lightweight, backward-compatible)
+8. **Rename files to TOGAF domains** — rejected (breaks consumer filename mapping)
+
+## Links
+- Spec: docs/specs/map_codebase_mermaid_togaf_featureai.md
+- Current workflow: pan-wizard-core/workflows/map-codebase.md
+- Current agent: .claude/agents/pan-document_code.md
+- Current templates: pan-wizard-core/templates/codebase/*.md
+- Related: ADR-0006 (focus commands — also uses .planning/ output)

package/docs/decisions/ADR-0009-production-deployment-checklist.md

@@ -0,0 +1,68 @@
+# ADR-0009: Production Deployment Checklist
+
+## Status
+Accepted (shipped in v1.0.0 — 2026-03-01)
+
+## Context
+
+PAN Wizard v1.0.0 is feature-complete with 37 commands, 15 modules, 11 agents, and 1065 passing tests across 5 runtimes (Claude Code, OpenCode, Gemini CLI, Codex, Copilot CLI). The codebase has undergone 21 sessions of systematic hardening, testing, and documentation work.
+
+Before publishing to npm as a stable v1.0.0 release, a production deployment audit was conducted to verify all non-code artifacts meet professional standards. The audit examined: LICENSE, SECURITY.md, .gitignore, CI pipeline, documentation accuracy, npm package configuration, installer robustness, and security posture.
+
+### Forces at Play
+- **First impressions matter:** New users evaluate quality from README, LICENSE, and install experience before reading code
+- **Security trust:** SECURITY.md with stale version (0.1.x) undermines confidence in a 1.0.0 release
+- **Contributor friction:** Minimal .gitignore risks accidental commits of sensitive files in PRs
+- **Documentation accuracy:** Stale counts (33 workflows when 30 exist) create confusion for contributors
+
+## Decision
+
+Execute a focused deployment preparation sprint addressing 9 items in priority order:
+
+### P0 (Must fix before publish)
+1. **SECURITY.md** — Update version table from `0.1.x` to `1.0.0`
+2. **.gitignore** — Expand from 3 entries to comprehensive Node/OS coverage
+3. **ARCHITECTURE.md** — Fix workflow count from 33 to 31
+
+### P1 (Should fix before publish)
+4. **npm publish --dry-run** — Verify package size and contents
+5. **Orphaned verify-work.md** — Remove or document as alias
+
+### P2+ (Polish, non-blocking)
+6. **Dependabot** — Add `.github/dependabot.yml` for esbuild updates
+7. **FUNDING.yml** — Populate or remove empty placeholder
+8. **Internal command files** — Fix stale "123 tests" references
+9. **isGitIgnored()** — Migrate from `execSync` string to `execFileSync` array (defense-in-depth)
+
+### What We Decided NOT to Do
+- **ESLint/Prettier:** Not blocking for v1.0.0. The codebase maintains consistent style without formal linting. Adding linting tools introduces devDependencies and CI complexity that doesn't match the "zero ceremony" philosophy. Consider for v1.1.0.
+- **TypeScript/JSDoc validation:** Pure CJS project with 1483 tests provides better guarantees than type annotations. Not worth the migration effort.
+- **npm publish workflow:** Manual publish via `npm publish` is appropriate for a solo-maintained tool. Automated publishing adds attack surface.
+- **Coverage thresholds:** The project has 1483 tests across 52 files. Threshold enforcement would add CI complexity without improving actual coverage.
+
+## Consequences
+
+### Positive
+- Clean, professional npm package on first publish
+- Accurate security policy builds trust with evaluators
+- Comprehensive .gitignore prevents contributor accidents
+- Documentation accuracy reduces confusion for new users
+
+### Negative
+- Small time investment (estimated 1 focus-exec session / ~30 minutes)
+- No automated code quality gates (ESLint/Prettier deferred)
+
+### Neutral
+- Dependabot will create PRs for esbuild updates (only devDependency)
+- FUNDING.yml decision depends on whether GitHub Sponsors is set up
+
+## Options Considered
+
+1. **Ship as-is** — All issues are non-blocking, but first impression suffers
+2. **Fix HIGH priority only** — SECURITY.md + .gitignore + ARCHITECTURE.md (chosen minimum)
+3. **Full polish sprint** — All 9 items including ESLint, Prettier, coverage (rejected: over-engineering for v1.0.0)
+
+## Links
+- Spec: `docs/specs/production_deployment_readiness_featureai.md`
+- Previous ADR: ADR-0007 (Ship v1.0.0 decision)
+- Previous spec: `docs/specs/production_readiness_ship_v1_featureai.md`

package/docs/decisions/ADR-0010-standards-integration.md

@@ -0,0 +1,79 @@
+# ADR-0010: Standards Integration
+
+## Status
+Accepted (shipped in v2.1.0 — 2026-03-02)
+
+## Context
+
+PAN Wizard orchestrates AI-assisted development across 5 runtimes but has no systematic way for users to select and enforce industry standards (OWASP, NIST, WCAG, ISO 25010, etc.) throughout their workflow. Research shows 25-45% of AI-generated code contains security vulnerabilities (2025-2026 studies). The industry has responded with new standards (OWASP LLM Top 10 2025, OWASP Agentic Top 10 2026, NIST SP 800-218A, OpenSSF AI Code Assistant Guide), but no AI workflow tool integrates standards selection with planning and verification.
+
+PAN already has the infrastructure: health checks (verify.cjs), 4-level verification (pan-verifier), 8-dimension plan checking (pan-plan-checker), config system (config.cjs), and STRIDE-lite in focus-design. What's missing is the connection — a way for users to declare which standards apply and have that declaration flow through every agent interaction.
+
+Forces at play:
+- AI-generated code vulnerability rates are high and well-documented
+- No AI coding tool provides standards selection + verification integration
+- PAN's existing architecture supports context injection via .planning/ files
+- Users want "set once, enforced everywhere" — not manual reminders
+- Standards should guide, not block (advisory model aligns with PAN's philosophy)
+- Zero runtime dependencies must be maintained
+
+## Decision
+
+Add a standards integration system with:
+
+1. **Built-in catalog** of 12 well-known standards (OWASP Top 10, ASVS L1, LLM Top 10, WCAG 2.2, NIST SSDF, ISO 25010, STRIDE, CWE Top 25, OWASP Agentic, SOC 2 Dev, TOGAF ADM, Conventional Commits)
+
+2. **`.planning/standards.md`** as the persistent registry — a Markdown file in .planning/ that agents naturally read as context
+
+3. **5 subcommands** under `pan-tools standards`: `list`, `select`, `remove`, `status`, `recommend`
+
+4. **Project-type recommendations** based on project.md analysis (web app → OWASP, UI → WCAG, etc.)
+
+5. **Agent context injection** — verifier and plan-checker gain standards-aware dimensions when standards.md exists
+
+6. **Advisory model** — standards violations are reported as warnings, not blocking errors
+
+Key design choices:
+- Markdown file (not JSON config) because agents read .planning/ files naturally
+- Built-in catalog (not user-defined rules) for quality control and zero-friction adoption
+- Advisory (not blocking) to match PAN's health check philosophy
+- No scanning (SonarQube/Semgrep do that) — PAN guides, external tools scan
+
+## Consequences
+
+### Positive
+- PAN becomes the first AI workflow tool with standards-aware planning and verification
+- Standards selection reduces to a menu choice during project setup
+- Verifier catches standards gaps automatically
+- Zero new runtime dependencies
+- Existing workflows unchanged if no standards selected (fully additive)
+
+### Negative
+- Catalog maintenance burden — standards evolve, catalog needs periodic updates
+- Advisory-only model may not satisfy compliance-heavy organizations
+- Checklist items are necessarily high-level (10 items per standard, not CWE-granular)
+
+### Neutral
+- No new commands — extends existing settings, health, and agent prompts
+- config.json gains optional `standards` section
+- ADR count increases to 10
+
+## Options Considered
+
+1. **Static instruction files** (Cursor approach) — User writes security rules manually
+   - Rejected: Too much friction, rules are forgotten, no verification loop
+
+2. **Built-in SAST scanning** — PAN scans code for vulnerabilities
+   - Rejected: Wrong tool for the job; SonarQube/Semgrep are specialized for this
+
+3. **Standards as workflow context** (chosen) — Select from catalog, inject into agents, report in health
+   - Chosen: Leverages PAN's architecture, minimal code, maximum impact
+
+4. **External standards plugin system** — Users install standard packs
+   - Rejected: Adds complexity, dependency management, breaks zero-dep promise
+
+## Links
+- Feature spec: `docs/specs/standards_integration_featureai.md`
+- Related: ADR-0006 (Focus Commands — STRIDE-lite in focus-design)
+- Related: ADR-0008 (Map Codebase — TOGAF alignment)
+- Related: ADR-0003 (Smart Execution — commit safety checks)

package/docs/decisions/ADR-0011-help-commands-rewrite.md

@@ -0,0 +1,64 @@
+# ADR-0011: Help Document & Command Descriptions End-to-End Rewrite
+
+## Status
+Accepted (shipped in v2.2.0 — 2026-03-02)
+
+## Context
+
+PAN Wizard v2.2.0 ships 37 user-facing slash commands across 5 AI coding runtimes (Claude Code, GitHub Copilot CLI, Gemini CLI, Codex, OpenCode). The `/pan:help` command outputs a 380-line static markdown reference that is the first thing every user sees when they try to learn PAN.
+
+The current help has several problems:
+1. **No progressive disclosure** — 380 lines dumped at once, mixing quick-reference tables with full flag documentation
+2. **Jargon-heavy descriptions** — "wave-based parallelization", "conversational UAT", "Reality Score filtering" mean nothing to new users
+3. **No entry point** — 37 commands presented with equal weight, no "start here" guidance
+4. **Inconsistent frontmatter** — 5 Focus commands missing `pan:` prefix, `patches.md` missing `name` and `group` fields entirely
+5. **8 groups with unbalanced sizes** — "Getting Started" (2 commands) and "Community" (2 commands) are too small to justify separate groups
+
+Competitive research shows that GitHub Copilot CLI (GA Feb 2026) ships with 4 functional groups and clear progressive disclosure, while clig.dev CLI guidelines explicitly recommend categorical grouping and outcome-oriented descriptions — patterns PAN currently violates.
+
+## Decision
+
+Rewrite the help document and all 37 command descriptions using these principles:
+
+1. **Progressive disclosure** — 3-tier structure: Quick Start decision tree (10 lines) → Grouped command tables (50 lines) → Detail sections (on demand)
+2. **Outcome-oriented descriptions** — max 10 words, plain English, describe what the USER gets, not how the tool works internally
+3. **5 groups** (from 8): Start & Plan, Build & Verify, Focus Pipeline, Milestones & Phases, Session & System
+4. **Common Recipes section placed early** — the 8 most common workflows as copy-paste patterns, before the full command listing
+5. **Fix all frontmatter inconsistencies** — add `pan:` prefix to 5 Focus commands, add missing fields to `patches.md`, standardize verbose argument-hints
+
+Target: 175 lines (from 380), 54% reduction.
+
+## Consequences
+
+### Positive
+- New users find the right command within 10 seconds
+- Every description answers "what does this DO for me?" in plain English
+- Consistent frontmatter across all 37 commands
+- Competitive parity with Copilot CLI's help organization
+- Reduced cognitive load (6 highlighted starter commands vs 37 equal-weight)
+
+### Negative
+- Existing users accustomed to 8-group structure must relearn the 5-group layout
+- Condensing Focus Pipeline detail from 98 to 30 lines means users must consult USER-GUIDE for full flag documentation
+- Some precision lost in shorter descriptions (mitigated by detail sections below the tables)
+
+### Neutral
+- No code changes — purely content work
+- No test regressions — static markdown content
+- Must propagate to 5 runtime directories (standard process)
+
+## Options Considered
+
+1. **Keep 8 groups, only rewrite descriptions** — Preserves familiar structure but doesn't address the core structural problem (no progressive disclosure, no entry point). Rejected: half-measure.
+
+2. **Reduce to 5 groups + progressive disclosure + outcome descriptions (chosen)** — Addresses all identified problems. Best balance of comprehensiveness and scannability. Competitive with Copilot CLI's 4-group approach while accommodating PAN's 2-workflow model.
+
+3. **Reduce to 3 groups (minimal)** — Too aggressive: would force unrelated commands together (milestones + debug + settings in one group). Rejected: loses semantic clarity.
+
+4. **Add AI-powered interactive help** — Would require new module, runtime dependency on LLM call, significant implementation. Rejected: over-engineering for the current problem. Can be v3 enhancement.
+
+## Links
+- Spec: `docs/specs/help_commands_rewrite_featureai.md`
+- Related: ADR-0005 (command naming), ADR-0006 (focus commands)
+- Competitive research: Aider, Cursor, Continue.dev, Cline, Claude Code, GitHub Copilot CLI
+- Industry guidelines: clig.dev CLI Interface Guidelines

package/docs/decisions/ADR-0012-contributors-attribution-index.md

@@ -0,0 +1,42 @@
+# ADR-0012: Contributors List & Attribution Index
+
+## Status
+Accepted
+
+## Context
+PAN Wizard is a public open-source project on npm and GitHub with 37 commands, 11 agents, 15 core modules, 11 ADRs, and 11 feature specs. The project references 6 strategic methodologies (Blue Ocean, Wardley, STRIDE, TOGAF, Spec-Driven Dev, ADRs), 12 industry standards (OWASP, NIST, ISO, WCAG, etc.), 8 competing tools (Aider, Cursor, Cline, etc.), and multiple research findings — but has no centralized attribution.
+
+The LICENSE and package.json say "PAN Wizard Contributors" without naming anyone. Git history shows a single human author (oharms), an AI co-author (Claude Opus 4.6), and a bot (dependabot). No CONTRIBUTORS.md or AUTHORS file exists.
+
+Open-source norms expect transparent attribution. New contributors cannot easily discover who built the project or where design ideas originated.
+
+## Decision
+Create two new documentation files:
+
+1. **CONTRIBUTORS.md** — Names every contributor (human, AI, bot) with role and contribution type
+2. **ATTRIBUTION.md** — Indexes every methodology, standard, tool, and research source that influenced the project, cross-referenced to the specific ADR/spec/file where each is used
+
+Additionally update package.json with a contributors array and link both files from README.md.
+
+## Consequences
+
+### Positive
+- Transparent attribution for all contributors including AI co-authors
+- Centralized influence index eliminates tribal knowledge
+- New contributors can understand design lineage without reading 11 ADRs
+- Follows open-source community norms
+
+### Negative
+- Two more files to maintain manually (low burden for a small contributor base)
+
+### Neutral
+- No code changes, no runtime impact, no test impact
+
+## Options Considered
+1. **Single CREDITS.md** — Mixes people and ideas in one file. Rejected: different audiences.
+2. **CONTRIBUTORS.md + ATTRIBUTION.md (chosen)** — Clean separation of people vs. ideas.
+3. **Auto-generated from git + CI** — Over-engineering for 1 human contributor. Deferred to v2.
+
+## Links
+- Related spec: `docs/specs/contributors_attribution_index_featureai.md`
+- Related files: CONTRIBUTORS.md, ATTRIBUTION.md, package.json, README.md

package/docs/decisions/ADR-0013-strategic-feature-additions.md

@@ -0,0 +1,53 @@
+# ADR-0013: Strategic Feature Additions (Industry Analysis)
+
+## Status
+Accepted
+
+## Context
+PAN Wizard v2.2.0 is a mature CLI workflow automation tool with 37 commands, 15 modules, and 5-runtime support. A competitive analysis of 6 AI coding tools (Aider, Cursor, Continue.dev, Cline, Windsurf, GitHub Copilot Workspace) identified that PAN is 18-24 months ahead on structured workflow orchestration but should deepen existing moats rather than expand surface area.
+
+Key industry findings:
+- #1 user pain point across all tools: context loss between sessions ("AI amnesia")
+- Planning-before-coding is now table-stakes (4/6 competitors have it)
+- Zero competitors have formal milestone lifecycle or cross-session verification
+- Context engineering identified as strategic priority (Anthropic 2026 report)
+- AI coding agent market growing from $7.8B to $52B by 2030
+
+## Decision
+Add 4 practical features that strengthen existing differentiators without over-engineering:
+
+1. **Pre-Flight Checks** (`preflight`) -- Validate execution prerequisites before spending tokens
+2. **Project Dashboard** (`dashboard`) -- Single-command aggregated project overview
+3. **Session Intelligence** (`learnings extract/list/prune`) -- Auto-extract patterns from sessions
+4. **Dependency Validation** (`deps validate`) -- Cross-reference roadmap vs reality
+
+All features: zero runtime dependencies, CommonJS, works across all 5 runtimes.
+
+## Consequences
+
+### Positive
+- Raises moat score from 25/30 to 29/30
+- Addresses #1 industry pain point (session learning)
+- Pre-flight checks prevent the most common execution failure (broken baseline)
+- Dashboard makes .planning/ state immediately actionable
+- All features build on existing architecture (verify.cjs, state.cjs, commands.cjs)
+
+### Negative
+- +4 new commands increases cognitive load slightly
+- Session learning requires structured session data (appendSessionSummary, appendErrorPattern)
+- Dashboard aggregates multiple files, so performance depends on .planning/ size
+
+### Neutral
+- Command count increases from 37 to 41
+- No new modules needed (features fit into existing verify.cjs, state.cjs, commands.cjs)
+
+## Options Considered
+1. **IDE integration** -- Rejected. PAN is CLI-first; competing with Cursor/Windsurf on IDE is losing strategy.
+2. **Parallel agent orchestration** -- Rejected. PAN's value is execution quality, not speed.
+3. **Auto-iteration loops** -- Rejected. Windsurf's approach is opaque; PAN values transparency.
+4. **Deepen existing moats (chosen)** -- Build practical features that strengthen PAN's unique workflow management position.
+
+## Links
+- Spec: docs/specs/industry_analysis_strategic_additions_featureai.md
+- Batch: .planning/focus/batch-2026-03-03.json
+- Related: ADR-0006 (focus commands), ADR-0003 (smart execution)

package/docs/decisions/ADR-0014-internal-cleanup-code-quality.md

@@ -0,0 +1,53 @@
+# ADR-0014: Internal Cleanup & Code Quality Hardening
+
+## Status
+Accepted (shipped in v2.3.0 — 2026-03-03)
+
+## Context
+PAN Wizard v2.3.0 has 15 core modules (4,770+ LOC), a CLI dispatcher (735+ LOC), and an installer (2,636 LOC) that have accumulated technical debt across 23 development sessions. A comprehensive 5-agent parallel audit identified ~170 issues:
+
+- 12 functions exceed the project's own 50-line complexity budget
+- 3 functions are duplicated across modules
+- 11 dispatcher argument accesses lack bounds validation
+- 15+ magic numbers are scattered instead of centralized in constants
+- 5 dead imports/re-requires waste module surface area
+
+The codebase is functionally correct (1,180 tests, 0 failures) and architecturally sound (clean DAG, no circular deps). This is maintenance debt, not architectural debt.
+
+## Decision
+Perform a 4-wave internal cleanup:
+
+1. **Dead code removal** — Remove duplicate imports, unused params, redundant re-requires
+2. **Duplication consolidation** — Merge `getArchivedPhaseDirs`/`listArchivedPhaseDirs`, extract shared standards parser, centralize magic numbers in constants.cjs, add `getArgValue()` dispatcher helper
+3. **Complexity reduction** — Split 12 functions exceeding 50 lines by extracting focused helpers
+4. **Dispatcher hardening** — Add argument validation to 11 unguarded `args[N]` accesses
+
+All changes are behavioral no-ops — identical input produces identical output. Zero breaking changes.
+
+## Consequences
+
+### Positive
+- All core functions comply with 50-line/3-nesting/4-param complexity budget
+- Single source of truth for archive phase search, standards parsing, magic numbers
+- Dispatcher rejects missing arguments with actionable errors instead of passing `undefined`
+- Reduced maintenance cost for future development sessions
+- Cleaner codebase for potential contributors
+
+### Negative
+- ~45 points of effort with zero user-facing feature delivery
+- Risk of subtle behavior changes in extracted helpers (mitigated by 1,180 existing tests)
+- Constants.cjs grows by ~15 new exports
+
+### Neutral
+- Installer is out of scope (its 22 issues warrant a separate ADR)
+- Test style inconsistencies (test vs it, assert vs assert/strict) are cosmetic and deferred
+
+## Options Considered
+1. **Do nothing** — Functional but accumulates debt; next session compounds issues
+2. **Full rewrite** — Unnecessary; architecture is sound, only implementation details need work
+3. **Incremental 4-wave cleanup (chosen)** — Lowest risk, independently testable per wave
+
+## Links
+- Feature spec: `docs/specs/internal_cleanup_code_quality_featureai.md`
+- Related: ADR-0003 (smart execution), ADR-0006 (focus commands)
+- Audit methodology: 5 parallel Explore agents scanning all 15 modules + dispatcher + installer