boost(docs): 2.1 github staging plan, frontend requirements, RHDHPLAN-1513 deferment details

[gabemontero]

Hey, I just made a Pull Request!

This processed our RHDHPLAN-1505 related 2.1 stories (RHDHPLAN-1507,1508,1510,1513) against the openspec proposal/design/tasks/specs and build a set of 29 github issues to use with fullsend to code up each feature

the github issues are already opened .... we'll adjust the github issue title and content if any review feedback on their content arises

Also provide details on the frontend reqs for 1507,1508,1510,1513 outside of RHDHPLAN-1509

Lastly posts a proposal on what changes if we defer RHDHPLAN-1513 to 2.2

✔️ Checklist

• [n/a] A changeset describing the change and affected packages. (more info)
• [/] Added or Updated documentation
• [n/a] Tests for new functionality and regression tests for bug fixes
• [n/a] Screenshots attached (for UI changes)

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:34 PM UTC · Completed 8:51 PM UTC
Commit: 81e2da5 · View workflow run →

[rhdh-qodo-merge]

PR Summary by Qodo

Document Boost 2.1 staging, frontend scope, and 1513 deferral

📝 Documentation 🕐 40+ Minutes

AI Description

• Defines 29 dependency-tiered GitHub issues for four Boost 2.1 AI Catalog features.
• Maps frontend ownership against RHDHPLAN-1509 and confirms eight independently scoped UI stories.
• Documents RHDHPLAN-1513 deferral impacts and narrows RHOAI connector scope to MCP catalog.

Diagram

graph TD
  A["Frontend coverage"] -->|informs scope| C["Staging plan"] -->|starts with| D["Tier 0"] -->|unblocks| E["Tier 1"] -->|unblocks| F["Tier 2"]
  B["Connector feasibility"] -->|narrows scope| C
  G["1513 deferral"] -->|re-scopes issues| C

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Issue tracker as live authority

• ➕ Prevents status, title, and dependency details from drifting after review
• ➕ Uses GitHub Projects or Jira relationships for live progress reporting
• ➖ Provides less narrative context than the consolidated staging document
• ➖ Cross-feature scope and deferral reasoning remain harder to review together

2. Generate plans from a manifest

• ➕ Creates dependency graphs and issue summaries from one machine-readable source
• ➕ Allows automated validation of issue counts, tiers, and feature ownership
• ➖ Requires new generation and validation tooling
• ➖ Adds process overhead before implementation begins

Recommendation: Keep the analytical coverage and deferral documents, but treat the opened GitHub issues and Jira relationships as authoritative for mutable status and dependency data. For future planning rounds, a machine-readable manifest that generates the staging summary would preserve this PR's reviewable structure while reducing drift.

Files changed (8) +2095 / -20

Documentation (8) +2095 / -20

RHDHPLAN-1507-frontend-coverage.mdDocument RHDHPLAN-1507 frontend ownership +84/-0

Document RHDHPLAN-1507 frontend ownership

• Explains that RHDHPLAN-1507 is backend-only and maps every user-facing requirement to existing RHDHPLAN-1509 stories. Confirms no additional frontend Jira stories or OpenSpec changes are needed.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1507-frontend-coverage.md

RHDHPLAN-1508-frontend-coverage.mdIdentify RHDHPLAN-1508 frontend deliverables +121/-0

Identify RHDHPLAN-1508 frontend deliverables

• Separates RHDHPLAN-1509 binary entity visibility from RHDHPLAN-1508 graduated visibility and RBAC administration. Maps four independently owned frontend stories to their Jira and OpenSpec coverage.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1508-frontend-coverage.md

RHDHPLAN-1510-feasibility-report.mdNarrow RHOAI connector feasibility scope +20/-20

Narrow RHOAI connector feasibility scope

