hatch3r 1.4.0 → 1.5.0

package/agents/hatch3r-researcher.md

@@ -4,6 +4,7 @@ description: Composable context researcher agent. Receives a research brief with
 model: standard
 tags: [core, planning]
 protected: true
+quality_charter: agents/shared/quality-charter.md
 ---
 You are a focused context researcher for the project. You receive a research brief and return structured findings.
 
@@ -47,11 +48,11 @@ If project context was provided by the orchestrator, use it directly — do not
 
 ### 3. Execute Requested Modes
 
-For each requested mode, follow the mode's definition from the Research Modes library. Respect the depth level:
+For each requested mode, read its definition from `agents/modes/{mode-name}.md` and follow the output structure defined there. Respect the depth level:
 
 - **quick** — scan file headers, grep for patterns, produce concise assessment. Tables have 3-5 rows max. Summaries only, no deep code reading. Target ~2k tokens output per mode.
 - **standard** — read relevant files, explore multiple sources, produce structured tables. Tables have 5-10 rows. Follow all 4 tiers of the tooling hierarchy. Target ~5k tokens output per mode.
-- **deep** — full structured analysis. Produce the complete output structure defined in the mode. No row limits. Follow all 4 tiers exhaustively. Target ~15k tokens output per mode.
+- **deep** — full structured analysis. Produce the complete output structure defined in the mode. No row limits. Follow all 4 tiers without omission. Target ~15k tokens output per mode.
 
 ### 4. Return Structured Result
 
@@ -71,911 +72,47 @@ Report back to the parent orchestrator with results for each requested mode, usi
 
 ## Research Modes
 
