Add shared GCP Vertex AI env template

[ggallen]

Summary

• Add env/gcp-vertex.env — shared Vertex AI configuration template used by all agents with inference: provider: vertex
• Copied from fullsend-ai/fullsend scaffold (internal/scaffold/fullsend-repo/env/gcp-vertex.env at upstream/main)
• Needed for config-driven agent registration (ADR-0058): when agents are fetched from this repo via URL, host_files with relative paths are resolved against the source repo — this file must exist here

Context

The triage agent's host_files reference env/gcp-vertex.env. With config-driven registration, resolveBaseHostFiles fetches it from this repo, but it didn't exist here — only in the fullsend scaffold. See fullsend-ai/fullsend#2845.

Test plan

• Verify file content matches scaffold source
• Re-run triage via /fs-triage on ggallen-sandbox/integration-service#1 after merging

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Add shared GCP Vertex AI env template

✨ Enhancement ⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Add shared Vertex AI env template for agents using inference.provider: vertex.
• Ensure config-driven agent registration can resolve host_files paths from this repo.
• Standardize required Vertex/GCP environment variables and credentials path.

Diagram

graph TD
  A["Agent configs"] --> B["host_files"] --> C["env/gcp-vertex.env"] --> D["Vertex AI runtime"]
  D --> E[("GCP Project/Region")]
  D --> F[("GCP Credentials")]

Loading

High-Level Assessment

Adding the shared env template in this repo is the correct fix because config-driven registration resolves host_files relative to the source repository; placing the file here ensures all Vertex-based agents can fetch it consistently. Alternatives like embedding values directly in each agent config or referencing scaffold paths would increase duplication or break URL-based resolution.

Files changed (1) +5 / -0

Other (1) +5 / -0

gcp-vertex.envAdd shared Vertex AI environment template +5/-0

Add shared Vertex AI environment template

• Introduces a shared env template exporting the required Vertex AI/GCP variables (project/region) and the expected credentials file path. Values are intended to be injected via environment variables at runtime while providing a stable host_files target.

env/gcp-vertex.env

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: 🎫 harness/triage.yaml has stale /tmp/workspace/ dest paths; env vars never reach sandbox

1. Empty env exports 🐞 Bug ☼ Reliability

Description

env/gcp-vertex.env self-assigns and exports ANTHROPIC_VERTEX_PROJECT_ID, CLOUD_ML_REGION, and
GOOGLE_CLOUD_PROJECT, which will set these variables to empty strings when they are unset in the
sourcing environment. This can silently override expected configuration for Vertex usage (the file
is uploaded for triage runs), leading to misconfigured runtime env without an explicit failure.

Code

env/gcp-vertex.env[R2-5]

+export ANTHROPIC_VERTEX_PROJECT_ID=${ANTHROPIC_VERTEX_PROJECT_ID}
+export CLOUD_ML_REGION=${CLOUD_ML_REGION}
+export GOOGLE_APPLICATION_CREDENTIALS=/tmp/.gcp-credentials.json
+export GOOGLE_CLOUD_PROJECT=${GOOGLE_CLOUD_PROJECT}

Evidence

The env file includes self-referential exports that turn unset variables into empty exported values.
The triage harness uploads this file into the sandbox environment directory, so these exports are
expected to be applied during triage execution.

