feat(repos): add repos status command

[ggallen]

Summary

• Adds fullsend repos status command that compares a repos.yaml manifest against actual forge state
• Wires the fullsend repos subcommand group into the CLI root, establishing the command structure for future repos management commands (ADR 0057)
• Implements parallel API discovery with configurable concurrency, drift detection for FULLSEND_MINT_URL, FULLSEND_GCP_REGION, and fullsend_ref, and both table and JSON output formats

Context

This is PR 4 from the repos management plan, implementing read-only status discovery. It depends on PRs #3002 (manifest parser) and #3001 (forge interface), both already merged.

Files changed

File	Change
internal/repos/status.go	New — Status(), checkRepoStatus(), extractWorkflowRef(), filterRepos()
internal/repos/status_test.go	New — 23 tests covering all status scenarios
internal/cli/repos.go	New — repos command group + repos status subcommand
internal/cli/root.go	Modified — wires newReposCmd() into root

Flags

• --manifest / -f (default repos.yaml): path or URL to manifest file
• --json: emit JSON output instead of table
• --repo (repeatable): filter to specific repos
• --concurrency (default 8): max parallel API calls

Exit codes

• 0: all repos match manifest
• 1: drift, missing repos, or errors detected

Test plan

• 23 unit tests pass (go test ./internal/repos/ -run TestStatus)
• 100% coverage on status.go (all functions)
• 91.2% overall package coverage
• go vet clean on both packages
• All pre-commit hooks pass
• Existing CLI tests (TestReposEnableCmd_*, TestReposDisableCmd_*) unaffected

🤖 Generated with Claude Code

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 11:52 PM UTC · Ended 11:59 PM UTC
Commit: 0a95cac · View workflow run →

[qodo-code-review]

PR Summary by Qodo

feat(repos): add fullsend repos status drift detection command

✨ Enhancement 🧪 Tests 🕐 40+ Minutes

AI Description

• Add fullsend repos status to compare repos.yaml against live forge state.
• Detect per-repo install status and drift for ref, mint URL, and GCP region.
• Support parallel discovery plus table/JSON output with non-zero exit on mismatches.

Diagram

