uipath-maestro-case

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UiPath Case Management Authoring Assistant

UiPath 案例管理创作助手

Build UiPath Case Management definitions from

sdd.md

. Generate

tasks.md

, then write

caseplan.json

directly using the applicable per-plugin JSON recipes.

Authoring invariant: Never use mutating
uip maestro case
commands (
cases|stages|tasks|*-conditions ... add|update|remove
, including
tasks add-connector
) or explore them with
--help
. Use the CLI only for scaffolding, metadata reads, validation/debug, runtime operations, and solution sync/upload. Consult case-commands.md only when exact syntax is needed. CLI availability or a final
validate
requirement never overrides this rule.

When

sdd.md

is absent, case design belongs exclusively to uipath-planner
, which runs its Case Design Lane in this conversation. This skill never designs independently. The lane uses best-assumption design, Listen → Sketch → full design-time tenant resolution, a mandatory other-path sweep, and one decision-first eight-section Case Review. Its Build answer is consent; it writes template-conformant

sdd.md

, then this skill continues immediately with

uip solution init

, Phase 1, and later phases. The same handoff applies to

sdd.draft.md

finalization. Never overwrite an existing

sdd.md

Scope: greenfield builds from

sdd.md

and brownfield targeted edits to an existing

caseplan.json

; see references/brownfield.md. For Studio Web cases, pull current server state first with

uip solution download

solution projects resync

so publishing cannot clobber server changes.

基于

sdd.md

构建UiPath案例管理定义。生成

tasks.md

，然后使用适用的插件专属JSON规则直接编写

caseplan.json

。

创作不变规则： 切勿使用可修改的
uip maestro case
命令（
cases|stages|tasks|*-conditions ... add|update|remove
，包括
tasks add-connector
），也不要用
--help
探索这些命令。仅将CLI用于脚手架搭建、元数据读取、验证/调试、运行时操作以及解决方案同步/上传。只有在需要精确语法时才查阅case-commands.md。CLI可用性或最终的
validate
要求绝不能凌驾于本规则之上。

当

sdd.md

不存在时，案例设计完全由**

uipath-planner

**负责，它会在本次对话中运行其案例设计流程。本技能绝不会独立进行设计。该流程采用最佳假设设计、Listen → Sketch → 全设计时租户解析、强制的其他路径排查，以及一次以决策为先的八部分案例评审。其构建答复即为同意；它会编写符合模板的

sdd.md

，随后本技能立即继续执行

uip solution init

、第一阶段及后续阶段。同样的交接规则也适用于

sdd.draft.md

的定稿。切勿覆盖已有的

sdd.md

。

适用范围： 基于

sdd.md

的全新构建，以及对现有

caseplan.json

的针对性编辑；详见references/brownfield.md。对于Studio Web案例，需先通过

uip solution download

或

solution projects resync

拉取当前服务器状态，以免发布操作覆盖服务器端的变更。

When to Use This Skill

何时使用本技能

Use for:

Building a Case Management project from
```
sdd.md
```
.
Creating a case when no SDD exists; hand design to
```
uipath-planner
```
in this conversation.
Generating implementation tasks from an SDD.
Editing an existing
```
caseplan.json
```
by targeted intent: stage/task changes, conditions, or triggers.
Questions about case JSON schema, nodes, transitions, tasks, rules, SLA, or runtime case instances.

Do not use for

.xaml

→

uipath-rpa

.flow

→

uipath-maestro-flow

, or standalone agents/APIs/processes outside case context.

适用于以下场景：

基于
```
sdd.md
```
构建案例管理项目。
无SDD时创建案例；在本次对话中将设计工作交接给
```
uipath-planner
```
。
从SDD生成实施任务。
根据目标意图编辑现有
```
caseplan.json
```
：阶段/任务变更、条件或触发器调整。
关于案例JSON schema、节点、流转、任务、规则、SLA或运行时案例实例的问题。

不适用于

.xaml

→

uipath-rpa

、

.flow

→

uipath-maestro-flow

，或案例上下文之外的独立代理/API/流程。

Critical Rules

关键规则

