docs(e2e): record why roadie-backstage-plugins has no app-next lane

[gustavolira]

Closes RHIDP-16301.

The ticket asks for an app-next lane. Both projects in this workspace are blocked upstream, for two different reasons, so the deliverable is the finding rather than a lane that cannot pass. Docs-only.

1. backstage-plugin-github-pull-requests — NFS surface exists, but contributes no UI

The package does have an NFS surface. At the pinned ref, src/alpha.tsx:

const githubPullRequestsApi = ApiBlueprint.make({ /* ... */ });

export default createFrontendPlugin({
  extensions: [githubPullRequestsApi],
});

extensions contains an ApiBlueprint and nothing else — no EntityContentBlueprint, no EntityCardBlueprint, no PageBlueprint. So the "Pull/Merge Requests" entity tab this spec clicks cannot exist under the new frontend system. The surface registers an API; it renders nothing.

The package also declares no backstage.features and has no exports map, which is consistent with what the readiness data already showed for all six @roadiehq/* frontend packages: a servable module-federation remote with no NFS entry point.

2. scaffolder-backend-module-http-request — NFS does not apply, and the spec needs the global header

It is a backend module, so there is no frontend surface to migrate. Separately, its spec asserts verifyHeading("Self-service") — a global header element, and rhdh:packages/app-next ships no global header. (Same thing that broke one test in #3318.)

Checked against a newer ref too

Both findings hold at the ref source.json pins (c1b84e94) and on upstream main, 62 commits ahead, where alpha.tsx is byte-identical. Bumping the ref would not help — worth stating because that is the obvious first guess.

Why not add the lane anyway

It would fail on a missing tab, and the failure would read as a wiring bug rather than as an absent upstream extension. That is precisely the misattribution this epic keeps hitting.

And per the support levels in rhdh:docs/testing-requirements-matrix.md, every frontend package here is community — a tier that requires no E2E at all, only that the published artifact installs and boots. The strategy is also explicit that for third-party plugins we do not own we should have no coverage goals, only integration checks. So the remedy is an upstream contribution to RoadieHQ, or nothing — not a lane in this repo.

Where the note lives

playwright.config.ts, because that is the first file someone adding a lane opens, and the triage sheet's roadie-backstage-plugins row now carries the same finding so the epic's tracking artifact agrees.

Relevant to the in-flight "disable non-NFS-ready tests" work

This workspace is a concrete, evidenced member of that set. Worth noting for whoever builds the filter: keying it on the project filename will not classify this workspace correctly — neither project is named -app-next, and neither is NFS-ready. Conversely useNewFrontendSystem: true in rhdh.configure() already enables NFS without the suffix (see #3234 for homepage), so the name and the reality can diverge in both directions. The authoritative signal is rhdh.deploymentConfig.useNewFrontendSystem.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:52 PM UTC · Completed 1:57 PM UTC

Commit: 6fca36f · View workflow run →

[gustavolira]

Closing — there is no lane to add here, so there is no PR to make. The finding stands and is recorded on RHIDP-16301 instead:

• backstage-plugin-github-pull-requests has an NFS surface (src/alpha.tsx) but registers only an ApiBlueprint — no EntityContentBlueprint — so the "Pull/Merge Requests" tab the spec clicks cannot exist under NFS.
• scaffolder-backend-module-http-request is a backend module, so NFS does not apply, and its spec asserts verifyHeading("Self-service"), a global header element packages/app-next does not ship.
• Both hold at the pinned ref c1b84e94 and on upstream main, 62 commits ahead, where alpha.tsx is byte-identical — bumping the ref would not help.

The remedy is an upstream contribution to RoadieHQ, and these packages are community, a tier the support matrix exempts from E2E entirely.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 1:56 PM UTC · Completed 2:05 PM UTC

Commit: 6fca36f · View workflow run →

[fullsend-ai-review]

Review skipped — this PR is already closed.

The /fs-review command only reviews open pull requests.

_{Posted by fullsend post-review check}

[fullsend-ai-retro]

Retro: PR #3327 — docs(e2e): record why roadie-backstage-plugins has no app-next lane

Workflow quality: Clean, no actionable improvements found. All identified waste is already tracked by existing issues.

Timeline

Time (UTC)	Event
13:51:42	PR opened by gustavolira (human, with Claude Code assistance) — docs-only, 2 files, 28 additions
13:51:46	Review workflow triggered (run 32260547297)
13:52:20	SonarQube: Quality Gate passed
13:55:02	Author closes PR — finding belongs on Jira RHIDP-16301, not as a merged PR
13:57:29	Review agent completes with APPROVE verdict; post-review correctly skips posting since PR is closed

Assessment

Review quality — Excellent. The agent verified technical claims (NFS surface analysis, backend module classification, support tier lookup) against actual workspace metadata. The APPROVE verdict was correct. No false positives, no missed issues.

Token waste — The review agent spent $0.85 and 5.5 minutes reviewing a PR that was closed 3 minutes after opening. The work was thorough but produced no value. This is the only waste identified.

Rework — None. Single commit, no iterations.

Already-tracked issues (no new proposals needed)

• Review running on closed PRs: Extensively tracked across fullsend-ai/fullsend #3010, #1870, #2388 and fullsend-ai/agents #337, #642. This retro provides another data point: $0.85 wasted on a 3-minute-lived PR.
• Harness dispatch LoadWithBase errors: Three agents (code, fix, review) failed dispatch with "base field is set but harness was not loaded with LoadWithBase." This was fixed today in fullsend-ai/fullsend #6127 (PR #6367 merged 2026-08-19T12:09Z). The review still ran via the Route path, so the error was non-blocking here.

Why no proposals

The only waste (review on a quickly-closed PR) is a well-understood problem with 5+ open issues tracking it across the platform and agents repos. The harness dispatch error was fixed earlier today. The human's workflow was efficient — they opened a PR, realized the finding belonged elsewhere, and closed it promptly. No systemic improvement beyond what is already tracked.