feat(agentready): source assessment data from central repo

[CryptoRodeo]

⚠️ Pre Checklist

Please complete ALL items in this checklist, and remove before submitting

• I have read through the Contributing Documentation.
• I have added relevant tests.
• I have added relevant documentation.
• I will add labels to the PR, such as pr-type/bug-fix, pr-type/feature-development, etc.

Summary

Instead of scanning individual repos, you can scan a centralized repository holding all the agent-readiness scores.

Here's an example repo that stores assessments: https://github.com/CryptoRodeo/agentready-scores

In submissions, you'll have this directory structure:

<org>/<repo>

and in each <repo> directory you'll have an agentready assessment file. For example: https://github.com/CryptoRodeo/agentready-scores/tree/main/submissions/TSD-UI/rhtas-console-ui

This enables easy onboarding. Teams don't have to generate and commit the assessment files in their repos.

Even better, we can generate the assessment files for them! No additional action is required on their end.

Devlake setup:

You create an agentready plugin connection for a specific team. In that connection's data scope, select their specific repositories. Then all you have to do is add the connection to their project.

Here's a demo of that workflow:

data-scope-per-project-demo.mp4

Other ideas:

In the centralized repo you can automate the generation of the assessment files for each repo on a schedule (per quarter?), making it much easier to track scores over time.

We can also take this plugin's API data, create an MCP server tool and use that in the DevLake MCP server. The MCP tool can be used with an LLM to run diagnostics on a team's repo based on the agentready assessment and generate a plan to improve the score.

Does this close any open issues?

Closes KFLUXDP-1010

Signed-off-by: Bryan Ramos bramos@redhat.com
Assisted-By: Claude Opus 4.6

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 227 lines in your changes missing coverage. Please review.
✅ Project coverage is 17.77%. Comparing base (0216ea4) to head (1a9ed21).

Files with missing lines	Patch %	Lines
...er/agentready/connection-fields/project-select.tsx	0.00%	67 Missing ⚠️
...nfig-ui/src/plugins/register/agentready/config.tsx	0.00%	61 Missing ⚠️
...ady/connection-fields/github-connection-select.tsx	0.00%	39 Missing ⚠️
.../agentready/connection-fields/submissions-repo.tsx	0.00%	24 Missing ⚠️
.../agentready/connection-fields/submissions-path.tsx	0.00%	19 Missing ⚠️
...s/register/agentready/connection-fields/branch.tsx	0.00%	14 Missing ⚠️
config-ui/src/plugins/register/agentready/index.ts	0.00%	2 Missing ⚠️
config-ui/src/plugins/register/index.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main      #97       +/-   ##
===========================================
- Coverage   52.50%   17.77%   -34.74%     
===========================================
  Files         104      408      +304     
  Lines        6940    21268    +14328     
  Branches        0       14       +14     
===========================================
+ Hits         3644     3780      +136     
- Misses       3220    17412    +14192     
  Partials       76       76               

Flag	Coverage Δ
unit-tests-go	44.00% <ø> (ø)
unit-tests-python	74.36% <ø> (ø)
unit-tests-typescript	0.94% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
config-ui/src/api/plugin/index.ts	0.00% <ø> (ø)
...ins/register/agentready/connection-fields/index.ts	0.00% <ø> (ø)
...ig-ui/src/routes/project/detail/settings-panel.tsx	0.00% <ø> (ø)
config-ui/src/plugins/register/index.ts	0.00% <0.00%> (ø)
config-ui/src/plugins/register/agentready/index.ts	0.00% <0.00%> (ø)
...s/register/agentready/connection-fields/branch.tsx	0.00% <0.00%> (ø)
.../agentready/connection-fields/submissions-path.tsx	0.00% <0.00%> (ø)
.../agentready/connection-fields/submissions-repo.tsx	0.00% <0.00%> (ø)
...ady/connection-fields/github-connection-select.tsx	0.00% <0.00%> (ø)
...nfig-ui/src/plugins/register/agentready/config.tsx	0.00% <0.00%> (ø)
... and 1 more

... and 293 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Dannyb48]

/agentic_review

[qodo-app-for-konflux-ci]

Code Review by Qodo

🐞 Bugs (6) 📘 Rule violations (3) 📎 Requirement gaps (0)

Context used

✅ Tickets: KFLUXDP-1010

✅ Compliance rules (platform): 113 rules

1. io.ReadAll error ignored 📘 Rule violation ≡ Correctness ⭐ New

Description

The new GitHub fetcher code discards io.ReadAll errors via _, which can mask I/O failures and
lead to misleading error messages or incorrect control flow. This violates the requirement to check
Go function errors immediately after the call.

Code

backend/plugins/agentready/tasks/submissions_collector.go[R237-238]

+		body, _ := io.ReadAll(io.LimitReader(resp.Body, 256))
+		return nil, fmt.Errorf("GitHub Trees API returned %d: %s", resp.StatusCode, string(body))

Relevance

