Preset Tasks

# Browser RPG Arena

Build a small browser RPG game that can be opened and judged in a browser. The submitted solution must include a self-contained static browser build even if you use Vite, TypeScript, or another development server while implementing it.

## Critical: Solution Root

- Put every implementation file and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `index.html`, `package.json`, or other entrypoint files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/`, and do not leave implementation assets beside the submitted Open Challenge `src/` directory.

**Difficulty:** medium  
**Estimated Time:** 45 minutes  
**Type:** Browser web app

## Runtime Compatibility

- The final solution root must contain a ready-to-serve `index.html` plus its browser-executable HTML/CSS/JavaScript/assets.
- If using Node.js for development or evaluation, it must work on Node.js 20 LTS and `package.json` must include a `start` script.
- If using Go, `go.mod` must specify `go 1.24` or lower.
- If using Python, use Python 3.12-compatible syntax.
- Do not use external network calls, CDNs, remote fonts, remote images, or online APIs.

## Critical: Public Preview Submission Contract

Open Challenge result preview is static-only. It serves files from the submitted solution archive in a sandbox and does **not** run `npm`, Vite, Node.js, Go, Python, PHP, or any backend process.

- `index.html` at the solution root must load directly from a plain static HTTP server.
- Reference scripts, styles, images, fonts, audio, and other assets with relative URLs such as `assets/main.js` or `./styles.css`.
- Do not use root-absolute URLs such as `/main.ts`, `/src/main.ts`, `/assets/main.js`, or `/favicon.svg`; they escape the submission preview path.
- Do not reference `.ts`, `.tsx`, or `.jsx` files from `index.html`. Browsers do not compile those files, and public preview serves only ready browser assets. Compile them to `.js` or `.mjs`.
- Do not depend on API routes, server-side rendering, runtime environment variables, WebSockets, or a development-server fallback. The complete playable game must work from the static bundle with network access disabled.
- Do not try to fix preview by allowing `Origin: null` or weakening CORS. A compliant submission does not require cross-origin requests.

If you use Vite or TypeScript:

1. Configure the production build to use relative asset paths, for example `base: "./"` in Vite.
2. Run the production build before submission.
3. Copy the **contents** of the generated `dist/` or `build/` directory into the solution root so the root `index.html` is the built file and its compiled assets are included. The submission collector excludes directories named `dist/` and `build/`.
4. Confirm the submitted root `index.html` references compiled `.js`/`.mjs` files through relative paths and does not reference source `.ts`/`.tsx`/`.jsx` files.

Before submitting, run a plain static server from the solution root, for example:

```bash
python3 -m http.server 8000 --bind 127.0.0.1
```

Open `http://127.0.0.1:8000/`, verify that the game is fully playable, and check the browser console and Network panel for missing files, blocked requests, or runtime errors. Passing through `npm run dev` or a Vite development server is not sufficient for this check.

## Game Requirements

- Show a playable RPG arena with a hero, an enemy, and a visible combat area.
- Implement turn-based combat with at least one basic attack and one ability or inventory action.
- Display hero stats and enemy stats, including HP and at least one additional stat such as attack, defense, mana, stamina, or armor.
- Use deterministic seeded encounters. The same seed must produce the same initial enemy/state.
- Show a combat log that records player and enemy actions.
- Show a clear win/loss/in-progress state.
- Include mouse controls. Keyboard shortcuts are optional but encouraged.
- Use responsive layout so the game remains usable on a phone-width viewport.

## Presentation and Gameplay Quality

This task will be reviewed by humans, so implementation quality should go beyond the minimum test hooks. Make the game look intentional, polished, and enjoyable to play.

- Prioritize visual quality: cohesive art direction, readable typography, clear spacing, strong contrast, and a deliberate color palette.
- Add meaningful animations and transitions for attacks, damage, healing, turn changes, status effects, victory, and defeat.
- Make combat feel interactive: actions should have immediate feedback, visible consequences, and enough pacing that turns are easy to follow.
- Think through game details such as ability cooldowns, resource costs, enemy behavior, item usage, tooltips, disabled states, and restart/retry flow.
- Keep the UI technically solid: no overlapping text, no layout jumps during combat, responsive controls, accessible button states, and clear focus/hover feedback.
- Use assets, CSS effects, canvas, or lightweight in-repo artwork where useful, but do not depend on external networks or CDNs.
- A complete, polished, playable experience should score better than a minimal interface that only passes automated smoke tests.

## Technical Quality Expectations

This is a dependency-free static browser game, so reviewers will judge the architecture proportionately. A framework, backend layering, build tool, or large component hierarchy is not required. Native browser modules loaded through relative URLs are fully acceptable.

- Keep deterministic game logic separate from DOM rendering and event orchestration. Separation may use focused ES modules or clear internal boundaries; file count alone is not a quality signal.
- Make the deterministic game logic independently testable. Deterministic engine tests should cover the same-seed contract, valid and rejected actions, cooldown/resource boundaries, and terminal win/loss behavior.
- Construct dynamic UI safely. Prefer `textContent`, `createElement`, `replaceChildren`, or equivalent safe APIs; avoid unsafe HTML injection with dynamic game or user-controlled values.
- Include browser-relevant defensive handling where the app has real failure boundaries: seed and action validation, missing required DOM hooks, unavailable optional browser APIs, repeated/locked actions, asynchronous enemy turns, and reset/retry races.
- Do not add fake backend, database, HTTP, or framework abstractions solely for review. Clear, maintainable boundaries and behavior-focused tests matter more than architectural ceremony.

## Required DOM/Test Hooks

Smoke tests and human reviewers will look for these stable hooks in the served page:

| Hook | Required selector | Purpose |
|------|-------------------|---------|
| App root | `[data-testid="app-root"]` | Main game mount point |
| Hero stats | `[data-testid="hero-stats"]` | Visible hero HP/stat state |
| Enemy stats | `[data-testid="enemy-stats"]` | Visible enemy HP/stat state |
| Combat log | `[data-testid="combat-log"]` | Action history |
| Attack button | `[data-testid="attack-button"]` | Basic action control |
| Ability button | `[data-testid="ability-button"]` | Ability or inventory action |
| Inventory panel | `[data-testid="inventory-panel"]` | Items, abilities, or resources |
| Encounter seed | `[data-testid="encounter-seed"]` | Deterministic seed display |
| Game status | `[data-testid="game-status"]` | Win/loss/in-progress state |

## Acceptance Criteria

- The app serves successfully at `/`.
- The first screen shows the actual game, not a landing page or instructions-only page.
- The user can take a turn and see the game state change.
- The enemy can respond or the game can advance deterministically after a player action.
- The game can reach a visible win or loss state.
- 

# Enterprise PDF API Challenge

Build a production-like HTTP API with order processing and asynchronous PDF report generation.

This is a **hard** task by design. A realistic completion time for a competent developer is **60-120 minutes**.

## CRITICAL: Solution Root Requirement

- Put every implementation package, entrypoint, and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `go.mod`, `package.json`, `requirements.txt`, and source files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/` inside the solution root, and do not leave packages beside the submitted Open Challenge `src/` directory.
- Validation starts the server from the submitted solution root (for example `go run .`, `npm start`, `python3 main.py`, or `php -S localhost:PORT -t .`). An entrypoint under `cmd/server/`, `app/`, or another nested application root will fail to start.

| Language | Required files at the solution root |
|----------|-------------------------------------|
| Go       | `go.mod` + `main.go` (package `main`) |
| Node.js  | `package.json` with `start` script, OR `index.js` / `main.js` |
| Python   | `main.py` (plus `requirements.txt` if needed) |
| PHP      | `composer.json` OR `*.php` files |

## Runtime Environment

The evaluation server has the following runtimes. Your code and dependencies **must be compatible** with these versions — using newer features or dependencies that require a higher version will cause a startup crash.

| Runtime    | Version            |
|------------|--------------------|
| **Go**     | 1.24 (`GOTOOLCHAIN=local`) |
| **Node.js**| 20 LTS             |
| **Python** | 3.12               |

- **Go version rule is strict:** `go.mod` must specify `go 1.24` or lower. Do **not** use `go 1.25`, `toolchain go1.25...`, or dependencies whose `go.mod` requires Go 1.25+.
- The evaluator runs with `GOTOOLCHAIN=local`, so Go will **not** auto-download a newer toolchain. A submission that requires Go 1.25+ will fail before tests run.
- Before adding a Go dependency, check its required Go version. If the latest release requires Go 1.25+, pin an older release that supports Go 1.24.
- For Node.js: do not use Node 22+ APIs. If using `package.json`, ensure `engines` allows Node 20.
- For Python: do not use Python 3.13+ features.

## Runtime Requirements

- Your server MUST listen on port **8080**.
- The server must become ready within **5 seconds**.
- Every JSON response MUST use `Content-Type: application/json`.
- PDF download responses MUST use `Content-Type: application/pdf`.

## Database Requirement (Critical)

- You MUST implement persistence using **PostgreSQL** (not SQLite and not in-memory only).
- The evaluation runner can provide an isolated Postgres instance inside the same Docker network.
- Your app MUST support the following connection env formats:
  - `DATABASE_URL` or `POSTGRES_URL`
  - or discrete vars: `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_SSLMODE`
- Your implementation must remain correct under concurrent writes and status transitions (race-safe behavior is tested).

## Required Endpoints

### Health and readiness

1. `GET /health`
- Returns `200` with:
```json
{"status":"ok"}
```

2. `GET /ready`
- Returns `200` with:
```json
{
  "status":"ready",
  "checks": {
    "storage":"ok",
    "pdf":"ok"
  }
}
```

### Customers

3. `POST /customers`
- Required header: `X-Request-ID` (non-empty)
- Request body:
```json
{
  "name":"Alice Doe",
  "email":"alice@example.com",
  "active":true
}
```
- Validation:
  - `name`: non-empty after trim
  - `email`: valid format
- Returns `201` with:
```json
{
  "customer_id":"uuid",
  "name":"Alice Doe",
  "email":"alice@example.com",
  "active":true,
  "created_at":"RFC3339"
}
```

4. `GET /customers/{customer_id}`
- Returns `200` with customer object.
- Returns `404` if missing.

5. `GET /customers?limit=...&offset=...&active=...`
- `limit` range: 1–100. Values outside this range (including 0 or >100) return `400`.
- Returns paginated list:
```json
{
  "items":[...],
  "total":1,
  "limit":10,
  "offset":0
}
```

### Products

6. `POST /products`
- Required header: `X-Request-ID`
- Request body:
```json
{
  "sku":"SKU-ABC-001",
  "name":"Starter Plan",
  "unit_price":1299,
  "currency":"USD",
  "active":true
}
```
- Validation:
  - `sku`: non-empty after trim
  - `unit_price`: integer cents, `> 0`
  - `currency`: currently only `USD`
- Returns `201` with product object and `product_id`.

7. `GET /products/{product_id}`
- Returns `200` with product object.

8. `GET /products?limit=...&offset=...&currency=USD`
- Returns paginated list with same envelope shape as customers.

### Orders

9. `POST /orders`
- Required header: `X-Request-ID`
- The referenced customer MUST have `active == true`. If the customer exists but is inactive, return `422`.
- Request body:
```json
{
  "customer_id":"uuid",
  "currency":"USD"
}
```
- Returns `201`:
```json
{
  "order_id":"uuid",
  "customer_id":"uuid",
  "currency":"USD",
  "status":"draft",
  "created_at":"RFC3339"
}
```

10. `POST /orders/{order_id}/items`
- Required header: `X-Request-ID`
- **Items can ONLY be added to `draft` orders.** Attempting to add items to an order in any other status MUST return `409`.
- Request body:
```json
{
  "items":[
    {"product_id":"uuid","quantity":2},
    {"product_id":"uuid","quantity":1}
  ]
}
```
- Validation:
  - `items`: 1..50
  - `quantity`: integer 1..100
- **Duplicate product merge**: When adding items with duplicate `product_id` in one request, quantities MUST be merged into a single line item. If a product already exists on the order from a previous request, ADD to the existing line item's quantity (do not create duplicate lines for the same product).
- Returns `200`:
```json
{
  "order_id":"uuid",
  "accepted_items":2,
  "item_count":3
}
```

11. `PATCH /orders/{order_id}/status`
- Required header: `X-Request-ID`
- Request body:
```json
{"status":"confirmed"}
```
- Allowed transitions:
  - `draft -> confirmed | cancelled`
  - `confirmed -> paid | cancelled`
  - `paid -> (no transitions)`
  - `cancelled -> (no transitions)`
- Returns `200`:
```json
{"order_id":"uuid","status":"confirmed"}
```
- **`draft → confirmed` requires at least 1 item on the order.** If the order has zero items, return `422`.
- Invalid transition returns `409` or `422` (must follow the common error schema).

12. `GET /orders/{order_id}`
- Returns full order details:
```json
{
  "order_id":"uuid",
  "customer_id":"uuid",
  "currency":"USD",
  "status":"confirmed",
  "items":[...],
  "item_count":3,
  "totals":{
    "subtotal":3897,
    "tax":389,
    "discount":0,
    "grand_total":4286
  },
  "updated_at":"RFC3339"
}
```

13. `GET /orders/{order_id}/totals`
- Returns:
```json
{
  "order_id":"uuid",
  "item_count":3,
  "subtotal":3897,
  "tax":389,
  "discount":0,
  "grand_total":4286,
  "currency":"USD"
}
```

## Totals Rules (strict)

- Money unit is integer cents.
- `subtotal = sum(quantity * unit_price)`
- `tax = floor(subtotal * 10 / 100)` — uses **floor** (truncation toward zero)
- Discount uses **tiered rates** with `round_half_up` rounding (NOT floor):

| Subtotal Range      | Rate |
|---------------------|------|
| < 5000              | 0%   |
| 5000 ≤ s < 15000   | 3%   |
| 15000 ≤ s < 30000  | 5%   |
| s ≥ 30000           | 8%   |

- `discount = round_half_up(subtotal * tier_rate / 100)`
- **`round_half_up(x) = floor(x + 0.5)`** — this is standard "round half up" (0.5 rounds to 1, not to 0).
- **IMPORTANT**: Tax uses `floor()`. Discount uses `round_half_up()`. These are DIFFERENT rounding methods.
- `grand_total = subtotal + tax - discount`

## Reports (asynchronous PDF)

14. `POST /reports/pdf`
- Required headers:
  - `X-Request-ID`
  - `Idempotency-Key`
- Request bod

# Enterprise PDF API Challenge

Build a production-like HTTP API with order processing and asynchronous PDF report generation.

This is a **hard** task by design. A realistic completion time for a competent developer is **60-120 minutes**.

## CRITICAL: Solution Root Requirement

- Put every implementation package, entrypoint, and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `go.mod`, `package.json`, `requirements.txt`, and source files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/` inside the solution root, and do not leave packages beside the submitted Open Challenge `src/` directory.
- Validation starts the server from the submitted solution root (for example `go run .`, `npm start`, `python3 main.py`, or `php -S localhost:PORT -t .`). An entrypoint under `cmd/server/`, `app/`, or another nested application root will fail to start.

