Inventory Tracker template

13. Edge cases

• Two people use the last unit at the same moment: one succeeds and the other is refused (R1).
• A move where the destination is the same as the source is refused.
• Receiving into an inactive location is refused, and so are use, move and adjust at an inactive location or on an archived item.
• A count is started at a location while another count there is open or submitted: refused, with a link to that count.
• An item with stock on order cannot be archived: "PO-0007 has 20 on order."
• An item's unit cost changes on receipt: the value of all its on-hand units changes with it (R6); the item page shows the previous cost in its history. Admins see a "Unit cost changes" table on the item page from Phase 1: date, old and new cost, and source (an edit, or the purchase order that changed it).
• A scanned barcode matches nothing: offer "Create item with this barcode" to admins and "No item has this barcode" to staff.

14. Seed data

Company "Brightside Cleaning Co.", a commercial cleaning business. Dates are relative to today; the examples assume today is Thursday, October 15, 2026.

People (emails firstname@brightside.example): Dana Reyes (admin, owner), Marco Silva (admin, operations), Priya Shah (staff, default location Van 1), Tom Bell (staff, default location Van 2).

Locations: Store room (STORE), Van 1 (VAN1), Van 2 (VAN2).

Suppliers: ProClean Wholesale (orders@proclean.example, lead time 5 days), Metro Paper Co. (sales@metropaper.example, lead time 7 days).

Stock value: Store room $805.20, Van 1 $197.30, Van 2 $130.55, total $1,133.05. Nitrile gloves are the only low item (7, reorder at 10); their low stock email has already gone out, so low_alerted is set; that email is not in the outbox, which starts empty.

Purchase orders:

• PO-0006, Metro Paper Co., created and sent by Dana 16 days ago and received by her 9 days ago into the Store room: trash bags 6 cases at $38.50 and paper towels 6 cases at $31.00, total $417.00.
• PO-0007, ProClean Wholesale, created and sent by Marco 2 days ago, expected in 5 days (Marco changed the default expected date when he sent it): nitrile gloves 20 boxes at $9.80 and vacuum bags 8 packs at $14.20, total $309.60, nothing received.

Movement history: an opening balance for each item and location 45 days ago (recorded by Dana), the PO-0006 receipt, moves by Marco 8 days ago from the Store room (1 case of trash bags to Van 1; 1 case of paper towels to Van 1 and 3 to Van 2), and "use" movements by Priya at Van 1 and Tom at Van 2 spread over the last 28 days, totalling glass cleaner 18, nitrile gloves 9, mop heads 6, disinfectant 5, microfiber cloths 4, vacuum bags 3, paper towels 3 and trash bags 2. Choose the opening balances so the quantities come out exactly as in the table; where a location starts empty its opening balance is 0 (opening balances are the only movements that may be 0).

15. Inventory tracker build plan

Send these prompts one at a time after pasting this file. Each phase ends with checks you can run by clicking through the app. Start the checks of Phases 1, 2 and 4 from a fresh load of the seed (the reset button); Phase 3's checks continue from the end of Phase 2's. Checks within a phase run in order on the same data.

Phase 1: Foundation

Using the Inventory Tracker blueprint above, build Phase 1 only.

1. Set up the data model from section 5 exactly, with a real database.
2. Add sign-in with the platform's built-in auth or Google sign-in limited to our company email domain. A signed-in email must match an active Person; anyone else sees "Ask an admin to add you."
3. Build People, Locations, Suppliers and Items (create, edit, photo upload, archive with R8 and R10), the Items list and the Item page (section 9, screens 1 and 2) without the Use, Move and Adjust buttons, enforcing R9 on the server.
4. Load the seed data from section 14, with dates relative to today, including the movement history.
5. Add a "sign in as" switcher, a "move the clock forward" control and a "reset to seed data" button (which also sets the clock back to the real time), all visible only in development.

When you're done, list what you built and anything in the spec you had to interpret.

Acceptance checks

