docs(uipath-ixp): note that folder deployment is not supported

[andrei-uipath]

Sets the expectation in the uipath-ixp skill that publishing an IXP model does not deploy it to an Orchestrator folder — that folder/environment binding is a product-side step with no uip ixp (or other CLI) equivalent. There are live cases where a project is created for use in a Flow and an agent then attempts folder deployment as the final step, landing the model locally instead of in the target folder (ACTV-89471).

The note lands at the publish guidance in SKILL.md and in the cli-reference Deployments section. Rather than only telling the agent what it can't do, it directs the correct behavior: publishing is the last step this skill performs, and when the user explicitly asks to deploy, the agent hands the folder/environment binding back to them (done in-product) and never falls back to a local or improvised deployment. (Publishing/tagging via uip ixp stays within the project; deploying to a folder — the product-side step — is what makes a model available to Maestro Flow.)

ACTV-89471: https://uipath.atlassian.net/browse/ACTV-89471

🤖 Generated with Claude Code

https://claude.ai/code/session_0164ykfgunBCrvhrUMHbaGEQ

[github-actions]

Claude finished @andrei-uipath's task in 1m 34s —— View job

---

PR Review: docs(uipath-ixp): note that folder deployment is not supported

• Read review criteria and project conventions
• Read full diff
• Read changed files in full for context
• Check relative links, cross-skill refs, secrets
• Post review

---

Summary

Adds a guardrail note in two places (SKILL.md Task Navigation table and cli-reference.md Deployments section) stating that publishing an IXP model does not deploy it to an Orchestrator folder. Prevents agents from attempting or promising folder deployment after publishing.

Change-by-Change Review

1. skills/uipath-ixp/SKILL.md:73

Severity: OK

The note is appended to the existing "Publish the model" / "Tag as live" row in the Task Navigation table. Placement is correct — this is the first point where an agent encounters the publish action. The bold callout (Publishing does not deploy...) and the explicit "never attempt or promise" directive are appropriately prescriptive for agent consumption.

2. skills/uipath-ixp/references/cli-reference.md:132

Severity: OK

The note is added to the Deployments section header. This is the second entry point where an agent would look at deployment-related commands, so placing the guardrail here catches agents that skip the SKILL.md table and go straight to the CLI reference.

3. Duplication between the two files

Severity: Low (acceptable)

Both files now state that folder deployment is not supported, in slightly different phrasing. Normally per Reference Pointer Discipline this would be a concern, but this is a one-sentence safety guardrail — agents may read either file in isolation, and the cost of missing this note (attempting folder deployment) outweighs the ~30 extra tokens of duplication. No action needed.

What's Missing

Nothing identified. This is a tightly scoped documentation fix addressing a real agent failure mode (ACTV-89471).

Area Ratings

Area	Status	Notes
Frontmatter	OK	No frontmatter changes
E2E Tests	OK	Documentation-only change (guardrail note); no new CLI workflows or commands introduced — existing test coverage is unaffected
Skill Body	OK	Note is well-placed and prescriptive
References & Assets	OK	cli-reference.md change is consistent with SKILL.md
Repo Hygiene	OK	No secrets, no cross-skill refs, changes scoped to uipath-ixp

Issues for Manual Review

None found.

Conclusion

Clean, well-scoped PR. The guardrail note addresses a real agent failure mode and is placed in both strategic locations where an agent encounters publish/deploy actions. No issues found — approve.

---

[richsilv]

I think the agent could do with some instruction that the correct thing to do is tell the user that they need to deploy the model, rather than just that the agent itself can't do so. Otherwise I'm concerned that it will try to find a workaround by using the CLI docs or something.

[richsilv]

I think the wording is a bit ambiguous, partly as a result of our ridiculous historic naming of stuff in IXP.

But today:
Publish - is really only something you do with packages (but we have been using it interchangeably with deployment)
Deploy to project - is the thing that makes the model available to tag, doesn't require publishing a package first, and doesn't make it available to Flow
Deploy to folder - requires a published package (although the package publishing can happen in the same step), and does make it available to Flow

I don't think much needs to change here, apart from the references to publish(ed) in the Deployments section.