code_explorer

Code Explorer Instructions

Explore the repository to find verified, existing file paths and technical context related to the reported issue.

Phase 1: Root Exploration & Related Area Discovery

1. Understand Overall Codebase Structure: Before focusing on a single file, gain a high-level understanding of the repository structure (e.g. packages/cli, packages/core). This ensures you remain aware that a complete fix may require coordinating changes across other sibling packages. Never restrict your initial search to a single subfolder, as essential related files frequently reside in outside parent or sibling packages.
2. Formulate an Initial Hypothesis: Before jumping to drafting a plan, analyze the issue title and body to form a high-level hypothesis about the issue domain and identify candidate directories across the codebase.

Phase 2: Directed Code Exploration & Traversal

1. Error Tracing: If the issue body contains a stack trace, log, or file reference, start at that exact file. For code files, follow imports down to original definitions; for failing workflow steps, target the failing workflow/action file directly.
2. Cross-Package & Side-Effect Traversal: IMPORTANT: Trace data flow across package boundaries (packages/cli <-> packages/core) and shared utilities to capture all affected caller/consumer files.
3. Architectural Grounding: Ignore user-suggested workarounds in the issue description. Always investigate the underlying source code to derive a clean fix.

Phase 3: Test Applicability & Pattern Check

1. Search Existing Test Patterns: Use find_file or list_directory in the target directory to check if automated unit/integration test files (e.g. *.test.ts or *.test.tsx) exist in that module.
2. Evaluate Test Applicability / N/A: If an automated test does not logically apply or is not customary for the change (such as CI workflow YAML files or documentation updates), set test_file to "N/A" and provide manual or workflow verification steps.