An inventory screen can show the right total while hiding how it got there. Before building, define each stock change as a separate adjustment and write the cases that must pass. This guide uses three fictional products and does not claim that PickByTask tested a live Lovable app.
Lovable currently describes building applications from plain-language instructions and offers backend and integration routes. Its Supabase documentation covers a connected database workflow. That supports prototyping, but does not prove that generated stock logic, permissions or audit history are correct. Lovable product information
Contents — jump to a section
Separate the product from its adjustments
Give each product a stable ID, name and unit. Store opening stock as the first adjustment rather than an editable total. Every later row needs a unique request ID, quantity change, reason, actor and timestamp. Calculate current stock from accepted adjustments, or update a cached total within the same protected operation.
Use Lovable for a disposable inventory prototype, then verify every stock change against an append-only adjustment history before importing real products.
Copy a bounded prototype prompt
Create a fictional inventory prototype with three products.
Record opening stock as an adjustment row.
Every later change needs a unique request ID, signed quantity, reason and actor.
Reject a change that would make stock negative.
Repeating the same request ID must return the original result without changing stock.
Users may add a correcting adjustment but may not overwrite history.
Show unresolved status when saving fails. Use no real products or customer data.The prompt describes expected behaviour, not a database guarantee. A qualified developer must review schema, row access and server-side operations before production. Lovable's Supabase documentation explains the current connection route; correct configuration remains the builder's responsibility.
Visit Lovable ↗Run six adjustment cases
- Create opening stock of 10 units and verify the history contains one +10 row.
- Record a sale of 3 and a return of 1. The displayed stock should be 8 and the history should preserve all three rows.
- Try an adjustment of -9 from stock 8. Reject it without adding a misleading accepted row or changing the total.
- Submit the same -2 request ID twice. Stock should decrease once, and both responses should refer to the same accepted adjustment.
- Correct a mistaken -3 with a new +3 row and a reason. The original row must remain visible.
- Use a second test role to read and change stock. Confirm that both actions follow the intended permissions and record the actor.
After each case, compare the visible total with the sum of accepted rows. Also simulate a lost response: a retry must not create a second change.
Decide whether to continue
The fictional example passes only when the total reconciles, negative stock is blocked, duplicate requests are idempotent and corrections preserve history. Reset and rerun after changes to schema, authentication or adjustment logic.
If reconciliation fails, freeze edits and count stock manually from the last trusted record. Keep a dated correction sheet until a developer repairs the operation and checks existing rows. Barcode scanning, purchasing, valuation, tax, multi-location transfers, offline use and legal retention need separate requirements and tests.
Product and Supabase documentation were inspected on 27 September 2026. This is a test plan, not a production-readiness, accounting or security certification.