• Removes Kubeflow Model Registry integration from RHDHPLAN-1510 and assigns it to RHDHPLAN-404. Reframes RHIDP-15314 as a single-source RHOAI MCP catalog provider and clarifies shared CA configuration.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1510-feasibility-report.md

RHDHPLAN-1510-frontend-coverage.mdDocument RHDHPLAN-1510 frontend coverage +101/-0

Document RHDHPLAN-1510 frontend coverage

• Confirms connector implementation remains backend-only and that RHDHPLAN-1509 displays its ingested entities. Records RHDHPLAN-404 ownership of Model Registry integration and RHDHPLAN-1513 ownership of connector administration.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1510-frontend-coverage.md

RHDHPLAN-1513-defer-from-2-1-staging-and-jira-impact.mdAnalyze RHDHPLAN-1513 deferral impact +130/-0

Analyze RHDHPLAN-1513 deferral impact

• Maps RHDHPLAN-1513 stories across the staged issue tiers and identifies cross-feature entanglements. Determines that 21 of 29 issues can proceed while eight require a deferral decision or re-scoping.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1513-defer-from-2-1-staging-and-jira-impact.md

RHDHPLAN-1513-frontend-coverage.mdDefine RHDHPLAN-1513 frontend boundaries +135/-0

Define RHDHPLAN-1513 frontend boundaries

• Distinguishes RHDHPLAN-1513 operational administration interfaces from RHDHPLAN-1509 discovery and analytics presentation. Maps four health and connector-configuration UI stories to Jira and OpenSpec coverage.

workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1513-frontend-coverage.md

cross-feature-frontend-summary.mdSummarize frontend ownership across four features +105/-0

Summarize frontend ownership across four features

• Consolidates frontend coverage for RHDHPLAN-1507, 1508, 1510, and 1513. Identifies eight stories outside RHDHPLAN-1509 and documents interface boundaries and the RHIDP-15167 dependency hub.

workspaces/boost/specifications/JIRA-analysis/cross-feature-frontend-summary.md

rhdhplan1505-1-staged-issues.mdStage 29 implementation-ready GitHub issues +1399/-0

Stage 29 implementation-ready GitHub issues

• Defines 29 linked GitHub issues across three dependency tiers for AI asset modeling, RBAC, connectors, Neo4j, ingestion operations, and administration interfaces. Includes task-level OpenSpec mappings, Jira ownership, cross-feature dependencies, and a consolidated dependency graph.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (6) 📘 Rule violations (4) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 37 rules

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh

  Not relevant to this PR: redhat-developer/rhdh-chart

  Not relevant to this PR: redhat-developer/rhdh-operator

  Not relevant to this PR: redhat-developer/rhdh-local

1. Tier-zero integration impossible 🐞 Bug ≡ Correctness

Description

Issue 1 is dependency-free and scoped for one /fs-code run, but it requires integrating the
utility package into MCP, RHOAI, and OCI connectors whose implementations are assigned to later
issues. The Tier-0 issue therefore cannot satisfy its stated completion scope before its downstream
connector issues exist.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[55]

+Create the `@red-hat-developer-hub/backstage-plugin-boost-connector-utils` shared package providing CA bundle resolution, fault isolation wrappers (including `createSafeRefresh()` for scheduled refresh callbacks), enable/disable patterns, and configurable endpoint/credential validation. All entity-provider connectors (MCP Registry, RHOAI, OCI Skill) depend on this package. Includes reference app-config YAML for air-gapped deployment with Helm and Operator CR examples, plus connector integration tasks to wire each connector to the shared package.

Relevance

⭐⭐⭐ High

PR 3574 accepted removing dependencies on implementations that did not yet exist.

PR-#3574

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Issue 1 is declared dependency-free but requires updating all three connectors. The staged OCI and
RHOAI issues only implement and scaffold those connectors later, so adoption cannot be a Tier-0
completion criterion.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[46-55]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[114-121]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[496-535]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[747-781]

Agent prompt

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

