Agentic Bug Resolution

Fetch GitHub issue #6992 from pydata/xarray and extract the bug details.

List my CoreStory projects and select the one for xarray.

Create a CoreStory conversation titled
"Bug Investigation: #6992 - reset_index coord_names issue"

Send CoreStory message: "What files are responsible for the reset_index
functionality for Dataset objects? I need to understand:
1. Primary implementation files
2. Test coverage
3. Helper/utility modules
4. Integration points with other components"

Send CoreStory message: "In the reset_index method for Dataset, what are
the key data structures involved? Specifically:
1. What is _coord_names and what does it contain?
2. What is _variables and what does it contain?
3. What is the relationship between _coord_names and _variables?
4. When reset_index is called with drop=True vs drop=False, how should
   these data structures be updated?"

Send CoreStory message: "Have there been recent changes to the reset_index
functionality? What was the original design intent? Are there related issues?"

Send CoreStory message: "If there's a bug where reset_index with drop=True
leaves stale coordinate names in _coord_names, what are the specific code
paths I should investigate? Walk me through the logic flow."

Send CoreStory message: "Based on the symptom that _coord_names contains
stale entries after drop=True, what are the most likely root causes? Is this
a missing cleanup operation, incorrect state update, or something else?
Rank by probability."

Send CoreStory message: "In dataset.py, where is the _coord_names update
logic during reset_index? Which methods should I examine?"

def test_reset_index_drop_removes_coord_names():
    """Test that reset_index(drop=True) removes coordinate names.

    Bug: GH#6992 - _coord_names retains stale entries after drop=True
    Expected: coord_names should only contain coordinates still in _variables
    Invariant: coord_names ⊆ variables.keys()
    """
    # Setup: Create Dataset with multi-index
    ds = Dataset({
        'data': ('x', [1, 2, 3]),
        'level_1': ('x', ['a', 'b', 'c']),
        'level_2': ('x', [10, 20, 30])
    })
    ds = ds.set_index(x=['level_1', 'level_2'])

    # Action: Reset index with drop=True
    result = ds.reset_index('x', drop=True)

    # Assert: Coordinate names should be cleaned up
    assert 'level_1' not in result._coord_names
    assert 'level_2' not in result._coord_names
    assert result._coord_names.issubset(result._variables.keys())

Send CoreStory message: "I've written this test to reproduce the bug:

[paste test code]

Does this correctly test the expected behavior according to the system design?
Are there edge cases I'm missing?"

Send CoreStory message: "Looking at line 4180 in dataset.py:

    coord_names = set(new_variables) | self._coord_names

This only ADDS to coord_names but doesn't REMOVE dropped coordinates.
Should this instead be:

    coord_names = (self._coord_names - set(drop_indexes)) | set(new_variables)

So we remove the dropped index names before adding new ones?"

Send CoreStory message: "I've implemented this fix: [describe change].
Does this align with the system architecture? Could it have unintended
side effects? Does it maintain all invariants?"

Send CoreStory message: "My basic test passes. What edge cases should I
test? Are there scenarios where reset_index behavior gets more complex?"

Fix: reset_index(drop=True) leaves stale coord_names

Problem:
After calling reset_index with drop=True on a multi-index Dataset,
_coord_names retains entries for dropped coordinates.

Root Cause:
Line 4180 in dataset.py only adds new_variables to coord_names but
never removes dropped coordinates, violating the invariant
coord_names ⊆ variables.keys().

Solution:
Subtract drop_indexes from coord_names before adding new_variables.

Invariants Restored:
- coord_names ⊆ variables.keys()

Testing:
- Added test_reset_index_drop_removes_coord_names
- Added 3 edge case tests (partial multi-index, single-level, with attrs)
- All existing tests pass (no regressions)

References:
- Issue: #6992
- CoreStory Investigation: [conversation-id]

Rename to: "Bug Investigation: #6992 - RESOLVED - reset_index coord_names cleanup"

