docs(guardrails): don't let fetched SDK docs override tenant availability

[apetraru-uipath]

Three coded-guardrail references tell the agent to WebFetch core/guardrails/ and langchain/guardrails/ and treat them as a source of truth:

• uipath-agents/references/coded/capabilities/guardrails/guardrails.md
• uipath-agents/references/coded/capabilities/guardrails/guardrails-recommend.md
• uipath-review/references/agents/guardrails/coded-guardrails-review.md

Those pages just gained Platform Availability notes saying BYOG and LLM-as-judge aren't enabled on every tenant (UiPath/uipath-python#1868, UiPath/uipath-langchain-python#1045). Nothing told the agent that prose is product-wide, not a statement about the tenant in front of it.

The risk is a false stop — an agent refusing to author, or filing a review finding, for a validator that uip agent guardrails list reports as Available here. guardrails-recommend.md is the sharpest case: in Validate mode it already calls the SDK docs "authoritative, sufficient" and demotes the tenant list to a non-mandatory cross-check.

So this adds one precedence line to each file, placed where that file scopes what to take from the fetched pages. +11 lines, additive, no logic touched.

No skill gets an availability note of the docs' kind, deliberately. Skills already resolve availability the right way — at runtime, against the live tenant. A static "not available yet" line would go stale the moment the flag flips, and could cause the very refusal this PR guards against. The existing machinery is left alone: the mandatory Check Tenant Availability step, the low-code not-found/Available/Unauthorised ladder, ByoGuardrailsUnavailable in uipath-platform, and the disabled-configuration handling in uipath-review / uipath-troubleshoot.

Also checked and deliberately unchanged: uipath-planner/references/platform-availability-guide.md. It's a product × delivery-model matrix (Cloud vs Automation Suite) — wrong granularity for a per-tenant feature flag.

Flavors: only studioweb exists, it has no guardrail overrides, and none of the three files carry skill-flavor: markers. Plain canonical edit — no override work, no pack cycle needed.

Verification

npm run skills:validate — OK on the rebased tree (26 skills / 1726 files, both flavors compose).

Evals run with --type claude-code --model claude-sonnet-5, experiments/default.yaml, --driver tempdir, -D 'agent.setting_sources=[]'. Scope is the 17 tasks covering these three files — the 13 under uipath-agents/coded/guardrails/ plus the 4 coded_review_guardrail_*. Low-code and uipath-platform guardrail tasks are excluded; they don't fetch the Python SDK docs.

Two passes, because #2707 bumped the pin mid-review:

1. Full 17 on coder-eval 0.10.2 (the pin before this branch was rebased) — 15/17 pass. Both LLM-as-judge and all four coded-review tasks at 1.000. Task logs confirm the runs read the checked-out repo, not a stale global ~/.agents/skills copy.

2. Re-verified on the current pin 0.11.2. 0.11.0 made task.reference directory-only — a load-time breaking change — so first coder-eval plan over all 17: "All tasks are valid!" (the migration touched 297 uipath-troubleshoot tasks, none here). Then a representative subset re-run — smoke, llm_as_judge, recommend_scoped, coded_review_guardrail_misapplied — 4/4 at 1.000.

The full 17 were not re-run on 0.11.2: the first pass took hours (one task 7039s) for 11 lines of additive prose. Single run per task throughout, not --repeats 3.

The two failures are pre-existing on main

Task	Score	Checker
coded-byog-middleware	0.000	UiPathByoGuardrailMiddleware not spread with * into the middleware list
coded-byog-decorator	0.231	no @guardrail(validator=ByoValidator(...)) — ByoValidator never wired

Re-ran both against unmodified main (worktree, identical flags): they fail identically — same scores, same checker messages. Not caused by this change.

Worth a separate look, though: a prior recorded Sonnet regression run in this repo has both at 1.000, so something regressed independently of this PR.

Follow-up worth its own issue

