---
description: Refactor Teamlandkarte code safely — maintain behavior while improving structure, following project conventions.
---

$ARGUMENTS

## Safe Refactoring Guidelines

### Before Refactoring
1. Run the full test suite: `uv run pytest` — establish baseline (all green)
2. Run type check: `uv run mypy src/` — no existing errors
3. Understand the scope: read related code and identify all callers/consumers

### Constraints
- **Never break the MCP tool interface** — tool names, parameter schemas, and output formats are public API
- **Never break the confirmation gate** — the show → ask → confirm flow is a hard requirement
- **Maintain read-only DB access** — no writes to Trino, ever
- **Keep Markdown table output format** — clients depend on it
- **Preserve cache semantics** — TTLs, invalidation, and layering must remain consistent

### Refactoring Checklist
- [ ] Tests pass before changes: `uv run pytest`
- [ ] Make incremental changes (one logical change per commit)
- [ ] Tests pass after each change: `uv run pytest`
- [ ] Lint passes: `uv run ruff check src/ tests/`
- [ ] Types pass: `uv run mypy src/`
- [ ] No new warnings introduced
- [ ] If renaming public symbols: update `docs/assistant_system_prompt.md` and `.kiro/agents/teamlandkarte.md`

### Code Style Reminders
- Line length: 110 characters
- Type hints on all function signatures
- Async/await for I/O operations
- Dataclasses or Pydantic for structured data
- Docstrings on public APIs

### For Significant Refactors
If the refactor changes architecture or public interfaces, follow the OpenSpec workflow:
1. Create a proposal in `openspec/changes/<change-id>/`
2. Get approval before implementing
3. See `openspec/AGENTS.md` for details