What files are responsible for [feature]? I need to understand primary
implementation files, test coverage, helper modules, and integration points.

What invariants should [data structure] maintain? What relationships must
hold between [A] and [B]? What are the pre/post conditions for [operation]?

Walk me through the execution flow of [operation] from entry point to exit:
key decision points, state transformations, error handling paths.

Given [symptom], what are the most likely root causes? For each: explain why
it could cause the symptom, rate probability, and point to specific code
locations to investigate.

I'm proposing this fix: [describe change]. Does this align with system
architecture? Does it maintain all invariants? Could it have unintended
side effects?

What existing tests cover [feature]? Are there gaps? What edge cases
should I test?

What changes have been made to [feature] recently? Related PRs, design
decisions, known limitations, evolution over time.

What user stories/requirements exist for [feature]? Acceptance criteria,
business rules, security requirements.

What other components depend on [feature]? Direct callers, integration
points, downstream impacts of changing [behavior].

I'm investigating a bug where [symptom]. Please answer:

Architecture: What files implement [feature]? Key data structures?
Expected Behavior: What invariants should hold? What should happen when
[operation] is called with [parameters]?
Code Paths: Walk me through the execution flow. Where could the bug be?
Testing: What existing tests cover this? What tests should I add?

Send CoreStory message: "What security considerations apply to [feature]?
Are there security requirements I should verify? Could this bug have
security implications?"

Send CoreStory message: "What other systems or components integrate with
[feature]? What downstream impacts should I consider if I change [behavior]?"

Send CoreStory message: "What are the performance characteristics of
[feature]? Expected complexity? Known bottlenecks?"

Send CoreStory message: "I'm investigating [bug A], [bug B], and [bug C]
which seem related. Are there common patterns or root causes? Could they
stem from the same underlying issue?"

mkdir -p .claude/skills/bug-resolver

mkdir -p .claude/commands

git add .claude/skills/ .claude/commands/
git commit -m "Add CoreStory bug resolution skill and command"

Fix bug #6992
Investigate issue JIRA-1234
Debug the login problem

/fix-bug #6992
/fix-bug JIRA-1234
/fix-bug "Users can't login after password reset"

---
name: CoreStory Bug Resolver
description: Resolves bugs using CoreStory's code intelligence and TDD methodology. Activates on bug fix requests or ticket IDs.
---

# CoreStory Bug Resolver

When this skill activates, execute the six-phase bug resolution workflow.

## Activation Triggers

Activate when user requests:
- Bug fix or investigation
- Ticket resolution (e.g., "Fix bug #6992", "Investigate JIRA-123")
- Any request containing "bug", "issue", "broken", "not working"

## Prerequisites

- CoreStory MCP server configured
- At least one CoreStory project with completed ingestion
- (Optional) Ticketing system MCP (GitHub Issues, Jira, ADO, Linear)

## Phase 1: Bug Intake & Context Gathering

1. **Extract Bug Information**
   - If ticket ID provided: fetch via appropriate MCP, parse symptoms, reproduction steps, expected/actual behavior
   - If described directly: extract from user message, ask for missing details

2. **Select CoreStory Project**
   ```
   Use CoreStory MCP: list_projects
   ```
   - Multiple projects → ask user which one
   - Single project → auto-select
   - Verify status is "completed"

3. **Create Investigation Conversation**
   ```
   Use CoreStory MCP: create_conversation
   Title: "Bug Investigation: #[ID] - [brief description]"
   ```
   Store conversation_id for all subsequent queries.

**Report:**
```
 Starting bug investigation for [ticket-id]
Bug: [description]
Symptoms: [what's broken]
Expected: [correct behavior]
CoreStory conversation: [conversation-id]
```

## Phase 2: Understanding System Behavior (Oracle Phase)

Send three CoreStory queries in sequence:

