Fix qualified range endpoints and literal recovery

.agents/skills/gstack-investigate/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: investigate
+description: Investigate and fix Peeper compiler bugs, incorrect diagnostics, crashes, and regressions. Use when asked to debug, reproduce, find root cause, or fix broken compiler behavior, including parser, semantics, IR, backend, LSP, and package tooling. Prove the failure before implementing the smallest verified fix.
+---
+
+# Compiler investigation
+
+Portable adaptation of the locally installed gstack investigation workflow.
+Read `AGENTS.md` and `RULES.md` for edit, validation, review, and delivery gates.
+This skill needs only repository tools; no global gstack scripts or services.
+
+## 1. Pin the failure
+
+- Read the issue, explicit user requirements, and relevant local plan.
+- Check branch, status, and recent changes in the affected files. Distinguish
+  pre-existing user work from the requested change.
+- Record exact input, expected behavior, actual diagnostics/output, and the
+  command that reproduces it. Reduce to the smallest source or test that still fails.
+- For a plan-only request, investigate and write the plan without implementing.
+
+## 2. Trace the owner
+
+- Search symbols and their callers before reading broad directories.
+- Follow input through the affected producers and consumers. For compiler bugs,
+  inspect parsing, binding/type evidence, lowering, and runtime only as relevant.
+- Compare the failing path with a working neighboring case. Identify which
+  owner lost, duplicated, or incorrectly reconstructed a fact.
+- Inspect diagnostics and source locations, node/symbol identity, evaluation
+  order, mutation, caching, and phase invariants before replacing behavior.
+- State one specific, testable root-cause hypothesis.
+
+## 3. Prove the hypothesis
+
+- Prefer a focused regression that fails on the baseline and positive controls
+  that pass. Reuse existing test harnesses; do not add production APIs for tests.
+- If it fails for a different reason, gather more evidence before patching.
+- Use temporary probes outside tracked source. Follow the repository's experiment
+  lifecycle if production instrumentation is genuinely needed.
+- After three rejected hypotheses, summarize evidence and ask for a decision
+  instead of stacking speculative fixes.
+
+## 4. Fix at the canonical boundary
+
+- Complete the repository pre-change and pre-patch gates.
+- Change the existing owner rather than scattering caller workarounds or writing
+  a parallel implementation. Preserve each owned behavior or explain its change.
+- Keep the diff scoped to the reproduced defect and necessary coverage.
+- Language changes need positive and applicable negative `x_test/` coverage,
+  executed with a rebuilt `build/bin/peeper`.
+- Stop at the approved step boundary unless multiple steps were explicitly requested.
+
+## 5. Verify and hand off
+
+- Run focused tests first, affected packages next, then required full checks once.
+  Reproduce the original source failure with the repaired compiler.
+- Apply [Peeper code review](../peeper-code-review/SKILL.md) to the completed diff;
+  this investigation does not replace standards/spec review.
+- Update the persistent local plan with red/green evidence, commands, outcomes,
+  remaining risks, and resume context.
+- Report symptom, proven root cause, fix, validation, review findings, and the
+  required Rules check. Distinguish passed checks from checks not run.
+
+## Routing examples
+
+- "Fix #157: qualified range endpoints eat the loop body" → reproduce parser
+  failure, inspect context propagation, test preserved enum/index behavior.
+- "LSP missed a file after reopening the workspace" → reproduce the state
+  sequence, inspect cache ownership/invalidation, add a focused regression.
+- "Plan scoped allocators" → use `plan-eng-review`; no bug is established.

.agents/skills/gstack-investigate/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "gstack-investigate"
+  short_description: "Reproduce compiler bugs, prove root cause, fix and validate."
+  default_prompt: "Use $investigate to investigate and fix this Peeper compiler bug."
+policy:
+  allow_implicit_invocation: true

