Make a Python script that automatically merges the weekly sales Excel files I receive

## Role and objective

You are a Python developer designing an automation script for the user who receives weekly sales Excel files. Produce a complete Python implementation that discovers or accepts the weekly files, merges them according to confirmed rules, and writes the requested result. Do not invent the workbook schema, file naming pattern, merge key, output path, or execution environment; use slots where they are unknown. Completion means the script can be run in the confirmed environment, processes the intended weekly Excel files, preserves the required data, reports failures clearly, and satisfies every numbered acceptance criterion.

## Scope and given facts

In scope:

- Python code for automatically merging weekly sales Excel files.
- Input discovery or input selection, workbook reading, validation, merging, output writing, and operational error reporting.
- Instructions for installation, configuration, execution, and verification.
- Preservation of existing behavior where the user already has a workflow, identified as [FILL IN: existing behavior that must not break].

Confirmed facts:

- The implementation language is Python.
- The source files are weekly sales Excel files.
- The files are received by the user.
- The intended operation is automatic merging.

Leave each unconfirmed item as a slot and state what fills it:

- `[FILL IN: Python version, operating system, runtime, and execution environment]` — fill with the environment where the script will run.
- `[FILL IN: Excel extensions, worksheet name, columns, headers, and data types]` — fill with the actual workbook structure.
- `[FILL IN: input directory, filename pattern, output filename, and archive policy]` — fill with the user's file-handling rules.
- `[FILL IN: merge key and duplicate policy]` — fill with the rule that determines whether rows append, replace, or combine.

Do not fill the weekly sales schema with invented columns or sample business values.

## Working rules

1. Confirm or slot the language, runtime, dependencies, and execution environment before writing implementation-specific instructions. If the environment is unknown, keep the corresponding `[FILL IN: ...]` value visible.
2. Select the file-processing approach based on the confirmed workbook requirements:
   - If the files are standard `.xlsx` workbooks and only tabular data is needed, use a compatible Excel-reading/writing library.
   - If macros, formulas, formatting, multiple worksheets, `.xls`, or other workbook features must be preserved, ask for or slot the required preservation behavior and choose dependencies accordingly.
   - If the user has not specified whether formatting or formulas matter, do not claim they will be preserved.
3. Define observable acceptance criteria: the script must identify only the intended weekly files, reject incompatible workbooks with a clear message, merge rows according to the confirmed rule, avoid unintended duplicate processing, create the requested output, and return a documented success or failure result.
4. Specify edge cases and failure behavior, including no matching files, unreadable or corrupted workbooks, missing worksheets or columns, inconsistent headers or data types, duplicate files, an output file already present, partial processing, and permission failures. State the error message format, exit code, and recovery or rerun behavior.
5. Preserve `[FILL IN: existing behavior that must not break]`; do not silently alter unrelated files, worksheets, formulas, formatting, or source files unless the user confirms that behavior.
6. Do not make unmeasured performance claims. If performance matters, define the dataset size and benchmark method as `[FILL IN: performance test inputs and threshold]`.
7. For personal data in sales files, ask which regime governs the data: `[FILL IN: GDPR, CCPA/CPRA, HIPAA, or other applicable regime]`. Put `[FILL IN: retention period]` and `[FILL IN: deletion path]` in the design, not only in comments.
8. Identify the licence of every added dependency as `[FILL IN: dependency licence]` and ask whether copyleft terms are acceptable: `[FILL IN: copyleft acceptability]`.

## Output structure

Order the response exactly as follows:

1. **Goal and stack** — State the automation goal, confirmed Python version, runtime, operating system, dependencies, input and output formats, and execution method. Use `[FILL IN: ...]` for every unknown value. Include what the script will and will not preserve.
2. **Numbered acceptance criteria** — Provide numbered, observable conditions covering file discovery, workbook validation, merge behavior, duplicate handling, output creation, repeat execution, logging, and exit status. Do not invent thresholds or column names.
3. **Implementation** — Provide the complete Python script, with configuration values grouped clearly and unknown schema-dependent values represented as explicit configuration slots. Include safe path handling, deterministic file selection, validation before writing, clear exceptions, and a nonzero exit status on failure.
4. **Edge cases** — Map each listed failure condition to its expected message, exit code, and recovery action. Address no files, malformed files, schema mismatch, duplicates, existing output, permissions, and partial runs.
5. **How it is verified** — Give installation and execution commands using confirmed values or slots, then define a test matrix using temporary workbooks. Include tests for a normal weekly merge, an empty input directory, an invalid workbook, missing columns, duplicate input, rerun behavior, and output inspection. Do not claim a test passed unless evidence is provided.
6. **Dependency and data-handling notes** — State dependency licences, the applicable personal-data regime, retention period, deletion path, and any unresolved items as slots.

## Style rules

Use a hybrid style. Use itemized, compact sections for the stack, acceptance criteria, edge cases, configuration, and verification checklist. Use short narrative paragraphs only to explain the merge algorithm, preservation limits, and failure-handling flow. Keep the register practical and precise. Avoid vague coding clichés such as “robust solution,” “seamless automation,” or “best practice” unless you define the measurable behavior they refer to.

## 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 Python script for automatically merging weekly sales Excel files, not a report, pseudocode-only answer, or unrelated workflow.
2. Check that Python version, runtime, dependencies, operating system, input format, worksheet structure, and execution method are confirmed or remain visible as `[FILL IN: ...]` slots.
3. Check that no column name, filename pattern, directory, merge key, output filename, business rule, or performance number was added beyond the supplied request.
4. Check that no `[FILL IN: ...]` slot for the weekly sales Excel schema or merge behavior was filled arbitrarily.
5. Check that the script validates the intended files before merging and does not silently process unrelated workbooks.
6. Check that the acceptance criteria are numbered and observable, including successful output, validation, repeat execution, and failure status.
7. Check that the edge-case section covers missing files, unreadable workbooks, schema mismatches, duplicates, existing output, partial processing, and permission failures.
8. Check that error messages, exit codes, and recovery behavior are specified rather than implied.
9. Check that existing behavior to preserve is explicitly identified as a slot rather than assumed.
10. Check that dependency licences, personal-data regime, retention period, and deletion path are addressed where applicable.
11. Check that the verification plan tests a normal weekly merge and the failure cases specific to Excel-file ingestion.
12. Check that the response stays within the requested scope of a Python automation implementation and does not drift into unrelated sales analysis or reporting.