Design handoff and SDD authority. If
```
sdd.md
```
is absent, immediately invoke
```
uipath-planner
```
’s Case Design Lane in this conversation, before reading references or running tenant commands. Do not improvise interviews, design subagents, generic Build Plan approvals, or design-only behavior here. The lane’s single Case Review has exactly these sections: Case Snapshot; Primary Journey; Other Paths Considered; SLA and Escalations; Rules and Outcomes; Resources and Integrations with design-time resolutions; Decisions I Made; Review Flags. It names every stage/task, type, activation/grouping, required status, routing/outcome, and SLA context;
```
sdd.md
```
separately contains the complete data contract, variables, and task inputs/outputs. The Build options incorporate Rule 11, and the Build answer is the sole consent. Corrections re-show only changed review sections. Before approval, every
```
selected-tasks-completed
```
selector must resolve to a non-adhoc sibling in the same stage. The lane writes
```
sdd.md
```
early, then this skill runs
```
uip solution init <SolutionName>
```
and Phase 1 without another prompt unless explicitly requested. If the request asks only for
```
sdd.md
```
plus
```
tasks/tasks.md
```
, write compact
```
tasks/tasks.md
```
after Save/Build, do not read plugin references or run tenant discovery, and stop before
```
caseplan.json
```
. If
```
sdd.draft.md
```
is to be finalized, use the lane fast path with target basename
```
sdd.md
```
. Never overwrite
```
sdd.md
```
.
SDD is the sole post-design input, across sessions. Trust user-provided or previously written
```
sdd.md
```
; do not validate, gap-fill, or silently infer it. In the same conversation as design approval, use the in-memory model that wrote it without rereading. Use AskUserQuestion for build-phase ambiguity. Run a one-Grep receipt spot-check before reading an SDD not watched being written: it must contain
```
## Section 1: Case Definition
```
through
```
## Section 4: Integrations
```
and at least one
```
##### Task
```
block. Freeform/summary SDDs go back through the planner template-conformance gate.
Phase 1 registry gate. Run
```
uip login status --output json
```
, then
```
uip maestro case registry pull
```
, before cache inspection, carryover, resolution, or Phase 1 writes. Pull at most once per session. If the planner lane ran in this session, its pull succeeded, and it wrote the SDD, reuse the cache. With the lane’s in-context resolution outcomes, use verify-only planning: persist them verbatim to
```
tasks/registry-resolved.json
```
, spot-check cache entries, execute gate decisions, and re-resolve only stale/missing entries. Otherwise run the full gate. Login/pull failure stops Phase 1. Read
```
~/.uip/case-resources/<type>-index.json
```
directly;
```
registry search
```
has known gaps, especially action-apps. Before a successful pull, missing cache files are failed refresh preconditions, never zero matches; only after success may empty exact-name matches or absent indexes enter empty-lookup handling. Trust the SDD; the pull refreshes discovery only. The planner lane owns design-time resolution, lazily starting login/pull when tenant-bound work first appears, resolving identities with one batched Case Review gate, and recording SDD cells plus its resolution ledger. No schema discovery occurs there.
Plan-only exception: when explicitly stopping at
```
sdd.md
```
,
```
sdd.draft.md
```
, or
```
tasks.md
```
without
```
caseplan.json
```
, solution, or build, do not run tenant registry, connection, schema, or user-discovery commands. Preserve intended names, mark identities
```
resolve at build
```
, and report deferred wiring. This exception does not apply when the user requests resource/identity resolution, registry refresh, stale-audit replacement,
```
tasks/registry-resolved.json
```
, or
```
tasks/recipients-resolved.json
```
; then run the normal gate, resolve identities, emit build-path
```
tasks.md
```
, and stop at the Rule 7 plan gate.
Parsed reads require
--output json
.
Use plugin references. Read the matching plugin
```
planning.md
```
during planning and
```
impl-json.md
```
during execution; never guess JSON shapes.
tasks.md
is declarative and lossless. No shell commands. Use plain field identifiers, not CLI flags. Create one T-entry for every SDD stage, task, trigger, condition, SLA rule, variable, and argument, including explicit defaults. Preserve every valid explicit rule/selector exactly; reject and repair invalid
```
selected-tasks-completed
```
selectors. Preserve stage/task/SLA
```
Design Rationale
```
and condition routing/activation rationales as
```
rationale:
```
. Preserve every Inputs row, binding mode, and value. Preserve JSON object literals exactly: native object or JSON-encoded string in
```
input.value
```
; add
```
=js:
```
/
```
=jsonString:
```
only when explicitly present in the SDD. Project Outputs through
```
plugins/variables/io-binding/planning.md
```
, preserving operator and operands. SDD output rows require
```
->
```
or
```
=
```
; schema-discovered bare outputs are not authored SDD rows. Never simplify equal-name
```
->
```
rows;
```
greeting -> greeting
```
differs from schema-discovered bare
```
greeting
```
.
```
—
```
placeholders are not operands. AskUserQuestion for unrecognized or ambiguous rows; never omit silently. Regenerate greenfield plans from scratch; brownfield edits preserve IDs. Every §4.6 task entry has its own
```
activation-mode:
```
and
```
entry-rule:
```
— repeat this per task, never author it once and drop it for later similar tasks;
```
validate
```
only warns
```
Task has no entry rules
```
, while a miss hangs
```
case debug
```
indefinitely. Every task heading is exactly
```
## T<n>: Add <type> task "<name>" to "<stage>"
```
. See references/planning.md §4.0 and the Plan-shape gate.
Plan gate. Phase 1 auto-proceeds to Phase 2 and treats the plan as approved. Stop after
```
tasks.md
```
only when the request explicitly says plan-only, Phase 1 only, review first, or not to build. Re-read
```
tasks.md
```
before execution.
Unresolved resources. Never fabricate IDs. Keep
```
<UNRESOLVED: ...>
```
in
```
tasks.md
```
. A placeholder task has
```
type
```
,
```
displayName
```
, structural fields, and
```
data: {}
```
; conditions still reference its TaskId. A placeholder event trigger has render fields and only
```
data.inputs: { serviceType: "Intsvc.EventTrigger" }
```
; append its
```
entry-points.json
```
entry and create no trigger edge. See references/placeholder-tasks.md and references/plugins/triggers/event/impl-json.md.
Resolution audit. Persist one object per task in
```
tasks/registry-resolved.json
```
with exact keys
```
stage
```
,
```
task
```
,
```
taskType
```
,
```
cacheFile
```
,
```
searchQuery
```
,
```
matches
```
,
```
selected
```
, and
```
rationale
```
, plus resolved I/O/review metadata. Add
```
gateDecision
```
only when the user answered the design-time resource gate; default deferrals have none.
```
matches
```
is the complete exact-name set from the refreshed cache;
```
selected
```
is a match or
```
null
```
after a genuine empty lookup. Same-session planner ledgers are persisted verbatim, then verified/extended under Rule 3. The resolution ledger and
```
registry-resolved.json
```
are machine-only — never shown to the user, including in the Case Review.
Cross-task references. Use
```
"Stage Name"."Task Name".output_name
```
and the common output-reference-ID algorithm in
```
plugins/variables/io-binding/impl-json.md
```
. Use the source output’s
```
.id
```
; only a custom
```
=
```
output without
```
.id
```
uses its verified root companion’s
```
.id
```
. Never use a reassigned output’s
```
.var
```
. Discover names with
```
uip maestro case spec
```
for connector tasks or
```
uip maestro case tasks describe
```
for non-connectors. In larger
```
=js:
```
expressions use
```
vars.$xref('Stage','Task','output')
```
, resolved at Step 11.5. See references/bindings-and-expressions.md.
Build-review preference. Capture once at journey start. Design handoff folds it into the Case Review Build options (
```
Build it — straight through
```
or
```
Build it — pause at the build preview
```
); provided SDD asks once after the roadmap. Non-interactive and resumed runs without a preference default to straight-through. At Phase 2→3, try
```
validate --skeleton-v2
```
; fall back once to legacy
```
--skeleton
```
only when the response explicitly says v2 is unknown/unsupported, typically invalid_argument/exit 3. Exit 3 alone is insufficient; real v2 failures are reported. Validation findings do not halt this advisory gate. Straight-through continues without prompting. Pause-at-preview follows references/phased-execution.md: AskUserQuestion
```
Publish for review
```
/
```
Skip publish and continue
```
/
```
Abort
```
; on publish, refresh resources, upload with the required filter, print
```
DesignerUrl
```
before the follow-up, then ask
```
Continue to implementation
```
/
```
Abort
```
. Hard stops always remain at Phase 4 retry exhaustion, Phase 5, Phase 6, and Phase 7.
Never auto-debug or publish to Orchestrator.
```
uip maestro case debug
```
executes real emails, messages, and API calls. Phase 7 (
```
case pack
```
→
```
solution pack
```
→
```
solution publish
```
) ships to the tenant. Each requires its own AskUserQuestion consent.
Artifact I/O. For
```
caseplan.json
```
,
```
sdd.md
```
,
```
sdd.draft.md
```
,
```
tasks.md
```
,
```
tasks/registry-resolved.json
```
,
```
tasks/trigger-spec-cache.json
```
,
```
tasks/spec-cache.<elementId>.json
```
,
```
bindings_v2.json
```
,
```
id-map.json
```
,
```
entry-points.json
```
, and
```
build-issues.md
```
, use only Read and Write/Edit. No Python, Node, jq, sed, awk, scripts, shell redirection,
```
tee
```
,
```
cp
```
,
```
mv
```
,
```
install
```
, or
```
rsync
```
; no helper scripts, including under
```
/tmp
```
. The
```
node -e ... fs.*
```
ban covers all file reads, including
```
~/.uip/case-resources/
```
; use Read or
```
cat ... | python3 -c ...
```
for cache lookup. If
```
caseplan.json
```
exceeds about 30KB, use the preview/detail cadence in case-editing-operations.md, never a helper. Bash is allowed only for UUID v4 generation without filesystem access, CLI metadata, validate, debug, and solution scaffold/upload. Prefixed IDs are chosen inline.
Runnable resources and sidecars. Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null
```
selected
```
resource must not become a placeholder: retain
```
data.name
```
and
```
data.folderPath
```
with complete root bindings, project it into
```
bindings_v2.json.resources[]
```
, and make its
```
resourceKey
```
self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and
```
wait-for-connector
```
rules, which require spliced
```
caseShape.context
```
plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate is insufficient. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every
```
resources refresh
```
. Refresh before every upload or debug. Every upload uses
```
--output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"
```
; print the returned DesignerUrl.
Handoff contract. Invoke
```
uipath-planner
```
’s Case Design Lane in this conversation, never as a subagent. It owns design, resolution, review, and SDD writing; this skill resumes at solution initialization. User-facing language presents one continuous flow and never mentions the handoff. If unavailable, say so in one line, request
```
sdd.md
```
or an approved pasted design, and stop. Cross-product planning remains a plain-text suggestion to the planner. Apply the Rule 15 receipt spot-check before unobserved SDD reads.
Closed task types.
```
caseplan.json
```
task
```
type
```
must be exactly one of:
```
process
```
,
```
agent
```
,
```
rpa
```
,
```
action
```
,
```
api-workflow
```
,
```
case-management
```
,
```
execute-connector-activity
```
,
```
wait-for-connector
```
,
```
wait-for-timer
```
. Never use plugin folder or CLI names,
```
external-agent
```
,
```
external-workflow
```
,
```
document-extraction
```
,
```
flow-process
```
,
```
wait-for-event
```
, or other invented values. The unsupported types remain unsupported. See references/case-schema.md and the Plugin Index.
Empty lookup gate. If the same-session ledger has a user
```
gateDecision
```
, execute it without asking again:
```
resolve-at-build
```
→ placeholder;
```
create-during-build
```
→ inline create;
```
pick:<name>
```
→ bind it. A missing decision is a default deferral, not consent; run the full gate. For zero matches, use one batched AskUserQuestion grouped by
```
(name,type)
```
with:
```
Force pull and re-resolve
```
;
```
Use placeholders for all
```
; and, only when creatable resources exist and
```
registry --local
```
is supported,
```
Create missing resources inline
```
. Create only selected
```
agent
```
or
```
api-workflow
```
resources, invoking
```
uipath-agents
```
or
```
uipath-api-workflow
```
; never infer Create from SDD content. Other empty types remain placeholder-only. Selected resources with identical I/O may share one build; differing I/O splits later with the anchor retaining the name, and SDD updates require permission. See registry-discovery.md § 1c, Create-on-Missing, and § MUST Confirm.
Layout. Emit top-level
```
layout: {}
```
only. Do not emit node
```
position
```
,
```
style
```
,
```
measured
```
,
```
width
```
,
```
height
```
,
```
zIndex
```
, or edge
```
data.waypoints
```
; do not compute positions.
Global output IDs. Run Step 12 Check 8 once at Phase 3 exit. It is mandatory; do not enter Phase 4 until it passes and do not substitute CLI validate.
No authored edges. Keep
```
schema.edges
```
as
```
[]
```
; never author TriggerEdge/Edge objects. Conditions provide stage flow; the first stage uses
```
case-entered
```
. Read-only edge shapes are documented in case-schema.md Appendix.
Global events and SLA responses. Model a global external event once as an interrupting secondary-stage
```
wait-for-connector
```
entry. Choose SLA response explicitly:
```
notify-only
```
,
```
start-task
```
,
```
enter-stage
```
,
```
exit-stage
```
, or
```
exit-case
```
. A
```
start-task
```
response belongs on the follow-up task’s own
```
sla-status-change
```
entry, not a stage entry. Interrupting depends on whether active work stops, pauses, or reroutes; parallel oversight uses
```
Interrupting: No
```
and remains secondary.
```
sla-status-change
```
names
```
slaId
```
; add
```
escalationId
```
only for at-risk responses. Without a stated response, at-risk and breach are notifications. Do not replicate rules across primary stages. See references/sla-response-shapes.md and the SLA Response Map.
Formal argument IDs.
```
variables.inputs[].id
```
and
```
variables.outputs[].id
```
must be synthetic
```
v
```
+ 8 characters and distinct from
```
name
```
/
```
var
```
; never copy companion names. Run Step 12 Check 10 once at Phase 3 exit and non-interactively re-mint violations. CLI validate does not check this. See global-vars/impl-json.md § Formal-arg slot ID format.
Never run
uip maestro case init
. It may create a second solution and separate manifest. Use
```
uip solution init <SolutionName>
```
and the T01 direct-JSON scaffold in implementation.md § Step 6. See case-commands.md § case init.
Read references to EOF before mutation. Every
```
references/*.md
```
ends with
```

```
. Before the first Write/Edit using a shape, procedure, constraint, or verification rule, Read that exact reference until its exact END marker appears in tool output during this session. Ranges, truncation, search hits, tables of contents, memory, and sibling references do not satisfy this. Reopen after compaction or when the prior read is unavailable. Keep reads modest to avoid output truncation. Tail contracts are normative.
Unique labels and task names. Stage
```
data.label
```
values are unique case-wide; task
```
displayName
```
values are unique across all stages, exact and untrimmed, and contain no
```
:
```
. A missing display name binds to the resource name and participates in uniqueness. Assign names in Phase 1; later renaming touches the SDD, plan, ID map, and name-keyed references.

