Strategic Finding
Type: roadmap-gap / ecosystem-opportunity
Horizon: mid-term
The hold-gate queue contains ~11 architect PRs, each establishing a per-repo 'single source of truth' for what is conceptually the same entity — image identity / variant matrix / arch / upstream mapping:
- common#1045 — image-name → upstream mapping
- bluefin#1165 — image-variant matrix
- bluefin-lts#553 — variant override dispatch
- server#40 — CPU-arch identity
- finpilot#292 — image-identity rename sites
- dakota#1437 — image-variant matrix
- dakota-iso#146 — host-side variant config
- dakota-iso#140 — live ISO source
- fsdk-containers#218 — elements/targets.json image_paths ownership
- actions#431 — render_pr_body source
- testsuite#773 — SSH transport source
Each PR is internally sound, but they are proceeding independently with no shared schema. The likely end-state is 9 divergent 'single sources' for overlapping identity data (image name, variant, arch, upstream) that must be kept manually consistent across repos — the same sprawl pattern already observed for tooling scripts (see common#1040).
Rationale
Image identity is the org's most cross-cutting data: it drives build matrices, promotion gates, SBOM/signing identity, docs, and tests. If each repo codifies its own variant matrix, any rename or new product line (e.g., a new bluefin-lts variant) requires N coordinated edits instead of one. A canonical schema (e.g., a machine-readable image-identity manifest in common or actions, consumed via the existing shared-workflow pattern) would make the per-repo SSOT PRs consumers rather than owners.
Proposed Next Step
Before the per-repo SSOT PRs are reviewed/merged, decide the owner of image-identity data at org level: either (a) designate common as canonical and re-scope the per-repo PRs as consumers, or (b) explicitly accept per-repo ownership with a documented consistency check in CI. A short ADR-style planning doc would settle this cheaply now; retrofitting after 9 merges will be expensive.
Filed by strategist agent (ACMM L5 — hold-gated mode)
🐝 Hive Agent: strategist | Instance: hosted-projectbluefin-knuckle-gjvq | SHA: unknown
— hive: agent=strategist backend=copilot model=kimi-k3
Strategic Finding
Type: roadmap-gap / ecosystem-opportunity
Horizon: mid-term
The hold-gate queue contains ~11 architect PRs, each establishing a per-repo 'single source of truth' for what is conceptually the same entity — image identity / variant matrix / arch / upstream mapping:
Each PR is internally sound, but they are proceeding independently with no shared schema. The likely end-state is 9 divergent 'single sources' for overlapping identity data (image name, variant, arch, upstream) that must be kept manually consistent across repos — the same sprawl pattern already observed for tooling scripts (see common#1040).
Rationale
Image identity is the org's most cross-cutting data: it drives build matrices, promotion gates, SBOM/signing identity, docs, and tests. If each repo codifies its own variant matrix, any rename or new product line (e.g., a new bluefin-lts variant) requires N coordinated edits instead of one. A canonical schema (e.g., a machine-readable image-identity manifest in common or actions, consumed via the existing shared-workflow pattern) would make the per-repo SSOT PRs consumers rather than owners.
Proposed Next Step
Before the per-repo SSOT PRs are reviewed/merged, decide the owner of image-identity data at org level: either (a) designate common as canonical and re-scope the per-repo PRs as consumers, or (b) explicitly accept per-repo ownership with a documented consistency check in CI. A short ADR-style planning doc would settle this cheaply now; retrofitting after 9 merges will be expensive.
Filed by strategist agent (ACMM L5 — hold-gated mode)
🐝 Hive Agent:
strategist| Instance:hosted-projectbluefin-knuckle-gjvq| SHA:unknown— hive: agent=strategist backend=copilot model=kimi-k3