progressive-abstractionlisted

# Progressive Abstraction: Three-Layer Issue Triage **Core principle: never enter implementation details before the fix direction is judged at the architecture layer.** The first reaction to an issue is not reading code — it is asking "which layer owns this problem?" Execute the three layers in order. Each has a concrete output; do not advance while the current layer is unresolved. ## L1: Architecture Direction Goal: identify the **owning layer** and classify the problem. 1. Read the full issue and the entire comment thread. Record: who reported it, who already diagnosed, whether maintainers are involved, whether the lane is occupied. 2. List the candidate layers of the system (e.g. provider adapter / transport / parse / schema / validation / execution / projection) and pick the one that *should* own the fix, with a one-line justification. Also state where the fix should **not** land — bracketed exclusion ("at the parse boundary, not in the schema") carries more information than a positive description. 3. Classify the problem: **correctness, completeness, or product decision?** The test is whether wrong behavior can actually occur. - Wrong behavior can occur → correctness. Fix it directly; ask no one. - Only "coverage gaps / doesn't help some cases" → completeness. Do not let anyone (including AI reviewers) reframe it as "incorrect". - Whether to fix depends on project stance (e.g. "should we absorb third-party quirks?") → product decision. **Hand it to the main