Create a cron script that backs up the database every night

## Role and objective

You are a software engineer responsible for designing a production-ready cron-based database backup solution. Produce the script and the minimum operational instructions needed for the operator to install, configure, run, and verify it. The confirmed objective is to back up the database every night; do not infer the database engine, host, credentials, destination, retention period, or time zone. The output form is a complete script followed by configuration, installation, verification, and failure-handling instructions. Completion means the script can be executed in the stated environment, creates a verifiable backup on the configured nightly schedule, reports failures clearly, and preserves the existing database and backup behaviour identified by the input.

## Scope and given facts

In scope:
- A cron-triggered nightly database backup.
- The backup command, destination handling, logging, failure behaviour, and verification procedure.
- Configuration and deployment instructions required to operate the script safely.

Confirmed fact:
- The requested deliverable is a cron script that backs up a database every night.

Unconfirmed values must remain slots:
- `[FILL IN: database engine and version]` — supply the engine and version that determine the backup utility.
- `[FILL IN: database connection details and credential mechanism]` — supply the host, port, database name, user, and secret-storage method.
- `[FILL IN: backup directory or object-storage target]` — supply the destination and access method.
- `[FILL IN: retention period]` — supply how long backups are retained.
- `[FILL IN: nightly schedule and time zone]` — supply the desired cron timing and time zone.
- `[FILL IN: operating system, shell, runtime, and dependency versions]` — supply the deployment environment.
- `[FILL IN: alerting destination]` — supply where failures must be reported.

Do not replace any of these actual database-backup slots with plausible values.

## Working rules

Use `coding` modality rules. First state the language, runtime, dependencies, shell, operating system, database engine, and backup utility as confirmed values or slots. If the database engine is missing, do not choose PostgreSQL, MySQL, SQLite, or another engine: provide a clearly marked engine-specific slot or ask for the engine before presenting executable command syntax.

Define numbered, observable acceptance criteria. They must cover: successful backup creation, correct nightly scheduling, destination naming, credential handling, permissions, logging, non-zero failure signalling, and verification of the resulting backup. Preserve existing behaviour by explicitly identifying `[FILL IN: existing backup, restore, retention, or operational behaviour that must not break]`; if none exists, state that this is unconfirmed rather than assuming there is no existing behaviour.

Specify edge cases and exact failure behaviour, including a missing destination, unavailable database, invalid credentials, insufficient disk space, an already-running backup, interrupted execution, partial output, corrupt or unverifiable backup, permission denial, and notification failure. Define the error message format, exit codes, cleanup or recovery action, and whether a temporary file is renamed only after successful completion. Prevent overlapping cron runs when the input environment requires it, but do not claim that a lock mechanism is safe until its platform and implementation are specified.

If the script touches personal data, ask which regime governs it: GDPR, CCPA/CPRA, or HIPAA. Require the retention period and deletion path in the design, not merely in a comment. Require the licence of every added dependency and whether copyleft terms are acceptable for this project. Do not make performance or reliability claims that have not been measured. Never print secrets, embed credentials in the script, or invent a backup command.

## Output structure

Order the response exactly as follows:

1. **Goal and stack** — State the nightly-backup objective, then list language, shell, runtime, operating system, database engine, backup utility, dependencies, credential method, destination, retention, schedule, and time zone. Mark each as `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`. Do not fill missing values.
2. **Configuration contract** — Show every required environment variable, configuration field, permission, directory, and secret reference. Explain what supplies each slot and how secrets are protected.
3. **Script** — Provide the complete cron-invoked script in one code block. Include strict error handling appropriate to the confirmed shell, safe temporary-file handling, logging, exit status, overlap protection where applicable, and cleanup. Use placeholders rather than fabricated commands when engine details are missing.
4. **Cron installation** — Show the cron entry only when the schedule and time zone are confirmed; otherwise show a cron-entry design with slots. State the required file ownership and permissions.
5. **Numbered acceptance criteria** — Each criterion must be testable and observable, with pass and fail conditions.
6. **Edge cases** — Use a table with condition, detection, message, exit code, cleanup or recovery, and alert action.
7. **How it is verified** — Give dry-run, successful-run, failure-injection, backup-integrity, restore-test, scheduling, permissions, retention, and log-review procedures. Do not claim a restore test passed unless evidence is provided.

## Style rules

Use a hybrid style. Use numbered lists and tables for the stack, acceptance criteria, edge cases, configuration fields, and verification checks. Use concise narrative paragraphs only to explain design decisions, deployment assumptions, and the boundary between confirmed facts and `[FILL IN]` slots. Keep the register operational, direct, and unambiguous. Avoid generic “best practice” slogans, vague assurances, and claims that the backup is secure, reliable, or production-ready without stated evidence.

## 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 cron-based database backup script, not a generic backup essay or unrelated automation.
2. Confirm that “every night” is represented by a schedule and time-zone slot unless the user supplied both.
3. Check that the database engine, backup utility, operating system, shell, runtime, destination, retention, and credentials were not invented.
4. Check that every unconfirmed actual item—especially the database engine and backup command—remains a `[FILL IN: item]` slot with an instruction for supplying it.
5. Check that no slot was filled arbitrarily with a database name, path, user, password, schedule, retention value, or notification address.
6. Check that the script does not expose credentials through arguments, logs, source text, or unsafe environment handling.
7. Check that success requires a completed and verifiable backup rather than merely a created file.
8. Check that failure cases include unavailable database, invalid credentials, insufficient storage, interruption, partial output, overlap, and permission errors with observable exit behaviour.
9. Check that existing behaviour is identified and protected, or explicitly marked as `[FILL IN: existing behaviour]`.
10. Check that measured performance claims have not been added.
11. Check that personal-data handling asks for GDPR, CCPA/CPRA, or HIPAA, and includes retention and deletion design when applicable.
12. Check that no content drifts beyond the requested backup automation, deployment, failure handling, and verification scope.