• Items lists the eight seed items with their totals; nitrile gloves show a Low badge with "20 on order".
• Glass cleaner's page shows Store room 8, Van 1 3 and Van 2 2, and a movement history that adds up to 13.
• Signed in as Tom, unit costs and values appear nowhere, and a direct request for an item's cost is refused.
• Creating another item with SKU GC-32 is refused as a duplicate, and archiving the mop heads is refused because 18 are on hand.

Phase 2: Recording stock, alerts, labels and scanning

Using the Inventory Tracker blueprint above, build Phase 2 only.

1. Add Use, Move and Adjust (section 6) on the Item and Location pages, with R1, R2 and R4, all on the server.
2. Write the low stock email (section 10) to the outbox and build the Outbox screen.
3. Build the Labels screen and the Location page (section 12 and section 9, screen 3), and the Scan screen (screen 4).

When you're done, list what you built and anything in the spec you had to interpret.

Acceptance checks

• Signed in as Tom, using 2 bottles of glass cleaner at Van 2 leaves Van 2 at 0 and the total at 11, and puts exactly one low stock email each for Dana and Marco in the outbox; using 1 more at Van 1 sends no further email.
• Tom using 1 case of trash bags at Van 2 is refused with "Only 0 on hand at Van 2."
• Marco moving 4 bottles of glass cleaner from the Store room to Van 2 leaves Store room 4 and Van 2 4, with one move in the history showing both locations.
• Marco adjusting the mop heads in the Store room by minus 2 with the reason Damaged leaves 16 in total; Tom has no Adjust button, and a direct adjust request from him is refused.
• The label sheet prints item labels with QR codes three across; opening a label's link signed in as Priya shows the item with Use set to Van 1.
• Typing 012345678905 into the Scan screen opens glass cleaner, and typing VAN1 opens the Van 1 page.

Phase 3: Purchase orders

Using the Inventory Tracker blueprint above, build Phase 3 only.

1. Build Purchase orders and Reorder suggestions (section 7 and section 9, screen 5) with R3, R5 and R6.
2. Write the purchase order emails and the overdue reminder (section 10) to the outbox, with the daily job.

When you're done, list what you built and anything in the spec you had to interpret.

Acceptance checks (continue from the end of the Phase 2 checks)

• After the Phase 2 checks, Reorder suggestions list glass cleaner, 24 bottles from ProClean Wholesale at $102.00, and do not list nitrile gloves; creating the draft makes PO-0008.
• Sending PO-0008 emails orders@proclean.example with the line and the total and sets the expected date 5 days ahead.
• Receiving 20 boxes of gloves on PO-0007 into the Store room leaves 24 there and 27 in total, clears the Low badge, and marks PO-0007 partially received.
• Receiving 10 packs of vacuum bags on PO-0007 is refused with "Ordered 8, 0 received; you can receive up to 8."; receiving 8 marks PO-0007 received.
• Receiving all of PO-0008 takes glass cleaner to 34 and clears its Low badge; recording use until it is at 12 again sends a new low stock email.
• After a reset, moving the clock 6 days ahead and running the daily job puts one overdue email to Marco about PO-0007 in the outbox; running the job again adds nothing.

Phase 4: Counts and reports

Using the Inventory Tracker blueprint above, build Phase 4 only.

1. Build Counts (section 9, screen 6) with R7, and the count submitted email.
2. Build Reports and the movement export (section 9, screen 7, and section 12).

When you're done, list what you built and anything in the spec you had to interpret.

Acceptance checks

• After a reset, the value report shows Store room $805.20, Van 1 $197.30, Van 2 $130.55 and a total of $1,133.05.
• Priya starts a count at Van 1 and never sees expected quantities; she enters microfiber cloths 1, nitrile gloves 3 and the seed quantity for everything else, and submits.
• Dana sees two differences: microfiber cloths minus 1 (minus $18.00) and nitrile gloves plus 1 (plus $9.80); approving posts two count movements and Van 1's value becomes $189.10.
• In a second count at Van 1, using 1 disinfectant there before approval flags that line "Changed during count", and approval waits until Dana recounts or confirms it.
• The usage report for the last 30 days shows 18 bottles of glass cleaner used, and the movement export includes every movement with its type, person and any purchase order or count number.