graph TD
  A["CLI root"] --> B["repos status cmd"] --> C["repos.Status()"] --> D["Manifest loader"] --> E["Resolved repo list"]
  C --> F["Forge client"] --> G["GitHub API"]
  B --> H["Output: table/JSON"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use errgroup with SetLimit + context cancellation

• ➕ Cancels remaining discovery early on context cancellation/timeouts
• ➕ Avoids manual semaphore/mutex patterns; simpler concurrency control
• ➖ Still needs per-repo error aggregation (this PR intentionally returns partial results)
• ➖ Would require careful handling to preserve stable ordering in output

2. Batch discovery via GitHub GraphQL where possible

• ➕ Reduces API round-trips per repo (especially for variables)
• ➕ Potentially lowers rate-limit pressure at high repo counts
• ➖ More complex implementation and schema maintenance
• ➖ May not cover all endpoints used (e.g., raw file content retrieval) cleanly

Recommendation: The current approach (bounded parallelism with a semaphore and always producing a full StatusResult) is a good fit for a read-only status command: it preserves per-repo outcomes, keeps ordering deterministic, and is straightforward to test. Consider migrating to errgroup if you later want stronger cancellation semantics or richer error propagation; consider GraphQL batching only if rate limits become a real operational constraint.

Files changed (4) +1189 / -0

Enhancement (3) +366 / -0

repos.goAdd 'repos' command group and 'repos status' subcommand +147/-0

Add 'repos' command group and 'repos status' subcommand

• Introduces a new 'fullsend repos' command group and implements 'repos status' with flags for manifest path/URL, JSON output, repo filtering, and concurrency. Runs manifest load/validation and prints either JSON or a formatted status table, returning a non-zero error on drift/not-installed/errors.

internal/cli/repos.go

root.goWire 'repos' commands into CLI root +1/-0

Wire 'repos' commands into CLI root

• Registers 'newReposCmd()' on the root command so 'fullsend repos ...' becomes available.

internal/cli/root.go

status.goImplement manifest-vs-forge status discovery with drift detection +218/-0

Implement manifest-vs-forge status discovery with drift detection

• Adds the core 'Status()' implementation that expands globs, optionally filters repos, and checks each repo in parallel with a max concurrency limit. Discovers install state via the per-repo guard variable, reads repo variables and shim workflow ref, and records drift for 'FULLSEND_MINT_URL', 'FULLSEND_GCP_REGION', and 'fullsend_ref' along with aggregate summary counts.

internal/repos/status.go

Tests (1) +823 / -0

status_test.goAdd comprehensive unit tests for status scenarios +823/-0

Add comprehensive unit tests for status scenarios

• Adds a broad suite of tests covering installed/not-installed behavior, multi-field drift, workflow ref extraction (.yml/.yaml fallback), repo filtering, glob expansion, per-repo overrides, multi-org inputs, API error handling, and concurrency bounds using the fake forge client.

internal/repos/status_test.go

[github-actions]

Site preview

Preview: https://63f64a0d-site.fullsend-ai.workers.dev

Commit: f4ff555f06866fe4280a87c1001183a727ff5981

[codecov]

Codecov Report

❌ Patch coverage is 92.50000% with 15 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/cli/repos.go	87.75%	11 Missing and 1 partial ⚠️
internal/repos/status.go	97.02%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 54 rules

✅ Skills: writing-user-docs, writing-adrs

1. Real-looking GCP IDs in tests ✓ Resolved 📘 Rule violation ⛨ Security

Description

The new Go tests hardcode a Cloud Run URL and GCP project IDs (e.g., acme-fullsend-prod) that look
environment-specific and could correspond to real infrastructure. This violates the requirement to
avoid embedding sensitive/environment-specific identifiers in source (even in tests) and increases
accidental disclosure risk.

Code

internal/repos/status_test.go[R14-22]

+		Mint: MintConfig{
+			URL:     "https://fullsend-mint-abc123-uc.a.run.app",
+			Project: "acme-fullsend-prod",
+			Region:  "us-central1",
+		},
+		Defaults: DefaultsConfig{
+			InferenceProject: "acme-inference-prod",
+			InferenceRegion:  "us-central1",
+			FullsendRef:      "v2.3.0",

Relevance

⭐⭐⭐ High

Previously accepted removing hardcoded GCP project defaults to avoid embedding env-specific
identifiers.

PR-#1215

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062040 disallows hardcoded secrets and environment-specific identifiers such as
GCP project IDs and internal/resource hostnames. The added test manifest includes a Cloud Run URL
and GCP project IDs as string literals, which are environment-specific identifiers embedded directly
in code.

Rule 1062040: Disallow hardcoded secrets and sensitive environment-specific identifiers in source code
internal/repos/status_test.go[14-22]

Agent prompt

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

## Issue description
`internal/repos/status_test.go` hardcodes environment-specific identifiers (Cloud Run URL + GCP project IDs) that look real. Compliance requires avoiding hardcoded sensitive or environment-specific identifiers in source code; tests should use clearly fake placeholders.

## Issue Context
The test manifest currently uses values like `https://fullsend-mint-abc123-uc.a.run.app`, `acme-fullsend-prod`, and `acme-inference-prod`, which resemble real deployment artifacts.

## Fix Focus Areas
- internal/repos/status_test.go[14-22]

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

---

2. Unbounded goroutine creation ✓ Resolved 🐞 Bug ➹ Performance

Description

repos.Status() starts one goroutine per resolved repo and only acquires the semaphore inside the
goroutine, so large glob-expanded manifests can create thousands of blocked goroutines. This
increases memory/scheduler overhead and can make fullsend repos status slow or unstable on large
orgs.

Code

internal/repos/status.go[R89-103]

+	for i, rr := range resolved {
+		wg.Add(1)
+		go func(idx int, rr ResolvedRepo) {
+			defer wg.Done()
+			sem <- struct{}{}
+			defer func() { <-sem }()
+
+			cfg := manifest.ResolveConfigForEntry(rr.Owner, rr.Repo, rr.Entry)
+			status := checkRepoStatus(ctx, client, rr.Owner, rr.Repo, cfg)
+
+			mu.Lock()
+			results[idx] = status
+			mu.Unlock()
+		}(i, rr)
+	}

Relevance

⭐⭐⭐ High

Team often accepts concurrency-bounding/perf hardening changes (e.g., shared-timeout/caching
stampede fixes).

PR-#1215
PR-#2277

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

ExpandGlobs() can return a large resolved list by expanding wildcards via org repo listing, and
Status() then spawns a goroutine for every element in that list before blocking on the semaphore.
This means goroutine count grows with repo count, not maxConcurrency.

internal/repos/status.go[65-105]
internal/repos/manifest.go[387-485]

Agent prompt

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

## Issue description
`repos.Status()` spawns one goroutine per repo and only then blocks on a semaphore (`sem <- struct{}{}`), so the number of goroutines scales with repo count rather than `maxConcurrency`. With org-wide glob expansion this can create a large number of blocked goroutines and unnecessary overhead.

## Issue Context
- `Manifest.ExpandGlobs()` can expand entries like `org/*` by listing all org repos.
- `Status()` currently limits *in-flight API calls*, but not *goroutine creation*.

## Fix Focus Areas
- internal/repos/status.go[65-105]
- internal/repos/manifest.go[387-485]

## Suggested fix
Use one of:
1) **Acquire the semaphore before spawning** the goroutine (simplest):
  - `sem <- struct{}{}` in the loop before `go func...`
  - `defer func(){<-sem}()` inside the goroutine
  - This caps goroutine count to ~`maxConcurrency`.

2) **Worker pool** (more explicit):
  - Create a `jobs` channel of `(idx, ResolvedRepo)`
  - Start `min(maxConcurrency, len(resolved))` workers that read from `jobs`
  - Each worker computes status and writes `results[idx]`

Optionally clamp `maxConcurrency` to a reasonable upper bound to avoid users accidentally overwhelming the forge API.

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

---

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 12:00 AM UTC · Ended 12:02 AM UTC
Commit: 0a95cac · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 12:02 AM UTC · Completed 12:28 AM UTC
Commit: 4747e82 · View workflow run →

[fullsend-ai-review]

Review

Verdict: approve

Re-review after rebase (prior review SHA 4f37867). The PR code is unchanged — single commit rebased onto newer main. All six review dimensions confirm the implementation is sound.

• Correctness: Concurrency model is safe (pre-allocated results slice with unique index per goroutine, semaphore with context cancellation). Summary counting non-partitioning is documented in the StatusSummary struct comment. Fail-closed error handling throughout — ListRepoVariables errors return with Installed: false and Error set; workflow read errors preserve Installed: true when guard was already checked. Drift detection correctly skips when expected value is empty. Regex uses:\s+fullsend-ai/fullsend/\.github/workflows/[^@]+@(\S+) correctly extracts workflow refs. 23+ status tests and 17 CLI tests cover all code paths including edge cases (guard var false, .yaml extension, empty manifest, concurrent access with 20 repos).
• Security: Minimal attack surface — read-only command. Token handling is fail-closed (resolveToken() returns error when no token available). Manifest loading inherits existing SSRF protections (HTTPS enforcement, netutil.CheckIP() blocking internal IPs, redirect limit, 1 MB size cap). No injection vectors — output via fmt.Fprintf (table) and json.MarshalIndent (JSON). No secrets exposure (ListRepoVariables returns Actions variables, not secrets).
• Architecture: Uses forge.Client interface correctly per AGENTS.md. Follows established CLI command patterns (newReposCmd()/newReposStatusCmd() matching newGitHubCmd()/newMintCmd()). Variable names (FULLSEND_MINT_URL, FULLSEND_GCP_REGION, FULLSEND_PER_REPO_INSTALL) match what install.go writes.
• Intent & scope: PR title feat(repos) correctly uses feat per COMMITS.md — this is a new CLI command users can invoke. Scope matches repos-management plan PR 4 exactly. The 206-line deletion in config.ts is auto-formatter output (single→double quotes, added semicolons); the functional change is one sidebar entry.
• Documentation: All docs updated — CLI README, new repos.md, CLI internals command tree, operations guide, and VitePress sidebar entry.

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 10 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

Previous run

Review

Verdict: approve

The prior review's medium finding ([missing-sidebar-entry]) has been addressed — { text: "fullsend repos", link: "/cli/repos" } is now present in the VitePress sidebar config. The accompanying code formatting in config.ts (single → double quotes, added semicolons) appears to be auto-formatter output triggered by the sidebar edit.

The core implementation (internal/repos/status.go, internal/cli/repos.go) is sound across all review dimensions:

• Correctness: Concurrency model is safe (pre-allocated results slice with unique index per goroutine). Summary counting non-partitioning is now documented. Guard variable check, workflow ref extraction, and drift detection logic are all correct. Edge cases (no workflow file, guard var "false", empty expected values) are properly handled. 23+ status tests and 15+ CLI tests cover all code paths.
• Security: Minimal attack surface — read-only command. Token handling is fail-closed (errors when no token available, never logged or exposed). Manifest loading has SSRF protections (HTTPS enforcement, IP blocking, size limits, redirect restrictions). No injection vectors in output rendering.
• Architecture: Uses forge.Client interface correctly per AGENTS.md. Follows established CLI command patterns (newReposCmd()/newReposStatusCmd() matching newGitHubCmd()/newMintCmd()).
• Documentation: All docs updated — CLI README, new repos.md, CLI internals command tree, operations guide, and VitePress sidebar.

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 10 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

Previous run

Review

Verdict: approve

The prior review's medium finding ([missing-sidebar-entry]) has been addressed — { text: "fullsend repos", link: "/cli/repos" } is now present in the VitePress sidebar config. The accompanying code formatting in config.ts (single → double quotes, added semicolons) appears to be auto-formatter output triggered by the sidebar edit.

The core implementation (internal/repos/status.go, internal/cli/repos.go) is sound across all review dimensions:

• Correctness: Concurrency model is safe (pre-allocated results slice with unique index per goroutine). Summary counting non-partitioning is now documented. Guard variable check, workflow ref extraction, and drift detection logic are all correct. Edge cases (no workflow file, guard var "false", empty expected values) are properly handled. 23+ status tests and 15+ CLI tests cover all code paths.
• Security: Minimal attack surface — read-only command. Token handling is fail-closed (errors when no token available, never logged or exposed). Manifest loading has SSRF protections (HTTPS enforcement, IP blocking, size limits, redirect restrictions). No injection vectors in output rendering.
• Architecture: Uses forge.Client interface correctly per AGENTS.md. Follows established CLI command patterns (newReposCmd()/newReposStatusCmd() matching newGitHubCmd()/newMintCmd()).
• Documentation: All docs updated — CLI README, new repos.md, CLI internals command tree, operations guide, and VitePress sidebar.

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 10 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

Previous run (2)

Review

Findings

Medium

• [missing-sidebar-entry] website/.vitepress/config.ts:160 — The CLI Reference sidebar includes fullsend github, fullsend inference, and fullsend mint, but does not include the new fullsend repos command. Users navigating the CLI documentation via the website sidebar will not discover the repos command documentation. AGENTS.md notes: "When adding a new doc under docs/, check website/.vitepress/config.ts sidebar config."
  Remediation: Add { text: 'fullsend repos', link: '/cli/repos' } to the CLI Reference sidebar items array after the fullsend mint entry.

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

Previous run (3)

Review

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

• [logic-error] internal/repos/status.go:102 — The summary counting logic allows a repo to be counted in both Errored and either Installed or NotInstalled, because the Error check is independent of the Installed/NotInstalled check. This means Installed + NotInstalled + Errored can exceed Total. The test suite explicitly validates this behavior as intentional, but downstream JSON consumers may assume counts partition Total. Consider documenting the non-partitioning semantics in the StatusSummary struct comment.

• [scope-creep] N/A — The PR includes 4 documentation files beyond the plan's explicit PR 4 scope. These were added to address prior review findings about missing documentation — standard practice, not a concern.

---

Labels: PR adds new Go CLI command group for per-repo installation management.

Previous run (4)

Review

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

• [logic-error] internal/repos/status.go:102 — The summary counting logic allows a repo to be counted in both Errored and either Installed or NotInstalled, because the Error check is independent of the Installed/NotInstalled check. This means Installed + NotInstalled + Errored can exceed Total. The test suite explicitly validates this behavior as intentional, but downstream JSON consumers may assume counts partition Total. Consider documenting the non-partitioning semantics in the StatusSummary struct comment.

• [scope-creep] N/A — The PR includes 4 documentation files beyond the plan's explicit PR 4 scope. These were added to address prior review findings about missing documentation — standard practice, not a concern.

Previous run (5)

Review

Findings

Medium

• [logic-error] internal/repos/status.go:103 — The summary counting logic treats Error and Installed as mutually exclusive (the switch checks s.Error first), but checkRepoStatus can return a status where both Installed = true and Error != "" — this happens when the guard variable is set (marking the repo as installed) but readWorkflowRef subsequently fails at line 145. In that case, the repo is counted as Errored but not Installed, so the Installed count undercounts. The error message from renderStatusResult (e.g., "0 installed, 0 drifted, 0 not installed, 1 errored") would be misleading since the repo is actually installed.
  Remediation: Either (a) always count Installed when s.Installed is true regardless of error status, or (b) clear status.Installed in checkRepoStatus before returning when an error occurs after the guard check.

