Skip to content

decide: adaptive integration admission without capping agent implementation #7520

Description

@ll7

Current ruling

The maintainer selected Option B: adaptive, resource-specific integration admission in the canonical ruling comment:

archetype: workflow-policy
ruling: B_adaptive_integration_admission
implementation_authorized: report_only_child_7647
parent_state: blocked_on_children_and_pilot

The policy decision is complete. This parent remains open because implementation and the report-only observation pilot are not complete.

Corrected problem statement

The repository has high agent implementation capacity but bounded shared integration capacity. The constrained resources are distinct:

  • overlapping writers on the same issue or shared control-plane component;
  • local worktree, environment, scratch, and disk capacity;
  • hosted CI and optional matrix capacity;
  • exact-head review, domain review, author decisions, and merge attention; and
  • external operations such as SLURM, artifact publication, and release actions.

Raw open-PR count is diagnostic only. Draft, blocked, parked, author-decision, Dependabot, security, superseded, and merge-ready states have different integration costs.

Frozen policy

  1. Do not apply a global cap to ordinary issue claims, independent local implementation, worktree creation, or draft preparation PRs.
  2. Keep one active writer per issue and bound writers on conflicting shared components.
  3. Permit draft/preparation PRs. They should receive cheap ownership and contract checks until integration admission.
  4. Require explicit lane-specific admission before full hosted CI, exact-head review, repeated current-main refresh, merge-ready, merge-queue participation, or external operations.
  5. Treat writer, host, CI, ordinary/domain/author review, and external-operation capacity as separate lanes.
  6. When main has a confirmed common baseline failure, continue focused implementation and validation, but defer redundant full-readiness runs. One complete current-base proof remains mandatory before merge.
  7. Use transparent categorical dimensions, not one opaque score:
change_class: docs | test_only | tooling | runtime | benchmark | evidence | release
shared_surface: isolated | component_shared | repository_control_plane
ci_cost: low | standard | optional_matrix | full
review_requirement: ordinary | independent_exact_head | domain | author
external_action: none | network | artifact | compute | release
base_sensitivity: ordinary | current_base_required
  1. Permit narrow, audited priority handling for P0 red-main repair, security incidents, shared-baseline repair, and work that directly reduces blocked WIP. Evidence and merge gates still apply.
  2. Prepared candidates expire after seven days without a meaningful head, owner, evidence, or dependency update. Expiry parks integration admission; it does not delete work.
  3. Re-entry after expiry requires owner and ancestry readback, focused validation, and current-base proof where the work is base-sensitive.
  4. The numeric limits in coordination: 2026-08-18 closeout execution, dependency, and maintainer-decision queue #7457 are temporary closeout configuration, not permanent repository constants.
  5. Reuse the existing PR-policy/orchestrator path. Do not create a parallel queue or readiness framework.

Authorized child graph

Do not open a second integration-admission implementation. #7647 is the single bounded child authorized by the ruling.

Report-only pilot

Run report-only for 14 days and at least 20 terminal PR dispositions. Extend to 28 days if the sample remains smaller.

Retain the policy only if useful terminal throughput is not materially reduced and the following do not worsen:

  • CI spent on superseded or unadmitted heads;
  • exact-head reviews invalidated by later mutation;
  • duplicate or competing PR rate;
  • stale prepared-candidate rate;
  • post-merge repair rate;
  • maintainer and domain decision latency.

Revise or roll back if the policy reduces useful throughput without a compensating reduction in integration waste or defects.

Parent completion criteria

Claim boundary

Repository workflow-policy and integration-capacity control only. This issue does not change benchmark semantics, planner behavior, metric definitions, scientific evidence, compute authorization, release decisions, issue priority, or dissertation claims.

Related work

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions