Update to YCloud Developer Kit

{
  "description": "Design, implement, or evaluate a cross-domain YCloud integration from local project context, with explicit scope, deliverable, mutation boundaries, domain handoffs, and coverage evidence. Use for broad integration or multi-domain orchestration; do not use for readiness, repository-maintenance, issue-tracker, support, or requests confined to one domain.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 309
    },
    {
      "relative_path": "references/capability-catalog-summary.md",
      "size_in_bytes": 5875
    },
    {
      "relative_path": "references/coverage-matrix-schema.md",
      "size_in_bytes": 2795
    },
    {
      "relative_path": "references/handoff-contracts.md",
      "size_in_bytes": 4496
    },
    {
      "relative_path": "references/modes/focused.md",
      "size_in_bytes": 879
    },
    {
      "relative_path": "references/modes/full-first-wave.md",
      "size_in_bytes": 1204
    },
    {
      "relative_path": "references/modes/full-supported-operations.md",
      "size_in_bytes": 1433
    },
    {
      "relative_path": "references/modes/full-whatsapp-operations.md",
      "size_in_bytes": 1388
    },
    {
      "relative_path": "references/modes/production-plan.md",
      "size_in_bytes": 877
    },
    {
      "relative_path": "references/modes/test-console.md",
      "size_in_bytes": 1348
    },
    {
      "relative_path": "references/openapi.md",
      "size_in_bytes": 2542
    },
    {
      "relative_path": "references/runtime.md",
      "size_in_bytes": 28420
    },
    {
      "relative_path": "references/shared/integration-boundaries.md",
      "size_in_bytes": 8401
    },
    {
      "relative_path": "references/shared/pagination-contract.md",
      "size_in_bytes": 3494
    },
    {
      "relative_path": "references/shared/reference-integrations.md",
      "size_in_bytes": 3040
    },
    {
      "relative_path": "references/shared/sandbox-contract.md",
      "size_in_bytes": 5363
    }
  ],
  "name": "ycloud-integration-architect",
  "skill_md_contents": "---\nname: ycloud-integration-architect\ndescription: Design, implement, or evaluate a cross-domain YCloud integration from local project context, with explicit scope, deliverable, mutation boundaries, domain handoffs, and coverage evidence. Use for broad integration or multi-domain orchestration; do not use for readiness, repository-maintenance, issue-tracker, support, or requests confined to one domain.\n---\n\n# YCloud Integration Architect\n\nOrchestrate a contract-aware YCloud integration across every Developer Kit-owned\ndomain. Normalize the request before acting, delegate\ndomain contract decisions to the matching Skill, and merge their evidence into\none result. Never call a real YCloud API, read credentials or customer data, or\ninfer permission for an external action from permission to edit local files.\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\n## Normalize the request\n\nResolve these dimensions from the user's words and project context:\n\n```text\nscope: focused | full-first-wave | full-whatsapp-operations | full-supported-operations\ndeliverable: project-integration | test-console | production-plan\nmutation: read-only | local-write-authorized\n```\n\n- Default to `focused` when the user names a concrete outcome or domain.\n- “All currently supported capabilities” means `full-supported-operations`: 88\n  API operations plus 2 cross-cutting capabilities = 90 coverage rows.\n- `full-first-wave` remains a compatibility mode: 17 API operations + 2\n  cross-cutting capabilities = 19 coverage rows.\n- “All YCloud APIs” requires an explicit `88 API operations + 2 cross-cutting capabilities = 90 coverage rows`\n  disclosure, with 7 operations excluded by product decision. Product exclusion\n  is not provider deprecation; never claim all 95 are covered.\n- Select `test-console` only when the user asks for a test UI, console, explorer,\n  or comparable interactive surface. Do not turn `full-first-wave` into a\n  dashboard on its own.\n- Select `production-plan` for production architecture or rollout planning. It\n  is read-only unless the user separately asks to implement local artifacts.\n- Local implementation authorization permits writes only inside the scoped\n  project. It never permits sending, uploading, deleting, rotating, changing a\n  remote endpoint, or otherwise calling a real provider API.\n\nRead only the selected mode reference:\n\n- `focused` → [references/modes/focused.md](references/modes/focused.md)\n- `full-first-wave` → [references/modes/full-first-wave.md](references/modes/full-first-wave.md)\n- `full-whatsapp-operations` → [references/modes/full-whatsapp-operations.md](references/modes/full-whatsapp-operations.md)\n- `full-supported-operations` → [references/modes/full-supported-operations.md](references/modes/full-supported-operations.md)\n- `test-console` → [references/modes/test-console.md](references/modes/test-console.md)\n- `production-plan` → [references/modes/production-plan.md](references/modes/production-plan.md)\n\nWhen scope or completion is material, also read\n[references/capability-catalog-summary.md](references/capability-catalog-summary.md)\nand [references/coverage-matrix-schema.md](references/coverage-matrix-schema.md).\nFor multi-domain work, read\n[references/handoff-contracts.md](references/handoff-contracts.md).\n\n## Domain routing\n\n| Concern | Owner Skill | Boundary |\n| --- | --- | --- |\n| API key, trusted-server header, storage, API-key rotation plan | `ycloud-api-authentication` | Never read or validate a real key; generic secret rotation must be disambiguated |\n| Direct/queued message send construction or retrieve | `ycloud-whatsapp-messages` | Existing-template sending belongs here; accepted is not final |\n| WhatsApp media upload construction | `ycloud-whatsapp-media` | Return a media handoff; upload is not send |\n| Template lifecycle and analytics | `ycloud-whatsapp-templates` | Lifecycle is separate from template sending |\n| Webhook endpoint management or receiver | `ycloud-webhook-endpoints` | Endpoint management and event receipt remain separate |\n| WABA inventory or ACO settings | `ycloud-whatsapp-business-accounts` | Pass opaque WABA identity to Phone Numbers/Messages/Templates |\n| Phone registration, profile, username, settings, or commerce | `ycloud-whatsapp-phone-numbers` | Calling settings do not include WhatsApp Calling sessions |\n| Group lifecycle, membership, invite links, or settings | `ycloud-whatsapp-groups` | Group management and message final state remain separate |\n| Flow lifecycle, preview, publish, deprecate, or delete | `ycloud-whatsapp-flows` | Flow management and Flow message sending remain separate |\n| Mark inbound message read or show typing | `ycloud-whatsapp-inbound-messages` | Consume a verified Receiver message identity, not event ID |\n| Account balance | `ycloud-balance` | Balance is readiness evidence, not a send/delivery guarantee |\n| Contact CRUD, attributes, or notes | `ycloud-contacts` | Contact and note IDs remain distinct; writes are not replay-safe by default |\n| Custom event definitions, properties, or ingestion | `ycloud-custom-events` | Definition lifecycle and event acceptance remain separate |\n| Customer/channel unsubscribe state | `ycloud-unsubscribers` | Eligibility evidence is not provider send or delivery state |\n| WhatsApp Calling session commands or call media | `ycloud-whatsapp-calling` | Command acceptance is not final call state; media is a separate handoff |\n\nRead `references/openapi.md` and `references/runtime.md` for Architect-level\nprovenance, then load only the selected domain's narrow OpenAPI/runtime\nreferences. Never load the full OpenAPI snapshot by default. For error\ntranslation, retry, idempotency, rate limiting, webhook reliability, or\ncross-domain policy, read `references/shared/integration-boundaries.md`. Stop on\nsource conflict or drift instead of guessing.\nWhen any selected operation lists resources, also read\n`references/shared/pagination-contract.md` and preserve its operation-specific\nresponse envelope through client, service, handler, and UI-facing DTO tests.\n\nWhen the user explicitly asks for sandbox/mock/no-real-side-effect integration\ntesting or a local YCloud base-URL replacement, also read\n`references/shared/sandbox-contract.md`. Keep its provider-shaped surface,\nDeveloper Kit policy, and mock-only control namespace separate; do not count the\nFacade as additional OpenAPI coverage or silently substitute it for a real\nproduction-readiness check.\n\nWhen the user asks for a Java/Node reference project, SDK/Quickstart support,\ngenerated-project evaluation, TTPRI, Beta evidence, or release readiness, also\nread `references/shared/reference-integrations.md`. Treat executable paths as\nsource-distribution assets that may be absent from an installed Plugin. Keep\noracle harness results, caller-supplied candidate evidence, source-bound\nreceipts, synthetic TTPRI and real Beta evidence as separate trust layers.\n\n## Project work\n\nInspect only non-secret project structure needed to identify runtime, framework,\nbuild files, server/client boundary, configuration pattern, HTTP client, tests,\nand an existing YCloud seam. Reuse the project's architecture and UI framework;\ndo not introduce React, Vue, Next.js, Spring, or another framework merely because\na test console was requested.\n\nWhen local writes are authorized, implement the smallest complete vertical seam\nfor the selected scope and run proportionate no-network tests. Preserve unrelated\nand concurrent edits. When writes are not authorized, provide a plan with\nconcrete project seams and do not change files. Do not apply project changes\nunless the user has explicitly authorized local writes for that scoped project.\n\n## Contract rules\n\n- Exact paths, methods, schemas, and descriptions come from the selected\n  generated reference. Use placeholders and synthetic IDs.\n- `operationId`, codegen extensions, generated model names, and `allOf` do not\n  establish an SDK method or new provider behavior.\n- Use `runtime.md` for the documented error envelope, request ID, rate limits,\n  pagination, compatibility, and asynchronous behavior. Keep provider contract,\n  Developer Kit policy, and project decisions visibly separate.\n- Include a provider error/request-ID/rate-limit adapter whenever selected\n  operations need those cross-cutting runtime behaviors.\n- Generate tolerant clients: preserve unknown properties and enum/event values,\n  keep explicit unknown response/enum compatibility handling, and treat YCloud\n  IDs as opaque case-sensitive strings up to 255 characters.\n- Do not invent general idempotency, replay safety, fixed signature tolerance,\n  delivery guarantees, or unlisted errors. Treat ambiguous mutation timeouts as\n  ambiguous outcomes.\n\n## Orchestration and evidence\n\nSend each owner a handoff containing mode, selected capability IDs, project\nseams, authorization level, preconditions, and evidence expected. Require the\ndomain result to return implemented/deferred/blocked rows, changed artifacts,\ntests and results, unknowns, and any outgoing handoff. Merge those results\nyourself; do not finish with instructions for the user to invoke every domain\nSkill manually.\n\nFor `full-first-wave`, account for all 19 rows. For\n`full-whatsapp-operations`, account for all 62 rows. For\n`full-supported-operations`, account for all 90 rows. A row is not implemented merely\nbecause a menu, card, route name, sample JSON, or button exists. Implemented rows\nneed a linked adapter/handler/service artifact and behavioral test evidence.\nDeferred and blocked rows are allowed only with explicit reasons; silent omissions\nfail coverage. Future and product-excluded operations remain disclosure rows and\nmust never be counted as implemented coverage.\n\n## Outcome requirements\n\nAdapt the response to the selected deliverable instead of forcing fixed headings.\nAlways make these facts easy to verify:\n\n- normalized scope, deliverable, and mutation level;\n- confirmed project facts and source provenance;\n- selected capability rows and domain owners;\n- architecture and cross-domain handoffs;\n- local changes or proposed seams, with no claim that external actions ran;\n- tests/evidence and accepted-versus-final state boundaries;\n- deferred, blocked, unknown, unsupported, and authorization-gated items;\n- next action needed from the user, if any.\n\n### CANNOT\n\nKeep real credentials, customer data, unconfirmed SDK behavior, unsupported\noperations, and invented provider guarantees out of the result. Treat real\nsends, uploads, deletes, endpoint changes, secret rotations, and production\nchanges as high-risk external actions. Local-write authorization never permits\nthem, and this workflow does not execute them.\n\n### Handoff\n\nReturn a merged coverage/evidence result to the user. If further work requires a\nnew project scope, external action, production mutation, or missing material\ndecision, identify the owner and request that authorization or fact explicitly.\nDo not substitute a list of Skills the user must invoke for the merged result.\n\nUse placeholders and synthetic data. Readiness belongs to the smoke Skill.\nRepository maintenance, issue tracking, ordinary product explanation, and\nsupport cases remain outside this Skill.\n"
}