Write a script that cleans up a messy customer CSV

## Role and objective

You are a software engineer responsible for producing a reliable script that cleans a messy customer CSV. Write the implementation for the person who will run, review, and maintain it. Preserve all customer information unless a cleanup rule explicitly authorizes normalization, correction, removal, or quarantine.

Your output must contain the goal and stack, numbered acceptance criteria, edge cases, and verification instructions, followed by the complete script or the smallest complete implementation possible from the supplied facts. Completion means that the script processes the stated input format, produces the stated output format, handles specified invalid records predictably, and passes every numbered acceptance criterion without inventing missing requirements.

## Scope and given facts

In scope:

- A script for cleaning a messy customer CSV.
- Input parsing, validation, normalization, reporting, and output writing required by the confirmed cleanup rules.
- Safe handling of malformed rows and recoverable data-quality problems.
- Instructions for running and verifying the script.

The only confirmed facts are that the source is a customer CSV and that it is messy. Treat these as unconfirmed until supplied:

- Programming language and version: `[FILL IN: language and version]`
- Runtime and execution environment: `[FILL IN: runtime, operating system, and invocation method]`
- Dependencies and permitted installation method: `[FILL IN: dependencies and installation constraints]`
- Input columns, delimiters, encoding, quoting, and representative rows: `[FILL IN: input CSV schema and sample]`
- Required output columns and destination: `[FILL IN: output schema and path]`
- Cleanup transformations and deduplication rule: `[FILL IN: exact cleanup rules]`
- Existing behaviour that must remain unchanged: `[FILL IN: compatibility requirements]`

Use each slot only after the user or a verifiable project source supplies its value. Do not choose a plausible language, customer field, duplicate rule, output path, or data transformation merely because it is common.

## Working rules

1. State the language, runtime, dependencies, and execution environment as confirmed values or retain them as `[FILL IN: ...]` slots. Do not write executable code that silently depends on an unstated package or runtime feature.
2. Derive transformations only from the confirmed input schema and cleanup rules. For each transformation, identify the input field, accepted formats, normalized result, and treatment of values that cannot be safely transformed.
3. Preserve data by default. If a value is ambiguous, branch as follows:
   - If the confirmed rule defines a safe normalization, apply it and document the result.
   - If the value violates a confirmed validation rule but can be isolated, quarantine or report it according to the confirmed policy.
   - If no policy exists, do not delete, merge, or overwrite it; raise a clearly labelled missing requirement.
4. Define duplicate handling explicitly. If a confirmed key exists, use only that key and the stated tie-break rule. If no key or tie-break rule exists, leave deduplication as `[FILL IN: duplicate-identification and retention rule]` rather than guessing.
5. Specify deterministic output ordering, encoding, delimiter, quoting, header behaviour, and whether the input is overwritten. If any is unknown, preserve the input where safely possible and mark the requirement as a slot.
6. Include numbered, observable completion conditions, such as required columns, row counts, normalization outcomes, rejected-row reporting, deterministic reruns, and exit status. Use only conditions grounded in supplied requirements.
7. Define failure behaviour: actionable error messages, non-zero exit codes for fatal failures, a separate policy for recoverable bad rows, and whether partial output is removed or retained. Do not claim recovery that the implementation does not perform.
8. Identify existing behaviour that must not break, using `[FILL IN: existing behaviour]` when absent.
9. If the CSV contains personal data, ask which regime governs it—GDPR, CCPA/CPRA, or HIPAA—and leave the applicable regime as `[FILL IN: governing privacy regime]` until confirmed. Put the retention period and deletion path in the design, not merely in a comment.
10. For every added dependency, state its licence and whether copyleft terms are acceptable for this project: `[FILL IN: dependency licence policy]`.
11. Do not make unmeasured performance claims. If performance matters, define the dataset size, hardware, runtime measurement method, and threshold as slots unless supplied.

## Output structure

Produce the response in this order:

1. **Goal and stack** — State what the cleanup script does, its input and output boundaries, the confirmed language, runtime, dependencies, execution environment, and every unresolved slot. Do not fill missing values.
2. **Numbered acceptance criteria** — Provide observable, testable criteria covering parsing, schema handling, each confirmed cleanup transformation, preservation of valid customer data, duplicate handling, output integrity, reporting, exit codes, and compatibility. Assign no invented thresholds.
3. **Edge cases** — List the behaviour for missing files, unreadable files, empty input, headers-only input, malformed CSV syntax, inconsistent column counts, blank values, invalid encodings, duplicate customers, ambiguous values, oversized fields, and write failures. Include only cases relevant to the confirmed schema and identify unresolved policies.
4. **Implementation** — Give the complete script in a clearly labelled code block using the confirmed language. If required information is missing, provide a runnable structure only where safe and mark implementation-dependent decisions with `[FILL IN: ...]`; do not fabricate customer columns or cleanup logic.
5. **How it is verified** — Describe fixtures and commands/tests that prove every acceptance criterion, including clean input, each confirmed messy-input case, rejected or quarantined rows, deterministic reruns, output comparison, and fatal-error exit behaviour. Leave commands dependent on unknown tooling as slots.

Keep the implementation and verification concise enough to be usable, but do not omit a required behaviour. Do not present placeholder values as completed data.

## Style rules

Use a hybrid style. Use itemized lists and numbered criteria for the stack, requirements, edge cases, failure policies, and verification checks. Use concise narrative paragraphs only to explain the script’s purpose, data-preservation decisions, and interactions between parsing, cleanup, reporting, and output. Keep the register technical, direct, and implementation-oriented. Avoid generic coding clichés such as “seamlessly,” “robust solution,” “best practice,” and “simply.”

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a CSV-cleaning script rather than a report, unrelated data pipeline, or general customer-management tool.
2. Confirm that every customer field, cleanup transformation, duplicate rule, output path, language, runtime, dependency, and execution detail comes from the input or remains an explicit `[FILL IN: ...]` slot.
3. Confirm that no arbitrary slot was filled, especially the input schema, output schema, duplicate-identification rule, and retention policy.
4. Confirm that the implementation matches the stated input and output CSV formats and does not silently invent columns.
5. Confirm that each numbered acceptance criterion is observable and has a corresponding verification step.
6. Confirm that malformed rows, invalid encodings, empty files, missing files, write failures, and ambiguous values have defined behaviour or clearly marked unresolved policies.
7. Confirm that valid customer data is preserved unless a confirmed cleanup rule authorizes a change.
8. Confirm that fatal failures produce documented error messages and non-zero exit codes, and that partial-output behaviour is stated.
9. Confirm that existing behaviour is identified rather than assumed, with `[FILL IN: existing behaviour]` retained where necessary.
10. Confirm that privacy-regime, retention, deletion-path, and dependency-licence requirements are addressed without asserting an unconfirmed regime.
11. Confirm that no unmeasured performance claim appears.
12. Confirm that the response stays within the requested CSV-cleaning scope and contains the required sections: goal and stack, acceptance criteria, edge cases, and verification.