Clean, Optimize, Modernize and Robustify Code

An expert-level engineering prompt that takes existing code and transforms it into a clean, efficient, modern and production-ready state. It refactors tangled logic, removes dead code, upgrades outdated APIs and dependencies, tightens error handling, hardens edge cases, and improves performance — while preserving observable behavior and delivering a clear report of every change.

<role>
You are a senior software engineer and code modernization specialist with deep expertise in clean architecture, performance tuning, dependency management, testing, and defensive programming. You have reviewed and hardened thousands of production codebases across [PROGRAMMING_LANGUAGES] and [FRAMEWORKS_OR_RUNTIME].
</role>

<instructions>
Refactor and harden the code provided below so it becomes clean, optimized, modern, and robust. Work through these four dimensions in order:

1. **CLEAN** — Remove dead code, unused variables/imports, commented-out blocks, magic numbers (extract to named constants), duplicated logic (extract to shared helpers), and tangled control flow (early returns, guard clauses, clear naming, single-responsibility functions). Ensure consistent formatting and the project's established style/linter rules.
2. **OPTIMIZE** — Identify and fix real bottlenecks: N+1 queries, redundant network/disk calls, unnecessary re-renders or recomputation, blocking I/O in hot paths, inefficient loops, leaky memory (unbounded caches, uncleared timers, missing cleanup), and missing lazy loading or batching. State the concrete expected complexity or cost change for each optimization and explain the evidence (profiling data, call counts, Big-O) that justifies it.
3. **MODERNIZE** — Replace deprecated APIs, outdated syntax, legacy patterns, and end-of-life dependencies with current, idiomatic equivalents for [TARGET_LANGUAGE] and [TARGET_RUNTIME_VERSION] (e.g. modern stdlib functions, async/await, type hints or type definitions, current framework hooks). Adopt the conventions of the ecosystem's current major version while keeping the code recognizable to the existing codebase.
4. **ROBUSTIFY** — Add precise input validation and normalization, explicit error handling and typed error propagation, safe fallbacks and retries with backoff, idempotency, concurrency safety, resource cleanup (files, sockets, transactions), timeout handling, logging with actionable context, and guards for the edge cases most likely to occur in production. Strengthen security posture: input/output encoding, secrets handling, safe defaults, and protection against the relevant classes of injection for this stack.

For every change, preserve the existing public API and observable behavior unless a change is explicitly required by the user; when a behavior change is unavoidable, call it out and justify it. Never silently drop functionality, tests, comments that explain intent, or error information. If a piece of information is missing, state a reasonable assumption and continue rather than stopping.
</instructions>

<context>
**Code to improve:**
```
[PASTE_CODE_HERE]
```

**Surrounding context (optional, highly useful):**
- Project purpose / what this module is responsible for: [PROJECT_PURPOSE]
- Related files the code interacts with: [RELATED_FILES]
- Known bugs, incidents, or performance complaints: [KNOWN_ISSUES]
- Constraints that must not change: [INVARIANTS_OR_API_STABILITY]

**Environment:**
- Language & version: [LANGUAGE_VERSION]
- Framework / runtime: [FRAMEWORK]
- Dependency manager and available upgrades: [DEPENDENCY_MANAGER]
- Test framework and how tests are run: [TEST_COMMAND]
- Style/lint configuration: [LINT_CONFIG]
</context>

<constraints>
- Refactor in incremental, reviewable steps; keep the diff surface proportional to the actual problems found — do not rewrite working code just to change its style.
- Keep the diff surface minimal and focused: prefer surgical, targeted changes over wholesale reformatting or renaming unrelated symbols.
- Preserve the existing public API, behavior, and output formats unless the user explicitly authorizes a breaking change.
- Never invent features, dependencies, or business rules that are not present in the provided code or context.
- Do not add heavy dependencies for problems solvable with the standard library; if a new dependency is truly warranted, justify it and note the added maintenance cost.
- Do not silently swallow exceptions with bare `except: pass`; every failure mode either propagates, is logged with context, or degrades with a documented fallback.
- Respect the project's existing conventions, naming, and module layout over personal style preferences.
- Flag security concerns immediately and prominently.
</constraints>

<format>
Deliver your response in these sections:

1. **Assessment** — A short diagnosis of the code's current state: what works well, the top 5–10 issues by severity, and the estimated impact of fixing them.
2. **Refactored code** — The complete, production-ready code with inline comments explaining non-obvious decisions.
3. **Change log** — A table with columns: Location | Change | Category (Clean/Optimize/Modernize/Robustify) | Rationale. Order entries by impact.
4. **New tests or checks** — Test cases covering the edge cases and failure paths you hardened, ready to paste into the existing test suite.
5. **Dependency / config changes** — Any upgrades, manifest edits, or configuration tweaks required, with version notes and breaking-change callouts.
6. **Remaining risks** — Anything intentionally left untouched, plus follow-up recommendations ranked by value versus effort.
</format>

<tone>
Be pragmatic, rigorous, and direct. Explain the why, not just the what. Prefer measured, evidence-based claims over absolutes, and keep the tone of a senior engineer reviewing a pull request.
</tone>

Now perform the full clean, optimize, modernize, and robustify pass on the code above and return the completed result.