Stacked PRs Make Change Shape Operable

GitHub's 30 July changelog introduced stacked pull requests in public preview: an ordered series of focused pull requests that can be reviewed independently, checked with existing branch protections, and merged individually or as a stack. The same day, GitHub Actions added self-repository syntax, where uses: $/... resolves an action or reusable workflow in the same repository at the exact commit that is running. GitHub also added a Copilot enterprise managed setting to limit remote control to managed devices.

Read separately, those are a pull-request feature, an Actions maintenance improvement, and a device-policy control. Read as an operating pattern, they say something more useful for practical web teams: the shape of a change is becoming a first-class control. A large checkout refactor, quote-form rebuild, analytics migration, or AI-assisted fix should no longer be treated as one oversized diff with one review moment.

The repeated angle to avoid

The last ten posts here covered review-agent context, package-malware state, inference-region routing, long-running agent checkpoints, overlapping work taxonomies, edge-controlled uploads, agent intake, purchase receipts, model routing, and AI credit chargeback. Older overlapping posts covered pull-request dashboards, feature-flag targeting diffs, code-quality gates, review-agent environments, deploy dry runs, dependency cooldowns, and repository operating boundaries.

The weak version of this article would repeat the old X needs Y pattern: pull requests need smaller reviews. That is true and too familiar. The sharper thesis is that stack structure, workflow reference integrity, and device eligibility now belong in the same release-control conversation. They decide whether a large change can be decomposed without losing the evidence that keeps each layer safe.

Stacks change the cost curve of review

Large pull requests fail in predictable ways. Reviewers skim. CI runs late. Design, analytics, accessibility, security, and business logic feedback collide in one thread. The author rebases repeatedly while trying to keep every dependency in their head. By the time the pull request is ready, nobody is sure which part is risky.

Stacked pull requests give teams a better shape: order the work so each layer has a narrow purpose and a clear dependency on the layer before it. That can reduce review friction, but only if the team treats the stack as more than a convenience feature.

For a small ecommerce or local-service site, a good stack might look like this:

Layer	Example	Review question	Evidence
Contract	Add typed event names, route constants, schema fields, or feature flags	Is the intended surface explicit?	Typecheck, schema diff, analytics plan
Internal implementation	Refactor form state, checkout totals, or CRM mapping behind existing behaviour	Did behaviour stay stable?	Unit tests, fixture comparison
User-facing change	Update form steps, product-page modules, booking copy, or validation UX	Is the customer journey better?	Preview URL, accessibility pass, screenshot
Integration	Connect payment, email, analytics, search, or agent workflow	Did external side effects remain controlled?	Sandbox run, webhook log, rollback note
Cleanup	Remove obsolete code, flags, docs, and temporary adapters	Is there no hidden dependency left?	Search result, deletion diff, monitoring check

The mechanism is simple: a stack lets reviewers ask one kind of question at a time. The contract layer can be reviewed by someone who cares about data shape. The user-facing layer can be reviewed with a browser and accessibility checklist. The integration layer can be reviewed by the operator who owns side effects.

Same-repository Actions make internal workflow dependencies less slippery

The self-repository Actions syntax matters because many repositories quietly depend on their own composite actions and reusable workflows. Before this update, teams often chose between ./ paths that required checkout and hardcoded versions that could drift away from the commit under test. GitHub says uses: $/... resolves to the workflow's own repository at the exact commit being run and works where workspace-relative syntax works, with runner version 2.336.0 or newer required.

That is a small syntax change with a large reliability consequence for stacks. If each layer in a stack runs checks that call internal actions, those checks should evaluate the workflow logic that belongs to that exact layer, not a stale tag or a convenience checkout side effect.

This is especially important when the stack changes the CI system itself. A small business may not think of CI as product surface, but it is: CI decides whether a booking funnel deploys, whether a Shopify app release is blocked, whether accessibility tests are required, and whether a lead-routing change is allowed to reach production.

Use this rule:

If a pull request changes both application behaviour and the workflow that proves that behaviour, split them into layers and pin internal workflow references to the commit under test.

