← YCloud Developer KitCONTENT HISTORY

Update to YCloud Developer Kit

Snapshot Sep 30, 2026 · 23:15 UTC · version 0.7.9

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Design, implement locally, or evaluate secure server-side YCloud API authentication with the contract’s X-API-Key scheme, placeholder configuration, environment isolation, secret-manager boundaries, and API-key rotation planning. Use for API-key storage, header, or API-key rotation questions; webhook endpoint secret rotation belongs to Webhooks.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 290
    },
    {
      "relative_path": "references/openapi.md",
      "size_in_bytes": 1382
    },
    {
      "relative_path": "references/runtime.md",
      "size_in_bytes": 13058
    },
    {
      "relative_path": "references/shared/integration-boundaries.md",
      "size_in_bytes": 8401
    },
    {
      "relative_path": "references/shared/sandbox-contract.md",
      "size_in_bytes": 5363
    }
  ],
  "name": "ycloud-api-authentication",
  "skill_md_contents": "---\nname: ycloud-api-authentication\ndescription: Design, implement locally, or evaluate secure server-side YCloud API authentication with the contract’s X-API-Key scheme, placeholder configuration, environment isolation, secret-manager boundaries, and API-key rotation planning. Use for API-key storage, header, or API-key rotation questions; webhook endpoint secret rotation belongs to Webhooks.\n---\n\n# YCloud API Authentication\n\nDesign or implement authentication at a trusted server boundary. Use the global authentication scheme in `references/openapi.md` and the official error behavior in `references/runtime.md`. When translating authentication errors or designing rotation coordination, also read `references/shared/integration-boundaries.md` and label project policy separately from YCloud behavior. Never call YCloud, read a credential, or expose a real secret.\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\nInfer the Architect dimensions when they are supplied: `scope`, `deliverable`,\nand `mutation`. Without an Architect handoff, default to focused scope and\nread-only guidance unless the user explicitly asks to implement local project\nchanges. Local-write authorization permits server config adapters, validation,\nredaction, and no-network tests inside the scoped project. It does not permit\nreading, setting, validating, or rotating a real key, changing deployment or\nproduction configuration, or making an external request.\n\n## Scope and handoff\n\nHandle only server-side API-key configuration and API-key rotation planning. A generic \"rotate secret\" request must be clarified: webhook endpoint secret rotation belongs to Webhooks, not Authentication. Route these requests away:\n\n- Message send/retrieve (including sending an existing template) → `ycloud-whatsapp-messages`.\n- Media upload → `ycloud-whatsapp-media`.\n- Template lifecycle or analytics → `ycloud-whatsapp-templates`.\n- Webhook endpoint management → `ycloud-webhook-endpoints`.\n- Broad or multi-domain integration planning → `ycloud-integration-architect`.\n- Plugin readiness → the readiness-only smoke Skill; repository-maintenance and issue-tracker workflows are outside this Plugin.\n\n## Workflow\n\nFor explicitly requested sandbox/mock/no-real-side-effect tests, also read\n`references/shared/sandbox-contract.md`. The fixed synthetic key belongs only to\nthe local Facade and is not a YCloud test credential or an example of production\nkey format.\n\n1. Inspect project structure read-only to identify the server runtime, configuration mechanism, deployment environments, and test harness. Do not open or parse secret values from `.env`, credential files, secret stores, logs, shell history, browser storage, or customer data. Ask only for a missing runtime/deployment fact that changes the guidance.\n2. Read both narrow references and preserve their exact boundaries. The request header is `X-API-Key`; show only a placeholder such as `<YCLOUD_API_KEY>`, never a user-provided key. An invalid key is documented as HTTP `401` with `error.code=UNAUTHORIZED`; preserve that provider envelope and `YCloud-Request-ID`. If the project exposes RFC 9457, translate only at its own API boundary and retain redacted `provider_code`/`provider_request_id`; never claim YCloud returned Problem Details.\n3. Keep the key on a trusted server boundary. Recommend an environment-specific secret injection path or Secret Manager reference, least-privilege access, redaction, and rotation ownership without claiming provider-specific behavior that the contract does not state.\n4. Explain environment isolation (development, staging, production), startup/configuration validation that checks presence and shape without printing the value, and tests that use a synthetic placeholder. When local writes are authorized, implement these seams using the project's established configuration pattern and run no-network tests; never inspect the user's environment value.\n\n## Safe examples\n\nIllustrative raw HTTP only; do not execute it:\n\n```http\nX-API-Key: <YCLOUD_API_KEY>\n```\n\nIllustrative server configuration shape (choose the project’s established mechanism; the value is never supplied here):\n\n```text\nYCLOUD_API_KEY=<injected-secret-placeholder>\n```\n\nNever place the key in a browser/mobile bundle, client-side storage, a URL/query parameter, source control, a code sample with a real value, analytics, or ordinary request logs. Redact authorization headers in diagnostics.\n\n## Outcome requirements\n\nAdapt the shape to planning, implementation, or evaluation. Make these results\neasy to verify:\n\n### Contract\n\nName the confirmed global `api_key` `apiKey` security scheme with header name `X-API-Key` and cite the generated reference. Distinguish raw HTTP from any SDK/codegen shape.\n\n### Configuration Plan\n\nDescribe the server-only injection point, environment separation, access/redaction controls, startup checks, and rotation handoff. Use names and placeholders, not secret values.\n\n### Project Integration\n\nMap the plan to confirmed project modules (HTTP client, config loader, deployment manifest, and tests). If the project cannot be inspected, ask the minimum questions or mark the assumption.\n\n### Tests\n\nCover header construction with `<YCLOUD_API_KEY>`, missing/blank configuration, environment isolation, redaction, a synthetic `401/UNAUTHORIZED` envelope, and request-ID correlation. Tests must not contact YCloud or inspect a real secret.\n\n### CANNOT\n\nExplicitly refuse to read, echo, validate, rotate, retrieve, or store a real key; call the API; make unrequested local changes or any deployment/production change; put a key client-side, in a URL, logs, or a repository; infer an SDK auth method; or assert unspecified key expiry, rotation overlap, recovery, retry, or endpoint-specific rate behavior. Do not mark the documented `401/UNAUTHORIZED` behavior as unknown. For rotation, describe coordination and confirmation points only.\n\n### Handoff\n\nSend message/media/template/webhook work to its domain Skill. For an Architect\nhandoff, return `crosscutting:api-authentication` status, project seams, changed\nor proposed artifacts, tests and results, unknowns, and the server-side header\nboundary. Authentication does not perform the downstream workflow.\n\n## Codegen boundary\n\nDo not infer a Java, TypeScript, Python, Go, or PHP SDK method from `operationId` or model names. Provide a raw HTTP/header example unless the user supplies a confirmed SDK artifact/version and authoritative docs. Treat generated models and schema composition as codegen hints, not additional authentication behavior.\n"
}

SHA-256 of public snapshot: 4684bc995ebcec2636f2226a6b24f2ee022f9830083517a0529b494269cc686b