## Issue description
Issue 1 includes adoption work for connectors that are created in later dependency tiers. Move connector-specific integration tasks into the corresponding connector issues, leaving Issue 1 responsible for the shared package, examples, and test doubles.

## Issue Context
The staging document says every issue must complete in one fullsend run and marks Issue 1 dependency-free. Its connector-integration completion criteria conflict with the later creation and implementation sequencing.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[46-55]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[114-121]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[496-535]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[747-781]

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

---

2. Connector namespaces conflict 🐞 Bug ≡ Correctness

Description

Issue 6 places deployment settings under ai-catalog.providers.<id>, while the shared
infrastructure and staged MCP/RHOAI connectors read catalog.providers.<id>. Implementing both
instructions will make connector startup, TLS, or credential configuration unavailable at the paths
consumed by those connectors.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[365]

+Define Zod connector config schemas (Jira, GitHub, GitLab) covering `boost.connectors` fields only — all fields are `configScope: db-overridable` (deployment-time fields like `credentials.*`, `tls.*`, and `namespace` live under `ai-catalog.providers.<id>.*` and are excluded from this schema entirely). Extend `RuntimeConfigResolver` to support connector config scope with two-layer merge (YAML baseline + DB overrides), 30s TTL cache with immediate invalidation, and schema validation during merge. Hot-reload propagation to connectors is in Issue 22; admin UI is in Issue 28.

Relevance

⭐⭐⭐ High

PR 3755 accepted canonical catalog.providers ownership and configuration-path alignment.

PR-#3755

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The hot-reload issue uses ai-catalog.providers, but the shared utility contract and MCP connector
schema/load calls use catalog.providers. These paths are not interchangeable configuration keys.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[356-372]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[61-87]
workspaces/boost/openspec/changes/connector-shared-infrastructure/tasks.md[5-10]
workspaces/boost/openspec/changes/mcp-registry-connector/tasks.md[36-43]

Agent prompt

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

## Issue description
Choose one connector deployment namespace and use it consistently across hot-reload, shared-infrastructure, and connector issues. Align Issue 6 with the `catalog.providers.<id>` paths currently consumed by the staged connector tasks, or update every consumer together if another namespace is intended.

## Issue Context
Issue 6 excludes deployment fields from its schema on the premise that they live under `ai-catalog.providers`, but the actual shared package examples and MCP/RHOAI tasks read `catalog.providers`.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[356-372]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[61-87]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[415-425]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[682-699]
- workspaces/boost/openspec/changes/connector-shared-infrastructure/tasks.md[5-10]
- workspaces/boost/openspec/changes/mcp-registry-connector/tasks.md[36-43]

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

---

3. Validator gate omitted 🐞 Bug ≡ Correctness

Description

Issue 2 omits the OpenSpec requirement to run the CatalogProcessor validator only for entities
carrying an rhdh.io/ai-asset-* annotation. Implemented literally, it can reject ordinary Backstage
entities because they lack the three AI annotations.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[158]

+- 1.6 Implement CatalogProcessor validator rejecting entities with missing/invalid annotations

Relevance

⭐⭐ Medium

PR 3752 partially accepted this exact AI-asset validator gating concern.

PR-#3752

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The staged task says to reject entities with missing annotations without qualification, while the
source task explicitly limits validation to entities carrying at least one AI-asset annotation.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[151-159]
workspaces/boost/openspec/changes/ai-catalog-entity-model/tasks.md[8-16]

Agent prompt

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

## Issue description
Issue 2 omits the condition limiting AI annotation validation to entities that already carry an `rhdh.io/ai-asset-*` annotation. Restore that condition so non-AI catalog entities are not rejected.

## Issue Context
The source OpenSpec explicitly gates the CatalogProcessor, but the staged GitHub issue reduces the task to rejecting all entities with missing or invalid annotations.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[151-159]
- workspaces/boost/openspec/changes/ai-catalog-entity-model/tasks.md[8-16]

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

