The production floor's pages - #18
Conversation
The personalisation is the reason the order is in Tensor at all - somebody
has to engrave "RAHUL & RANU" onto a plank - and the order page showed
none of it.
Each line now lists its custom attributes under the product, verbatim and
in the order the customer answered them. Verbatim matters: a storefront
personaliser labels its questions for humans ("STEP 4-First Name-:"), and
a question the backend does not recognise still has to reach the person
doing the work rather than being silently absent.
Shopify's own bookkeeping attributes - the underscore-prefixed
_gpo_product_group, _has_gpo - are kept but folded into a disclosure.
Someone scanning for a name should not have to read past a product-group
id to find it, but throwing them away would lose how the order was built.
Properties are matched to the product row by SKU: order_line_items and
the raw Shopify payload are two views of the same line, and SKU is the
only identifier both carry.
Requires the backend change that stops discarding these attributes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ggle The sample/live switch is gone. The Orders page asks Tensor-Core for `live` orders and nothing else, and Sync from Shopify remains the way to pull in anything new. A toggle was the wrong shape for this. Defaulting to seeded sample rows meant the first thing anyone saw was fabricated data that looks exactly like the real thing - and a list that might be showing invented orders is worse than an empty one, because nothing on screen says which it is. The empty state now points at Sync, which is the actual next step. The seeded orders are not deleted and remain reachable by id; they are simply not what this page is for. OrderSource keeps both values because the backend still supports both and the service is a typed client for that API rather than for one page's current use. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The screens between a Shopify order and a plate coming off a printer: Orders, Production Jobs, Batch Management and Machine Management, plus the model previews and the dialogs the floor works from. Orders - Order detail split into header, payment, fulfilment and line-item cards, with the customer's own customisation properties shown verbatim. - Tabs for Unfulfilled and Done. Pending is gone: it asked about PAYMENT and read zero on every order the store has ever taken, sitting where the useful question belongs. - Sync starts a background import and says so, rather than reporting a count from a request the browser abandons after five seconds. Batches - Colours and Jobs columns: the bed's filament as dots, and the orders on it as tags - a count answered the wrong question, and was never populated anyway. - Mark done opens a dialog listing each plank by order number. A plate comes off with three good and one warped, so finishing is a selection; the bed stays open until nothing on it is outstanding. - The plate preview renders 3MF with its real colours, and downloads with the filename the backend chose. Jobs and machines - Model preview with a generating state, a manual upload for a job whose render failed, and the customisation the job was built from. - Machine Management gains the printer queue board. Shared - Pagination on Orders, Jobs and Batches: 15/25/50/100 per page, page clamped rather than reset by an effect so filtering down from 68 pages while on page 40 lands on the last page that exists rather than an empty one. - One failure note across orders, jobs, batches and machines, with a tone: a bed that will not print reads as danger, while a printer whose last print failed - available, just wanting its plate cleared - reads as advice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W4ND3pFVaX7yGzWxZiHPYu
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|




The screens between a Shopify order and a plate coming off a printer.
Pairs with Optiminastic/Tensor-Core#12, which is the pipeline behind them.
Orders
with the customer's own customisation properties shown verbatim.
read zero on every order the store has ever taken - a tab nobody could use,
sitting where the useful question belongs. Partially fulfilled counts as
unfulfilled: part of an order having shipped still leaves a plank to make.
from a request the browser abandoned after five seconds.
Batches
it as tags. A count answered the wrong question, and was never populated.
off with three good and one warped, so finishing is a selection; the bed stays
open until nothing on it is outstanding, and a plank already done shows its
order number on green.
filename the backend chose.
Jobs and machines
Model preview with a generating state, a manual upload for a job whose render
failed, and the customisation the job was built from. Machine Management gains
the printer queue board.
Shared
clamped rather than reset by an effect, so filtering down from 68 pages while
on page 40 lands on the last page that exists instead of an empty one.
print reads as danger, while a printer whose last print failed - available,
just wanting its plate cleared - reads as advice.
🤖 Generated with Claude Code
https://claude.ai/code/session_01W4ND3pFVaX7yGzWxZiHPYu