| Language | Required files at the solution root |
|----------|-------------------------------------|
| Go       | `go.mod` + `main.go` (package `main`) |
| Node.js  | `package.json` with `start` script, OR `index.js` / `main.js` |
| Python   | `main.py` (plus `requirements.txt` if needed) |
| PHP      | `composer.json` OR `*.php` files |

## Runtime Environment

The evaluation server has the following runtimes. Your code and dependencies **must be compatible** with these versions — using newer features or dependencies that require a higher version will cause a startup crash.

| Runtime    | Version            |
|------------|--------------------|
| **Go**     | 1.24 (`GOTOOLCHAIN=local`) |
| **Node.js**| 20 LTS             |
| **Python** | 3.12               |

- **Go version rule is strict:** `go.mod` must specify `go 1.24` or lower. Do **not** use `go 1.25`, `toolchain go1.25...`, or dependencies whose `go.mod` requires Go 1.25+.
- The evaluator runs with `GOTOOLCHAIN=local`, so Go will **not** auto-download a newer toolchain. A submission that requires Go 1.25+ will fail before tests run.
- Before adding a Go dependency, check its required Go version. If the latest release requires Go 1.25+, pin an older release that supports Go 1.24.
- For Node.js: do not use Node 22+ APIs. If using `package.json`, ensure `engines` allows Node 20.
- For Python: do not use Python 3.13+ features.

## Runtime Requirements

- Your server MUST listen on port **8080**.
- The server must become ready within **5 seconds**.
- Every JSON response MUST use `Content-Type: application/json`.
- PDF download responses MUST use `Content-Type: application/pdf`.

## Database Requirement (Critical)

- You MUST implement persistence using **PostgreSQL** (not SQLite and not in-memory only).
- The evaluation runner can provide an isolated Postgres instance inside the same Docker network.
- Your app MUST support the following connection env formats:
  - `DATABASE_URL` or `POSTGRES_URL`
  - or discrete vars: `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_SSLMODE`
- Your implementation must remain correct under concurrent writes and status transitions (race-safe behavior is tested).

## Required Endpoints

### Health and readiness

1. `GET /health`
- Returns `200` with:
```json
{"status":"ok"}
```

2. `GET /ready`
- Returns `200` with:
```json
{
  "status":"ready",
  "checks": {
    "storage":"ok",
    "pdf":"ok"
  }
}
```

