A fix the owner or steward writes lands through the queue as is: an in-repo pull is gated and landed, not closed for being off a fork #7575

A pull a person opens from a branch of the repository itself (the owner's or a steward's fix) now stays open and keeps following its branch until it lands. The crew no longer sends a builder to it or parks it.

What closed #7436: a reviewer asked for changes, and the changes-requested pass (src/crew/requested.ts) assigned builder mason. Mason's run could only refuse the branch, because the crew works from forks. That pushless run then hit answeredWithoutChange → parkPull, which closed the pull. A closed pull's head doesn't move when its branch does (trackPullHead), so every later push was lost to it. For an open in-repo pull, pushes already moved the head and started a check, review and gate, and a green one already landed through the queue. The finishing pass already skipped pulls a person wrote.

What changed:

• src/crew/authors_pull.ts (new): one check, authorsInRepoPull, true for a person's pull whose branch is in the repository it proposes to.
• src/crew/requested.ts: when changes are asked for on such a pull, it is assigned back to its author, even if a builder's name was on it as with #7436. No feedback run is queued. The pass reports it as "back with its author, a person: the branch lives in the repository", which the tick line counts under "handed to a person".
• src/crew/autonomy.ts: parkPull refuses such a pull. That covers the pushless-feedback park, the red-check limit and the decider's stop.
• src/crew/runner.ts: if a builder run reaches one anyway (say a person assigns an agent to it), it still fails, but it no longer says "close it". It says only the author can push the branch.
• docs/APPS.md rule 1 now says how these pulls are handled.

Tests: test/authors-pull.test.ts covers that:

• a push to the pull's branch moves its head and starts a pull-N check of the new tip;
• changes asked for go back to the author and queue no builder run;
• a builder's pushless feedback run does not park the pull, parkPull refuses it, and the next push still moves its head;
• the finishing pass leaves an approved, conflicted pull of this kind alone, still open;
• a builder's own legacy in-repo pull still parks as before.

With the three source files reverted, the two behaviour tests fail. tsc is clean. The new file, the requested, parks, finishing and crew suites, and the five cross files CLAUDE.md names gave 225 pass, 0 fail.

Not done: #7436 is not reopened; it is a closed pull and a person can reopen it. Conflict updates and red-check rework are not handed to the author: the finishing pass and conflict sweep already skip pulls a person wrote, and the park guard means a red check can no longer close one.

🤖 Generated with Claude Code

Closes #7572

A pull a person opens from a branch of the repository itself (the owner's or a steward's fix) now stays open and keeps following its branch until it lands. The crew no longer sends a builder to it or parks it.

What closed #7436: a reviewer asked for changes, and the changes-requested pass (src/crew/requested.ts) assigned builder mason. Mason's run could only refuse the branch, because the crew works from forks. That pushless run then hit answeredWithoutChange → parkPull, which closed the pull. A closed pull's head doesn't move when its branch does (trackPullHead), so every later push was lost to it. For an open in-repo pull, pushes already moved the head and started a check, review and gate, and a green one already landed through the queue. The finishing pass already skipped pulls a person wrote.

What changed:

• src/crew/authors_pull.ts (new): one check, authorsInRepoPull, true for a person's pull whose branch is in the repository it proposes to.
• src/crew/requested.ts: when changes are asked for on such a pull, it is assigned back to its author, even if a builder's name was on it as with #7436. No feedback run is queued. The pass reports it as "back with its author, a person: the branch lives in the repository", which the tick line counts under "handed to a person".
• src/crew/autonomy.ts: parkPull refuses such a pull. That covers the pushless-feedback park, the red-check limit and the decider's stop.
• src/crew/runner.ts: if a builder run reaches one anyway (say a person assigns an agent to it), it still fails, but it no longer says "close it". It says only the author can push the branch.
• docs/APPS.md rule 1 now says how these pulls are handled.

Tests: test/authors-pull.test.ts covers that:

• a push to the pull's branch moves its head and starts a pull-N check of the new tip;
• changes asked for go back to the author and queue no builder run;
• a builder's pushless feedback run does not park the pull, parkPull refuses it, and the next push still moves its head;
• the finishing pass leaves an approved, conflicted pull of this kind alone, still open;
• a builder's own legacy in-repo pull still parks as before.

With the three source files reverted, the two behaviour tests fail. tsc is clean. The new file, the requested, parks, finishing and crew suites, and the five cross files CLAUDE.md names gave 225 pass, 0 fail.

Not done: #7436 is not reopened; it is a closed pull and a person can reopen it. Conflict updates and red-check rework are not handed to the author: the finishing pass and conflict sweep already skip pulls a person wrote, and the park guard means a red check can no longer close one.

