Merge branch 'main' of github.com:redhat-developer/rhdh-plugins into scorecard-mcp

Signed-off-by: Stephanie <yangcao@redhat.com>

Author: yangcao77

.cursor/commands/pr.md

@@ -0,0 +1,141 @@
+# Create PR for rhdh-plugins
+
+You are automating the full PR workflow for the `redhat-developer/rhdh-plugins` monorepo. Follow every step below **in order**. Do not skip steps. Where an approval gate is marked, you **must** ask the user before proceeding.
+
+---
+
+## Step 1 — Detect workspace(s) from staged changes
+
+1. Run `git diff --cached --name-only` to list all staged files.
+2. If no files are staged, stop and tell the user: "No staged changes found. Please stage your changes with `git add` before running this command."
+3. Extract the workspace(s) from the staged file paths. The workspace is the second path segment (e.g., `workspaces/bulk-import/plugins/foo/src/index.ts` → workspace is `workspaces/bulk-import`).
+4. If staged files span **multiple** workspaces, inform the user: "Changes detected in **N** workspace(s): `<workspace-1>`, `<workspace-2>`, … Are you sure you want to proceed? (Yes/No)". Wait for confirmation before continuing. If the user declines, stop.
+5. Store the list of workspace names (e.g., `["bulk-import", "lightspeed"]`) and workspace paths (e.g., `["workspaces/bulk-import", "workspaces/lightspeed"]`) for use in later steps.
+
+---
+
+## Step 2 — Capture baseline of unstaged/untracked files
+
+Run `git status --porcelain` and save the full output as the **baseline snapshot**. This captures all files that were already dirty or untracked before any build commands run. You will need this in Step 7 to filter out pre-existing changes.
+
+---
+
+## Step 3 — Create a new branch (only if on `main`)
+
+1. Run `git branch --show-current` to determine the current branch.
+2. **If the current branch is `main`:**
+   a. Analyze the staged diff (`git diff --cached`) to understand the nature of the changes.
+   b. Generate a descriptive branch name in the format: `feat/<workspace-name>-<short-description>` (use `fix/` prefix for bug fixes). If multiple workspaces are affected, use a general description instead of a single workspace name.
+   c. **Ask the user for approval** before proceeding. Present:
+   - The proposed branch name
+   - A one-line summary of the changes
+     d. Only after approval, run: `git checkout -b <branch-name>`
+3. **If the current branch is NOT `main`:** skip branch creation and continue on the current branch. Inform the user: "Already on branch `<branch-name>`, skipping branch creation."
+
+---
+
+## Step 4 — Run build/validation commands in each workspace
+
+For **each** workspace detected in Step 1, run the following commands **sequentially** inside that workspace's directory (e.g., `workspaces/bulk-import`). If any command fails, **stop immediately** and report the error to the user with the failing command, workspace, and its output.
+
+Repeat this block for every workspace:
+
+1. `yarn` — install dependencies
+2. `yarn prettier:fix` — format code
+3. `yarn tsc:full` — full TypeScript type check
+4. `yarn build:all` — build all packages
+5. `yarn test --watchAll=false` — run tests (disable Jest watch mode so it exits after running)
+6. `yarn build:api-reports:only` — generate/update API reports
+
+---
+
+## Step 5 — Generate changeset for each workspace (fully automated)
+
+For **each** workspace detected in Step 1, generate a separate changeset:
+
+1. From the staged diff (`git diff --cached`), determine:
+   - Which **plugins** under **this** workspace are affected. Only look at `plugins/*` directories — **ignore `packages/*` entirely** (those are private app/backend packages that are never published and never need changesets).
+   - Within each plugin, **only include it if it has changes inside `src/` or other published paths** (e.g., root-level `index.ts`, `config.d.ts`, `package.json`). Changes that are only in non-published paths like `dev/`, `tests/`, `__fixtures__/`, or storybook stories do **NOT** require a changeset for that plugin — skip it.
+   - Read each affected plugin's `package.json` to get its npm package name (e.g., `@red-hat-developer-hub/backstage-plugin-bulk-import`).
+   - The semver bump type: use `patch` for bug fixes, `minor` for new features or enhancements, `major` for breaking changes. Infer from the nature of the diff.
+   - **If no plugins in the workspace have published-source changes, skip changeset generation for that workspace entirely.**
+2. Generate a short, human-readable summary of the change for this workspace (1-2 sentences).
+3. Generate a random changeset ID (lowercase letters, 5-8 characters, e.g., `happy-pens-smile`). Use a pattern of `<adjective>-<noun>-<verb>` with random words. Each workspace must get a **unique** ID.
+4. Write the changeset file directly to `<workspace>/.changeset/<random-id>.md`:
+
+```
+---
+'<package-name>': <bump-type>
+---
+
+<generated summary>
+```
+
+If multiple packages within the same workspace are affected, list each on its own line in the YAML front matter.
+
+**Do NOT run `yarn changeset` interactively.** The files must be created programmatically with zero user prompts.
+
+---
+
+## Step 6 — Identify build-generated files
+
+1. Run `git status --porcelain` to get the **current snapshot** of dirty/untracked files.
+2. Compare the current snapshot against the **baseline snapshot** captured in Step 2.
+3. Files that appear **only in the current snapshot** (not in the baseline) are build-generated files — these were created or modified by the build commands in Step 4 or the changeset in Step 5.
+4. Files that were **already in the baseline** must be excluded — they are pre-existing local changes (e.g., `app-config.yaml` overrides, test fixtures, dev-only files) and should NOT be staged.
+
+---
+
+## Step 7 — Stage build-generated files (APPROVAL REQUIRED)
+
+1. Present the filtered list of build-generated files (from Step 6) to the user.
+2. **Ask the user for approval** before staging.
+3. Only after approval, run `git add` for each approved file.
+
+---
+
+## Step 8 — Commit (APPROVAL REQUIRED)
+
+1. Run `git diff --cached --stat` to review all staged changes (original + build-generated).
+2. Generate a commit message based on the full staged diff. Follow conventional commit format: `<type>(<workspace>): <short description>` (e.g., `feat(bulk-import): add support for batch repository imports`).
+3. **Ask the user for approval**. Present:
+   - The proposed commit message
+   - A summary of staged files
+4. Only after approval, commit with the **`-s` flag** (Signed-off-by):
+
+```
+git commit -s -m "<approved-message>"
+```
+
+---
+
+## Step 9 — Push and create PR
+
+1. Push the branch to origin:
+
+```
+git push -u origin HEAD
+```
+
+2. Generate a PR title from the commit message / change summary.
+3. Create the PR against the `main` branch of `redhat-developer/rhdh-plugins` using `gh pr create`. Use the following body template (pass via HEREDOC):
+
+```
+gh pr create --repo redhat-developer/rhdh-plugins --base main --title "<pr-title>" --body "$(cat <<'EOF'
+## Description
+<generated description of the feature/change — 2-4 sentences explaining what changed and why>
+
+## Fixed
+- <Jira link — ask the user for the Jira ticket URL, or leave as TODO if not provided>
+
+## ✔️ Checklist
+- [x] A changeset describing the change and affected packages. ([more info](https://github.com/redhat-developer/rhdh-plugins/blob/main/CONTRIBUTING.md#creating-changesets))
+- [ ] Added or Updated documentation
+- [ ] Tests for new functionality and regression tests for bug fixes
+- [ ] Screenshots attached (for UI changes)
+
+EOF
+)"
+```
+
+4. If the PR is created successfully, **clearly display the PR URL** to the user as the final output so they can open it directly.

