genval-github-integration[bot]
commented
16 hours ago Pre Refactor Summary
| Property | Value |
|---|---|
| Proposed Branch Name | feature/create-api-models |
| Total Files in Scope | 10 |
| Estimated Input Tokens | 11032 |
Details
Scope Patterns
```text .system/definitions/* .system/models/* ```
Files in Scope
| File | Estimated Tokens | |------|------------------| | .system/definitions/processes/sync-latest-analytics-and-order-data.md | 1376 | | .system/definitions/integrations/shopify.md | 1296 | | .system/definitions/integrations/google-analytics.md | 1123 | | .system/definitions/integrations/aws.md | 1004 | | .system/definitions/capabilities/eventing.md | 939 | | .system/definitions/capabilities/object-storage.md | 821 | | .system/definitions/capabilities/order-history.md | 737 | | .system/definitions/stacks/analytics-stack.md | 658 | | .system/definitions/capabilities/web-analytics-reporting.md | 600 | | .system/definitions/capabilities/configuration-management.md | 385 |
Processing Instructions
I need you to create or update programming standards as source code models for capabilities and processes I want to expose in a technical way, as models. I have already developed the definitions of all the capabilities, processes, and integrations located in
.system/definitions/. This task is focused on developing models for Capabilities and Processes, so I'm only showing you integration definitions so you get a sense of what kinds of model implementations we'll make later.Models may already be created, if they are you'll see them in
.system/models, you should only update them if needed. If you generate the same content as a file that already exists you don't need to return it in your output.Capabilities
For each capability I need you to build me an OpenAPI spec for the capability. Use REST conventions and try to include as much documentation as you can in the OpenAPI spec. Store it as YAML and use the following naming convention for the files:
.system/models/capabilities/{capability-code}/{capability-code}.openapi.yamlwhere the capability-code is the one used in the source file path you are using as input. When developing the OpenAPI spec you should try to abstract the API so it could integrate with any of the integrations that indicated they could implement the capability.Processes
We will group all the processes into a single AsyncAPI spec. Use asyncapi version
3.0.0. Note the asyncapi 3.0.0 uses channels, operations, messages, and schemas. Use your best judgement to figure out the right way to model all the processes and events using this spec.Process definitions can be found in the
.system/definitions/processes/folder.For each process, use the
{process-code}(you can get this from the process directory structure) as the operation name.For each event exposed by a process you should document them as operations with the
{event-code}as as the operation name. Useapplication/jsonfor contentType for messages.Document everything you can in the API spec, becuase we'll use this later to generate code.
Save the AsyncAPI spec to
.system/models/processes/processes.asyncapi.yamlin YAML format.Scope Patterns
Source Branch
main