### Customers

3. `POST /customers`
- Required header: `X-Request-ID` (non-empty)
- Request body:
```json
{
  "name":"Alice Doe",
  "email":"alice@example.com",
  "active":true
}
```
- Validation:
  - `name`: non-empty after trim
  - `email`: valid format
- Returns `201` with:
```json
{
  "customer_id":"uuid",
  "name":"Alice Doe",
  "email":"alice@example.com",
  "active":true,
  "created_at":"RFC3339"
}
```

4. `GET /customers/{customer_id}`
- Returns `200` with customer object.
- Returns `404` if missing.

5. `GET /customers?limit=...&offset=...&active=...`
- `limit` range: 1–100. Values outside this range (including 0 or >100) return `400`.
- Returns paginated list:
```json
{
  "items":[...],
  "total":1,
  "limit":10,
  "offset":0
}
```

### Products

6. `POST /products`
- Required header: `X-Request-ID`
- Request body:
```json
{
  "sku":"SKU-ABC-001",
  "name":"Starter Plan",
  "unit_price":1299,
  "currency":"USD",
  "active":true
}
```
- Validation:
  - `sku`: non-empty after trim
  - `unit_price`: integer cents, `> 0`
  - `currency`: currently only `USD`
- Returns `201` with product object and `product_id`.

7. `GET /products/{product_id}`
- Returns `200` with product object.

8. `GET /products?limit=...&offset=...&currency=USD`
- Returns paginated list with same envelope shape as customers.

### Orders

9. `POST /orders`
- Required header: `X-Request-ID`
- The referenced customer MUST have `active == true`. If the customer exists but is inactive, return `422`.
- Request body:
```json
{
  "customer_id":"uuid",
  "currency":"USD"
}
```
- Returns `201`:
```json
{
  "order_id":"uuid",
  "customer_id":"uuid",
  "currency":"USD",
  "status":"draft",
  "created_at":"RFC3339"
}
```

10. `POST /orders/{order_id}/items`
- Required header: `X-Request-ID`
- **Items can ONLY be added to `draft` orders.** Attempting to add items to an order in any other status MUST return `409`.
- Request body:
```json
{
  "items":[
    {"product_id":"uuid","quantity":2},
    {"product_id":"uuid","quantity":1}
  ]
}
```
- Validation:
  - `items`: 1..50
  - `quantity`: integer 1..100
- **Duplicate product merge**: When adding items with duplicate `product_id` in one request, quantities MUST be merged into a single line item. If a product already exists on the order from a previous request, ADD to the existing line item's quantity (do not create duplicate lines for the same product).
- Returns `200`:
```json
{
  "order_id":"uuid",
  "accepted_items":2,
  "item_count":3
}
```

11. `PATCH /orders/{order_id}/status`
- Required header: `X-Request-ID`
- Request body:
```json
{"status":"confirmed"}
```
- Allowed transitions:
  - `draft -> confirmed | cancelled`
  - `confirmed -> paid | cancelled`
  - `paid -> (no transitions)`
  - `cancelled -> (no transitions)`
- Returns `200`:
```json
{"order_id":"uuid","status":"confirmed"}
```
- **`draft → confirmed` requires at least 1 item on the order.** If the order has zero items, return `422`.
- Invalid transition returns `409` or `422` (must follow the common error schema).

12. `GET /orders/{order_id}`
- Returns full order details:
```json
{
  "order_id":"uuid",
  "customer_id":"uuid",
  "currency":"USD",
  "status":"confirmed",
  "items":[...],
  "item_count":3,
  "totals":{
    "subtotal":3897,
    "tax":389,
    "discount":0,
    "grand_total":4286
  },
  "updated_at":"RFC3339"
}
```

13. `GET /orders/{order_id}/totals`
- Returns:
```json
{
  "order_id":"uuid",
  "item_count":3,
  "subtotal":3897,
  "tax":389,
  "discount":0,
  "grand_total":4286,
  "currency":"USD"
}
```

## Totals Rules (strict)

- Money unit is integer cents.
- `subtotal = sum(quantity * unit_price)`
- `tax = floor(subtotal * 10 / 100)` — uses **floor** (truncation toward zero)
- Discount uses **tiered rates** with `round_half_up` rounding (NOT floor):

| Subtotal Range      | Rate |
|---------------------|------|
| < 5000              | 0%   |
| 5000 ≤ s < 15000   | 3%   |
| 15000 ≤ s < 30000  | 5%   |
| s ≥ 30000           | 8%   |

- `discount = round_half_up(subtotal * tier_rate / 100)`
- **`round_half_up(x) = floor(x + 0.5)`** — this is standard "round half up" (0.5 rounds to 1, not to 0).
- **IMPORTANT**: Tax uses `floor()`. Discount uses `round_half_up()`. These are DIFFERENT rounding methods.
- `grand_total = subtotal + tax - discount`

## Reports (asynchronous PDF)

14. `POST /reports/pdf`
- Required headers:
  - `X-Request-ID`
  - `Idempotency-Key`
- Request bod

# Enterprise PDF Ledger

Build an HTTP service for inventory-backed orders and immutable financial PDF
reports. Target implementation time: **120–180 minutes**. All requirements are
available immediately; there are no later waves. The difficult part is preserving
the same invariants across retries, stale revisions, refunds and concurrent writes.

## Execution and persistence

Listen on `0.0.0.0:8080`; become ready within 5 seconds. Use PostgreSQL for all
authoritative state, including successful idempotency results and report snapshots.
Support `DATABASE_URL`, `POSTGRES_URL`, or `DB_HOST`, `DB_PORT`, `DB_NAME`,
`DB_USER`, `DB_PASSWORD`, `DB_SSLMODE`. Create your own schema at startup.
No external services are available. Go must declare `go 1.24` or lower and use
dependencies compatible with Go 1.24 (`GOTOOLCHAIN=local`); Node.js 20 and
Python 3.12 are available. Do not use newer runtime APIs.