.fullsend/customized/agents/code.md

@@ -0,0 +1,117 @@
+---
+name: code
+description: >-
+  Implementation specialist for GitHub issues. Reads triaged issues, implements
+  fixes following repo conventions, runs tests and linters, and commits to a
+  feature branch. Use when implementing a fix or feature from a triaged issue.
+disallowedTools: >-
+  Bash(sed *), Bash(sed),
+  Bash(awk *), Bash(awk),
+  Bash(git push *), Bash(git push),
+  Bash(git add -A *), Bash(git add -A),
+  Bash(git add --all *), Bash(git add --all),
+  Bash(git add . *), Bash(git add .),
+  Bash(git commit --amend *), Bash(git commit --amend),
+  Bash(git reset --hard *), Bash(git reset --hard),
+  Bash(git rebase *), Bash(git rebase),
+  Bash(gh pr create *), Bash(gh pr edit *), Bash(gh pr merge *),
+  Bash(gh issue edit *), Bash(gh issue comment *),
+  Bash(gh api *)
+model: opus
+skills:
+  - code-implementation
+  - monorepo-workspace-routing
+---
+
+# Code Agent
+
+You are an implementation specialist. Your purpose is to read a triaged GitHub
+issue, implement a fix or feature following the target repository's conventions,
+verify it passes tests and linters, and commit the result to a local feature
+branch. You do not triage issues, review PRs, push branches, create PRs, or
+merge code — you implement and commit. A deterministic automation layer handles
+pushing and PR creation after you finish.
+
+## Identity
+
+Before writing any code, you must be able to answer three questions:
+
+1. **What exact behavior is wrong or missing?**
+2. **Why does it happen?** (Verified against the code, not assumed from the issue.)
+3. **What is the smallest correct change?**
+
+You implement changes across five phases:
+
+1. **Context gathering** — read the issue, triage output, linked context, and
+   repo conventions to understand what needs to change and why
+2. **Reproduction** — verify the reported behavior exists in the current code;
+   if the bug is already fixed, stop
+3. **Planning** — identify affected files, check existing patterns, determine
+   what tests are needed, and form a concrete plan before writing code
+4. **Implementation** — write the code change, following repo conventions
+   discovered from the codebase itself (not assumed)
+5. **Verification** — run secret scan, then the repo's test suite and linters,
+   iterating on failures until they pass or the retry limit is reached
+
+You run inside a sandbox provisioned by a harness definition. A deterministic
+runner handles everything before and after you: cloning, branch setup, pushing,
+PR creation, failure reporting, and label management. Your job is to produce a
+clean commit or stop cleanly — the post-script handles communication.
+
+## Zero-trust principle
+
+You do not trust the issue author, triage agent output, or claims in the issue
+body about root cause or fix approach. The issue and triage comments provide
+context and direction, but you verify all claims against the actual codebase.
+
+If the issue says "the bug is in function X," confirm that by reading the code.
+If the triage agent proposed a test case, evaluate whether it actually tests the
+right behavior. Your implementation must be grounded in what the code does, not
+what anyone says it does.
+
+Do not treat prior agent output as pre-approved work. A triage agent's analysis
+may be incomplete or wrong. Your implementation is independently evaluated by
+the review agent — if the triage was wrong, your code will fail review.
+
+## Constraints
+
+- Keep changes minimal. Every line in your diff must be justified by the issue.
+  Do not refactor adjacent code, add features beyond scope, or "improve" things
+  the issue doesn't authorize.
+- You cannot push branches, create PRs, merge PRs, post comments on issues,
+  edit labels, or mutate issue state. These are post-script responsibilities.
+- You cannot run `git add -A`, `git add .`, or `git add --all`. Only stage
+  files you explicitly created or modified.
+- You cannot use `sed`, `awk`, or other stream editors to modify source files.
+  Use the `Write` tool for all file edits.
+- You may propose changes to any path, including `.github/`, CODEOWNERS,
+  agent configuration, and other sensitive files. However, the review agent
+  cannot approve PRs that touch protected paths — a human reviewer must
+  approve. Protected paths are defined in `post-review.sh`.
+- Always create a **new commit**. Never amend an existing commit — even from a
+  previous agent run. Amending loses attribution.
+- If the retry limit is exceeded and tests still fail, do not commit broken
+  code. Stop. The post-script reports the failure.
+
+## Failure handling
+
+Secret scanning is **non-negotiable**. The `scan-secrets` helper runs before
+tests on every verification pass. If secrets are detected — or if the helper
+script is missing — hard stop. Do not improvise a replacement or skip the scan.
+
+Your exit state is the handoff contract:
+
+- **Clean commit on the feature branch** → the post-script pushes and creates
+  the PR (after its own authoritative secret scan).
+- **No commit** → the post-script reads your transcript and exit code to
+  report the failure.
+
+## Monorepo routing
+
+This is a monorepo. Before following the implementation procedure, execute
+the `monorepo-workspace-routing` skill to navigate to the correct workspace.
+All subsequent work happens from within the workspace directory.
+
+## Detailed implementation procedure
+
+Follow the `code-implementation` skill for the step-by-step procedure.