⭐⭐⭐ High

Error-handling/avoid-silent-failure improvements were previously accepted (e.g., add warnings/check
failures instead of ignoring errors in #82).

PR-#82

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1017 requires checking returned errors immediately. In submissions_collector.go,
io.ReadAll(...) is called and its error return value is ignored using _ in multiple newly added
code paths.

Rule 1017: Check Go function errors immediately after call
backend/plugins/agentready/tasks/submissions_collector.go[236-238]
backend/plugins/agentready/tasks/submissions_collector.go[283-286]
backend/plugins/agentready/tasks/submissions_collector.go[345-348]

Agent prompt

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

## Issue description
`io.ReadAll` errors are ignored (assigned to `_`) in the new GitHub HTTP error-handling paths.

## Issue Context
These reads happen when building error messages for non-200 HTTP responses; ignoring the read error can hide underlying transport/body-read failures and violates the immediate error-checking requirement.

## Fix Focus Areas
- backend/plugins/agentready/tasks/submissions_collector.go[236-238]
- backend/plugins/agentready/tasks/submissions_collector.go[283-286]
- backend/plugins/agentready/tasks/submissions_collector.go[345-348]

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

---

2. Invalid scope search column 🐞 Bug ≡ Correctness ⭐ New

Description

agentready/api.Init configures the DS helper scope search columns as ["fullName"], but the
paging/search code interpolates those values directly into SQL ("fullName LIKE ?"), which will fail
when a searchTerm is used because the actual DB column is snake_case (e.g., "full_name"). This can
break scope/scope-config list/search endpoints at runtime with SQL "unknown column" errors.

Code

backend/plugins/agentready/api/init.go[R32-38]

+	dsHelper = api.NewDataSourceHelper[
+		models.AgentReadyConnection, models.AgentReadyScope, models.AgentReadyScopeConfig,
+	](
+		br,
+		p.Name(),
+		[]string{"fullName"},
+		func(c models.AgentReadyConnection) models.AgentReadyConnection {

Relevance

⭐⭐⭐ High

Team has accepted fixes for broken search/runtime behavior in plugins (Codecov search #91;
agentready runtime/schema fixes #87).

PR-#91
PR-#87

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

AgentReady wires fullName as a search column, and the shared paging helper uses those strings
directly in SQL LIKE expressions; this requires real DB column names (snake_case), which is also
how other plugins configure it (e.g., GitHub uses full_name).

backend/plugins/agentready/api/init.go[30-43]
backend/helpers/srvhelper/model_service_helper.go[161-179]
backend/plugins/github/api/init.go[36-52]

Agent prompt

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

### Issue description
`api.NewDataSourceHelper(..., []string{"fullName"}, ...)` configures search columns that are later used as raw SQL identifiers in `LIKE` clauses. For GORM-managed tables (including AgentReadyScope), the `FullName` field maps to a `full_name` column by default, so using `fullName` will generate invalid SQL whenever `searchTerm` is present.

### Issue Context
Other datasource plugins (e.g., GitHub) pass snake_case DB column names (e.g. `full_name`) into `NewDataSourceHelper`.

### Fix Focus Areas
- backend/plugins/agentready/api/init.go[32-43]
- backend/helpers/srvhelper/model_service_helper.go[161-179]
- backend/plugins/github/api/init.go[39-47]

### Implementation notes
- Change AgentReady’s `scopeSearchColumns` to the actual DB column name(s), e.g. `[]string{"full_name"}` (optionally also include `"name"` if you want search-by-repo-name).
- Ensure scope-config listing search columns also remain valid (they share the same `searchColumns` list via `NewDataSourceHelper`).

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

---

3. Wrong default branch 🐞 Bug ☼ Reliability

Description

FetchGithubTree forces branch="main" whenever the connection branch is empty, so submissions
collection/scope discovery will fail or read the wrong branch for repos whose default branch is not
main. This contradicts the UI text that says leaving the field empty uses the default branch.

Code

backend/plugins/agentready/tasks/submissions_collector.go[R191-197]

+func FetchGithubTree(ctx context.Context, endpoint, fullName, branch, token string, client ...*http.Client) (*githubTreeResponse, error) {
+	if token == "" {
+		return nil, fmt.Errorf("a GitHub token is required to fetch the tree")
+	}
+	if branch == "" {
+		branch = "main"
+	}

Relevance

⭐⭐⭐ High

Hardcoded default branch caused real bugs; default-branch detection fixes were accepted in codecov
(PR82).

PR-#82

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The collector hard-codes main for empty branch, but the UI communicates the opposite behavior;
this will break repositories whose default branch is not main.

backend/plugins/agentready/tasks/submissions_collector.go[191-198]
config-ui/src/plugins/register/agentready/connection-fields/branch.tsx[40-44]
PR-#82

Agent prompt

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

### Issue description
`FetchGithubTree` currently replaces an empty `branch` with `"main"`, which breaks collection for submissions repos that use a different default branch (e.g., `master`, `trunk`).

### Issue Context
The Config-UI explicitly tells users to leave Branch empty to use the repository default branch, so the backend must not silently force `main`.

### Fix Focus Areas
- backend/plugins/agentready/tasks/submissions_collector.go[191-239]
- backend/plugins/agentready/api/remote_api.go[34-46]

### Proposed fix
1. Remove the `branch == "" -> "main"` fallback.
2. If `branch` is empty, resolve the default branch via GitHub API (e.g., `GET /repos/{owner}/{repo}` and read `default_branch`) and then call the Trees API using that branch.
3. If default-branch resolution fails, return a clear error (or at minimum log a warning and fall back explicitly, but avoid silent `main`).
4. Apply the same logic path for `RemoteScopes` since it also relies on `FetchGithubTree`.

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

---

View more (4)

4. config-ui changed outside allowed 📘 Rule violation § Compliance

Description

This PR modifies files outside the allowed owned plugin directories (backend/plugins/aireview/,
backend/plugins/codecov/, backend/plugins/testregistry/). This violates the ownership
restriction and introduces out-of-scope changes.

Code

config-ui/src/api/plugin/index.ts[21]

-import * as agentready from './agentready';

Relevance

⭐⭐⭐ High

Repo explicitly limits custom changes to owned plugins; refactors moved code to comply (PR96, PR86).

PR-#96
PR-#86

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 984 requires that every changed file path be under one of the three owned plugin directories.
The PR includes changes under config-ui/ and backend/plugins/agentready/, which are outside the
allowed prefixes.

Rule 984: Restrict code changes to owned plugin directories only
config-ui/src/api/plugin/index.ts[19-34]
backend/plugins/agentready/impl/impl.go[45-53]

Agent prompt

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

## Issue description
The PR changes files outside the allowed owned plugin directories.

## Issue Context
Rule restricts all touched paths to these prefixes only:
- `backend/plugins/aireview/`
- `backend/plugins/codecov/`
- `backend/plugins/testregistry/`

## Fix Focus Areas
- config-ui/src/api/plugin/index.ts[18-34]
- backend/plugins/agentready/impl/impl.go[45-53]

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

---

5. UI entities prevent subtasks 🐞 Bug ≡ Correctness

Description

Config-UI sets AgentReady scopeConfig.entities to ["CICD"], but AgentReady subtasks are registered
under DOMAIN_TYPE_CODE, so pipeline planning will select zero enabled subtasks and the plugin won’t
run by default. This makes newly created AgentReady connections/scopes appear to do nothing.

Code

config-ui/src/plugins/register/agentready/config.tsx[R87-93]

+  dataScope: {
+    title: 'Repositories',
+  },
+  scopeConfig: {
+    entities: ['CICD'],
+    transformation: {},
+  },

Relevance

⭐⭐ Medium

No historical evidence found about UI entities/domain-type mismatch affecting subtask selection for
plugins.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The UI requests the CICD domain type, but the subtasks are CODE-only; the pipeline planner filters
by domain type so none of AgentReady’s subtasks will be selected.

config-ui/src/plugins/register/agentready/config.tsx[87-93]
backend/plugins/agentready/tasks/submissions_collector.go[22-28]
backend/plugins/agentready/api/blueprint_v200.go[45-48]
backend/helpers/pluginhelper/api/pipeline_plan.go[32-55]

Agent prompt

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

### Issue description
The UI config registers AgentReady `scopeConfig.entities` as `['CICD']`, but the backend subtasks are `DomainTypes: [DOMAIN_TYPE_CODE]`. The pipeline planner filters subtasks by the requested entities, resulting in an empty task.

### Issue Context
`MakePipelinePlanSubtasks` only includes subtasks whose `DomainTypes` appear in the requested `entities` list.

### Fix Focus Areas
- config-ui/src/plugins/register/agentready/config.tsx[87-93]
- backend/plugins/agentready/tasks/submissions_collector.go[22-28]
- backend/plugins/agentready/api/blueprint_v200.go[45-48]

### Proposed fix
1. Change the default entities to `['CODE']` for AgentReady.
2. (Optional) If AgentReady should be configurable, ensure the UI offers valid domain-type selections and defaults to `CODE` so collection runs out of the box.

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

---

6. Assessment API ignores connection 🐞 Bug ⛨ Security

Description

Assessment and finding records are now keyed by (id, connection_id), but the assessments API queries
by id/assessment_id only, so it can return incorrect or cross-connection data when the same
assessment id exists under multiple AgentReady connections. This is also a data isolation issue
because one connection’s data can be surfaced through another connection’s API usage.

Code

backend/plugins/agentready/api/assessments.go[R78-83]

func GetAssessment(input *plugin.ApiResourceInput) (*plugin.ApiResourceOutput, errors.Error) {
+	db := basicRes.GetDal()
+
	id := input.Params["id"]
	var assessment models.AgentReadyAssessment
	err := db.First(&assessment, dal.Where("id = ?", id))

Relevance

⭐⭐ Medium

No direct precedent for adding connection_id filter in agentready assessment API; isolation valued
generally (PR78).

PR-#78

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The models declare connection_id as part of the primary key, but the API does not use it in WHERE
clauses, which makes lookups ambiguous across connections.

backend/plugins/agentready/models/assessment.go[9-16]
backend/plugins/agentready/models/finding.go[7-14]
backend/plugins/agentready/api/assessments.go[78-99]
backend/plugins/agentready/api/assessments.go[111-129]

Agent prompt

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

### Issue description
`GetAssessment` and `GetAssessmentFindings` fetch rows without constraining by `connection_id`, even though the tool-layer tables use composite primary keys `(id, connection_id)`.

### Issue Context
- `AgentReadyAssessment.ConnectionId` and `AgentReadyFinding.ConnectionId` are part of the primary key.
- API endpoints currently accept only `:id` and query by `id` / `assessment_id`.

### Fix Focus Areas
- backend/plugins/agentready/api/assessments.go[78-143]
- backend/plugins/agentready/api/stats.go[22-77]

### Proposed fix
1. Introduce a required `connectionId` parameter for these endpoints (either as a query param or by adding connection-scoped routes like `/connections/:connectionId/assessments/...`).
2. Update queries:
  - `GetAssessment`: `WHERE id = ? AND connection_id = ?`
  - `GetAssessment` findings query: `WHERE assessment_id = ? AND connection_id = ?`
  - `GetAssessmentFindings`: `WHERE assessment_id = ? AND connection_id = ?`
  - `GetAssessments` list: when filtering by `repoId`, also filter by `connection_id` (or ensure uniqueness constraints make it safe).
3. If keeping backwards compatibility, reject requests missing `connectionId` with `400 BadInput` to avoid returning ambiguous data.

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

---

7. blueprint_v200.go missing license header 📘 Rule violation § Compliance

Description

New Go files added in this PR do not include the required Apache 2.0 license header at the top of
the file. This can create licensing/compliance issues for distribution and auditing.

Code

backend/plugins/agentready/api/blueprint_v200.go[1]

+package api

Relevance

⭐⭐ Medium

No clear historical evidence in this fork that missing Apache header on new Go files gets enforced.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 989 requires the Apache 2.0 header at the very top of newly added Go files. These newly added
Go files start immediately with package ..., demonstrating the header is missing.

Rule 989: Require Apache 2.0 license header in new Go files
backend/plugins/agentready/api/blueprint_v200.go[1-3]
backend/plugins/agentready/models/connection.go[1-4]
backend/plugins/agentready/tasks/submissions_collector.go[1-3]

Agent prompt

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

## Issue description
New `.go` files begin with `package ...` and are missing the required Apache 2.0 license header comment block.

## Issue Context
The repository requires the Apache 2.0 header to appear at the very top of each newly added Go file, before the `package` declaration.

## Fix Focus Areas
- backend/plugins/agentready/api/blueprint_v200.go[1-5]
- backend/plugins/agentready/models/connection.go[1-5]
- backend/plugins/agentready/tasks/submissions_collector.go[1-5]

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

---

8. TODO context in API 🐞 Bug ☼ Reliability ⭐ New

Description

RemoteScopes and connection-related handlers use context.TODO() for outbound GitHub requests, so
HTTP request cancellation/deadlines from the incoming API call will not propagate. This can leave
work running after client disconnects and waste resources under load.

Code

backend/plugins/agentready/api/remote_api.go[56]

+	treeResp, fetchErr := tasks.FetchGithubTree(gocontext.TODO(), endpoint, connection.SubmissionsRepo, branch, ghConn.Token)

Relevance

⭐⭐ Medium

No historical review evidence found about replacing context.TODO() with request contexts for
cancellation/deadlines in handlers.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The code explicitly uses gocontext.TODO() for GitHub calls inside API handlers, even though the
API input includes Request *http.Request which provides the appropriate cancellable context to
use.

backend/plugins/agentready/api/remote_api.go[33-60]
backend/plugins/agentready/api/connection.go[78-111]
backend/plugins/agentready/api/connection.go[152-163]
backend/core/plugin/plugin_api.go[28-35]

Agent prompt

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

### Issue description
Several API handlers create outbound GitHub calls using `context.TODO()` instead of using the incoming HTTP request context. This prevents cancellation/deadlines from propagating and may keep work running after the client disconnects.

### Issue Context
`plugin.ApiResourceInput` carries the incoming `*http.Request`, which provides a cancellable context (`input.Request.Context()`).

### Fix Focus Areas
- backend/plugins/agentready/api/remote_api.go[33-60]
- backend/plugins/agentready/api/connection.go[78-111]
- backend/plugins/agentready/api/connection.go[152-163]
- backend/core/plugin/plugin_api.go[28-35]

### Implementation notes
- In `RemoteScopes`, replace `gocontext.TODO()` with `input.Request.Context()` (or a derived `context.WithTimeout` if you want an explicit cap).
- Thread a `context.Context` down into `resolveDefaultBranch` / `testAgentReadyConnection` (e.g., accept `ctx context.Context` as a parameter) and use it for `FetchDefaultBranch` / `NewApiClient`.
- Avoid introducing a global context; always derive from the request when inside an API handler.

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

---

9. PK migration not applied 🐞 Bug ☼ Reliability

Description

The schema now models composite primary keys including connection_id, but the migration uses
AutoMigrateTables which does not update existing primary key constraints, so pre-existing AgentReady
tables will not be brought into alignment with the new GORM models. This can break CreateOrUpdate
semantics and prevents the intended (id, connection_id) uniqueness on upgraded installations.

Code

backend/plugins/agentready/models/migrationscripts/init_schema.go[R117-126]

func (script *initSchema) Up(basicRes context.BasicRes) errors.Error {
	return migrationhelper.AutoMigrateTables(
		basicRes,
-		&agentReadyAssessment20260511{},
-		&agentReadyFinding20260511{},
-		&agentReadyMetric20260511{},
-		&agentReadyScopeConfig20260511{},
+		&agentReadyConnection20260604{},
+		&agentReadyScope20260604{},
+		&agentReadyScopeConfig20260604{},
+		&agentReadyAssessment20260604{},
+		&agentReadyFinding20260604{},
+		&agentReadyMetric20260604{},
	)

Relevance

⭐⭐⭐ High

Team previously fixed agentready migration/model schema mismatches; likely to accept PK migration
issue (PR87).

PR-#87

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The migration only calls AutoMigrate, and AutoMigrate does not change PK constraints; meanwhile the
models and migration structs declare connection_id as part of primary keys.

backend/plugins/agentready/models/migrationscripts/init_schema.go[117-131]
backend/plugins/agentready/models/assessment.go[9-16]
backend/helpers/migrationhelper/migrationhelper.go[35-46]
backend/plugins/agentready/models/migrationscripts/register.go[7-11]

Agent prompt

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

### Issue description
`initSchema.Up` relies on `migrationhelper.AutoMigrateTables`, but `AutoMigrate` does not alter existing primary keys. The models have been changed to composite PKs (e.g., `(id, connection_id)`), so upgrades from an existing AgentReady deployment will not get the new PK constraints.

### Issue Context
This plugin already has persisted tool tables (`_tool_agentready_*`). Without explicit `ALTER TABLE ... DROP/ADD PRIMARY KEY ...`, existing DBs keep the old PK definitions.

### Fix Focus Areas
- backend/plugins/agentready/models/migrationscripts/init_schema.go[117-131]
- backend/plugins/agentready/models/migrationscripts/register.go[7-11]
- backend/helpers/migrationhelper/migrationhelper.go[35-46]

### Proposed fix
1. Add a new migration script with a higher Version() than `20260604000001`.
2. In that migration, for each affected table:
  - Add missing `connection_id` columns where needed.
  - Backfill `connection_id` for findings/metrics if upgrading from older rows (e.g., join on assessment_id to assessments).
  - Drop existing PK and add the intended composite PK (`ADD PRIMARY KEY (connection_id, id)` or `(id, connection_id)` consistently with model tags).
  - Handle MySQL vs Postgres similarly to the existing pattern in `sonarqube` migrations.
3. Register the new migration in `migrationscripts/register.go`.

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

---

Previous review results

Review updated until commit 1a9ed21

Results up to commit 7499c2f

🐞 Bugs (4) 📘 Rule violations (2) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0)

1. config-ui changed outside allowed 📘 Rule violation § Compliance

Description

This PR modifies files outside the allowed owned plugin directories (backend/plugins/aireview/,
backend/plugins/codecov/, backend/plugins/testregistry/). This violates the ownership
restriction and introduces out-of-scope changes.

Code

config-ui/src/api/plugin/index.ts[21]

-import * as agentready from './agentready';

Relevance

⭐⭐⭐ High

Repo explicitly limits custom changes to owned plugins; refactors moved code to comply (PR96, PR86).

PR-#96
PR-#86

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 984 requires that every changed file path be under one of the three owned plugin directories.
The PR includes changes under config-ui/ and backend/plugins/agentready/, which are outside the
allowed prefixes.

Rule 984: Restrict code changes to owned plugin directories only
config-ui/src/api/plugin/index.ts[19-34]
backend/plugins/agentready/impl/impl.go[45-53]

Agent prompt

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

## Issue description
The PR changes files outside the allowed owned plugin directories.

## Issue Context
Rule restricts all touched paths to these prefixes only:
- `backend/plugins/aireview/`
- `backend/plugins/codecov/`
- `backend/plugins/testregistry/`

## Fix Focus Areas
- config-ui/src/api/plugin/index.ts[18-34]
- backend/plugins/agentready/impl/impl.go[45-53]

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

---

2. Wrong default branch 🐞 Bug ☼ Reliability

Description

FetchGithubTree forces branch="main" whenever the connection branch is empty, so submissions
collection/scope discovery will fail or read the wrong branch for repos whose default branch is not
main. This contradicts the UI text that says leaving the field empty uses the default branch.

Code

backend/plugins/agentready/tasks/submissions_collector.go[R191-197]

+func FetchGithubTree(ctx context.Context, endpoint, fullName, branch, token string, client ...*http.Client) (*githubTreeResponse, error) {
+	if token == "" {
+		return nil, fmt.Errorf("a GitHub token is required to fetch the tree")
+	}
+	if branch == "" {
+		branch = "main"
+	}

Relevance

⭐⭐⭐ High

Hardcoded default branch caused real bugs; default-branch detection fixes were accepted in codecov
(PR82).

PR-#82

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The collector hard-codes main for empty branch, but the UI communicates the opposite behavior;
this will break repositories whose default branch is not main.

backend/plugins/agentready/tasks/submissions_collector.go[191-198]
config-ui/src/plugins/register/agentready/connection-fields/branch.tsx[40-44]
PR-#82

Agent prompt

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

### Issue description
`FetchGithubTree` currently replaces an empty `branch` with `"main"`, which breaks collection for submissions repos that use a different default branch (e.g., `master`, `trunk`).

### Issue Context
The Config-UI explicitly tells users to leave Branch empty to use the repository default branch, so the backend must not silently force `main`.

### Fix Focus Areas
- backend/plugins/agentready/tasks/submissions_collector.go[191-239]
- backend/plugins/agentready/api/remote_api.go[34-46]

### Proposed fix
1. Remove the `branch == "" -> "main"` fallback.
2. If `branch` is empty, resolve the default branch via GitHub API (e.g., `GET /repos/{owner}/{repo}` and read `default_branch`) and then call the Trees API using that branch.
3. If default-branch resolution fails, return a clear error (or at minimum log a warning and fall back explicitly, but avoid silent `main`).
4. Apply the same logic path for `RemoteScopes` since it also relies on `FetchGithubTree`.

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

---

3. blueprint_v200.go missing license header 📘 Rule violation § Compliance

Description

New Go files added in this PR do not include the required Apache 2.0 license header at the top of
the file. This can create licensing/compliance issues for distribution and auditing.

Code

backend/plugins/agentready/api/blueprint_v200.go[1]

+package api

Relevance

⭐⭐ Medium

No clear historical evidence in this fork that missing Apache header on new Go files gets enforced.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 989 requires the Apache 2.0 header at the very top of newly added Go files. These newly added
Go files start immediately with package ..., demonstrating the header is missing.

Rule 989: Require Apache 2.0 license header in new Go files
backend/plugins/agentready/api/blueprint_v200.go[1-3]
backend/plugins/agentready/models/connection.go[1-4]
backend/plugins/agentready/tasks/submissions_collector.go[1-3]

Agent prompt

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

## Issue description
New `.go` files begin with `package ...` and are missing the required Apache 2.0 license header comment block.

## Issue Context
The repository requires the Apache 2.0 header to appear at the very top of each newly added Go file, before the `package` declaration.

## Fix Focus Areas
- backend/plugins/agentready/api/blueprint_v200.go[1-5]
- backend/plugins/agentready/models/connection.go[1-5]
- backend/plugins/agentready/tasks/submissions_collector.go[1-5]

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

---

View more (2)

4. Assessment API ignores connection 🐞 Bug ⛨ Security

Description

Assessment and finding records are now keyed by (id, connection_id), but the assessments API queries
by id/assessment_id only, so it can return incorrect or cross-connection data when the same
assessment id exists under multiple AgentReady connections. This is also a data isolation issue
because one connection’s data can be surfaced through another connection’s API usage.

Code

backend/plugins/agentready/api/assessments.go[R78-83]

func GetAssessment(input *plugin.ApiResourceInput) (*plugin.ApiResourceOutput, errors.Error) {
+	db := basicRes.GetDal()
+
	id := input.Params["id"]
	var assessment models.AgentReadyAssessment
	err := db.First(&assessment, dal.Where("id = ?", id))

Relevance

⭐⭐ Medium

No direct precedent for adding connection_id filter in agentready assessment API; isolation valued
generally (PR78).

PR-#78

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The models declare connection_id as part of the primary key, but the API does not use it in WHERE
clauses, which makes lookups ambiguous across connections.

backend/plugins/agentready/models/assessment.go[9-16]
backend/plugins/agentready/models/finding.go[7-14]
backend/plugins/agentready/api/assessments.go[78-99]
backend/plugins/agentready/api/assessments.go[111-129]

Agent prompt

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

### Issue description
`GetAssessment` and `GetAssessmentFindings` fetch rows without constraining by `connection_id`, even though the tool-layer tables use composite primary keys `(id, connection_id)`.

### Issue Context
- `AgentReadyAssessment.ConnectionId` and `AgentReadyFinding.ConnectionId` are part of the primary key.
- API endpoints currently accept only `:id` and query by `id` / `assessment_id`.

### Fix Focus Areas
- backend/plugins/agentready/api/assessments.go[78-143]
- backend/plugins/agentready/api/stats.go[22-77]

### Proposed fix
1. Introduce a required `connectionId` parameter for these endpoints (either as a query param or by adding connection-scoped routes like `/connections/:connectionId/assessments/...`).
2. Update queries:
  - `GetAssessment`: `WHERE id = ? AND connection_id = ?`
  - `GetAssessment` findings query: `WHERE assessment_id = ? AND connection_id = ?`
  - `GetAssessmentFindings`: `WHERE assessment_id = ? AND connection_id = ?`
  - `GetAssessments` list: when filtering by `repoId`, also filter by `connection_id` (or ensure uniqueness constraints make it safe).
3. If keeping backwards compatibility, reject requests missing `connectionId` with `400 BadInput` to avoid returning ambiguous data.

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

---

5. UI entities prevent subtasks 🐞 Bug ≡ Correctness

Description

Config-UI sets AgentReady scopeConfig.entities to ["CICD"], but AgentReady subtasks are registered
under DOMAIN_TYPE_CODE, so pipeline planning will select zero enabled subtasks and the plugin won’t
run by default. This makes newly created AgentReady connections/scopes appear to do nothing.

Code

config-ui/src/plugins/register/agentready/config.tsx[R87-93]

+  dataScope: {
+    title: 'Repositories',
+  },
+  scopeConfig: {
+    entities: ['CICD'],
+    transformation: {},
+  },

Relevance

⭐⭐ Medium

No historical evidence found about UI entities/domain-type mismatch affecting subtask selection for
plugins.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The UI requests the CICD domain type, but the subtasks are CODE-only; the pipeline planner filters
by domain type so none of AgentReady’s subtasks will be selected.

config-ui/src/plugins/register/agentready/config.tsx[87-93]
backend/plugins/agentready/tasks/submissions_collector.go[22-28]
backend/plugins/agentready/api/blueprint_v200.go[45-48]
backend/helpers/pluginhelper/api/pipeline_plan.go[32-55]

Agent prompt

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

### Issue description
The UI config registers AgentReady `scopeConfig.entities` as `['CICD']`, but the backend subtasks are `DomainTypes: [DOMAIN_TYPE_CODE]`. The pipeline planner filters subtasks by the requested entities, resulting in an empty task.

### Issue Context
`MakePipelinePlanSubtasks` only includes subtasks whose `DomainTypes` appear in the requested `entities` list.

### Fix Focus Areas
- config-ui/src/plugins/register/agentready/config.tsx[87-93]
- backend/plugins/agentready/tasks/submissions_collector.go[22-28]
- backend/plugins/agentready/api/blueprint_v200.go[45-48]

### Proposed fix
1. Change the default entities to `['CODE']` for AgentReady.
2. (Optional) If AgentReady should be configurable, ensure the UI offers valid domain-type selections and defaults to `CODE` so collection runs out of the box.

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

---

6. PK migration not applied 🐞 Bug ☼ Reliability

Description

The schema now models composite primary keys including connection_id, but the migration uses
AutoMigrateTables which does not update existing primary key constraints, so pre-existing AgentReady
tables will not be brought into alignment with the new GORM models. This can break CreateOrUpdate
semantics and prevents the intended (id, connection_id) uniqueness on upgraded installations.

Code

backend/plugins/agentready/models/migrationscripts/init_schema.go[R117-126]

func (script *initSchema) Up(basicRes context.BasicRes) errors.Error {
	return migrationhelper.AutoMigrateTables(
		basicRes,
-		&agentReadyAssessment20260511{},
-		&agentReadyFinding20260511{},
-		&agentReadyMetric20260511{},
-		&agentReadyScopeConfig20260511{},
+		&agentReadyConnection20260604{},
+		&agentReadyScope20260604{},
+		&agentReadyScopeConfig20260604{},
+		&agentReadyAssessment20260604{},
+		&agentReadyFinding20260604{},
+		&agentReadyMetric20260604{},
	)

Relevance

⭐⭐⭐ High

Team previously fixed agentready migration/model schema mismatches; likely to accept PK migration
issue (PR87).

PR-#87

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The migration only calls AutoMigrate, and AutoMigrate does not change PK constraints; meanwhile the
models and migration structs declare connection_id as part of primary keys.

backend/plugins/agentready/models/migrationscripts/init_schema.go[117-131]
backend/plugins/agentready/models/assessment.go[9-16]
backend/helpers/migrationhelper/migrationhelper.go[35-46]
backend/plugins/agentready/models/migrationscripts/register.go[7-11]

Agent prompt

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

### Issue description
`initSchema.Up` relies on `migrationhelper.AutoMigrateTables`, but `AutoMigrate` does not alter existing primary keys. The models have been changed to composite PKs (e.g., `(id, connection_id)`), so upgrades from an existing AgentReady deployment will not get the new PK constraints.

### Issue Context
This plugin already has persisted tool tables (`_tool_agentready_*`). Without explicit `ALTER TABLE ... DROP/ADD PRIMARY KEY ...`, existing DBs keep the old PK definitions.

### Fix Focus Areas
- backend/plugins/agentready/models/migrationscripts/init_schema.go[117-131]
- backend/plugins/agentready/models/migrationscripts/register.go[7-11]
- backend/helpers/migrationhelper/migrationhelper.go[35-46]

### Proposed fix
1. Add a new migration script with a higher Version() than `20260604000001`.
2. In that migration, for each affected table:
  - Add missing `connection_id` columns where needed.
  - Backfill `connection_id` for findings/metrics if upgrading from older rows (e.g., join on assessment_id to assessments).
  - Drop existing PK and add the intended composite PK (`ADD PRIMARY KEY (connection_id, id)` or `(id, connection_id)` consistently with model tags).
  - Handle MySQL vs Postgres similarly to the existing pattern in `sonarqube` migrations.
3. Register the new migration in `migrationscripts/register.go`.

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

---

[CryptoRodeo]

I added the latest grafana changes from #94 here so Qodo doesn't bring up those issues again. I might close my other two PRs and use this one for all the changes.

[CryptoRodeo]

Actually I think those grafana changes from the other PR broke something... reverting.

[CryptoRodeo]

Working locally after revert

[Dannyb48]

/agentic_review

[qodo-app-for-konflux-ci]

Code review by qodo was updated up to the latest commit a29d263

[Dannyb48]

/agentic_review

[qodo-app-for-konflux-ci]

Code review by qodo was updated up to the latest commit a29d263

[CryptoRodeo]

Pushed changes to resolve Qodo issues.

Wrong default branch was handled here:092fa76

config-ui changed outside allowed: should be resolved now that I rebased onto main. Looks like the AGENTS.md file was updated to be more flexible.

UI entities prevent subtasks: this should be fixed already.

PK migration not applied: handled here: 8806477

The other ones in that review should also be handled here: ab5ebda

[CryptoRodeo]

Whoops, looks like my plugin still needs an AGENT.md file: https://github.com/konflux-ci/devlake/blob/main/AGENTS.md#owned-plugins

Let me add this.

[CryptoRodeo]

AGENTS.md file added: 1a9ed21

[Dannyb48]

/agentic_review

[qodo-app-for-konflux-ci]

Code review by qodo was updated up to the latest commit 1a9ed21

[qodo-app-for-konflux-ci]

1. io.readall error ignored 📘 Rule violation ≡ Correctness

The new GitHub fetcher code discards io.ReadAll errors via _, which can mask I/O failures and
lead to misleading error messages or incorrect control flow. This violates the requirement to check
Go function errors immediately after the call.

Agent Prompt

## Issue description
`io.ReadAll` errors are ignored (assigned to `_`) in the new GitHub HTTP error-handling paths.

## Issue Context
These reads happen when building error messages for non-200 HTTP responses; ignoring the read error can hide underlying transport/body-read failures and violates the immediate error-checking requirement.

## Fix Focus Areas
- backend/plugins/agentready/tasks/submissions_collector.go[236-238]
- backend/plugins/agentready/tasks/submissions_collector.go[283-286]
- backend/plugins/agentready/tasks/submissions_collector.go[345-348]

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

[qodo-app-for-konflux-ci]

2. Invalid scope search column 🐞 Bug ≡ Correctness

agentready/api.Init configures the DS helper scope search columns as ["fullName"], but the
paging/search code interpolates those values directly into SQL ("fullName LIKE ?"), which will fail
when a searchTerm is used because the actual DB column is snake_case (e.g., "full_name"). This can
break scope/scope-config list/search endpoints at runtime with SQL "unknown column" errors.

Agent Prompt

### Issue description
`api.NewDataSourceHelper(..., []string{"fullName"}, ...)` configures search columns that are later used as raw SQL identifiers in `LIKE` clauses. For GORM-managed tables (including AgentReadyScope), the `FullName` field maps to a `full_name` column by default, so using `fullName` will generate invalid SQL whenever `searchTerm` is present.

### Issue Context
Other datasource plugins (e.g., GitHub) pass snake_case DB column names (e.g. `full_name`) into `NewDataSourceHelper`.

### Fix Focus Areas
- backend/plugins/agentready/api/init.go[32-43]
- backend/helpers/srvhelper/model_service_helper.go[161-179]
- backend/plugins/github/api/init.go[39-47]

### Implementation notes
- Change AgentReady’s `scopeSearchColumns` to the actual DB column name(s), e.g. `[]string{"full_name"}` (optionally also include `"name"` if you want search-by-repo-name).
- Ensure scope-config listing search columns also remain valid (they share the same `searchColumns` list via `NewDataSourceHelper`).

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