Ready Is Not a Label: PR Readiness Is a Vector

The most dangerous word in a pull request queue is often ready.

It feels binary. The branch was updated. The tests passed. The proof was posted. The label changed. The reviewer was pinged. Pick one, call it ready, move on.

That is how agent-driven maintenance work starts looping. One surface says the work is done while another surface is still red, stale, dirty, scoped wrong, or waiting for a human decision. The agent keeps nudging the surface it can see, but the real blocker lives somewhere else.

For pull request operations, ready is not a label. Ready is a vector of independent signals that must be reconciled before the next public action.

Conceptual scope: this is a sanitized OpenClaw-style agent-operations lesson from public/open-source pull request work. I am intentionally omitting exact PR numbers, private thread references, local checkout paths, raw logs, access-token details, temporary artifact names, and branch-specific operational fingerprints. The reusable lesson is the readiness model, not the identity of one maintenance queue.

The Shape of a Ready-State Wave

A ready-state wave starts when several open pull requests are close enough to finish that the agent can no longer reason about each one as an isolated patch.

Some branches need a safe refresh against the current base. Some need targeted test proof. Some are merge-clean but still carrying a stale review label. Some have green CI but need a parser-readable proof comment. Some are technically correct but too broad for the maintainers' current appetite. Some should be closed voluntarily because the scope is not worth the social cost of keeping them open.

Those are different states. Collapsing them into one word is the bug.

In an agent queue, the failure mode is not just wasting time. It is public-action drift: posting another comment when the next step should be code repair, pushing another commit when the real issue is maintainer scope, or asking for review when the branch is not mergeable yet.

The Readiness Vector

The model I trust is a vector with at least six coordinates:

Coordinate	Question	Common false-ready signal
Code head	Is the branch proving the current intended diff on the current base?	The old commit passed a local check before the base moved.
CI / tests	Are the relevant checks green, and are unrelated failures separated from proof?	One focused test passed, so the whole PR is treated as done.
Mergeability	Can the hosting platform merge the branch cleanly now?	CI is green, but the branch is still dirty or stale.
Proof contract	Can both humans and automation read the behavior evidence?	The comment sounds convincing, but the policy parser still sees missing proof.
Review state	Do labels, reviewer requests, and bot state reflect the current head?	A stale label says waiting on author even after the branch is fixed.
Scope appetite	Is this still a change maintainers are likely to want in this form?	The patch is technically defensible, but it asks maintainers to own too much product or policy surface.

The vector matters because each coordinate has a different next action. If the code head is stale, refresh the branch. If proof is missing, add behavior evidence. If mergeability is dirty, repair the base conflict. If scope appetite is weak, narrow or close. If the label is stale after proof, ask for review once, then wait instead of spamming the queue.

Why Agents Get This Wrong

Agents are good at producing local progress. That is useful, but it creates a bias toward the action surface closest to the current error message.

A red check suggests "patch the code."
A stale label suggests "post a comment."
A merge conflict suggests "rebase and push."
A maintainer concern suggests "explain better."

Sometimes those are correct. The problem is doing them before identifying which coordinate is actually blocking readiness.

A strong agent should not merely ask, "What can I do next?" It should ask, "Which readiness coordinate is false, and which public action is justified by that evidence?"

The Queue Triage I Want

When a PR queue gets busy, I want the agent to produce a compact status table before taking another public action:

Current head: latest branch commit and whether the diff still matches the intended scope.
Checks: relevant CI/test state, with unrelated or infrastructure failures separated from code failures.
Mergeability: clean, dirty, unknown, or blocked by platform state.
Proof: behavior evidence present, parser-readable, and tied to the current head.
Review labels: whether labels/bot state match the current evidence.
Scope fit: keep, narrow, hold, or voluntarily close.
Next action: one action only, with an approval boundary if it is public or risky.

This turns a messy queue into a set of small decisions. More importantly, it prevents the agent from using a green signal on one coordinate to justify movement on another.

The Scope-Fit Gate

The least obvious coordinate is scope appetite.

A pull request can be technically correct, tested, and mergeable while still being the wrong thing to keep pushing. Maybe it creates a new product commitment. Maybe it changes security posture. Maybe it is a large contract change in a project where maintainers have not signaled appetite for that direction. Maybe the issue it tried to fix has moved to a different ownership path.

That does not make the work worthless. It means readiness is no longer purely technical.

Reputation rule: green checks are necessary, but they do not override maintainability, ownership, and scope fit. If a PR asks maintainers to own too much new surface, narrow it or close it before the queue turns into noise.

This is especially important for AI-assisted contributors. Agents can generate a lot of plausible work. The social constraint is not "can this be made green?" It is "should this be the next thing maintainers spend attention on?"

Public Actions Need Evidence Boundaries

Once the vector is explicit, public actions become easier to gate:

Push only when the branch change is necessary, scoped, and validated enough for the repository's norms.
Comment only when there is new evidence, a concise re-review request, or a clear scope decision.
Close when the scope no longer fits, the upstream direction changed, or the maintenance cost is not worth the attention debt.
Wait when the remaining state is reviewer/label refresh rather than code failure.

The last one is underrated. Agents love doing something. Sometimes the correct next action is to stop touching the public surface and let the maintainer or bot state catch up.

The Anti-Patterns

One-green-check optimism: treating a focused test pass as global readiness.
Comment-looping: posting increasingly polished proof when the blocker is actually code, mergeability, or scope.
Label worship: trusting a label without checking whether it reflects the current head.
Scope blindness: assuming technical correctness entitles the PR to maintainer attention.
Queue flattening: giving every PR the same next action because they all feel "almost done."

The fix is not a heavier ceremony. It is a better status model.

My Final Read

A pull request is ready when the readiness vector is coherent enough that the next public action is obvious and justified.

That might mean a final push. It might mean a re-review comment. It might mean no action because the reviewer label is stale but the proof is already there. It might mean voluntarily closing the PR because the scope is not a good fit anymore.

All of those can be good outcomes. The bad outcome is pretending one green surface makes the whole vector green.

Ready is not one bit. For agent-operated PR queues, ready is a reconciled vector.

About the Author

Jingxiao Cai works on distributed ML runtime systems and uses OpenClaw as a personal automation and investigation platform. His agent-operations writing focuses on the gap between "the tool can do it" and "the workflow is safe, reviewable, and worth doing."

This post intentionally omits private deployment identifiers, local paths, exact pull request identifiers, branch names, raw logs, channel/thread/message IDs, and access details. The reusable lesson is the readiness-vector workflow, not a fingerprint of one queue.