设计交接与SDD权威性：如果
```
sdd.md
```
不存在，在查阅参考文档或运行租户命令前，立即在本次对话中调用
```
uipath-planner
```
的案例设计流程。切勿自行设计访谈、创建设计子代理、进行通用构建计划审批或仅开展设计相关操作。该流程的单次案例评审包含以下固定部分：案例快照；主流程；考虑过的其他路径；SLA与升级机制；规则与结果；资源与集成（含设计时解析）；我做出的决策；评审标记。它会明确每个阶段/任务的名称、类型、激活/分组方式、必填状态、路由/结果以及SLA上下文；
```
sdd.md
```
则单独包含完整的数据契约、变量和任务输入/输出。构建选项需纳入规则11，构建答复即为唯一同意。修改仅需重新展示变更的评审部分。在审批前，每个
```
selected-tasks-completed
```
选择器必须解析为同一阶段中的非临时同级任务。该流程会提前编写
```
sdd.md
```
，随后本技能无需额外提示（除非明确要求）即可运行
```
uip solution init <SolutionName>
```
和第一阶段。如果请求仅要求
```
sdd.md
```
加
```
tasks/tasks.md
```
，则在保存/构建后编写简洁的
```
tasks/tasks.md
```
，无需查阅插件参考文档或运行租户发现命令，并在生成
```
caseplan.json
```
前停止操作。如需定稿
```
sdd.draft.md
```
，请使用该流程的快速路径，目标基准名为
```
sdd.md
```
。切勿覆盖
```
sdd.md
```
。
SDD是设计后的唯一输入（跨会话）：信任用户提供或已编写的
```
sdd.md
```
；切勿验证、填补空白或静默推断。在设计审批的同一会话中，使用编写该文件时的内存模型，无需重新读取。构建阶段若有歧义，请使用AskUserQuestion。在读取未亲眼见证编写过程的SDD前，先进行一次Grep抽查：它必须包含
```
## Section 1: Case Definition
```
至
```
## Section 4: Integrations
```
的内容，以及至少一个
```
##### Task
```
块。自由格式/摘要式SDD需重新通过规划器的模板一致性校验。
第一阶段注册表校验：在检查缓存、延续操作、解析或第一阶段写入前，先运行
```
uip login status --output json
```
，再运行
```
uip maestro case registry pull
```
。每个会话最多执行一次拉取。如果本次会话中已运行规划器流程，且拉取成功并已编写SDD，则复用缓存。结合流程的上下文解析结果，仅进行验证式规划：将结果原封不动地保存到
```
tasks/registry-resolved.json
```
，抽查缓存条目，执行校验决策，仅重新解析过期/缺失的条目。否则运行完整的校验流程。登录/拉取失败将终止第一阶段。直接读取
```
~/.uip/case-resources/<type>-index.json
```
；
```
registry search
```
存在已知缺陷，尤其是针对动作应用。在成功拉取前，缺失的缓存文件是刷新失败的前提条件，而非零匹配；仅在拉取成功后，空的精确名称匹配或缺失的索引才进入空查找处理逻辑。信任SDD；拉取仅用于刷新发现结果。规划器流程负责设计时解析，当首次出现租户相关工作时才延迟启动登录/拉取，通过一次批量案例评审校验解析身份，并记录SDD单元格及其解析台账。该流程不进行schema发现。
仅规划例外： 当明确要求仅生成
```
sdd.md
```
、
```
sdd.draft.md
```
或
```
tasks.md
```
，无需
```
caseplan.json
```
、解决方案或构建时，请勿运行租户注册表、连接、schema或用户发现命令。保留预期名称，标记身份为
```
resolve at build
```
，并报告延迟的连接配置。当用户请求资源/身份解析、注册表刷新、过期审计替换、
```
tasks/registry-resolved.json
```
或
```
tasks/recipients-resolved.json
```
时，本例外不适用；此时需运行正常的校验流程，解析身份，生成构建路径的
```
tasks.md
```
，并在规则7的规划校验处停止。
解析读取需使用
--output json
。
使用插件参考文档：规划阶段查阅匹配的插件
```
planning.md
```
，执行阶段查阅
```
impl-json.md
```
；切勿猜测JSON结构。
tasks.md
需具备声明性且无信息丢失：不包含Shell命令。使用纯字段标识符，而非CLI标志。为SDD中的每个阶段、任务、触发器、条件、SLA规则、变量和参数创建一个T条目，包括显式默认值。精确保留所有有效的显式规则/选择器；拒绝并修复无效的
```
selected-tasks-completed
```
选择器。保留阶段/任务/SLA的
```
Design Rationale
```
以及条件路由/激活理由，格式为
```
rationale:
```
。保留所有Inputs行、绑定模式和值。精确保留JSON对象字面量：
```
input.value
```
中使用原生对象或JSON编码字符串；仅当SDD中明确存在时才添加
```
=js:
```
/
```
=jsonString:
```
。按照plugins/variables/io-binding/planning.md映射Project Outputs，保留运算符和操作数。SDD输出行需包含
```
->
```
或
```
=
```
；通过schema发现的裸输出不属于已创作的SDD行。切勿简化同名的
```
->
```
行；
```
greeting -> greeting
```
与通过schema发现的裸
```
greeting
```
不同。
```
—
```
占位符不属于操作数。对于无法识别或有歧义的行，请使用AskUserQuestion；切勿静默省略。全新规划需从头生成；已有系统编辑需保留ID。每个§4.6任务条目都有自己的
```
activation-mode:
```
和
```
entry-rule:
```
— 每个任务重复设置，切勿仅设置一次并在后续类似任务中省略；
```
validate
```
仅会警告
```
Task has no entry rules
```
，而遗漏该设置会导致
```
case debug
```
无限挂起。每个任务标题必须严格为
```
## T<n>: Add <type> task "<name>" to "<stage>"
```
。详见references/planning.md §4.0和Plan-shape gate。
规划校验：第一阶段自动进入第二阶段，并视为规划已获批准。仅当请求明确要求仅做规划、仅执行第一阶段、先评审或不进行构建时，才在生成
```
tasks.md
```
后停止。执行前需重新读取
```
tasks.md
```
。
未解析资源：切勿编造ID。在
```
tasks.md
```
中保留
```
<UNRESOLVED: ...>
```
。占位符任务需包含
```
type
```
、
```
displayName
```
、结构字段和
```
data: {}
```
；条件仍需引用其TaskId。占位符事件触发器需包含渲染字段和仅有的
```
data.inputs: { serviceType: "Intsvc.EventTrigger" }
```
；添加其
```
entry-points.json
```
条目，且不创建触发器边。详见references/placeholder-tasks.md和references/plugins/triggers/event/impl-json.md。
解析审计：在
```
tasks/registry-resolved.json
```
中为每个任务保存一个对象，包含精确的键
```
stage
```
、
```
task
```
、
```
taskType
```
、
```
cacheFile
```
、
```
searchQuery
```
、
```
matches
```
、
```
selected
```
和
```
rationale
```
，以及已解析的I/O/评审元数据。仅当用户答复了设计时资源校验时才添加
```
gateDecision
```
；默认延迟处理则不添加。
```
matches
```
是刷新后缓存中的完整精确名称集合；
```
selected
```
是匹配结果，或在真正空查找后为
```
null
```
。同一会话中的规划器台账需原封不动地保存，然后根据规则3进行验证/扩展。解析台账和
```
registry-resolved.json
```
仅用于机器处理 — 切勿展示给用户，包括在案例评审中。
跨任务引用：使用
```
"Stage Name"."Task Name".output_name
```
以及plugins/variables/io-binding/impl-json.md中的通用输出引用ID算法。使用源输出的
```
.id
```
；仅当自定义
```
=
```
输出无
```
.id
```
时，才使用其已验证的根伴生对象的
```
.id
```
。切勿使用重新分配的输出的
```
.var
```
。对于连接器任务，通过
```
uip maestro case spec
```
发现名称；对于非连接器任务，通过
```
uip maestro case tasks describe
```
发现名称。在较大的
```
=js:
```
表达式中使用
```
vars.$xref('Stage','Task','output')
```
，在步骤11.5中解析。详见references/bindings-and-expressions.md。
构建评审偏好：在流程开始时捕获一次。设计交接会将其纳入案例评审的构建选项（
```
Build it — straight through
```
或
```
Build it — pause at the build preview
```
）；若提供了SDD，则在路线图后询问一次。非交互式和无偏好的恢复运行默认采用直通模式。在第二阶段→第三阶段时，尝试
```
validate --skeleton-v2
```
；仅当响应明确表示v2未知/不支持（通常为invalid_argument/exit 3）时，才回退一次使用旧版
```
--skeleton
```
。仅exit 3不足以触发回退；真正的v2失败会有明确报告。验证结果不会终止该咨询性校验。直通模式将继续执行，无需提示。暂停预览模式需遵循references/phased-execution.md：使用AskUserQuestion询问
```
Publish for review
```
/
```
Skip publish and continue
```
/
```
Abort
```
；若选择发布，则刷新资源，使用必填过滤器上传，在后续操作前打印
```
DesignerUrl
```
，然后询问
```
Continue to implementation
```
/
```
Abort
```
。硬停止始终发生在第四阶段重试耗尽、第五阶段、第六阶段和第七阶段。
切勿自动调试或发布到Orchestrator：
```
uip maestro case debug
```
会执行真实的邮件、消息和API调用。第七阶段（
```
case pack
```
→
```
solution pack
```
→
```
solution publish
```
）会部署到租户。每个操作都需要单独的AskUserQuestion同意。
工件I/O：对于
```
caseplan.json
```
、
```
sdd.md
```
、
```
sdd.draft.md
```
、
```
tasks.md
```
、
```
tasks/registry-resolved.json
```
、
```
tasks/trigger-spec-cache.json
```
、
```
tasks/spec-cache.<elementId>.json
```
、
```
bindings_v2.json
```
、
```
id-map.json
```
、
```
entry-points.json
```
和
```
build-issues.md
```
，仅使用Read和Write/Edit操作。禁止使用Python、Node、jq、sed、awk、脚本、Shell重定向、
```
tee
```
、
```
cp
```
、
```
mv
```
、
```
install
```
或
```
rsync
```
；禁止使用辅助脚本，包括
```
/tmp
```
下的脚本。
```
node -e ... fs.*
```
禁令涵盖所有文件读取，包括
```
~/.uip/case-resources/
```
；缓存查找请使用Read或
```
cat ... | python3 -c ...
```
。如果
```
caseplan.json
```
大小超过约30KB，请遵循case-editing-operations.md中的预览/详细流程，切勿使用辅助工具。仅允许Bash用于无文件系统访问的UUID v4生成、CLI元数据操作、验证、调试以及解决方案脚手架搭建/上传。前缀ID需内联选择。
可运行资源与辅助文件：在第四阶段前，即使跳过发布、调试或资源刷新，也要运行步骤12中的检查7、9、11和12。非空的
```
selected
```
资源绝不能变为占位符：保留
```
data.name
```
和
```
data.folderPath
```
以及完整的根绑定，将其映射到
```
bindings_v2.json.resources[]
```
，并确保其
```
resourceKey
```
与自身默认值一致，切勿复制租户身份/UUID。检查9/11豁免连接器节点；检查12涵盖已解析的连接器任务、事件触发器和
```
wait-for-connector
```
规则，这些需要拼接
```
caseShape.context
```
以及Connection/Folder根绑定，而非简化的typeId/connectionId-only数据。CLI验证不足以覆盖这些检查。修复并重新检查不匹配项；若问题仍存在，则在进入第四阶段前停止。每次
```
resources refresh
```
前重复检查7。每次上传或调试前刷新资源。每次上传需使用
```
--output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"
```
；打印返回的DesignerUrl。
交接契约：在本次对话中调用
```
uipath-planner
```
的案例设计流程，切勿作为子代理调用。它负责设计、解析、评审和SDD编写；本技能在解决方案初始化后继续执行。面向用户的语言需呈现为一个连续流程，切勿提及交接。若该流程不可用，请用一句话说明，请求提供
```
sdd.md
```
或已批准的粘贴设计，然后停止操作。跨产品规划仅作为纯文本建议提交给规划器。在读取未观察编写过程的SDD前，需执行规则15的抽查。
封闭任务类型：
```
caseplan.json
```
中的任务
```
type
```
必须严格为以下类型之一：
```
process
```
、
```
agent
```
、
```
rpa
```
、
```
action
```
、
```
api-workflow
```
、
```
case-management
```
、
```
execute-connector-activity
```
、
```
wait-for-connector
```
、
```
wait-for-timer
```
。切勿使用插件文件夹或CLI名称、
```
external-agent
```
、
```
external-workflow
```
、
```
document-extraction
```
、
```
flow-process
```
、
```
wait-for-event
```
或其他自创值。不支持的类型仍保持不可用状态。详见references/case-schema.md和插件索引。
空查找校验：如果同一会话台账中有用户的
```
gateDecision
```
，则直接执行，无需再次询问：
```
resolve-at-build
```
→ 占位符；
```
create-during-build
```
→ 内联创建；
```
pick:<name>
```
→ 绑定。若缺少决策，则默认延迟处理，而非同意；需运行完整的校验流程。对于零匹配结果，按
```
(name,type)
```
分组使用一次批量AskUserQuestion，选项包括：
```
Force pull and re-resolve
```
；
```
Use placeholders for all
```
；以及仅当存在可创建资源且支持
```
registry --local
```
时，
```
Create missing resources inline
```
。仅创建选中的
```
agent
```
或
```
api-workflow
```
资源，调用
```
uipath-agents
```
或
```
uipath-api-workflow
```
；切勿从SDD内容推断创建操作。其他空类型仅使用占位符。具有相同I/O的选中资源可共享一次构建；I/O不同则后续拆分，锚点保留名称，SDD更新需获得许可。详见registry-discovery.md § 1c、Create-on-Missing和§ MUST Confirm。
布局：仅输出顶层
```
layout: {}
```
。切勿输出节点的
```
position
```
、
```
style
```
、
```
measured
```
、
```
width
```
、
```
height
```
、
```
zIndex
```
，或边的
```
data.waypoints
```
；切勿计算位置。
全局输出ID：在第三阶段结束时运行一次步骤12中的检查8。此检查为必填项；未通过前不得进入第四阶段，且不得用CLI验证替代。
禁止创作边：保持
```
schema.edges
```
为
```
[]
```
；切勿创作TriggerEdge/Edge对象。条件控制阶段流转；第一个阶段使用
```
case-entered
```
。只读边的结构记录在case-schema.md Appendix中。
全局事件与SLA响应：将全局外部事件建模为中断性次级阶段的
```
wait-for-connector
```
条目。明确选择SLA响应：
```
notify-only
```
、
```
start-task
```
、
```
enter-stage
```
、
```
exit-stage
```
或
```
exit-case
```
。
```
start-task
```
响应需放在后续任务自身的
```
sla-status-change
```
条目上，而非阶段条目。是否中断取决于活动工作是否停止、暂停或重新路由；并行监控使用
```
Interrupting: No
```
并保持为次级阶段。
```
sla-status-change
```
需指定
```
slaId
```
；仅针对风险响应添加
```
escalationId
```
。若无明确响应，风险和违约事件默认仅发送通知。切勿在主阶段间复制规则。详见references/sla-response-shapes.md和SLA响应映射表。
正式参数ID：
```
variables.inputs[].id
```
和
```
variables.outputs[].id
```
必须为
```
synthetic v
```
+ 8个字符，且与
```
name
```
/
```
var
```
不同；切勿复制伴生名称。在第三阶段结束时运行一次步骤12中的检查10，并以非交互方式重新生成违规ID。CLI验证不会检查此项。详见global-vars/impl-json.md § Formal-arg slot ID format。
切勿运行
uip maestro case init
：它可能会创建第二个解决方案和单独的清单。请使用
```
uip solution init <SolutionName>
```
以及implementation.md § Step 6中的T01直接JSON脚手架。详见case-commands.md § case init。
读取参考文档至EOF后再进行修改：每个
```
references/*.md
```
都以
```

```
结尾。在首次使用某结构、流程、约束或验证规则进行Write/Edit操作前，需在本次会话中读取对应的参考文档，直到工具输出中出现其精确的END标记。范围读取、截断、搜索结果、目录、记忆或同类参考文档均不满足要求。在压缩后或之前的读取不可用时，需重新打开文档。控制读取内容的大小，避免输出截断。尾部契约为规范性内容。
唯一标签与任务名称：阶段的
```
data.label
```
值在案例范围内必须唯一；任务的
```
displayName
```
值在所有阶段中必须唯一，精确且未修剪，且不含
```
:
```
。若缺少显示名称，则绑定到资源名称并参与唯一性检查。在第一阶段分配名称；后续重命名需修改SDD、规划、ID映射和按名称键的引用。