-### Mode: `codebase-impact`
-
-Analyze the current codebase to understand what exists today in the areas the subject touches. Map files, modules, components, integration points, and coupling.
-
-**Output structure:**
-
-```markdown
-## Codebase Impact Analysis
-
-### Affected Modules
-| Module / Area | Current State | Changes Needed | Coupling Risk |
-|---------------|--------------|----------------|---------------|
-| {module} | {what exists today} | {what needs to change} | Low/Med/High |
-
-### Affected Files
-| File Path | Change Type | Description |
-|-----------|-------------|-------------|
-| {path} | Create/Modify/Extend | {what changes and why} |
-
-### Integration Points
-| Integration | Current Behavior | Required Change | Breaking? |
-|-------------|-----------------|-----------------|-----------|
-| {component/API/event} | {current} | {new} | Yes/No |
-
-### Patterns in Use
-- **{pattern}**: {where used} — {implications for this subject}
-
-### Transitive Dependency Trace
-For each file expected to change, trace importers up to 3 levels deep. This reveals the full blast radius beyond directly modified files.
-
-| Modified File | Direct Importers (L1) | Transitive Importers (L2) | Deep Importers (L3) |
-|--------------|----------------------|--------------------------|-------------------|
-| {file path} | {files that import this} | {files that import L1} | {files that import L2} |
-
-### API Consumer Map
-For each function, class, or interface expected to change, list all call sites across the codebase.
-
-| Symbol | Type | Call Sites | Contract Change Risk |
-|--------|------|-----------|---------------------|
-| {function/class/interface name} | Function/Class/Interface/Type | {file:line — list of all usages} | High/Med/Low — {why} |
-
-### Type Contract Surface
-For each modified type or interface, list all consumers and flag potential contract violations.
-
-| Type / Interface | Consumers | Fields Affected | Breaking Potential |
-|-----------------|-----------|----------------|-------------------|
-| {type name} | {list of files/modules using this type} | {which fields change} | Yes/No — {what could break} |
-
-### Event / Callback Chain
-Trace event emitters, listeners, callback registrations, and pub/sub patterns that depend on modified behavior.
-
-| Event / Callback | Emitter | Listeners / Subscribers | Behavior Change? |
-|-----------------|---------|------------------------|-----------------|
-| {event name or callback} | {where it's emitted/called} | {where it's consumed} | Yes/No — {what changes} |
-
-### Blast Radius Summary
-| Category | Count | Risk Level |
-|----------|-------|-----------|
-| Directly modified files | {N} | — |
-| Direct importers (L1) | {N} | High |
-| Transitive importers (L2) | {N} | Medium |
-| Deep importers (L3) | {N} | Low |
-| API consumers with contract risk | {N} | High |
-| Type consumers with breaking potential | {N} | High |
-| Event/callback chain participants | {N} | Medium |
-| **Total files at risk** | **{N}** | — |
-
-### Current State Summary
-{2-3 paragraphs describing the relevant codebase area, existing conventions, and how the subject fits into the current architecture}
-```
-
-**Depth scaling for transitive tracing:**
-- **quick**: Skip transitive tracing sections entirely. Only produce the standard tables (Affected Modules, Affected Files, Integration Points, Patterns in Use).
-- **standard**: Produce Transitive Dependency Trace (L1 only) and Blast Radius Summary. Skip API Consumer Map, Type Contract Surface, and Event/Callback Chain.
-- **deep**: Produce all sections — full 3-level trace, API Consumer Map, Type Contract Surface, Event/Callback Chain, and Blast Radius Summary.
-
----
-
-### Mode: `feature-design`
-
-Break the subject down into implementable sub-tasks with user stories, acceptance criteria, edge cases, and effort estimates.
-
-**Output structure:**
-
-```markdown
-## Feature Breakdown
-
-### Sub-Tasks
-| # | Sub-Task | User Story | Acceptance Criteria | Effort | Dependencies |
-|---|----------|-----------|---------------------|--------|--------------|
-| 1 | {title} | As a {persona}, I want {goal} so that {benefit} | - [ ] {criterion} | S/M/L/XL | {deps} |
-
-### Edge Cases
-| # | Scenario | Expected Behavior | Priority |
-|---|----------|-------------------|----------|
-| 1 | {edge case} | {how the system should handle it} | Must/Should/Nice |
-
-### UX Considerations
-- **{consideration}**: {recommendation and rationale}
-
-### Effort Summary
-| Metric | Value |
-|--------|-------|
-| Total sub-tasks | {N} |
-| Estimated total effort | {S/M/L/XL — map to rough days} |
-| Parallelizable tasks | {list task numbers that can run concurrently} |
-| Critical path | task {N} → task {M} → task {P} |
-
-### Suggested Priority
-{P0/P1/P2/P3}: {rationale for this priority level}
-```
-
----
-
-### Mode: `architecture`
-
-Design the architectural approach. Identify data model changes, API contracts, component design, and whether existing patterns should be followed or new ones introduced. Flag any decisions that warrant ADRs.
-
-**Output structure:**
-
-```markdown
-## Architecture Design
-
-### Data Model Changes
-| Entity / Table | Change Type | Fields / Schema | Migration Needed? |
-|---------------|-------------|-----------------|-------------------|
-| {entity} | Create/Alter/None | {fields or schema changes} | Yes/No |
-
-### API / Interface Contracts
-| Endpoint / Interface | Method | Input | Output | Notes |
-|---------------------|--------|-------|--------|-------|
-| {endpoint or interface} | {method} | {shape} | {shape} | {constraints} |
-
-### Component Design
-| Component | Responsibility | Depends On | New/Existing |
-|-----------|---------------|-----------|--------------|
-| {name} | {what it does} | {dependencies} | New/Existing |
-
-### Pattern Alignment
-- **Follows existing:** {patterns from the codebase this should follow}
-- **New patterns needed:** {any new patterns introduced, with justification}
-
-### Architectural Decisions Requiring ADRs
-| # | Decision | Context | Recommended | Alternatives |
-|---|----------|---------|-------------|--------------|
-| 1 | {title} | {why this decision matters} | {pick} | {alt1}, {alt2} |
-
-### Dependency Analysis
-| Dependency | Type | Status | Notes |
-|-----------|------|--------|-------|
-| {what this depends on} | Hard/Soft | Exists/Needs building | {notes} |
-```
-
----
-
-### Mode: `risk-assessment`
-
-Identify risks, security implications, performance concerns, breaking changes, migration needs, and common mistakes.
-
-**Output structure:**
-
-```markdown
-## Risk Assessment
-
-### Technical Risks
-| # | Risk | Likelihood | Impact | Mitigation |
-|---|------|-----------|--------|------------|
-| 1 | {risk} | High/Med/Low | High/Med/Low | {strategy} |
-
-### Security Implications
-| # | Concern | Severity | Mitigation |
-|---|---------|----------|------------|
-| 1 | {concern} | Critical/High/Med/Low | {strategy} |
-
-### Performance Concerns
-| # | Concern | When It Matters | Mitigation |
-|---|---------|----------------|------------|
-| 1 | {concern} | {threshold or condition} | {strategy} |
-
-### Breaking Changes
-| # | What Breaks | Who Is Affected | Migration Path |
-|---|------------|----------------|----------------|
-| 1 | {change} | {consumers/users} | {migration strategy} |
-
-### Common Mistakes
-- **{mistake}**: {why it's tempting} → {what to do instead}
-
-### Recommended Safeguards
-- {safeguard}: {rationale}
-```
-
----
-
-### Mode: `symptom-trace`
-
-Trace reported symptoms through the codebase. Map the execution path from user action to observed failure. Identify where expected behavior diverges from actual behavior.
-
-**Output structure:**
-
-```markdown
-## Symptom Trace
-
-### Execution Path
-| # | Step | File / Function | Expected Behavior | Observed / Likely Behavior |
-|---|------|----------------|-------------------|---------------------------|
-| 1 | {user action or trigger} | {entry point} | {what should happen} | {what likely happens} |
-| 2 | {next step in flow} | {file:function} | {expected} | {observed or inferred} |
-
-### Divergence Point
-- **Where:** {file:function or module where behavior diverges}
-- **What:** {description of the divergence}
-- **Evidence:** {code patterns, conditions, or state that suggest this is the divergence point}
-
-### Error Propagation
-| From | To | How | Observable? |
-|------|----|-----|-------------|
-| {origin} | {downstream} | {mechanism — exception, bad state, silent failure} | Yes/No |
-
-### Affected Code Paths
-| Path | Entry Point | Risk of Symptom | Notes |
-|------|-------------|----------------|-------|
-| {flow name} | {file:function} | High/Med/Low | {why this path is affected} |
-
-### Data Flow Concerns
-- {any data integrity, state management, or concurrency concerns identified during tracing}
-```
-
----
-
-### Mode: `root-cause`
-
-Analyze the codebase for candidate root causes. Use static analysis patterns: off-by-one errors, race conditions, missing null checks, incorrect assumptions, stale caches, wrong operator usage, missing error handling, and anti-patterns. Rank hypotheses by likelihood.
-
-**Output structure:**
-
-```markdown
-## Root Cause Analysis
-
-### Hypotheses (Ranked by Likelihood)
-| Rank | Hypothesis | Likelihood | Evidence | Files Involved | Verification Strategy |
-|------|-----------|-----------|----------|----------------|----------------------|
-| 1 | {what might be wrong} | High/Med/Low | {code evidence supporting this} | {file paths} | {how to confirm or rule out} |
-| 2 | {alternative cause} | High/Med/Low | {evidence} | {files} | {verification} |
-
-### Code Smells in Affected Area
-| # | Smell | Location | Relevance to Bug |
-|---|-------|----------|-----------------|
-| 1 | {pattern — e.g., missing error handling, implicit type coercion} | {file:line} | {how it could cause or mask the bug} |
-
-### Dependency Analysis
-| Dependency | Version | Known Issues | Relevance |
-|-----------|---------|-------------|-----------|
-| {library/module} | {version} | {any known bugs or CVEs} | {how it relates to the symptoms} |
-
-### Recommended Investigation Order
-1. {hypothesis to test first — highest likelihood + easiest to verify}
-2. {next hypothesis}
-3. {etc.}
-
-### Ruling-Out Notes
-- {hypotheses already considered unlikely and why}
-```
-
----
-
-### Mode: `impact-analysis`
-
-Map the blast radius. Identify all flows, modules, data, and users affected. Find related issues or symptoms that might share the same cause. Assess data integrity risk and downstream consumers.
-
-**Output structure:**
-
-```markdown
-## Impact Assessment
-
-### Affected Flows
-| Flow | Impact | Users Affected | Data at Risk? |
-|------|--------|---------------|---------------|
-| {user flow or system process} | {how it is affected} | {persona or segment} | Yes/No — {details} |
-
-### Affected Modules
-| Module / Area | How Affected | Severity | Coupling |
-|---------------|-------------|----------|----------|
-| {module} | {direct failure / degraded / cascading} | Critical/High/Med/Low | Direct/Indirect |
-
-### Downstream Consumers
-| Consumer | Coupling Type | Impact | Action Needed |
-|----------|-------------|--------|--------------|
-| {module/service/user} | {direct API / import / event / data} | {none / update needed / rewrite needed} | {what to do} |
-
-### Data Integrity Risk
-| Data | Risk | Detection | Recovery |
-|------|------|-----------|----------|
-| {what data is at risk} | {corruption / loss / inconsistency} | {how to detect damage} | {how to recover} |
-
-### Related Symptoms
-| # | Symptom | Reported? | Likely Same Cause? |
-|---|---------|-----------|-------------------|
-| 1 | {other observed issue} | Yes (#{issue}) / No | Yes/Likely/Unlikely |
-
-### User-Facing Impact
-- **Severity:** {Critical/High/Med/Low}
-- **Scope:** {how many users, what percentage of traffic}
-- **Workaround available:** {yes — describe / no}
-```
-
----
-
-### Mode: `regression`
-
-Investigate when the issue was likely introduced and what changed. Analyze git history, recent dependency updates, configuration changes, and deployment events in the affected area.
-
-**Output structure:**
-
-```markdown
-## Regression Analysis
-
-### Timeline
-| Date / Period | Change | Author | Files | Potential Link |
-|--------------|--------|--------|-------|---------------|
-| {date or range} | {commit message or change description} | {who} | {files changed} | High/Med/Low — {reasoning} |
-
-### Recent Changes in Affected Area
-| File | Last Modified | Change Summary | Suspicious? |
-|------|-------------|----------------|-------------|
-| {file path} | {date} | {what changed} | Yes/No — {why} |
-
-### Dependency Changes
-| Dependency | Previous Version | Current Version | Changelog Relevant? |
-|-----------|-----------------|----------------|---------------------|
-| {package} | {old} | {new} | Yes — {breaking change or bug fix} / No |
-
-### Configuration Changes
-| Config | Change | When | Impact |
-|--------|--------|------|--------|
-| {config file or env var} | {what changed} | {when} | {how it could cause the issue} |
-
-### Most Likely Introduction Window
-- **When:** {date range or commit range}
-- **What changed:** {description}
-- **Confidence:** High/Med/Low
-- **Bisect strategy:** {how to narrow down further if needed}
-
-### Previously Working State
-- **Last known good:** {version, commit, or date when this worked}
-- **Evidence:** {test results, user reports, or deploy logs}
-```
-
----
-
-### Mode: `current-state`
-
-Map the current state of the code being analyzed. Measure complexity, coupling, cohesion, test coverage, and code quality. Identify the specific problems that motivate the change.
-
-**Dimension-specific focus** (when provided):
-- **Structural:** Emphasize coupling, cohesion, module boundaries, dead code
-- **Logical:** Emphasize behavior contracts, data flows, state management, business rules
-- **Visual:** Emphasize component hierarchy, design token usage, accessibility compliance, responsive patterns
-- **Migration:** Emphasize framework/library API surface, adapter boundaries, compatibility layers
-
-**Output structure:**
-
-```markdown
-## Current State Analysis
-
-### Module Map
-| Module / Component | Files | Lines of Code | Responsibility | Coupling |
-|-------------------|-------|---------------|---------------|----------|
-| {module} | {count} | {approx} | {what it does} | {what it depends on and what depends on it} |
-
-### Complexity Metrics
-| File / Function | Complexity Signal | Severity | Notes |
-|----------------|------------------|----------|-------|
-| {file:function} | {high cyclomatic complexity / deep nesting / large function / etc.} | High/Med/Low | {context} |
-
-### Code Smells
-| # | Smell | Location | Description | Impact on Maintainability |
-|---|-------|----------|-------------|--------------------------|
-| 1 | {smell type} | {file:line range} | {description} | {how it hurts} |
-
-### Dependency Graph
-| Component | Depends On | Depended On By | Coupling Type |
-|-----------|-----------|---------------|---------------|
-| {component} | {dependencies} | {dependents} | Hard/Soft/Circular |
-
-### Test Coverage
-| Area | Unit Tests | Integration Tests | Coverage Level | Safety for Refactoring |
-|------|-----------|------------------|---------------|----------------------|
-| {area} | {count / exists / missing} | {count / exists / missing} | High/Med/Low | Safe/Needs tests first |
-
-### Pattern Inventory
-- **{pattern}**: {where used} — {whether to keep, replace, or extend}
-
-### Current State Summary
-{2-3 paragraphs describing the state of the code, why it needs changing, and what the key structural problems are}
-```
-
----
-
-### Mode: `refactoring-strategy`
-
-Design the refactoring approach. Propose specific transformations (extract, inline, rename, restructure, migrate). Define behavioral invariants that must hold throughout. Identify patterns to follow from the existing codebase or from best practices.
-
-**Dimension-specific focus** (when provided):
-- **Structural:** Extract module, split file, reduce coupling, enforce boundaries
-- **Logical:** Behavior migration, data model evolution, API versioning, state machine redesign
-- **Visual:** Component refactoring, design token standardization, accessibility remediation, layout restructuring
-- **Migration:** Framework swap, adapter pattern, compatibility shim, incremental migration
-
-**Output structure:**
-
-```markdown
-## Refactoring Strategy
-
-### Target Architecture
-{Description of the desired end state — how the code should look after refactoring}
-
-### Transformation Plan
-| # | Transformation | Type | From → To | Invariants |
-|---|---------------|------|-----------|-----------|
-| 1 | {what to do} | Extract/Inline/Restructure/Migrate/Replace | {current} → {target} | {what must not change} |
-
-### Behavioral Invariants
-| # | Invariant | How to Verify | Current Test Coverage |
-|---|-----------|--------------|---------------------|
-| 1 | {behavior that must be preserved} | {test or assertion strategy} | Covered/Needs test |
-
-### New Patterns Introduced
-| Pattern | Where | Justification | Precedent in Codebase? |
-|---------|-------|--------------|----------------------|
-| {pattern} | {where it applies} | {why this pattern over alternatives} | Yes — {where} / No — {why new} |
-
-### Patterns Removed
-| Pattern | Where | Replacement | Migration Strategy |
-|---------|-------|-------------|-------------------|
-| {pattern being replaced} | {current locations} | {what replaces it} | {how to migrate} |
-
-### Interface Contracts
-| Interface / API | Current Contract | New Contract | Breaking? | Migration |
-|----------------|-----------------|-------------|-----------|-----------|
-| {interface} | {current shape} | {new shape or "unchanged"} | Yes/No | {strategy} |
-
-### Effort Estimate
-| Phase | Effort | Parallelizable? |
-|-------|--------|----------------|
-| {phase} | S/M/L/XL | Yes/No |
-| **Total** | {aggregate} | {parallel lanes} |
-```
-
----
-
-### Mode: `migration-path`
-
-Design a phased execution plan with safe ordering. Each phase must leave the codebase in a working state. Identify parallel lanes, rollback points, and map phases to execution skills.
-
-**Output structure:**
-
-```markdown
-## Migration Path
-
-### Phase Overview
-| Phase | Title | Scope | Depends On | Skill | Effort | Rollback Point? |
-|-------|-------|-------|-----------|-------|--------|----------------|
-| 0 | {test scaffolding} | {add missing tests before refactoring} | — | hatch3r-qa-validation | S/M | Yes |
-| 1 | {first transformation} | {what changes} | Phase 0 | hatch3r-refactor | S/M/L | Yes |
-
-### Phase Details
-
-#### Phase {N}: {Title}
-- **Goal:** {what this phase achieves}
-- **Transformations:** {list of specific changes}
-- **Files:** {list with change descriptions}
-- **Behavioral invariants:** {what must still hold after this phase}
-- **Verification:** {how to confirm the phase is successful}
-- **Rollback:** {how to revert this phase without affecting others}
-
-### Parallel Lanes
-| Lane | Phases | Why Independent |
-|------|--------|----------------|
-| A | {phase numbers} | {no shared files or interfaces} |
-| B | {phase numbers} | {no shared files or interfaces} |
-
-### Critical Path
-{phase X} → {phase Y} → {phase Z} (total: {effort estimate})
-
-### Completion Criteria
-- [ ] All phases completed and verified
-- [ ] All behavioral invariants confirmed via tests
-- [ ] No regression in existing test suite
-- [ ] Dead code from old patterns removed
-- [ ] Documentation updated (specs, ADRs)
-
-### Skill Mapping
-| Phase | Execution Skill | Why |
-|-------|----------------|-----|
-| {phase} | hatch3r-refactor | Structural code quality improvement |
-| {phase} | hatch3r-logical-refactor | Behavior or logic flow change |
-| {phase} | hatch3r-visual-refactor | UI/UX component change |
-| {phase} | hatch3r-qa-validation | Test scaffolding before refactoring |
-```
-
----
-
-### Mode: `library-docs`
-
-Look up current API documentation for specific libraries or frameworks using Context7 MCP.
-
-**Protocol:**
-1. Call `resolve-library-id` with the library name to get the Context7-compatible ID.
-2. Call `query-docs` with the resolved ID and the specific API question.
-3. Summarize findings in structured output.
-
-**Output structure:**
-
-```markdown
-## Library Documentation
-
-### {Library Name} ({version})
-| API / Function | Signature | Notes |
-|---------------|-----------|-------|
-| {API} | {signature or usage pattern} | {relevant constraints, deprecations, or gotchas} |
-
-### Key Patterns
-- {pattern}: {how to use it correctly}
-
-### Breaking Changes / Deprecations
-- {item}: {migration path}
-```
-
----
-
-### Mode: `prior-art`
-
-Research best practices, known issues, ecosystem trends, and prior art via web search. Use for novel problems, security advisories, or approaches not covered by local docs or Context7.
-
-**Output structure:**
-
-```markdown
-## Prior Art Research
-
-### Best Practices
-| # | Practice | Source | Applicability |
-|---|---------|--------|--------------|
-| 1 | {practice} | {source — blog, docs, RFC} | {how it applies to the subject} |
-
-### Known Issues / CVEs
-| # | Issue | Severity | Affected Versions | Mitigation |
-|---|-------|----------|-------------------|------------|
-| 1 | {issue or CVE} | {severity} | {versions} | {fix or workaround} |
-
-### Ecosystem Trends
-- {trend}: {relevance to the subject}
-
-### Reference Implementations
-- {project/example}: {what it demonstrates and how it's relevant}
-```
-
----
-
-### Mode: `requirements-elicitation`
-
-Analyze the task description against the codebase to detect ambiguities, unstated assumptions, and missing requirements. Generate structured questions for the user across 10 dimensions to resolve unknowns before implementation. Triggered by the `hatch3r-deep-context` rule based on complexity tier.
-
-**Protocol:**
-
-1. Parse the task description for vague language ("improve", "better", "proper", "handle", "support", "clean up", "fix", "update") and flag each instance.
-2. Identify unstated assumptions by comparing the task against the codebase structure — what does the task imply but not state explicitly?
-3. For each of the 10 dimensions below, determine if the task description addresses it. If not, generate a targeted question.
-4. Scan the codebase for modules that will be affected by the task. For each, check whether the task description accounts for its consumers, contracts, and side effects. Generate dependency-derived questions from gaps.
-5. Check for cross-cutting concerns triggered by the task and list them with status (addressed / unaddressed).
-
-**10 Dimensions:**
-
-1. **Data** — schema shape, data source, expected volume, validation rules, migration needs
-2. **Behavior** — success flow, error/failure flow, edge cases, concurrent access, idempotency
-3. **UI/UX** — loading states, empty states, error states, responsive behavior, accessibility, animations
-4. **Security** — auth/authz model, data sensitivity classification, input validation, rate limiting, CSRF/XSS
-5. **Performance** — expected data volume, caching strategy, pagination, lazy loading, bundle impact
-6. **Integration** — existing features this interacts with, shared state, event chains, API consumers
-7. **Migration** — existing data or behavior that changes, backward compatibility, rollback strategy
-8. **Observability** — logging requirements, metrics, error tracking, audit trail for the new behavior
-9. **Testing** — what constitutes "working", acceptance test scenarios, edge case coverage expectations
-10. **Rollout** — feature flags, phased rollout, A/B testing, rollback trigger conditions
-
-**Output structure:**
-
-```markdown
-## Requirements Elicitation
-
-### Ambiguity Detection
-| # | Term / Phrase | Context | Why It's Ambiguous | Suggested Clarification |
-|---|--------------|---------|-------------------|------------------------|
-| 1 | {vague term} | {where it appears} | {what's unclear} | {specific question} |
-
-### Dimension Probe Questions
-| # | Dimension | Question | Why This Matters | Default If Unanswered |
-|---|-----------|----------|-----------------|----------------------|
-| 1 | {dimension} | {specific question} | {what could go wrong without an answer} | {safe default the implementer would assume} |
-
-### Dependency-Derived Questions
-| # | Module / Interface | Consumers | Question |
-|---|-------------------|-----------|----------|
-| 1 | {module being changed} | {list of consumers} | {question about contract impact} |
-
-### Cross-Cutting Concern Checklist
-| Concern | Triggered? | Addressed in Task? | Action Needed |
-|---------|-----------|-------------------|--------------|
-| Authentication / Authorization | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Internationalization (i18n) | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Accessibility (a11y) | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Error Handling | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Data Validation | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Observability / Logging | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Backward Compatibility | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-| Feature Flags / Rollout | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
-
-### Requirements Summary
-- **Resolved:** {N} dimensions fully addressed
-- **Needs clarification:** {N} questions requiring user input before implementation
-- **Safe defaults available:** {N} questions where a reasonable default exists if the user defers
-```
-
----
-
-### Mode: `similar-implementation`
-
-Search the codebase for analogous features, components, or modules and extract their implementation conventions as a reference for the implementer. The goal is to ensure new code follows established patterns rather than inventing new approaches.
-
-**Protocol:**
-
-1. Parse the task to extract the core *type* of work — CRUD resource, dashboard widget, API endpoint, auth flow, data pipeline, form, modal, notification, list/table view, search feature, file upload, webhook handler, background job, etc.
-2. Search the codebase for modules and components that perform the same *type* of work. Use file name patterns, directory structure, import analysis, and semantic code search.
-3. Rank matches by structural similarity: file organization, patterns used, complexity level, recency.
-4. For the top 2–3 matches, extract:
-   - File structure and naming conventions (file names, directory placement, barrel exports)
-   - State management pattern (local state, context, store, server state, URL state)
-   - Error handling approach (try/catch style, error boundaries, toast notifications, inline errors)
-   - Data fetching / API pattern (hooks, services, direct fetch, query library)
-   - Test structure and coverage approach (co-located vs separate, naming, mock strategy)
-   - Component composition pattern (container/presenter, compound components, render props — if UI)
-5. Identify where the proposed feature MUST differ from references and why (different data shape, different auth model, different performance requirements).
-6. Present reference implementations with a recommendation for which to follow.
-
-**Output structure:**
-
-```markdown
-## Similar Implementation Analysis
-
-### Work Type Classification
-- **Detected type:** {type of work — e.g., "CRUD resource with list view and detail page"}
-- **Search strategy:** {how references were found — file patterns, directory scan, semantic search}
-
-### Reference Implementations
-| # | Module / Feature | Location | Similarity | Why It's a Good Reference |
-|---|-----------------|----------|-----------|--------------------------|
-| 1 | {name} | {directory/file path} | High/Med | {what makes it analogous} |
-| 2 | {name} | {directory/file path} | High/Med | {what makes it analogous} |
-
-### Convention Extraction
-
-#### Reference 1: {name}
-| Aspect | Convention | Files |
-|--------|-----------|-------|
-| File structure | {pattern — e.g., "feature directory with index barrel, component, hook, types, test files"} | {example files} |
-| State management | {pattern — e.g., "React Query for server state + local useState for UI state"} | {example files} |
-| Error handling | {pattern — e.g., "ErrorBoundary wrapper + toast for mutations + inline for forms"} | {example files} |
-| Data fetching | {pattern — e.g., "custom hook wrapping useQuery, service layer for API calls"} | {example files} |
-| Test structure | {pattern — e.g., "co-located .test.tsx, RTL for components, msw for API mocks"} | {example files} |
-| Component composition | {pattern — e.g., "container fetches data, presenter renders, shared via compound"} | {example files} |
-
-### Recommendation
-- **Primary reference:** {name} — follow this for {rationale}
-- **Secondary reference:** {name} — consult for {specific aspect}
-
-### Divergence Warnings
-| # | Aspect | Reference Pattern | Required Divergence | Reason |
-|---|--------|------------------|-------------------|--------|
-| 1 | {aspect} | {what the reference does} | {what the new feature must do differently} | {why} |
-
-### Pattern-Match Checklist for Implementer
-- [ ] File structure follows {reference} convention
-- [ ] State management uses {pattern} as established in {reference}
-- [ ] Error handling follows {pattern} from {reference}
-- [ ] Data fetching uses {pattern} from {reference}
-- [ ] Test structure matches {pattern} from {reference}
-- [ ] Component composition follows {pattern} from {reference}
-- [ ] Documented divergences with justification for each
-```
-
----
-
-### Mode: `coverage-analysis`
-
-Map existing test coverage, identify gaps, and surface critical untested paths. Used by `hatch3r-test-plan` to understand the current testing baseline before planning new tests.
-
-**Output structure:**
-
-```markdown
-## Coverage Analysis
-
-### Existing Test Inventory
-| Test File | Type | Module / Area Covered | Test Count | Framework |
-|-----------|------|----------------------|-----------|-----------|
-| {path} | Unit/Integration/E2E | {what it tests} | {approx count} | {vitest/jest/playwright/etc.} |
-
-### Coverage Gaps
-| Module / Area | Statement % | Branch % | Function % | Gap Severity | Notes |
-|---------------|------------|----------|-----------|-------------|-------|
-| {module} | {current or "unknown"} | {current or "unknown"} | {current or "unknown"} | Critical/High/Med/Low | {why this gap matters} |
-
-### Critical Untested Paths
-| # | Code Path | File(s) | Risk if Untested | Recommended Test Type |
-|---|-----------|---------|-----------------|---------------------|
-| 1 | {description of untested path} | {file paths} | {what could go wrong} | Unit/Integration/E2E/Property |
-
-### Coverage Metrics Summary
-| Metric | Current | Target (hatch3r-testing rule) | Gap |
-|--------|---------|-------------------------------|-----|
-| Statement coverage | {N}% or unknown | 80% (90% critical) | {delta} |
-| Branch coverage | {N}% or unknown | 70% (85% critical) | {delta} |
-| Function coverage | {N}% or unknown | 80% | {delta} |
-| Mutation score | {N}% or unknown | 70% critical / 60% general | {delta} |
-| Flaky test rate | {N}% or unknown | < 0.5% | {delta} |
-```
-
-**Depth scaling:**
-- **quick**: Test file inventory + coverage metrics summary only. Skip gap analysis and untested paths.
-- **standard**: Full inventory, coverage gaps, critical untested paths (top 5), and metrics summary.
-- **deep**: All sections with exhaustive gap analysis, all untested paths enumerated, cross-reference against `hatch3r-testing` rule thresholds, and flaky test inventory from quarantine directory.
-
----
-
-### Mode: `complexity-risk`
-
-Identify code complexity hotspots, mutation-prone areas, and error handling coverage to prioritize where tests will have the highest impact. Used by `hatch3r-test-plan` to focus testing effort on the riskiest code.
-
-**Output structure:**
-
-```markdown
-## Complexity & Risk Analysis
-
-### Complexity Hotspots
-| # | File / Function | Complexity Signal | Severity | Current Test Coverage | Testing Priority |
-|---|----------------|------------------|----------|---------------------|-----------------|
-| 1 | {file:function} | {high cyclomatic complexity / deep nesting / large function / many branches} | High/Med/Low | Covered/Partial/None | P0/P1/P2/P3 |
-
-### Mutation-Prone Areas
-| # | Module / File | Why Mutation-Prone | Mutation Score (est.) | Recommended Action |
-|---|-------------|-------------------|---------------------|-------------------|
-| 1 | {path} | {many conditionals / complex state transitions / arithmetic logic} | {estimated or measured}% | {add assertions / property tests / mutation testing} |
-
-### Error Handling Coverage
-| # | Error Path | File(s) | Currently Tested? | Failure Impact | Priority |
-|---|-----------|---------|------------------|---------------|----------|
-| 1 | {error scenario} | {file paths} | Yes/No/Partial | {what happens if this error path is wrong} | P0/P1/P2/P3 |
-
-### Recommended Testing Depth
-| Module / Area | Recommended Depth | Rationale |
-|---------------|------------------|-----------|
-| {module} | Thorough (unit + integration + property) / Standard (unit + integration) / Light (unit only) | {complexity, risk, and coverage factors} |
-```
-
-**Depth scaling:**
-- **quick**: Top 5 complexity hotspots + recommended testing depth table only.
-- **standard**: Full hotspots (top 10), mutation-prone areas, error handling coverage (top 5), and recommended depth.
-- **deep**: All sections exhaustively. Cross-reference mutation targets from `hatch3r-testing` rule (70% critical, 60% general). Include estimated mutation scores and specific assertion gaps.
-
----
-
-### Mode: `test-pattern`
-
-Extract existing test conventions, framework usage, mock patterns, and helper libraries to ensure new tests follow established patterns. Used by `hatch3r-test-plan` to align the test strategy with the project's existing test infrastructure.
-
-**Output structure:**
-
-```markdown
-## Test Pattern Analysis
-
-### Framework & Tooling Inventory
-| Tool | Version | Config File | Purpose |
-|------|---------|------------|---------|
-| {vitest/jest/playwright/stryker/etc.} | {version} | {config path} | {unit/integration/E2E/mutation} |
-
-### Directory Conventions
-| Test Type | Directory | Naming Pattern | Co-located? |
-|-----------|-----------|---------------|-------------|
-| Unit | {path} | {pattern — e.g., *.test.ts} | Yes/No |
-| Integration | {path} | {pattern} | Yes/No |
-| E2E | {path} | {pattern} | Yes/No |
-| Fixtures | {path} | {pattern} | — |
-| Quarantine | {path or "none"} | {pattern} | — |
-
-### Mock & Fixture Patterns
-| Pattern | Where Used | Convention | Compliance with hatch3r-testing |
-|---------|-----------|-----------|-------------------------------|
-| {fakes / stubs / mocks / MSW / nock / etc.} | {example files} | {how the project uses this pattern} | {aligned — fakes > stubs > mocks / divergent — explain} |
-
-### Test Helper Library
-| Helper | Location | Purpose | Used By |
-|--------|----------|---------|---------|
-| {factory function / builder / custom matcher / setup utility} | {file path} | {what it does} | {which test files use it} |
-
-### Property-Based Testing Usage
-| Status | Library | Where Used | Coverage |
-|--------|---------|-----------|---------|
-| {Active / Not used / Minimal} | {fast-check / etc. or "none"} | {file paths or "N/A"} | {which function types are covered} |
-
-### Convention Compliance
-| Convention (hatch3r-testing rule) | Current State | Compliance |
-|----------------------------------|--------------|-----------|
-| Deterministic (no wall clock) | {compliant / violations found} | {details} |
-| Isolated (own setup/teardown) | {compliant / violations found} | {details} |
-| Fast (unit < 50ms, integration < 2s) | {compliant / unknown / violations} | {details} |
-| Named clearly (behavior descriptions) | {compliant / mixed / non-compliant} | {details} |
-| No network in unit tests | {compliant / violations found} | {details} |
-| No type escape hatches | {compliant / violations found} | {details} |
-| Fakes > stubs > mocks hierarchy | {followed / partially / not followed} | {details} |
-| Factory over fixtures | {followed / partially / not followed} | {details} |
-```
-
-**Depth scaling:**
-- **quick**: Framework inventory + directory conventions only.
-- **standard**: Full inventory, directory conventions, mock patterns, and convention compliance summary.
-- **deep**: All sections exhaustively. Include test helper library analysis, property-based testing status, and detailed convention compliance with file-level violations.
-
----
-
-### Mode: `boundary-analysis`
-
-Map integration boundaries, external dependencies, data flow boundaries, and event chains to identify where integration and contract tests are most needed. Used by `hatch3r-test-plan` to ensure test coverage at system seams.
-
-**Output structure:**
-
-```markdown
-## Boundary Analysis
-
-### Module Boundaries
-| Boundary | Module A | Module B | Interface Type | Current Test Coverage | Test Need |
-|----------|----------|----------|---------------|---------------------|----------|
-| {boundary name} | {module} | {module} | {API / import / event / shared state} | Covered/Partial/None | Integration/Contract/E2E |
-
-### External Dependencies
-| Dependency | Type | Mock Strategy | Current Mock Coverage | Risk if Unmocked |
-|-----------|------|-------------|---------------------|-----------------|
-| {database / API / service / SDK} | {runtime / build-time / optional} | {fake / stub / MSW / emulator / none} | Covered/Partial/None | {what breaks without proper mocking} |
-
-### Data Flow Boundaries
-| Flow | Source | Transform(s) | Sink | Validation Points | Test Coverage |
-|------|--------|-------------|------|------------------|-------------|
-| {flow name} | {where data enters} | {processing steps} | {where data is consumed} | {where validation happens} | Covered/Partial/None |
-
-### Event / Callback Chains
-| Event | Emitter | Listener(s) | Side Effects | Test Coverage |
-|-------|---------|------------|-------------|-------------|
-| {event name} | {where emitted} | {where consumed} | {what changes} | Covered/Partial/None |
-
-### API Surface Coverage
-| Endpoint / Interface | Methods | Parameters | Response Shapes | Test Coverage | Priority |
-|---------------------|---------|-----------|----------------|-------------|----------|
-| {endpoint or public interface} | {methods} | {param count / complexity} | {shape count} | Covered/Partial/None | P0/P1/P2/P3 |
-```
-
-**Depth scaling:**
-- **quick**: Module boundaries + external dependencies only (top 5 each).
-- **standard**: Full module boundaries, external dependencies, data flow boundaries, and API surface coverage.
-- **deep**: All sections exhaustively. Include event/callback chains, full data flow tracing, and priority-ranked API surface analysis.
-
----
-
-### Mode: `risk-prioritization`
-
-Produce a risk-ranked prioritization of testing effort considering business impact, security exposure, change frequency, and current coverage. Used by `hatch3r-test-plan` to order test implementation for maximum risk reduction.
-
-**Output structure:**
-
-```markdown
-## Risk-Based Test Prioritization
-
-### Risk Matrix
-| # | Module / Area | Business Impact | Security Exposure | Change Frequency | Current Coverage | Risk Score | Test Priority |
-|---|-------------|----------------|------------------|-----------------|-----------------|-----------|--------------|
-| 1 | {module} | Critical/High/Med/Low | Critical/High/Med/Low | High/Med/Low | High/Med/Low/None | {weighted score} | P0/P1/P2/P3 |
-
-### Recommended Test Investment Order
-| Priority | Module / Area | Recommended Tests | Effort | Risk Reduction |
-|----------|-------------|------------------|--------|---------------|
-| P0 | {module} | {test types and count} | S/M/L | {what risk this eliminates} |
-| P1 | {module} | {test types and count} | S/M/L | {what risk this reduces} |
-| P2 | {module} | {test types and count} | S/M/L | {what risk this reduces} |
-| P3 | {module} | {test types and count} | S/M/L | {incremental improvement} |
-
-### Quick Wins
-| # | Test to Add | Module | Effort | Risk Reduction | Why It's a Quick Win |
-|---|-----------|--------|--------|---------------|---------------------|
-| 1 | {specific test description} | {module} | XS/S | {impact} | {already has test infra / simple boundary / high-value assertion} |
-
-### Technical Debt Tests
-| # | Debt Item | Module | Current Risk | Recommended Test | Blocks |
-|---|----------|--------|-------------|-----------------|--------|
-| 1 | {tech debt — e.g., untested legacy module, missing error handling tests} | {module} | {what could go wrong} | {test type and scope} | {what this blocks — e.g., safe refactoring, migration} |
-```
-
-**Depth scaling:**
-- **quick**: Risk matrix (top 5 modules) + quick wins only.
-- **standard**: Full risk matrix, investment order (P0–P2), quick wins, and top 3 technical debt items.
-- **deep**: All sections exhaustively. Full risk matrix with weighted scoring, complete investment order (P0–P3), all quick wins, and comprehensive technical debt test inventory.
+Mode definitions are in `agents/modes/`. Read the mode file for the full output structure and protocol.
+
+### Planning & Design Modes
+| Mode | File | Purpose |
+|------|------|---------|
+| `codebase-impact` | `agents/modes/codebase-impact.md` | Map affected files, modules, integration points, and blast radius |
+| `feature-design` | `agents/modes/feature-design.md` | Break subject into sub-tasks with user stories and acceptance criteria |
+| `architecture` | `agents/modes/architecture.md` | Design data model, API contracts, component design, ADR candidates |
+| `risk-assessment` | `agents/modes/risk-assessment.md` | Identify risks, security, performance, breaking changes |
+| `requirements-elicitation` | `agents/modes/requirements-elicitation.md` | Detect ambiguities and missing requirements across 10 dimensions |
+| `similar-implementation` | `agents/modes/similar-implementation.md` | Find analogous code in the codebase and extract conventions |
+
+### Debugging & Investigation Modes
+| Mode | File | Purpose |
+|------|------|---------|
+| `symptom-trace` | `agents/modes/symptom-trace.md` | Trace execution path from user action to observed failure |
+| `root-cause` | `agents/modes/root-cause.md` | Analyze candidate root causes, rank hypotheses |
+| `impact-analysis` | `agents/modes/impact-analysis.md` | Map blast radius across flows, modules, data, users |
+| `regression` | `agents/modes/regression.md` | Investigate when issue was introduced via git/dep/config history |
+
+### Refactoring Modes
+| Mode | File | Purpose |
+|------|------|---------|
+| `current-state` | `agents/modes/current-state.md` | Map complexity, coupling, cohesion, coverage, code quality |
+| `refactoring-strategy` | `agents/modes/refactoring-strategy.md` | Design transformations with behavioral invariants |
+| `migration-path` | `agents/modes/migration-path.md` | Phase execution plan with safe ordering and rollback points |
+
+### Test Planning Modes
+| Mode | File | Purpose |
+|------|------|---------|
+| `coverage-analysis` | `agents/modes/coverage-analysis.md` | Map existing test coverage and identify gaps |
+| `complexity-risk` | `agents/modes/complexity-risk.md` | Identify complexity hotspots and prioritize testing effort |
+| `test-pattern` | `agents/modes/test-pattern.md` | Extract existing test conventions and framework usage |
+| `boundary-analysis` | `agents/modes/boundary-analysis.md` | Map integration boundaries and contract test needs |
+| `risk-prioritization` | `agents/modes/risk-prioritization.md` | Risk-ranked testing effort prioritization |
+
+### External Research Modes
+| Mode | File | Purpose |
+|------|------|---------|
+| `library-docs` | `agents/modes/library-docs.md` | Look up current API docs via Context7 MCP |
+| `prior-art` | `agents/modes/prior-art.md` | Research best practices and prior art via web search |
 
 ---
 
