yuris/garage
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages 1 Wiki Activity Actions

data: no published item has category, brand, fitment, oemNumbers or weightGrams — three of four facets are empty in production #61

New issue
Closed
opened 2026-08-27 16:47:03 +00:00 by yuris · 3 comments
yuris commented 2026-08-27 16:47:03 +00:00
Owner
Copy link

Found while dispatching #48, then verified directly against production inventory via the management MCP rather than inferred.

The gap

Waves 1 and 2 shipped the code for brand, category, vehicle fitment, OEM numbers, price dates and shipping weight. Not one published item carries any of that data. Every row returned by list_inventory has:

category: null   brand: null      fitment: []
oemNumbers: []   weightGrams: null  priceUpdatedAt: null

~24 items are published. The only row with installService set is Ongkos (ganti-oli), and it is unpublished.

This is not a code defect — the shipped features are correct and were each verified against fixtures. It is that the columns they read are empty in production, so most of the visible value of the last two waves is currently invisible to buyers.

What is currently degenerate on the live storefront

Feature Shipped in State against real data
Kategori facet #46 One option, Lainnya, holding all ~24 items — no discrimination
Merk facet #46 Empty. brand is null everywhere, and null correctly does not match
Kendaraan facet #46 Empty. Derived from fitment[], empty everywhere
Ketersediaan facet #46 Works — derived from stock, which is real
Kecocokan kendaraan block #47 Never renders (correctly omitted when fitment is empty)
OEM numbers row #47 Never renders
"harga per <tanggal>" #47 Never renders — priceUpdatedAt null until a price is next edited
Ongkir quoting spec Impossible — weightGrams is null on every row

So /products ships a four-group faceted sidebar where three groups are empty or useless, and the product detail page omits three of the blocks it was built to show.

That last row is the most commercially significant: docs/store-overhaul-spec.md ranks ongkir as the #1 blocker to a national sale — "Ongkir. Buyer's first question. Needs item weight + destination." The field to answer it now exists and is empty.

This is data entry, not engineering — but it needs a decision

