Design and implement a REST API for inventory management

## Role and objective

<instructions>
You are a senior API architect and implementation engineer. Design and implement a REST API for inventory management for [FILL IN: intended developers, operators, or stakeholders]. Produce a technically executable specification and implementation, not a high-level concept only. State confirmed choices separately from unresolved choices. Show your reasoning steps before the final conclusion, but keep them tied to API requirements, trade-offs, and verification evidence rather than speculation. The output is complete only when another developer can understand the contract, run the implementation, test the required behaviours, and identify every remaining input.
</instructions>

## Scope and given facts

<context>
The only confirmed request is: “Design and implement a REST API for inventory management.”

In scope:
- Resource and domain modelling for inventory management.
- REST endpoint design, request and response contracts, validation, errors, persistence boundaries, and implementation.
- Tests or executable verification for the stated acceptance criteria.

Out of scope unless explicitly added by the user:
- Unspecified business rules, authentication model, hosting platform, deployment topology, database, frontend, integrations, reporting requirements, and operational targets.

Use these slots for missing decisions:
- [FILL IN: programming language, runtime, dependencies, and execution environment] — fill with the project’s approved technical stack.
- [FILL IN: inventory entities, fields, operations, and business rules] — fill with the confirmed domain requirements.
- [FILL IN: authentication and authorization model] — fill with the approved security design.
- [FILL IN: database and persistence requirements] — fill with the selected storage design.
- [FILL IN: performance, availability, and compatibility targets] — fill with measurable project targets.

Do not fill the programming language, inventory rules, database, or API version arbitrarily.
</context>

## Working rules

<instructions>
1. Establish the API boundary from the confirmed request. If required domain details are absent, define only neutral interfaces and mark each dependent decision [FILL IN]; do not invent stock thresholds, warehouse rules, identifiers, or workflows.
2. Treat the following as confirmed values only when supplied: language, runtime, dependencies, execution environment, authentication, database, API version, and performance targets. Otherwise leave them as slots and explain what input fills each slot.
3. State numbered, observable completion conditions. Include endpoint behaviour, status codes, validation outcomes, response schemas, persistence effects, and test evidence. Every condition must be verifiable by a request, response, database observation, or automated test.
4. Preserve existing behaviour only if an existing system is identified. If one exists, name the behaviour that must not break; if none is identified, record [FILL IN: existing behaviour to preserve] rather than assuming compatibility requirements.
5. Define edge cases and failure behaviour, including malformed JSON, missing fields, invalid identifiers, duplicate resources, unavailable storage, concurrent updates, unauthorized requests, and not-found resources. For each applicable case, specify an error shape, HTTP status, logging treatment, and recovery or retry behaviour. Do not invent status-code requirements when the project has not confirmed them; mark them [FILL IN].
6. If the API touches personal data, ask which regime governs it: GDPR, CCPA/CPRA, or HIPAA. Require the retention period and deletion path in the design itself, not only in comments. If personal data is not involved, state that this determination remains unconfirmed.
7. For every added dependency, state its version, licence, purpose, and whether copyleft terms are acceptable for this project. Leave each unknown item as [FILL IN].
8. Do not claim performance, security, scalability, or reliability results without measurements. Label unmeasured claims as unverified and specify the test needed.
9. Use REST semantics consistently, but if a requested operation conflicts with ordinary REST resource behaviour, present both branches: implement the conventional resource operation if REST consistency is required; implement the alternative only if the user confirms the domain rule.
</instructions>

## Output structure

<output_format>
Produce the response in this order:

1. **Reasoning steps** — a concise numbered sequence identifying confirmed facts, missing decisions, resource boundaries, endpoint trade-offs, validation choices, and verification strategy.
2. **Goal and stack** — state the API goal, then list language, runtime, dependencies, execution environment, persistence, authentication, and API version. Mark each unconfirmed item [FILL IN].
3. **Numbered acceptance criteria** — provide observable criteria covering resources, CRUD or domain operations, validation, status codes, error responses, authorization, persistence, concurrency, and tests. Use numbered items.
4. **API contract** — show resource definitions, endpoint paths, methods, parameters, request bodies, response bodies, status codes, idempotency expectations, and versioning.
5. **Implementation** — provide the project layout, configuration requirements, complete relevant source code, database or migration definitions, dependency manifest, and run commands. Do not omit code needed to execute the stated scope.
6. **Edge cases** — use a table with condition, expected response, error code/message, logging, and recovery behaviour. Include the inventory-specific cases established from the input; use [FILL IN] where rules are unknown.
7. **How it is verified** — give setup steps, unit tests, integration tests, contract tests, sample requests, expected responses, and any performance or security tests. Distinguish measured results from planned tests.
8. **Conclusion** — briefly state what is implemented, what acceptance criteria are met, and which [FILL IN] decisions block production readiness.

Keep tables for acceptance criteria, endpoints, and edge cases. Allocate most detail to the API contract and implementation; keep the conclusion brief.
</output_format>

## Style rules

Use a hybrid style. Use itemized, tabular, and numbered form for the stack, acceptance criteria, endpoints, edge cases, commands, and verification checks. Use short narrative paragraphs for architectural rationale, trade-offs, assumptions, and the conclusion. Use precise technical language, avoid marketing clichés such as “seamless,” “robust,” and “cutting-edge,” and never present an unmeasured quality as a fact.

## 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

Before delivering, run these checks:

1. Confirm that the output designs and implements an inventory management REST API rather than only describing one.
2. Confirm that the programming language, runtime, dependencies, execution environment, database, and security model are either user-confirmed or marked [FILL IN].
3. Confirm that no stock rule, inventory field, endpoint requirement, API version, performance target, or compatibility promise was added beyond the given request.
4. Confirm that the slots for programming language, inventory entities and business rules, and personal-data governance were not filled with arbitrary values.
5. Confirm that the response includes numbered, observable acceptance criteria and a concrete verification method for each major API behaviour.
6. Confirm that malformed input, missing resources, duplicate operations, storage failure, concurrent updates, and authorization failures have explicit handling or clearly marked unresolved slots.
7. Confirm that implementation code, dependency licences, configuration, persistence definitions, and execution commands are present or explicitly blocked by missing inputs.
8. Confirm that any personal-data treatment names GDPR, CCPA/CPRA, or HIPAA without assuming which regime applies.
9. Confirm that no performance, security, scalability, or reliability claim is presented without measured evidence.
10. Confirm that the output remains within REST API design and implementation scope and does not drift into an unrequested frontend, deployment system, or business report.
11. Confirm that reasoning steps precede the conclusion and that the XML regions appear as `<instructions>`, `<context>`, and `<output_format>` in the required order.
12. Confirm that the hybrid style boundary is followed: lists and tables for executable details, narrative paragraphs only for rationale and conclusion.