chore(boost): RHDHPLAN-1505 feasibility analysis wrt current upstream capabilities#3703
chore(boost): RHDHPLAN-1505 feasibility analysis wrt current upstream capabilities#3703gabemontero wants to merge 1 commit into
Conversation
… capabilities Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: gabemontero <gmontero@redhat.com>
|
🤖 Finished Review · ✅ Success · Started 6:43 PM UTC · Completed 6:58 PM UTC |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3703 +/- ##
=======================================
Coverage 54.55% 54.55%
=======================================
Files 2349 2349
Lines 89735 89735
Branches 25135 25135
=======================================
Hits 48953 48953
Misses 40482 40482
Partials 300 300
*This pull request uses carry forward flags. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Review — RHDHPLAN-1505 feasibility analysisVerdict: Approve ✅ This PR adds four well-structured feasibility reports assessing 22 JIRA epics across four features (RHDHPLAN-1507, 1508, 1510, 1513) against the Backstage catalog and permission frameworks. The reports are documentation-only — no code, config, or workflow changes. What was reviewed
Minor observations (non-blocking)
These are all minor terminology/precision items in planning documents and do not affect the technical soundness of the feasibility assessments. Labels: PR adds feasibility specification documents in the boost workspace |
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
| | `ALLOW` / `DENY` definitive decisions | **Available** | | ||
| | `CONDITIONAL` decisions (delegated to plugin backend) | **Available** — requires `resourceType` | | ||
| | `isResourcePermission()` type narrowing | **Available** | | ||
| | Custom rules via `apply(entity, params)` → boolean | **Available** — synchronous, single entity, no external calls | |
There was a problem hiding this comment.
[low] technical-accuracy
Permission rule signature described as apply(entity, params) → boolean but the actual Backstage type is apply(resource, params) → boolean where resource is a generic type (entity in catalog context, but could be other resource types). Minor imprecision.
Suggested fix: Change apply(entity, params) to apply(resource, params) in the framework capabilities table.
|
|
||
| | Criterion | Feasible without upstream changes? | Assessment | | ||
| | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `ai-catalog.asset.read` defined via `createPermission` and registered via `permissionsRegistry.addPermissions()` | **YES** | Standard permission registration — boost already does this for its 16 lifecycle permissions | |
There was a problem hiding this comment.
[low] terminology-consistency
References '16 lifecycle permissions' but the codebase (boost-common/src/permissions.ts) calls these '16 entity permissions' (10 agent + 5 tool + 1 kagenti-infra). Terminology mismatch could confuse implementers.
Suggested fix: Use '16 entity permissions' to match the codebase naming convention.
fullsend-ai-review
Bot
added
ready-for-merge
1 participant
Hey, I just made a Pull Request!
analysis feedback for PM on what we can achieve with the current upstream capabilities for RHDHPLAN-1505's child features
✔️ Checklist