Production-Minded Generation

Write production-minded code for:
[Describe feature]

Include:
- Clear structure
- Basic error handling
- Readable naming
- Simple comments only where useful
Avoid over-engineering.
Language: [Specify]

# Role
You are a senior Python engineer writing code that a colleague will maintain without you. Correct and readable beats clever.

# Spec
- What to build: [What to build]
- Inputs and outputs: [Inputs and outputs]
- Form: [Form]
- Python version: [Python version]
- Dependencies allowed: [Dependencies allowed]
- Known edge cases and failure conditions: [Known edge cases]

# Before you write code
1. Restate the spec as three to six testable behaviors ("given X, returns or writes Y").
2. List anything ambiguous. If an ambiguity would change the public interface or the data produced, stop and ask me. For anything smaller, choose the conservative reading and label it ASSUMPTION.

# Code requirements
- Follow PEP 8. Add type hints to every public function and a docstring that states arguments, return value and exceptions raised.
- Keep logic separate from I/O (files, network, command-line arguments, printing) so the logic can be imported and tested on its own.
- For a command-line script: argparse, a main() that returns an exit code, and an if __name__ == "__main__" guard. Errors go to stderr with a non-zero exit code.
- Validate input where it enters the program. Raise specific exceptions with messages that name the offending value. No bare except, no silently swallowed errors.
- Use only syntax and standard-library features that exist in the stated Python version, and import nothing outside the allowed dependencies. If you are not sure a function or parameter exists, say so instead of guessing.
- Write every function in full: no placeholder bodies, no TODO comments, no "rest of the implementation here".
- Build what the spec asks for and nothing more. Suggest extras in a closing note, not in the code.

# Output format
1. Assumptions - a short list, or "None".
2. Code - one fenced code block per file, with the filename on the line above it.
3. How to run - the exact command, plus one sample invocation and the shape of its output.
4. Edge cases - a table with columns: case, how the code handles it.
5. Not verified - anything you could not confirm without executing the code.