james
e457339847
The merge creates the brand capability (two requirements) and extends the catalog browse requirement with the brand filter, the sales sort and a real sold count. openspec validate --all --strict stays green at 14 specs. With every box now checked, docs/TBD-migrate-wave.md is deleted, as its own instructions require. Its two durable notes move to the README instead of disappearing with it: - `nuxt build` does not typecheck, so a green build is not the type gate the verification section claimed. AGENTS.md told me to treat it as one, which is why waves 1-5 over-reported "builds pass" as evidence. - the list of what stays deliberately mock: addresses, coupons, favourites, account stats, the seckill/collective/integral pages, reviews, and the fixed-data adapter itself, which the adapter spec requires for rollback. The README's verification block also gains the real test count (29, not 16).
29 lines
1.7 KiB
Markdown
29 lines
1.7 KiB
Markdown
# brand Specification
|
|
|
|
## Purpose
|
|
The product brand registry: a bilingual, admin-managed list of manufacturers that products reference, shoppers filter listings by, and the storefront shows on a product.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Public brand list
|
|
`GET /api/brands` SHALL return the brands without authentication, ordered by their stored position, each with an id, slug and bilingual name. Products SHALL carry a nullable `brand_id` referring to that list, and `GET /api/products` SHALL accept a `brand_id` filter that composes with the existing category, shop and keyword filters.
|
|
|
|
#### Scenario: filter a listing by brand
|
|
- **WHEN** a shopper filters the catalog by a brand
|
|
- **THEN** only that brand's published products are returned, and the filter combines with a category filter rather than replacing it
|
|
|
|
#### Scenario: a product without a brand
|
|
- **WHEN** a product has no brand assigned
|
|
- **THEN** it is still listed and its `brand_id` is null rather than pointing at an invented brand
|
|
|
|
### Requirement: Brand management
|
|
A platform admin SHALL replace the brand list with `PUT /api/admin/brands`, which validates each entry, applies as one transaction and reindexes positions from the submitted order; the write SHALL require the `platform_admin` role. Each entry SHALL carry a slug and non-empty `en` and `zh` names, and a rejected list SHALL leave the stored brands untouched.
|
|
|
|
#### Scenario: replace round-trips
|
|
- **WHEN** an admin replaces the brands and then reads them publicly
|
|
- **THEN** the public list matches, in the submitted order
|
|
|
|
#### Scenario: incomplete bilingual name is refused
|
|
- **WHEN** an admin submits a brand with only `en` text
|
|
- **THEN** the request fails and the stored brands are unchanged
|