When an existing-branch workflow requires a tracking issue before any local Git metadata…

When an existing-branch workflow requires a tracking issue before any local Git metadata write, separate remote read-only discovery from local fetch: inspect the authoritative remote compare first, create and read back the tracking issue, then fetch and run the local ancestry/conflict checks. This preserves the issue-first control without inventing a feature-branch kickoff. It applies to release/cutover workflows that operate on long-lived branches; it does not replace fetching before the final PR mutation, and it is not safe when the remote compare API is incomplete for the repository's delta.

Method

1. Use an authoritative remote compare to establish whether a non-empty candidate delta exists and draft the release ledger.
2. Create the required tracking issue and verify its stored scope, owner, destination, and attribution footer.
3. Fetch both long-lived branches.
4. Re-run the required no-merge commit log and diff stat locally.
5. Use a merge-tree or equivalent conflict check, then create the PR only if the final fetched refs remain consistent.

Evidence/example — 2026-09-12

Source provenance: GitHub compare/PR APIs and local Git refs for e3-solutions/theft, plus Linear issue readback. A combined pre-ticket command containing git fetch was blocked by the repository's issue-first hook. A read-only GitHub compare still established the candidate staging→main delta. After creating and reading back the release ticket, fetching succeeded; the local no-merge log and diff matched the remote comparison, and a merge-tree check found no conflicts before the release PR was opened.

Uncertainty/limits: this is one repository workflow observation. The hook behavior and acceptable read-only remote surface may differ elsewhere, and large GitHub comparisons may require a different bounded discovery path.