16. Variations

• Days of cover: on hand divided by average daily use, with a warning when cover is shorter than the supplier's lead time.
• Pick lists for jobs, deducting stock when the job is completed.
• Lots and expiry dates for medical or food supplies.
• Check tools in and out to people (see the Equipment Tracker blueprint).
• Sync purchase orders and supplier bills to your accounting system.
• Several units per item (buy by the case, use by the bottle).

17. Build notes from our test build

We built this blueprint by sending the four phase prompts above, in order, to an AI builder (Claude, working in Type, with a fresh session for each phase that saw only this spec and the code so far), then checked every acceptance item in a real browser, resetting to the seed data before the checks of Phases 1, 2 and 4 (Phase 3's checks continue from Phase 2's, as section 15 says). Where a check says something is refused, the person saw the reason on screen and a direct request got an error with nothing changed. The label sheet was rendered for printing and one label's QR code was decoded and opened, emails were read on the Outbox screen, the daily job was run from the development control with the development clock, and the movement export was downloaded, parsed and matched against every item's history.

Result: 21 of 21 acceptance checks passed in one final browser run on a fresh database, plus 137 automated tests. The item-by-item results are in acceptance-results.json.

Gaps the build found, now fixed in this spec:

1. Sign-in with "the platform's built-in auth or Google sign-in" didn't say what to do on a host with no built-in auth. Section 4 now says Google sign-in limited to the company domain is enough, and every sign-in path, the development switcher included, runs the same check.
2. Sign-in was limited to "our company email domain", but no setting held the domain. The seed now names brightside.example, and an address from any other domain sees "Ask an admin to add you." like an unknown or inactive one.
3. Nothing protected the last admin or said what deactivating someone does. Admins can't demote or deactivate themselves, there is always an active admin, and deactivating someone ends their sessions.
4. The seed history could not produce the seed table: the Store room receives PO-0006's 6 trash bags and 6 paper towels yet must end at 5 and 2, while all use happens in the vans. The history now includes the moves that restock the vans 8 days ago.
5. The seed's history of "an opening balance for each item and location" didn't say what to record where a location starts empty. An opening balance of 0 is recorded too, and opening balances are the only movements that may have a quantity of 0.
6. PO-0007 was sent 2 days ago to a supplier with a 5-day lead time, which gives an expected date 3 days away, yet the seed says "expected in 5 days". The seed now says the expected date was changed by hand when it was sent.
7. PO-0006 had no creator or sent date, and the openings had no person. Dana created and sent PO-0006 16 days ago and recorded the opening balances and the receipt.
8. The gloves' earlier low stock email had "already gone out", which could put a seed email in the outbox and break Phase 2's check of exactly one low stock email each for Dana and Marco. The seed now keeps the outbox empty and records only low_alerted.
9. Dana and Marco had no default location, so Use had nowhere to start for them. Admins have none, and Use starts at a location chosen on the page (the label's or location page's), then the person's default location, then the Store room; Move's destination starts blank.
10. The outbox record had no timestamp, so the Outbox couldn't show when an email was written. The time each email was written is now recorded with it and shown on the Outbox.
11. No time zone was named for "today", expected dates and times on screen. The company time zone is a setting (UTC in the seed), and stored times stay UTC.
12. SKUs, location codes and barcodes had no format, though SKUs and codes go into label URLs. SKUs are letters, digits, dots, underscores and hyphens, unique regardless of case and stored in capitals; codes are up to 12 letters, digits or hyphens; barcodes have no spaces.
13. Nothing said which supplier and item fields are required. A supplier needs an email (orders are emailed to it) and a lead time of 0 to 365 days; every item needs a supplier and a unit cost, and an item with a reorder quantity of 0 is never suggested.
14. Screen 1 didn't say what the Low badge shows when nothing is on order, or whether archived items can be low. The badge reads "Low", followed by the on-order quantity (such as "20 on order") when anything is on order, and archived items are never low.
15. The location filter could mean items stocked anywhere or items stocked there. It shows the items with stock at that location, with their quantity there.
16. R9 listed what staff never see but not what they do see. Staff see supplier names, reorder points and reorder quantities.
17. The check's "direct request for an item's cost" named no endpoint, and the spec had no API. R9 now says every page and data response is shaped on the server, and any staff request for an admin-only page, action or field gets 403.
18. Archiving had no undo, and R8 didn't say whether a draft order blocks it. Draft orders don't block archiving (only sent and partially received ones count as on order), and an admin can restore an archived item.
19. A location could be deactivated while it was still someone's default location. That is now refused too.
20. R10 didn't say whether opening balances lock an item's unit. Any movement does, opening balances included, and the server refuses the change.
21. Section 13 says the item page shows the previous cost, but cost changes on receipt arrive in Phase 3 and nothing said where manual edits appear. Admins now see a "Unit cost changes" table from Phase 1, with each change's date, old and new cost and source (an edit or a purchase order).
22. R4 didn't say what happens when an admin edits the reorder point. The same rule runs after an edit: raising the total above the point clears low_alerted, and dropping the point to or below the total sends the email.
23. The development clock's controls weren't defined. It moves forward by days and hours, only "Reset to seed data" sets it back, and moving it doesn't sign anyone out.
24. Section 12 says a label opens for a signed-in person but not what happens to someone signed out. They sign in and land on the label's page.
25. Adjust didn't say whether the admin enters a change or a new quantity. It is a signed change (-2 removes two), zero is refused, and a negative change gets R1's message.
26. Nothing tied a reason to a direction, so "Found" could remove stock. Damaged and Lost only remove, Found only adds, and Correction and Opening balance go either way.
27. Only receiving into an inactive location was refused. Use, move and adjust are now refused at an inactive location and for an archived item.
28. "Every item at that location" didn't say whether items that have run out there are listed. Items with stock are listed with a one-tap Use; items that have had stock there but are at 0 are listed under "None left here".
29. The location page's "one-tap Use" didn't say how many units it records or whether it asks first. It records 1 unit with no confirmation, and a double tap is not recorded twice.
30. "Every admin" could include deactivated admins. Low stock and count emails go to every active admin.
31. Section 10 gave the low stock email's subject but no body. The body lists the quantity at each location, what is on order, the reorder quantity and supplier, and a link to the item, with no costs.
32. Nothing said which address the QR codes encode. They use the app's public address (an APP_URL setting), or the address the Labels page was opened on when it isn't set.
33. The label size, "the common 1 by 2⅝ inch address label size", gave no margins. The sheet now uses the Avery 5160 layout: 0.5 inch top margin, 3/16 inch side margins, 1/8 inch between columns.
34. The Labels screen had no controls. An admin ticks the items and locations to print (all active ones ticked by default) and the number of copies of each.
35. Scan didn't say what wins when a typed code could be a barcode, a SKU and a location code. It matches a label link, then a barcode, then a SKU, then a location code, ignoring case for SKUs and codes.
36. The camera depends on a barcode library or the browser's barcode detector, which iPhones lack. Where the browser can't read the camera, the Scan page says so and the text box still works.
37. Screen 5 put Purchase orders under admins, but anyone can receive. Staff now see the orders waiting for delivery and can open sent, partially received and received orders without costs; drafts and cancelled orders are admin-only.
38. R5 counts only sent orders as on order, so an item already on a draft was suggested again. It still is, marked "on draft PO-0008" and unticked.
39. Creating drafts from suggestions didn't say which suggestions or how numbers run. The admin ticks suggestions, the server rechecks them, and numbers run one above the highest; a cancelled order keeps its number.
40. "Edit lines" didn't say what can change. On a draft an admin changes quantities and unit costs, adds and removes lines (one line per item) and edits notes; the supplier can't change.
41. Section 7 gave the expected date a default but didn't say whether it can be changed. The admin can change it when sending, but not to a past date, and it is fixed once sent.
42. The purchase order email had no layout beyond its contents. It also gives the order date, asks the supplier to quote the PO number, and names the sending admin as the contact; the cancellation email lists the lines without prices.
43. The receive form wasn't described. Each line has a box that starts at 0, and one receipt goes into one location; to split a delivery, receive twice.
44. Nothing said what happens to the other lines of a receipt when one is refused. A receipt is all or nothing.
45. An overdue reminder "after the expected date" left the expected date itself unclear, and a check moves the clock 6 days for a 5-day order. An order is overdue from the day after its expected date in the company time zone.
46. The overdue reminder had nowhere to go if the admin who created the order was deactivated. It goes to every active admin.
47. A daily job "protected by a CRON_SECRET header" named no endpoint or header and no scheduler. It is /cron/daily, GET or POST, with the secret in Authorization: Bearer or X-Cron-Secret, called once a day by an outside scheduler, and turned off when CRON_SECRET isn't set.
48. The daily job "retries failed emails" with no rule. The job requeues every failed email on each run.
49. "Counts are blind: counters never see expected quantities" didn't say whether an admin counting is blind too. Nobody sees expected quantities on a count while it is open; admins see them only after it is submitted, and staff never do.
50. R7 didn't say which items a count lists. It lists every active item that has had stock at the location, those now at 0 included, and the counter can add an item found there.
51. Only an open count blocked a new count, so a submitted count awaiting review didn't, and approving both would correct the same stock twice. A submitted count blocks one too.
52. Flagging a movement "after the count started" didn't say what counts as after or whether a flag clears. Any movement of the item at that location recorded after the start flags the line, and the flag stays.
53. A flagged line that "must be recounted or confirmed by the approver" didn't say what each does. Recount replaces the counted number with what is there now; Confirm keeps the counted number because it was counted after the change; either covers changes up to that moment.
54. Screen 6 showed "variances" while R7 posts counted minus the current on hand, which differ when stock moved during the count. The difference on review is counted minus on hand now, valued at the current unit cost, with expected shown beside it.
55. Submitting didn't say whether every line needs a number. Every line does, a blank is not 0, and the counter can save partial work first.
56. Nothing said who can submit or approve. Anyone can submit; any admin can approve, including one who counted.
57. The count email's "(2 differences)" had no singular or zero form and no body. It reads "(1 difference)" and "(no differences)", goes to every active admin, and lists each difference in units and value.
58. The count status cancelled had no action. An admin can cancel an open or submitted count, and whoever started it can cancel it while it is open; nothing is posted.
59. Approval could post stock to an inactive location or change an archived item. Both are refused.
60. Count movements had no date or person. They are dated at approval and recorded against the approver.
61. The value reports didn't say whether an inactive location or an item's past supplier counts. By location covers active locations and any inactive one still holding stock; by supplier uses each item's current supplier.
62. Usage "over the last 30 or 90 days" didn't say what counts as usage or where the window ends. Only use movements count, and the window is the 30 or 90 days up to now on the app clock.
63. The export format left out how a move appears, the quantity's sign, the time format and spreadsheet safety. A move is two rows, quantities are signed, times are "YYYY-MM-DD HH:MM:SS" in the company time zone (named in the header), and text starting with = + - or @ gets a leading apostrophe.

What we did not test:

• Production sign-in. Google sign-in limited to the company domain was built, but every check used the development "sign in as" switcher.
• Sending email. Low stock, purchase order, overdue and count emails were logged in the outbox, not delivered.
• The daily job on a real scheduler. It was run from the development control and the cron endpoint with the development clock.
• Hosting. The checks ran on localhost, not on a public https address that phones can reach.
• Phone cameras and barcode scanners. Codes were typed into Scan, and one QR code was decoded by software from the rendered label sheet, not scanned from a printed label.
• Printing on real label stock. The sheet was checked as a one-page US Letter PDF with three labels across.
• Two people taking the last unit at the same moment. The build's own tests cover it with two database connections; no browser check did.
• Spec fixes that no acceptance check covers, such as restoring an archived item, cancelling a count, CSV formula guarding and a deactivated admin's reminders. The test build handles them through its own choices.