**Query 1 — Architecture Discovery:**
```
What files are responsible for [affected feature]? I need:
1. Primary implementation files
2. Test coverage
3. Helper/utility modules
4. Integration points
```

**Query 2 — Invariants & Data Structures:**
```
What are the key data structures in [feature]? What invariants must hold?
What relationships between data structures? How should [operation] affect
state when [parameters from bug]?
```

**Query 3 — Historical Context:**
```
Have there been recent changes to [feature]? Design intent?
Related user stories or issues?
```

**Report:** Summarize key files, critical invariants, data structures, and design context.

## Phase 3: Hypothesis Generation (Navigator Phase)

**Query 1:** Map symptoms to code paths
**Query 2:** Generate ranked root cause candidates
**Query 3:** Get precise file/method navigation

**Report:** Most likely root cause with location, alternatives, and code path to investigate.

## Phase 4: Test-First Investigation

**CRITICAL: Write tests BEFORE reading implementation code.**

1. **Write failing test** based on expected behavior and invariants from Phase 2
2. **Verify test fails** — confirms bug exists
3. **Validate test with CoreStory** — paste test code, ask if it correctly tests expected behavior
4. **Read code** — only now, focused on methods CoreStory identified
5. **Identify bug** — compare against expected behavior
6. **Validate finding with CoreStory** — paste code snippet, explain hypothesis, get confirmation

## Phase 5: Solution Development

1. **Implement minimal fix** — smallest change that restores invariant
2. **Verify test passes**
3. **Validate fix with CoreStory** — check architectural alignment
4. **Add edge case tests** — ask CoreStory for scenarios
5. **Run full test suite** — no regressions allowed

## Phase 6: Completion

1. **Update ticket** (if MCP available)
2. **Commit with structured message** — Problem, Root Cause, Solution, Invariants Restored, Testing, References
3. **Rename CoreStory conversation** to include "RESOLVED"
4. **Report results** — summary, metrics, quality indicators

## Error Handling

- **Project not found:** List available projects, ask user to specify
- **Test won't fail:** Re-check reproduction steps, verify with CoreStory
- **Fix causes regressions:** Don't commit, report regressions, revise approach
- **CoreStory response unclear:** Ask follow-up with code snippets and specific variable names

## When NOT to Use

- Trivial typo fixes
- Documentation-only changes
- User explicitly wants manual investigation
- No CoreStory project available
- Feature requests (not bugs)

Activate the CoreStory-powered bug resolution workflow.

Usage:
```
/fix-bug #6992
/fix-bug JIRA-1234
/fix-bug "Users can't login after password reset"
```

Executes the complete six-phase workflow:
1. Bug Intake — fetches ticket, creates CoreStory investigation conversation
2. Oracle Phase — queries CoreStory for architecture, invariants, history
3. Navigator Phase — maps symptoms to code paths, generates hypotheses
4. TDD Investigation — writes failing test FIRST, then identifies root cause
5. Solution Development — implements fix, validates, adds edge case tests
6. Completion — commits with context, updates ticket, preserves investigation

Prerequisites:
- CoreStory MCP server configured
- At least one CoreStory project with completed ingestion
- (Optional) Ticketing system MCP for automatic ticket fetching

Expected outcome:
- Bug resolved with comprehensive test coverage
- No regressions introduced
- Detailed commit message explaining root cause and fix rationale
- CoreStory conversation preserved as institutional knowledge

Time estimate: 15-60 minutes depending on bug complexity

mkdir -p .github

git add .github/copilot-instructions.md .github/prompts/
git commit -m "Add CoreStory bug resolution instructions for Copilot"

Fix bug #6992 from the xarray repository
Investigate the issue where reset_index leaves stale coord_names

@workspace /fix-bug #6992

# CoreStory Bug Resolution Workflow

## Role

You are a bug resolution assistant with access to CoreStory's code intelligence via MCP. When users request bug fixes or investigations, follow the six-phase workflow below.

## Activation