getGuardrailDefinitions (packages/agent-sdk/src/governance.ts, comment: "FeatureDisabled is always dropped") filters FeatureDisabled out of uip agent guardrails list. A flagged-off validator — BYOG and LLM-as-judge today — therefore yields no entry at all, not an entry with a bad status. The coded authoring rule keys on Status != "Available", so it never fires for that case; the low-code twin handles absence explicitly, the coded page has no not-found branch. Separately, getGuardrailCatalog does not filter and GuardrailCatalogEntry.status includes "FeatureDisabled" — yet no skill reads that status. So an agent currently can't tell "flagged off on this tenant" from "misspelled validator name".

🤖 Generated with Claude Code

[github-actions]

Claude finished @apetraru-uipath's task in 1m 28s —— View job

---

PR Review: docs(guardrails) — don't let fetched SDK docs override tenant availability

• Read review criteria and project conventions
• Read full diff
• Read existing PR conversation
• Read each changed file in full for context
• Verify relative links and cross-skill references
• Check for secrets/tokens/personal paths
• Post review findings

---

Summary

Adds a single precedence rule to each of three guardrail reference files (guardrails.md, guardrails-recommend.md, coded-guardrails-review.md) so agents don't treat product-wide Platform Availability notes fetched from the Python SDK docs as a reason to refuse or flag a validator that uip agent guardrails list reports as Available on the current tenant. +11 lines, purely additive, no logic changed.

Change-by-Change Review

1. skills/uipath-agents/references/coded/capabilities/guardrails/guardrails.md (lines 27)

Severity: OK

Two-line blockquote inserted immediately after the "sole source of truth" mandate in Step 0, right where the agent scopes what to take from the fetched pages. Placement is correct — it qualifies the authority established in the preceding paragraph without altering it. The anchor link to #check-tenant-availability-mandatory-for-built-in-ai-validators resolves to the heading at line 40. The closing "author it" is prescriptive and consistent with the repo's agent-facing tone.

2. skills/uipath-agents/references/coded/capabilities/guardrails/guardrails-recommend.md (lines 17–20)

Severity: OK

Five-line blockquote added inside Step 0, between the Validate-mode note and the "Required first operation" instruction. It names the two affected features (BYOG, LLM-as-judge) and directs the agent to uip agent guardrails list as the sole availability authority. Consistent with the existing > Full three-fetch mandate… blockquote style above it. No new links to verify — the added text is self-contained prose.

3. skills/uipath-review/references/agents/guardrails/coded-guardrails-review.md (lines 170–172)

Severity: OK

Four-line paragraph added in the "SDK Docs" subsection of Step 0, directly after the two WebFetch URLs and before the { validator_id → … } lookup paragraph. Correctly scoped to the review skill's concern: "never turn one into a review finding." Reinforces the existing constraint that the fetched pages supply "class, scope, and import names only." No cross-skill references — the text is self-contained within uipath-review.

What's Missing

Nothing identified. The three files are the exact set that instruct agents to WebFetch the SDK guardrail docs and treat them as a source of truth. The added lines are minimal, correctly placed, and additive. No CODEOWNERS change needed (existing paths). No test changes needed (the files are reference docs, not skill entry points, and the PR description confirms 15/17 existing guardrail tasks pass with the two failures pre-existing on main).

Area Ratings

Area	Status	Notes
Frontmatter	OK	No frontmatter changes
E2E Tests	OK	No new capabilities — existing 17 guardrail tasks cover these files; 15/17 pass, 2 fail identically on main
Skill Body	OK	No SKILL.md changes
References & Assets	OK	All three reference edits are correct, well-placed, and self-contained
Repo Hygiene	OK	No secrets, no cross-skill deps, changes scoped to the two affected skills

Issues for Manual Review

None found. The claim that Platform Availability notes are product-wide (not per-tenant) is a domain fact — the PR description cites the upstream PRs (UiPath/uipath-python#1868, UiPath/uipath-langchain-python#1045) that introduced those notes, and the existing uip agent guardrails list machinery already handles per-tenant availability.

Conclusion

Clean PR. The three additions are minimal, correctly placed at the exact points where each file scopes what to take from fetched SDK docs, and consistent with the existing precedence model (uip agent guardrails list as the tenant-availability authority). No issues found — approve.

---