feat(boost): RHDHPLAN-1508 openspecs

[gabemontero]

Hey, I just made a Pull Request!

These are the openspec markdowns through tasks.md for all the RHIDP epics / stories under RHDHPLAN-1508

✔️ 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)

[rhdh-qodo-merge]

Qodo is busy working

Check back in a few minutes. Qodo's code review agents are on it.

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-boost-backend	workspaces/boost/plugins/boost-backend	patch	v0.1.3
@red-hat-developer-hub/backstage-plugin-boost-common	workspaces/boost/plugins/boost-common	patch	v0.1.3

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:22 PM UTC · Completed 6:28 PM UTC
Commit: a04cf01 · View workflow run →

[rhdh-qodo-merge]

PR Summary by Qodo

docs(boost): RHDHPLAN-1508 openspecs + conditional RBAC for agent list

📝 Documentation ✨ Enhancement 🧪 Tests 🕐 40+ Minutes

AI Description

• Add OpenSpec change set for AI Catalog asset governance (RBAC, defaults, audit, admin UI).
• Upgrade boost.agent.list to a resource permission and support 3-tier (ALLOW/DENY/CONDITIONAL)
 evaluation.
• Update backend middleware, routes, and tests to use authorizeConditional() for list endpoints.

Diagram

graph TD
  O["OpenSpec: AI Catalog"] --> S["Specs + tasks"] --> R["Implementation plan"]
  F["Fine-grained spec"] --> P["boost-common perms"] --> M["Security middleware"] --> A["Agent list route"]
  M --> T["Route tests"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Treat CONDITIONAL as DENY until filtering is implemented

• ➕ Prevents a policy-bypass situation where conditional policies appear configured but are not enforced
• ➕ Simplifies reasoning: list results are either fully allowed or fully denied
• ➖ Overly restrictive; conditional policies cannot be used for visibility scoping
• ➖ May break expected deployer behavior if they rely on CONDITIONAL for list filtering

2. Implement minimal filtering now (in-memory or store-level) for known fields

• ➕ Delivers the promised conditional visibility behavior immediately
• ➕ Keeps the 3-tier model while actually enforcing conditions
• ➖ May require expanding agent records (e.g., createdBy/lifecycleStage) or adding a resource loader sooner
• ➖ Risk of duplicating logic that will later move into a proper resource loader/query layer

Recommendation: The resource-based + authorizeConditional() approach is the right long-term direction and aligns with the shared 3-tier model. However, the current route handler logs CONDITIONAL and returns unfiltered results, which can undermine deployer expectations for visibility filtering. If the agent store does not yet expose the fields needed for filtering, consider a short-term safety posture (e.g., CONDITIONAL→DENY behind a config flag) or prioritize adding the minimal resource metadata needed to enforce filters so CONDITIONAL policies have immediate effect.

Files changed (17) +1008 / -34

Enhancement (3) +77 / -23

routes.tsPlumb conditional permission criteria into the agent list route +14/-1

Plumb conditional permission criteria into the agent list route

• Imports the new 'BoostAuthorizedRequest' type and reads attached permission conditions on the list handler. Logs that filtering is deferred (TODO) until agent resources provide fields needed for applying conditions.

workspaces/boost/plugins/boost-backend/src/agents/routes.ts

security.tsUse authorizeConditional for resource list permissions and attach conditions to requests +59/-21

Use authorizeConditional for resource list permissions and attach conditions to requests

• Extends 'authorizeLifecycleAction' to use 'permissions.authorizeConditional()' for resource-scoped list endpoints (no resourceRef) and to attach returned criteria to the request. Preserves existing 'authorize()' flow for single-resource endpoints and the fallback to 'boost.admin' on denial.

workspaces/boost/plugins/boost-backend/src/middleware/security.ts

permissions.tsMake boost.agent.list resource-scoped and include in agent resource permission exports +4/-1

Make boost.agent.list resource-scoped and include in agent resource permission exports

• Adds 'resourceType: BOOST_AGENT_RESOURCE_TYPE' to 'boostAgentListPermission' and updates documentation/comments to reflect the basic vs resource permission counts. Includes the list permission in the exported 'boostAgentResourcePermissions' array.

workspaces/boost/plugins/boost-common/src/permissions.ts

Tests (2) +13 / -10

routes.test.tsUpdate agent route tests to mock authorizeConditional for list endpoints +7/-6

Update agent route tests to mock authorizeConditional for list endpoints

• Adjusts the permissions mock to resolve 'authorizeConditional()' decisions. Updates the list endpoint test to expect conditional authorization to be called and to reduce reliance on multiple 'authorize()' calls.

workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts

index.test.tsUpdate boost-common permission export tests for resource-scoped list permission +6/-4

Update boost-common permission export tests for resource-scoped list permission

• Updates expectations to account for 'boost.agent.list' moving into the resource-scoped permission set. Replaces the prior assertion about list being basic with an assertion that it has the agent resourceType.

workspaces/boost/plugins/boost-common/src/index.test.ts

Documentation (12) +918 / -1

.openspec.yamlRegister new OpenSpec change set for AI Catalog governance +2/-0

Register new OpenSpec change set for AI Catalog governance

• Adds OpenSpec metadata for the new spec-driven change, including schema type and creation date.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/.openspec.yaml

design.mdAdd AI Catalog Asset Governance design decisions +124/-0

Add AI Catalog Asset Governance design decisions

• Introduces the design doc covering permissions, graduated visibility, conditional policies, policy cascade via RBACProvider, default-deny posture, audit events, and a standalone admin UI. Captures risks/trade-offs and alignment with existing Boost permissions and augment’s 3-tier evaluation model.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/design.md

proposal.mdAdd proposal and capability impact summary for AI Catalog governance +44/-0

Add proposal and capability impact summary for AI Catalog governance

• Defines the motivation, proposed capabilities, and impacted code areas for the AI Catalog RBAC/visibility model. Explicitly calls out three new permissions and how they integrate across backend, frontend, and config.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/proposal.md

spec.mdSpecify audit logging requirements for AI Catalog governance +97/-0

Specify audit logging requirements for AI Catalog governance

• Defines required audit events for posture changes, policy CRUD, and ingestion operations. Clarifies non-duplication with RBAC plugin AuditorService and specifies structured log format requirements.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/audit-logging/spec.md

spec.mdSpecify custom conditional rules for category/connector/tenant scoping +99/-0

Specify custom conditional rules for category/connector/tenant scoping

• Defines three conditional rules, their 'apply()' behavior, and 'toQuery()' support for list endpoint filtering. Specifies rule registration and composability with Backstage criteria operators.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/conditional-policies/spec.md

spec.mdSpecify default-deny posture configuration and validation +91/-0

Specify default-deny posture configuration and validation

• Defines 'ai-catalog.rbac.defaultPolicy' behavior, per-category and per-connector overrides, and the “only new assets affected” ingestion-time boundary. Requires startup validation and warning behavior for unknown values.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/default-deny-config/spec.md

spec.mdSpecify two-tier graduated visibility permissions and filtering +101/-0

Specify two-tier graduated visibility permissions and filtering

• Defines the three permissions, resource types, field-level Tier 2 filtering, and entity-level list filtering via authorizeConditional + toQuery. Includes frontend gating expectations and performance constraints (batch evaluation).

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/graduated-visibility/spec.md

spec.mdSpecify standalone RBAC admin UI requirements for AI Catalog +100/-0

Specify standalone RBAC admin UI requirements for AI Catalog

• Defines a dedicated '/ai-catalog/admin/rbac' page gated by 'ai-catalog.admin' and using RBAC REST APIs for policy/role/condition management. Specifies required UX behavior, navigation gating, and error handling expectations.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/rbac-admin-ui/spec.md

spec.mdSpecify SkillBundle content filtering under AI Catalog RBAC +67/-0

Specify SkillBundle content filtering under AI Catalog RBAC

• Defines backend filtering of skills within a bundle based on 'ai-catalog.asset.read', including visible/total counts and no-leakage of hidden skill references. Specifies batch evaluation requirements and corresponding UI messaging.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/skillbundle-filtering/spec.md

spec.mdSpecify RBACProvider-based policy cascade to version entities +71/-0

Specify RBACProvider-based policy cascade to version entities

• Defines an 'AICatalogRBACProvider' that propagates asset-level conditional policies to version entities, supports version-specific overrides, and handles edge cases (orphan versions, asset deletion). Includes event-driven refresh/debouncing requirements.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/version-policy-cascade/spec.md

tasks.mdAdd implementation task plan for AI Catalog Asset Governance +99/-0

Add implementation task plan for AI Catalog Asset Governance

• Adds a staged task breakdown (P0/P1/P2) for permissions, backend/frontend visibility, conditional rules, RBACProvider cascade, default-deny config, audit logging, admin UI, and SkillBundle filtering. Includes explicit verification checklist items.

workspaces/boost/openspec/changes/ai-catalog-asset-governance/tasks.md

spec.mdDocument conditional list filtering and augment alignment for agent list permission +23/-1

Document conditional list filtering and augment alignment for agent list permission

• Updates the permission table to mark 'boost.agent.list' as resource-scoped and introduces a scenario describing ALLOW/DENY/CONDITIONAL list evaluation. Adds an explicit requirement to align Boost and Augment list permission evaluation models.

workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md

[fullsend-ai-review]

Review

Findings

Medium

• [fail-open] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:409 — When authorizeConditional() returns CONDITIONAL for the GET /agents endpoint, the conditions are attached to the request but never applied as filters. The handler returns all agents unfiltered. The code has a TODO comment and logger.warn() documenting this as intentional deferral, and the conditional rules (IS_OWNER, HAS_LIFECYCLE_STAGE) are not yet registered with createPermissionIntegrationRouter, so the CONDITIONAL path is currently unreachable in production. However, upgrading boost.agent.list to a ResourcePermission signals to deployers that conditional policies are supported, when they are silently ignored.
  Remediation: Either implement condition filtering before merging, return 403 when CONDITIONAL is received with unimplemented filtering, or clearly document in release notes that conditional RBAC policies on boost.agent.list are not yet enforced.

• [backward-incompatible] workspaces/boost/plugins/boost-common/src/permissions.ts:50 — boostAgentListPermission changed from BasicPermission to ResourcePermission<'boost-agent'>. This is a breaking change for any downstream consumer that types this permission as BasicPermission. The changeset marks both packages as patch but this is at minimum a minor bump for boost-common. The blast radius is limited since the boost workspace is relatively new, but the readonly tuple types for boostAgentPermissions, boostEntityPermissions, and boostPermissions all changed their first element type.
  Remediation: Change the changeset from patch to minor for boost-common. Document as a breaking change in release notes.

• [permission-expansion] workspaces/boost/plugins/boost-common/src/permissions.ts — boostAgentListPermission upgraded from BasicPermission to ResourcePermission<'boost-agent'> by adding resourceType: BOOST_AGENT_RESOURCE_TYPE. This alters how the RBAC plugin evaluates this permission. Informational flag per review protocol: any diff modifying permission definitions must produce a finding. The change is justified by the design for 3-tier evaluation and follows the documented Backstage patterns.

Low

• [backward-incompatible] workspaces/boost/plugins/boost-common/src/permissions.ts:414 — boostAgentResourcePermissions array grew from 7 to 8 elements by adding boostAgentListPermission at index 0, shifting existing elements. Impact is limited since consumers typically iterate rather than index.

• [scope-creep] workspaces/boost/plugins/boost-common/src/permissions.ts — PR title claims "openspecs" but includes functional code changes (permission type upgrade, middleware refactoring, new type export, test updates). The changeset and PR body do describe the full scope accurately.

• [naming-convention] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:145 — BoostAuthorizedRequest is defined in boost-backend and exported as @public. Since it extends Express Request (a backend-only dependency), placing it in boost-common would break the common package's framework-agnostic role. Current placement is correct.

• [stale-reference] workspaces/boost/openspec/changes/security-safety-governance/design.md:5 — References permissions.authorize() without mentioning authorizeConditional(). The PR updated the equivalent text in 6+ other files but missed this one.

• [comment-consistency] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:169 — JSDoc @param _resourceLoader says "reserved for future use", but createStoreAgentResourceLoader in routes.ts already provides a real resource loader that returns createdBy and lifecycleStage. The underscore prefix and documentation are stale.

• [test-inadequate] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts — No test for non-resource-scoped permission on a route without :id param (the permission.type !== 'resource' path). Indirectly exercised by existing tests.

• [information-disclosure] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:413 — logger.warn message reveals internal permission evaluation result in server logs. Acceptable for operational debugging; no client exposure.

Previous run

Review

Findings

High

• [fail-open] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:123 — When authorizeConditional() returns CONDITIONAL for the GET /agents list endpoint, conditions are attached to the request but never applied as filters. The route handler logs a warning and returns all agents unfiltered, treating CONDITIONAL identically to ALLOW. A deployer who configures conditional RBAC policies (e.g., IS_OWNER to restrict users to only their own agents) would find all agents returned regardless. The test explicitly validates this fail-open behavior.
  Remediation: Either (a) implement actual filtering before shipping as a patch release using applyConditions() from @backstage/plugin-permission-common, (b) keep boost.agent.list as BasicPermission until filtering is ready, or (c) clearly document in changeset/release notes that CONDITIONAL policies are not yet enforced and treat CONDITIONAL as DENY (fail-closed) as an interim measure.

• [breaking-api] workspaces/boost/plugins/boost-common/src/permissions.ts:52 — The exported constant boostAgentListPermission changes from BasicPermission to ResourcePermission<'boost-agent'>. This is a breaking type change for any downstream consumer that relies on the type being BasicPermission. The changeset classifies this as patch for both boost-common and boost-backend.
  Remediation: Consider bumping boost-common to minor rather than patch given the type narrowing change on a public export. Verify that no downstream consumers within the RHDH ecosystem explicitly type this constant as BasicPermission.

Medium

• [test-integrity] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts:564 — The test "returns all agents when authorizeConditional returns CONDITIONAL (filtering deferred)" asserts that CONDITIONAL results return all agents unfiltered. The test comment says "filtering is intentionally deferred, not fail-open," but functionally this IS fail-open: CONDITIONAL means "allowed with conditions" and the conditions are not applied. This test encodes the gap as expected behavior, which could mask missing enforcement long-term.

• [behavioral-contract-change] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:189 — The authorizeLifecycleAction middleware now branches on permission.type === 'resource' && !resourceRef to call authorizeConditional() instead of authorize(). This introduces a new CONDITIONAL result path that allows requests through with attached conditions. Route handlers consuming this middleware must now check req.boostPermissionConditions to enforce conditions.

• [scope-creep] workspaces/boost/openspec/changes/ai-catalog-asset-governance/design.md — The PR title claims "RHDHPLAN-1508 openspecs" and body says "These are the openspec markdowns." However, the PR includes substantial code changes: upgrading boost.agent.list from BasicPermission to ResourcePermission, refactoring authorizeLifecycleAction middleware, adding BoostAuthorizedRequest interface, updating tests, and adding a changeset for a patch release. These functional code changes go beyond the claimed scope.

Low

• [missing-test] workspaces/boost/plugins/boost-backend/src/middleware/security.test.ts — The middleware unit tests are not updated to cover the new authorizeConditional code path. Integration tests in routes.test.ts provide partial coverage, but no unit tests isolate the middleware's CONDITIONAL handling.

• [fail-open] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:199 — The middleware attaches conditions to the request and calls next() without verifying the downstream handler enforces them. If a future route forgets to check req.boostPermissionConditions, CONDITIONAL silently degrades to ALLOW.

• [cascading-type-change] workspaces/boost/plugins/boost-common/report.api.md — The type change on boostAgentListPermission cascades to four exported aggregate arrays (boostAgentPermissions, boostEntityPermissions, boostPermissions, boostAgentResourcePermissions). Consumers using the Permission base type are unaffected.

• [scope-creep] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md — Existing security-safety-governance openspec files are retroactively updated with the 3-tier evaluation model. Appropriate for spec consistency but not disclosed in the PR description.

• [internal-consistency] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md — The spec's "Conditional list filtering" scenario says conditions are attached "for the handler to apply as filters," but the handler does not apply them. The task list does not track implementing the actual filtering.

• [error-handling-idiom] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:129 — logger.warn() is used for a deliberately deferred feature path. logger.info() or logger.debug() would be more consistent with the codebase idiom where warn signals unexpected states.

• [missing-authorization] workspaces/boost/openspec/changes/ai-catalog-asset-governance/proposal.md — The PR references RHDHPLAN-1508 in the title but no Jira issue is linked. For a 27-file PR with code changes, linking the tracking issue provides traceability.

Previous run (2)

Review

Findings

High

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:49 — boostAgentListPermission changes from BasicPermission to ResourcePermission<'boost-agent'> by adding resourceType: BOOST_AGENT_RESOURCE_TYPE. This is a breaking type change in the public npm package @red-hat-developer-hub/backstage-plugin-boost-common. Downstream consumers that import boostAgentListPermission and use it in contexts typed as BasicPermission will get TypeScript compilation errors. The cascading effect changes the tuple types of boostAgentPermissions, boostEntityPermissions, and boostPermissions. At runtime, the Backstage permissions framework evaluates ResourcePermission through authorizeConditional() instead of authorize(), potentially changing authorization behavior for existing RBAC configurations.
  Remediation: Ensure a changeset documenting the breaking change is included (the PR checklist marks changesets as "n/a" but the API surface changed). Verify no downstream consumers type this as BasicPermission. Consider whether this warrants a major version bump or whether the pre-1.0 status of the boost workspace makes this acceptable.

• [authorization-bypass] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:126 — When authorizeConditional() returns CONDITIONAL for boost.agent.list, the middleware attaches conditions to the request but the route handler ignores them and returns all agents unfiltered. A TODO comment acknowledges filtering is "deferred until resource loader is implemented." However, the PR converts boostAgentListPermission to a ResourcePermission, making the CONDITIONAL code path live in production. Any RBAC policy that returns CONDITIONAL for boost.agent.list (e.g., IS_OWNER to restrict visibility) will be silently ignored — users see all agents regardless of policy.
  Remediation: Either (a) implement condition-based filtering before merging the permission type change, or (b) keep boostAgentListPermission as BasicPermission in this PR and convert it only when filtering is implemented.

Medium

• [scope-creep] workspaces/boost/plugins/boost-common/src/permissions.ts — The PR title says "openspecs" (documentation) but includes production code changes: permission type upgrade, middleware rewrite, new public interface, route handler modification, and test updates. The PR checklist marks tests as "n/a" despite including test changes.

• [fail-open-logging] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:130 — The CONDITIONAL non-enforcement is logged at debug level only, which is typically disabled in production. Deployers who configure conditional RBAC policies will have no indication their policies are being silently ignored.
  Remediation: Log at warn level so production deployments are alerted.

Low

• [naming-convention] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:127 — Handler parameter named _req (indicating unused) but the code reads it to access boostPermissionConditions. Should be renamed to req.
• [import-style] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:38 — BoostAuthorizedRequest uses inline type import in a mixed import statement. The file's existing pattern uses separate import type statements.
• [stale-task-description] workspaces/boost/staged-issues.md:64 — Task 2.2 description is out of sync with the updated source in tasks.md.
• [stale-permission-count] workspaces/boost/specifications/boost-frontend-architecture.md:189 — References two AI Catalog permissions but the openspec defines three (including ai-catalog.admin).
• [missing-edge-case-test] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts — Consider adding an explicit test for the authorizeConditional DENY path with separate mocks rather than relying on the generic createMockPermissions helper.
• [missing-authorization] No GitHub issue is linked. RHDHPLAN-1508 is a Jira reference; non-trivial production code changes typically require a linked GitHub issue.
• [naming-coherence] workspaces/boost/AGENTS.md:88 — Introduces a second permission namespace ai-catalog.* alongside boost.* in the same workspace. The AGENTS.md update documents this as "two namespaces by design" which is appropriate, but consider whether ai-catalog.* permissions should live in a separate package when implemented.
• [commit-message-inconsistency] The permission type change is a breaking change but commit prefixes do not signal this (no feat!: or BREAKING CHANGE footer).

Previous run (3)

Review

Findings

High

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:49 — The exported boostAgentListPermission changes from BasicPermission to ResourcePermission<'boost-agent'>. These are structurally incompatible TypeScript types. External consumers of @red-hat-developer-hub/backstage-plugin-boost-common (published at v0.1.3) that assign boostAgentListPermission to BasicPermission-typed variables or pass it to functions expecting BasicPermission will get compile-time type errors after upgrading. At runtime, code checking permission.type === 'basic' will also break.
  Remediation: Since the package is 0.x (pre-1.0 semver), breaking changes are permitted by convention. Bump version to at least 0.2.0 and document the migration in a changelog entry so external adopters know to update their code.

Medium

• [logic-error] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:125 — When authorizeConditional() returns CONDITIONAL, the middleware attaches conditions to the request, but the route handler ignores them and returns all agents unfiltered. Any RBAC policy relying on conditional evaluation (IS_OWNER, HAS_LIFECYCLE_STAGE) is silently ineffective at the handler level. The code includes an explicit TODO acknowledging this is intentionally deferred, but the use of logger.debug means deployers receive no indication their RBAC policy is not being enforced. See also: [authorization-bypass] finding at this location.
  Remediation: Either defer the permission type change until the handler applies conditions, or add a log.warn (not debug) when CONDITIONAL results are ignored and document this limitation in deployment guides.

• [authorization-bypass] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:123 — When authorizeConditional() returns CONDITIONAL for boost.agent.list, the conditions are attached to req.boostPermissionConditions but the handler discards them. A user granted only conditional access (e.g., IS_OWNER to see only their own agents) would receive the complete unfiltered agent list. Currently mitigated by the fact that the resource loader placeholder returns undefined — so no deployer can configure meaningful conditional policies yet — but once resource loaders are implemented this gap must be closed. See also: [logic-error] finding at this location.
  Remediation: Log at warn level rather than debug when CONDITIONAL results are not applied. Treat CONDITIONAL as DENY until filtering is implemented, or clearly document the limitation.

• [test-coverage-gap] workspaces/boost/plugins/boost-backend/src/middleware/security.ts — The new authorizeConditional code path in authorizeLifecycleAction is not tested in security.test.ts. All existing middleware tests use boostAgentRegisterPermission (a basic permission), exercising only the authorize() branch. The new branch is only tested via integration-level route tests in routes.test.ts.
  Remediation: Add middleware-level unit tests in security.test.ts for: (1) ALLOW from authorizeConditional, (2) CONDITIONAL attaching conditions to the request, (3) DENY falling back to admin check.

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/design.md:5 — The context paragraph and Decision 1 describe authorizeLifecycleAction as using only permissions.authorize() with a DENY-then-fallback flow. This PR adds authorizeConditional() for list endpoints with a three-outcome (ALLOW/DENY/CONDITIONAL) flow. Other parallel documents (proposal.md, spec.md, boost-context.md, AGENTS.md, PRD) were updated, but design.md was not.
  Remediation: Update design.md context paragraph and Decision 1 to mention both permissions.authorize() and permissions.authorizeConditional(), and describe the CONDITIONAL path.

Low

• [test-integrity] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts:556 — The CONDITIONAL test validates the current incomplete behavior (all agents returned) without verifying that conditions were actually attached to the request object.

• [data-exposure] workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/skillbundle-filtering/spec.md:46 — The spec exposes totalSkills alongside visibleSkills, revealing the count of hidden assets. The spec acknowledges this as an accepted trade-off and offers bundle-level default-deny as mitigation.

• [scope-mismatch] The PR title characterizes this as openspec documentation, but includes functional code changes (permission type upgrade, middleware rework, new public interface, test changes). Consider updating the title to reflect both scopes.

• [breaking-tuple-type-change] workspaces/boost/plugins/boost-common/report.api.md:89 — Cascading type changes in aggregate tuples (boostAgentPermissions, boostEntityPermissions, boostPermissions) from the boostAgentListPermission type change.

• [breaking-array-length-change] workspaces/boost/plugins/boost-common/src/permissions.ts:412 — boostAgentResourcePermissions array grows from 7 to 8 elements by adding boostAgentListPermission.

• [permission-scope-change] workspaces/boost/plugins/boost-common/src/permissions.ts:49 — Existing RBAC policies configured for boost.agent.list as a basic permission may need updating after the BasicPermission → ResourcePermission change. Verify existing ALLOW policies still produce ALLOW results after the type change.

Previous run (4)

Review

Findings

High

• [fail-open] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:409 — When authorizeConditional() returns CONDITIONAL, the conditions are attached to the request but never applied as filters — all agents are returned unfiltered, identical to ALLOW. The TODO comment at line 410 explicitly acknowledges this: “Apply conditions as filters when resource loader populates createdBy/lifecycleStage on agent records. Until then, CONDITIONAL results pass through unfiltered (same as ALLOW).” This means RBAC policies like IS_OWNER will not actually filter the list, creating a fail-open authorization bypass. See also: [breaking-type-change] finding on the permission upgrade that enables this path.
  Remediation: Either (a) implement the filtering logic now, or (b) have the middleware treat CONDITIONAL as DENY (fail-closed) until filtering is ready, or (c) at minimum log a warning (not debug) and document the gap prominently.

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:48 — boostAgentListPermission changed from BasicPermission to ResourcePermission<'boost-agent'>. In Backstage’s permission framework, BasicPermission (type: 'basic') and ResourcePermission (type: 'resource') are distinct discriminated union branches — ResourcePermission is NOT assignable to BasicPermission. Any downstream consumer that has typed a variable as BasicPermission and passes boostAgentListPermission will get a TypeScript compilation error. The API report (report.api.md) confirms the type change.
  Remediation: Document the breaking change prominently and consider whether a semver-major bump is warranted.

Medium

• [fail-open] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:202 — The authorizeLifecycleAction middleware passes CONDITIONAL results through to the handler without any guarantee that the handler will enforce the conditions. Any handler using this middleware for a resource-scoped permission without a resourceRef could silently ignore the conditions. See also: [fail-open] finding on routes.ts.
  Remediation: Consider adding a response interceptor or middleware post-handler check, or document prominently that handlers MUST check and apply boostPermissionConditions.

• [spec-error] workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/conditional-policies/spec.md:94 — The ‘not composition’ scenario states: “a deployer wants to deny access to everything except a specific category” and then configures not: isAiAssetCategory({ category: 'internal-tool' }) on an ALLOW policy. An ALLOW policy with not: isAiAssetCategory(internal-tool) means “ALLOW access when the asset is NOT internal-tool” — which grants access to everything EXCEPT internal-tool. The stated intent is the opposite.
  Remediation: Fix the scenario description to match the rule semantics, or change the rule to match the stated intent.

• [scope-mismatch] The PR title says “openspecs” and body says “openspec markdowns through tasks.md”. However, the PR contains functional code changes: boost.agent.list permission upgrade from BasicPermission to ResourcePermission, authorizeLifecycleAction middleware rewrite, new BoostAuthorizedRequest interface, route handler modification, test changes, and API report updates.
  Remediation: Either split the code changes into a separate PR, or update the PR title and description to reflect both specs and implementation.

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:354 — The readonly tuple types for boostAgentPermissions, boostEntityPermissions, and boostPermissions all changed their first element type from BasicPermission to ResourcePermission<'boost-agent'>. Any consumer that indexes at [0] or iterates into BasicPermission[] will get type errors.
  Remediation: Ensure downstream consumers are aware. Consumers using Permission[] (base union type) are unaffected.

Low

• [stale-reference] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md:99 — Line 99 states “the specific fine-grained permission is checked via permissions.authorize()” but the PR updates the same file to add authorizeConditional() for list endpoints. The line describes a single-resource scenario where authorize() is still correct, but could be clearer.

• [missing-authorization] The PR references Jira RHDHPLAN-1508 but no GitHub issue is linked. The Jira reference provides authorization context, but adding a comment explaining the Jira-only tracking model would help reviewers.

• [naming-convention-deviation] workspaces/boost/openspec/changes/ai-catalog-asset-governance/design.md:64 — The openspec proposes ai-catalog.* permissions that deviate from the established boost.* naming convention in AGENTS.md. The design document explains this as a deliberate catalog-layer distinction, but AGENTS.md should be updated to acknowledge the new namespace when implementation begins.

• [array-membership-change] workspaces/boost/plugins/boost-common/src/permissions.ts:416 — boostAgentResourcePermissions gained boostAgentListPermission at position 0 (7→8 elements). Consumers using this array for permission integration router registration will now register boost.agent.list as a resource permission requiring conditional rule handling.

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/design.md — Design document references permissions.authorize() as sole authorization mechanism but the PR adds permissions.authorizeConditional() as a parallel path. This is a historical design document, lower priority than the spec and code files (which were updated).

• [test-inadequate] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts:1229 — The new CONDITIONAL test verifies the request succeeds (200) and that authorizeConditional was called, but does not assert that the conditions object was actually attached to the request. Given that filtering is explicitly deferred, this is low priority.

• [cross-workspace-reference] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md:161 — The spec states “the augment workspace is expected to adopt the same pattern” — consider softening to “may benefit from adopting” since this is a prescriptive claim about another workspace’s implementation.

---

Labels: PR includes functional code changes (permission type upgrade, middleware rewrite, new interface) alongside documentation specs, warranting the enhancement label.

Previous run (5)

Review

Findings

High

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:49 — boostAgentListPermission changed from BasicPermission to ResourcePermission<'boost-agent'>. This is a breaking change to the public exported type. Any downstream consumer that types this value as BasicPermission will get a compile error. Code that passes boostAgentListPermission to permissions.authorize() without a resourceRef will also fail, since resource-scoped permissions require authorizeConditional() or a resourceRef. The tuple types of boostAgentPermissions, boostEntityPermissions, and boostPermissions are similarly affected (first element changed from BasicPermission to ResourcePermission<'boost-agent'>).
  Remediation: Bump to next major or minor version with a changelog entry calling out this type change. Add a migration note for consumers who reference boostAgentListPermission with the BasicPermission type.

Medium

• [logic-error] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:409 — CONDITIONAL authorization results are not applied as filters. When authorizeConditional() returns CONDITIONAL, the conditions are attached to the request but never evaluated — all agents are returned unfiltered. The code has a TODO acknowledging this is deferred until the resource loader is implemented. Risk is currently theoretical since the IS_OWNER/HAS_LIFECYCLE_STAGE rules are not yet registered with a permissionIntegrationRouter, so authorizeConditional() cannot return CONDITIONAL in practice.

• [stale-reference] workspaces/boost/specifications/prd/security-safety-governance.md:93 — Permission table lists boost.agent.list with Resource Type — and Conditional Rules —, but the code now defines it with resourceType: 'boost-agent' and conditional rules IS_OWNER, HAS_LIFECYCLE_STAGE.

• [stale-behavioral-description] workspaces/boost/specifications/prd/security-safety-governance.md:272 — Security model diagram describes authorizeLifecycleAction as performing permission checks via permissions.authorize(). The middleware now uses authorizeConditional() for list endpoints.

• [stale-behavioral-description] Multiple documentation files state "All authorization decisions use permissions.authorize()" but list endpoints now use authorizeConditional(). Affected files: specifications/prd/security-safety-governance.md:20, openspec/changes/security-safety-governance/proposal.md:19, AGENTS.md:59,110, specifications/boost-context.md:60, openspec/changes/security-safety-governance/tasks.md:14.

Low

• [test-adequacy] workspaces/boost/plugins/boost-backend/src/middleware/security.test.ts — The authorizeConditional() path in authorizeLifecycleAction is tested via integration tests in routes.test.ts but not in the middleware's own unit test file.

• [internal-consistency] workspaces/boost/openspec/changes/ai-catalog-asset-governance/design.md:99 — Decision 4 describes a timestamp-based default-deny mechanism comparing rhdh.io/ai-catalog-ingested-at against a policy-change timestamp, but no spec or task defines how the policy-change timestamp is stored or tracked.

• [edge-case] workspaces/boost/openspec/changes/ai-catalog-asset-governance/specs/skillbundle-filtering/spec.md:44 — totalSkills field reveals the count of hidden skills. The spec acknowledges this as an accepted trade-off with bundle-level hiding as mitigation.

• [missing-authorization] PR references RHDHPLAN-1508 (Jira) but has no linked GitHub issue.

• [scope-mismatch] PR title says "openspecs" but includes functional code changes (permission type change, middleware update). Consider updating the title to reflect both deliverables.

Previous run (6)

Review

Findings

Critical

• [breaking-type-change] workspaces/boost/plugins/boost-common/src/permissions.ts:43 — boostAgentListPermission changed from BasicPermission to ResourcePermission<'boost-agent'>. This is a breaking change to the public API surface of @red-hat-developer-hub/backstage-plugin-boost-common. Downstream consumers that import this permission and pass it to APIs expecting BasicPermission will get compile-time type errors. The aggregate permission arrays (boostAgentPermissions, boostEntityPermissions, boostPermissions) all changed their first element type, and boostAgentResourcePermissions grew from 7 to 8 elements. The PR checklist marks changesets as "n/a" despite this being a semver-major change.
  Remediation: Add a changeset documenting the breaking change. Coordinate with downstream consumers.

Medium

• [logic-error] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:126 — When authorizeConditional() returns CONDITIONAL for boost.agent.list, conditions are attached to the request but the route handler ignores them — it logs a debug message and returns ALL agents unfiltered. This makes CONDITIONAL results functionally identical to ALLOW, silently defeating conditional visibility policies. The TODO comment acknowledges this is intentionally deferred. Note: this path is currently unreachable in practice because createPermissionIntegrationRouter in plugin.ts does not register resourceType or rules for boost-agent, so the framework cannot produce CONDITIONAL results. See also the [api-contract] finding below.
  Remediation: Either implement the filtering logic, or keep boost.agent.list as a BasicPermission until filtering and rule registration are ready.

• [test-inadequate] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts:566 — No test coverage for the CONDITIONAL authorization path. The middleware now has three branches (ALLOW, CONDITIONAL, DENY) but only ALLOW and DENY are tested.
  Remediation: Add a test where authorizeConditional returns { result: AuthorizeResult.CONDITIONAL, conditions: {...} } and verify the request proceeds with conditions attached.

• [api-contract] workspaces/boost/plugins/boost-backend/src/plugin.ts:265 — createPermissionIntegrationRouter only passes permissions without resourceType or rules. With boost.agent.list now resource-scoped, the integration router needs to know the resource type and its conditional rules (IS_OWNER, HAS_LIFECYCLE_STAGE) for server-side condition evaluation. Without this, authorizeConditional() will never return CONDITIONAL — making the entire 3-tier evaluation infrastructure non-functional.
  Remediation: Add resourceType: BOOST_AGENT_RESOURCE_TYPE and the conditional rules to the createPermissionIntegrationRouter call, or defer the boost.agent.list upgrade until the rules are implemented.

• [scope-mismatch] — PR titled feat(boost): RHDHPLAN-1508 openspecs and described as containing "openspec markdowns," but also includes functional code changes: upgrading boost.agent.list from BasicPermission to ResourcePermission, refactoring authorizeLifecycleAction middleware for 3-tier evaluation, adding the BoostAuthorizedRequest interface, and updating tests. The openspec proposal.md even notes "already implemented in this branch."
  Remediation: Update the PR title and description to accurately reflect both the openspec documentation and the code changes, or split the code changes into a separate PR.

Low

• [behavioral-contract-change] workspaces/boost/plugins/boost-backend/src/middleware/security.ts — authorizeLifecycleAction middleware changed runtime behavior for resource-scoped permissions without resourceRef. Previously called authorize() (ALLOW/DENY only); now calls authorizeConditional() (can also return CONDITIONAL as pass-through).

• [stale-doc] workspaces/boost/AGENTS.md:59,110 — References only permissions.authorize() as the authorization method. After this PR, list endpoints also use permissions.authorizeConditional(). Line 110's prohibition ("Do not add authorization checks outside permissions.authorize()") would incorrectly flag the new pattern.

• [stale-doc] workspaces/boost/specifications/prd/security-safety-governance.md:93 — Permission table shows boost.agent.list with Resource Type ‘—’ and Conditional Rules ‘—’. Code now uses resourceType: 'boost-agent' with IS_OWNER, HAS_LIFECYCLE_STAGE rules.

• [stale-doc] workspaces/boost/specifications/prd/security-safety-governance.md:272 — Middleware description mentions only authorize(), not authorizeConditional().

• [stale-doc] workspaces/boost/specifications/boost-context.md:60 — States "All authorization decisions use permissions.authorize()"; now also uses authorizeConditional().

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/proposal.md:19 — States "All authorization decisions use permissions.authorize() from day one."

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/design.md:29 — Does not mention the authorizeConditional() path.

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/tasks.md:14 — Task 2.2 only mentions authorize().

• [naming-coherence] workspaces/boost/openspec/changes/ai-catalog-asset-governance/design.md — New AI Catalog permissions use ai-catalog.* prefix, diverging from the established boost.* convention. The design acknowledges this tension in its Risks section.

• [edge-case] workspaces/boost/plugins/boost-backend/src/middleware/security.ts — Middleware derives resourceRef from req.params.id. Routes using different param names would incorrectly trigger authorizeConditional() for single-resource endpoints.

• [comment-convention] workspaces/boost/plugins/boost-backend/src/middleware/security.ts — boostPermissionConditions property on BoostAuthorizedRequest lacks a TSDoc comment; all other public interface properties in this codebase are documented.

Previous run (7)

Review

Findings

High

• [fail-open] workspaces/boost/plugins/boost-backend/src/agents/routes.ts:123 — CONDITIONAL authorization result from authorizeConditional() is treated as ALLOW. boost.agent.list now advertises conditional rule support (resourceType: BOOST_AGENT_RESOURCE_TYPE), meaning deployers can configure IS_OWNER/HAS_LIFECYCLE_STAGE RBAC policies — but those policies silently have no effect. The middleware (security.ts:202) calls next() for CONDITIONAL without the admin fallback, and the route handler returns all agents unfiltered with only a debug log.
  Remediation: Either keep boost.agent.list as BasicPermission until filtering is implemented (preventing deployers from configuring policies that silently fail), or treat CONDITIONAL as DENY (falling through to admin check) so conditional policies deny by default until filtering works.

Medium

• [technical-accuracy] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md:161 — The "3-Tier Evaluation Model Consistency" requirement claims augment.agent.list exists with resource-based 3-tier evaluation. The augment workspace only defines augment.access and augment.admin — no such permission exists.
  Remediation: Reword as a future-intent statement or remove the cross-workspace claim.

• [permission-expansion] workspaces/boost/plugins/boost-common/src/permissions.ts:49 — boost.agent.list changed from BasicPermission to ResourcePermission. Enables conditional evaluation but conditional filtering is not implemented in this PR.

• [missing-authorization] No linked GitHub issue. The PR body references RHDHPLAN-1508 (Jira) but no GitHub issue is linked for the non-trivial code changes (permission type upgrade, middleware refactor).

• [scope-creep] workspaces/boost/plugins/boost-backend/src/middleware/security.ts — PR title/body claims "openspec markdowns" but includes non-trivial code changes: permission type upgrade from BasicPermission to ResourcePermission, middleware refactor to support authorizeConditional(), new BoostAuthorizedRequest interface, and test updates.
  Remediation: Update PR title/body to declare the code changes, or split into a separate PR.

• [breaking-api] workspaces/boost/plugins/boost-common/src/permissions.ts:53 — boostAgentListPermission changed from BasicPermission to ResourcePermission<'boost-agent'>. Breaking type change — downstream consumers typing against BasicPermission will get compile errors. Aggregated arrays (boostAgentPermissions, boostEntityPermissions, boostPermissions) also affected. boostAgentResourcePermissions grew from 7 to 8 elements. API reports are updated.
  Remediation: Ensure semver handling is appropriate and document migration path for consumers.

• [stale-doc] workspaces/boost/specifications/prd/security-safety-governance.md:93 — Permissions table shows boost.agent.list with Resource Type "—" and Conditional Rules "—". Now stale — should reflect boost-agent and IS_OWNER, HAS_LIFECYCLE_STAGE.

• [stale-doc] workspaces/boost/AGENTS.md:59 — States "All authorization decisions use permissions.authorize()" — now incomplete since list endpoints use authorizeConditional().

• [stale-doc] workspaces/boost/specifications/boost-context.md:60 — States "All authorization decisions use permissions.authorize()" — now incomplete.

• [stale-doc] workspaces/boost/specifications/prd/security-safety-governance.md:272 — Backend middleware diagram shows only permissions.authorize(). Now incomplete.

Low

• [test-inadequate] workspaces/boost/plugins/boost-backend/src/agents/routes.test.ts — No test covers the CONDITIONAL result path for GET /agents. Tests cover ALLOW, DENY, and DENY-with-admin-fallback but not CONDITIONAL.

• [stale-doc] workspaces/boost/openspec/changes/security-safety-governance/specs/fine-grained-permissions/spec.md:5 — PR modifies line 5 to mention authorizeConditional() but other references in the same file (lines 99, 112) still only mention authorize(). Internal inconsistency.

• [naming-convention] workspaces/boost/plugins/boost-backend/src/middleware/security.ts:145 — BoostAuthorizedRequest defined in middleware module but consumed in routes.ts via type assertion (_req as BoostAuthorizedRequest).

---

Labels: PR modifies security middleware (authorizeLifecycleAction) and permission definitions (boost.agent.list type change)

Previous run (8)

Review — approve

This PR contains two distinct parts: (1) upgrading boost.agent.list from a BasicPermission to a ResourcePermission<'boost-agent'> with 3-tier evaluation support in the authorizeLifecycleAction middleware, and (2) adding comprehensive OpenSpec documentation for the AI Catalog Asset Governance feature (RHDHPLAN-1508).

Code changes

The code changes are well-structured and correct:

• boost-common/src/permissions.ts — boostAgentListPermission gains resourceType: BOOST_AGENT_RESOURCE_TYPE, moving it from basic to resource-scoped. The boostAgentResourcePermissions array is updated accordingly. This is a breaking API change for consumers that type-check against BasicPermission, but the report.api.md update documents this clearly.

• boost-backend/src/middleware/security.ts — The authorizeLifecycleAction middleware is refactored to distinguish list endpoints (resource-scoped permission, no resourceRef) from single-resource endpoints. List endpoints use authorizeConditional() which can return CONDITIONAL with filter conditions, while single-resource endpoints continue using authorize(). The new BoostAuthorizedRequest interface cleanly carries conditions forward to route handlers.

• boost-backend/src/agents/routes.ts — The list handler reads conditions from the request but defers actual filtering (TODO), which is explicitly documented. This means CONDITIONAL results are currently treated as ALLOW — acceptable as incremental work.

• Tests — routes.test.ts is updated to mock authorizeConditional for the admin-fallback scenario. index.test.ts updates permission count expectations. Both correctly reflect the new behavior.

OpenSpec documentation

The OpenSpec documents are thorough and well-organized, covering graduated visibility, conditional policies, default-deny configuration, version-level policy cascade, audit logging, RBAC admin UI, and SkillBundle filtering. All specs are appropriately marked as "Draft." The fine-grained-permissions spec is updated to reflect the boost.agent.list upgrade and augment workspace alignment.

Findings

Low — Missing unit test for CONDITIONAL middleware path (security.test.ts): The authorizeLifecycleAction unit tests in security.test.ts only test basic permissions (boostAgentRegisterPermission), which always take the else branch. The new if (permission.type === 'resource' && !resourceRef) branch — particularly the CONDITIONAL path where conditions are attached to the request — has no direct unit test. The routes.test.ts covers the DENY→admin-fallback scenario, but a direct middleware test for the CONDITIONAL attachment would strengthen confidence.

Low — CONDITIONAL results not enforced in route handler (routes.ts): The agent list handler receives conditions but returns all agents unfiltered. This is documented with a clear TODO and debug log, and the design docs confirm this is incremental. Worth tracking as follow-up work.

---

Labels: PR modifies boost workspace permissions and openspec documentation

Previous run (9)

Review — approve

This PR delivers two well-scoped pieces of work:

1. OpenSpec documentation (11 new files) — comprehensive specifications for AI Catalog Asset Governance under RHDHPLAN-1508, covering graduated visibility, conditional policies, default-deny configuration, version-level policy cascade, audit logging, an RBAC admin UI, and SkillBundle filtering. The specs are well-structured with clear requirements, scenarios, and Jira traceability.

2. boost.agent.list upgrade to resource-scoped permission (7 modified files) — upgrades boostAgentListPermission from BasicPermission to ResourcePermission<'boost-agent'>, enabling 3-tier evaluation (ALLOW / DENY / CONDITIONAL) in the authorizeLifecycleAction middleware. This is the foundational change needed for the future graduated visibility work described in the specs.

Code changes — analysis

permissions.ts — boostAgentListPermission gains resourceType: BOOST_AGENT_RESOURCE_TYPE. Comment and aggregate arrays updated consistently. The API surface change in report.api.md correctly reflects BasicPermission → ResourcePermission<'boost-agent'>.

security.ts — The middleware now branches on permission.type === 'resource' && !resourceRef to call authorizeConditional() for list endpoints. CONDITIONAL results attach conditions to the request via BoostAuthorizedRequest and proceed. DENY results correctly fall through to the admin fallback in both branches. The new BoostAuthorizedRequest interface is cleanly typed and exported.

routes.ts — The list handler extracts conditions from the request and logs a debug message when CONDITIONAL results are received. Actual filtering is deferred with a clear TODO explaining the dependency on the resource loader populating createdBy/lifecycleStage. This is a reasonable incremental approach — no security regression since the current behavior already returns all agents.

Tests — createMockPermissions updated to mock authorizeConditional. The admin-fallback test correctly uses separate mocks for authorizeConditional (DENY) and authorize (ALLOW). Permission count and type assertions updated in index.test.ts.

Verdict

The code changes are correct, well-tested, and backward-compatible. The authorization flow is sound — CONDITIONAL is treated as ALLOW (with deferred filtering), and DENY still falls through to admin. The openspec documentation is thorough and provides clear implementation guidance for future work. A few minor follow-up items are noted below.

Follow-up items

• The _req parameter in the list handler (routes.ts:117) now references _req for condition extraction, but the underscore prefix conventionally signals an unused parameter. Consider renaming to req for clarity.
• No test covers the CONDITIONAL code path (where authorizeConditional returns CONDITIONAL with conditions). Consider adding one when the filtering implementation lands.
• The new .openspec.yaml at ai-catalog-asset-governance/ omits the status field that other openspec YAML files in this workspace include (e.g., security-safety-governance/.openspec.yaml has status: draft).

Previous run (10)

Review — approve

Summary

This PR adds comprehensive openspec documentation for the RHDHPLAN-1508 AI Catalog Asset Governance feature (design doc, proposal, 7 capability specs, task breakdown) and upgrades boost.agent.list from a basic permission to a resource-scoped permission with 3-tier evaluation support (ALLOW / DENY / CONDITIONAL).

Code changes

The code changes are minimal, correct, and well-tested:

boost-common/src/permissions.ts — boostAgentListPermission gains resourceType: BOOST_AGENT_RESOURCE_TYPE, making it resource-scoped. The boostAgentResourcePermissions array is updated to include it. Comment updated from "3 basic + 7 resource-scoped" to "2 basic + 8 resource-scoped".

boost-backend/src/middleware/security.ts — authorizeLifecycleAction now distinguishes list endpoints (resource-scoped permission without resourceRef) from single-resource endpoints. List endpoints call authorizeConditional() which can return CONDITIONAL with filter conditions attached to the request via BoostAuthorizedRequest. Single-resource endpoints continue using authorize() with resourceRef. The CONDITIONAL path correctly bypasses the admin fallback since CONDITIONAL is a qualified ALLOW.

boost-backend/src/agents/routes.ts — The list handler reads boostPermissionConditions from the request. Actual filtering is deferred with a clear TODO until the resource loader populates createdBy/lifecycleStage on agent records. CONDITIONAL results currently pass through unfiltered (equivalent to ALLOW), which is safe and documented.

Tests — Updated to reflect the new resource-scoped type, mock authorizeConditional for list endpoints, and verify the admin-fallback path through the conditional flow.

Openspec documentation

The 12 openspec files follow the established project conventions (matching the structure of security-safety-governance/ and other existing change sets). The design document covers 7 well-reasoned architectural decisions with clear rationale, and the 7 capability specs (graduated-visibility, conditional-policies, default-deny-config, version-policy-cascade, audit-logging, rbac-admin-ui, skillbundle-filtering) define requirements through concrete WHEN/THEN scenarios with appropriate Jira references.

Notes

• Low: The CONDITIONAL path in authorizeLifecycleAction (conditions attached to request, handler logs and passes through) is not exercised by a dedicated test case. This is acceptable given the feature is explicitly deferred, but a test verifying conditions are attached to the request would strengthen the contract for future implementers.
• Low: The createMockPermissions helper's authorizeConditional mock doesn't return a result by default on the base branch. The diff updates it to jest.fn().mockResolvedValue([{ result }]), which is correct for the new flow.

No security, correctness, or architectural concerns identified. The change is appropriately scoped and safe to merge.

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 7:29 PM UTC · Ended 7:34 PM UTC
Commit: a04cf01 · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.68%. Comparing base (a04cf01) to head (36c2fce).
⚠️ Report is 151 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3753      +/-   ##
==========================================
+ Coverage   54.65%   54.68%   +0.02%     
==========================================
  Files        2360     2362       +2     
  Lines       90140    90163      +23     
  Branches    25214    25207       -7     
==========================================
+ Hits        49270    49309      +39     
- Misses      40598    40634      +36     
+ Partials      272      220      -52     

Flag	Coverage Δ		*Carryforward flag
adoption-insights	83.70% <ø> (ø)		Carriedforward from 345855f
ai-integrations	67.53% <ø> (ø)		Carriedforward from 345855f
app-defaults	69.79% <ø> (ø)		Carriedforward from 345855f
augment	46.39% <ø> (ø)		Carriedforward from 345855f
boost	73.83% <100.00%> (+0.70%)	⬆️
bulk-import	72.46% <ø> (ø)		Carriedforward from 345855f
cost-management	14.10% <ø> (ø)		Carriedforward from 345855f
dcm	61.81% <ø> (ø)		Carriedforward from 345855f
extensions	61.53% <ø> (ø)		Carriedforward from 345855f
global-floating-action-button	71.18% <ø> (ø)		Carriedforward from 345855f
global-header	59.71% <ø> (ø)		Carriedforward from 345855f
homepage	50.23% <ø> (ø)		Carriedforward from 345855f
install-dynamic-plugins	56.77% <ø> (ø)		Carriedforward from 345855f
konflux	91.49% <ø> (ø)		Carriedforward from 345855f
lightspeed	69.02% <ø> (ø)		Carriedforward from 345855f
mcp-integrations	85.46% <ø> (ø)		Carriedforward from 345855f
orchestrator	43.74% <ø> (ø)		Carriedforward from 345855f
quickstart	65.63% <ø> (ø)		Carriedforward from 345855f
sandbox	79.56% <ø> (ø)		Carriedforward from 345855f
scorecard	82.93% <ø> (ø)		Carriedforward from 345855f
theme	61.26% <ø> (ø)		Carriedforward from 345855f
translations	7.25% <ø> (ø)		Carriedforward from 345855f
x2a	78.68% <ø> (ø)		Carriedforward from 345855f

*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 a04cf01...36c2fce. 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]

