Update to YCloud Developer Kit

{
  "description": "Design, implement locally, or evaluate the YCloud WhatsApp media upload contract, multipart request and response handling, and media-to-message handoff. Use for media upload integration; do not use for sending messages, template lifecycle, readiness, broad integration planning, or real API operations.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 275
    },
    {
      "relative_path": "references/openapi.md",
      "size_in_bytes": 7800
    },
    {
      "relative_path": "references/runtime.md",
      "size_in_bytes": 17157
    },
    {
      "relative_path": "references/shared/integration-boundaries.md",
      "size_in_bytes": 8401
    }
  ],
  "name": "ycloud-whatsapp-media",
  "skill_md_contents": "---\nname: ycloud-whatsapp-media\ndescription: Design, implement locally, or evaluate the YCloud WhatsApp media upload contract, multipart request and response handling, and media-to-message handoff. Use for media upload integration; do not use for sending messages, template lifecycle, readiness, broad integration planning, or real API operations.\n---\n\n# YCloud WhatsApp Media\n\nDesign or implement a contract-aware media upload integration. Keep this skill\nlimited to the one media-upload operation and the handoff that follows it.\n\n## Execution boundary\n\nThese restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.\n\nHonor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,\nproject seams, and expected evidence. Without one, default to focused scope and\nread-only guidance unless the user explicitly requests local implementation.\nLocal-write authorization permits multipart builders, adapters, handlers,\ntest-console bindings, synthetic fixtures, and no-network tests inside the scoped\nproject. It does not authorize opening or transmitting a real user file or\ncalling the upload API. Reuse the project's existing UI/interface stack; do not\ncreate a dashboard or select a framework without user/project support.\n\n## Trigger boundary\n\nUse this skill when the user asks to upload WhatsApp media, construct the upload\nrequest, interpret its response, or connect an upload result to a later message.\nRoute these requests elsewhere:\n\n- Send a message, including a message that references an existing media object: hand off to `ycloud-whatsapp-messages`.\n- Create, edit, list, retrieve, delete, or analyze a template: hand off to `ycloud-whatsapp-templates`.\n- Design a multi-domain YCloud integration: hand off to `ycloud-integration-architect`.\n- Check Developer Kit readiness or run repository-maintenance/issue-tracker workflows: do not trigger this skill.\n- Download, inspect, or transmit a real local file: stop and use a synthetic fixture instead.\n\nDo not load the complete OpenAPI document. Read only\n`references/openapi.md` and `references/runtime.md` after this skill has been selected. If retry, idempotency, queueing, or error translation is requested, also read `references/shared/integration-boundaries.md`. Treat the exact\nsource path, method, operationId, schema, and constraints in that generated\nreference as authoritative. If the reference is missing, stale, or conflicts\nwith the pinned source, report the drift and stop rather than guessing.\n\n## Workflow\n\n1. Identify the server-side project location and runtime only from files the user\n   explicitly places in scope. Ask for missing facts; do not assume a framework,\n   SDK, package, deployment, or credential source. When local writes are\n   authorized, preserve existing project patterns and concurrent edits.\n2. Select the single upload operation documented in the reference:\n   `POST /whatsapp/media/{phoneNumber}/upload`, operationId\n   `whatsapp_media-upload`. Preserve its path parameter, multipart content type,\n   required fields, request schema, response schema, and documented descriptions\n   exactly as generated. Apply the standard error envelope, request ID, generic\n   `429` headers, documented `413 CONTENT_TOO_LARGE`, the one-file rule,\n   reviewed media type/size limits, and 30-day persistence from `runtime.md`.\n   Reject multiple files locally even though the API would process only the\n   first. Do not invent a media-specific quota, safe replay rule, idempotency,\n   or durable retention beyond that period.\n   Interpret `allOf` as schema composition and `x-*` extensions or generated\n   model names as codegen hints, not additional business behavior.\n3. Produce a contract-aware request construction using placeholders such as\n   `<YCLOUD_API_KEY>`, `<PHONE_NUMBER>`, and synthetic media metadata. Raw HTTP\n   examples are allowed. Use an SDK-specific example only when the project or\n   user supplies a confirmed artifact and version; never derive a method name\n   from `operationId`.\n4. Explain the response only to the extent confirmed by the reference. Identify\n   the media identifier/reference needed by a later message, without implying\n   that an upload sent a WhatsApp message. Prefer the returned media ID for a\n   normal media message, but preserve the documented exception that an\n   interactive-message header must use a link instead of a Media ID.\n5. Place the upload at the server-side integration boundary (for example, an\n   application service or adapter) and keep the API key out of browsers, mobile\n   apps, URLs, logs, source control, and generated snippets. Do not read `.env`,\n   secret stores, logs, or customer media.\n6. Treat upload timeouts as ambiguous and never replay automatically. Any\n   project idempotency record, queue, retry budget, or Problem Details response\n   is local policy, not a YCloud feature.\n7. Give synthetic tests for multipart construction, exactly-one-file validation,\n   supported type/size boundaries, 30-day lifecycle handling, path-parameter\n   handling, response/reference mapping, the interactive-header link exception,\n   and the upload-to-message handoff. Tests must not call YCloud or upload a real\n   file.\n\n## Outcome requirements\n\nAdapt the result to planning, implementation, or evaluation. Preserve these\ncontract and evidence outcomes:\n\n1. **Matched contract** — reference source hash, path, method, operationId,\n   request content type/schema, response schema, and confirmed constraints.\n2. **Request construction** — placeholder raw HTTP or project-local snippet;\n   state any project facts still needed.\n3. **Response and handoff** — map only confirmed response fields to a media\n   reference, then hand off message composition/sending to\n   `ycloud-whatsapp-messages`.\n4. **Integration placement** — server-side module, configuration boundary, and\n   redacted observability guidance.\n5. **Tests** — synthetic unit/contract tests and negative cases.\n6. **CANNOT** — list unknown contract facts, missing project facts, unsupported\n   media operations, SDK uncertainties, and every action intentionally not run.\n7. **Handoff** — return to Architect with `whatsapp_media-upload` status,\n   changed or proposed artifacts, tests/results, unknowns, and the confirmed\n   media-reference contract for Messages; otherwise state that no handoff is\n   needed.\n\n## Safety stop\n\nNever call the YCloud API, open or transmit a real user file, persist credentials,\nor claim that media was sent. Local code changes are allowed only when explicitly\nrequested and remain synthetic/no-network. A request to perform a real upload\nstops before the external action even when local implementation was authorized.\n"
}