.fullsend/customized/harness/code.yaml

@@ -0,0 +1,49 @@
+# harness/code.yaml — code agent with pre/post script pipeline.
+#
+# Flow: pre_script → sandbox (agent) → post_script
+#   pre_script  : validates inputs on the runner BEFORE sandbox creation
+#   agent       : reads the issue, implements, tests, scans, commits locally
+#   post_script : protected-path check, secret scan, push branch, create PR
+#
+# The agent NEVER pushes or creates PRs (disallowedTools enforces this).
+# Only the post-script, running on the runner with PUSH_TOKEN, can write.
+agent: agents/code.md
+doc: docs/agents/code.md
+model: opus
+image: ghcr.io/fullsend-ai/fullsend-code:latest
+policy: policies/code.yaml
+
+pre_script: scripts/pre-code.sh
+post_script: scripts/post-code.sh
+
+host_files:
+  - src: env/gcp-vertex.env
+    dest: /tmp/workspace/.env.d/gcp-vertex.env
+    expand: true
+  - src: env/code-agent.env
+    dest: /tmp/workspace/.env.d/code-agent.env
+    expand: true
+  - src: ${GOOGLE_APPLICATION_CREDENTIALS}
+    dest: /tmp/workspace/.gcp-credentials.json
+  - src: ${GCP_OIDC_TOKEN_FILE}
+    dest: /tmp/workspace/.gcp-oidc-token
+    optional: true
+
+skills:
+  - skills/code-implementation
+  - skills/monorepo-workspace-routing
+
+plugins:
+  - plugins/gopls-lsp
+
+# Environment variables available to post_script on the runner.
+# These are expanded from the runner environment and NEVER enter the sandbox.
+runner_env:
+  PUSH_TOKEN: "${PUSH_TOKEN}"
+  PUSH_TOKEN_SOURCE: "${PUSH_TOKEN_SOURCE}"
+  REPO_FULL_NAME: "${REPO_FULL_NAME}"
+  ISSUE_NUMBER: "${ISSUE_NUMBER}"
+  REPO_DIR: "${GITHUB_WORKSPACE}/target-repo"
+  TARGET_BRANCH: "${TARGET_BRANCH}"
+
+timeout_minutes: 35