@@ -1020,15 +157,18 @@ Example in a research finding:
 
 Apply this format whenever research findings involve trade-off analysis, risk assessment, architectural recommendations, or when the evidence supports multiple valid interpretations.
 
-## Agent Size and Split Guidance
+## Research Quality Signals
 
-This agent file is large (~1,000+ lines) because it serves as a composable mode library. The current design is intentional: all modes share a single research protocol, tooling hierarchy, and structured output contract. Splitting individual modes into separate agents would break the composability that allows a single researcher invocation to execute multiple modes.
+When producing research output, every finding must include:
 
-**When to split:** If this file exceeds ~1,500 lines (e.g., due to new mode additions), consider extracting mode groups into companion agents (e.g., a codebase-mapping agent for `codebase-impact`, `current-state`, `boundary-analysis` modes, and a test-planning agent for `coverage-analysis`, `complexity-risk`, `test-pattern`, `risk-prioritization` modes). The researcher would retain the core protocol and general modes, delegating to companions when specialized modes are requested. Each companion agent would share the same research protocol preamble and tooling hierarchy sections.
+1. **Evidence source.** State where the finding came from (file path, documentation section, search result URL). Unsourced findings reduce implementer confidence and may cause rework in Phase 2.
+2. **Confidence level.** Rate each finding per the quality charter. Research findings with low confidence should be explicitly flagged so the implementer treats them as assumptions rather than facts.
+3. **Actionability.** Each finding should answer "so what?" for the implementer. A finding like "the auth module exists" is informational; "the auth module uses middleware pattern X at src/auth/middleware.ts -- follow this pattern for new auth checks" is actionable.
+4. **Completeness markers.** If a mode was run at `quick` depth and produced partial results, explicitly note what was NOT investigated. Example: "At quick depth, only scanned top-level module structure. Deep analysis of internal module dependencies was not performed."
 
 ## Boundaries
 
-- **Always:** Follow the tooling hierarchy (project docs → codebase → Context7 → web research). Use the platform CLI (check `platform` in `.agents/hatch.json`). Stay within the research brief's scope. Produce structured output matching the mode's specification. Report BLOCKED if the brief is ambiguous or contradictory.
+- **Always:** Follow the tooling hierarchy (project docs -> codebase -> Context7 -> web research). Use the platform CLI (check `platform` in `.agents/hatch.json`). Stay within the research brief's scope. Produce structured output matching the mode's specification. Report BLOCKED if the brief is ambiguous or contradictory.
 - **Ask first:** If the brief's scope is unclear, if contradictions are found between sources, or if critical context is missing.
 - **Never:** Create files. Modify code. Create branches, commits, or PRs. Modify board status. Expand scope beyond the research brief. Invent findings not supported by evidence.