agents/gcp_solution_architecture_agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7926fabc37983d131528e7e5bd5873e7dcadb890
gcp_solution_architecture_a…/docs/architecture.md
demo-bot 7926fabc37
Some checks failed
validation / verify (push) Failing after 13s
Details
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.
2026-09-01 20:00:05 +00:00

2.1 KiB
Raw Blame History

Steps 1–2 — Architecture and validation

Selected products

  • Cloud Run: managed HTTPS, stateless container runtime.
  • Pub/Sub: durable asynchronous event transport.
  • Cloud Storage: object persistence.
  • Firestore: document/application state persistence.
  • VPC and Serverless VPC Access: controlled private egress foundation.
  • Cloud Logging and Cloud Monitoring: operational telemetry.
  • Artifact Registry: container image source.
  • IAM and Service Usage: identities and API enablement.

Request flow

Clients call Cloud Run over HTTPS. The service writes application state to Firestore, stores binary objects in Cloud Storage, and publishes domain events to Pub/Sub. A separately deployed worker can subscribe to the topic; this baseline creates the topic and dead-letter topic but intentionally does not invent worker application code. Logs and platform metrics feed the operational plane.

Security and reliability

Cloud Run uses a dedicated service account and configurable ingress. Firestore and Storage use managed encryption. Pub/Sub dead-lettering limits poison-message impact. Runtime configuration is supplied as variables rather than secrets in source. Production hardening should add Secret Manager, customer-managed keys, edge protection, private ingress, backups, and multi-region DR if the open questions require them.

Terraform notes

The terraform/ directory is a module-like root configuration. It enables required APIs, creates the network, storage bucket, Firestore database, Pub/Sub topics, Artifact Registry repository, service account, and Cloud Run service. Supply project_id, region, and container_image; do not commit a state backend or credentials. The Cloud Run resource is a deployable placeholder whose image must already exist.

Validation result

Static artifact tests check required sections, Mermaid markers, Terraform file presence, and absence of obvious credential material. Terraform formatting/validation and an optional plan are defined in scripts/validate.sh; they are not executed by repository generation because this environment has no filesystem or cloud credentials. No resources are provisioned by the workflow.

Reference in New Issue View Git Blame Copy Permalink