The forge computes the "drifting pull" flow alarm: an open pull's base is 25 landings or 6 h behind main #6400

I added the drifting-pull alarm in src/flow/alarm_drift.ts. It computes { fired, since?, says }, but nothing calls it yet. It isn't wired into /flow, the terminal or MCP.

The new test file test/flow-alarm-drift.test.ts passes (3 tests). The type check came back clean for the new files, but it can't fully run here: with no bun type definitions in the sandbox, tsc reports Cannot find type definition file for 'bun'. I haven't run the rest of the suite; the forge's check does that on push.

• alarmDrift(app, now):

- Pulls counted: every open, unmerged pull. A merged or closed pull never counts. - Landing count: one landing is one first-parent commit on the pull's base branch past its base_oid. - Hours: they run from the first such commit. - Threshold: it fires above 25 landings or above 6 h. - since: the earliest moment main moved past a firing pull's base.

• says: names the three most-behind pulls and appends "; and N more" when more are drifting. For example: "#4413 is 41 landings behind main; #4420 is 7h behind."
• Tests: 26 landings fires and 25 does not. The hours rule fires at 7 h and not at exactly 6 h. A real git repository confirms that 25 commits past a pull's base don't fire, 26 do, and closing a pull drops it from says.
• Pure core: driftAlarm(drifts, now) takes the measured pulls and now as arguments, so the hour tests never read the wall clock. The git test does use Date.now(), because its commits carry real timestamps.

Not done:

• The alarm costs one git log per open pull and has no caching, which is fine for a small forge but would need it on a busy one.
• Pulls from private repositories are counted and named by number only. It doesn't filter by viewer, because the issue didn't ask for that.

Closes #6390

I added the drifting-pull alarm in src/flow/alarm_drift.ts. It computes { fired, since?, says }, but nothing calls it yet. It isn't wired into /flow, the terminal or MCP.

The new test file test/flow-alarm-drift.test.ts passes (3 tests). The type check came back clean for the new files, but it can't fully run here: with no bun type definitions in the sandbox, tsc reports Cannot find type definition file for 'bun'. I haven't run the rest of the suite; the forge's check does that on push.

• alarmDrift(app, now):

- Pulls counted: every open, unmerged pull. A merged or closed pull never counts. - Landing count: one landing is one first-parent commit on the pull's base branch past its base_oid. - Hours: they run from the first such commit. - Threshold: it fires above 25 landings or above 6 h. - since: the earliest moment main moved past a firing pull's base.

• says: names the three most-behind pulls and appends "; and N more" when more are drifting. For example: "#4413 is 41 landings behind main; #4420 is 7h behind."
• Tests: 26 landings fires and 25 does not. The hours rule fires at 7 h and not at exactly 6 h. A real git repository confirms that 25 commits past a pull's base don't fire, 26 do, and closing a pull drops it from says.
• Pure core: driftAlarm(drifts, now) takes the measured pulls and now as arguments, so the hour tests never read the wall clock. The git test does use Date.now(), because its commits carry real timestamps.

Not done:

• The alarm costs one git log per open pull and has no caching, which is fine for a small forge but would need it on a busy one.
• Pulls from private repositories are counted and named by number only. It doesn't filter by viewer, because the issue didn't ask for that.

I've changed the alarm to measure from where each pull's head forked from main, so a rebased pull now clears it. The drift tests pass (4). The tsc check can't fully run in the sandbox, so I only checked that it reports no errors in the new files. I haven't run the rest of the suite; the forge's check does that on push.

• Fix: readDrift now takes the pull's head_oid. It finds git merge-base <head_oid> refs/heads/<base> and counts --first-parent <merge-base>..main from there. Both oids are checked with isSafeOid, and the module comment says why base_oid is not used. Hours also run from the first landing past that fork point.
• Test for the rebase case: a pull is opened and 26 commits land on main, so the alarm fires. Main is then merged into the head and the pull's head_oid is updated, and the alarm no longer fires. This test fails against the previous code.
• Test for the merged case: after 26 more landings the alarm fires again. Marking the pull merged clears it.
• Test isolation: the earlier git test now closes its open pull at the end. The alarm covers every repository, so that pull would otherwise have kept it firing in the later tests.
• Not changed: as you noted, the alarm isn't wired in anywhere yet. Whoever wires it in must gate says by viewer, since it names pulls from private repositories.

I pushed a likely fix for the check failure, but I couldn't reproduce the failure here, so it's unconfirmed. The drift tests pass locally with git's config removed, and they also passed with the fix reverted.

The check log only named the failing test, "a rebased head stops counting; a merged pull never counts", without an assertion message. My best guess is that the test's git commit-tree call had no author identity. On the CI machine that would fail quietly, leaving an empty head oid, so the later "alarm fires again" assertion would fail.

The fix is in test/flow-alarm-drift.test.ts. It sets the git author and committer identity explicitly on that call, and it now asserts that the commit-tree output is a 40-character oid. If the guess is wrong, the test will fail at that assertion instead of a later one. Production code is unchanged.

Please check the forge's re-run on this push. If the test still fails, the log's assertion line will show where.