env/gcp-vertex.env[1-5]
harness/triage.yaml[10-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`env/gcp-vertex.env` currently contains self-referential exports like `export FOO=${FOO}`. If `FOO` is not set at source-time, this will export `FOO` as an empty string, silently masking missing configuration.

### Issue Context
This env file is shipped into the triage sandbox via `host_files`, so its contents are expected to influence runtime behavior.

### Fix Focus Areas
- env/gcp-vertex.env[1-5]
- harness/triage.yaml[10-21]

### Suggested fix
Update the env template to fail fast or only export when set. For example:
- Fail-fast (recommended for required vars):
 - `: "${ANTHROPIC_VERTEX_PROJECT_ID:?ANTHROPIC_VERTEX_PROJECT_ID must be set}"`
 - `: "${CLOUD_ML_REGION:?CLOUD_ML_REGION must be set}"`
 - `: "${GOOGLE_CLOUD_PROJECT:?GOOGLE_CLOUD_PROJECT must be set}"`
 - then `export` them normally.

Or, if these are optional, export only when non-empty:
- `if [ -n "${ANTHROPIC_VERTEX_PROJECT_ID:-}" ]; then export ANTHROPIC_VERTEX_PROJECT_ID; fi`
(and similarly for the others).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Empty env exports 🐞 Bug ☼ Reliability

env/gcp-vertex.env self-assigns and exports ANTHROPIC_VERTEX_PROJECT_ID, CLOUD_ML_REGION, and
GOOGLE_CLOUD_PROJECT, which will set these variables to empty strings when they are unset in the
sourcing environment. This can silently override expected configuration for Vertex usage (the file
is uploaded for triage runs), leading to misconfigured runtime env without an explicit failure.

Agent Prompt

### Issue description
`env/gcp-vertex.env` currently contains self-referential exports like `export FOO=${FOO}`. If `FOO` is not set at source-time, this will export `FOO` as an empty string, silently masking missing configuration.

### Issue Context
This env file is shipped into the triage sandbox via `host_files`, so its contents are expected to influence runtime behavior.

### Fix Focus Areas
- env/gcp-vertex.env[1-5]
- harness/triage.yaml[10-21]

### Suggested fix
Update the env template to fail fast or only export when set. For example:
- Fail-fast (recommended for required vars):
  - `: "${ANTHROPIC_VERTEX_PROJECT_ID:?ANTHROPIC_VERTEX_PROJECT_ID must be set}"`
  - `: "${CLOUD_ML_REGION:?CLOUD_ML_REGION must be set}"`
  - `: "${GOOGLE_CLOUD_PROJECT:?GOOGLE_CLOUD_PROJECT must be set}"`
  - then `export` them normally.

Or, if these are optional, export only when non-empty:
- `if [ -n "${ANTHROPIC_VERTEX_PROJECT_ID:-}" ]; then export ANTHROPIC_VERTEX_PROJECT_ID; fi`
(and similarly for the others).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 12:42 PM UTC · Completed 12:45 PM UTC
Commit: 68fac39 · View workflow run →

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open pull requests.

_{Posted by fullsend pre-review check}

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open pull requests.

_{Posted by fullsend post-review check}

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 12:46 PM UTC · Completed 12:53 PM UTC
Commit: 68fac39 · View workflow run →

[fullsend-ai-retro]

Retro: PR #6 — Add shared GCP Vertex AI env template

Timeline:

1. 12:39:35 — PR Add shared GCP Vertex AI env template #6 created by ggallen (human): adds 5-line env/gcp-vertex.env file
2. 12:39:49 — Review workflow dispatched (run 28518163921)
3. 12:40:48 — PR merged by author (~1 min after creation, before review completes)
4. 12:42:20 — Qodo bot posts review finding: env file self-assigns variables, blanking them if unset
5. 12:42:45 — fullsend review bot posts "Finished Review — Success"
6. 12:42:46 — fullsend review bot posts "Review skipped — this PR is already merged"
7. 12:45:17 — Second "Review skipped" message posted
8. 12:46:23 — Follow-up PR Move gcp-vertex.env to common/env/ #7 created to move the file to common/env/
9. 12:46:27 — Retro dispatched on this PR

Assessment: This was a straightforward human PR with no agent involvement (no triage, no code agent). The review agent ran to completion but couldn't post its review because the PR was already merged. The retro agent was then dispatched on a PR that had no agent workflow to analyze. Both agent runs represent wasted compute.

No new proposals. All improvement opportunities identified are already covered by existing open issues:

• #2388 — Cancel in-flight review workflow when PR merges during review (would have stopped the review run)
• #1439 — Skip review dispatch when PR is already closed or merged (would have prevented dispatch entirely)
• #2708 — Skip retro dispatch for merged human PRs with no agent involvement (would have prevented this retro)
• #2522 — Post-review script should not post skip comment when pre-review already skipped (would have prevented duplicate skip messages)
• #1373 — Post review results on recently-merged PRs as informational comments (would have made the Qodo finding more visible)

Implementing #1439 or #2388 plus #2708 would have the highest impact — preventing both the review and retro dispatches entirely, saving ~10 minutes of agent compute on a PR that needed neither.