---

View more (1)

4. Wrong utility package name 🐞 Bug ≡ Correctness

Description

Issues 10 and 13 instruct implementers to import @boost/connector-utils, but Issue 1 and the
source OpenSpecs create @red-hat-developer-hub/backstage-plugin-boost-connector-utils. Following
the staged issue text will produce unresolved package imports.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[562]

+Add multi-registry configuration support (distinct credentials, CA bundles, and sync schedules per registry instance), K8s pull secret loader with Docker `config.json` parsing, custom CA bundle integration via shared `@boost/connector-utils`, and air-gapped registry support with no external DNS resolution.

Relevance

⭐⭐ Medium

PR 3726 accepted full published names, but PR 3754 treated @boost/connector-utils as canonical.

PR-#3726
PR-#3754

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The staged connector summaries use @boost/connector-utils, whereas the package creation task and
connector source tasks consistently use the full Red Hat package name.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[553-562]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[668-678]
workspaces/boost/openspec/changes/connector-shared-infrastructure/tasks.md[3-10]
workspaces/boost/openspec/changes/mcp-registry-connector/tasks.md[34-38]

Agent prompt

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

## Issue description
Replace the nonexistent `@boost/connector-utils` references with the canonical package name created by Issue 1.

## Issue Context
The package is consistently named `@red-hat-developer-hub/backstage-plugin-boost-connector-utils` in the shared-infrastructure and connector OpenSpecs. The staged summaries for Issues 10 and 13 use a different name.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[553-562]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[668-678]
- workspaces/boost/openspec/changes/connector-shared-infrastructure/tasks.md[3-10]
- workspaces/boost/openspec/changes/mcp-registry-connector/tasks.md[34-38]

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

---

5. Analytics dependency unsupported 🐞 Bug ≡ Correctness

Description

The summary assigns an Analytics tab to RHIDP-15167 and uses that to block RHDHPLAN-1509 on
RHIDP-15335, but RHIDP-15167's OpenSpec scope contains no Analytics work and the analytics API is
staged separately in Issue 29 under RHDHPLAN-1508. This unsupported dependency makes the 1513
deferral analysis incorrectly report that RHDHPLAN-1509 is blocked.

Code

workspaces/boost/specifications/JIRA-analysis/cross-feature-frontend-summary.md[69]

+| **RHIDP-15167 depends on**        | RHIDP-15335 (RHDHPLAN-1513) | RHIDP-15167's Analytics tab (Journey 6 Step 16) consumes the per-connector health status API             | Cannot render metrics without a metrics API |

Relevance

⭐⭐⭐ High

PRs 3752 and 3755 accepted corrections aligning derived documentation with authoritative OpenSpecs.

PR-#3752
PR-#3755

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The complete RHIDP-15167 OpenSpec task section has no Analytics tab, while staged Issue 29
explicitly owns analytics APIs under RHDHPLAN-1508. The summary nevertheless attributes Analytics to
RHIDP-15167 and propagates that claim into the deferral analysis.

workspaces/boost/specifications/JIRA-analysis/cross-feature-frontend-summary.md[45-71]
workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1513-defer-from-2-1-staging-and-jira-impact.md[67-73]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[1300-1358]
workspaces/boost/openspec/changes/ai-catalog-frontend/tasks.md[37-51]

Agent prompt

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

## Issue description
Remove or correct the claim that RHIDP-15167 owns an Analytics tab and depends on RHIDP-15335. Map the analytics frontend and API to their actual Jira stories, then recalculate whether deferring RHDHPLAN-1513 blocks RHDHPLAN-1509.

## Issue Context
The repository's RHIDP-15167 task list covers summary, adoption, version, and usage components only. The staged analytics API is Issue 29 under RHDHPLAN-1508, although it separately depends on the 1513 health model.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/cross-feature-frontend-summary.md[45-71]
- workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1513-defer-from-2-1-staging-and-jira-impact.md[67-73]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[1300-1358]
- workspaces/boost/openspec/changes/ai-catalog-frontend/tasks.md[37-51]

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

