Implement PR Feedback - Turn Reviews into Improvements

Implement review feedback from PR $ARGUMENTS in the bbvch-ai/aihub-core monorepo.

Step 1: Fetch Unresolved Feedback Only

Use the GitHub GraphQL API via gh api graphql to fetch only unresolved, non-outdated review threads:

gh api graphql -f query='
{
  repository(owner: "bbvch-ai", name: "aihub-core") {
    pullRequest(number: $PR_NUMBER) {
      reviewThreads(first: 50) {
        nodes {
          isResolved
          isOutdated
          comments(first: 10) {
            nodes {
              body
              path
              line
              author { login }
              createdAt
            }
          }
        }
      }
    }
  }
}'

Filter to only threads where isResolved: false and isOutdated: false. Resolved and outdated threads have already been addressed — skip them entirely.

Also fetch CI status and changed files for scope detection:

gh pr checks $PR_NUMBER -R bbvch-ai/aihub-core
gh pr view $PR_NUMBER -R bbvch-ai/aihub-core --json files

Step 2: Triage Feedback

Human Comments (TOP PRIORITY)

Implement all unresolved human reviewer feedback. Read the referenced file before making changes. Skip resolved threads — they have already been addressed in previous commits.

Bot Feedback (EVALUATE CRITICALLY)

This repo's CI pipeline (.github/workflows/analyze-test-pr.yml) runs these bot checks:

• test-modules — pytest across scopes. Failures here are real — fix the code.
• pytest-coverage-comment — coverage delta. Add tests only if the uncovered code is meaningful.
• env-check — .env.prod vs rendered compose consistency. Failures are real — run make generate-compose and make check-env.

• sonarcloud-scan — scans one SonarCloud project per package (keys in packages/*/sonar-project.properties, e.g. aihub-core_lib-core for packages/core, aihub-core_api-core for packages/api, aihub-core_agents-core for packages/agent).

  SonarCloud bugs and vulnerabilities: almost always fix. Code smells: fix if straightforward. Security hotspots: evaluate case-by-case.

Step 3: Identify Affected Scopes

Use the file list from Step 1 (gh pr view --json files) to determine which monorepo scopes need testing. Map changed file paths to scopes: packages/core/ → packages/core, packages/api/ → packages/api, packages/agent/ → packages/agent, packages/pipeline/ → packages/pipeline, packages/process/ → packages/process, packages/bot/ → packages/bot, packages/web/ → packages/web, plus packages/backup/, packages/sysadmin-api/, packages/sysadmin-web/ the same way.

Step 4: Implement Changes

For each comment, read the referenced file, make the change, and move to the next. Work through human comments first, then bot findings.

Step 5: Validate

After all changes are implemented:

# Lint all affected scopes
make pr-ready

# Run tests in affected scopes (or delegate to /test-scope)
make -C packages/core test    # if packages/core was affected
make -C packages/api test    # if packages/api was affected

Troubleshooting

Done When

• Every human comment addressed or responded to
• All critical SonarCloud and test-module findings resolved
• make pr-ready runs clean from repo root
• make test passes in all affected scopes