Create a cron script that backs up the database every night

## Role and objective

You are a software engineer designing a cron-based database backup solution. Produce the requested nightly backup script and the minimum instructions needed for a qualified operator to configure, run, and verify it. The deliverable must be executable only after all required `[FILL IN: ...]` values are confirmed, and it must not silently assume a database engine, operating system, credentials method, storage destination, retention policy, or timezone. Completion means that the script has a defined trigger, invokes the confirmed backup mechanism, reports success and failure observably, protects backup integrity and sensitive data, and can be tested without waiting for the nightly schedule.

## Scope and given facts

In scope:

- A cron script that backs up a database every night.
- The cron entry or scheduling instruction required to run the script.
- Configuration, permissions, logging, failure reporting, and a verification procedure.
- Preservation of existing database behaviour and avoidance of unnecessary application changes.

The only confirmed request facts are that the deliverable is a cron script and that the backup should run nightly. Treat the following as unresolved:

- `[FILL IN: database engine, version, database name or selection method, and native backup command]`
- `[FILL IN: operating system, shell, runtime, and cron implementation]`
- `[FILL IN: backup destination, storage access method, and encryption requirement]`
- `[FILL IN: schedule time, timezone, retention period, and expected backup frequency]`
- `[FILL IN: credential source and alerting destination]`
- `[FILL IN: existing backup process or behaviour that must not break]`

Fill each slot only from a user-confirmed value or a verifiable project source. Do not arbitrarily fill the database engine, nightly time, backup path, retention period, or credential method.

## Working rules

1. State the language, runtime, dependencies, shell, operating system, database engine, and execution environment as confirmed values or `[FILL IN: ...]` slots. Do not present a script as production-ready while a required slot remains unresolved.
2. Select the implementation branch from these conditions:
   - If the database engine has an official command-line backup utility, use that utility and document its exact invocation.
   - If the engine requires a logical or physical backup distinction, ask which type is required before choosing.
   - If the backup destination is local, define filesystem permissions, free-space checks, and atomic completion handling.
   - If the destination is remote or object storage, define the confirmed client, authentication method, transfer verification, and retry behaviour.
   - If credentials are supplied through an environment file, secret store, or operating-system account, use only the confirmed method; never embed secrets in the script or command line unless explicitly required and approved.
3. Make completion conditions observable: the expected exit status, creation or update of the backup artifact, integrity-check result, log entry, and failure notification must each be stated.
4. Define failure behaviour for invalid configuration, unavailable database, authentication failure, insufficient disk space, interrupted backup, failed transfer, checksum or integrity mismatch, concurrent execution, and permission errors. Specify error messages, exit codes, cleanup, and whether a retry occurs.
5. Prevent partial artifacts from being mistaken for completed backups by using a temporary name and an atomic rename or an equivalent confirmed mechanism.
6. Define locking or another concurrency control so overlapping nightly runs have an explicit outcome.
7. Preserve the confirmed existing behaviour of the database and application. Do not stop services, change schemas, alter production data, or modify unrelated cron jobs unless the user confirms that requirement.
8. For personal data, ask which regime governs it—`[FILL IN: GDPR, CCPA/CPRA, HIPAA, or other regime]`—and place the confirmed retention period and deletion path in the design, not only in a comment.
9. Record the licence of every added dependency and whether copyleft terms are acceptable for this project. Do not make unmeasured performance claims.

## Output structure

Use this order and include every item:

1. **Goal and stack** — State the nightly backup objective, then provide a compact table containing the language, runtime, shell, operating system, database engine, dependencies, execution user, destination, schedule, timezone, retention, credential source, and existing behaviour to preserve. Mark each value `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`; add one line explaining how each slot is filled.
2. **Implementation** — Provide the script in a fenced code block, followed by the cron entry. Include strict error handling appropriate to the confirmed language, locking, temporary output, permissions, logging, integrity verification, cleanup, and notification behaviour. Do not include invented commands.
3. **Numbered acceptance criteria** — List observable pass/fail conditions, including a successful test run, a valid backup artifact, failure detection, safe secret handling, no accidental overwrite, and no breakage to the confirmed existing behaviour.
4. **Edge cases** — Use a table with condition, expected message, exit code, cleanup or recovery, and operator action.
5. **How it is verified** — Give setup checks, a dry run or safe test procedure, a manual invocation, artifact validation, log inspection, failure simulation, and confirmation that the nightly cron trigger uses the confirmed timezone.
6. **Dependency and operations notes** — List dependency licences, permissions, retention/deletion implementation, alerting configuration, and rollback or disablement steps.

Do not fill unresolved fields with example values. Keep explanatory prose limited to the goal, implementation caveats, and verification instructions; use lists and tables for the remaining sections.

## Style rules

Use a hybrid style. Write **Goal and stack**, implementation caveats, and verification explanations as concise narrative prose. Write acceptance criteria, edge cases, configuration fields, and operational checks as numbered lists or tables. Use a precise operational register. Avoid vague phrases such as “securely back up,” “handle errors gracefully,” or “run as needed”; replace each with a measurable condition, mechanism, or operator action.

## 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 output is a cron-based script and not a report, generic backup explanation, or unrelated deployment tool.
2. Confirm that “every night” is represented by an explicit schedule slot and timezone slot, without inventing a time.
3. Confirm that the database engine and native backup command are either user-confirmed or marked `[FILL IN]`.
4. Confirm that language, runtime, shell, operating system, dependencies, and execution user are identified without fabricated values.
5. Confirm that the script cannot treat a partial backup as a completed artifact.
6. Confirm that locking, exit codes, error messages, logging, cleanup, and recovery behaviour are specified for the listed failure cases.
7. Confirm that credentials are not hard-coded and that the credential source is either confirmed or left as a slot.
8. Confirm that destination, retention period, deletion path, and encryption treatment are not assumed.
9. Confirm that any personal-data regime is named only as a slot or confirmed value, with no unsupported legal conclusion.
10. Confirm that every added dependency has a licence treatment and copyleft acceptability status.
11. Check for facts added beyond the input, especially a database product, operating system, backup path, schedule time, retention duration, or alerting service.
12. Check that no `[FILL IN]` slot was arbitrarily completed with a plausible-looking value.
13. Check that the work stays within nightly database backup automation and does not drift into schema changes, application refactoring, or unrelated infrastructure changes.
14. Confirm that the final sections appear in the required order and that acceptance criteria and edge cases are observable rather than aspirational.