.agents/skills/gstack-plan-eng-review/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: plan-eng-review
+description: Brainstorm implementation approaches, plan Peeper compiler features, and review architecture or execution plans before coding. Use for requests to plan, compare designs, decide compiler boundaries, or review an implementation approach. Ground options in current source, reuse, language semantics, invariants, and executable fixtures.
+---
+
+# Compiler engineering plan review
+
+Portable adaptation of the locally installed gstack engineering-plan workflow.
+Read `AGENTS.md` and `RULES.md` for scope, local-plan, edit, and delivery gates.
+This skill needs only repository tools; no global gstack scripts or services.
+
+## 1. Establish scope
+
+- Use the issue, user request, or named plan as the review target. Ask only when
+  the target or an implementation-critical requirement is actually ambiguous.
+- Read relevant source, callers, tests, specs, and architecture documents. Verify
+  document claims against behavior; do not treat historical plans as task status.
+- Record the current need, existing owner, canonical implementation to reuse,
+  proposed shape, and experimental exit condition.
+- Planning does not authorize production edits. An explicit request to implement
+  permits execution after the repository gates and necessary decisions are met.
+
+## 2. Compare approaches
+
+- For unsettled design, propose two or three meaningfully different approaches.
+  Include direct reuse or deletion when it can meet the requirement.
+- Explain behavior, affected owners, invariant risks, migration cost, and test
+  obligations. Recommend the smallest complete solution, not the smallest shortcut.
+- For a proven defect with a clear owner, do not invent competing designs to fill
+  a quota. Use `investigate` to establish root cause and evaluate the focused fix.
+- Ask for a decision when language semantics, ownership, ABI, or incompatible
+  architecture choices remain open. Separate recommendations from approved choices.
+
+## 3. Review four areas
+
+### Architecture and data flow
+
+- Identify producers, consumers, and the fact crossing each affected boundary.
+- Inventory validation, diagnostics/locations, identity, mutation, caching,
+  evaluation order, and ownership/lifetime obligations before moving responsibility.
+- Use a compact ASCII diagram when it clarifies nontrivial flow.
+- Name concrete failure modes and how the plan preserves or tests the boundary.
+
+### Code quality
+
+- Prefer canonical owners and direct calls. Check proposed functions/fields for
+  current production consumers and the exact helper allowance in `RULES.md`.
+- Remove wrappers, stale aliases, ignored parameters, and duplicated decisions.
+  Similar-looking code with distinct semantics may correctly remain separate.
+- Keep unrelated refactors outside the task. Do not add speculative frameworks.
+
+### Tests
+
+- Map acceptance and rejection cases to existing package tests and `x_test/`.
+- Include a red baseline for bugs, preserved neighboring syntax/diagnostics,
+  source locations and bindings, and downstream lowerability/runtime evidence.
+- Distinguish native execution from cross-target object validation. Cover affected
+  target widths where numeric, pointer, layout, or ABI behavior requires it.
+- Specify focused, affected, full, bundle/fixture, and diff-check commands.
+
+### Performance
+
+- Check whether traversal, copying, allocations, cache lifetime, or invalidation
+  change. Measure only a concrete relevant cost; do not invent a benchmark project.
+- Record no material performance change when that is the source-backed conclusion.
+
+## 4. Produce an executable plan
+
+- Use the persistent `*.localplan.md` format in `AGENTS.md`.
+- Each step names goal, reason, files/owners, invariants, validation, and review stop.
+- Preserve completed work and risks; do not reduce the plan to a scratch checklist.
+- Report verified findings, recommendation, decisions still needed, and next step.
+- During implementation, use [Peeper code review](../peeper-code-review/SKILL.md)
+  for completed source changes. Plan review does not substitute for diff review.
+
+## Routing examples
+
+- "Plan #157" → inspect parser owner, delimiter contexts, preserved enum syntax,
+  and existing range tests; produce focused fix/validation steps.
+- "Brainstorm default-argument snapshot semantics" → compare evaluation-order
+  and ownership models, surface the language decision before implementation.
+- "Review this PR diff" → use `peeper-code-review` for standards/spec findings.

.agents/skills/gstack-plan-eng-review/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "gstack-plan-eng-review"
+  short_description: "Plan compiler changes around owners, invariants and fixtures."
+  default_prompt: "Use $plan-eng-review to plan or review this Peeper compiler change."
+policy:
+  allow_implicit_invocation: true

.gitignore

@@ -17,6 +17,7 @@ _gen
 .tmpdebug
 _tmp
 *.localplan.md
+backlog.md
 *.html
 playground
 installers/dist
@@ -33,6 +34,8 @@ clean.md
 !.agents/skills/peeper-code-review/
 .agents/skills/peeper-code-review/*
 !.agents/skills/peeper-code-review/SKILL.md
+!.agents/skills/gstack-investigate/
+!.agents/skills/gstack-plan-eng-review/
 !.gitignore
 !.github/
 !.github/workflows/

AGENTS.md

@@ -10,6 +10,21 @@ For code-review requests, read [Peeper code review](.agents/skills/peeper-code-r
 It captures the review workflow and user's simplicity preferences; use `RULES.md`
 for durable engineering requirements.
 
+### Automatic skill routing
+
+Read the matching repo-local skill before starting its workflow, even when the
+user does not name it. Use the skill tool when available; otherwise read its file.
+
+| Task | Local skill |
+| --- | --- |
+| Investigate or fix compiler bugs, diagnostics, crashes, or regressions | [investigate](.agents/skills/gstack-investigate/SKILL.md) |
+| Brainstorm implementation approaches, plan compiler features, or review architecture/execution plans | [plan-eng-review](.agents/skills/gstack-plan-eng-review/SKILL.md) |
+| Review source changes, branches, or PRs; audit completed implementation | [peeper-code-review](.agents/skills/peeper-code-review/SKILL.md) |
+
+Use investigation and planning alongside Peeper code review when each phase is
+needed. Skills do not authorize implementation during a plan-only request or
+change the edit, validation, review, and delivery gates below.
+
 ---
 
 ## 1) Required pre-change check

RULES.md

@@ -123,6 +123,8 @@ Fix defect at source layer when possible. Use workaround only with explicit appr
 
 Remove dead code and migration debris in same change. Do not trade correctness for fewer edited files.
 
+Peeper is pre-stable and targets the current language grammar. Do not preserve deprecated syntax, compatibility paths, or migration-only parser behavior unless explicitly requested. Unsupported syntax must still be rejected through current grammar and validation.
+
 ## 7. Errors, diagnostics, and panics
 
 Preserve root-cause context and error identity. When wrapping Go error, use `%w` so callers can use `errors.Is` and `errors.As`.