fix(client): refresh workspace files after disk changes - #4379
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 |
ApprovabilityVerdict: Needs human review This PR introduces a new file watching feature with a streaming RPC endpoint, new server-side watch logic including symlink and security handling, and new client-side state management patterns. Despite the "fix" title, this is a new capability spanning multiple layers that warrants human review. You can customize Macroscope's approvability policy. Learn more. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 394b9a9. Configure here.
e98bb71 to
a27510d
Compare
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
…gdotgg#4379) (#312) Imported from pingdotgg#4379 at a27510d. Open file previews revalidate on mount and subscribe to debounced native filesystem watches so external edits (editors, git, agents) show without a manual refresh. Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Enrico Polanski <16064771+enricopolanski@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
a27510d to
06025a7
Compare
A fork issue, comment, or pull-request body that writes a live upstream reference makes GitHub post a backlink on that upstream thread, from the fork's bot account. The fork does not file upstream, so the event is noise on somebody else's issue. `vp run fork:upstream-refs <file>` reads a body from a file or stdin, blanks fenced blocks, indented code, code spans, and HTML comments at their original offsets, and exits 1 with the line and column of anything left live. A bare `pingdotgg#4379` counts: GitHub resolves a number this fork has never issued against the repository it was forked from, so the plainest-looking citation is the one that reaches upstream without naming it. Writing a fork reference as `#108` clears the guard and still renders `#108`. An upstream URL that names no item is not a finding. Inline pairing splits on every block start that ends a paragraph, so a backtick run cannot reach across a heading, a thematic break, a table cell, an HTML block, or a deeper blockquote to mask a citation between them. Each rule was checked in both directions against GitHub's own Markdown renderer. The pre-publication run is the gate: GitHub posts the backlink when the item is created, so nothing that reacts afterwards can withdraw it. Fork CI re-runs the guard on every pull-request body as a backstop and says so. `docs/internals/scripts.md` records what stays unguarded, including issue bodies, comments, titles, and the parts of CommonMark the reader skips. Fork-Domain: fork-meta Fork-Tier: qol
A fork issue, comment, or pull-request body that writes a live upstream reference makes GitHub post a backlink on that upstream thread, from the fork's bot account. The fork does not file upstream, so the event is noise on somebody else's issue. `vp run fork:upstream-refs <file>` reads a body from a file or stdin, blanks fenced blocks, indented code, code spans, and HTML comments at their original offsets, and exits 1 with the line and column of anything left live. A bare `pingdotgg#4379` counts: GitHub resolves a number this fork has never issued against the repository it was forked from, so the plainest-looking citation is the one that reaches upstream without naming it. Writing a fork reference as `#108` clears the guard and still renders `#108`. An upstream URL that names no item is not a finding. Inline pairing splits on every block start that ends a paragraph, so a backtick run cannot reach across a heading, a thematic break, a table cell, an HTML block, or a deeper blockquote to mask a citation between them. Each rule was checked in both directions against GitHub's own Markdown renderer. The pre-publication run is the gate: GitHub posts the backlink when the item is created, so nothing that reacts afterwards can withdraw it. Fork CI re-runs the guard on every pull-request body as a backstop and says so. `docs/internals/scripts.md` records what stays unguarded, including issue bodies, comments, titles, and the parts of CommonMark the reader skips. Fork-Domain: fork-meta Fork-Tier: qol
A fork issue, comment, or pull-request body that writes a live upstream reference makes GitHub post a backlink on that upstream thread, from the fork's bot account. The fork does not file upstream, so the event is noise on somebody else's issue. `vp run fork:upstream-refs <file>` reads a body from a file or stdin, blanks fenced blocks, indented code, code spans, and HTML comments at their original offsets, and exits 1 with the line and column of anything left live. A bare `pingdotgg#4379` counts: GitHub resolves a number this fork has never issued against the repository it was forked from, so the plainest-looking citation is the one that reaches upstream without naming it. Writing a fork reference as `#108` clears the guard and still renders `#108`. An upstream URL that names no item is not a finding. Inline pairing splits on every block start that ends a paragraph, so a backtick run cannot reach across a heading, a thematic break, a table cell, an HTML block, or a deeper blockquote to mask a citation between them. Each rule was checked in both directions against GitHub's own Markdown renderer. The pre-publication run is the gate: GitHub posts the backlink when the item is created, so nothing that reacts afterwards can withdraw it. Fork CI re-runs the guard on every pull-request body as a backstop and says so. `docs/internals/scripts.md` records what stays unguarded, including issue bodies, comments, titles, and the parts of CommonMark the reader skips. Fork-Domain: fork-meta Fork-Tier: qol
A fork issue, comment, or pull-request body that writes a live upstream reference makes GitHub post a backlink on that upstream thread, from the fork's bot account. The fork does not file upstream, so the event is noise on somebody else's issue. `vp run fork:upstream-refs <file>` reads a body from a file or stdin, blanks fenced blocks, indented code, code spans, and HTML comments at their original offsets, and exits 1 with the line and column of anything left live. A bare `pingdotgg#4379` counts: GitHub resolves a number this fork has never issued against the repository it was forked from, so the plainest-looking citation is the one that reaches upstream without naming it. Writing a fork reference as `#108` clears the guard and still renders `#108`. An upstream URL that names no item is not a finding. Inline pairing splits on every block start that ends a paragraph, so a backtick run cannot reach across a heading, a thematic break, a table cell, an HTML block, or a deeper blockquote to mask a citation between them. Each rule was checked in both directions against GitHub's own Markdown renderer. The pre-publication run is the gate: GitHub posts the backlink when the item is created, so nothing that reacts afterwards can withdraw it. Fork CI re-runs the guard on every pull-request body as a backstop and says so. `docs/internals/scripts.md` records what stays unguarded, including issue bodies, comments, titles, and the parts of CommonMark the reader skips. Fork-Domain: fork-meta Fork-Tier: qol
A fork issue, comment, or pull-request body that writes a live upstream reference makes GitHub post a backlink on that upstream thread, from the fork's bot account. The fork does not file upstream, so the event is noise on somebody else's issue. `vp run fork:upstream-refs <file>` reads a body from a file or stdin, blanks fenced blocks, indented code, code spans, and HTML comments at their original offsets, and exits 1 with the line and column of anything left live. A bare `pingdotgg#4379` counts: GitHub resolves a number this fork has never issued against the repository it was forked from, so the plainest-looking citation is the one that reaches upstream without naming it. Writing a fork reference as `#108` clears the guard and still renders `#108`. An upstream URL that names no item is not a finding. Inline pairing splits on every block start that ends a paragraph, so a backtick run cannot reach across a heading, a thematic break, a table cell, an HTML block, or a deeper blockquote to mask a citation between them. Each rule was checked in both directions against GitHub's own Markdown renderer. The pre-publication run is the gate: GitHub posts the backlink when the item is created, so nothing that reacts afterwards can withdraw it. Fork CI re-runs the guard on every pull-request body as a backstop and says so. `docs/internals/scripts.md` records what stays unguarded, including issue bodies, comments, titles, and the parts of CommonMark the reader skips. Fork-Domain: fork-meta Fork-Tier: qol
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>

Summary
Verification
vp test run apps/server/src/workspace/WorkspaceFileSystem.test.ts packages/client-runtime/src/state/runtime.test.ts apps/web/src/components/files/projectFilesQueryState.test.tsNote
Medium Risk
New per-open-file WebSocket subscriptions and fs watchers increase server/client load; read caching behavior changes (more refetch on mount) but auth and path-safety rules match existing read paths.
Overview
Workspace file previews now stay in sync when files change on disk outside the app, using native filesystem watches instead of long-lived cached reads.
Server & RPC: Adds a streaming
projects.watchFileRPC (orchestration read scope) backed byWorkspaceFileSystem.watchFile, which debounces directory watches, handles missing files and in-workspace symlink targets, and keeps the same workspace-root escape checks as reads.Client state: Introduces
refreshQueryOnSuccessso aprojectsReadFilequery re-fetches whenever the matchingprojectsWatchFilesubscription emits a success.readFileatoms use zero stale/idle TTL so watchers and queries drop when nothing is mounted; mobile preload applies a 1s idle TTL so preloaded reads still hand off cleanly to the live query.UI:
useProjectFileQueryno longer subscribes whenrelativePathis null, even if the hook is enabled.Reviewed by Cursor Bugbot for commit 06025a7. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Add
projects.watchFilestreaming RPC to auto-refresh workspace file queries on disk changeswatchFilemethod toWorkspaceFileSystemthat emits debouncedProjectFileChangeEventstream entries when a workspace-relative file changes, including symlink target changes; rejects paths that escape the workspace root.projects.watchFileWebSocket RPC (with orchestration read scope required) viaws.tsand the updated contracts inrpc.ts.refreshQueryOnSuccessinruntime.ts— a helper that wraps a query atom with a signal atom so the query auto-refreshes on each success event from the subscription.readFilequeries inprojectCommands.tsto revalidate on mount and refresh automatically when theprojects.watchFilesubscription fires, replacing the previous static query atom family.readFilequeries now have zero idle TTL and stale time, meaning they are evicted immediately when idle; the preload path compensates with a 1sWORKSPACE_FILE_PRELOAD_RETAIN_MSidle TTL.Macroscope summarized 06025a7.