feat: establish auth listing and image vertical slices
Includes MFA-capable authentication, session and CSRF security, password recovery, listing lifecycle and ownership rules, inventory image metadata, local ImageStorage, migrations, tests, and implementation status documentation. Verification: npm test (62 passing) and integration suite (14 passing).
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
# Architecture Decision: Provider Product Mapping
|
||||
|
||||
## Status
|
||||
Accepted
|
||||
|
||||
## Decision
|
||||
Provider mappings are first-class Product-level records.
|
||||
|
||||
During new Product creation, configured pricing providers are searched for candidate matches. The admin confirms the appropriate match, refines a search manually when necessary, or marks a provider Not Applicable.
|
||||
|
||||
Mappings are reused by all physical Inventory Items belonging to the Product.
|
||||
|
||||
## Mapping types
|
||||
|
||||
- `PRODUCT`: specific canonical provider/catalog entity.
|
||||
- `SEARCH`: provider search/query definition.
|
||||
|
||||
eBay supports both mapping types.
|
||||
|
||||
## Rationale
|
||||
|
||||
A provider relationship describes the identity of the Product, not a particular physical copy. Keeping it at Product level avoids repeating provider discovery for every copy while supporting multiple conditions and future copies.
|
||||
|
||||
A search mapping is necessary for providers such as eBay where a canonical product may not exist for every collectible or merchandise item.
|
||||
Reference in New Issue
Block a user