[kirtesh-cstk]

What changed

The field label's REFERENCE_MAP request now names the hovered field's entry: { entry_uid, content_type_uid, locale } instead of {}. The editor can then answer for that entry alone instead of building the map for every entry on the page. For a field on the page entry it can answer at once, since the page entry is never looked up for the map.

• getReferenceParentMap(fieldMetadata) sends the hovered field's entry identity; the call site passes props.fieldMetadata.
• The response shape and how the label reads it are unchanged.
• Editors that ignore the payload behave exactly as before.

Test evidence

• npx tsc --noEmit: 0 errors
• npx eslint on the changed files: 0 errors
• Full suite: 118 files, 918 tests passed
• New fieldLabelWrapper.referenceMapRequest.test.tsx: the request carries the hovered field's entry uid, content type and locale. It fails on develop_v4.

Measured on a production site with the matching editor change (the site's bundled SDK patched in the browser to send this payload): hovering fields of the page entry went from about 0.9s with 2 /references calls to about 0.1s with none. Fields of other entries are unchanged.

Needs manual QA

With the editor change deployed: hover fields of the page entry (no "referenced from" badge, label loads at once), then fields of a referenced entry (badge and tooltip still appear).

---

🤖 Generated with Claude Code

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	2	0	10	✅ Passed
🟠 High Severity	2	0	25	✅ Passed
🟡 Medium Severity	1	0	500	✅ Passed
🔵 Low Severity	1	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	68.72%	2597 / 3779
🔵	Statements	67.6%	2640 / 3905
🔵	Functions	66.28%	468 / 706
🔵	Branches	63.07%	1573 / 2494

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/visualBuilder/components/fieldLabelWrapper.tsx	60.9%	62.62%	69.56%	61.68%	48-49, 64-65, 113-116, 150-160, 180-182, 260-269, 276-279, 314-317, 322-349, 402, 407-410, 416, 575

Generated in workflow #958 for commit f19df3e by the Vitest Coverage Report Action

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	2	0	10	✅ Passed
🟠 High Severity	2	0	25	✅ Passed
🟡 Medium Severity	1	0	500	✅ Passed
🔵 Low Severity	1	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[karancs06]

LGTM!!