• [regex-scope] internal/repos/status.go:14 — The workflowRefPattern regex uses .* between fullsend-ai/fullsend/ and @, which is broader than needed. It could match action paths or arbitrary file paths within the fullsend repo, not just workflow file references.
  Remediation: Tighten the regex to match only expected workflow paths: uses:\s+fullsend-ai/fullsend/\.github/workflows/[^@]+@(\S+).

• [missing-doc] docs/cli/README.md:13 — The CLI documentation overview lists command groups (github, inference, mint) but does not include the new fullsend repos command group added in this PR.
  Remediation: Add a row to the Command groups table for fullsend repos.

• [missing-doc] docs/cli/repos.md — No documentation file exists for the new fullsend repos command group, unlike the existing github.md, inference.md, and mint.md.
  Remediation: Create docs/cli/repos.md documenting the repos command group, flags, and usage examples.

• [missing-doc] docs/guides/dev/cli-internals.md:6 — The CLI command tree does not include the new repos command group.
  Remediation: Add the repos command group to the CLI command tree.

Low

• [dead-code] internal/repos/status.go:79 — The indexedStatus struct is declared inside the Status function but is never used. Dead code from a previous implementation approach.

• [context-cancellation] internal/repos/status.go:88 — The semaphore send does not check ctx.Done(). If the context is cancelled, the loop continues launching goroutines for remaining repos rather than stopping early. Low impact since goroutines fail fast on cancelled context API calls.

• [error-message-format] internal/cli/repos.go:67 — Error message uses invalid manifest prefix, inconsistent with manifest.go's action-oriented prefixes.

• [error-message-format] internal/repos/status.go:68 — Error message expanding globs could include which glob for debuggability.

• [flag-description] internal/cli/repos.go:45 — Flag description says "path or URL" but manifest.go only supports HTTPS URLs. Consider "path or HTTPS URL".

• [missing-doc] docs/guides/getting-started/operations.md — The Operations guide does not mention the new repos status command.

---

Labels: PR adds new Go CLI command group for per-repo installation management.

Previous run (6)

Review

Findings

Medium

• [missing-sidebar-entry] website/.vitepress/config.ts:160 — The CLI Reference sidebar includes fullsend github, fullsend inference, and fullsend mint, but does not include the new fullsend repos command. Users navigating the CLI documentation via the website sidebar will not discover the repos command documentation. AGENTS.md notes: "When adding a new doc under docs/, check website/.vitepress/config.ts sidebar config."
  Remediation: Add { text: 'fullsend repos', link: '/cli/repos' } to the CLI Reference sidebar items array after the fullsend mint entry.

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

Previous run (7)

Review

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

• [logic-error] internal/repos/status.go:102 — The summary counting logic allows a repo to be counted in both Errored and either Installed or NotInstalled, because the Error check is independent of the Installed/NotInstalled check. This means Installed + NotInstalled + Errored can exceed Total. The test suite explicitly validates this behavior as intentional, but downstream JSON consumers may assume counts partition Total. Consider documenting the non-partitioning semantics in the StatusSummary struct comment.

• [scope-creep] N/A — The PR includes 4 documentation files beyond the plan's explicit PR 4 scope. These were added to address prior review findings about missing documentation — standard practice, not a concern.

---

Labels: PR adds new Go CLI command group for per-repo installation management.

Previous run (8)

Review

Findings

Low

• [missing-authorization] N/A — This PR implements non-trivial structural changes spanning 9 files without a linked GitHub issue. The PR references ADR 0057 and the repos management plan (docs/plans/repos-management.md) as architectural authorization, which clearly authorizes this work (plan PR 4 matches scope exactly), but a GitHub issue linking the ADR to this implementation would improve traceability.

• [logic-error] internal/repos/status.go:102 — The summary counting logic allows a repo to be counted in both Errored and either Installed or NotInstalled, because the Error check is independent of the Installed/NotInstalled check. This means Installed + NotInstalled + Errored can exceed Total. The test suite explicitly validates this behavior as intentional, but downstream JSON consumers may assume counts partition Total. Consider documenting the non-partitioning semantics in the StatusSummary struct comment.

• [scope-creep] N/A — The PR includes 4 documentation files beyond the plan's explicit PR 4 scope. These were added to address prior review findings about missing documentation — standard practice, not a concern.

Previous run (9)

Review

Findings

Medium

