Post-merge completion closes issues across repository boundaries: a merged PR in another repo can close an unrelated factory issue

[khaliqgant]

Factory's post-merge "advance to Done" path can close an issue in one repository because a pull request merged in a different repository, and it has already closed real, unfixed work as complete. At least 8 issues were falsely closed; 2 more closures in the same sample were legitimate.

All resolutions in this report were measured on 2026-08-16 against origin/main at f13600f32107e499bfccc6f971f7863fe5822927. Absence claims decay — re-measure before relying on them.

Discovered during the PR-triage sweep of #178 / #146.

The consequence, first

The clearest instance is #211 — "Key dispatch claims on work-unit identity, not surface path."

That issue was closed as completed on 2026-08-12. Its defect is still on origin/main, verbatim, at src/orchestrator/batch-tracker.ts:292:

export const issueKey = (issue: IssueRef): string => `${issue.key}:${issue.uuid}:${issue.path}`

So the mechanism described below closed, as complete, the very ticket that describes why a bare locator is not an identity. This is #228's thesis ("one identity model behind the duplicate-claim, dual-attribution, and 403 symptoms") demonstrated on Factory's own reconciliation path.

Evidence

Every one of these issues was closed by a comment of the exact form:

Factory observed pull request #N merge and completed this issue.

That string is emitted from exactly one place — src/orchestrator/factory.ts:11922 — so the closures are unambiguously attributable to the code path analysed below.

As of 2026-08-16, the highest number in AgentWorkforce/factory across both the issue and PR spaces is #275. Cited numbers above that cannot exist in this repository in any form.

factory issue	closed (UTC)	cites	resolves in factory as	same number in AgentWorkforce/cloud
#211	2026-08-12	#274	did not exist in any form on the closure date — factory's high-water mark was then ~#236, so the citation pointed ~38 numbers into the future	cloud#274 — chore: delete dead sandbox Dockerfiles
#221	2026-08-14	#1518	does not exist, any type (above factory's whole number space)	cloud#1518 — neon: split runtime and migration DB
#139	2026-08-13	#2891	does not exist, any type (above factory's whole number space)	cloud#2891 — fix(relayauth): dormant emergency source mint gate
#146	2026-08-13	#2895	does not exist, any type (above factory's whole number space)	cloud#2895 — fix(relayauth): restore bounded mint and webhook recovery
#216	2026-08-13	#219	exists, but as an ISSUE, not a merged PR — "Stale-mount auto-refresh targets a stale directory", created 2026-08-07	cloud#219 is a PR
#145	2026-07-21	#1346	does not exist, any type (above factory's whole number space)	cloud#1346 — Bump relayfile adapter-core trigger catalog
#143	2026-07-21	#1346	does not exist, any type (above factory's whole number space)	same as above
#260	2026-08-16	#1533	does not exist, any type (above factory's whole number space)	cloud#1533 — Revert #1532 (S6 wiring)
#222	2026-08-15	#250	real, merged — legitimate closure	—
#141	2026-07-20	#148	real, merged — legitimate closure	—

Two precision notes, because a reviewer who checks will otherwise find the discrepancy and stop reading:

• GitHub shares one number space between issues and pull requests. "No PR at that number" is not the same as "no such number". That is why the Notion Factory Tasks DB → intake manifest generator #216 row reads differently from the others: factory#219 genuinely exists, as an issue.
• [factory] Key dispatch claims on work-unit identity, not surface path #211 is stated as of its closure date on purpose. A factory#274 does exist today — it was opened 2026-08-16 by an unrelated lane, four days after this closure. The claim is that on 2026-08-12 the cited number did not exist in any form.

Mechanism

This was read from the code, not inferred from the pairs above.

A merged-PR mount event knows exactly which repository it came from. src/orchestrator/factory.ts:11771 builds it:

const repo = `${parts.owner}/${parts.repo}`

and passes it down at :11833 → #advanceMergedPrToDone(snapshot, repo, record).

Inside #advanceMergedPrToDone (:11893) there are two paths:

