fix(#5700): move mint config into per-forge section in repos.yaml

[fullsend-ai-coder]

Summary

Moves the top-level mint block in repos.yaml into a per-forge forge section, allowing GitLab-only manifests to validate without mint fields (GitLab does not use the mint service per ADR 0067).

Not a breaking change: No repos.yaml consumers exist yet (#5616), so the schema migration from mint: to forge: does not require the ! suffix.

Changes

• internal/repos/manifest.go: Replace MintConfig with ForgeSection / GitHubForgeInfra / GitLabForgeInfra types. Validate() now only requires forge.github.mint_url/mint_project/mint_region when at least one repo resolves to forge: github. resolveWithEntry() sources mint config from the forge-specific section. LoadManifest() detects the old top-level mint: key and returns a clear migration error.
• internal/repos/init.go: buildManifest() generates the new forge: section instead of a top-level mint: block. TODOs reference forge.github.* paths. GitLab-only manifests skip mint config entirely.
• internal/repos/upgrade.go: Updated mint URL comparison to read from Forge.GitHub.MintURL.
• internal/cli/repos.go: Updated resolveMintProvisioner() to read from Forge.GitHub.*. Guard mint verification behind hasGitHubForge() check so GitLab-only manifests skip mint entirely.
• internal/repos/batch_install.go: Filter Phase 2 org-mint loop to skip non-GitHub orgs, preventing EnsureOrgInMint calls with empty MintURL for GitLab repos.
• Docs: Updated stale mint.url/mint.project/mint.region references in docs/cli/repos.md, docs/guides/getting-started/repo-management.md, docs/plans/repos-management.md, and docs/plans/repos-init.md.
• Test files: Updated all test fixtures (YAML strings and Go struct literals) to use the new schema with ForgeSection and GitHubForgeInfra. Added tests for GitLab-only and mixed-forge validation.

Scope

Partial #5700 — implements items 1, 2, 5, 6 from the issue. Items 3 (installVarsForForge for GitLab) and 4 (gitlabUninstallVars) are deferred because the GitLab install flow is not yet implemented (install.go line 171 returns early with "not yet implemented"). Those will be addressed when the GitLab install path is built. Similarly, install.go still lists FULLSEND_MINT_URL in requiredVariables regardless of forge — this is inert for GitLab since install returns early, but should be made forge-aware when GitLab install lands.

Testing

• All internal/repos/... tests pass (race detection enabled)
• All repos-related internal/cli/... tests pass
• go build ./... succeeds
• go vet ./... clean
• New test cases: TestValidate_GitLabOnly_NoMintRequired, TestValidate_MixedForge_RequiresMint

---

Post-script verification

• Branch is not main/master (agent/5700-forge-section-manifest)
• Secret scan passed (gitleaks — eeb97439bfb4d4d400c47607f4a1ccbea3244872..HEAD)
• PR body secret scan passed (gitleaks — no-git)
• Pre-commit hooks passed (authoritative run on runner)
• Tests ran inside sandbox

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:22 AM UTC · Completed 1:41 AM UTC
Commit: b0d86dd · View workflow run →

[codecov]

Codecov Report

❌ Patch coverage is 75.90361% with 20 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/cli/repos.go	65.00%	4 Missing and 3 partials ⚠️
internal/repos/manifest.go	82.14%	5 Missing ⚠️
internal/repos/uninstall.go	0.00%	3 Missing and 1 partial ⚠️
internal/repos/batch_install.go	77.77%	1 Missing and 1 partial ⚠️
internal/repos/init.go	90.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Review

Findings

Low

• [edge-case] internal/repos/manifest.go:271 — The legacy mint: key detection in LoadManifest uses a second yaml.Unmarshal into map[string]interface{} after the struct unmarshal. This works correctly with yaml.v3's default permissive behavior (unknown keys are silently ignored), but if strict mode (KnownFields(true)) is ever added, the struct unmarshal would fail first with a less helpful error, masking the migration hint.

• [edge-case] internal/repos/batch_install.go:327 — Non-GitHub repos skip WIF provisioning in Phase 2 and proceed to Phase 3 with an empty WIFProvider string in InstallConfig. The downstream Install() function receives SkipWIF: true but also an empty WIFProvider, which may result in writing an empty secret for FULLSEND_GCP_WIF_PROVIDER. This is a known limitation — GitLab install currently returns early with "not yet implemented" — and is deferred to items 3–4 of issue repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700.

• [scope-completeness] — PR correctly uses "Partial repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700" and implements items 1, 2, 5, 6. Items 3–4 (GitLab install/uninstall variable fixes) are deferred until the GitLab install path is implemented. Consider filing follow-up issues to maintain traceability.

Previous run

Review

Findings

Low

• [defensive-panic] internal/cli/repos.go:981 — resolveMintProvisioner uses panic() for the defensive precondition check when MintProject is empty. Both call sites (runReposUpgrade and runReposUpgradeMint) correctly guard with HasForge(repos.ForgeGitHub), making the panic unreachable in normal execution. A returned error would be marginally safer for future callers, but the panic serves as a clear assertion.

• [edge-case] internal/repos/batch_install.go:201 — Phase 1 org-mint loop correctly skips non-GitHub repos via the new forge guard. The theoretical concern about same-name GitHub org / GitLab group is already handled by Validate(), which rejects same-owner mixed-forges.

• [scope-completeness] — PR correctly uses "Partial repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700" — items 3–4 (GitLab install/uninstall variable fixes) are deferred until the GitLab install path is implemented (install.go returns early with "not yet implemented"). Consider filing follow-up issues for items 3–4 to maintain traceability.

Previous run (2)

Review

Findings

Medium

• [error-handling-gap] internal/repos/batch_install.go:430 — Phase 3 install failure cleanup calls provisionerFactory(dr.resolved) and prov.DeletePerRepoWIF() without a forge guard. Non-GitHub repos skip Phase 2 WIF provisioning (line 327 guard) but still proceed to Phase 3 as phase3Candidates. When Install() fails for a GitLab repo ("not yet implemented"), the cleanup creates a GCF provisioner with empty MintProject/MintRegion/MintURL (since resolveWithEntry only populates these for ForgeGitHub), causing a spurious GCP API call with an empty project ID. The error is caught and logged, and the repo is already marked as failed, so there is no data loss or crash — but the cleanup path should be guarded.
  Remediation: Add if dr.resolved.Forge == ForgeGitHub before the provisionerFactory call in the Phase 3 failure handler, matching the Phase 2 guard pattern.

Low

• [fail-open] internal/cli/repos.go:978 — resolveMintProvisioner reads m.Forge.GitHub.* unconditionally without validating that GitHub forge config is populated. Both current callers (runReposUpgrade at line 1344 and runReposUpgradeMint at line 1481) have HasForge(ForgeGitHub) guards, so the function is safe today. A future caller without that guard would create a GCF provisioner with empty credentials.
  Remediation: Consider adding a precondition check in resolveMintProvisioner for non-empty m.Forge.GitHub.MintProject.

Previous run (3)

Review

Findings

Low

• [fail-open] internal/repos/batch_install.go:324 — BatchInstall Phase 2 per-repo WIF provisioning calls provisionerFactory(d.resolved) for all repos including non-GitHub. For GitLab repos, resolved mint fields are empty strings. The PR added a ForgeGitHub guard at line 203 for org-level mint but did not replicate it for per-repo WIF provisioning. Currently latent because ProvisionWIF with empty config would fail and move the repo to the Failed list.
  Remediation: Add a forge guard (continue if d.resolved.Forge != ForgeGitHub) before the provisionerFactory call at line 276, matching the pattern at line 203.

• [fail-open] internal/repos/uninstall.go:150 — WIF cleanup calls provisionerFactory(resolved) regardless of forge type. uninstallRepoResources does not have a GitLab early-return, so if a GitLab repo's workflow deletion succeeds, it will reach the WIF cleanup and call provisionerFactory with empty mint fields.
  Remediation: Add a forge guard (continue if resolved.Forge != ForgeGitHub) before the provisionerFactory call.

• [code-organization] internal/cli/repos.go:987 — hasGitHubForge is a free function in the CLI layer that operates purely on *repos.Manifest via DistinctForges(). Every other manifest-state query is a method on *Manifest in internal/repos/manifest.go.
  Remediation: Move to internal/repos/manifest.go as func (m *Manifest) HasForge(name string) bool.

---

Labels: PR fixes a validation bug in repos.yaml manifest handling

Previous run (4)

Review

Findings

Medium

• [stale-reference] docs/plans/repos-management.md:32 — The introductory YAML example block (lines 29–35) still shows the old mint:/url:/project:/region: top-level structure. Every other YAML example in the changed files was updated to forge: github: mint_url/mint_project/mint_region, but this block was missed. A developer following this example would produce YAML that the new LoadManifest legacy-key detection rejects.
  Remediation: Update the YAML example at lines 29–35 to use the new forge: github: structure with mint_url, mint_project, mint_region keys.

• [stale-reference] docs/plans/repos-management.md:1039 — The sync reconciliation table at line 1039 still reads "Upsert to match mint.url". This is a stale reference to the removed config path; it should reference forge.github.mint_url. The equivalent table earlier in the file (line 206) was correctly updated by this PR.
  Remediation: Change "Upsert to match mint.url" to "Upsert to match forge.github.mint_url".

Low

• [code-organization] internal/cli/repos.go:987 — hasGitHubForge is placed in the CLI layer but operates purely on *repos.Manifest via DistinctForges(). All other manifest-state queries are methods on *Manifest in internal/repos/manifest.go. Consider moving to the repos package as a Manifest method.

• [fail-open] internal/repos/batch_install.go:324 — BatchInstall Phase 2 per-repo WIF provisioning calls provisionerFactory(d.resolved) for all repos including non-GitHub. For GitLab repos, resolved mint fields are empty strings. Pre-existing but made more explicit by this PR's conditional field population. Currently inert because GitLab install returns early at install.go:171.

• [fail-open] internal/repos/uninstall.go:150 — Same pattern in uninstall: WIF cleanup calls provisionerFactory(resolved) regardless of forge type. Currently inert for the same reason.

• [install-latent-drift-acknowledgment] internal/repos/install.go:349 — requiredVariables still includes FULLSEND_MINT_URL unconditionally. Acknowledged as deferred; no runtime impact since GitLab install is not yet implemented.

• [code-organization] internal/repos/manifest.go:273 — Legacy mint: key detection performs a second yaml.Unmarshal into map[string]interface{} inline in LoadManifest. Consider extracting to a separate function for consistency with the codebase's pattern of separating validation/migration logic.

• [scope-completeness] — PR implements items 1, 2, 5, 6 from issue repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700; items 3–4 (GitLab install/uninstall vars) are explicitly deferred because the GitLab install path is not yet implemented. Scope is adequately documented in the PR description.

Previous run (5)

Review

Findings

Medium

• [stale-reference] internal/cli/repos.go:1462 — The upgrade-mint command's Long description still references "the manifest's mint.url" — the old config path that this PR renames to forge.github.mint_url. Every other user-facing reference (docs, error messages, comments) was updated, but this help-text string was missed. Users running fullsend repos upgrade-mint --help will see the stale path.
  Remediation: Change "the manifest's mint.url" to "the manifest's forge.github.mint_url" in the Long description of newReposUpgradeMintCmd.

Low

• [code-organization] internal/repos/manifest.go:273 — The legacy mint: key detection logic is embedded inline in LoadManifest. Consider extracting to a separate function (e.g., checkLegacyMintKey) for consistency with the codebase's pattern of separating validation/migration logic.

• [install-latent-drift-acknowledgment] internal/repos/install.go — requiredVariables still includes FULLSEND_MINT_URL regardless of forge type. The PR body acknowledges this as intentionally deferred — create a follow-up issue when GitLab install is implemented.

• [scope-completeness] — PR implements items 1, 2, 5, 6 from issue repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700; items 3–4 (GitLab install/uninstall vars) are explicitly deferred. Scope is adequately documented in the PR description.

• [breaking-change-protocol-compliance] — Prior review flagged the schema migration as a breaking change requiring the ! suffix. The PR's rationale ("No repos.yaml consumers exist yet," per issue repos: make repos tool forge-aware for multi-forge manifest support #5616) is confirmed — the ! suffix is not required.

Previous run (6)

Review

Findings

High

• [schema-breaking-change] internal/repos/manifest.go — The repos.yaml schema changed incompatibly (mint: → forge.github:) without a breaking-change signal in the PR title. Per COMMITS.md, breaking changes must use the ! suffix (e.g., fix(#5700)!:). Existing user manifests with the old mint: block will fail validation after upgrading the CLI, with no indication that the old field was present and needs migrating.
  Remediation: Add ! suffix to PR title (fix(#5700)!: move mint config into per-forge section in repos.yaml) and add a BREAKING CHANGE trailer to the merge commit body explaining migration from mint: to forge: github:.

• [missing-guard] internal/cli/repos.go:1479 — runReposUpgradeMint calls resolveMintProvisioner(opts.testProvisioner, m) unconditionally after validation passes. With this PR's changes, a GitLab-only manifest passes validation without mint fields, but resolveMintProvisioner creates a gcf.NewProvisioner with empty ProjectID, Region, and MintURL, causing a runtime failure. The same issue exists at line 1345 in runReposUpgrade when skipMintCheck is false.
  Remediation: Guard both runReposUpgradeMint and the !opts.skipMintCheck block behind a check like slices.Contains(m.DistinctForges(), repos.ForgeGitHub). When no GitHub repos exist, skip mint verification entirely.

• [stale-doc] docs/cli/repos.md:371 — The upgrade-mint command description says "matches the manifest's mint.url" — now incorrect; should reference forge.github.mint_url. This is user-facing CLI reference documentation.
  Remediation: Update reference to forge.github.mint_url.

• [stale-doc] docs/guides/getting-started/repo-management.md — Example YAML manifest (lines 71–74) shows the old top-level mint: structure. Users following this getting-started guide will create manifests with the old schema that silently lose their mint config.
  Remediation: Update YAML example to use the forge: github: structure.

Medium

• [scope-authorization-mismatch] — PR claims "Closes repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700" but only delivers items 1, 2, 5, 6 from the 6-item issue scope. Items 3 (fix installVarsForForge for GitLab) and 4 (fix gitlabUninstallVars) are not implemented. However, installVarsForForge() and gitlabUninstallVars do not exist yet — they are part of the GitLab install flow which returns early with "not yet implemented" in install.go line 171. Using "Partial repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700" instead of "Closes" would be more accurate.

• [behavioral-regression] internal/repos/batch_install.go:223 — BatchInstall Phase 2 iterates ALL orgs and calls prov.EnsureOrgInMint(ctx, resolved.MintURL, org). With this PR's changes to resolveWithEntry, GitLab repos get empty MintURL in ResolvedConfig. For mixed-forge manifests with SkipMintCheck=false, EnsureOrgInMint is called for GitLab orgs with empty MintURL.
  Remediation: Filter Phase 2 org loop to skip orgs whose forge is not ForgeGitHub.

• [silent-data-loss] internal/repos/manifest.go:45 — LoadManifest uses yaml.Unmarshal without strict/KnownFields mode. A repos.yaml with the old top-level mint: block parses without error — the mint configuration is silently discarded. Validate() then fails with forge.github.mint_url is required with no indication that the old mint: block was present.
  Remediation: Add backward-compatibility detection (e.g., a private LegacyMint field or two-pass parse) that emits a clear migration error when the old mint key is present.

• [architectural-coherence] internal/repos/install.go — The manifest schema now correctly models forge-specific infrastructure, but install.go still has requiredVariables including FULLSEND_MINT_URL in checkInstallComponents (line 349) regardless of forge type. While GitLab install currently returns early at line 171, this creates latent schema/implementation drift.
  Remediation: Track as a follow-up item or note in the PR description that install.go variables need forge-specific handling when GitLab install is implemented.

• [stale-doc] docs/plans/repos-management.md — Multiple stale references to mint.url, mint.project, mint.region as YAML manifest keys (lines 81, 206, 248, 490–498, 592–593, 1039, 1179).

• [stale-doc] docs/plans/repos-init.md — Stale references to mint.project and mint.region as manifest field names (lines 64–66, 204–212, 236).

Low

• [commit-type-accuracy] — PR title uses fix(#5700): but the dominant change is a schema migration/refactor. The fix component (GitLab manifests wrongly requiring mint fields) is enabled by the refactor. Per COMMITS.md: "When in doubt, prefer refactor or chore over feat or fix." However, fix is defensible since issue repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700 describes an actual user-visible validation error blocking GitLab-only manifests.

• [documentation-consistency] internal/repos/manifest.go — GitHubForgeInfra doc comment mixes requirement constraints ("required when at least one repo resolves to forge: github") with type description. Consider: "GitHubForgeInfra holds GitHub-specific infrastructure settings for the token mint service."

• [documentation-consistency] internal/repos/manifest.go — GitLabForgeInfra uses forward-looking language ("Currently has no required fields; future additions (e.g., gcp_project for WIF mode) will live here"). Other struct docs in the file describe current state only.

• [edge-case] internal/repos/manifest.go:657 — DistinctForges() returns an empty slice for manifests with zero repos, causing the validation loop to skip forge-specific checks. Correct behavior for validation, but resolveMintProvisioner doesn't benefit from this guard (see high finding above).

• [naming-consistency] internal/repos/manifest.go — ForgeSection uses "Section" suffix while existing types use "Config" suffix (DefaultsConfig). However, ForgeConfig already exists in forge_config.go as a different concept, making renaming impractical.

---

Labels: PR restructures mint config into per-forge sections of repos.yaml, directly modifying mint infrastructure config types and CLI install commands.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

[ggallen]

/fs-review

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 1:56 AM UTC · Ended 2:12 AM UTC
Commit: 4e2934c · View workflow run →

[github-actions]

Site preview

Preview: https://3cac75bd-site.fullsend-ai.workers.dev

Commit: 2477b78009ed5c49d4cd1a59b676aa91c53a3de4

Superseded by updated review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:56 AM UTC · Completed 2:12 AM UTC
Commit: 4e2934c · View workflow run →

[ggallen]

/fs-review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:18 AM UTC · Completed 2:38 AM UTC
Commit: 616c6bd · View workflow run →

[ggallen]

/fs-review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:45 AM UTC · Completed 3:04 AM UTC
Commit: 2c662a6 · View workflow run →

[ggallen]

/fs-review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 10:27 AM UTC · Completed 10:41 AM UTC
Commit: 2477b78 · View workflow run →

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 12:18 PM UTC · Completed 12:34 PM UTC
Commit: 2477b78 · View workflow run →

[fullsend-ai-retro]

Retro: PR #5701 — move mint config into per-forge section in repos.yaml

Timeline

Time (UTC)	Event
00:53	Issue #5700 created by ggallen
00:54	Triage agent succeeds, applies ready-to-code + component labels
01:01	Code agent run 30412860009 starts
01:21	Code agent opens PR #5701 — 12 files changed
01:41	Auto-triggered review 30413834977 finds 4 HIGH, 5 MEDIUM findings
01:54–03:30	ggallen manually iterates through 5 fix-review cycles via /fs-review
10:25	ggallen pushes final cleanup, triggers 7th review
10:41	Final review 30443632369 approves with 3 LOW findings
11:11	ggallen acknowledges remaining findings and approves
12:15	PR merged (18 files, +842/−577)

What went well

The review agent was highly effective. It caught all critical issues on the first pass — missing forge guards that would crash on GitLab-only manifests, silent data loss from undetected old-format config files, and stale documentation references. Across 7 review iterations, findings decreased monotonically from 4 HIGH + 5 MEDIUM to 3 LOW, with each cycle surfacing progressively lower-severity issues. The final 3 LOW findings were all acknowledged by the human reviewer as intentional design decisions.

What could go better

High rework rate: 7 review cycles over ~11 hours. The code agent's initial output required significant human rework. The code agent correctly restructured the type definitions (MintConfig → ForgeSection) and updated some consumers, but missed critical runtime safety paths:

1. Missing forge guards — batch_install.go, uninstall.go, and repos.go (upgrade path) all called mint/WIF operations unconditionally. The code agent updated test fixtures for these packages but did not update the production code — a detectable antipattern.
2. No backward-compatibility handling — Old repos.yaml files with a top-level mint: key would silently lose their config. The human had to add legacy key detection with a migration hint.
3. No documentation updates — 4 docs files needed updating; the code agent touched none.
4. Scope overreach — Used "Closes repos.yaml: move mint config into per-forge section, fix GitLab install variables #5700" when only 4 of 6 items were implemented.

The fix agent was never dispatched (no fix.yml runs). The human did all 6 fix iterations manually.

Evidence for existing issues

• fullsend-ai/agents#455 (code agent should enumerate struct consumers): The code agent changed MintConfig to ForgeSection but didn't trace all runtime consumers (batch_install.go Phase 2 org-mint loop, uninstall.go WIF cleanup, repos.go upgrade guard). This PR provides a concrete Go type-restructuring case where consumer enumeration would have prevented 3 HIGH findings.
• fullsend-ai/agents#452 (triage should enumerate documentation touchpoints): The triage agent applied component/install and component/mint labels but did not identify the 4 documentation files that needed updating. Enumerating doc touchpoints during triage would have given the code agent explicit targets.
• fullsend-ai/agents#474 (code agent should verify all files listed in the issue body): The issue body listed 6 implementation items but the code agent only addressed 4, and used "Closes" instead of "Partial."

Proposals filed

• Code agent should add backward-compatible migration detection when restructuring config schemas (in fullsend-ai/agents)
• Code agent should verify production code is updated when test fixtures reference a restructured type (in fullsend-ai/agents)