Routing

路由规则

Condition	Journey
New case, SDD provided, no caseplan, or rebuild from spec	Greenfield: handoff if needed, then Phases 1–7
Existing caseplan and targeted edit intent	Brownfield: skip handoff and Phases 1–7; use brownfield.md

Brownfield still requires latest-state pull, debug consent, and Orchestrator-publish consent, and reuses Phase 5–7 contracts.

条件	流程
新案例，提供SDD，无caseplan，或根据规范重建	全新构建：必要时进行交接，然后执行第一至第七阶段
已有caseplan且有针对性编辑意图	已有系统编辑：跳过交接和第一至第七阶段；使用brownfield.md

已有系统编辑仍需拉取最新状态、调试同意和Orchestrator发布同意，并复用第五至第七阶段的契约。

User-Facing Roadmap

面向用户的路线图

Print once, after routing and before detailed work, in five lines or fewer. Do not expose phases, modes, filenames, or implementation mechanics.

New case without SDD:

1. I read your request and make the design calls, checking your UiPath tenant along the way. 2. One review packet: case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision I made — you confirm or correct. 3. Build and validate without interruptions; the full technical design doc is saved alongside for reference. 4. Pause for your call before any run or publish.

New case with SDD:

1. Read the design and verify available UiPath resources. 2. One question: build straight through, or pause at a mid-build preview. 3. Plan, build, and validate without further interruptions. 4. Pause for your call before any run or publish.

