The Best Prompt for Database Schema Design

# Role
You are a database engineer designing a relational schema that will run in production for years. You prefer constraints in the database over rules that live only in application code.

# Inputs
- Application: Multi-tenant invoicing tool for freelancers
- Entities and business rules: Accounts have users, clients and invoices. An invoice belongs to one client and has one or more line items. Invoice numbers are unique within an account. Status is draft, sent, paid or void. A sent invoice's line items cannot change. Payments can be partial. A client with invoices cannot be deleted.
- Database engine: PostgreSQL
- Most important queries and writes: List an account's unpaid invoices ordered by due date. Look up an invoice by account and number. Total billed and total paid per client per month. List a client's invoices newest first. Find invoices overdue as of today.
- Expected size and growth: Thousands of accounts, up to a few million invoices over three years
- Conventions, ORM or existing tables: snake_case, plural table names, UUID primary keys, created_at and updated_at on every table

# Steps

## 1. Relationships in plain language
Before any SQL, write one sentence per relationship in the form "A customer has zero or more orders; an order belongs to exactly one customer." I will check these against reality, so include optionality and whether deleting the parent should be blocked, cascaded or should null the reference.

## 2. Schema
Write CREATE TABLE statements for the engine above, runnable in order. For every table include:
- a primary key, with a one-line reason for the key type;
- foreign keys with explicit ON DELETE behavior;
- NOT NULL, UNIQUE and CHECK constraints that enforce the business rules I gave you;
- the most specific sensible type for each column. Money is never a floating-point type. Timestamps state whether they carry a time zone.

## 3. Indexes
List each index beyond those created by keys. Beside each, name the query from my list that it serves. No index without a named query.

## 4. Design decisions
In a short table: decision, alternative considered, why you chose this. Cover at least normalization versus any deliberate denormalization, how history or soft deletion is handled if the rules imply it, and anything that will be hard to change once data exists.

## 5. Query check
Write the SQL for the three most important queries from my list against your schema. If one is awkward, revise the schema and say what changed.

## 6. Open questions
Rules that were ambiguous and what you assumed.

# Constraints
- Use only features of the stated engine and say so when a feature is engine-specific.
- Do not add tables or columns for features I did not describe. Suggest them under Open questions.
- Mark every guess [ASSUMPTION]. Do not invent row counts or performance figures.

# Output format
The six numbered headings above. SQL in fenced code blocks, everything else as brief bullets or tables.