# Light Discovery Process for Extensions

## Objective
Perform a targeted, time-efficient investigation focused on integration feasibility and compatibility when extending an existing system with a well-understood addition.

---

## Focused Discovery Steps

### 1. Extension Point Analysis
**Identify Where and How to Plug In**
- Locate the existing extension points, interfaces, or hooks that this feature can attach to
- Determine the precise modification scope: which files, modules, and components will change
- Identify patterns already established in the codebase that this feature should follow
- Confirm backward compatibility requirements — what must not change for existing consumers

### 2. Dependency Compatibility Check
**Verify That the Extension Is Safe to Add**
- Confirm version compatibility for any new dependencies being introduced
- Check that existing API contracts consumed by this feature have not changed in recent versions
- Verify the build and test pipeline will not break due to the addition

### 3. Technology Verification for New Libraries
**For Each New Library Only** (skip for purely in-house extensions):
- Use WebSearch to retrieve official documentation and confirm active maintenance
- Verify basic integration patterns and idiomatic usage
- Check for reported compatibility issues with the existing stack
- Confirm licensing is compatible with the project's requirements
- Record key findings in `research.md` under the technology alignment section

### 4. Integration Risk Assessment
**Quick Triage of What Could Break**
- Identify potential impact on existing functionality and test coverage
- Assess performance implications: does this add latency to hot paths?
- Review security surface: does this introduce new input vectors or permission requirements?
- Determine what new tests are required to maintain confidence in the extended system

---

## When to Escalate to Full Discovery

Switch to the full discovery process (`design-discovery-full.md`) if any of the following are true:
- The extension requires significant architectural changes, not just additive code
- A new external service must be integrated for the first time
- The feature touches authentication, authorization, or other security-sensitive flows
- The change affects performance-critical paths that have defined SLA targets
- A key dependency is poorly documented or its behavior is uncertain
- The scope of files and components affected exceeds initial expectations

---

## Output Requirements

Capture the following in `research.md`:
- **Integration Approach**: How the extension connects to the existing system; note any new boundary implications
- **Files and Components to Modify**: Specific list with a one-line rationale for each
- **New Dependencies**: Library name, version, and role; licensing confirmed
- **Compatibility Confirmed**: Checklist of verified API contracts and build pipeline status
- **Integration Risks and Mitigations**: Short list of risks with their proposed mitigations
- **Testing Focus Areas**: Which existing tests may be affected; what new tests are required