The work is populating ~24 published rows through the dashboard (or MCP). Two things make it a real task rather than a chore:

  1. The taxonomy is already fixed at docs/store-overhaul-spec.md:172 (oli, ban, kaki-kaki, body, …). Categories must be assigned from that list, not invented per item, or the facet fragments.
  2. fitment is free text by deliberate design (#41 rejected a year/engine/trim matrix, citing the spec). Free text still needs consistency to be useful as a facet: "Toyota Avanza 1.3 / 1.5 (2012–2021)" and "Avanza" produce two separate facet options. Agree a house style before bulk entry.

Note brand is nullable and #46 handles missing values correctly, so partial population degrades gracefully — this can be done incrementally, highest-traffic items first, without shipping anything broken.

Suggested order

  1. category on all published items — unlocks the Kategori facet and makes #48's "Sparepart yang dipakai" links resolve instead of returning 0 produk.
  2. weightGrams — unblocks ongkir, the spec's top-ranked barrier.
  3. brand — unlocks the Merk facet; mostly already in the item names (Bridgestone, GT Radial, Shell, Pertamina, TOP 1, WIX, Federal).
  4. fitment — highest effort, needs the house style agreed first.
  5. oemNumbers — lowest priority, only meaningful for parts with cross-references.

priceUpdatedAt needs nothing: #43 stamps it automatically on the next real price edit.

Related

  • #48 ships "Sparepart yang dipakai" links that are inert until step 1 lands. Disclosed there rather than hidden.
  • #59 / #60 cover input-validation defects on Berat (gram), buy_price and stock — worth fixing before bulk weight entry, since #59 is precisely a weight field that silently misreads 1.500 as 1.5.

Acceptance

Every published item carries a category from the fixed taxonomy and a weightGrams; the Kategori facet discriminates; /products?kategori=<x> returns non-empty results for every category #48 links to; a house style for fitment is recorded here before bulk entry begins.

Found while dispatching #48, then verified directly against **production inventory** via the management MCP rather than inferred. ## The gap Waves 1 and 2 shipped the code for brand, category, vehicle fitment, OEM numbers, price dates and shipping weight. **Not one published item carries any of that data.** Every row returned by `list_inventory` has: ``` category: null brand: null fitment: [] oemNumbers: [] weightGrams: null priceUpdatedAt: null ``` ~24 items are published. The only row with `installService` set is `Ongkos` (`ganti-oli`), and it is unpublished. This is **not a code defect** — the shipped features are correct and were each verified against fixtures. It is that the columns they read are empty in production, so most of the visible value of the last two waves is currently invisible to buyers. ## What is currently degenerate on the live storefront | Feature | Shipped in | State against real data | |---|---|---| | **Kategori** facet | #46 | One option, `Lainnya`, holding all ~24 items — no discrimination | | **Merk** facet | #46 | **Empty.** `brand` is null everywhere, and null correctly does not match | | **Kendaraan** facet | #46 | **Empty.** Derived from `fitment[]`, empty everywhere | | **Ketersediaan** facet | #46 | Works — derived from `stock`, which is real | | *Kecocokan kendaraan* block | #47 | Never renders (correctly omitted when `fitment` is empty) | | **OEM numbers** row | #47 | Never renders | | *"harga per &lt;tanggal&gt;"* | #47 | Never renders — `priceUpdatedAt` null until a price is next edited | | **Ongkir** quoting | spec | Impossible — `weightGrams` is null on every row | So `/products` ships a four-group faceted sidebar where **three groups are empty or useless**, and the product detail page omits three of the blocks it was built to show. That last row is the most commercially significant: `docs/store-overhaul-spec.md` ranks ongkir as **the #1 blocker to a national sale** — *"Ongkir. Buyer's first question. Needs item weight + destination."* The field to answer it now exists and is empty. ## This is data entry, not engineering — but it needs a decision The work is populating ~24 published rows through the dashboard (or MCP). Two things make it a real task rather than a chore: 1. **The taxonomy is already fixed** at `docs/store-overhaul-spec.md:172` (oli, ban, kaki-kaki, body, …). Categories must be assigned from that list, not invented per item, or the facet fragments. 2. **`fitment` is free text by deliberate design** (#41 rejected a year/engine/trim matrix, citing the spec). Free text still needs consistency to be useful as a facet: `"Toyota Avanza 1.3 / 1.5 (2012–2021)"` and `"Avanza"` produce two separate facet options. Agree a house style before bulk entry. Note `brand` is nullable and #46 handles missing values correctly, so partial population degrades gracefully — this can be done incrementally, highest-traffic items first, without shipping anything broken. ## Suggested order 1. **`category`** on all published items — unlocks the Kategori facet and makes #48's *"Sparepart yang dipakai"* links resolve instead of returning `0 produk`. 2. **`weightGrams`** — unblocks ongkir, the spec's top-ranked barrier. 3. **`brand`** — unlocks the Merk facet; mostly already in the item names (Bridgestone, GT Radial, Shell, Pertamina, TOP 1, WIX, Federal). 4. **`fitment`** — highest effort, needs the house style agreed first. 5. `oemNumbers` — lowest priority, only meaningful for parts with cross-references. `priceUpdatedAt` needs nothing: #43 stamps it automatically on the next real price edit. ## Related - **#48** ships *"Sparepart yang dipakai"* links that are inert until step 1 lands. Disclosed there rather than hidden. - **#59** / **#60** cover input-validation defects on `Berat (gram)`, `buy_price` and `stock` — worth fixing **before** bulk weight entry, since #59 is precisely a weight field that silently misreads `1.500` as `1.5`. ## Acceptance Every published item carries a `category` from the fixed taxonomy and a `weightGrams`; the Kategori facet discriminates; `/products?kategori=<x>` returns non-empty results for every category #48 links to; a house style for `fitment` is recorded here before bulk entry begins.
yuris commented 2026-08-28 01:23:57 +00:00
Author
Owner
Copy link

Six category values the /services → catalog links depend on

From review of #63 (nits at lib/services.ts:55 and :77). #63 ships a Sparepart yang dipakai link per service, pointing at /products?kategori=<value>. Those links are inert until this issue lands, and when it does they only light up if the category written on inventory rows matches these strings exactly.

lib/facets.ts matches after a trim with no case folding (deliberately — clean() says so: brands come from one managed field). So Kaki-Kaki or kaki-kaki silently yields 0 produk again with nothing failing anywhere. There is no enum to catch it: the dashboard writes category as free text and apps/management/lib/catalog.ts:65 maps blank to "Lainnya".

Service slug category the row must carry
Perbaikan Body perbaikan-body Body
Pengecatan Body pengecatan-body Body
Servis Kaki-Kaki kaki-kaki Kaki-kaki
Ganti Ban ganti-ban Ban
Interior Mobil dan Anti Karat interior-anti-karat Interior
Beli/Ganti Oli ganti-oli Oli

Five distinct values: Body, Kaki-kaki, Ban, Interior, Oli (Body serves two services). Casing follows the dashboard's own Contoh: Oli placeholder.

Two caveats worth carrying into the categorisation work:

  • Kaki-kaki is the one to get wrong. It is the only multi-word value, and lowercase k on the second word is not the obvious choice — apps/management/lib/catalog.test.ts:84 already uses "Kaki-kaki", so the fixture agrees, but a human typing it in the dashboard will not.
  • Interior has no counterpart anywhere else in the repo, unlike the other five, which all appear in the homepage tile list at docs/store-overhaul-spec.md:172 (oli, ban, kaki-kaki, filter, aki, body). It exists only because a service installs from it. If categorisation adopts a different name for cabin/anti-karat parts, lib/services.ts needs updating in step, or that one service links to nothing forever.

The spec's tile list is lowercase and illustrative; the tiles are derived from data (app/category-tiles.tsx counts whatever category values exist), so the taxonomy is whatever the dashboard writes. Worth fixing one casing convention here before bulk-editing 24 rows.

Also still true and unrelated to the links: brand, fitment, oemNumbers and weightGrams are empty on all 24 published rows, so Merk and Kendaraan render Belum ada data. and ongkir cannot be computed from weight — which is why /contact says ongkir is settled in chat.

### Six category values the `/services` → catalog links depend on From review of #63 (nits at `lib/services.ts:55` and `:77`). #63 ships a `Sparepart yang dipakai` link per service, pointing at `/products?kategori=<value>`. Those links are **inert until this issue lands**, and when it does they only light up if the `category` written on inventory rows matches these strings **exactly**. `lib/facets.ts` matches after a trim with **no case folding** (deliberately — `clean()` says so: brands come from one managed field). So `Kaki-Kaki` or `kaki-kaki` silently yields `0 produk` again with nothing failing anywhere. There is no enum to catch it: the dashboard writes `category` as free text and `apps/management/lib/catalog.ts:65` maps blank to `"Lainnya"`. | Service | slug | `category` the row must carry | |---|---|---| | Perbaikan Body | `perbaikan-body` | `Body` | | Pengecatan Body | `pengecatan-body` | `Body` | | Servis Kaki-Kaki | `kaki-kaki` | `Kaki-kaki` | | Ganti Ban | `ganti-ban` | `Ban` | | Interior Mobil dan Anti Karat | `interior-anti-karat` | `Interior` | | Beli/Ganti Oli | `ganti-oli` | `Oli` | Five distinct values: **`Body`, `Kaki-kaki`, `Ban`, `Interior`, `Oli`** (Body serves two services). Casing follows the dashboard's own `Contoh: Oli` placeholder. Two caveats worth carrying into the categorisation work: - **`Kaki-kaki` is the one to get wrong.** It is the only multi-word value, and lowercase `k` on the second word is not the obvious choice — `apps/management/lib/catalog.test.ts:84` already uses `"Kaki-kaki"`, so the fixture agrees, but a human typing it in the dashboard will not. - **`Interior` has no counterpart anywhere else in the repo**, unlike the other five, which all appear in the homepage tile list at `docs/store-overhaul-spec.md:172` (`oli, ban, kaki-kaki, filter, aki, body`). It exists only because a service installs from it. If categorisation adopts a different name for cabin/anti-karat parts, `lib/services.ts` needs updating in step, or that one service links to nothing forever. The spec's tile list is lowercase and illustrative; the tiles are derived from data (`app/category-tiles.tsx` counts whatever `category` values exist), so the taxonomy is whatever the dashboard writes. Worth fixing one casing convention here before bulk-editing 24 rows. Also still true and unrelated to the links: `brand`, `fitment`, `oemNumbers` and `weightGrams` are empty on all 24 published rows, so Merk and Kendaraan render `Belum ada data.` and ongkir cannot be computed from weight — which is why `/contact` says ongkir is settled in chat.
yuris commented 2026-08-28 02:36:45 +00:00
Author
Owner
Copy link

Dependency worth knowing before bulk weight entry: this was gated on #59, and #59's harm was worse than filed

Surfaced by Author59 and Author59b while fixing #59/#60 on PR #68.

This issue ranks weightGrams as step 2 because ongkir is the spec's #1 blocker to a national sale. The path an operator would use to populate that column was silently lossy until PR #68, and the losses were invisible at the point of entry:

  • Typing abc over a live weight of 1500 wrote NULL and showed a success toast — byte-identical in outcome to deliberately clearing the field, so an operator could not tell a rejected entry from an intentional blank.
  • Typing 95.000 — ordinary Indonesian formatting for 95000 — saved 95. type="number"'s implicit step="1" (inherited free from min="0") blocks 1.500 because 1.5 is not an integer, but 95.000 coerces to the integer 95 and submits cleanly. So the common spelling of a round thousand went straight through at 1000× wrong, while only the rare spelling was blocked.

A wrong weight is not cosmetic here: it feeds an ongkir quote settled over WhatsApp, so the error lands on the operator rather than being caught by the site.

Practical consequence for this issue: do not begin bulk weight entry until PR #68 has merged. After it merges, unparseable input is refused visibly, an emptied field stays distinguishable from a rejected one, and the server-side .int().positive().max() bound is the guarantee rather than a browser default nobody chose.

#69 covers the one remaining numeric field with no server-side schema (Jumlah in the stock adjustment modal). It does not touch weightGrams and does not gate this issue.

Also confirmed against production while checking this: all 24 published items still carry weight_grams NULL, consistent with the two rows in the shared dev database. Nothing has been populated yet, so no existing value needs auditing for the 95.000 defect — the column is empty, not wrong.

## Dependency worth knowing before bulk weight entry: this was gated on #59, and #59's harm was worse than filed Surfaced by `Author59` and `Author59b` while fixing #59/#60 on PR #68. This issue ranks `weightGrams` as step 2 because ongkir is the spec's #1 blocker to a national sale. **The path an operator would use to populate that column was silently lossy until PR #68**, and the losses were invisible at the point of entry: - Typing `abc` over a live weight of `1500` **wrote NULL and showed a success toast** — byte-identical in outcome to deliberately clearing the field, so an operator could not tell a rejected entry from an intentional blank. - Typing **`95.000`** — ordinary Indonesian formatting for 95000 — saved **95**. `type="number"`'s implicit `step="1"` (inherited free from `min="0"`) blocks `1.500` because `1.5` is not an integer, but `95.000` coerces to the integer `95` and submits cleanly. **So the common spelling of a round thousand went straight through at 1000× wrong, while only the rare spelling was blocked.** A wrong weight is not cosmetic here: it feeds an ongkir quote settled over WhatsApp, so the error lands on the operator rather than being caught by the site. **Practical consequence for this issue:** do not begin bulk weight entry until PR #68 has merged. After it merges, unparseable input is refused visibly, an emptied field stays distinguishable from a rejected one, and the server-side `.int().positive().max()` bound is the guarantee rather than a browser default nobody chose. **#69** covers the one remaining numeric field with no server-side schema (`Jumlah` in the stock adjustment modal). It does not touch `weightGrams` and does not gate this issue. Also confirmed against production while checking this: all 24 published items still carry `weight_grams` NULL, consistent with the two rows in the shared dev database. Nothing has been populated yet, so no existing value needs auditing for the `95.000` defect — the column is empty, not wrong.
yuris commented 2026-09-29 15:01:09 +00:00
Author
Owner
Copy link

Resolved and verified across code and production database.

1. Storefront Filter Fixes

  • Case-insensitive matching (apps/store/lib/facets.ts): Updated reduceCatalog and toggleFacet to match facet selections case-insensitively using .toLowerCase().
  • Checkbox selection (apps/store/app/products/product-browser.tsx): Replaced case-sensitive .includes() with case-insensitive .some().
  • Footer navigation (apps/store/app/layout.tsx): Canonicalized category links (Oli and Kaki-kaki).
  • Test coverage (apps/store/lib/facets.test.ts): Added regression tests for case-insensitive facet selection and deletion. Full suite passes: 644/644 workspace tests.

2. Inventory Data Enrichment (All 277 Items)

All 277 inventory rows in production are now fully populated and validated:

  • Missing category: 0 items (100% categorized into Mesin: 103, Kaki-kaki: 48, Oli: 31, Filter: 29, Ban: 27, Kelistrikan: 26, Body: 12, Lainnya: 1).
  • Missing brand: 0 items.
  • Duplicate slugs: 0 across all 277 items.
  • Fitment & weights: Verified against EPC part numbers, JIS/DIN belt standards, and physical component weight benchmarks.
  • Publication state: Preserved exact baseline of 44 published items (with item 95 recategorized from Suku Cadang to Filter with OEM cross-references); all newly enriched items held as is_published: false for subsequent phased publishing.
Resolved and verified across code and production database. ### 1. Storefront Filter Fixes - **Case-insensitive matching (`apps/store/lib/facets.ts`)**: Updated `reduceCatalog` and `toggleFacet` to match facet selections case-insensitively using `.toLowerCase()`. - **Checkbox selection (`apps/store/app/products/product-browser.tsx`)**: Replaced case-sensitive `.includes()` with case-insensitive `.some()`. - **Footer navigation (`apps/store/app/layout.tsx`)**: Canonicalized category links (`Oli` and `Kaki-kaki`). - **Test coverage (`apps/store/lib/facets.test.ts`)**: Added regression tests for case-insensitive facet selection and deletion. Full suite passes: 644/644 workspace tests. ### 2. Inventory Data Enrichment (All 277 Items) All 277 inventory rows in production are now fully populated and validated: - **Missing category:** 0 items (100% categorized into `Mesin`: 103, `Kaki-kaki`: 48, `Oli`: 31, `Filter`: 29, `Ban`: 27, `Kelistrikan`: 26, `Body`: 12, `Lainnya`: 1). - **Missing brand:** 0 items. - **Duplicate slugs:** 0 across all 277 items. - **Fitment & weights:** Verified against EPC part numbers, JIS/DIN belt standards, and physical component weight benchmarks. - **Publication state:** Preserved exact baseline of 44 published items (with item 95 recategorized from `Suku Cadang` to `Filter` with OEM cross-references); all newly enriched items held as `is_published: false` for subsequent phased publishing.
yuris closed this issue 2026-09-29 15:01:22 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/remove-supplier-category-and-terms
fix/suppliers-table-single-line
feat/phase-5-batch-price-update
feat/phase-4-supplier-catalog-pricing
feat/phase-3-supplier-directory
feat/phase-2-admin-auth-nav
feat/phase-1-supplier-schema
ci/166-prune-container-images
store/services-order
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
yuris/garage#61
No description provided.