Put every source file, dependency manifest and entrypoint in the **solution root**:
`workspace/src/` in a live match, or `<challenge>/src/` after pulling an Open
Challenge. If already in that directory, write directly there. Never nest another
`src/` or `workspace/src/`, or put implementation packages beside the root.
Entrypoint: `main.go` + `go.mod` with package main, `package.json` with `start`
or `index.js`, or `main.py` + optional `requirements.txt`.

## Common protocol

`GET /health` returns `200 {"status":"ok"}`; `GET /ready` returns
`200 {"status":"ready"}` only when storage is usable. Other endpoints require
`X-Tenant-ID`: 1–64 ASCII letters, digits, `_` or `-`. Tenants are created lazily.
This header represents an upstream authenticated identity; do not implement login.
All data, SKU uniqueness, sequences and idempotency keys are tenant-local.
Foreign or missing resource IDs return `404`, without revealing their existence.

Every POST/PUT additionally requires nonempty `X-Request-ID` and `Idempotency-Key`
(1–128 printable ASCII characters). JSON responses, including errors, use
`application/json`. Error body: `{"error":{"code":"...","message":"..."}}`.
Codes: `validation_error` (400), `not_found` (404), `conflict` (409),
`precondition_failed` (412), `unprocessable` (422), `precondition_required` (428).
GET errors use the same shape. Unknown routes return 404. Unknown JSON fields,
duplicate JSON keys, malformed JSON, booleans/fractions where integers are required,
and out-of-range values return 400. All specified fields are required. IDs are
server-generated UUIDs. Timestamps are not part of this contract.

### Atomic command and replay rules

A successful POST/PUT commits its data, exactly **one tenant sequence increment**,
and its idempotency record in one transaction. Tenant sequence starts at 0.
Failures, reads and replays never change it. `/state` returns `{"sequence":N}`.
Idempotency keys are scoped to the tenant across **all** POST/PUT routes.

The fingerprint is HTTP method + path + parsed body + parsed If-Match value
(or absence). JSON object key order and insignificant whitespace do not matter;
array order does matter. Integers are JSON integer tokens, not `1.0` or `1e0`.
Replaying the same fingerprint returns the original success status and identical
JSON value, even after later mutations make that revision stale. Reusing a key
with a different fingerprint returns 409. Concurrent identical requests must all
return the same success; concurrent different requests with the same key have
one winning fingerprint. Failed requests do **not** reserve a key.

Validation precedence: common headers and JSON syntax/types first; then successful
replay/key conflict; then resource visibility; then revision precondition; then
domain invariants. Errors do not partially write state. Invalid domain operations
must not poison a key for a corrected retry.

### Revision preconditions

All order PUTs and order action POSTs require `If-Match: "N"`, a quoted positive
decimal revision. Missing -> 428; malformed -> 400; stale -> 412. Revision checks
and writes are atomic. A successful new order has revision 1; every successful
order mutation increases revision by exactly 1. Replays do not. All order response
objects include `revision` and `sequence` (the last sequence that changed that order).

## Products and inventory

`POST /products`: `{"sku":"A","unit_price":101,"tax_bps":1000,"stock":10}`
returns 201 product; duplicate SKU -> 409. SKU matches `[A-Za-z0-9_-]{1,32}`;
price is integer 1..1,000,000,000 cents; tax_bps is integer 0..10000;
stock is integer 0..1,000,000. Prices and tax rates are immutable.

`GET /products/{sku}` returns 200:
`{"sku":"A","unit_price":101,"tax_bps":1000,"on_hand":10,"reserved":0,"available":10}`.
Product creation returns the same shape. Always `available = on_hand - reserved`;
all three quantities are nonnegative.

## Orders and allocation

`POST /orders` returns 201; `PUT /orders/{id}` replaces an entire draft and returns
200. Both accept `{"items":[{"sku":"A","quantity":3}],"discount":1}`.
There must be 1..20 distinct SKUs (duplicates -> 400), quantity integer 1..1000,
discount integer 0..sum(gross). Missing SKU -> 404; discount above gross -> 422.
Drafts do not reserve stock and may exceed currently available stock.
Replacing a non-draft -> 409. Validate the entire replacement before writing.

`GET /orders/{id}` and all successful order mutations return the full order:

```json
{"order_id":"uuid","status":"draft","revision":1,"sequence":2,
 "discount":1,"subtotal":303,"tax":30,"total":332,"refunded_total":0,
 "lines":[{"sku":"A","quantity":3,"unit_price":101,"tax_bps":1000,
 "gross":303,"discount":1,"net":302,"tax":30,"total":332,"refunded_quantity":0}]}
```

Always sort lines by ASCII SKU. Keep original totals unchanged after refunds.
Calculate using exact integers (no floating-point rounding):

1. Line gross `g[i] = price[i] * quantity[i]`; subtotal `S = sum(g)`.
2. Distribute order discount `D` proportionally: initial allocation
   `d[i] = floor(D*g[i]/S)`. Give the remaining cents one per line by decreasing
   remainder `(D*g[i]) mod S`, ties by ascending ASCII SKU. This is largest remainder.
3. Line net `n[i] = g[i]-d[i]`. Line tax is **round half to even** of
   `n[i]*tax_bps[i]/10000`; ties go to the even integer. Tax is rounded per line.
4. Line total = net + tax. Order tax/total are sums of line tax/total.

Intermediate `D*g[i]` may exceed both JavaScript safe integers and signed int64.
Use arbitrary precision or a mathematically equivalent overflow-safe algorithm.
JSON result values remain safe integers within the declared limits.

## State transitions and stock

Each action accepts `{}` except refund; each needs If-Match and normal mutation
headers. Domain-invalid transitions return 409 after the revision check.