That rule avoids a common failure mode: the stack looks green because the tests ran through old workflow glue. The result is not malicious; it is simply untrustworthy evidence.

Remote-control policy belongs in the same release model

GitHub's managed-device setting for Copilot remote control looks like an enterprise endpoint-management feature. It also belongs in this discussion because stack-based work is increasingly agent-assisted and cross-device. A developer may review a layer on mobile, ask an agent to investigate a failing check, continue in an IDE, and use remote control for a session that touches repository state.

The release question is not only "who can merge?" It is also:

• which devices are allowed to host remote-control sessions for this organization or repository;
• whether SSO authorization is required for the organizations involved;
• whether agent-assisted work can touch only low-risk layers from unmanaged machines;
• which logs should prove where the change was initiated and reviewed;
• which work classes must wait for a managed desktop session before continuing.

For a small team, this may sound heavier than the immediate feature demands. But the failure mode is practical: a compressed or unmanaged surface becomes the place where a broad change is approved, rebased, or fixed without the same local policy as the main development machine.

A stack contract for operators

Before opening a large change as a stack, write a short contract. It can live in the root pull request body, the tracking issue, or the release checklist.

stack_contract:
  change_id: checkout-analytics-refresh
  business_surface: ecommerce_checkout
  stack_goal: replace checkout event mapping without changing payment flow
  layers:
    - order: 1
      name: event_contract
      allowed_changes:
        - analytics event schema
        - typed constants
      must_not_change:
        - runtime checkout behaviour
      evidence:
        - typecheck
        - schema review
    - order: 2
      name: mapper_refactor
      allowed_changes:
        - internal mapping implementation
        - tests and fixtures
      must_not_change:
        - event names
        - payment provider calls
      evidence:
        - fixture diff
        - unit tests
    - order: 3
      name: rollout_flag
      allowed_changes:
        - feature flag wiring
        - preview instrumentation
      must_not_change:
        - default production path
      evidence:
        - preview URL
        - analytics debug log
  ci_reference_policy:
    internal_actions: self_repository_syntax
    runner_minimum: 2.336.0
  remote_work_policy:
    remote_control: managed_devices_only
    mobile_actions: comment_or_investigate_only
  merge_rule:
    merge_contract_and_refactor_before_user_facing_layer: true
    stop_if_any_layer_expands_business_surface: true

The value is not the YAML. The value is forcing the team to say which layer is allowed to change which business surface. If the second layer suddenly touches payment provider configuration, the stack has changed shape and should stop for a new decision.

Failure modes to design around

Stacked pull requests can still go wrong.

Hidden coupling. If layer three cannot be tested without layer five, the stack is not actually decomposed. Reorder it or admit that the change needs a different release path.

Review diffusion. Small pull requests can create the illusion that someone reviewed the whole system. Assign one person to the stack-level contract, not just individual layers.

CI evidence drift. If internal actions or reusable workflows resolve to the wrong version, each layer may report evidence from a different workflow than the one being changed.

Merge queue surprise. Merging several layers at once is convenient, but it can hide which layer introduced a production signal. Keep layer names and release notes specific enough to diagnose after merge.

Agent scope creep. An agent asked to fix a failing layer may broaden the diff across the stack. Require the agent to state whether it stayed inside the layer contract before a human reviews the patch.

The practical decision rule

Use stacked pull requests when the change is too large for one honest review but has a natural order of proof. Do not use them to make an unclear change look tidy.

A good stack has these properties:

1. each layer has one review question;
2. each layer can run meaningful checks at its own commit;
3. internal workflow dependencies resolve to the same commit being tested;
4. side-effecting layers are later than contract and refactor layers;
5. agent or remote-control entry points are scoped by layer risk;
6. the stack has a stop rule when the business surface expands.

That is the new information surplus in the fresh GitHub changes: stacked PRs are not just a nicer branch workflow. Combined with commit-consistent internal Actions and managed remote-control policy, they let operators turn a large change into a sequence of reviewable commitments. For websites that sell, book, quote, route leads, or collect customer data, that sequence is the difference between "we reviewed the diff" and "we controlled the release."