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. Produce an implementation-ready technical deliverable for [FILL IN: intended API users or development team]. Use only requirements confirmed in the input; do not invent domain rules, infrastructure choices, or operational guarantees.

The output must be organized as goal and stack, numbered acceptance criteria, edge cases, and how it is verified. Completion is achieved only when the proposed API can be implemented and tested against explicit, observable conditions, with every unconfirmed technical choice marked as `[FILL IN: item]`.

## Scope and given facts

In scope:

- A REST API for inventory management.
- API resource design, endpoint behavior, request and response contracts, validation, errors, persistence boundaries, and verification.
- An implementation or implementation-ready code structure appropriate to the confirmed stack.

Confirmed fact:

- The requested system is a REST API for inventory management.

Leave each unconfirmed item as a slot and add one line explaining what fills it:

- `[FILL IN: programming language, runtime, framework, and execution environment]` — fill with the approved implementation stack.
- `[FILL IN: inventory resources and fields]` — fill with the required entities, attributes, identifiers, and relationships.
- `[FILL IN: inventory business rules]` — fill with rules for stock changes, reservations, adjustments, low-stock handling, and concurrency.
- `[FILL IN: authentication and authorization model]` — fill with identity, roles, permissions, and token or session requirements.
- `[FILL IN: database and deployment target]` — fill with the persistence technology and hosting environment.
- `[FILL IN: testing, observability, and performance requirements]` — fill with required test coverage, logs, metrics, and measured thresholds.

Do not arbitrarily fill the inventory resources, stock rules, programming stack, database, or authentication model.

## Working rules

1. State the language, runtime, dependencies, framework, database, and execution environment as confirmed values only when supplied. Otherwise retain explicit `[FILL IN: ...]` slots. For every added dependency, state its version and licence; flag whether copyleft terms are acceptable for this project as `[FILL IN: copyleft acceptability]`.
2. Define each endpoint by method, path, purpose, authentication requirement, parameters, request schema, successful responses, validation errors, and relevant status codes. Use consistent naming and error formats.
3. Make inventory mutations safe under retries and concurrent requests. If idempotency is required by the business rules, specify the idempotency key and storage behavior; if it is not confirmed, mark the decision `[FILL IN: mutation idempotency policy]` rather than assuming it.
4. Write numbered acceptance criteria that are observable through API calls, database assertions, automated tests, or deployment checks. Do not claim security, scalability, availability, or performance without a defined verification method and measured result.
5. Specify edge-case behavior for missing identifiers, duplicate identifiers, malformed payloads, invalid quantities, insufficient stock, conflicting updates, unauthorized access, unavailable storage, repeated requests, and unsupported methods. If a case depends on an unconfirmed business rule, present both branches and label the condition determining which branch applies.
6. If the API touches personal data, ask which regime governs it: GDPR, CCPA/CPRA, or HIPAA. Also require `[FILL IN: retention period]` and `[FILL IN: deletion path]` to appear in the design itself, not merely in comments. If no personal data is confirmed, state that the applicability decision remains `[FILL IN: personal-data determination]`.
7. Preserve existing behavior only when an existing system is supplied. Otherwise mark `[FILL IN: existing behavior that must not break]`.
8. Separate implementation code from configuration, secrets, migrations, tests, and documentation. Never place credentials or invented environment values in code.

## Output structure

Produce the response in exactly this order:

1. **Goal and stack**
   - Restate the inventory API objective in one concise paragraph.
   - List the confirmed stack and all unresolved stack decisions.
   - Identify the API resources, actors, and business rules, using slots where absent.
   - Include architecture boundaries, persistence approach, authentication, and dependency licences.

2. **Numbered acceptance criteria**
   - Provide numbered, testable criteria covering resource operations, validation, authorization, stock consistency, error responses, persistence, documentation, and deployment.
   - Each criterion must identify the observable request, expected result, or verification artifact.
   - Do not invent quantities, latency targets, availability targets, or coverage percentages.

3. **Edge cases**
   - Use a table with columns: case, trigger, required behavior, status or error response, and unresolved decision.
   - Include the confirmed or slot-based rules for concurrency, retries, deletion, and unavailable dependencies.

4. **How it is verified**
   - Describe unit, integration, contract, authorization, migration, failure-recovery, and end-to-end tests.
   - Provide example requests and responses only when their fields and values are confirmed; otherwise use clearly labeled schema placeholders.
   - State how measured performance claims would be obtained, without claiming unmeasured results.

## Style rules

Use a hybrid style. Use itemized, tabular, and numbered form for the stack, endpoint contracts, acceptance criteria, edge cases, and verification steps. Use concise narrative paragraphs only for the goal, architecture rationale, and decisions that connect related implementation choices. Maintain a precise technical register. Avoid vague software clichés such as “seamless,” “robust,” “scalable by default,” and “best practice” unless each is replaced by a measurable, verified condition.

## 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 REST API design and implementation for inventory management, not a report, marketing asset, or unrelated application.
2. Confirm that the response uses the required order: goal and stack, numbered acceptance criteria, edge cases, and how it is verified.
3. Check that programming language, runtime, framework, dependencies, database, and execution environment are either supplied facts or `[FILL IN: ...]` slots.
4. Check that inventory resources, fields, stock rules, roles, authentication, and deployment assumptions are not filled arbitrarily.
5. Check every dependency entry for version and licence, and mark copyleft acceptability when it is unresolved.
6. Confirm that acceptance criteria are numbered and observable through a request, assertion, test, migration check, or deployment check.
7. Confirm that edge cases cover invalid input, missing resources, authorization failure, insufficient stock, concurrency, retries, storage failure, and unsupported methods.
8. Confirm that any personal-data handling includes the unresolved or confirmed governing regime, retention period, and deletion path in the design.
9. Remove any performance, security, availability, or compatibility claim that lacks a stated measurement or verification method.
10. Check that no fact has been added beyond the inventory-management API request without a slot or explicit evidence.
11. Check that no `[FILL IN: ...]` slot has been replaced with an invented value, especially for the stack, database, business rules, budget, schedule, or deployment.
12. Check that the work remains within API design, implementation, testing, and verification scope and has not drifted into unrelated product or organizational planning.