| POST route | Allowed state | Result and inventory effect |
|---|---|---|
| `/orders/{id}/confirm` | draft | confirmed; reserve every line atomically; insufficient available stock -> 409 |
| `/orders/{id}/pay` | confirmed | paid; decrease on_hand and reserved by each quantity |
| `/orders/{id}/cancel` | draft, confirmed | cancelled; confirmed releases reserved; draft has no stock effect |
| `/orders/{id}/refund` | paid, partially_refunded | described below |

Different orders competing for stock must never oversell. Rejected multi-product
confirmation must not reserve even its satisfiable lines. Opposite line ordering
in concurrent commands must not cause an unbounded deadlock. A successful HTTP
response is a committed operation: subsequent reads must observe it.

### Partial refunds

Body: `{"items":[{"sku":"A","quantity":1}]}`, 1..20 distinct SKUs,
positive integer quantity <=1000. Every SKU must be on the order (otherwise 422).
If any cumulative refunded quantity would exceed the original quantity, reject the
whole command with 422. Duplicate SKUs -> 400. Refunded units return to on_hand.

For original line total `T`, original quantity `Q` and cumulative refunded units
`k`, the cumulative refunded cents are `f

# Enterprise PDF Recovery

Repair the supplied running HTTP service for inventory-backed orders and immutable
financial PDF reports. Copy the contents of `starter/` into your solution root.
You may restructure or reimplement it in any accepted runtime; the HTTP contract
is authoritative. The starter passes ordinary flows but contains recovery and
concurrency defects. Include regression tests and explain your changes in a README. Target implementation time: **120–180 minutes**. All requirements are
available immediately; there are no later waves. The difficult part is preserving
the same invariants across retries, stale revisions, refunds and concurrent writes.

## Execution and persistence

Listen on `0.0.0.0:8080`; become ready within 5 seconds. Use PostgreSQL for all
authoritative state, including successful idempotency results and report snapshots.
Support `DATABASE_URL`, `POSTGRES_URL`, or `DB_HOST`, `DB_PORT`, `DB_NAME`,
`DB_USER`, `DB_PASSWORD`, `DB_SSLMODE`. Create your own schema at startup.
The supplied archive at `AICHAMP_FIXTURE_URL` is the only additional service.
PostgreSQL and the archive survive application crashes. The evaluator may SIGKILL
and restart your application at any time, including during a request. Dependencies
are prepared once; restart has no package-network access. Only PostgreSQL is
promised durable application state. Become ready within 5 seconds after restart.
Pending work must resume without a new client request. Go must declare `go 1.24` or lower and use
dependencies compatible with Go 1.24 (`GOTOOLCHAIN=local`); Node.js 20 and
Python 3.12 are available. Do not use newer runtime APIs.

Put every source file, dependency manifest and entrypoint in the **solution root**:
`workspace/src/` in a live match, or `<challenge>/src/` after pulling an Open
Challenge. If already in that directory, write directly there. Never nest another
`src/` or `workspace/src/`, or put implementation packages beside the root.
Entrypoint: `main.go` + `go.mod` with package main, `package.json` with `start`
or `index.js`, or `main.py` + optional `requirements.txt`.

## Common protocol

`GET /health` returns `200 {"status":"ok"}`; `GET /ready` returns
`200 {"status":"ready"}` only when storage is usable. Other endpoints require
`X-Tenant-ID`: 1–64 ASCII letters, digits, `_` or `-`. Tenants are created lazily.
This header represents an upstream authenticated identity; do not implement login.
All data, SKU uniqueness, sequences and idempotency keys are tenant-local.
Foreign or missing resource IDs return `404`, without revealing their existence.

Every POST/PUT additionally requires nonempty `X-Request-ID` and `Idempotency-Key`
(1–128 printable ASCII characters). JSON responses, including errors, use
`application/json`. Error body: `{"error":{"code":"...","message":"..."}}`.
Codes: `validation_error` (400), `not_found` (404), `conflict` (409),
`precondition_failed` (412), `unprocessable` (422), `precondition_required` (428).
GET errors use the same shape. Unknown routes return 404. Unknown JSON fields,
duplicate JSON keys, malformed JSON, booleans/fractions where integers are required,
and out-of-range values return 400. All specified fields are required. IDs are
server-generated UUIDs. Timestamps are not part of this contract.

### Atomic command and replay rules

A successful POST/PUT commits its data, exactly **one tenant sequence increment**,
and its idempotency record in one transaction. Tenant sequence starts at 0.
Failures, reads and replays never change it. `/state` returns `{"sequence":N}`.
Idempotency keys are scoped to the tenant across **all** POST/PUT routes.

The fingerprint is HTTP method + path + parsed body + parsed If-Match value
(or absence). JSON object key order and insignificant whitespace do not matter;
array order does matter. Integers are JSON integer tokens, not `1.0` or `1e0`.
Replaying the same fingerprint returns the original success status and identical
JSON value, even after later mutations make that revision stale. Reusing a key
with a different fingerprint returns 409. Concurrent identical requests must all
return the same success; concurrent different requests with the same key have
one winning fingerprint. Failed requests do **not** reserve a key.

Validation precedence: common headers and JSON syntax/types first; then successful
replay/key conflict; then resource visibility; then revision precondition; then
domain invariants. Errors do not partially write state. Invalid domain operations
must not poison a key for a corrected retry.

### Revision preconditions

All order PUTs and order action POSTs require `If-Match: "N"`, a quoted positive
decimal revision. Missing -> 428; malformed -> 400; stale -> 412. Revision checks
and writes are atomic. A successful new order has revision 1; every successful
order mutation increases revision by exactly 1. Replays do not. All order response
objects include `revision` and `sequence` (the last sequence that changed that order).

## Products and inventory

`POST /products`: `{"sku":"A","unit_price":101,"tax_bps":1000,"stock":10}`
returns 201 product; duplicate SKU -> 409. SKU matches `[A-Za-z0-9_-]{1,32}`;
price is integer 1..1,000,000,000 cents; tax_bps is integer 0..10000;
stock is integer 0..1,000,000. Prices and tax rates are immutable.

`GET /products/{sku}` returns 200:
`{"sku":"A","unit_price":101,"tax_bps":1000,"on_hand":10,"reserved":0,"available":10}`.
Product creation returns the same shape. Always `available = on_hand - reserved`;
all three quantities are nonnegative.

## Orders and allocation

`POST /orders` returns 201; `PUT /orders/{id}` replaces an entire draft and returns
200. Both accept `{"items":[{"sku":"A","quantity":3}],"discount":1}`.
There must be 1..20 distinct SKUs (duplicates -> 400), quantity integer 1..1000,
discount integer 0..sum(gross). Missing SKU -> 404; discount above gross -> 422.
Drafts do not reserve stock and may exceed currently available stock.
Replacing a non-draft -> 409. Validate the entire replacement before writing.

`GET /orders/{id}` and all successful order mutations return the full order:

```json
{"order_id":"uuid","status":"draft","revision":1,"sequence":2,
 "discount":1,"subtotal":303,"tax":30,"total":332,"refunded_total":0,
 "lines":[{"sku":"A","quantity":3,"unit_price":101,"tax_bps":1000,
 "gross":303,"discount":1,"net":302,"tax":30,"total":332,"refunded_quantity":0}]}