🤖 Finished Review · ❌ Failure · Started 7:29 PM UTC · Completed 7:34 PM UTC
Commit: a04cf01 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:57 PM UTC · Completed 8:02 PM UTC
Commit: a04cf01 · View workflow run →

[mareklibra]

It would be good to keep the code and spec changes in separate PRs. Anyway, not a blocker - just for clarity and focus.

As there are codechanges (not just openspec), the changeset should be included in this PR.

Other comments in code.

[gabemontero]

It would be good to keep the code and spec changes in separate PRs. Anyway, not a blocker - just for clarity and focus.

yeah the code change in this one was a bit of an anomaly, and admittedly a short cut given the dependency with subsequent openspecs

agree with the take in general ... will try to refrain from such short cuts in the future

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 6:05 PM UTC · Ended 6:24 PM UTC
Commit: e1119fe · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:52 PM UTC · Completed 3:11 PM UTC
Commit: 95b7bc9 · View workflow run →

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 6:01 PM UTC · Ended 6:41 PM UTC
Commit: 570aa70 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ❌ Failure · Started 6:01 PM UTC · Completed 6:41 PM UTC
Commit: 570aa70 · View workflow run →

[gabemontero]

Fullsend review artifacts (run 29944797092) — triage summary

Inspected 12 findings from the failed-to-post fullsend review. Compared against the 25 existing review threads on this PR.

