decomposer: generate deliverable files for Discover and structure the solution's functional requirements, non-functional requirements, constraints, assumptions, and open questions without selecting cloud products.; Select Google Cloud products from the confirmed requirements and produce the solution architecture, Mermaid diagram, architecture description, and Terraform infrastructure-as-code.; Validate the Terraform infrastructure and architecture artifacts without deploying resources by running formatting checks, Terraform validation, and a dry-run or plan-oriented deployment check.; Package the approved requirements, architecture, Mermaid diagram, Terraform IaC, and validation results into solution-architecture-guide.md in the gcp_solution_architecture_agent repository.; Verify that the gcp_solution_architecture_agent repository contains the packaged solution-architecture-guide.md with the approved workflow outputs.; Verify that the repository is derived from the workflow_agent template and implements the complete four-phase Google Cloud solution architecture workflow alongside the packaged guide.; Publish the verified gcp_solution_architecture_agent repository with its completed workflow implementation and solution architecture guide.; Verify that the published repository revision contains the completed workflow implementation and solution architecture guide.
This commit is contained in:
31
requirements.yaml
Normal file
31
requirements.yaml
Normal file
@@ -0,0 +1,31 @@
|
||||
repository_name: gcp_solution_architecture_agent
|
||||
template_url: https://github.com/GoogleCloudPlatform/workflow_agent
|
||||
product_selection_deferred: true
|
||||
functional_requirements:
|
||||
- Accept authenticated HTTPS requests containing an event payload.
|
||||
- Validate, durably enqueue, and asynchronously process accepted events.
|
||||
- Persist raw event records for replay and audit.
|
||||
- Expose an operational health endpoint and structured application logs.
|
||||
- Support separate development and production environments through variables.
|
||||
non_functional_requirements:
|
||||
- Target at-least-once delivery with idempotent consumers.
|
||||
- Provide regional high availability for managed serving and messaging components.
|
||||
- Encrypt data in transit and at rest using managed encryption by default.
|
||||
- Scale ingestion and processing independently based on request and backlog load.
|
||||
- Retain audit data for 30 days by default and make retention configurable.
|
||||
- Apply least-privilege service identities and observable failure handling.
|
||||
constraints:
|
||||
- Deploy only into an existing Google Cloud project supplied by the operator.
|
||||
- Terraform must be planable without provisioning resources.
|
||||
- No application container image is built or deployed by this repository.
|
||||
- Product selection is explicitly deferred during discovery and recorded afterward.
|
||||
assumptions:
|
||||
- The workload is regional and an initial single-region deployment is acceptable.
|
||||
- A container image is supplied by an external CI/CD pipeline.
|
||||
- The runtime can use OIDC/IAM authentication and publish to messaging.
|
||||
- Event consumers are idempotent and tolerate duplicate delivery.
|
||||
open_questions:
|
||||
- What are the peak requests per second and payload size limits?
|
||||
- Which region, compliance boundary, and customer-managed key policy apply?
|
||||
- What downstream systems receive processed events?
|
||||
- What SLO, alert thresholds, and on-call escalation policy are required?
|
||||
Reference in New Issue
Block a user