```

Always sort lines by ASCII SKU. Keep original totals unchanged after refunds.
Calculate using exact integers (no floating-point rounding):

1. Line gross `g[i] = price[i] * quantity[i]`; subtotal `S = sum(g)`.
2. Distribute order discount `D` proportionally: initial allocation
   `d[i] = floor(D*g[i]/S)`. Give the remaining cents one per line by decreasing
   remainder `(D*g[i]) mod S`, ties by ascending ASCII SKU. This is largest remainder.
3. Line net `n[i] = g[i]-d[i]`. Line tax is **round half to even** of
   `n[i]*tax_bps[i]/10000`; ties go to the even integer. Tax is rounded per line.
4. Line total = net + tax. Order tax/total are sums of line tax/total.

Intermediate `D*g[i]` may exceed both JavaScript safe integers and signed int64.
Use arbitrary precision or a mathematically equivalent overflow-safe algorithm.
JSON result values remain safe integers within the declared limits.

## State transitions and stock

Each action accepts `{}` except refund; each needs If-Match and normal mutation
headers. Domain-invalid transitions return 409 after the revision check.

| POST route | Allowed state | Result and inventory effect |
|---|---|---|
| `/orders/{id}/confirm` | draft | confirmed; reserve every line atomically; insufficient available stock -> 409 |
| `/orders/{id}/pay` | confirmed | paid; decrease on_hand and reserved by each quantity |
| `/orders/{id}/cancel` | draft, confirmed | cancelled; confirmed releases reserved; draft has no stock effect |
| `/orders/{id}/refund` | paid, partially_refunded | described below |

Different orders competing 

# Hello API

Build an HTTP API server that responds to greeting requests.

## CRITICAL: Solution Root and Entry Point

- Put every implementation file and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create the files below directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/`, and do not leave implementation packages beside the submitted Open Challenge `src/` directory.

| Language | Required files at the solution root |
|----------|-------------------------------------|
| Go       | `go.mod` + `main.go` (package `main`) — runner executes `go run .` |
| Node.js  | `package.json` with a `start` script, OR `index.js` / `main.js` |
| Python   | `main.py` (plus `requirements.txt` if needed) |
| PHP      | `composer.json` OR `*.php` files — runner uses `php -S` with `-t .` |

Placing the entrypoint under `cmd/server/`, `app/`, or another nested application root will cause startup validation to fail.

## Requirements

Your server MUST listen on port **8080** and implement the following endpoints:

### `GET /hello`

Returns a JSON greeting with a default name.

**Response** (200 OK):
```json
{"message": "Hello, World!"}
```

### `GET /hello?name=Alice`

Returns a personalized JSON greeting using the `name` query parameter.

**Response** (200 OK):
```json
{"message": "Hello, Alice!"}
```

### `GET /health`

Returns a health check response.

**Response** (200 OK):
```json
{"status": "ok"}
```

## Runtime Environment

The evaluation server has the following runtimes. Your code and dependencies **must be compatible** with these versions — using newer features or dependencies that require a higher version will cause a startup crash.

| Runtime    | Version            |
|------------|--------------------|
| **Go**     | 1.24 (`GOTOOLCHAIN=local`) |
| **Node.js**| 20 LTS             |
| **Python** | 3.12               |

- For Go: `go.mod` must specify `go 1.24` or lower. All dependencies must support Go ≤1.24.
- For Node.js: do not use Node 22+ APIs. If using `package.json`, ensure `engines` allows Node 20.
- For Python: do not use Python 3.13+ features.

## Constraints

- The server must start and be ready to accept connections within 5 seconds.
- All responses must have `Content-Type: application/json`.
- The `name` parameter must be trimmed of leading/trailing whitespace.
- Empty or whitespace-only `name` should fall back to `"World"`.
- If using JavaScript/Node.js, name the entry point file `index.js` (or provide a `package.json` with a `start` script).

# Hill Climb Racing

Build a small side-scrolling hill-driving game that can be opened and judged in a browser. The submitted solution must include a self-contained static browser build even if you use Vite, TypeScript, or another development server while implementing it.

Create original visuals and vehicle design. Do not copy branded artwork, logos, characters, level layouts, audio, or other proprietary assets from an existing game.

## Critical: Solution Root

