Consistency Review

Showing 3 of 5

1. 1 Load existing user stories for the target entity/package

   Before writing a new user story or function model, query the API or read the package.yml to see what stories already exist. Understand the established patterns: how actors interact, what fixture data is used, how BDD scenarios are structured.

   # API query
   curl http://localhost:5000/api/packages/{category}/{name}/stories
   
   # Or read directly
   cat .sbx/workspace/packages/{category}/{name}/package.yml
   # Look at: user_stories section

2. 2 Identify reusable patterns in existing stories

   Note naming conventions for scenarios, fixture field names, step action verbs, and error handling patterns. Check if similar flows exist that can be extended rather than duplicated. Look for established actor-system interaction patterns.

   # Existing pattern in R2 storage:
   #   scenario: connect-to-bucket
   #   steps use: action (verb) + input (fixture ref) + expected (assertion)
   #   fixture refs: <<fixture:valid-config.endpoint>>
   #
   # New story for same package should follow same structure

3. 3 Check function model naming against existing exports

   Load the package trace to see existing exported types and functions. New functions should follow the same naming conventions (e.g., verb+noun for methods, noun for types). Avoid introducing synonyms for existing concepts.

   # API query
   curl http://localhost:5000/api/packages/{category}/{name}/trace
   
   # If existing functions use: Connect, Disconnect, ListBuckets
   # New function should use: UploadObject (not AddObject or PutObject)
   # Follow the established verb vocabulary

• Package stories API
• Package trace API
• SBX model browser

• external Brad Frost Design System Governance
• external ISO 42010 Architecture Description