Duplicates (8): fail-open/CONDITIONAL findings on routes.ts and security.ts (resolved 4× already), agents-md-coherence (addressed via Marek's thread), scope-creep on permissions.ts, missing GitHub issue link, intent-alignment on augment references, unused _resourceLoader parameter.

New but not actionable (3): test body assertion on admin fallback test (marginal), _req naming convention (cosmetic), security-safety-governance/design.md authorize reference (historical context, not stale).

New and actionable (1): boost-frontend-architecture.md:189 listed two AI Catalog permissions but design docs define three — missing ai-catalog.admin. Fixed in 773d6225ad.

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 8:32 PM UTC · Ended 8:36 PM UTC
Commit: d4a6aac · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ❌ Failure · Started 8:41 PM UTC · Completed 9:19 PM UTC
Commit: d4a6aac · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:24 PM UTC · Completed 9:44 PM UTC
Commit: d4a6aac · View workflow run →

[gabemontero]

ok @mareklibra your latest round of comments have been processed, a long with a few iterations of fullsend review comments

left your most recent threads unresolved in case you had more f/ups in those threads

thanks

[mareklibra]

A tiny note. Hopefully last one.

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 5:14 PM UTC · Ended 5:33 PM UTC
Commit: 36c2fce · View workflow run →

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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

Superseded by updated review

[fullsend-ai-review]

🤖 Finished Review · ❌ Failure · Started 5:14 PM UTC · Completed 5:33 PM UTC
Commit: 36c2fce · View workflow run →

[gabemontero]

Fullsend Review Artifacts — No New Actionable Findings

The fullsend /fs-code review run (actions/runs/30028507592) failed mid-run but collected artifacts before exiting. We downloaded and analyzed the fullsend-review artifact (artifact ID 8572819839). The review agent completed 1 iteration (41 turns, 124 tool calls) and produced 10 findings.

Cross-reference against existing review threads

All 10 findings are either duplicates of previously resolved threads or self-dismissing (the finding itself notes the behavior is correct/acceptable). No code changes needed.

#	Severity	Category	File	Verdict
1	medium	fail-open	routes.ts:409	Duplicate — CONDITIONAL path raised 4+ times (threads PRRT_kwDOM7E64c6Q4gzb, SrrDB, SsJvr, TE355), all resolved. By design: middleware attaches conditions to req.boostPermissionConditions, handler has documented TODO for filtering. Currently unreachable — no conditional rules registered for boost-agent.
2	medium	backward-incompatible	permissions.ts:50	Duplicate — changeset bump raised 3+ times (threads SrrDG, S92MH, TE359), all resolved. boost-common has no published versions and no external consumers.
3	medium	permission-expansion	permissions.ts	Duplicate — raised multiple times (thread SrrDL). Finding itself marks actionable: false (informational flag per review protocol).
4	low	backward-incompatible	permissions.ts:414	Duplicate — variant of #2 (array element shift). Same response: no external consumers.
5	low	scope-creep	permissions.ts	Self-dismissing — finding itself says "The changeset and PR body do describe the full scope accurately."
6	low	naming-convention	security.ts:145	Self-dismissing — finding itself says "Current placement is correct." BoostAuthorizedRequest extends Express Request (backend-only dep), so boost-backend is the right home.
7	low	stale-reference	design.md:5	Not actionable — the Context paragraph says Boost uses permissions.authorize() as the sole authorization mechanism (vs Augment's parallel auth layer). This is an architectural statement — authorizeConditional() is a specialization within the same permission framework, not a separate mechanism. The design.md text is correct at the architectural level.
8	low	comment-consistency	security.ts:169	Not actionable — JSDoc says _resourceLoader is "reserved for future use." Verified: the parameter IS genuinely unused in the middleware function body (declared at L175, never referenced in the function). The underscore prefix and JSDoc are technically correct. createStoreAgentResourceLoader is passed from routes.ts but consumed only at the route level, not inside the authorizeLifecycleAction middleware itself.
9	low	test-inadequate	routes.test.ts	Self-dismissing — finding says "Indirectly exercised by existing tests."
10	low	information-disclosure	routes.ts:413	Self-dismissing — finding says "Acceptable for operational debugging; no client exposure."

Summary

No new actionable findings beyond what was already addressed in the 32 existing resolved review threads. The review agent continues to re-raise the CONDITIONAL/fail-open finding (4th duplicate) and the breaking-type-change finding (3rd duplicate) despite prior resolutions explaining the design rationale.

[gabemontero]

ok @mareklibra your latest round of comments have been processed, and there are no additional findings from fullsend review I'm making changes for

left your most recent threads unresolved in case you had more f/ups in those threads

thanks

[mareklibra]

LGTM

[gabemontero]

ok @mareklibra approved this one for me in slack, and though the last fullsend review run failed to post an update, fullsend skills and I grabbed the feedback content from the run and its artifacts, and no new actionable items were there.

Breakdown:

All 10 findings are duplicates or non-actionable. Here's the breakdown:
     
  Medium (3) — all duplicates:
     
  1. fail-open (CONDITIONAL not enforced) — Raised 4+ times across prior runs. The CONDITIONAL path is unreachable because conditional rules (IS_OWNER, HAS_LIFECYCLE_STAGE) aren't registered yet. Documented TODO, by design.
  2. backward-incompatible (BasicPermission → ResourcePermission) — Raised 3+ times. boost-common has no published versions and no external downstream consumers — no semver/changeset concern.
  3. permission-expansion — Protocol-mandatory informational finding. Non-actionable by its own description.

  Low (7) — all duplicates or non-actionable:

  4. Array grew — Expected: the PR adds new permissions. Not actionable.
  5. Scope-creep / title mismatch — Downgraded, not actionable.
  6. Naming convention — Non-actionable by its own assessment.
  7. Stale reference (design.md:5) — Raised before. The permissions.authorize() mention is an architectural statement, not a code-level API reference.
  8. Stale JSDoc (_resourceLoader) — Raised before. Verified: parameter is genuinely unused in the middleware body, underscore prefix and "reserved for future use" JSDoc are correct.
  9. Missing test scenario — CONDITIONAL path is unreachable, so testing it would be testing dead code.
  10. Information-disclosure — Incomplete entry, not actionable.

  No changes needed. PR #3753 is clean — Marek's approval stands.

merging