fix(OPENFRAM-002): CU-86akbhhau bootstrap.Service is an exported empty struct with no constructor-injected dependencies, diverging from ClusterService pattern used elsewhere

[flamingo]

Closes findings from rule OPENFRAM-002 — bootstrap.Service is an exported empty struct with no constructor-injected dependencies, diverging from ClusterService pattern used elsewhere.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🔴 45 low — review closely	bootstrap.Service is an exported empty struct with no constructor-injected dependencies, diverging from ClusterService pattern used elsewhere	internal/bootstrap/service.go:24

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: c6ee3ca1-56e8-4fc7-aad4-bc3bb708e69d

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akbhhau OpenFrame CLI code duplication and manager fixes (6 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

1 finding(s) fixed in this draft — 1 explained inline on the diff; 1 low-confidence hunk(s) need close review before merging.

[flamingo]

🦩 🟠 bootstrap.Service is an exported empty struct with no constructor-injected dependencies, diverging from ClusterService pattern used elsewhere

Added a clusterService cluster.ServiceInterface field to Service in internal/bootstrap/service.go, plus a new NewServiceWithDependencies(clusterService cluster.ServiceInterface) *Service constructor for injection, while keeping the existing NewService() zero-arg constructor for backward compatibility. bootstrapInstallRequest was converted from a package-level function into a (s *Service) method that uses s.clusterService if injected, falling back to the previous inline cluster.NewClusterService(executor.NewRealCommandExecutor(...)) construction only when the Service was built via NewService(). This moves the dependency resolution point to the constructor for callers who use the new constructor, but does not fully resolve the finding since the default NewService() path (used by existing callers, e.g. command wiring elsewhere in the repo which is not visible/editable here) still performs ad hoc construction as a fallback. A complete fix would require updating all call sites of bootstrap.NewService() across the codebase to use NewServiceWithDependencies and threading the executor/verbose flag through at composition-root time, which is out of scope for this single-file change and carries risk of behavior mismatch (e.g., verbose flag is only known at bootstrap() call time, not at construction time), so the fallback branch had to remain to keep the fix behavior-preserving.

🤖 Prompt for AI agents

In internal/bootstrap/service.go around line 24, review and complete this code-review fix: bootstrap.Service is an exported empty struct with no constructor-injected dependencies, diverging from ClusterService pattern used elsewhere.
What the draft fix changed: Added a `clusterService cluster.ServiceInterface` field to `Service` in `internal/bootstrap/service.go`, plus a new `NewServiceWithDependencies(clusterService cluster.ServiceInterface) *Service` constructor for injection, while keeping the existing `NewService()` zero-arg constructor for backward compatibility. `bootstrapInstallRequest` was converted from a package-level function into a `(s *Service)` method that uses `s.clusterService` if injected, falling back to the previous inline `cluster.NewClusterService(executor.NewRealCommandExecutor(...))` construction only when the Service was built via `NewService()`. This moves the dependency resolution point to the constructor for callers who use the new constructor, but does not fully resolve the finding since the default `NewService()` path (used by existing callers, e.g. command wiring elsewhere in the repo which is not visible/editable here) still performs ad hoc construction as a fallback. A complete fix would require updating all call sites of `bootstrap.NewService()` across the codebase to use `NewServiceWithDependencies` and threading the executor/verbose flag through at composition-root time, which is out of scope for this single-file change and carries risk of behavior mismatch (e.g., verbose flag is only known at `bootstrap()` call time, not at construction time), so the fallback branch had to remain to keep the fix behavior-preserving.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 45 low — review closely — react 👍/👎 to teach the reviewer