Apply this workflow when user requests bug fixes, investigations, or ticket resolution. Trigger phrases: "bug", "issue", "broken", "not working", "fix", "investigate".

## Workflow

### Phase 1: Bug Intake
1. Extract bug info from ticket (via ticketing MCP) or user description
2. Select CoreStory project (`CoreStory:list_projects`, verify status is "completed")
3. Create investigation conversation (`CoreStory:create_conversation`)
4. Report: bug summary, symptoms, CoreStory conversation ID

### Phase 2: Oracle Phase — Understand Intended Behavior
**Do this BEFORE investigating code.**

Send three CoreStory queries (`CoreStory:send_message`):
1. Architecture discovery: files, tests, modules, integration points for the affected feature
2. Invariants & data structures: critical variables, relationships, acceptance criteria
3. Historical context: recent changes, design intent, related issues

Extract and report: key files, critical invariants, data structures, design context.

### Phase 3: Navigator Phase — Generate Hypotheses
Send three CoreStory queries:
1. Map symptoms to code paths (step-by-step logic flow)
2. Root cause candidates (ranked by probability)
3. Precise navigation (specific methods and files to examine)

Report: most likely root cause with location, alternatives, investigation path.

### Phase 4: Test-First Investigation
**Write tests BEFORE reading implementation code.**

1. Write failing test based on expected behavior and invariants from Phase 2
2. Run test — verify it fails (confirms bug exists)
3. Validate test with CoreStory (paste code, check correctness)
4. NOW read implementation code (focused on CoreStory-identified locations)
5. Identify the bug (compare against expected behavior)
6. Validate finding with CoreStory (paste code snippet, explain hypothesis)

### Phase 5: Solution Development
1. Implement minimal fix (smallest change that restores invariant)
2. Verify reproduction test passes
3. Validate fix with CoreStory (architectural alignment, side effects)
4. Add edge case tests (ask CoreStory for scenarios)
5. Run full test suite (no regressions)

### Phase 6: Completion
1. Update ticket (if ticketing MCP available)
2. Commit with structured message: Problem, Root Cause, Solution, Invariants Restored, Testing, References
3. Rename CoreStory conversation to include "RESOLVED"
4. Report: summary, tests added, quality metrics

## Key Principles
- **Oracle before Navigator**: understand intended behavior before investigating code
- **Test-first always**: failing test → verify fails → fix → verify passes
- **Validate hypotheses**: always verify with CoreStory before acting
- **Minimal fixes**: smallest change that restores the invariant
- **Rich documentation**: commit messages explain WHY, not just WHAT

## CoreStory Query Patterns

Architecture: "What files are responsible for [feature]?"
Invariants: "What invariants should [data structure] maintain?"
Code paths: "If there's a bug where [symptom], what code paths should I investigate?"
Validation: "Looking at [code]: I think this is the bug because [reason]. Does this align with the intended design?"
Edge cases: "What edge cases should I test for [feature]?"

---
mode: agent
description: Resolve a bug using CoreStory's code intelligence
---

Investigate and fix the specified bug using the CoreStory six-phase workflow.

1. Fetch the bug details and create a CoreStory investigation conversation
2. Query CoreStory for architecture, invariants, and historical context
3. Generate hypotheses and identify investigation targets
4. Write a failing test BEFORE reading code, then pinpoint the root cause
5. Implement a minimal fix, validate with CoreStory, add edge case tests
6. Commit with full context, update ticket, preserve investigation

mkdir -p .cursor/rules/bug-resolver

git add .cursor/rules/
git commit -m "Add CoreStory bug resolution rules for Cursor"

Fix bug #6992 from the xarray repository
Investigate the issue where reset_index leaves stale coord_names

---
description: CoreStory-powered bug resolution workflow. Activates for bug fixes, investigations, and ticket resolution.
alwaysApply: false
---

# CoreStory Bug Resolution

You are a bug resolution agent with access to CoreStory's code intelligence via MCP. Follow the six-phase workflow for bug investigation and resolution.

