Files
vmall/openspec/specs/address-book/spec.md
T
james bcd97ab48f docs(openspec): fix group-buying archive scenario and address-book purpose
Rename the group-buying "Order lifecycle" cancel scenario to the exact name
the current order spec uses; a MODIFIED requirement replaces the whole block,
so the old name made archive refuse to drop the existing scenario.

Replace the placeholder Purpose in the archived address-book spec, which the
wave-7 archive left as TBD and strict validation rejected.

openspec validate --all --strict is green again.
2026-09-18 11:54:44 +00:00

1.7 KiB

address-book Specification

Purpose

Let a signed-in customer keep a reusable book of shipping addresses: owner-scoped list, create, update and delete, plus exactly one database-enforced default per customer. Introduced when the mall's fixture address book was replaced with live data (replace-mock-api-wave-7); checkout still submits its own inline shipping-address snapshot rather than a saved address id.

Requirements

Requirement: Saved shipping addresses

A customer SHALL be able to list, create, update and delete their own shipping addresses through the API. Every address operation SHALL be scoped to the authenticated customer; operating on another user's address SHALL return 404. Non-customer roles SHALL be rejected with 403.

Scenario: manage own addresses

  • WHEN a customer creates, updates or deletes an address they own
  • THEN the change persists and appears in their address list

Scenario: cross-user access

  • WHEN a customer requests an address id owned by a different user
  • THEN the API returns 404 as if the address did not exist

Requirement: Single default address

Each customer SHALL have at most one default address, enforced by the database. The first saved address SHALL become the default. Setting a new default SHALL unset the previous one atomically. Deleting the default address SHALL promote the most recently created remaining address to default.

Scenario: switch default

  • WHEN a customer marks address B as default while address A was default
  • THEN B is default and A is not, after one request

Scenario: delete the default

  • WHEN a customer deletes their default address and other addresses remain
  • THEN the most recently created remaining address becomes the default