---

6. Default policy lacks namespace 📘 Rule violation ⚙ Maintainability

Description

The staged implementation defines ai-catalog.rbac.defaultPolicy, which does not start with the
required boost. namespace. Following this issue plan would introduce a noncompliant application
configuration key.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[979]

+- 6.1 Add `ai-catalog.rbac.defaultPolicy` config schema (allow|deny, default: allow)

Relevance

⭐⭐ Medium

PR 3753 only partially accepted the exact ai-catalog.rbac namespace inconsistency.

PR-#3753
PR-#3755

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2401 requires application configuration keys to start with boost.. The new
staging document directs implementation of ai-catalog.rbac.defaultPolicy and multiple
catalog.providers.* schemas instead.

Rule 2401: Configuration keys must use the boost.* namespace
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[979-981]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[417-421]

Agent prompt

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

## Issue description
Application-owned configuration keys in the staged issues use `ai-catalog.*` and `catalog.providers.*` roots rather than the required `boost.*` namespace.

## Issue Context
Update schemas, examples, and planned configuration lookups together so downstream implementations use one compliant namespace.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[65-86]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[365-372]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[417-421]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[685-691]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[800-806]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[979-981]

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

---

7. Load-test dependency missing 🐞 Bug ≡ Correctness

Description

Issue 12 can start after Issues 1 and 9 even though it must validate production incremental-sync
behavior implemented by Issue 11. Unless that test is removed or explicitly made fixture-only, the
dependency graph permits the load test to run before its subject exists.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[631]

+**Depends on:** Issue 1 (shared infra), Issue 9 (core connector)

Relevance

⭐⭐ Medium

No directly relevant historical evidence found for staged load-test dependency corrections.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Issue 12's task 5.7 validates incremental sync, but Issue 11 is the staged issue that implements
digest comparison, delta mutation emission, and cache persistence. Issue 12 does not declare Issue
11 as a dependency.

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[585-617]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[626-659]

Agent prompt

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

## Issue description
Add Issue 11 as an Issue 12 dependency when the incremental-sync scale test is intended to exercise the production connector implementation. Otherwise, narrow Issue 12 so its acceptance criteria do not require functionality outside Issues 1 and 9.

## Issue Context
Issue 12 requires a 10%-churn incremental-sync performance test, while Issue 11 owns digest comparison, delta mutation, and durable cache implementation.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[585-617]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[626-659]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[1376-1380]

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

---

8. ai-catalog permissions lack prefix 📘 Rule violation ⚙ Maintainability

Description

The staged implementation defines ai-catalog.asset.read, ai-catalog.asset.read.usage-docs, and
ai-catalog.admin permission identifiers instead of the required boost.* names. Implementing
these tasks as written would violate the permission naming convention across backend and frontend
authorization checks.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[R206-208]

+- 1.2 Define `ai-catalog.asset.read` resource permission
+- 1.3 Define `ai-catalog.asset.read.usage-docs` resource permission
+- 1.4 Define `ai-catalog.admin` basic permission

Relevance

⭐ Low

PR 3755 explicitly rejected replacing ai-catalog permissions with boost-prefixed identifiers.

PR-#3755
PR-#3753

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2409 requires every permission identifier to begin with boost.. The staged tasks
explicitly introduce and register three identifiers beginning with ai-catalog. and later direct
consumers to use them.

Rule 2409: Permission identifiers must use the boost.* naming prefix
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[199-208]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[1093-1132]

Agent prompt

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

## Issue description
The staged permission identifiers use the noncompliant `ai-catalog.*` prefix instead of `boost.*`.

## Issue Context
Update definitions and all planned backend/frontend consumers consistently so the generated implementation does not introduce incompatible permission names.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[199-208]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[312-331]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[1093-1132]

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

