← 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 YCloud custom-event definition/property lifecycle and CONTACT-associated event ingestion. Use for the seven allowlisted Custom Events operations; exclude Contact lifecycle, webhook consumption, analytics, and real API mutations.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 287
    },
    {
      "relative_path": "references/openapi.md",
      "size_in_bytes": 19829
    },
    {
      "relative_path": "references/runtime.md",
      "size_in_bytes": 13898
    },
    {
      "relative_path": "references/shared/integration-boundaries.md",
      "size_in_bytes": 8401
    }
  ],
  "name": "ycloud-custom-events",
  "skill_md_contents": "---\nname: ycloud-custom-events\ndescription: Design, implement locally, or evaluate YCloud custom-event definition/property lifecycle and CONTACT-associated event ingestion. Use for the seven allowlisted Custom Events operations; exclude Contact lifecycle, webhook consumption, analytics, and real API mutations.\n---\n\n# YCloud Custom Events\n\nDesign or implement contract-aware custom-event schema management and event\ningestion with synthetic data and a mock transport only. Never call YCloud,\nread credentials or customer data, mutate a real definition, or send a real\nevent.\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 an Architect handoff for scope, deliverable, mutation, capability IDs,\nproject seams, Contact artifacts, and expected evidence. Without one, default\nto focused read-only guidance unless the user explicitly requests local\nimplementation. Local-write authorization permits server-side request models,\nbuilders, adapters, handlers, fixtures, and no-network tests in the scoped\nproject. It never authorizes an external create, update, delete, retrieve, or\nsend request. Use placeholders and synthetic identifiers throughout.\n\nAfter this Skill is selected, read the pinned [OpenAPI\ncontract](references/openapi.md) and reviewed [runtime\nboundaries](references/runtime.md). If retry, idempotency, outbox/queue, rate\nlimiting, or error translation is requested, also read\n`references/shared/integration-boundaries.md`. If the source hash, operation\ncoverage, or contract facts drift, stop and report the mismatch instead of\nguessing.\n\n## Exact scope and routing\n\nDefinition and property lifecycle is separate from occurrence ingestion:\n\n| Concern | Method and path | operationId |\n| --- | --- | --- |\n| Create definition | `POST /event/definitions` | `custom_events-create-definition` |\n| Retrieve definition | `GET /event/definitions/{name}` | `custom_events-retrieve-definition` |\n| Update definition metadata | `PATCH /event/definitions/{name}` | `custom_events-update-definition` |\n| Create property definition | `POST /event/definitions/{name}/properties` | `custom_events-create-property-definition` |\n| Delete property definition | `DELETE /event/definitions/{name}/properties/{propertyName}` | `custom_events_delete-property-definition` |\n| Update property metadata | `PATCH /event/definitions/{name}/properties/{propertyName}` | `custom_events_update-property-definition` |\n| Ingest event occurrence | `POST /event/events` | `custom_events-send-event` |\n\nThe first six operations manage reusable definitions; they do not ingest an\nevent. The final operation submits one occurrence; it does not create or alter\nits definition. Contact create/retrieve/update/delete and identity resolution\nbelong to the Contact workflow. Webhook consumption, analytics, readiness, and\nbroad multi-domain planning are outside this Skill.\n\n## Contract-first workflow\n\n1. Match only the selected operations above to their exact method, path,\n   parameters, request schema, responses, and descriptions in `openapi.md`.\n   Treat `operationId` as an identifier, not an SDK method. Use raw HTTP shapes\n   or an SDK artifact/version already confirmed in the project.\n2. For definition creation, preserve required `name`, `label`, and `objectType`;\n   the pinned enum contains only `CONTACT`. Preserve the exact source patterns\n   and lengths without “correcting” or anchoring them. Definition update changes\n   only `label` and/or `description` in the declared request shape.\n3. For property creation, preserve required `name`, `label`, and `type`, and the\n   declared types `STRING`, `NUMBER`, `TIMESTAMP`, and `URL`. Property update\n   changes only `label` and/or `description`; changing a property's name or type\n   is not an allowlisted update behavior. Treat delete as high risk: identify\n   the exact definition/property pair and stop before any external execution.\n4. Before ingestion, require an already-defined `eventName` and validate event\n   property names and values against the confirmed definition. The source says\n   NUMBER accepts numeric values with up to one decimal, TIMESTAMP accepts epoch\n   milliseconds, and URL accepts strings beginning with `http://` or `https://`.\n   Do not infer coercion, undeclared-property handling, schema evolution, or\n   server-side validation behavior beyond the pinned descriptions.\n5. Consume a Contact handoff artifact rather than looking up or changing a\n   contact. Accept either a confirmed opaque contact ID for `objectId` or a\n   confirmed contact phone number for `contactPhoneNumber`, together with its\n   provenance. Choose one association form as project policy; the OpenAPI says\n   the phone number is an alternative but does not define precedence when both\n   fields are present. If the handoff is missing or supplies both without an\n   explicit project decision, stop instead of resolving identity here.\n6. Keep `occurTime` as RFC 3339 when supplied. The source says the current time\n   is used when omitted, but does not define whose clock, timezone normalization,\n   or replay semantics. Preserve omission intentionally and test supplied and\n   omitted branches with a fake clock where project code needs deterministic\n   behavior.\n7. Treat a documented HTTP `200` as synchronous acceptance/success for the\n   selected endpoint only. For event ingestion, the source declares no response\n   body, event ID, processing state, callback, query operation, ordering rule,\n   or downstream-completion guarantee. Never label an accepted occurrence as\n   processed, delivered, or completed.\n8. All seven external operations are mock-only in this workflow. Treat a timeout\n   or lost response from create, update, delete, or send as an ambiguous outcome.\n   Never replay automatically. Any idempotency key, outbox identity, deduplication\n   ledger, retry budget, or reconciliation process is project-owned architecture\n   unless a separate authoritative contract confirms it.\n\n## Illustrative ingestion shape\n\nThis is documentation only; do not execute it:\n\n```http\nPOST <YCLOUD_API_BASE_URL>/event/events\nX-API-Key: <YCLOUD_API_KEY>\nContent-Type: application/json\n\n{\"eventName\":\"<DEFINED_EVENT_NAME>\",\"objectId\":\"<CONFIRMED_CONTACT_ID>\",\"occurTime\":\"<RFC3339_TIME>\",\"properties\":{\"<DEFINED_PROPERTY>\":\"<SYNTHETIC_VALUE>\"}}\n```\n\nUse `contactPhoneNumber` instead of `objectId` only when that is the confirmed\nContact handoff artifact. Do not put a real key, contact, phone number, event, or\ncustomer property in examples, fixtures, logs, or generated artifacts.\n\n## Outcome requirements\n\nAdapt the result to planning, implementation, or evaluation and make these\nitems explicit:\n\n1. **Matched contract** — source hash, selected operation IDs, exact methods and\n   paths, parameters, request/response schemas, and description-only rules.\n2. **Lifecycle versus ingestion** — definition/property changes and occurrence\n   submission remain distinct in architecture, handlers, permissions, and tests.\n3. **Contact handoff** — record whether the input is a confirmed opaque contact\n   ID or confirmed contact phone number, its provenance, and any project-owned\n   choice when both could exist; perform no Contact lookup or mutation.\n4. **Acceptance boundary** — distinguish endpoint `200` from unconfirmed\n   downstream processing or completion and preserve unknown future fields.\n5. **Safety** — trusted-server placement, placeholder authentication, mock-only\n   transport, high-risk delete stop, timeout ambiguity, and no automatic replay.\n6. **Tests** — exact routing and schemas; name/type constraints; CONTACT-only\n   definition handling; update field allowlists; property-value validation;\n   Contact artifact branches; supplied/omitted occurrence time; empty-body `200`;\n   `404` lifecycle fixtures; ambiguous timeout/no replay; and proof of no network.\n7. **CANNOT** — real API calls or credentials, Contact resolution/mutation,\n   undocumented property coercion/precedence, safe replay or exactly-once claims,\n   downstream status/completion, analytics, callbacks, guessed SDK methods, and\n   unlisted errors or operations.\n8. **Handoff** — send contact creation, retrieval, normalization, or identity\n   choice to Contact; consume only its confirmed artifact. Return to Architect\n   with capability-row status, artifacts, tests/results, accepted-versus-final\n   evidence, unknowns, and outgoing handoffs.\n\n## Safety and source priority\n\nUse the pinned OpenAPI source first, these derived references second, and this\nworkflow third. Keep source facts, observed runtime evidence, and project policy\nvisibly separate. No local implementation authorization permits a network call\nor external side effect.\n"
}

SHA-256 of public snapshot: 025150813f8e690e52c7a930c8a2cfd96e5c935882b82a3ac89deb5a0a4b905c