• [logic-error] internal/repos/status.go:103 — The summary counting logic treats Error and Installed as mutually exclusive (the switch checks s.Error first), but checkRepoStatus can return a status where both Installed = true and Error != "" — this happens when the guard variable is set (marking the repo as installed) but readWorkflowRef subsequently fails at line 145. In that case, the repo is counted as Errored but not Installed, so the Installed count undercounts. The error message from renderStatusResult (e.g., "0 installed, 0 drifted, 0 not installed, 1 errored") would be misleading since the repo is actually installed.
  Remediation: Either (a) always count Installed when s.Installed is true regardless of error status, or (b) clear status.Installed in checkRepoStatus before returning when an error occurs after the guard check.

• [regex-scope] internal/repos/status.go:14 — The workflowRefPattern regex uses .* between fullsend-ai/fullsend/ and @, which is broader than needed. It could match action paths or arbitrary file paths within the fullsend repo, not just workflow file references.
  Remediation: Tighten the regex to match only expected workflow paths: uses:\s+fullsend-ai/fullsend/\.github/workflows/[^@]+@(\S+).

• [missing-doc] docs/cli/README.md:13 — The CLI documentation overview lists command groups (github, inference, mint) but does not include the new fullsend repos command group added in this PR.
  Remediation: Add a row to the Command groups table for fullsend repos.

• [missing-doc] docs/cli/repos.md — No documentation file exists for the new fullsend repos command group, unlike the existing github.md, inference.md, and mint.md.
  Remediation: Create docs/cli/repos.md documenting the repos command group, flags, and usage examples.

• [missing-doc] docs/guides/dev/cli-internals.md:6 — The CLI command tree does not include the new repos command group.
  Remediation: Add the repos command group to the CLI command tree.

Low

• [dead-code] internal/repos/status.go:79 — The indexedStatus struct is declared inside the Status function but is never used. Dead code from a previous implementation approach.

• [context-cancellation] internal/repos/status.go:88 — The semaphore send does not check ctx.Done(). If the context is cancelled, the loop continues launching goroutines for remaining repos rather than stopping early. Low impact since goroutines fail fast on cancelled context API calls.

• [error-message-format] internal/cli/repos.go:67 — Error message uses invalid manifest prefix, inconsistent with manifest.go's action-oriented prefixes.

• [error-message-format] internal/repos/status.go:68 — Error message expanding globs could include which glob for debuggability.

• [flag-description] internal/cli/repos.go:45 — Flag description says "path or URL" but manifest.go only supports HTTPS URLs. Consider "path or HTTPS URL".

• [missing-doc] docs/guides/getting-started/operations.md — The Operations guide does not mention the new repos status command.

---

Labels: PR adds new Go CLI command group for per-repo installation management.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 12:38 AM UTC · Completed 12:49 AM UTC
Commit: dfbe3ec · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 12:54 AM UTC · Completed 1:05 AM UTC
Commit: b369161 · View workflow run →

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 10:30 AM UTC · Ended 10:38 AM UTC
Commit: 0a95cac · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 10:38 AM UTC · Completed 10:48 AM UTC
Commit: 4f37867 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:26 PM UTC · Completed 1:36 PM UTC
Commit: f4ff555 · View workflow run →

[rh-hemartin]

Not sure why config.ts was changed, looks mostly style, maybe pre-commit changed it? Well, LGTM anyway.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 12:15 PM UTC · Completed 12:23 PM UTC
Commit: f4ff555 · View workflow run →

[fullsend-ai-retro]

PR #3031 added a fullsend repos status command (1889+/206- across 10 files, authored by ggallen with Claude Code). The review agent provided genuine value — its first complete review found a logic error in summary counting, unbounded goroutine creation, an overly broad regex, dead code, and 4 missing documentation locations, all promptly fixed. However, the workflow exhibited three inefficiencies: (1) the [missing-authorization] Low finding was repeated in all 9+ review iterations despite never being actionable (evidence for #1013), (2) the agent flagged [scope-creep] for docs added to fix its own prior [missing-doc] findings, and (3) the human reviewer approved 22h after agent approval with zero novel findings — only noting auto-formatter confusion in config.ts (evidence for #3068).

Proposals filed

• Evidence for #1013: missing-authorization finding repeated in all 9+ review iterations on PR #3031 (in fullsend-ai/fullsend)
• Review agent flags scope-creep for changes that remediate its own prior findings (in fullsend-ai/fullsend)
• Evidence for #3068: human review added zero novel findings on feature PR #3031 (in fullsend-ai/fullsend)