chore: temporarily run knowledge-graph workflow on pull requests

Lets the graph be built and fetched before any release carries it, so the
self-update path can be exercised end to end. Also stamps the PR head commit
rather than the merge commit, which exists in no local clone and would make
every staleness check report an invalid revision range.

Dry-run only — drop this commit before merging.

.github/workflows/knowledge-graph.yml

@@ -27,6 +27,8 @@ on:
     workflows: ["Continuous Delivery"]
     types: [completed]
   workflow_dispatch: {}
+  # TEMPORARY dry-run trigger — this commit is meant to be dropped before merge.
+  pull_request: {}
 
 permissions:
   contents: read
@@ -51,7 +53,12 @@ jobs:
         id: gate
         run: |
           TAG="$(git tag --points-at HEAD | grep '^v' | head -n 1 || true)"
-          echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          # TEMPORARY: on pull_request the checkout is the merge commit, which exists in
+          # no local clone - stamping it would make every staleness check report
+          # "Invalid revision range". Stamp the PR head, which developers do have.
+          SHA="${{ github.event.pull_request.head.sha }}"
+          [ -n "$SHA" ] || SHA="$(git rev-parse HEAD)"
+          echo "sha=$SHA" >> "$GITHUB_OUTPUT"
           echo "tag=$TAG" >> "$GITHUB_OUTPUT"
           if [ "${{ github.event_name }}" != "workflow_run" ]; then
             # dry-run contexts: build, but there is no release to attach to

AGENTS.md

@@ -109,6 +109,29 @@ The `:?` guard matters: without it an unreadable `build_meta.json` yields an emp
 `git rev-list` cheerfully answers `0`, which is indistinguishable from a perfectly current map. In every
 non-zero case, say the map is stale rather than presenting its answer as current.
 
+### TEMPORARY — fetch the map from this pull request's build
+
+> **Dry-run only.** This section, and the `pull_request` trigger it depends on, are dropped before
+> merge. Once releases carry the asset, use *Fetching and refreshing the map* above instead.
+
+No release carries the graph yet, so take it from the artifact the knowledge-graph workflow attaches to
+its run on this pull request. **Do this yourself when `graphify-out/` is missing or the staleness check
+below reports anything other than `0` — do not ask first, and do not fall back to grep without saying
+that the map was unavailable.**
+
+```bash
+RUN=$(gh run list --repo bec-project/bec_widgets --workflow=knowledge-graph.yml \
+        --branch "$(git rev-parse --abbrev-ref HEAD)" --status success --limit 1 \
+        --json databaseId -q '.[0].databaseId')
+TMP=$(mktemp -d)
+gh run download "$RUN" --repo bec-project/bec_widgets -n knowledge-graph -D "$TMP"
+mkdir -p graphify-out && tar -xzf "$TMP"/knowledge-graph-v*.tar.gz -C graphify-out && rm -rf "$TMP"
+```
+
+Then run the same `git rev-list --count` check as above. A pull-request build stamps the PR *head*
+commit, so it reports `0` when your checkout sits at the PR head, and otherwise the number of commits
+you have added since. State which number you got before you use the map.
+
 `requires` is what to check when a *cross-repo* answer looks wrong. Note these are floors
 (`bec_lib~=3.134`), not the version resolved at build time — `bec` may be many releases past the floor —
 so treat them as a coarse signal, and read `bec`'s own graph or source when the question is really about

CLAUDE.md

@@ -14,6 +14,10 @@ truth). The points that matter most in day-to-day work:
   not the installed package, which can lag — with the `git rev-list --count` snippet in `AGENTS.md`.
   Anything but `0` means the map is behind your working tree: say so and verify against the code
   instead of answering from the graph.
+- **TEMPORARY (dropped before merge):** if `graphify-out/` is missing or that check is not `0`, fetch
+  the map yourself from this pull request's workflow artifact — see *TEMPORARY — fetch the map from
+  this pull request's build* in `AGENTS.md`. Do it without asking, and report the staleness number you
+  got before using the map.
 - **Import from `qtpy`, never `PySide6.*`.** CI greps for `from PySide6.` and fails the build (only
   `PySide6.QtDesigner` and `PySide6.scripts` are exempt).
 - **`bec_widgets/cli/client.py` and the Designer plugin files are generated — never hand-edit them.**