Design and implement a REST API for inventory management

## Role and objective

You are a software architect and developer. Design and implement a REST API for inventory management for [FILL IN: intended users or consuming systems]. Produce a technically executable solution covering the API contract, implementation, configuration, validation, error handling, tests, and verification instructions. Use only requirements confirmed in the input; treat every unresolved design choice as a slot or state the assumption explicitly for confirmation. The output is complete only when the implementation can be run in [FILL IN: execution environment] and each numbered acceptance criterion is demonstrably verified without breaking [FILL IN: existing behaviour that must remain compatible].

## Scope and given facts

In scope:

- A REST API for inventory management.
- The API design and its implementation.
- Resource definitions, endpoints, request and response formats, validation, persistence, and operational failure behaviour, where required to make the API executable.
- Tests and instructions for verifying the implementation.

Confirmed fact: the requested subject is an inventory management REST API.

Leave the following unresolved unless the input or a supplied source confirms them:

- [FILL IN: programming language and runtime]
- [FILL IN: framework]
- [FILL IN: database and schema requirements]
- [FILL IN: inventory resources and fields]
- [FILL IN: authentication and authorization model]
- [FILL IN: API versioning and compatibility requirements]
- [FILL IN: deployment and execution environment]
- [FILL IN: existing behaviour that must not break]

Add one line after the unresolved-items list: “Fill each slot with the project’s confirmed requirement, environment value, or compatibility constraint; do not choose a value merely to complete the example.” Do not invent product names, stock thresholds, identifiers, business rules, users, or operational volumes.

## Working rules

1. State the language, runtime, dependencies, database, and execution environment as confirmed values or `[FILL IN: item]` slots. For every added dependency, state its licence and whether copyleft terms are acceptable for this project.
2. Define the inventory domain only from confirmed requirements. If stock is represented as a current quantity, use that model; if movement history is required, define transactions and reconciliation separately. Do not infer one branch from the other.
3. For each endpoint, specify the HTTP method, path, authentication decision, required inputs, validation rules, success status, response schema, and documented error statuses. If authentication is not supplied, mark it `[FILL IN: authentication and authorization model]` rather than treating the API as public.
4. Make completion observable through numbered acceptance criteria. Each criterion must identify an endpoint, data rule, response, security property, test, or operational outcome that can be checked.
5. Cover edge cases including unknown item identifiers, duplicate identifiers, missing fields, invalid quantities, negative stock where prohibited, concurrent updates, stale versions, malformed JSON, unsupported media types, unauthorized access, unavailable persistence, and duplicate requests. Include the exact error-message policy and exit codes where a command-line process is involved.
6. Define failure behaviour: return structured errors for client failures, avoid exposing secrets or internal traces, use transactions for atomic inventory changes, and specify recovery or retry behaviour only where the selected storage and deployment design supports it.
7. Preserve `[FILL IN: existing behaviour that must not break]`. If no existing system is identified, keep the slot and state that compatibility cannot be assessed.
8. If the API touches personal data, ask which regime governs it—GDPR, CCPA/CPRA, or HIPAA—and require the retention period and deletion path to appear in the design, not only in comments. If it does not touch personal data, state that this determination requires confirmation.
9. Do not claim performance, scalability, security, or reliability results unless measured. Label unmeasured targets as `[FILL IN: measurable target]` and provide a test method.

## Output structure

Organize the response in this order:

1. **Goal and stack** — State the inventory API objective, confirmed technology stack, unresolved slots, assumptions requiring confirmation, and the execution command.
2. **Numbered acceptance criteria** — List testable criteria for API availability, resource behaviour, validation, persistence, authentication, authorization, error responses, concurrency, documentation, and tests. Include only criteria supported by confirmed requirements; mark unresolved criteria with slots.
3. **API contract and implementation** — Provide the resource model, endpoint table, schemas, status codes, error format, project structure, configuration, migrations, implementation code, and tests. Do not fill unresolved inventory fields or business rules with invented values.
4. **Edge cases** — For each listed failure condition, specify the triggering input, expected HTTP response or process exit code, safe error body, persistence effect, and recovery behaviour.
5. **How it is verified** — Give setup steps, dependency installation, database preparation, test execution, API smoke tests, and acceptance-criteria mapping. Include measurable performance tests only when a target and measurement method are confirmed.

Use tables for the endpoint contract, acceptance criteria, edge cases, and verification mapping. Allocate enough detail to make the code runnable, but do not produce unrelated frontend, analytics, or deployment work unless the input confirms it is required.

## Style rules

Use a hybrid style. Use itemized, compact sections for the stack, acceptance criteria, endpoint contract, edge cases, commands, and verification mapping. Use short narrative paragraphs only for the objective, assumptions, design rationale, and limitations. Maintain a precise engineering register. Avoid generic claims such as “robust,” “scalable,” or “secure by design” unless each is tied to an observable implementation or measured result.

## 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 designed and implemented inventory management REST API, not a general inventory explanation or an unrelated application.
2. Confirm that the language, runtime, dependencies, database, execution environment, inventory model, and authentication decisions are either supplied facts or clearly marked `[FILL IN: item]`.
3. Check that no invented product name, stock threshold, field, endpoint rule, user role, performance figure, or compatibility requirement has been presented as confirmed.
4. Check that every arbitrary slot remains unfilled and has an instruction explaining what project information must replace it.
5. Confirm that the output contains the required order: goal and stack, numbered acceptance criteria, edge cases, and how it is verified.
6. Check that every endpoint has inputs, validation, success response, error behaviour, and authentication treatment, or an explicit unresolved slot.
7. Confirm that invalid quantities, unknown identifiers, duplicate requests, concurrent updates, malformed requests, unauthorized access, and persistence failure have distinct handling.
8. Check that implementation code, migrations, configuration, and tests agree on resource names, fields, status codes, and error schemas.
9. Confirm that personal-data handling asks for the governing regime and places retention and deletion in the design when applicable.
10. Check that dependency licences and copyleft acceptability are addressed for every added dependency.
11. Confirm that existing behaviour is not silently changed and that the compatibility slot is preserved when no baseline is supplied.
12. Remove any performance or security claim that lacks a measurement, evidence, or an explicitly labelled target.
13. Confirm that no work has drifted into frontend design, analytics, or deployment beyond the confirmed REST API scope.