Targeted edit:

1. Pull the latest case. 2. Apply the requested change. 3. Validate the updated case. 4. Ask before running or publishing anything.

在路由后、详细工作前打印一次，控制在五行以内。切勿暴露阶段、模式、文件名或实现机制。

无SDD的新案例：

1. 我会读取您的需求并做出设计决策，同时检查您的UiPath租户。2. 提供一份评审包：案例快照、主流程、其他路径、SLA响应、业务规则、资源以及我做出的所有决策 — 您可确认或修改。3. 无中断地构建并验证；完整的技术设计文档会一并保存供参考。4. 在任何运行或发布前暂停，等待您的指示。

有SDD的新案例：

1. 读取设计并验证可用的UiPath资源。2. 询问一次：直接构建到底，还是在构建中途预览时暂停。3. 无中断地规划、构建并验证。4. 在任何运行或发布前暂停，等待您的指示。

针对性编辑：

1. 拉取最新案例。2. 应用您请求的变更。3. 验证更新后的案例。4. 在运行或发布任何内容前询问您的意见。

Workflow

工作流程

Front-load decisions, then run unattended to consent gates:

Design handoff when required → Phase 1 Planning → Phase 2 Prototyping → Phase 3 Implementation → Phase 4 Validate → Phase 5 Publish → Phase 6 Debug → Phase 7 Publish to Orchestrator.

At invocation start, present once the matching kickoff block below, at handoff start or Phase 1 start. Status text must follow the Anti-patterns limits.

Greenfield kickoff:

Here's how I'll build this case, and where I'll stop for your call:

Planning — I draft a task plan from the spec and continue; ask up front if you want to review it first.

Prototyping — I build the reviewable case flow (stages, tasks, triggers, rules, SLA/escalation; connector rules use stubs). Whether I pause here for a Studio Web preview is your up-front call — asked once at the start, never mid-build.

Implementation — I wire task inputs/outputs, connector schemas, and resolved connector-rule details.

Validate — I run validation and fix errors.

Publish (optional) — you choose whether to upload to Studio Web.

Debug (optional) — you choose whether to run the case for real (live emails / API calls).

Publish to Orchestrator (optional) — you choose whether to publish the case to Orchestrator.

For handoff, prefix:

First I'll design the case from what you've given me — checking your UiPath tenant along the way — and show one decision-first review packet with the case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision made — one confirmation, then I build; the full technical design doc (sdd.md) is saved alongside for reference.

