fix(guard): derive target base ref for cross-repository checkouts #983

New Issue

2026-07-30T20:57:38-05:00

jcwalker3 commented

2026-07-30 20:57:38 -05:00

Summary

Cross-repository mutation gating and parity reporting each hardcode a PRGS-specific
base ref. A namespace whose canonical repository root points at any repository that
does not use the remote prgs with branch master cannot prove base equivalence,
so every gated mutation fails closed with no reachable remedy.

Two independent hardcoded assumptions, in two different modules, disagreeing with
each other and with reality.

Observed failure

A valid cross-repository target:

Repository: MDCPS/WeeklyBriefings-Meta
Remote: MDCPS
Integration/default branch: dev
Tracking ref: refs/remotes/MDCPS/dev

fails create-issue bootstrap with:

blocker_kind: missing_issue_worktree
Create-issue bootstrap guard (#749): live master tip is unknown;
base equivalence to live master cannot be proven

The guard probes only prgs/master and refs/remotes/prgs/master. Neither exists
in that checkout, so the resolver returns None, base equivalence is unprovable,
and the bootstrap fails closed. The target repository is correct and healthy; the
guard is asking it the wrong question.

Confirmed defect sites (verified at `108cbfa173`)

1. `root_checkout_guard.py` — mutation gating

Line 23: REMOTE_MASTER_REFS = ("prgs/master", "refs/remotes/prgs/master")
Line 26 resolve_remote_master_sha() accepts a remote_refs override, but
all four production callers omit it and silently inherit the PRGS default:
- gitea_mcp_server.py:1055 — author issue bootstrap
- gitea_mcp_server.py:1085 — create-issue bootstrap (#749/#757 path)
- gitea_mcp_server.py:1306 — namespace mutation preflight
- gitea_mcp_server.py:1990 — _enforce_root_checkout_guard (#475)
Line 106-107 hardcodes the literal string prgs/master into the operator-facing
failure message, so even a correct non-PRGS failure is reported misleadingly.

2. `master_parity_gate.py` — parity reporting

Line 381: DEFAULT_TARGET_TRACKING_REF = "refs/remotes/origin/master"
Line 411: assess_target_repository_parity(..., tracking_ref=DEFAULT_TARGET_TRACKING_REF)
Line 466: repository identity is read via git remote get-url origin — a
hardcoded remote name.

The two modules do not even agree with each other: gating assumes remote prgs,
reporting assumes remote origin. At most one can be right for any given
repository, and for a repository using neither, both are wrong.

Live evidence in this very repository

This reporting defect is observable on Gitea-Tools itself, today:

"tracking_ref": "refs/remotes/origin/master",
"remote_tracking_head": "08c3488d7c35ba27efcd5119514aeeac37b657f7",
"repository_slug": null,
"stale": true,
"reasons": ["target repository identity could not be derived from its git remote"]

There is no origin remote in this checkout (git config --get remote.origin.url
exits 1; git remote lists only prgs). refs/remotes/origin/master is an
orphan remote-tracking ref left behind by a remote that was removed. The parity
gate read that abandoned ref, compared HEAD against a long-dead commit, and reported
the target repository as stale — while simultaneously failing to derive the
repository identity because the origin remote it assumed does not exist.

So the reporting bug is not hypothetical or MDCPS-specific. It already produces a
false stale: true and a null identity against the PRGS repository itself.

Why no new configuration field is needed

Git already records the authoritative default branch per remote:

$ git symbolic-ref refs/remotes/prgs/HEAD
refs/remotes/prgs/master

And canonical_repository_root.repository_identity_slug() (the existing
authoritative repository/context resolver, #706/#973) already probes remotes in
order and successfully identifies the right one — it simply discards the remote
name after using it, returning only the owner/repo slug.

The information required to fix this is therefore already present and already
resolved. The fix extends the existing resolver to stop throwing away what it
learned. No second source of repository truth, and no new configuration field.

Scope of work

Remove PRGS-specific prgs/master assumptions from cross-repository mutation gating.
Remove origin/master assumptions from related parity reporting.
Derive the actual remote name (case-sensitively preserved — MDCPS must never
be folded to mdcps) and the authoritative integration/default branch.
Use one consistent resolved target for both gating and reporting, so the two can
never again disagree.
Preserve existing PRGS behavior exactly: prgs + master must keep resolving to
refs/remotes/prgs/master and the same SHA as today.
Support repositories such as MDCPS/dev without special-casing MDCPS anywhere.
Remain fail-closed when the target is missing, stale, divergent, or ambiguous. An
underivable base ref must never fall back to an unrelated PRGS commit.
Test all four affected production callers.
Leave MDCPS and Weekly Briefings repository structure untouched.

Explicit non-goals

Not to be done under any circumstance:

Do not create a fake master branch in a target repository.
Do not add or rename an origin remote.
Do not change any target repository's default branch.
Do not compare a target checkout against an unrelated PRGS commit.
Do not special-case MDCPS, WeeklyBriefings-Meta, or dev.

Acceptance criteria

Existing PRGS behavior using prgs/master is unchanged.
A repository using remote MDCPS and branch dev resolves refs/remotes/MDCPS/dev.
A repository with no remote named origin resolves correctly.
Remote-name case is preserved exactly end to end.
A local target equal to the resolved remote tip reports in-parity.
A local target behind or divergent from the resolved tip is reported as such.
A missing target remote or missing tracking ref fails closed with a reason.
Ambiguous remote/base resolution fails closed rather than guessing.
Mutation gating and parity reporting resolve the same target.
Every affected production caller supplies or consumes the resolved target correctly.

## Summary Cross-repository mutation gating and parity reporting each hardcode a PRGS-specific base ref. A namespace whose canonical repository root points at any repository that does not use the remote `prgs` with branch `master` cannot prove base equivalence, so every gated mutation fails closed with no reachable remedy. Two independent hardcoded assumptions, in two different modules, disagreeing with each other and with reality. ## Observed failure A valid cross-repository target: ``` Repository: MDCPS/WeeklyBriefings-Meta Remote: MDCPS Integration/default branch: dev Tracking ref: refs/remotes/MDCPS/dev ``` fails create-issue bootstrap with: ``` blocker_kind: missing_issue_worktree Create-issue bootstrap guard (#749): live master tip is unknown; base equivalence to live master cannot be proven ``` The guard probes only `prgs/master` and `refs/remotes/prgs/master`. Neither exists in that checkout, so the resolver returns `None`, base equivalence is unprovable, and the bootstrap fails closed. The target repository is correct and healthy; the guard is asking it the wrong question. ## Confirmed defect sites (verified at 108cbfa173de) ### 1. `root_checkout_guard.py` — mutation gating - Line 23: `REMOTE_MASTER_REFS = ("prgs/master", "refs/remotes/prgs/master")` - Line 26 `resolve_remote_master_sha()` accepts a `remote_refs` override, but **all four production callers omit it** and silently inherit the PRGS default: - `gitea_mcp_server.py:1055` — author issue bootstrap - `gitea_mcp_server.py:1085` — create-issue bootstrap (#749/#757 path) - `gitea_mcp_server.py:1306` — namespace mutation preflight - `gitea_mcp_server.py:1990` — `_enforce_root_checkout_guard` (#475) - Line 106-107 hardcodes the literal string `prgs/master` into the operator-facing failure message, so even a correct non-PRGS failure is reported misleadingly. ### 2. `master_parity_gate.py` — parity reporting - Line 381: `DEFAULT_TARGET_TRACKING_REF = "refs/remotes/origin/master"` - Line 411: `assess_target_repository_parity(..., tracking_ref=DEFAULT_TARGET_TRACKING_REF)` - Line 466: repository identity is read via `git remote get-url origin` — a hardcoded remote name. The two modules do not even agree with each other: gating assumes remote `prgs`, reporting assumes remote `origin`. At most one can be right for any given repository, and for a repository using neither, both are wrong. ### Live evidence in this very repository This reporting defect is observable on Gitea-Tools itself, today: ``` "tracking_ref": "refs/remotes/origin/master", "remote_tracking_head": "08c3488d7c35ba27efcd5119514aeeac37b657f7", "repository_slug": null, "stale": true, "reasons": ["target repository identity could not be derived from its git remote"] ``` There is no `origin` remote in this checkout (`git config --get remote.origin.url` exits 1; `git remote` lists only `prgs`). `refs/remotes/origin/master` is an **orphan remote-tracking ref left behind by a remote that was removed**. The parity gate read that abandoned ref, compared HEAD against a long-dead commit, and reported the target repository as stale — while simultaneously failing to derive the repository identity because the `origin` remote it assumed does not exist. So the reporting bug is not hypothetical or MDCPS-specific. It already produces a false `stale: true` and a null identity against the PRGS repository itself. ## Why no new configuration field is needed Git already records the authoritative default branch per remote: ``` $ git symbolic-ref refs/remotes/prgs/HEAD refs/remotes/prgs/master ``` And `canonical_repository_root.repository_identity_slug()` (the existing authoritative repository/context resolver, #706/#973) **already probes remotes in order and successfully identifies the right one** — it simply discards the remote name after using it, returning only the `owner/repo` slug. The information required to fix this is therefore already present and already resolved. The fix extends the existing resolver to stop throwing away what it learned. No second source of repository truth, and no new configuration field. ## Scope of work - Remove PRGS-specific `prgs/master` assumptions from cross-repository mutation gating. - Remove `origin/master` assumptions from related parity reporting. - Derive the actual remote name (**case-sensitively preserved** — `MDCPS` must never be folded to `mdcps`) and the authoritative integration/default branch. - Use one consistent resolved target for both gating and reporting, so the two can never again disagree. - Preserve existing PRGS behavior exactly: `prgs` + `master` must keep resolving to `refs/remotes/prgs/master` and the same SHA as today. - Support repositories such as `MDCPS/dev` without special-casing MDCPS anywhere. - Remain fail-closed when the target is missing, stale, divergent, or ambiguous. An underivable base ref must never fall back to an unrelated PRGS commit. - Test all four affected production callers. - Leave MDCPS and Weekly Briefings repository structure untouched. ## Explicit non-goals Not to be done under any circumstance: - Do not create a fake `master` branch in a target repository. - Do not add or rename an `origin` remote. - Do not change any target repository's default branch. - Do not compare a target checkout against an unrelated PRGS commit. - Do not special-case `MDCPS`, `WeeklyBriefings-Meta`, or `dev`. ## Acceptance criteria 1. Existing PRGS behavior using `prgs/master` is unchanged. 2. A repository using remote `MDCPS` and branch `dev` resolves `refs/remotes/MDCPS/dev`. 3. A repository with no remote named `origin` resolves correctly. 4. Remote-name case is preserved exactly end to end. 5. A local target equal to the resolved remote tip reports in-parity. 6. A local target behind or divergent from the resolved tip is reported as such. 7. A missing target remote or missing tracking ref fails closed with a reason. 8. Ambiguous remote/base resolution fails closed rather than guessing. 9. Mutation gating and parity reporting resolve the same target. 10. Every affected production caller supplies or consumes the resolved target correctly.

jcwalker3 added the status:in-progress mcp testing workflow-hardening preflight safety control-plane multi-project type:bug labels 2026-07-30 20:57:38 -05:00

jcwalker3 referenced this issue from a commit

2026-07-30 21:33:10 -05:00

fix(guard): derive cross-repository target base ref

jcwalker3 referenced a pull request that will close this issue

2026-07-30 21:35:56 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

jcwalker3 added status:pr-open and removed status:in-progress labels 2026-07-30 21:35:57 -05:00

jcwalker3 commented

2026-07-30 21:39:26 -05:00

[THREAD STATE LEDGER] Issue #983 / PR #984 — author implementation complete, pull request open

What is true now:

Issue state: open, labelled status:pr-open
Pull request state: open, mergeable, base master, head fix/issue-983-cross-repo-base-ref
Current head SHA: 2d5d5c9d17
Remote head equals local head at 2d5d5c9d17
Server-side decision state: no reviewer verdict exists on Gitea for this pull request
Local verdict/state: author implementation complete locally, no verdict prepared, the author holds no review verdict of any kind
Latest known validation: full suite run on the branch and on a clean baseline worktree at the identical base commit 108cbfa, failure sets byte-identical

What changed:

Issue #983 created, locked to branch fix/issue-983-cross-repo-base-ref
One commit 2d5d5c9 published to prgs, only the issue branch pushed
Pull request #984 opened against master

What is blocked:

Blocker classification: no blocker

Who/what acts next:

Next actor: reviewer
Required action: review pull request #984 at head 2d5d5c9d17
Do not do: the author must not review, approve, merge, restart production MCP servers, or remove the implementation worktree
Resume from: pull request #984

Server-side mutation ledger:

gitea_create_issue → issue #983 created with nine verified labels
gitea_lock_issue → issue lock acquired at base, later renewed by exact recorded owner after publication
gitea_publish_unpublished_issue_branch → branch published and verified at 2d5d5c9d17
gitea_create_pr → pull request #984 opened, issue transitioned to status:pr-open

Canonical Issue State

STATE: implementation complete, pull request #984 open and awaiting reviewer
WHO_IS_NEXT: reviewer
NEXT_ACTION: review pull request #984 at head 2d5d5c9d17, confirming that the derived base ref removes the prgs/master gating assumption and the origin/master reporting assumption, that remote-name case is preserved exactly, and that fail-closed refusals carry a reason_code
NEXT_PROMPT: Review pull request #984 on Scaled-Tech-Consulting/Gitea-Tools at head 2d5d5c9d17. Verify that root_checkout_guard no longer inherits the prgs/master default at any of its five production consumers, that master_parity_gate derives its tracking ref and repository identity instead of assuming a remote named origin, that canonical_repository_root.resolve_target_base_ref preserves exact remote-name case and refuses ambiguous or underivable targets with a reason_code, and that tests/test_issue_983_cross_repo_base_ref.py covers the MDCPS/dev cross-repository case without special-casing MDCPS. Confirm the twenty-eight full-suite failures are pre-existing at base commit 108cbfa and not introduced by this branch.
WHAT_HAPPENED: the guard and the parity report each hardcoded a different base ref, so the author derived the target instead by extending canonical_repository_root, the existing authoritative repository resolver, to return the remote name it already discovered while resolving repository identity and to build refs/remotes// from git's own recorded remote default branch; five production consumers now share that one resolved target, twenty-four hermetic regression tests were added, and one commit was published and opened as pull request #984
WHY: cross-repository mutation gating assumed the base ref was prgs/master while parity reporting independently assumed origin/master, so any repository using neither could not prove base parity and every gated mutation failed closed with no reachable remedy; the two modules also disagreed with each other, so at most one could be correct for any given repository
RELATED_PRS: PR #984 is the only pull request for this issue, opened from fix/issue-983-cross-repo-base-ref against master; no other pull request touches this work
BLOCKERS: none — the pull request is open and mergeable, no blocker applies
VALIDATION: focused suite tests/test_issue_983_cross_repo_base_ref.py 24 passed in 4.41s; sixteen directly affected suites 375 passed and 130 subtests passed in 36.93s; full suite on branch 28 failed, 6191 passed, 6 skipped, 1106 subtests passed; full suite on clean baseline worktree at the identical base commit 108cbfa 28 failed, 6166 passed, 6 skipped, 1106 subtests passed; both sorted FAILED lists diffed byte-identical, so zero failures were introduced and the plus twenty-five passed delta is the new tests
LAST_UPDATED_BY: author (prgs-author, jcwalker3)

[THREAD STATE LEDGER] Issue #983 / PR #984 — author implementation complete, pull request open What is true now: - Issue state: open, labelled status:pr-open - Pull request state: open, mergeable, base master, head fix/issue-983-cross-repo-base-ref - Current head SHA: 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc - Remote head equals local head at 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc - Server-side decision state: no reviewer verdict exists on Gitea for this pull request - Local verdict/state: author implementation complete locally, no verdict prepared, the author holds no review verdict of any kind - Latest known validation: full suite run on the branch and on a clean baseline worktree at the identical base commit 108cbfa, failure sets byte-identical What changed: - Issue #983 created, locked to branch fix/issue-983-cross-repo-base-ref - One commit 2d5d5c9 published to prgs, only the issue branch pushed - Pull request #984 opened against master What is blocked: - Blocker classification: no blocker Who/what acts next: - Next actor: reviewer - Required action: review pull request #984 at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc - Do not do: the author must not review, approve, merge, restart production MCP servers, or remove the implementation worktree - Resume from: pull request #984 Server-side mutation ledger: - gitea_create_issue → issue #983 created with nine verified labels - gitea_lock_issue → issue lock acquired at base, later renewed by exact recorded owner after publication - gitea_publish_unpublished_issue_branch → branch published and verified at 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc - gitea_create_pr → pull request #984 opened, issue transitioned to status:pr-open ## Canonical Issue State STATE: implementation complete, pull request #984 open and awaiting reviewer WHO_IS_NEXT: reviewer NEXT_ACTION: review pull request #984 at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc, confirming that the derived base ref removes the prgs/master gating assumption and the origin/master reporting assumption, that remote-name case is preserved exactly, and that fail-closed refusals carry a reason_code NEXT_PROMPT: Review pull request #984 on Scaled-Tech-Consulting/Gitea-Tools at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc. Verify that root_checkout_guard no longer inherits the prgs/master default at any of its five production consumers, that master_parity_gate derives its tracking ref and repository identity instead of assuming a remote named origin, that canonical_repository_root.resolve_target_base_ref preserves exact remote-name case and refuses ambiguous or underivable targets with a reason_code, and that tests/test_issue_983_cross_repo_base_ref.py covers the MDCPS/dev cross-repository case without special-casing MDCPS. Confirm the twenty-eight full-suite failures are pre-existing at base commit 108cbfa and not introduced by this branch. WHAT_HAPPENED: the guard and the parity report each hardcoded a different base ref, so the author derived the target instead by extending canonical_repository_root, the existing authoritative repository resolver, to return the remote name it already discovered while resolving repository identity and to build refs/remotes/<remote>/<branch> from git's own recorded remote default branch; five production consumers now share that one resolved target, twenty-four hermetic regression tests were added, and one commit was published and opened as pull request #984 WHY: cross-repository mutation gating assumed the base ref was prgs/master while parity reporting independently assumed origin/master, so any repository using neither could not prove base parity and every gated mutation failed closed with no reachable remedy; the two modules also disagreed with each other, so at most one could be correct for any given repository RELATED_PRS: PR #984 is the only pull request for this issue, opened from fix/issue-983-cross-repo-base-ref against master; no other pull request touches this work BLOCKERS: none — the pull request is open and mergeable, no blocker applies VALIDATION: focused suite tests/test_issue_983_cross_repo_base_ref.py 24 passed in 4.41s; sixteen directly affected suites 375 passed and 130 subtests passed in 36.93s; full suite on branch 28 failed, 6191 passed, 6 skipped, 1106 subtests passed; full suite on clean baseline worktree at the identical base commit 108cbfa 28 failed, 6166 passed, 6 skipped, 1106 subtests passed; both sorted FAILED lists diffed byte-identical, so zero failures were introduced and the plus twenty-five passed delta is the new tests LAST_UPDATED_BY: author (prgs-author, jcwalker3)

sysadmin referenced this issue

2026-07-30 21:54:02 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

sysadmin referenced this issue

2026-07-30 21:59:12 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

sysadmin referenced this issue

2026-07-30 21:59:45 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

jcwalker3 referenced this issue from a commit

2026-07-30 23:02:14 -05:00

fix(guard): derive base ref from configured upstream, not the remote-HEAD cache

jcwalker3 commented

2026-07-30 23:17:14 -05:00

[THREAD STATE LEDGER] Issue #983 / PR #984 — REQUEST_CHANGES review 658 remediated at new head 03b434a0b6

What is true now:

Server-side decision state: no server-side review state changed by this author cycle. Review 658 (REQUEST_CHANGES, reviewer sysadmin, at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc) is untouched — not dismissed, not overwritten, not concealed. has_blocking_change_requests=true, approval_visible=false, approval_at_current_head=false.
Local verdict/state: both blocking findings are corrected in code with regression coverage that fails against the previous head. PR #984 remains in open state, base master, head branch fix/issue-983-cross-repo-base-ref, body links Closes #983.
Latest known verification: focused suite 37 passed; nineteen affected suites 441 passed with 167 subtests passed; full suite 28 failed / 6204 passed / 6 skipped / 1106 subtests passed against a clean baseline worktree at the identical base commit 108cbfa showing 28 failed / 6166 passed / 6 skipped / 1106 subtests passed. Sorted FAILED lists are byte-identical (sha1 092dae4bc8c4e77d14504d90690d50e0fcd2f637) — zero introduced failures.

What changed:

New head 03b434a0b631a197005068725176b3726a46ae89 pushed to fix/issue-983-cross-repo-base-ref; remote head equals local head; worktree clean.
B1 — refs/remotes/<remote>/HEAD is no longer authoritative. It is a clone-time cache that an ordinary fetch never refreshes, so on the real target it named main while the checkout tracked and sat exactly on dev. resolve_target_base_ref now derives from the identity remote, then the checkout's own configured upstream (branch.<current>.remote + branch.<current>.merge) accepted only when it names that remote and its tracking ref exists, then exactly one present master/main/dev tracking ref. The cached symref is demoted to an observation reported as cached_remote_head_branch / cached_remote_head_conflicts and named in refusal text; it never decides the branch and never breaks a tie.
B2 — the reporting path no longer launders an inferred remote into explicit caller intent. The parameter is renamed explicit_remote through resolve_target_base_ref, resolve_remote_master_sha, and resolve_remote_master_ref_state; assess_target_repository_parity passes none and now resolves identity through the new ambiguity-aware assess_identity_remote. An ambiguous target yields a null slug, no tracking ref, and the same reason_code the guard emits. resolve_identity_remote / repository_identity_slug keep first-wins behaviour for the #706/#973 canonical-root validation path.
Live read-only verification: /Users/jasonwalker/Development/weekly-briefings now derives MDCPS / dev / refs/remotes/MDCPS/dev, source configured_branch_upstream, cached_remote_head_conflicts=true, checkout not stale at a37ac427c18b. PRGS is unchanged — prgs / master / refs/remotes/prgs/master, identical SHA 108cbfa173de, not stale.
Regression fixtures added: the principal MDCPS/dev case now reproduces the real stale-cache disagreement (upstream dev, cached refs/remotes/MDCPS/HEAD pointing at main, both refs present at different commits) instead of manufacturing the cache state; plus cache-alone never proves a target, cache never breaks a tie, guard and parity report agree on an ambiguous remote and on an ambiguous branch, explicit disambiguation stays distinct from inferred identity, no production caller passes explicit_remote, and a read-only proof snapshotting refs, remotes, local config, HEAD, branch, working-tree status, and the cached symref.

What is blocked:

Blocker classification: no blocker
The PR description text is now inaccurate in three places and cannot be edited from the author role under the #618 wall (gitea_edit_pr exposes no worktree_path). Treat this comment as the accurate record: the section "How the authoritative target is resolved" still describes step 2 as refs/remotes/<remote>/HEAD; "PRGS compatibility" still cites source remote_head_symref; and "Exact test results" still cites the previous head's counts of 24 focused tests, 375 affected-suite passes, and 6191 full-suite passes.

Who/what acts next:

Next actor: reviewer
Required action: perform an independent formal review of new head 03b434a0b631a197005068725176b3726a46ae89 as prgs-reviewer / sysadmin, confirming B1 and B2 remediation and the regression fixtures, then record a formal verdict through the native review API.
Do not do: do not dismiss, overwrite, or conceal review 658; do not merge PR #984; do not run git fetch, git remote set-head, or any ref mutation against the Weekly Briefings target; do not synchronize the production control checkout; do not restart MCP servers; do not change the author binding to mdcps-author.

Canonical Issue State

STATE: remediated-at-new-head-awaiting-independent-formal-review
WHO_IS_NEXT: reviewer
NEXT_ACTION: Review new head 03b434a0b6 on PR #984 as prgs-reviewer and record an independent formal verdict; review 658 at the prior head stays on the record untouched.
NEXT_PROMPT:

Continue Reviewer work on Gitea-Tools PR #984 (issue #983) as namespace gitea-reviewer, profile prgs-reviewer, identity sysadmin, repository Scaled-Tech-Consulting/Gitea-Tools.

Invoke the canonical gitea-workflow skill first. Verify runtime parity, repository binding, and reviewer mutation capability with fresh native calls.

The author remediated formal review 658 (REQUEST_CHANGES at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc). The new head is 03b434a0b631a197005068725176b3726a46ae89. Bind a review worktree detached at that exact head and confirm merge-base equals 108cbfa173de34470d7abc022b929e6b3adc418a.

Verify B1: canonical_repository_root.resolve_target_base_ref no longer treats refs/remotes/<remote>/HEAD as authoritative. Confirm precedence is identity remote, then the checkout's configured upstream (branch.<current>.remote plus branch.<current>.merge, accepted only when its tracking ref exists), then exactly one present master/main/dev tracking ref, and that the cached symref is reported but never decides the branch or breaks a tie. Execute the resolver read-only against /Users/jasonwalker/Development/weekly-briefings and confirm it derives MDCPS/dev with the checkout not stale, and against the Gitea-Tools control checkout to confirm prgs/master is unchanged.

Verify B2: master_parity_gate.assess_target_repository_parity passes no remote into resolve_target_base_ref, resolves identity through assess_identity_remote, and fails closed on an ambiguous target with a null repository_slug and the same reason_code the guard emits. Reproduce a hermetic two-remote repository and confirm the guard and the report agree.

Confirm the regression fixtures include the stale-cache disagreement (upstream dev while refs/remotes/MDCPS/HEAD points at main) rather than a manufactured cache, and that no MDCPS, WeeklyBriefings-Meta, or dev special-casing was introduced.

Run the focused issue #983 suite, the affected suites, and the broader suite with a baseline comparison at 108cbfa. Report exact passed, failed, skipped, and subtest counts.

Do not merge. Do not dismiss or overwrite review 658. Do not run git fetch or git remote set-head against any target repository. Record one formal verdict for this head.

WHAT_HAPPENED: Author cycle remediated the two blocking findings of review 658 and pushed commit 03b434a0b6 to fix/issue-983-cross-repo-base-ref, replacing the stale remote-HEAD cache with the checkout's configured upstream as the authoritative base signal, and separating explicit caller disambiguation from internally inferred identity so an ambiguous target fails closed identically in gating and in reporting; the prior review verdict was left in place and a fresh independent review of the new head is required.
WHY: The previous head derived the integration branch from a clone-time cache that fetch never refreshes, which produced MDCPS/main for a Weekly Briefings checkout sitting exactly on its MDCPS/dev tip and kept that target's author work failing closed; and the parity report re-supplied its own inferred remote to the resolver, suppressing the ambiguity gate so gating and reporting could evaluate different repositories.
RELATED_PRS: PR #984 (open, base master, head fix/issue-983-cross-repo-base-ref, links Closes #983) is the only pull request for issue #983; no other pull request is involved.
BLOCKERS: None outstanding for the author role. The PR description text remains inaccurate about the resolution order, the PRGS source label, and the previous head's test counts, and cannot be edited from the author role under the #618 wall; this comment is the accurate record.
VALIDATION: Focused tests/test_issue_983_cross_repo_base_ref.py 37 passed; nineteen affected suites 441 passed with 167 subtests passed; full suite 28 failed, 6204 passed, 6 skipped, 1106 subtests passed; clean baseline worktree at base commit 108cbfa 28 failed, 6166 passed, 6 skipped, 1106 subtests passed; sorted FAILED lists byte-identical at sha1 092dae4bc8c4e77d14504d90690d50e0fcd2f637 so zero failures were introduced; remote head equals local head at 03b434a0b6.
LAST_UPDATED_BY: author

[THREAD STATE LEDGER] Issue #983 / PR #984 — REQUEST_CHANGES review 658 remediated at new head 03b434a0b631 What is true now: - Server-side decision state: no server-side review state changed by this author cycle. Review 658 (REQUEST_CHANGES, reviewer `sysadmin`, at head `2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc`) is untouched — not dismissed, not overwritten, not concealed. `has_blocking_change_requests=true`, `approval_visible=false`, `approval_at_current_head=false`. - Local verdict/state: both blocking findings are corrected in code with regression coverage that fails against the previous head. PR #984 remains in open state, base `master`, head branch `fix/issue-983-cross-repo-base-ref`, body links `Closes #983`. - Latest known verification: focused suite 37 passed; nineteen affected suites 441 passed with 167 subtests passed; full suite 28 failed / 6204 passed / 6 skipped / 1106 subtests passed against a clean baseline worktree at the identical base commit `108cbfa` showing 28 failed / 6166 passed / 6 skipped / 1106 subtests passed. Sorted FAILED lists are byte-identical (sha1 `092dae4bc8c4e77d14504d90690d50e0fcd2f637`) — zero introduced failures. What changed: - New head `03b434a0b631a197005068725176b3726a46ae89` pushed to `fix/issue-983-cross-repo-base-ref`; remote head equals local head; worktree clean. - B1 — `refs/remotes/<remote>/HEAD` is no longer authoritative. It is a clone-time cache that an ordinary fetch never refreshes, so on the real target it named `main` while the checkout tracked and sat exactly on `dev`. `resolve_target_base_ref` now derives from the identity remote, then the checkout's own configured upstream (`branch.<current>.remote` + `branch.<current>.merge`) accepted only when it names that remote and its tracking ref exists, then exactly one present `master`/`main`/`dev` tracking ref. The cached symref is demoted to an observation reported as `cached_remote_head_branch` / `cached_remote_head_conflicts` and named in refusal text; it never decides the branch and never breaks a tie. - B2 — the reporting path no longer launders an inferred remote into explicit caller intent. The parameter is renamed `explicit_remote` through `resolve_target_base_ref`, `resolve_remote_master_sha`, and `resolve_remote_master_ref_state`; `assess_target_repository_parity` passes none and now resolves identity through the new ambiguity-aware `assess_identity_remote`. An ambiguous target yields a null slug, no tracking ref, and the same `reason_code` the guard emits. `resolve_identity_remote` / `repository_identity_slug` keep first-wins behaviour for the #706/#973 canonical-root validation path. - Live read-only verification: `/Users/jasonwalker/Development/weekly-briefings` now derives `MDCPS` / `dev` / `refs/remotes/MDCPS/dev`, source `configured_branch_upstream`, `cached_remote_head_conflicts=true`, checkout not stale at `a37ac427c18b`. PRGS is unchanged — `prgs` / `master` / `refs/remotes/prgs/master`, identical SHA `108cbfa173de`, not stale. - Regression fixtures added: the principal MDCPS/dev case now reproduces the real stale-cache disagreement (upstream `dev`, cached `refs/remotes/MDCPS/HEAD` pointing at `main`, both refs present at different commits) instead of manufacturing the cache state; plus cache-alone never proves a target, cache never breaks a tie, guard and parity report agree on an ambiguous remote and on an ambiguous branch, explicit disambiguation stays distinct from inferred identity, no production caller passes `explicit_remote`, and a read-only proof snapshotting refs, remotes, local config, HEAD, branch, working-tree status, and the cached symref. What is blocked: - Blocker classification: no blocker - The PR description text is now inaccurate in three places and cannot be edited from the author role under the #618 wall (`gitea_edit_pr` exposes no `worktree_path`). Treat this comment as the accurate record: the section "How the authoritative target is resolved" still describes step 2 as `refs/remotes/<remote>/HEAD`; "PRGS compatibility" still cites source `remote_head_symref`; and "Exact test results" still cites the previous head's counts of 24 focused tests, 375 affected-suite passes, and 6191 full-suite passes. Who/what acts next: - Next actor: reviewer - Required action: perform an independent formal review of new head `03b434a0b631a197005068725176b3726a46ae89` as `prgs-reviewer` / `sysadmin`, confirming B1 and B2 remediation and the regression fixtures, then record a formal verdict through the native review API. - Do not do: do not dismiss, overwrite, or conceal review 658; do not merge PR #984; do not run `git fetch`, `git remote set-head`, or any ref mutation against the Weekly Briefings target; do not synchronize the production control checkout; do not restart MCP servers; do not change the author binding to `mdcps-author`. ## Canonical Issue State STATE: remediated-at-new-head-awaiting-independent-formal-review WHO_IS_NEXT: reviewer NEXT_ACTION: Review new head 03b434a0b631a197005068725176b3726a46ae89 on PR #984 as prgs-reviewer and record an independent formal verdict; review 658 at the prior head stays on the record untouched. NEXT_PROMPT: ```text Continue Reviewer work on Gitea-Tools PR #984 (issue #983) as namespace gitea-reviewer, profile prgs-reviewer, identity sysadmin, repository Scaled-Tech-Consulting/Gitea-Tools. Invoke the canonical gitea-workflow skill first. Verify runtime parity, repository binding, and reviewer mutation capability with fresh native calls. The author remediated formal review 658 (REQUEST_CHANGES at head 2d5d5c9d174ae5f7a36c57e724af298fc5cff8dc). The new head is 03b434a0b631a197005068725176b3726a46ae89. Bind a review worktree detached at that exact head and confirm merge-base equals 108cbfa173de34470d7abc022b929e6b3adc418a. Verify B1: canonical_repository_root.resolve_target_base_ref no longer treats refs/remotes/<remote>/HEAD as authoritative. Confirm precedence is identity remote, then the checkout's configured upstream (branch.<current>.remote plus branch.<current>.merge, accepted only when its tracking ref exists), then exactly one present master/main/dev tracking ref, and that the cached symref is reported but never decides the branch or breaks a tie. Execute the resolver read-only against /Users/jasonwalker/Development/weekly-briefings and confirm it derives MDCPS/dev with the checkout not stale, and against the Gitea-Tools control checkout to confirm prgs/master is unchanged. Verify B2: master_parity_gate.assess_target_repository_parity passes no remote into resolve_target_base_ref, resolves identity through assess_identity_remote, and fails closed on an ambiguous target with a null repository_slug and the same reason_code the guard emits. Reproduce a hermetic two-remote repository and confirm the guard and the report agree. Confirm the regression fixtures include the stale-cache disagreement (upstream dev while refs/remotes/MDCPS/HEAD points at main) rather than a manufactured cache, and that no MDCPS, WeeklyBriefings-Meta, or dev special-casing was introduced. Run the focused issue #983 suite, the affected suites, and the broader suite with a baseline comparison at 108cbfa. Report exact passed, failed, skipped, and subtest counts. Do not merge. Do not dismiss or overwrite review 658. Do not run git fetch or git remote set-head against any target repository. Record one formal verdict for this head. ``` WHAT_HAPPENED: Author cycle remediated the two blocking findings of review 658 and pushed commit 03b434a0b631a197005068725176b3726a46ae89 to fix/issue-983-cross-repo-base-ref, replacing the stale remote-HEAD cache with the checkout's configured upstream as the authoritative base signal, and separating explicit caller disambiguation from internally inferred identity so an ambiguous target fails closed identically in gating and in reporting; the prior review verdict was left in place and a fresh independent review of the new head is required. WHY: The previous head derived the integration branch from a clone-time cache that fetch never refreshes, which produced MDCPS/main for a Weekly Briefings checkout sitting exactly on its MDCPS/dev tip and kept that target's author work failing closed; and the parity report re-supplied its own inferred remote to the resolver, suppressing the ambiguity gate so gating and reporting could evaluate different repositories. RELATED_PRS: PR #984 (open, base master, head fix/issue-983-cross-repo-base-ref, links Closes #983) is the only pull request for issue #983; no other pull request is involved. BLOCKERS: None outstanding for the author role. The PR description text remains inaccurate about the resolution order, the PRGS source label, and the previous head's test counts, and cannot be edited from the author role under the #618 wall; this comment is the accurate record. VALIDATION: Focused tests/test_issue_983_cross_repo_base_ref.py 37 passed; nineteen affected suites 441 passed with 167 subtests passed; full suite 28 failed, 6204 passed, 6 skipped, 1106 subtests passed; clean baseline worktree at base commit 108cbfa 28 failed, 6166 passed, 6 skipped, 1106 subtests passed; sorted FAILED lists byte-identical at sha1 092dae4bc8c4e77d14504d90690d50e0fcd2f637 so zero failures were introduced; remote head equals local head at 03b434a0b631a197005068725176b3726a46ae89. LAST_UPDATED_BY: author

sysadmin referenced this issue

2026-07-30 23:24:13 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

sysadmin referenced this issue

2026-07-30 23:51:16 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

sysadmin referenced this issue

2026-07-30 23:54:02 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984

sysadmin referenced this issue

2026-07-30 23:54:29 -05:00

fix(guard): derive target base ref for cross-repository checkouts #984