records: land FLAMEGPU2, nothing outstanding

.claude/agents/intake.md

@@ -61,6 +61,16 @@ Two checks that are per-file, not top-level:
 - Grep the upstream's own docs: `grep -rniE 'amd|rocm|hip|gfx[0-9]' README* docs/`.
   Reference repos routinely link platform ports in a "notable forks" section, and that
   link IS the existing AMD port. Cheapest check available, highest signal.
+- List the upstream's OPEN pull requests and branches for the same work:
+  `gh pr list --repo <owner/repo> --state open --search "hip OR rocm OR amd" --json number,title,author,createdAt,isDraft`
+  and `gh api repos/<owner/repo>/branches --paginate --jq '.[].name' | grep -iE 'hip|rocm|amd'`.
+  An open draft PR is invisible to a docs grep and to a fork search, and it is the
+  strongest duplicate-effort signal there is: the maintainer or a contributor is
+  already doing the port. FLAMEGPU2 was adopted with the maintainer's own
+  "AMD GPU Support via HIP/ROCm" draft PR two months old and open on the upstream
+  repo; the screen missed it and a full parallel port was built before anyone
+  noticed. When such a PR exists, the recommendation is to contribute to it, not
+  to compete with it.
 - For the finer judgement -- is an existing port authoritative, and does that make the
   work "validate and improve" rather than "port from scratch" -- read the
   `cuda-to-rocm` skill's `references/assess-existing-support.md`.

.claude/skills/cuda-to-rocm/references/assess-existing-support.md

@@ -19,6 +19,8 @@ One more classification, easy to miss because the search finds it and you recogn
 
 When resuming follow-up work parked on a branch, check HOW the earlier PR landed before rebasing. A SQUASH-merge collapses the commits you branched from into one new commit with a different sha, so your branch's base is not an ancestor of upstream and `git rebase` replays content that is already merged, conflicting all the way. Re-derive instead: identify which of your commits are inside the squash (drop them), which touch files the merged PR never modified (transplant those -- they usually apply cleanly), and which are now superseded by what upstream did during the review rounds you were not tracking. A long review can add commits to the upstream PR that your branch never saw, so "my branch is the merged PR plus my extras" is false in both directions. (colmap: `rocm-sift-gpu` was 4 commits inside the squash + 3 transplantable SIFT commits + 2 superseded docs commits, against a PR that had continued for 5 more commits.)
 
+Contributing to a maintainer's own live HIP branch is a different shape from opening a port PR, and it has two recurring traps. First, your evidence is only about a sha, and their branch moves: state the tip sha you tested in the comment, and re-run on the arch you are differentiating on at THEIR current tip before offering numbers, because a branch that rebases can rewrite your fork base out of ancestry and a large refactor can regress the arch they do not own. (FLAMEGPU2: upstream's `amdgpu` branch gained 84 commits including an API abstraction series; gfx90a was re-run at the new tip but the offered gfx1100 numbers were still from the old base, and only a fresh wave32 run could show the abstraction held -- it did, 1070 passed / 64 skipped / 0 failed, matching wave64 exactly.) Second, pushing a branch cut from their branch to our fork can be rejected outright with `refusing to allow an OAuth App to create or update workflow .github/workflows/<f> without workflow scope`, even when your own commits touch no workflow file, because every commit of theirs that is new to the remote ships too and CI changes are common on an enablement branch. That is a token-scope decision for a person, not something to work around by rewriting the branch.
+
 Performance-critical kernels (attention, GEMM, quantization) are often tuned to NVIDIA-specific features (CUTLASS/CuTe, Hopper sm90 wgmma/MMA, warp specialization). A straight CUDA-to-HIP translation will compile and run but can leave large performance on the table versus an AMD-native implementation (rocWMMA, Composable Kernel, MFMA intrinsics). For these the planner decides between a mechanical port (correctness first) and an AMD-native rewrite of the hot kernels, and says which in plan.md. When hipify has nothing to translate at all -- CUTLASS, CuTe, raw PTX -- the question stops being performance and becomes whether an AMD-native target exists to reimplement against: `references/no-hip-equivalent.md`.
 
 A pull request's `author` is who OPENED it, not who wrote it. Judging "is this existing AMD support ours?" from that field alone gets it backwards on any collaborative PR, and ROCm-enablement PRs are often collaborative: an outside contributor starts one, we take it over, a maintainer finishes it. colmap#4420 was opened by a third party and reported that way by `gh pr view --json author`, while four of its eight commits were ours and the merged squash carries our `Co-authored-by` trailer. Read `pulls/<n>/commits` for per-commit authorship and the merge commit's trailers before concluding either "already supported by someone else" or "this is our work", because the two lead opposite ways: one says stop, the other says finish what is left.