Skip to content

fix(client): refresh workspace files after disk changes - #4379

Open
PixPMusic wants to merge 5 commits into
pingdotgg:mainfrom
PixPMusic:fix/client-refresh-workspace-file-on-open
Open

fix(client): refresh workspace files after disk changes#4379
PixPMusic wants to merge 5 commits into
pingdotgg:mainfrom
PixPMusic:fix/client-refresh-workspace-file-on-open

Conversation

@PixPMusic

@PixPMusic PixPMusic commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Summary

  • revalidate cached workspace files whenever a preview opens
  • subscribe mounted file queries to debounced native filesystem change events instead of polling contents
  • dispose file queries and watchers when no preview is mounted
  • skip file queries entirely when no web preview path is selected

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.ts
  • targeted contracts, server, client-runtime, web, and mobile typechecks
  • targeted formatting and lint checks
  • isolated web and iOS verification covering external edits while open and unmount → disk edit → remount

Note

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.watchFile RPC (orchestration read scope) backed by WorkspaceFileSystem.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 refreshQueryOnSuccess so a projectsReadFile query re-fetches whenever the matching projectsWatchFile subscription emits a success. readFile atoms 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: useProjectFileQuery no longer subscribes when relativePath is 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.watchFile streaming RPC to auto-refresh workspace file queries on disk changes

  • Adds a watchFile method to WorkspaceFileSystem that emits debounced ProjectFileChangeEvent stream entries when a workspace-relative file changes, including symlink target changes; rejects paths that escape the workspace root.
  • Exposes this as a streaming projects.watchFile WebSocket RPC (with orchestration read scope required) via ws.ts and the updated contracts in rpc.ts.
  • Introduces refreshQueryOnSuccess in runtime.ts — a helper that wraps a query atom with a signal atom so the query auto-refreshes on each success event from the subscription.
  • Wires readFile queries in projectCommands.ts to revalidate on mount and refresh automatically when the projects.watchFile subscription fires, replacing the previous static query atom family.
  • Risk: readFile queries now have zero idle TTL and stale time, meaning they are evicted immediately when idle; the preload path compensates with a 1s WORKSPACE_FILE_PRELOAD_RETAIN_MS idle TTL.

Macroscope summarized 06025a7.

@coderabbitai

coderabbitai Bot commented Jul 23, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 775be6df-ecfd-4a1b-a83a-24208af92087

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:M 30-99 changed lines (additions + deletions). labels Jul 23, 2026
Comment thread apps/web/src/components/files/FilePreviewPanel.tsx Outdated
Comment thread packages/client-runtime/src/state/runtime.ts
@macroscopeapp

macroscopeapp Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: 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.

@github-actions github-actions Bot added size:L 100-499 changed lines (additions + deletions). and removed size:M 30-99 changed lines (additions + deletions). labels Jul 23, 2026
Comment thread apps/server/src/workspace/WorkspaceFileSystem.ts Outdated
Comment thread packages/client-runtime/src/state/projectCommands.ts

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Fix All in Cursor

❌ 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.

Comment thread packages/client-runtime/src/state/projectCommands.ts
@PixPMusic
PixPMusic force-pushed the fix/client-refresh-workspace-file-on-open branch from e98bb71 to a27510d Compare August 3, 2026 16:07
patroza added a commit to patroza/t3code that referenced this pull request Aug 4, 2026
…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>
patroza added a commit to patroza/t3code that referenced this pull request Aug 4, 2026
…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>
patroza added a commit to patroza/t3code that referenced this pull request Aug 4, 2026
…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>
patroza added a commit to patroza/t3code that referenced this pull request Aug 5, 2026
…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>
patroza added a commit to patroza/t3code that referenced this pull request Aug 5, 2026
…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>
patroza added a commit to patroza/t3code that referenced this pull request Aug 5, 2026
…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>
omegent-app Bot added a commit to patroza/t3code that referenced this pull request Aug 6, 2026
…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>
@PixPMusic
PixPMusic force-pushed the fix/client-refresh-workspace-file-on-open branch from a27510d to 06025a7 Compare August 10, 2026 08:06
@t3dotgg t3dotgg added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. and removed vouch:unvouched PR author is not yet trusted in the VOUCHED list. labels Aug 24, 2026
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
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
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
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
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
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
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
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
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
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
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 27, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 28, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 29, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 30, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Aug 31, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
donjor added a commit to RSI-Software/t3code-hyprws that referenced this pull request Sep 2, 2026
A fork issue or comment that wrote a live `pingdotgg/t3code#N` or a bare upstream URL made GitHub post a "mentioned this" event on the upstream thread, from our bot. The rule is now stated and enforced: wrap the citation in a code span, or paste the survey in a fence.

`vp run fork:upstream-refs` masks HTML comments, fenced blocks, and code spans at their original offsets, then refuses any live upstream issue, pull request, commit, or discussion reference left outside them, reporting line and column for each.

A bare `#N` is a finding too. GitHub resolves a number this fork has never issued against the repository it was forked from: `pingdotgg#5779` in a fork body links to `pingdotgg/issues/5779` and posts the backlink there. The guard has no network, so it cannot ask which numbers the fork holds and reports every bare number. Writing the fork item in full as `#108` clears it and still renders as `#108`.

```text
$ vp run fork:upstream-refs body.md
1:22 pingdotgg#4379 (cross-repo issue reference)
1:48 pingdotgg#4402 (upstream item URL)
3:11 #107 (bare item number, resolved upstream when this fork has no such item)
failed: 3 live upstream reference(s) in body.md; wrap each one in a code span or a fenced block so GitHub does not post a backlink on the pingdotgg/t3code thread, or write a bare number that names a fork item as RSI-Software/t3code-hyprws#N, which renders the same (docs/internals/fork-development.md)
```

Masking holds against the cases that make a naive scanner lie: indented and blockquoted fences, backtick runs that would otherwise pair across paragraphs, and emoji shifting every column after them. Item URLs no longer over-match `/issues/new` or `/discussions/categories/ideas`, which the fork's own `README.md` and `CONTRIBUTING.md` carry.

`AGENTS.md` and the fork guide carry the code-span form and the reason. Fork CI runs the guard on every pull-request body as a post-publication backstop, before the ledger step so a ledger failure cannot hide it.

A scan of the whole fork estate, 120 item bodies plus 95 comments plus 1 review, found zero live cross-repo, URL, commit, or discussion references. It is not a vacuous pass: the items that mention upstream carry their citations inside a fence or code span already.

The bare-number rule is preventive, and it is not free. The same scan reports 94 bare numbers across 47 surfaces. Every one of them names a number this fork holds today, so none has ever posted upstream; they are unqualified references that would resolve upstream the moment a fork body cited a number the fork does not own. Existing bodies are not being rewritten. New prose qualifies its references, and this pull request's own body does.

Refs #107

The refusal condition is not met by this PR. CI reads a body GitHub already published, and issue bodies and comments have no trigger at all, so the guard catches a live reference after the backlink exists. The pre-publication gate belongs in the `ghb` publish path, which runs the guard on the body file before posting; that is fork tooling a sibling change owns. The two stated-rule and clean-scan conditions are met here.

One residual, out of scope here: `docs/internals/t3-connect.md` carries `(pingdotgg#5051)` in prose inherited from upstream. It is a true positive that the guard never reads, because the guard scans GitHub bodies and not the tracked tree.

Fork-Domain: fork-meta
Fork-Tier: qol
Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L 100-499 changed lines (additions + deletions). vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants