fix(tests): raise guardrail smoke/escalation turn_timeout 300 -> 1200

[mjnovice]

Why

The uipath-agents smoke suite is flaking on turn-timeout kills. In the last two runs on PR #1694:

• July 7: skill-agent-guardrail-coded-escalation-smoke — Turn timeout (300s) fired after 300.0s — hard-killing subprocess
• Today (after branch refresh): skill-agent-guardrail-coded-smoke — same 300s hard-kill

These were the only turn-timeout deaths in the suite, and they map exactly to the only two smoke-suite tasks pinning turn_timeout: 300. A single agent turn that wraps a long pip install / uip invocation legitimately exceeds 5 minutes on CI.

What

Raises turn_timeout from 300 to 1200 in:

• tests/tasks/uipath-agents/coded/guardrails/smoke/smoke.yaml
• tests/tasks/uipath-agents/coded/guardrails/escalation/escalation.yaml

1200 is the suite standard — 99 of 106 turn_timeout pins under tests/tasks/uipath-agents/ already use it, including every sibling guardrail task. Neither task sets task_timeout, so nothing else caps the run sooner.

Three other tasks pin turn_timeout: 300 (deploy_folder_and_rebump, push_pull_roundtrip, maestro-flow routing_listing) but each pairs it with a deliberate short task_timeout (300–600s) and none has failed on turn timeout — left untouched.

🤖 Generated with Claude Code

[github-actions]

Claude finished @mjnovice's task in 1m 20s —— View job

---

Summary

Raises turn_timeout from 300 to 1200 in two guardrail smoke tasks that were flaking on CI due to hard-kills at 300s. The new value aligns with the suite standard (every other guardrail sibling already uses 1200).

Change-by-Change Review

1. tests/tasks/uipath-agents/coded/guardrails/smoke/smoke.yaml

OK — turn_timeout changed from 300 → 1200 at line 52. Consistent with all sibling guardrail tasks. No task_timeout set, so the turn timeout was the only cap — 300s was too tight for CI.

2. tests/tasks/uipath-agents/coded/guardrails/escalation/escalation.yaml

OK — turn_timeout changed from 300 → 1200 at line 87. Same rationale. Consistent with siblings.

What's Missing

Nothing identified. The three remaining turn_timeout: 300 tasks (deploy_folder_and_rebump, push_pull_roundtrip) each pair it with a deliberate task_timeout: 600, confirming they're intentionally short — correctly left untouched. The maestro-flow routing_listing task mentioned in the PR body also has a paired short task_timeout.

Area Ratings

Area	Status	Notes
Frontmatter	N/A	No frontmatter changes
E2E Tests	OK	Only timeout tuning, no behavioral changes
Skill Body	N/A	No skill changes
References & Assets	N/A	No references changed
Repo Hygiene	OK	Scoped change, no secrets, no unrelated edits

Issues for Manual Review

None found.

Conclusion

Clean, well-scoped fix. Both values now match the suite standard. LGTM — approve.

[github-actions]

Claude finished @mjnovice's task in 2m 7s —— View job

---

Coder-eval task lint (advisory)

2 task YAMLs changed; verdict counts: 0 Critical, 1 High, 0 Medium, 0 Low, 2 OK.

Rubric: .claude/commands/lint-task.md. This check is advisory and never blocks merge.

Evidence of passing run

❌ High — PR body does not claim the changed tasks have been run and passed with the new timeout value. The PR documents why the change is needed (300s timeout kills on CI) but doesn't assert the tasks pass at 1200s. Please consider editing the PR description to add a line like:

Ran skill-agent-guardrail-coded-smoke and skill-agent-guardrail-coded-escalation-smoke locally and they passed.

(Given the change is purely a timeout raise, this is largely ceremonial — but the convention asks for it.)

Per-task lint

tests/tasks/uipath-agents/coded/guardrails/smoke/smoke.yaml — verdict: OK

No issues. Change is a single-field bump (turn_timeout: 300 → 1200, line 52). run_limits: is correctly at top level. Success criteria use run_command + file_contains with substantive checks — solid for a smoke task.

tests/tasks/uipath-agents/coded/guardrails/escalation/escalation.yaml — verdict: OK

No issues. Change is a single-field bump (turn_timeout: 300 → 1200, line 87). run_limits: is correctly at top level. Criteria mix run_command (syntax parse, import grep, custom check_escalation.py) with file_contains (app name, recipient) — good coverage for an escalation smoke.

Conclusion

✅ Both changed tasks pass the rubric. Only finding is the missing passing-run claim in the PR body (High, advisory). The change itself — aligning two outlier turn_timeout values to the suite standard of 1200 — is straightforward and well-motivated.

---

[apetraru-uipath]

I will approve this, but it doesn't solve the real problem: failing cli calls (fixed yesterday), LLM not following the skills steps.

I'm working on a more robust fix: #2219