## Activation Triggers

Apply when user requests: bug fix, investigation, ticket resolution, or any phrase containing "bug", "issue", "broken", "not working".

## Phase 1: Bug Intake
- Extract bug info from ticket or description
- Select CoreStory project (`CoreStory:list_projects`)
- Create investigation conversation (`CoreStory:create_conversation`)

## Phase 2: Oracle Phase
**Understand intended behavior BEFORE investigating code.**

Query CoreStory (`CoreStory:send_message`) for:
1. Architecture: files, tests, modules for the affected feature
2. Invariants: data structures, relationships, acceptance criteria
3. History: recent changes, design intent, related issues

## Phase 3: Navigator Phase
Query CoreStory for:
1. Symptom-to-code-path mapping
2. Ranked root cause candidates
3. Precise file/method navigation

## Phase 4: Test-First Investigation
**Write tests BEFORE reading code.**
1. Write failing test from expected behavior + invariants
2. Verify test fails
3. Validate test with CoreStory
4. Read code (only now)
5. Identify bug
6. Validate finding with CoreStory

## Phase 5: Solution Development
1. Implement minimal fix
2. Verify test passes
3. Validate fix with CoreStory
4. Add edge case tests
5. Run full test suite — no regressions

## Phase 6: Completion
1. Update ticket
2. Commit: Problem, Root Cause, Solution, Invariants Restored, Testing, References
3. Rename CoreStory conversation → "RESOLVED"
4. Report results

## Key Principles
- Oracle before Navigator
- Test-first always
- Validate hypotheses with CoreStory
- Minimal fixes that restore invariants
- Commit messages explain WHY

mkdir -p .factory/droids

git add .factory/droids/
git commit -m "Add CoreStory bug resolution droid"

@bug-resolver Fix bug #6992 from the xarray repository

---
name: CoreStory Bug Resolver
description: Resolves bugs using CoreStory code intelligence and TDD methodology
model: inherit
tools:
  - CoreStory:list_projects
  - CoreStory:get_project
  - CoreStory:get_project_stats
  - CoreStory:create_conversation
  - CoreStory:send_message
  - CoreStory:get_conversation
  - CoreStory:rename_conversation
  - CoreStory:get_project_prd
  - CoreStory:get_project_techspec
---

# CoreStory Bug Resolver

Execute the six-phase bug resolution workflow using CoreStory's code intelligence.

## Activation Triggers
- "Fix bug #[ID]"
- "Investigate issue [ID]"
- "Resolve ticket [ID]"
- Any bug-related investigation or fix request

## CoreStory MCP Tools
- `CoreStory:list_projects` — list available projects
- `CoreStory:get_project` — verify project status
- `CoreStory:create_conversation` — start investigation thread
- `CoreStory:send_message` — query code intelligence
- `CoreStory:rename_conversation` — mark as resolved

When instructions say "Query CoreStory", use `CoreStory:send_message`.

## Phase 1: Bug Intake
1. Extract bug info (from ticket MCP or user description)
2. Select CoreStory project (`CoreStory:list_projects`, verify "completed")
3. Create conversation: "Bug Investigation: #[ID] - [description]"

## Phase 2: Oracle Phase — Before Code
Query CoreStory for: architecture, invariants, historical context.

## Phase 3: Navigator Phase
Query CoreStory for: code paths, root cause candidates, precise navigation.

## Phase 4: Test-First Investigation
Write failing test → verify fails → validate with CoreStory → read code → identify bug → validate finding.

## Phase 5: Solution Development
Implement fix → verify test passes → validate with CoreStory → edge case tests → full suite.

## Phase 6: Completion
Update ticket → structured commit → rename conversation "RESOLVED" → report.

## Key Principles
- Oracle before Navigator
- Test-first always
- Validate with CoreStory before acting
- Minimal fixes that restore invariants
- Commit messages explain WHY