For brownfield, use the short entry flow in references/brownfield.md.

提前完成决策，然后在无人工干预的情况下运行至同意校验点：

必要时进行设计交接 → 第一阶段规划 → 第二阶段原型制作 → 第三阶段实施 → 第四阶段验证 → 第五阶段发布 → 第六阶段调试 → 第七阶段发布到Orchestrator。

在调用开始时，在交接开始或第一阶段开始时，展示一次匹配的启动块。状态文本必须遵循反模式限制。

全新构建启动块：

以下是我构建此案例的流程，以及我会暂停等待您指示的节点：

规划 — 我会根据规范起草任务计划并继续；若您希望先评审计划，请提前告知。

原型制作 — 我会构建可评审的案例流程（阶段、任务、触发器、规则、SLA/升级机制；连接器规则使用存根）。是否在此处暂停以进行Studio Web预览由您提前决定 — 仅在开始时询问一次，构建中途不再询问。

实施 — 我会绑定任务输入/输出、连接器schema以及已解析的连接器规则细节。

验证 — 我会运行验证并修复错误。

发布（可选） — 由您选择是否上传到Studio Web。

调试（可选） — 由您选择是否实际运行案例（发送真实邮件/调用API）。

发布到Orchestrator（可选） — 由您选择是否将案例发布到Orchestrator。

对于交接场景，添加前缀：

首先我会根据您提供的信息设计案例 — 同时检查您的UiPath租户 — 并展示一份以决策为先的评审包，包含案例快照、主流程、其他路径、SLA响应、业务规则、资源以及我做出的所有决策 — 您确认后我再进行构建；完整的技术设计文档（sdd.md）会一并保存供参考。

对于已有系统编辑，请使用brownfield.md中的简短进入流程。

Design handoff

设计交接

The trigger is binary: if no

.md

whose basename contains

sdd

exists at the resolved path, hand off. If the prompt names another SDD basename, copy it to

./sdd.md

using Read + Write; do not invoke the lane. If no

.md

is named, use

./sdd.md

. Do not read planning/plugin references or run tenant commands before the Case Review. For an explicit no-build design+plan request, write

sdd.md

and compact

tasks/tasks.md

after approval, without plugin references, schema, registry, connection, or user discovery, then stop. Planner-owned drafts and

sdd-viewer.html

stay with the planner. If unavailable, request an SDD and stop.

触发条件为二元判断：若解析路径下不存在basename包含

sdd

的

.md

文件，则进行交接。若提示中指定了其他SDD基准名，请通过Read + Write操作将其复制到

./sdd.md

；切勿调用该流程。若未指定

.md

文件名，则使用

./sdd.md

。在案例评审前，切勿查阅规划/插件参考文档或运行租户命令。对于明确要求仅进行设计+规划而不构建的请求，在审批后编写

sdd.md

和简洁的

tasks/tasks.md

，无需查阅插件参考文档、schema、注册表、连接或用户发现，然后停止操作。规划器生成的草稿和

sdd-viewer.html

由规划器保留。若该流程不可用，请请求提供SDD并停止操作。

Phase 1 — Planning

第一阶段 — 规划

Read references/planning.md to produce:

```
tasks/tasks.md
```
: T-numbered stages, tasks, conditions, SLA, variables, and arguments.
```
tasks/registry-resolved.json
```
: complete resolution audit.
If Create is selected at Rule 17: build selected agents/API workflows as in-solution siblings through the permitted sub-agent paths, ensure a solution exists, register them, refresh resources, rediscover, and bind them. See registry-discovery.md § Create-on-Missing.

tasks/

is adjacent to

sdd.md

, never inside the solution/project. Auto-proceed to Phase 2 unless the request explicitly asks to stop for plan review. Re-read

tasks.md

first.

查阅references/planning.md以生成：

```
tasks/tasks.md
```
：带T编号的阶段、任务、条件、SLA、变量和参数。
```
tasks/registry-resolved.json
```
：完整的解析审计记录。
若规则17中选择了Create：通过允许的子代理路径在解决方案内构建选中的代理/API工作流作为同级项目，确保解决方案已存在，注册它们，刷新资源，重新发现并绑定。详见registry-discovery.md § Create-on-Missing。

tasks/

与

sdd.md

同级，切勿放在解决方案/项目内部。除非请求明确要求停止以进行计划评审，否则自动进入第二阶段。首先重新读取

tasks.md

。

Phase 2 — Prototyping

第二阶段 — 原型制作

Read references/implementation.md and references/phased-execution.md. Follow Steps 6–11.9:

Step 6:
```
uip solution init
```
, project, and root case (T01 direct-JSON recipe in plugins/case/impl-json.md); never
```
case init
```
.
Step 6.1: manual, timer, and event triggers, including Rule 8 placeholders; capture trigger IDs.
Step 6.2: global variables and arguments; In-argument
```
elementId
```
references the trigger named by
```
sourceTriggers
```
, or the primary trigger when blank.
Step 6.3: synchronize
```
entry-points.json
```
from declared In/Out arguments per entry-points-sync.md. Emit the
```
job-attachment
```
```
definitions
```
block byte-for-byte from that reference — reproduce its
```
MimeType.description
```
inner quotes exactly (single-
```
\"
```
escaping); never re-escape (
```
\\"
```
) or rebalance them, or the JSON breaks.
Step 7: stages.
Step 9: task shapes; non-connectors get complete
```
data.inputs[]
```
with empty values, connectors only
```
typeId
```
/
```
connectionId
```
, unresolved resources use placeholders.
Step 11: SLA/escalation objects with stable IDs.
Step 10: all four condition scopes; connector waits use canonical stubs regardless of resolution.
Step 11.9: informational skeleton validation with Rule 11 fallback behavior.
Apply the Phase 2→3 preference. Preview branch uses resource refresh, filtered solution upload, printed DesignerUrl, and the prescribed continuation gate; Abort writes
```
build-issues.md
```
and exits.

查阅references/implementation.md和references/phased-execution.md。遵循步骤6–11.9：

步骤6：
```
uip solution init
```
、项目和根案例（使用plugins/case/impl-json.md中的T01直接JSON规则）；切勿使用
```
case init
```
。
步骤6.1：手动、计时器和事件触发器，包括规则8中的占位符；捕获触发器ID。
步骤6.2：全局变量和参数；In参数的
```
elementId
```
引用
```
sourceTriggers
```
指定的触发器，若为空则引用主触发器。
步骤6.3：根据entry-points-sync.md同步
```
entry-points.json
```
与声明的In/Out参数。从该参考文档中逐字节输出
```
job-attachment
```
的
```
definitions
```
块 — 精确复制其
```
MimeType.description
```
的内部引号（单
```
\"
```
转义）；切勿重新转义（
```
\\"
```
）或调整引号，否则JSON会损坏。
步骤7：阶段。
步骤9：任务形状；非连接器任务需包含完整的
```
data.inputs[]
```
（值为空），连接器任务仅包含
```
typeId
```
/
```
connectionId
```
，未解析资源使用占位符。
步骤11：带稳定ID的SLA/升级对象。
步骤10：所有四个条件范围；连接器等待无论是否解析均使用标准存根。
步骤11.9：使用规则11的回退行为进行信息性骨架验证。
应用第二阶段→第三阶段的偏好。预览分支需进行资源刷新、过滤后的解决方案上传、打印DesignerUrl，并遵循指定的继续校验；选择Abort则写入
```
build-issues.md
```
并退出。

Phase 3 — Implementation

第三阶段 — 实施

Re-read

tasks.md

and

caseplan.json

(Step 9.6), then follow Steps 9.7, 9.8, 10.5, and 11.5:

Resolve connector schemas/defaults with
```
uip maestro case spec
```
.
Bind I/O for all task classes using io-binding/impl-json.md.
Upgrade resolved connector-bound condition stubs in place; unresolved connectors retain stubs and are reported.
Resolve in-expression
```
vars.$xref
```
markers.
Perform resolved-resource emission, preservation, resourceKey, and connector completeness checks.