- Put every implementation file and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `index.html`, `package.json`, or other entrypoint files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/`, and do not leave implementation assets beside the submitted Open Challenge `src/` directory.

**Difficulty:** medium
**Estimated Time:** 45 minutes
**Type:** Browser web app

## Runtime Compatibility

- The final solution root must contain a ready-to-serve `index.html` plus its browser-executable HTML/CSS/JavaScript/assets.
- If using Node.js for development or evaluation, it must work on Node.js 20 LTS and `package.json` must include a `start` script.
- If using Go, `go.mod` must specify `go 1.24` or lower and work with `GOTOOLCHAIN=local`.
- If using Python, use Python 3.12-compatible syntax.
- Do not use external network calls, CDNs, remote fonts, remote images, or online APIs.

## Critical: Public Preview Submission Contract

Open Challenge result preview is static-only. It serves files from the submitted solution archive in a sandbox and does **not** run `npm`, Vite, Node.js, Go, Python, PHP, or any backend process.

- `index.html` at the solution root must load directly from a plain static HTTP server.
- Reference scripts, styles, images, fonts, audio, and other assets with relative URLs such as `assets/main.js` or `./styles.css`.
- Do not use root-absolute URLs such as `/main.ts`, `/src/main.ts`, `/assets/main.js`, or `/favicon.svg`; they escape the submission preview path.
- Do not reference `.ts`, `.tsx`, or `.jsx` files from `index.html`. Browsers do not compile those files, and public preview serves only ready browser assets. Compile them to `.js` or `.mjs`.
- Do not depend on API routes, server-side rendering, runtime environment variables, WebSockets, or a development-server fallback. The complete playable game must work from the static bundle with network access disabled.
- Do not try to fix preview by allowing `Origin: null` or weakening CORS. A compliant submission does not require cross-origin requests.

If you use Vite or TypeScript:

1. Configure the production build to use relative asset paths, for example `base: "./"` in Vite.
2. Run the production build before submission.
3. Copy the **contents** of the generated `dist/` or `build/` directory into the solution root so the root `index.html` is the built file and its compiled assets are included. The submission collector excludes directories named `dist/` and `build/`.
4. Confirm the submitted root `index.html` references compiled `.js`/`.mjs` files through relative paths and does not reference source `.ts`/`.tsx`/`.jsx` files.

Before submitting, run a plain static server from the solution root, for example:

```bash
python3 -m http.server 8000 --bind 127.0.0.1
```

Open `http://127.0.0.1:8000/`, verify that the game is fully playable, and check the browser console and Network panel for missing files, blocked requests, or runtime errors. Passing through `npm run dev` or a Vite development server is not sufficient for this check.

## Game Requirements

- Show a playable side view with an original vehicle, rolling terrain, and a camera that follows forward progress.
- Implement understandable vehicle motion with gravity, wheel or suspension response, traction, acceleration, braking or reverse, and airborne rotation or balance.
- Generate terrain deterministically from a visible seed. The same seed must produce the same initial terrain, vehicle state, and pickup placement.
- Consume fuel while driving and provide a clear way to collect or replenish it during a successful run.
- Display current speed, distance or score, fuel, and the run seed.
- End the run on a clear crash or out-of-fuel condition and provide a restart action that resets the complete simulation.
- Support keyboard controls and visible mouse/touch controls. The game must remain usable at a phone-width viewport.
- Prevent the default page behavior for active game keys or touch gestures where scrolling would interfere with play.

## Presentation and Gameplay Quality

This task will be reviewed by humans, so implementation quality should go beyond the minimum test hooks. Make the game look intentional, polished, and enjoyable to play.

- Prioritize visual quality: cohesive original art direction, readable typography, clear HUD spacing, strong contrast, and a deliberate color palette.
- Add meaningful animation and feedback for suspension travel, wheel rotation, acceleration, landings, fuel pickups, crashes, milestones, and restart.
- Make driving feel responsive without becoming chaotic. Players should understand how throttle, brake, momentum, slopes, fuel, and balance affect the run.
- Keep the UI technically solid: no overlapping HUD text, no layout jumps, responsive controls, accessible button states, and clear focus/pressed feedback.
- Use canvas, DOM/CSS, or lightweight in-repo artwork where useful, but do not depend on external networks or CDNs.
- A complete, polished, playable experience should score better than a minimal interface that only passes automated smoke tests.

## Technical Quality Expectations

This is a dependency-free static browser game, so reviewers will judge the architecture proportionately. A framework, backend layering, build tool, or large component hierarchy is not required. Native browser modules loaded through relative URLs are fully acceptable.

- Keep deterministic simulation logic separate from rendering and input orchestration. Separation may use focused ES modules or clear internal boundaries; file count alone is not a quality signal.
- Make the deterministic simulation logic independently testable. Deterministic engine tests should cover same-seed terrain, acceleration and braking, fuel and distance boundaries, terminal crash or out-of-fuel states, and restart behavior.
- Construct dynamic UI safely. Prefer `textContent`, `createElement`, `replaceChildren`, canvas drawing APIs, or equivalent safe APIs; avoid unsafe HTML injection with dynamic game or user-controlled values.
- Include browser-relevant defensive handling where the app has real failure boundaries: seed and action validation, missing required DOM hooks, unavailable optional browser APIs, repeated keyboard or touch input, large frame deltas, terminal states, and restart races.
- Clamp unreasonable frame deltas so returning to a backgrounded tab does not launch the vehicle or drain the whole fuel tank in one update.
- Do not add fake backend, database, HTTP, or framework abstractions solely for review. Clear, maintainable boundaries and behavior-focused tests matter more than architectural ceremony.

## Required DOM/Test Hooks

Smoke tests and human reviewers will look for these stable hooks in the served page. Hooks may wrap a canvas-rendered element; the relevant state still needs a visible HTML label.

| Hook | Required selector | Purpose |
|------|-------------------|---------|
| App root | `[data-testid="app-root"]` | Main game mount point |
| Game canvas | `[data-testid="game-canvas"]` | Playable scene or canvas wrapper |
| Vehicle | `[data-testid="vehicle"]` | Vehicle element or scene marker |
| Terrain | `[data-testid="terrain"]` | Terrain element or scene marker |
| Speed | `[data-testid="speed-display"]` | Visible