---

9. skill lacks resource prefix 📘 Rule violation ⚙ Maintainability

Description

The OCI connector plan specifies the canonical resource type as spec.type: skill, and the RHOAI
plan similarly uses mcp-server, rather than identifiers beginning with boost-. These staged
definitions would produce resource entities that violate the required type naming convention.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505]

+Implement the core OCI Skill Registry connector: OCI Distribution Spec client for tag listing, manifest fetching, and blob download; skillcard extraction from OCI image layers with YAML parsing and SDK schema validation; entity emission as `kind: AIResource` with `spec.type: skill` and all required annotations; backend module registration with `createBackendModule`. This is the foundational OCI connector — multi-registry config, incremental sync, and load testing are separate issues.

Relevance

⭐ Low

PRs 3752 and 3755 retained skill and mcp-server as authoritative resource types.

PR-#3752
PR-#3755

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2417 requires canonical resource type identifiers to begin with boost-. The
changed staging plan explicitly prescribes spec.type: skill and spec.type: mcp-server.

Rule 2417: Prefix resource type identifiers with boost-
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505-505]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[756-765]

Agent prompt

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

## Issue description
The staged connectors emit canonical resource types without the required `boost-` prefix.

## Issue Context
Update the connector issue definitions, mapping tasks, tests, and examples consistently so emitted entities use compliant resource type identifiers.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505-543]
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[756-765]

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

---

10. AIResource is nonstandard 📘 Rule violation ≡ Correctness

Description

The OCI connector issue directs the provider to emit kind: AIResource, which is not a standard
Backstage catalog kind, and no explicit custom-kind registration is present in the repository.
Implementing this plan would cause the provider to emit entities that do not satisfy standard
catalog schemas.

Code

workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505]

+Implement the core OCI Skill Registry connector: OCI Distribution Spec client for tag listing, manifest fetching, and blob download; skillcard extraction from OCI image layers with YAML parsing and SDK schema validation; entity emission as `kind: AIResource` with `spec.type: skill` and all required annotations; backend module registration with `createBackendModule`. This is the foundational OCI connector — multi-registry config, incremental sync, and load testing are separate issues.

Relevance

⭐ Low

PR 3752 explicitly established AIResource for skills and accepted consistency fixes preserving that
kind.

PR-#3752

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2386 requires entity providers to emit standard Backstage kinds unless a custom
kind is explicitly registered and validated. The staging plan mandates AIResource, while
repository searches show no custom-kind registration or entity schema validator for it.

Rule 2386: Backstage entity providers must emit standard catalog entity kinds and shapes
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505-505]
workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[523-543]

Agent prompt

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

## Issue description
The staged OCI provider uses the unregistered nonstandard catalog kind `AIResource`.

## Issue Context
Use a standard Backstage kind such as `Resource` with a compliant `spec.type`, or explicitly add and document custom-kind registration and schema validation if a custom kind is essential.

## Fix Focus Areas
- workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md[505-543]

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

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.87%. Comparing base (e649ae6) to head (81e2da5).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4069   +/-   ##
=======================================
  Coverage   57.87%   57.87%           
=======================================
  Files        2393     2393           
  Lines       95985    95985           
  Branches    26803    26813   +10     
=======================================
  Hits        55551    55551           
  Misses      38967    38967           
  Partials     1467     1467           