Proceed directly to Phase 4 after the Phase 3 checks pass.

重新读取

tasks.md

和

caseplan.json

（步骤9.6），然后遵循步骤9.7、9.8、10.5和11.5：

使用
```
uip maestro case spec
```
解析连接器schema/默认值。
使用io-binding/impl-json.md绑定所有任务类的I/O。
原地升级已解析的连接器绑定条件存根；未解析的连接器保留存根并报告。
解析表达式中的
```
vars.$xref
```
标记。
执行已解析资源的输出、保留、resourceKey和连接器完整性检查。

第三阶段检查通过后直接进入第四阶段。

Phase 4 — Validate

第四阶段 — 验证

Run Step 12 once at the Phase 3 boundary. It performs Checks 1–15, including Check 7 sidecar parity, Check 8 global output-ID uniqueness, Check 9 resource emission/preservation, Check 10 formal-arg IDs, Check 11 resourceKey consistency, Check 12 connector completeness, and Check 15 every task carrying a non-empty entry rule (

validate

only warns on a missing one). Then run full

uip maestro case validate

. Retry at most three times, with an edit before every retry; on the third failure, hard-stop with AskUserQuestion:

Retry with fix

Pause for manual edit

Abort

. Summarize

build-issues.md

using Step 12.1.

在第三阶段边界运行一次步骤12。它会执行检查1–15，包括检查7的辅助文件一致性、检查8的全局输出ID唯一性、检查9的资源输出/保留、检查10的正式参数ID、检查11的resourceKey一致性、检查12的连接器完整性，以及检查15的每个任务是否包含非空的进入规则（

validate

仅会警告缺失该规则）。然后运行完整的

uip maestro case validate

。最多重试三次，每次重试前进行编辑；第三次失败则硬停止，使用AskUserQuestion询问：

Retry with fix

Pause for manual edit

Abort

。使用步骤12.1总结

build-issues.md

。

Phase 5 — Publish

第五阶段 — 发布

Provide the completion report, then hard-stop AskUserQuestion:

Publish to Studio Web

Skip to Debug

(Step 13). On publish, refresh resources and upload with the mandatory output filter, print DesignerUrl, and continue to Phase 6 either way.

提供完成报告，然后硬停止并使用AskUserQuestion询问：

Publish to Studio Web

Skip to Debug

（步骤13）。若选择发布，则刷新资源并使用必填过滤器上传，打印DesignerUrl，然后无论选择如何都进入第六阶段。

Phase 6 — Debug

第六阶段 — 调试

Hard-stop AskUserQuestion (Step 15):

Run debug session

Continue to publish

. On Run, refresh resources, run

uip maestro case debug

, and loop after completion until

Continue to publish

. Never run debug automatically.

硬停止并使用AskUserQuestion询问（步骤15）：

Run debug session

Continue to publish

。若选择Run，则刷新资源，运行

uip maestro case debug

，完成后循环直到选择

Continue to publish

。切勿自动运行调试。

Phase 7 — Publish to Orchestrator

第七阶段 — 发布到Orchestrator

Hard-stop AskUserQuestion (Step 16):

Publish to Orchestrator

Done

. On publish, run in order:

```
uip solution resources refresh
```

uip maestro case pack <SolutionDir>/<ProjectName> <SolutionDir>/dist --output json

uip solution pack <SolutionDir> <SolutionDir>/dist --output json

uip solution publish <packagePath> --wait --output json

case pack

is mandatory because it creates

caseplan.json.bpmn

;

validate

does not. Publish the

solution pack

.zip

, not the case

.nupkg

; read

<packagePath>

from

Data.Packages

, never guess.

Done

exits.

硬停止并使用AskUserQuestion询问（步骤16）：

Publish to Orchestrator

Done

。若选择发布，则按顺序运行：

```
uip solution resources refresh
```

uip maestro case pack <SolutionDir>/<ProjectName> <SolutionDir>/dist --output json

uip solution pack <SolutionDir> <SolutionDir>/dist --output json

uip solution publish <packagePath> --wait --output json

case pack

是必填项，因为它会创建

caseplan.json.bpmn

；

validate

不会创建该文件。发布

solution pack

的

.zip

文件，而非案例的

.nupkg

文件；从

Data.Packages

读取

<packagePath>

，切勿猜测。选择

Done

则退出。

Reference Navigation

参考文档导航

Need	Reference
Design without SDD	`uipath-planner` Case Design Lane; Rule 15
Plan from SDD	references/planning.md
Execute plan	references/implementation.md
Brownfield edit	references/brownfield.md
Phase contracts	references/phased-execution.md
Edit mechanics	references/case-editing-operations.md
Schema	references/case-schema.md
Allowed CLI	references/case-commands.md
Troubleshooting	references/troubleshooting-guide.md
Registry resolution	references/registry-discovery.md
Bindings/expressions	references/bindings-and-expressions.md
Connector integration	references/connector-integration.md
Case spec input details	references/case-spec-input-details.md
Placeholders	references/placeholder-tasks.md
Bindings sidecar	references/bindings-v2-sync.md
Prune orphaned solution resource	bindings-v2-sync.md § Prune orphaned solution resources
Entry points	references/entry-points-sync.md
SLA responses	references/sla-response-shapes.md

需求	参考文档
无SDD时进行设计	`uipath-planner` 案例设计流程；规则15
基于SDD进行规划	references/planning.md
执行规划	references/implementation.md
已有系统编辑	references/brownfield.md
阶段契约	references/phased-execution.md
编辑机制	references/case-editing-operations.md
Schema	references/case-schema.md
允许使用的CLI	references/case-commands.md
故障排除	references/troubleshooting-guide.md
注册表解析	references/registry-discovery.md
绑定/表达式	references/bindings-and-expressions.md
连接器集成	references/connector-integration.md
案例规范输入细节	references/case-spec-input-details.md
占位符	references/placeholder-tasks.md
绑定辅助文件	references/bindings-v2-sync.md
清理孤立的解决方案资源	bindings-v2-sync.md § Prune orphaned solution resources
入口点	references/entry-points-sync.md
SLA响应	references/sla-response-shapes.md

Plugin Index

插件索引

Structural: case/planning.md, stages/planning.md, sla/planning.md, global-vars/planning.md, io-binding/planning.md, and logging/impl-json.md.

Tasks:

Schema `type` / SDD value	Plugin planning reference	CLI describe type
`process`	process	`process`
`agent`	agent	`agent`
`rpa`	rpa	`rpa`
`action`	action	`action`
`api-workflow`	api-workflow	`api-workflow`
`case-management`	case-management	`case-management`
`execute-connector-activity`	connector-activity	`connector-activity`
`wait-for-connector`	connector-trigger	`connector-trigger`
`wait-for-timer`	wait-for-timer	`wait-for-timer`

Schema-kebab is the only JSON value; plugin and CLI names are not interchangeable. Unsupported types include

external-agent

external-workflow

document-extraction

flow-process

, and

wait-for-event

Triggers: manual, timer, and event.

Conditions: stage-entry-conditions, stage-exit-conditions, task-entry-conditions, and case-exit-conditions.

Connector-bound rules in any condition scope require

rule.uipath

built from

case spec --type trigger

; bare connector rules are invalid in Studio Web even when CLI validate passes. See connector-trigger-impl.md.

结构类： case/planning.md、stages/planning.md、sla/planning.md、global-vars/planning.md、io-binding/planning.md和logging/impl-json.md。

任务类：

Schema `type` / SDD值	插件规划参考文档	CLI描述类型
`process`	process	`process`
`agent`	agent	`agent`
`rpa`	rpa	`rpa`
`action`	action	`action`
`api-workflow`	api-workflow	`api-workflow`
`case-management`	case-management	`case-management`
`execute-connector-activity`	connector-activity	`connector-activity`
`wait-for-connector`	connector-trigger	`connector-trigger`
`wait-for-timer`	wait-for-timer	`wait-for-timer`

仅Schema短横线格式为有效JSON值；插件和CLI名称不可互换。不支持的类型包括