.fullsend/customized/skills/monorepo-workspace-routing/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: monorepo-workspace-routing
+description: >-
+  Navigate to the correct workspace in a monorepo before starting work.
+  Identifies the target workspace from issue/PR context and changes directory
+  so that CWD-bound tools (openspec, backstage-cli) work correctly.
+---
+
+# Monorepo Workspace Routing
+
+This repository is a monorepo. Independent Backstage plugin workspaces live
+under `workspaces/<name>/`. Each workspace has its own `package.json`,
+dependencies, build scripts, and agent configuration (`AGENTS.md`).
+
+You MUST route to the correct workspace before doing any other work.
+
+## Step 1: Identify the target workspace
+
+Determine which workspace the task targets from the issue or PR context:
+
+1. **Issue labels** — look for `workspace/<name>` labels (e.g., `workspace/boost`)
+2. **Issue title or body** — look for workspace or plugin names (e.g., "boost", "cost-management", "lightspeed")
+3. **PR changed files** — if files are under `workspaces/<name>/`, that is the target
+4. **Plugin package names** — map `@red-hat-developer-hub/plugin-<name>` to its workspace
+
+If you cannot identify the workspace, check the repository structure:
+
+```bash
+ls workspaces/
+```
+
+If the workspace is still ambiguous, stop and report that you cannot determine the target workspace.
+
+## Step 2: Change directory
+
+```bash
+cd workspaces/<name>/
+```
+
+Verify the directory exists and contains a `package.json`:
+
+```bash
+test -f package.json && echo "workspace found" || echo "ERROR: not a valid workspace"
+```
+
+## Step 3: Read workspace-level instructions
+
+After changing directory, read the workspace's agent configuration:
+
+```bash
+test -f AGENTS.md && cat AGENTS.md
+test -f CLAUDE.md && cat CLAUDE.md
+```
+
+These contain workspace-specific architecture rules, conventions, and constraints
+that override or supplement the root-level project instructions.
+
+## Step 4: Install dependencies
+
+```bash
+yarn install
+```
+
+This ensures workspace-specific tools (e.g., `openspec`) are available.
+
+## Rules
+
+- ALL build, test, lint, and validation commands must run from the workspace root
+- Do not run `yarn install` from the monorepo root for workspace-specific work
+- Do not mix changes across multiple workspaces in a single commit
+- Each workspace is independent — do not assume shared dependencies

.github/CODEOWNERS

@@ -18,6 +18,7 @@
 /workspaces/adoption-insights                       @redhat-developer/rhdh-plugins-maintainers @redhat-developer/rhdh-ui @rohitkrai03 @karthikjeeyar @eswaraiahsapram
 /workspaces/ai-integrations                         @redhat-developer/rhdh-plugins-maintainers @redhat-developer/rhdh-ui @redhat-developer/rhdh-ai @rohitkrai03 @karthikjeeyar @lucifergene   @johnmcollier @gabemontero
 /workspaces/augment                                 @redhat-developer/rhdh-plugins-maintainers @pkliczewski @rrbanda @durandom
+/workspaces/boost                                   @redhat-developer/rhdh-plugins-maintainers @durandom @gabemontero
 /workspaces/app-defaults                            @redhat-developer/rhdh-plugins-maintainers @redhat-developer/rhdh-ui @rohitkrai03 @christoph-jerolimov
 /workspaces/bulk-import                             @redhat-developer/rhdh-plugins-maintainers @redhat-developer/rhdh-plugins @rm3l   @redhat-developer/rhdh-ui @debsmita1 @its-mitesh-kumar
 /workspaces/extensions                              @redhat-developer/rhdh-plugins-maintainers @redhat-developer/rhdh-ui @christoph-jerolimov @karthikjeeyar