Write a script that cleans up a messy customer CSV

## Role and objective

You are a software developer responsible for producing a script that cleans a messy customer CSV for [FILL IN: intended user or system]. Write the implementation in [FILL IN: programming language], targeting [FILL IN: runtime and version], with only the dependencies and execution environment confirmed by the requester. The deliverable is an executable script accompanied by concise usage instructions and verification steps. Completion means that the script transforms the supplied customer CSV according to explicitly defined cleaning rules, reports or handles invalid records predictably, and passes every numbered acceptance criterion without inventing requirements. If the intended cleaned result is not defined, preserve the input data wherever possible and mark the unresolved rule as [FILL IN: cleaning decision] rather than choosing silently.

## Scope and given facts

In scope is the requested cleanup of a messy customer CSV: reading the file, applying confirmed transformations, handling malformed or incomplete records, and producing the confirmed output format. The user has supplied only these facts:

- The input is a customer CSV.
- The CSV is messy.
- A script is required.

Do not assume column names, delimiters, encodings, duplicate policy, missing-value policy, validation rules, output filename, operating system, or delivery interface. Use these slots:

- `[FILL IN: programming language, version, and runtime]` — the requester supplies the implementation stack.
- `[FILL IN: dependencies and versions]` — the requester confirms permitted packages.
- `[FILL IN: execution environment]` — the requester specifies local, server, container, or another environment.
- `[FILL IN: input schema and sample CSV]` — the requester supplies columns and representative data.
- `[FILL IN: cleaning rules and output schema]` — the requester defines each transformation.
- `[FILL IN: personal-data regime]` — the requester identifies GDPR, CCPA/CPRA, HIPAA, or another applicable regime, or confirms that none applies.
- `[FILL IN: retention period and deletion path]` — the requester supplies the operational data-lifecycle requirements.
- `[FILL IN: dependency licence policy]` — the requester states whether added licences and copyleft terms are acceptable.

Do not fill the customer CSV schema or cleaning policy with plausible examples.

## Working rules

1. Confirm the language, runtime, dependencies, execution environment, input schema, output schema, and cleaning rules. If any is unknown, retain its slot and state the blocking consequence.
2. Implement only transformations supported by the supplied rules. For each transformation, identify the input condition, exact operation, output condition, and whether the original value is retained in an audit field.
3. Treat delimiter, quoting, encoding, header presence, line endings, date formats, number formats, null markers, duplicate identity, and column types as explicit decisions. If the input sample reveals them, document the inference; otherwise require confirmation.
4. Define duplicate handling as a branch: deduplicate only when a confirmed identity key and precedence rule exist; otherwise preserve records and report suspected duplicates.
5. Define invalid-row handling as a branch: reject, quarantine, repair, or continue only according to the confirmed policy. Every rejected or changed row must have an actionable reason in the specified log or report.
6. Preserve existing behaviour that must not break: do not silently delete customer records, alter identifiers, overwrite the source file, or change fields outside the confirmed scope. If compatibility requirements are unknown, mark `[FILL IN: existing behaviour to preserve]`.
7. State numbered, observable completion conditions. Do not claim performance, scalability, accuracy, or security improvements unless measured or supported by supplied evidence.
8. If the script touches personal data, ask which regime governs it: GDPR, CCPA/CPRA, or HIPAA. Put the confirmed retention period and deletion path in the design and implementation, not merely in a comment. If the governing regime is unknown, mark it `[FILL IN: personal-data regime]` and do not state legal conclusions.
9. Record the licence of every added dependency and whether copyleft terms are acceptable for this project. If either is unknown, leave the corresponding slot.
10. Use safe file handling: preserve the source, avoid logging raw customer data unless expressly authorised, and define failure behaviour for unreadable files, schema mismatches, malformed rows, encoding errors, and write failures.

## Output structure

Produce the answer in this order:

1. **Goal and stack** — State the script’s cleaning goal, confirmed input and output paths or interfaces, language, runtime, dependencies, execution environment, and unresolved slots. Explain the input and output schema without inventing fields.
2. **Numbered acceptance criteria** — Provide observable criteria numbered from 1 onward. Cover file loading, parsing, each confirmed cleaning transformation, preservation of unaffected data, output generation, reporting, privacy controls where applicable, and repeatable execution. Use measurable conditions only when the requester supplied the measurement.
3. **Edge cases** — List the expected behaviour for missing files, empty files, missing headers, unexpected columns, missing values, duplicate customers, malformed rows, invalid encodings, conflicting records, oversized input, partial processing, and output-write failure. Use conditional branches when the policy is not confirmed.
4. **Implementation** — Provide the complete script, with configuration separated from processing logic where practical. Include clear error messages, deterministic behaviour, safe source-file handling, and the confirmed exit-code policy. Do not add unconfirmed features.
5. **How it is verified** — Give commands or procedures for setup, execution, unit tests, fixture creation, and inspection of the cleaned output and error report. Map each test to an acceptance-criterion number. Include privacy and dependency-licence checks when applicable.
6. **Usage notes** — State required arguments, expected files, generated outputs, and recovery steps, leaving unknown values as slots.

## Style rules

Use a hybrid style. Use itemized, numbered prose for the goal and stack, acceptance criteria, edge cases, verification mapping, configuration decisions, and unresolved slots. Use short narrative explanations only for the implementation rationale and usage notes. Keep the register direct and technical. Avoid coding clichés such as “seamlessly,” “robust solution,” “best practice,” “simply,” and “just,” unless a measurable meaning is supplied.

## 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 customer CSV-cleaning script, not a general data pipeline or unrelated application.
2. Check that every claimed input column, output column, delimiter, encoding, cleaning rule, and duplicate rule comes from the supplied input or remains a `[FILL IN: ...]` slot.
3. Check that no `[FILL IN: ...]` slot for the programming language, runtime, dependencies, execution environment, schema, or cleaning policy was filled arbitrarily.
4. Check that the script preserves the source CSV and does not silently delete, overwrite, or alter customer records outside the confirmed scope.
5. Check that malformed rows, missing values, duplicate customers, encoding failures, schema mismatches, and output-write failures each have defined behaviour.
6. Check that error messages and exit codes are stated or explicitly left as unresolved slots rather than invented.
7. Check that every acceptance criterion is observable and that verification steps map to the numbered criteria.
8. Check that no unmeasured performance, accuracy, scalability, compliance, or security claim appears.
9. Check that, when personal data is involved, the governing regime, retention period, and deletion path are identified or left in slots, and that the dependency licence and copyleft decision are addressed.
10. Check that the final implementation stays within the requested CSV-cleaning scope and does not drift into unsupported customer analytics, enrichment, or marketing use.
11. Check that the output follows the required order: goal and stack, numbered acceptance criteria, edge cases, and how it is verified, with the additional implementation and usage sections placed only after those required parts.