Forge can publish new-library PRs below the review dynamic-access coverage threshold
Summary
Forge's successful new-library publication path can still open library-new-request PRs with non-zero dynamic-access calls at or below the review-blocking coverage threshold. The review skill requires new-library dynamic-access coverage above 20%, but current Forge automation uses a 10% low-coverage threshold and applies that follow-up only after PR publication.
Generated by the human-intervention-scanner Rhei template.
Affected Source Items
Current File Evidence
skills/review-library-new-request/SKILL.md requires reported dynamic-access coverage above 20% for new-library PRs when there are non-zero dynamic-access calls, and directs reviewers to block PRs at 20% or lower.forge/forge_metadata.py defines LOW_DYNAMIC_ACCESS_COVERAGE_RATIO = 0.10, so the automation threshold is lower than the review threshold.forge/forge_metadata.py::resolve_human_intervention_candidate(...) suppresses successful-run low-coverage follow-up when coverage is greater than 10%, allowing 10% < coverage <= 20% to pass this automation check even though review will reject it.forge/forge_metadata.py::handle_completed_run(...) calls finalize_successful_issue(...) before maybe_apply_human_intervention_follow_up(...), so even low coverage that is detected is handled after PR publication.forge/git_scripts/make_pr_new_library_support.py::create_pull_request(...) creates the library-new-request PR and does not block publication based on dynamic-access coverage.forge/ai_workflows/core/dynamic_access_iterative_strategy.py accepts partial dynamic-access progress and can return success without enforcing an overall 20% dynamic-access coverage floor.forge/docs/workflows/dynamic-access.md documents progress-based acceptance criteria for dynamic-access runs rather than a new-library reviewer-threshold gate.
Why This Is Not Stale
The current checkout still has the mismatch: review requires above 20%, while Forge's low-coverage constant is 10%. The current lifecycle also still publishes the PR before checking whether successful generation needs human-intervention follow-up. Existing prompt instructions ask for dynamic-access coverage, and existing review instructions catch bad PRs, but neither prevents PRs below the review threshold from entering the review queue.
Proposed Fix
Align the successful new-library publication gate with the review rule:
- Introduce a named new-library minimum dynamic-access coverage threshold of 20%, or reuse a single shared constant that review-facing docs and Forge code cite.
- Evaluate dynamic-access coverage before
finalize_successful_issue(...) publishes the PR.
- For non-zero dynamic-access calls with coverage <= 20%, do not create the PR as a normal successful publication. Preserve the work for follow-up, post/label human intervention on the source issue, or route the run to a non-PR human-intervention state with a clear comment.
- Apply the same gate to all new-library strategies that produce dynamic-access stats, not only
dynamic_access_iterative.
- Keep
0/0 dynamic-access as an allowed no-calls case, matching the review skill.
Verification Idea
Add a Forge lifecycle regression test with pending metrics for a successful library-new-request run where dynamicAccess.totalCalls > 0 and coverageRatio is 0.20 or lower. Verify that PR publication is not invoked and the human-intervention follow-up path is invoked. Add a boundary case for coverage just above 20% and a 0/0 no-calls case to verify they remain PR-eligible.
Forge can publish new-library PRs below the review dynamic-access coverage threshold
Summary
Forge's successful new-library publication path can still open
library-new-requestPRs with non-zero dynamic-access calls at or below the review-blocking coverage threshold. The review skill requires new-library dynamic-access coverage above 20%, but current Forge automation uses a 10% low-coverage threshold and applies that follow-up only after PR publication.Generated by the human-intervention-scanner Rhei template.
Affected Source Items
[GenAI] Add support for jakarta.servlet.jsp:jakarta.servlet.jsp-api:3.1.0 using gpt-5.5[GenAI] Add support for com.alibaba.fastjson2:fastjson2:2.0.53 using gpt-5.5[GenAI] Add support for com.fasterxml.woodstox:woodstox-core:5.0.3 using gpt-5.5Current File Evidence
skills/review-library-new-request/SKILL.mdrequires reported dynamic-access coverage above 20% for new-library PRs when there are non-zero dynamic-access calls, and directs reviewers to block PRs at 20% or lower.forge/forge_metadata.pydefinesLOW_DYNAMIC_ACCESS_COVERAGE_RATIO = 0.10, so the automation threshold is lower than the review threshold.forge/forge_metadata.py::resolve_human_intervention_candidate(...)suppresses successful-run low-coverage follow-up when coverage is greater than 10%, allowing 10% < coverage <= 20% to pass this automation check even though review will reject it.forge/forge_metadata.py::handle_completed_run(...)callsfinalize_successful_issue(...)beforemaybe_apply_human_intervention_follow_up(...), so even low coverage that is detected is handled after PR publication.forge/git_scripts/make_pr_new_library_support.py::create_pull_request(...)creates thelibrary-new-requestPR and does not block publication based on dynamic-access coverage.forge/ai_workflows/core/dynamic_access_iterative_strategy.pyaccepts partial dynamic-access progress and can return success without enforcing an overall 20% dynamic-access coverage floor.forge/docs/workflows/dynamic-access.mddocuments progress-based acceptance criteria for dynamic-access runs rather than a new-library reviewer-threshold gate.Why This Is Not Stale
The current checkout still has the mismatch: review requires above 20%, while Forge's low-coverage constant is 10%. The current lifecycle also still publishes the PR before checking whether successful generation needs human-intervention follow-up. Existing prompt instructions ask for dynamic-access coverage, and existing review instructions catch bad PRs, but neither prevents PRs below the review threshold from entering the review queue.
Proposed Fix
Align the successful new-library publication gate with the review rule:
finalize_successful_issue(...)publishes the PR.dynamic_access_iterative.0/0dynamic-access as an allowed no-calls case, matching the review skill.Verification Idea
Add a Forge lifecycle regression test with pending metrics for a successful
library-new-requestrun wheredynamicAccess.totalCalls > 0andcoverageRatiois 0.20 or lower. Verify that PR publication is not invoked and the human-intervention follow-up path is invoked. Add a boundary case for coverage just above 20% and a0/0no-calls case to verify they remain PR-eligible.