feat(skill): 固定服务地址并强化目标确认

.agents/skills/upload-delivery-desk-work/SKILL.md

@@ -12,6 +12,7 @@ Use a two-phase plan/apply workflow. Optimize for correct placement, not speed.
 - Treat the product hierarchy as `operation group -> project -> work -> review round`.
 - Never use a collection/delivery-set identifier. `collections`, `notes`, and `versions` are legacy compatibility names.
 - Never infer a project or work from a partial name, page position, recent activity, or a remembered ID.
+- At the start of every invocation, discover and explicitly ask the operator to confirm the exact operation group and project. A target confirmation from an earlier invocation cannot be reused.
 - Never create a work until the operator confirms the resolved group, project, content, image order, and confirmation code.
 - Never create a new round until the operator confirms the resolved work and current round.
 - Never retry a timed-out create request. First inspect current server state; otherwise a retry can create a duplicate round.
@@ -38,7 +39,7 @@ Do not create groups, projects, API keys, feedback, or review decisions with thi
 
 For both operations, require:
 
-- Delivery Desk base URL. Default to `DELIVERY_DESK_BASE_URL` or `http://127.0.0.1:3010` only for local development.
+- Use the fixed Delivery Desk API address `http://192.168.30.90:3010`. Do not ask the operator to configure it. Use `--base-url` only when the operator explicitly instructs you to migrate or test another environment.
 - A valid API key in `DELIVERY_DESK_API_KEY`.
 - Exact target project, resolved to group ID/name and project ID/name/slug.
 - Ordered public image URLs or ordered local image paths.
@@ -57,7 +58,7 @@ For `create_round`, also require:
 
 When information is missing, ask one concise question listing only the missing fields. Do not proceed to mutation.
 
-## 3. Discover authoritative IDs
+## 3. Discover and confirm the authoritative target
 
 Use the bundled script from the skill directory:
 
@@ -73,8 +74,9 @@ Resolution rules:
 1. Match IDs first.
 2. Validate the project ID against its returned group ID, group name, project name, and slug.
 3. If the operator supplied only names, list exact matches with IDs and ask the operator to choose when zero or multiple matches exist.
-4. Even with one match, show the resolved identity before creating the plan.
-5. For a new round, verify the work belongs to the confirmed project.
+4. Even when the request already names a target or only one project is accessible, show the resolved group name/ID and project name/ID/slug and ask: `本次操作目标是否为：运营组「<group_name>」(ID <group_id>) / 项目「<project_name>」(ID <project_id>, slug <slug>)？请回复“确认目标”。`
+5. Accept only an explicit target confirmation given during the current invocation. Do not generate `plan-work` or `plan-round` before it.
+6. For a new round, verify the work belongs to the confirmed project.
 
 Do not silently choose the only project merely because an API key currently exposes one.