Flag	Coverage Δ		*Carryforward flag
adoption-insights	84.54% <ø> (ø)		Carriedforward from e649ae6
ai-integrations	69.06% <ø> (ø)		Carriedforward from e649ae6
app-defaults	69.79% <ø> (ø)		Carriedforward from e649ae6
augment	46.67% <ø> (ø)		Carriedforward from e649ae6
boost	76.77% <ø> (ø)
bulk-import	72.55% <ø> (ø)		Carriedforward from e649ae6
cost-management	13.55% <ø> (ø)		Carriedforward from e649ae6
dcm	60.72% <ø> (ø)		Carriedforward from e649ae6
extensions	56.48% <ø> (ø)		Carriedforward from e649ae6
global-floating-action-button	71.18% <ø> (ø)		Carriedforward from e649ae6
global-header	62.17% <ø> (ø)		Carriedforward from e649ae6
homepage	47.46% <ø> (ø)		Carriedforward from e649ae6
install-dynamic-plugins	56.77% <ø> (ø)		Carriedforward from e649ae6
intelligent-assistant	74.24% <ø> (ø)		Carriedforward from e649ae6
konflux	91.98% <ø> (ø)		Carriedforward from e649ae6
lightspeed	69.02% <ø> (ø)		Carriedforward from e649ae6
mcp-integrations	83.40% <ø> (ø)		Carriedforward from e649ae6
orchestrator	66.79% <ø> (ø)		Carriedforward from e649ae6
quickstart	65.04% <ø> (ø)		Carriedforward from e649ae6
sandbox	79.56% <ø> (ø)		Carriedforward from e649ae6
scorecard	84.94% <ø> (ø)		Carriedforward from e649ae6
theme	87.90% <ø> (ø)		Carriedforward from e649ae6
translations	5.12% <ø> (ø)		Carriedforward from e649ae6
x2a	79.31% <ø> (ø)		Carriedforward from e649ae6

*This pull request uses carry forward flags. Click here to find out more.

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e649ae6...81e2da5. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fullsend-ai-review]

Review

Findings

Medium

• [stale-reference] workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1510-feasibility-report.md:180 — The "Comparison Across Features" table still describes RHIDP-15314 as "RHOAI — two-source connector," but this PR changes RHIDP-15314 to a single-source MCP-only connector (Model Registry / Kubeflow scope moved to RHDHPLAN-404). The Summary Matrix and RHIDP-15314 section body were updated, but the Comparison table was not.
  Remediation: Update the "Highest-risk epic" cell to read RHIDP-15314 (RHOAI — MCP catalog connector) to reflect the reduced scope.

Low

• [stale-reference] workspaces/boost/specifications/JIRA-analysis/RHDHPLAN-1510-frontend-coverage.md:57 — The frontend coverage table includes "View detail page for RHOAI-sourced ai-model with version info" as a RHDHPLAN-1510 frontend need, but RHDHPLAN-1510 no longer produces ai-model entities (moved to RHDHPLAN-404). The row above (line 55, browsing RHOAI models) is correctly struck through with a RHDHPLAN-404 annotation, but this row is not.
  Remediation: Strike through or add _(RHDHPLAN-404 scope)_ annotation, consistent with line 55.

• [unresolved-jira-reference] workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md — Issue 29's task group header references "group 5 (RHIDP-15344)" but RHIDP-15344 does not appear in Issue 29's RHIDP Stories line (which lists only RHIDP-15280), nor in any feature structure table across the PR.
  Remediation: Verify whether RHIDP-15344 is a real Jira story and update accordingly.

• [imprecise-terminology] workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md — The cross-feature dependencies section states the RHIDP-15167 → RHIDP-15335 dependency creates "a cross-feature cycle." The actual structure (RHIDP-15335 → RHIDP-15167 → RHIDP-15273) is a linear dependency chain, not a cycle.
  Remediation: Change "creating a cross-feature cycle" to "creating a cross-feature dependency chain."

• [naming-convention] workspaces/boost/specifications/JIRA-analysis/rhdhplan1505-1-staged-issues.md — File name deviates from the established directory convention (RHDHPLAN-XXXX-suffix.md with uppercase prefix and hyphens). All existing files use uppercase RHDHPLAN- with a hyphen before the number.
  Remediation: Consider renaming to RHDHPLAN-1505-staged-issues.md.

---

Labels: PR adds planning/specification documents under workspaces/boost/