Archive add-favorites and split-catalog-into-product-category-brand

- Sync favorites capability spec and frontend-mall live-favorites
  requirement into openspec/specs/
- Split catalog spec into new category and product capability specs;
  remove now-empty catalog spec
- Move both completed changes to openspec/changes/archive/
- Ignore .superpowers/ scratch directory

openspec/changes/archive/2026-09-22-add-favorites/specs/favorites/spec.md

@@ -0,0 +1,34 @@
+## ADDED Requirements
+
+### Requirement: Customer-owned favorite targets
+A favorite SHALL belong to one authenticated customer and reference exactly one product or one shop. The database SHALL enforce target foreign keys and no more than one favorite per customer and target. Customers SHALL never read or mutate another customer's favorites.
+
+#### Scenario: target shape is enforced
+- **WHEN** a favorite row would reference both a product and a shop or neither target
+- **THEN** the database rejects the row
+
+#### Scenario: ownership filters every operation
+- **WHEN** one customer lists or removes favorites
+- **THEN** only that customer's rows are read or changed
+
+### Requirement: Idempotent favorite mutation
+An authenticated customer SHALL add or remove a published product belonging to an active shop or an active shop as a favorite. Repeating the same add SHALL return the existing favorite without creating a duplicate, and repeating the same remove SHALL succeed with the target still unfavorited. A missing or unavailable target SHALL return 404 on add.
+
+#### Scenario: repeated product add
+- **WHEN** a customer adds the same published product twice
+- **THEN** both requests succeed and exactly one favorite row exists
+
+#### Scenario: repeated shop removal
+- **WHEN** a customer removes the same shop favorite twice
+- **THEN** both requests succeed and no favorite row remains
+
+### Requirement: Paginated target-aware favorite listing
+An authenticated customer SHALL list favorites filtered by product or shop kind, with optional target ID and pagination. Each result SHALL be a discriminated favorite containing current public target summary data; product summaries SHALL include the current lowest active SKU price and currency. Unpublished products, products of inactive shops, and inactive shops SHALL be absent, and `total` SHALL count only visible results.
+
+#### Scenario: buyer center loads product favorites
+- **WHEN** a customer lists product favorites
+- **THEN** each visible row contains product card data without additional per-product requests
+
+#### Scenario: unavailable target is hidden
+- **WHEN** a favorited product becomes unpublished
+- **THEN** it is absent from the favorite list and total until it becomes publicly available again

openspec/changes/archive/2026-09-22-add-favorites/specs/frontend-mall/spec.md

@@ -0,0 +1,20 @@
+## ADDED Requirements
+
+### Requirement: Live customer favorites
+The mall SHALL use the shared selected API adapter for product and shop favorite state. Product and store detail controls SHALL load persisted state, require customer authentication, prevent duplicate in-flight mutations, and survive reloads. The buyer-center favorites page and dashboard preview/counts SHALL render paginated live favorite results and remove targets through the API instead of reading `MOCK_FAVORITES` or mutating local-only state.
+
+#### Scenario: product favorite survives reload
+- **WHEN** a signed-in shopper favorites a product and reloads its detail page
+- **THEN** the favorite control remains selected from backend state
+
+#### Scenario: anonymous favorite requires sign-in
+- **WHEN** a signed-out shopper uses a product or store favorite control
+- **THEN** the mall sends the shopper to sign in with the current detail URL as the return destination
+
+#### Scenario: remove from buyer center
+- **WHEN** a shopper removes a product or shop from the favorites page
+- **THEN** the API state, visible list, dashboard preview, and visible count reflect the removal without fixture mutation
+
+#### Scenario: fixed adapter remains functional
+- **WHEN** the favorites domain is configured to fixed data
+- **THEN** detail controls and buyer-center favorite flows behave deterministically through the same shared client methods