🤖 Generated with Claude Code

A pull a person opens from a branch of the repository itself (the owner's or a steward's fix) now stays open and keeps following its branch until it lands. The crew no longer sends a builder to it or parks it.

What closed #7436: a reviewer asked for changes, and the changes-requested pass assigned builder mason. Mason's run could only refuse the branch, because the crew works from forks. That pushless run then hit answeredWithoutChange → parkPull, which closed the pull. A closed pull's head doesn't move when its branch does (trackPullHead), so every later push was lost to it. For an open in-repo pull, pushes already moved the head and started a check, review and gate, and a green one already landed through the queue. The finishing pass already skipped pulls a person wrote.

What changed:

• src/crew/authors_pull.ts (new): one check, authorsInRepoPull, true for a person's pull whose branch is in the repository it proposes to.
• src/crew/requested.ts: when changes are asked for on such a pull, it is assigned back to its author, even if a builder's name was on it as with #7436. No feedback run is queued. The pass reports it as "back with its author, a person: the branch lives in the repository".
• src/crew/autonomy.ts: parkPull refuses such a pull. That covers the pushless-feedback park, the red-check limit and the decider's stop.
• src/crew/runner.ts: if a builder run reaches one anyway, it still fails, but it no longer says "close it". It says only the author can push the branch.
• docs/APPS.md rule 1 now says how these pulls are handled.

Tests: test/authors-pull.test.ts covers that:

• a push to the pull's branch moves its head and starts a pull-N check of the new tip;
• changes asked for go back to the author and queue no builder run;
• a builder's pushless feedback run does not park the pull, and the next push still moves its head;
• the finishing pass leaves an approved, conflicted pull of this kind alone;
• a builder's own legacy in-repo pull still parks.

With the source changes reverted, the two behaviour tests fail.

Tests that were wrong, and changed:

• test/crew-failed-while-building.test.ts, test/checks-disk-red.test.ts and test/crew-shared-red.test.ts stood in for a crew pull with a pull alice opened from an in-repo branch, with the bot assigned. That is exactly the person's pull this change protects, so they now open it as the bot.
• In test/holds.test.ts, greenPull rewrote the pull's author in the database but returned the copy it read before. It now re-reads the pull after the rewrite.

tsc is clean, and the four previously failing suites pass. Every suite that touches parking, the requested pass, finishing, stale pulls or the runner's refusal passed, along with the five cross files: 49 files and then 31 files, 0 failing. The forge's check had stopped early and skipped 37 shards, so its full run on this push is the first complete pass.

Not done: #7436 is not reopened; a person can reopen it.

🤖 Generated with Claude Code

A person's pull from a branch of the repository itself (an owner's or a steward's fix) is now a normal pull. Its pushes move its head and re-run its check, review and gate, and it lands through the queue. The crew no longer closes it with "the crew works from forks now".

• src/crew/authors_pull.ts (new): authorsInRepoPull(pull) returns true when the author is not an agent and the pull is not from a fork. Every other change below checks it.
• src/crew/autonomy.ts: parkPull never parks such a pull. A closed pull stops following its branch, which is how #7436 lost every later push.
• src/crew/requested.ts: when changes are requested on it, the pull is assigned back to its author once, and no builder is sent. A builder can't push that branch, so its run would fail and the failure would park the pull.
• src/crew/runner.ts: if a run still reaches such a pull, it fails with a message saying the author keeps it, not "close it and assign the issue again". A crew agent's own in-repo pull is still treated as before.
• docs/APPS.md: the crew rules now describe this case.

test/authors-pull.test.ts covers the issue's two required tests: a push to the pull's branch moves its head and starts a check of the new head, and the finishing pass leaves it open. It also covers four more cases:

• which pulls count as a person's in-repo pull;
• requested changes go back to the author, even when a builder is already assigned;
• a builder run that pushes nothing doesn't park the pull, and its next push still moves the head;
• a builder's own in-repo pull is still parked.

Four existing tests built a "crew pull" as a person's pull with an agent assigned, which is now this new case. I changed their fixtures to an agent's own pull (checks-disk-red, crew-failed-while-building, crew-shared-red, holds). The code was right; the fixtures were wrong.

bun x tsc --noEmit is clean, and those five test files pass (54 tests). The latest comment on the issue is the automatic triage note saying it waits behind the Later gate until a pillar is named. That is a label for a person to set, so the code doesn't change for it.

To try it: open a pull as a person from a branch of the repository, push to that branch, and the pull's head and check follow. Request changes on it and it is assigned back to you, not to a builder.

🤖 Generated with Claude Code