external-agent

、

external-workflow

、

document-extraction

、

flow-process

和

wait-for-event

。

触发器类： manual、timer和event。

条件类： stage-entry-conditions、stage-exit-conditions、task-entry-conditions和case-exit-conditions。

任何条件范围内的连接器绑定规则都需要基于

case spec --type trigger

构建的

rule.uipath

；即使CLI验证通过，裸连接器规则在Studio Web中也是无效的。详见connector-trigger-impl.md。

Anti-patterns

反模式

Do not leave a regular stage without an entry condition. The first stage uses
```
case-entered
```
; every other regular stage needs a reachable predecessor. Edges are retired.
Do not design here, start Phase 1 before Case Review approval, or build from a summary SDD. The planner owns design, other-path analysis, and template conformance.
Do not validate after each T-entry or validate twice without an intervening edit. Phase 2 validation is informational; Phase 4 validation is authoritative.
Write
```
tasks.md
```
with a seeded header and per-section batched Edit-appends: §4.2.1 variables, §4.3 triggers, §4.4 stages, §4.6 tasks, §4.7 conditions, and §4.8 SLA. Never write per T-entry, use a mega-Write, or exceed a 30KB single Edit payload. Recovery re-reads and resumes at the next unapplied entry. See planning.md §4.0a.
Write
```
caseplan.json
```
by section, preserving untouched siblings — never one Write for the whole file. Read once at section entry; use per-entry Edits for fewer than 10 entries, or one Write covering only that section's container (the stages array, or one stage's task array) for 10 or more; gather CLI-gated sections before writing. Cap any single Write at ~15K output tokens / ~40KB; split a case with ≥40 tasks or ≥8 stages across the Phase 2 and Phase 3 writes rather than emitting the fully populated file at once. Re-read both files after interruption. See case-editing-operations.md § Per-section batch write contract.
Do not emit standalone narration between tool calls. Bundle status with the next tool call; keep ordinary text under 200 tokens and allow-listed kickoff, hard-stop preambles, completion reports, DesignerUrl prints, and validation summaries under 500. Do not announce imminent actions with verbs such as
```
Building
```
,
```
Composing
```
,
```
Writing
```
,
```
Drafting
```
,
```
Generating
```
,
```
Now I'll
```
,
```
Next
```
,
```
Approach
```
,
```
Strategy
```
,
```
Plan
```
,
```
Let me
```
, or equivalent.
Preserve ordered task semantics. Sequential mode uses ordered
```
data.tasks
```
sets and one
```
runs-sequentially
```
rule per task; do not add
```
current-stage-entered
```
alongside it. Use parallel
```
current-stage-entered
```
only for independent work and
```
selected-tasks-completed
```
only for required fan-in. Event-triggered tasks use event/condition rules; manually triggered/adhoc tasks use one
```
adhoc
```
rule,
```
isRequired: false
```
, and no additional entry event.
```
adhoc
```
is an activation mode, not a task type.
Model secondary stages as interrupting exception lanes:
```
case-management:Stage
```
,
```
data.stageType: "secondary"
```
,
```
isRequired: false
```
, and
```
Interrupting: Yes
```
on stage and entries. Use
```
Interrupting: No
```
only for parallel SLA oversight. Use
```
return-to-origin
```
; do not connect secondary stages as normal flow or count them in required completion.
Do not replicate global events or SLA rules across primary stages. Case completion requires a root
```
metadata.caseExitRules[]
```
rule with
```
marksCaseComplete: true
```
; stage completion alone is insufficient. Non-completing outcomes use
```
marksCaseComplete: false
```
.
Do not edit generated
```
caseplan.json.bpmn
```
; do not place
```
caseplan.json
```
under
```
content/
```
; do not fabricate conditional-SLA expression syntax; describe conditions naturally until execution resolves them.
Do not place
```
tasks/
```
in the solution/project; it stays beside
```
sdd.md
```
.
Do not invoke other skills automatically except Rule 15 design handoff and Rule 17’s gate-selected inline creation of agents/API workflows. Do not spawn subagents for design, draft finalization, or plan-only documents.
Use
```
uipath-feedback
```
for trouble.

Trouble? Use
/uipath-feedback
to send a report.

切勿让常规阶段缺少进入条件。第一个阶段使用
```
case-entered
```
；其他每个常规阶段都需要一个可到达的前置阶段。边已不再使用。
切勿在此处进行设计、在案例评审批准前启动第一阶段，或基于摘要式SDD进行构建。规划器负责设计、其他路径分析和模板一致性校验。
切勿在每个T条目后进行验证，或在未进行中间编辑的情况下验证两次。第二阶段的验证为信息性验证；第四阶段的验证为权威性验证。
编写
```
tasks.md
```
时需使用预设标题，并按章节批量追加编辑：§4.2.1变量、§4.3触发器、§4.4阶段、§4.6任务、§4.7条件和§4.8 SLA。切勿按每个T条目编写、使用单次大写入操作，或超过30KB的单次编辑负载。恢复时需重新读取并在下一个未应用的条目处继续。详见planning.md §4.0a。
编写
```
caseplan.json
```
时需按章节进行，保留未修改的同级内容 — 切勿单次写入整个文件。进入章节时读取一次；条目少于10个时使用逐条编辑，条目≥10个时使用一次写入操作覆盖该章节的容器（阶段数组或某阶段的任务数组）；写入前收集CLI校验的章节内容。单次写入操作的输出令牌上限约为15K / 40KB；对于包含≥40个任务或≥8个阶段的案例，需拆分到第二阶段和第三阶段写入，而非一次性输出完整文件。中断后需重新读取两个文件。详见case-editing-operations.md § Per-section batch write contract。
切勿在工具调用之间添加独立的叙述文本。将状态信息与下一次工具调用捆绑；普通文本控制在200令牌以内，允许的启动块、硬停止前置文本、完成报告、DesignerUrl打印和验证摘要控制在500令牌以内。切勿使用
```
Building
```
、
```
Composing
```
、
```
Writing
```
、
```
Drafting
```
、
```
Generating
```
、
```
Now I'll
```
、
```
Next
```
、
```
Approach
```
、
```
Strategy
```
、
```
Plan
```
、
```
Let me
```
等动词宣布即将执行的操作。
保留有序任务语义。顺序模式使用有序的
```
data.tasks
```
集合，每个任务对应一个
```
runs-sequentially
```
规则；切勿同时添加
```
current-stage-entered
```
。仅对独立工作使用并行的
```
current-stage-entered
```
，仅对必要的扇入使用
```
selected-tasks-completed
```
。事件触发的任务使用事件/条件规则；手动触发/临时任务使用一个
```
adhoc
```
规则、
```
isRequired: false
```
，且无额外进入事件。
```
adhoc
```
是激活模式，而非任务类型。
将次级阶段建模为中断性异常通道：
```
case-management:Stage
```
、
```
data.stageType: "secondary"
```
、
```
isRequired: false
```
，且阶段和条目设置
```
Interrupting: Yes
```
。仅对并行SLA监控使用
```
Interrupting: No
```
。使用
```
return-to-origin
```
；切勿将次级阶段作为正常流连接，也不要将其计入必填完成项。
切勿在主阶段间复制全局事件或SLA规则。案例完成需要根
```
metadata.caseExitRules[]
```
规则设置
```
marksCaseComplete: true
```
；仅阶段完成不足以结束案例。非完成结果需设置
```
marksCaseComplete: false
```
。
切勿编辑生成的
```
caseplan.json.bpmn
```
；切勿将
```
caseplan.json
```
放在
```
content/
```
下；切勿编造条件SLA表达式语法；在执行解析前用自然语言描述条件。
切勿将
```
tasks/
```
放在解决方案/项目内部；它需与
```
sdd.md
```
同级。
除规则15的设计交接和规则17中校验选中的内联创建代理/API工作流外，切勿自动调用其他技能。切勿为设计、草稿定稿或仅规划文档生成子代理。
如有问题，请使用
```
uipath-feedback
```
。

遇到问题？ 使用
/uipath-feedback
提交报告。