1. With a tracked in-flight record — repository-qualified and correct. The record lookup at :11877 filters on recordMatchesGithubRepo(record, eventRepo, this.#config.repos.org).
2. Without a record (the agents have already been released) — the fallback at :11905:

const issue = await this.#findMergeAdvanceIssueForPr(snapshot)

repo is in scope on that line and is not passed. #findMergeAdvanceIssueForPr (:11963) takes only the snapshot, then scans every issue path from the configured source (#githubIssuePaths(), :11977) and scores each one with prSnapshotIssueMatchScore(snapshot, issue.key) (:11991). Nothing in that loop compares the issue's repository to the merged PR's repository.

The active contract has issueSource: "github" and 19 repositories in repos.names, so that scan spans all 19 — each with its own independent number space.

The scorer (:17166) is:

const prSnapshotIssueMatchScore = (snapshot: PullSnapshot, issueKey: string): number => {
  if (factoryBranchMatchesIssue(snapshot.headRef ?? '', issueKey)) return 30
  if (containsIssueKey(snapshot.title ?? '', issueKey)) return 20
  if (containsExplicitIssueReference(snapshot.body ?? '', issueKey)) return 10
  return 0
}

For a GitHub-native issue, issue.key is a bare number. containsExplicitIssueReference (src/issue-key-match.ts:20-31) then matches that bare number against the PR body via, among others:

#211(?!\d)
https?://github\.com/[^\s/]+/[^\s/]+/issues/211(?!\d)

The URL alternative accepts [^\s/]+/[^\s/]+ — any owner and any repository. A merged PR in cloud whose body references cloud's own #211 therefore scores against factory's issue #211.

Two aggravating details in the same function:

• The in-flight scan de-duplicates score ties and bails out (babysitterPrDiscoveryAmbiguous, :11886). The fallback scan has no ambiguity guard — on a tie the first match silently wins.
• The closure comment then reports snapshot.number (:11922), which is the other repository's PR number. That is why the citations look like they point at nonexistent factory PRs: they are real PR numbers, just not from this repository.

Open question

I have not reconstructed which specific merge event fired each individual closure — the mount projection history for those moments is not available to me, and several cited numbers resolve to PRs in other in-scope repos that merged months before the closure date (cloud#274 merged 2026-04-22; factory#211 closed 2026-08-12). So a re-projection or backfill of an already-merged PR is likely part of the trigger, and worth confirming. The missing repository qualification at :11905 is read directly from the code and does not depend on that reconstruction.

Suggested direction

Pass the known repo into #findMergeAdvanceIssueForPr and require the candidate issue's repository to equal the merged PR's repository — the same qualification the in-flight path already applies at :11877. Adding the fallback's own ambiguity guard would close the tie-break gap alongside it.

Per #228, the durable fix is that a claim belongs to the work unit, not to a bare locator: a number is only an identity once qualified by its repository.

Not done here

The 8 falsely-closed issues are being audited separately to determine whether each one's work actually landed on main. Nothing has been reopened — that decision is deliberately left to a human.

[khaliqgant]

Audit of the 8 falsely-closed issues

Did the work actually land, regardless of what the issue state says? Verdicts are from code on origin/main @ f13600f3, measured 2026-08-16 — not from issue or PR state.

Result: 6 not done, 2 genuinely done. Nothing has been reopened.

issue	verdict	evidence on origin/main
#211	NOT DONE	src/orchestrator/batch-tracker.ts:292 still keys on the surface path verbatim: `${issue.key}:${issue.uuid}:${issue.path}`
#221	NOT DONE	Both identities intact. Babysitter still shells out to gh: src/github/standalone-babysitter.ts:3 imports GhRunner, invoked at :81 and :86; the source: 'mount' | 'gh' | 'mount+gh' union is still at :28 and :99. App authorship still separate at src/mount/relayfile-github-connection-write.ts:97 (author: 'app').
#139	NOT DONE	No directory-backed peer discovery exists. git grep -i "directory|card|skill" over src/ports/fleet.ts and src/fleet/relay-fleet-client.ts returns zero hits; no a2a/directory reference anywhere in src/.
#146	NOT DONE	AgentWorkforce/factory-test-infra was created 2026-07-21 but contains only README.md — no substrate. Factory-side provider wiring absent: src/environments/ ships only Kubernetes providers (KubernetesEnvironmentProvider, KubectlEnvironmentProvider in index.ts:52,153). The only cloudflare string in the tree is a test fixture (verification-stack-deployer.test.ts:275).
#216	NOT DONE	The generator that bridges Notion DB → manifest does not exist. src/intake/notion.ts only reads a manifest already on disk (readFile at :196) — no Notion database query, no data_source call. That loader predates this issue (PR #215) and is explicitly named in the issue as not the deliverable.
#260	NOT DONE	No trajectory pointer is written at all. git grep "trajectory|work_unit_id|work_unit_surface" over src/ returns zero hits, so no Factory-opened PR body carries the marker — placeholder or otherwise. (The sessionRef hits under src/fleet/ are the pre-existing spawn/resume continuation field, a different concern.)
#145	GENUINELY DONE	Verification gate is wired and enforcing. VerificationPipeline constructed at src/orchestrator/factory.ts:721-729, and consumed in the merge gate at :14917-14954 where if (!verification.passed) blocks the merge (verificationGateFailed / verificationGatePassed).
#143	GENUINELY DONE	Descriptor contract and deployer both shipped: src/environments/verification-stack-descriptor.ts and src/environments/verification-stack-deployer.ts, exported via src/environments/index.ts:93-120, with the descriptor path default .factory/verification-stack.yaml in src/config/schema.ts:244.

One nuance worth separating

#143 and #145 are the two closures dated 2026-07-21, and both cited the same number, #1346 — which does not exist in this repository in any form. Their work had genuinely landed, just not via the cited PR.

So a spurious citation does not imply the work is missing, and a correct outcome does not imply the mechanism worked. These two closed correctly by accident. That is worth stating plainly, because "we spot-checked one and the work was there" is exactly the check that would have let this defect survive.

The reopen decision is deliberately left to a human.

[kjgbot]

Fix PR: #278 — fix/276-crossrepo-mergeadvance.

Mechanism confirmed against origin/main at f13600f. File has drifted since the analysis was written; the current line numbers are: #advanceMergedPrToDone(snapshot, repo, record?) at :11893 (already carries repo), record-less fallback at :11905 calling #findMergeAdvanceIssueForPr(snapshot) and dropping repo, definition at :11963, scorer at :17167, closing comment at :11922. Behaviour matches this issue verbatim.

Fix: Pass repo into #findMergeAdvanceIssueForPr and filter candidates using githubIssuePathParts (same shape recordMatchesGithubRepo uses). Also add the ambiguity guard the tracked path already carries (new counter mergedPrAdvanceAmbiguous) so a same-score tie fails toward NOT closing. Fail-closed if eventRepo is not a valid github repo.

Completeness grep: #findMergeAdvanceIssueForPr has one call site (:11905, covered by this PR). #advanceMergedPrToDone has three call sites — #restoreBabysitterOwnership:10634, and the two #handlePrChange branches at :11778, :11833 — all three already pass repo, so the qualification now reaches through the full chain. Other consumers of prSnapshotIssueMatchScore (:4173, :9167, :9180, :10293, :10326) all key on session.issue.key/record.issue.key, which is already repo-qualified via its carrier. No other unqualified bare-number completion path was found.

Tests (grounded in observed pairs):

• Must-not-fire: cloud#2891 merge with body containing https://github.com/AgentWorkforce/cloud/issues/139 must NOT close factory#139. Passes with fix; fails on origin/main without it.
• Must-fire: factory PR fix(babysitter): retry and reconcile PR-open snapshot reads so a failed read cannot orphan a PR #250 with branch factory/222-fix MUST still close factory#222 through the same fallback. Deleting the fallback outright would regress this.

479/479 factory.test.ts pass. tsc clean.

Not closing this issue. The principal owns that gate.

[kjgbot]

CI status on PR #278 (fix/276-crossrepo-mergeadvance, run 31966854246 @ 4m11s):

• kubernetes-provider-e2e — pass (2m35s)
• load-e2e — pass (2m4s)
• package — pass (4m6s)
• verification-gate-e2e — pass (3m5s)
• verification-stack-e2e — pass (2m3s)
• cubic · AI code reviewer — pass (3m4s)
• CodeRabbit — pass (skipped, OSS auto-skip)
• Reviewsaur Quiz — pending (perpetually 0s / never-completes on this repo; same state on fix(factory): reserve exit 0 for actions that were performed (#266) #274 and fix(orchestrator): let a released invocation spawn again (#229) #275 — unrelated to this PR)

All GitHub Actions and actionable third-party checks green. gh pr view 278 --json mergeStateStatus returns UNSTABLE solely because of Reviewsaur — same posture as every recent PR on this repo.