Ask Knox

The Foresight Shadow Trade Log PR sat open for 9 days.

It was not forgotten. It was in the review queue. Active development continued on the repo — bug fixes, config tuning, a refactor of the signal scoring module. Nine days of daily commits in a repo with multiple active contributors.

By the time the PR came up for merge, it was 100+ commits behind main. The rebase required resolving conflicts across 6 files. Two of those files had been structurally reorganized in the intervening commits — the code the PR was touching no longer looked the way it did when the PR was written.

The rebase took longer than the original feature.

The Compound Nature of Rebase Debt

Rebase debt does not grow linearly. This is the part that surprises people.

Days 1–3: Fast-forward rebase or trivial conflict resolution. A renamed variable, a moved import, a reordered function. Git can often handle this automatically. Even manual resolution is under 20 minutes.

Days 4–6: A few real conflicts. A file was partially restructured. A function you call was renamed. Still manageable — an hour, maybe less. The architectural context is still fresh.

Days 7–9: The repo has moved. Subsystems have been refactored. The function you added behavior to has been restructured around a new pattern. You are no longer merging two versions of the same code — you are reconciling two different architectural directions that diverged over a week of active development.

Day 10+: The original change may be obsolete. The problem it solved may have been addressed differently. The approach it introduced may be architecturally misaligned with where the codebase landed.

The inflection point is around day 5. Before day 5, rebase is cheap. After day 5, the cost curve bends sharply.

The 5-Day Rule

Any PR open more than 5 days in an actively developed repo should be flagged. Not merged — flagged for a decision.

The decision has exactly three outcomes:

1. Merge it. If the PR is ready, merge it. The most common reason PRs age is not that they need more work — it is that "waiting for a good moment" keeps getting deferred. There is no better moment than before the cost curve bends.

2. Rebase it. If the PR is not ready, rebase it against main at day 5. The debt is manageable at this point. Schedule a rebase, not just a review.

3. Close it. If the work is obsolete, the approach changed, or the problem was solved differently on main — close it. Close it cleanly. If the work is ever needed again, open a fresh branch from the current main. Do not keep an obsolete PR open because closing it feels like admitting defeat.

All three outcomes are better than the fourth: doing nothing and letting the debt compound.

The Rebase Workflow

When the rebase decision is "rebase it":

git checkout feat/shadow-trade-log
git fetch origin
git rebase origin/main
# Resolve conflicts as they surface — one commit at a time
git push --force-with-lease origin feat/shadow-trade-log

The --force-with-lease flag is the correct flag here. Unlike --force, it checks whether the remote branch has advanced since your last fetch. If someone pushed to the branch since you fetched — a collaborator's change, an automated commit — the push fails instead of silently overwriting their work.

Do not use --force on shared branches. Use --force-with-lease.

The Agent-Specific Problem

Human developers eventually notice their PRs aging. They see the review queue. They feel the social pressure of an open PR. These are imperfect signals, but they exist.

AI agents do not have these signals.

An agent opens a PR and moves on. It does not monitor PR age. It does not notice when the repo advances past the branch. It has no instinct for the social pressure of an aged PR. If Knox is reviewing 5+ PRs a day across multiple repos, an agent-opened PR can age past the threshold without anyone actively noticing.

The practical solution is to put the deadline in the PR description:

## Rebase Deadline

This PR was opened by an automated agent in an active repo.
**Rebase deadline: 2026-04-01** (5 days from open date)

If not merged by this date, rebase against main before review.
Automated agent: Foresight Shadow Trade Log agent

The deadline is visible to anyone who opens the PR. It does not require active monitoring. It surfaces the risk at the right moment — when someone is reviewing.

The Connection to File Manifest Discipline

Small PRs age more gracefully than large ones. A PR touching 3 files in one subsystem is reviewed in 15 minutes and merged the same day. A PR touching 15 files across 3 subsystems sits in the review queue for a week while reviewers find time to build the context needed to evaluate it.

File manifest discipline keeps agent scope tight. Tight scope produces small PRs. Small PRs get reviewed and merged before they age.

This is not coincidental. The two lessons reinforce each other. An agent operating with a strict file manifest will produce a PR that is focused enough to be merged quickly. A PR that is merged quickly never accumulates 100 commits of divergence.

The full discipline stack:

File manifest — constrain agent scope to a clean file set
Small PR — produce a focused, reviewable change
Rebase deadline — surface age risk in the PR description
5-day flag — merge, rebase, or close before the cost curve bends

Lesson 177 Drill

Review every open PR in your active repos. For each one:

How many days has it been open?
How many commits has main advanced since the PR was opened?
Which outcome applies: merge, rebase, or close?

For any PR past 5 days: make the decision now. Not at the end of the week. Now. The cost of the decision is lower today than it will be tomorrow.

For the next agent-dispatched PR you open: add the rebase deadline to the description before you move on. It takes 30 seconds and makes the age risk visible without requiring you to actively track it.