GCP
GCP Discovery Module - authenticates with a per-company service-account
What it does
Credential loop: setup wizard -> cred-mgr:gcp:<company> -> bridge injects GcpProjectId / GcpServiceAccountKey into $Configuration -> this module mints an OAuth token from the service-account key and calls the GCP REST API. Emits: - GCPProjects.csv (cloudresourcemanager projects.get) - GCPComputeInstances.csv (compute instances.aggregatedList, best-effort) CSV rows are migration-useful when data exists: - Stable ObjectId / ResourceId (GCP resource names) - DisplayName / Name human labels (never filled from ids) - Parent relationships (project -> parent org/folder; instance -> project) - Timestamps / lifecycle state from the API - Network + service-account relationships on instances AUTH: missing or invalid GCP credentials -> AUTH_FAILURE (no invented rows). EMPTY: authenticated with zero instances -> honest empty export (no sentinel rows). OUT OF SCOPE for v1 (SPEC-89): IAM, Cloud Storage, BigQuery, GKE, billing, networking inventory beyond NIC fields on VMs.
How the app exposes it
The module runs through the ACQI discovery orchestrator and writes its rows into a dedicated results view. From there, conflicts, dependencies, and readiness scores feed the deal-wide consolidation layer.
/discovered/gcp Outputs
Each module emits a normalised CSV keyed by entity ID with readiness and risk scores, evidence-source counts, and last-seen timestamps. The exact column set varies by module — the app's results view shows the live schema.