← YCloud Developer KitCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to YCloud Developer Kit
Snapshot Sep 30, 2026 · 23:15 UTC · version 0.7.9
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Design, implement locally, or evaluate YCloud customer unsubscribe creation, lookup, listing, and deletion. Use for opt-out records and message-eligibility evidence; exclude Contact CRUD, message sending, provider delivery status, and real API operations.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 303
},
{
"relative_path": "references/openapi.md",
"size_in_bytes": 18162
},
{
"relative_path": "references/runtime.md",
"size_in_bytes": 13692
},
{
"relative_path": "references/shared/integration-boundaries.md",
"size_in_bytes": 8401
},
{
"relative_path": "references/shared/pagination-contract.md",
"size_in_bytes": 3494
}
],
"name": "ycloud-unsubscribers",
"skill_md_contents": "---\nname: ycloud-unsubscribers\ndescription: Design, implement locally, or evaluate YCloud customer unsubscribe creation, lookup, listing, and deletion. Use for opt-out records and message-eligibility evidence; exclude Contact CRUD, message sending, provider delivery status, and real API operations.\n---\n\n# YCloud Unsubscribers\n\nFor `unsubscriber-list`, read\n[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md)\nwith the generated OpenAPI/runtime references.\n\nDesign or implement contract-aware handling for the five Unsubscriber operations\nin the pinned reference. Use synthetic customers and a mock transport only.\nNever call YCloud, inspect credentials or customer data, or mutate a real\nunsubscribe record.\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 or Contact handoff for scope, deliverable, mutation,\ncapability IDs, project seams, confirmed customer identity, and expected\nevidence. Without one, default to focused read-only guidance unless the user\nexplicitly requests local implementation. Local-write authorization permits\nrequest/response models, adapters, handlers, mock fixtures, policy-evidence\nmappers, and no-network tests in the scoped project. Create and delete remain\nmock-only, and even GET operations must use mocks in this workflow.\n\nAfter this Skill is selected, read the generated [OpenAPI\ncontract](references/openapi.md) and reviewed [runtime\nbehavior](references/runtime.md). For retry, idempotency, error translation, or\nproduction architecture, also read\n`references/shared/integration-boundaries.md`. If either local reference is\nmissing, stale, or inconsistent with its recorded source hash or operation\ncount, report drift and stop rather than reconstructing the contract from\nmemory.\n\n## Exact operation scope\n\n| Intent | Method and path | operationId |\n| --- | --- | --- |\n| Create an unsubscribe record | `POST /unsubscribers` | `unsubscriber-create` |\n| Delete by composite identity | `DELETE /unsubscribers/{customer}/{channel}` | `unsubscriber-delete-by-customer-and-channel` |\n| List unsubscribe records | `GET /unsubscribers` | `unsubscriber-list` |\n| List all records for one customer | `GET /unsubscribers/{customer}` | `unsubscriber-list-all-by-customer` |\n| Retrieve by composite identity | `GET /unsubscribers/{customer}/{channel}` | `unsubscriber-retrieve-by-customer-and-channel` |\n\nContact discovery and updates belong to a Contact capability; message request\nconstruction, `filterUnsubscribed`, submission, retrieval, and message status\nbelong to `ycloud-whatsapp-messages`. Authentication belongs to\n`ycloud-api-authentication`; broad multi-domain planning belongs to\n`ycloud-integration-architect`. Webhook processing, keyword configuration,\nmarketing consent design, and non-WhatsApp channel behavior are out of scope.\n\n## Contract-first workflow\n\n1. Match only the five allowlisted operations. Report exact method, path,\n `operationId`, parameters, body, response schema, and documented status.\n Treat operation IDs and `x-*` fields as identifiers or codegen hints, not SDK\n method names or additional behavior.\n2. Model `(customer, channel)` as the unique Unsubscriber identity. Do not use\n `regionCode`, `source`, or `createTime` as identity. For the documented\n `type=PHONE_NUMBER`, require `customer` to remain an E.164 string, never a\n number, and URL-encode it as one path segment (including the leading `+`).\n The only currently documented channel is lowercase `whatsapp`; do not\n normalize an unknown future channel into it. Consume a Contact handoff only\n when it supplies a confirmed customer value and its identity provenance;\n never infer an E.164 number from a contact name or unrelated identifier.\n3. For create, send required `type`, `customer`, and `channel`; `regionCode` is\n optional. Preserve the documented `PHONE_NUMBER` and `whatsapp` values, but\n decode future `type`, `channel`, and `source` values through an explicit\n unknown branch. Preserve unknown response properties. Do not interpret the\n response `source` prose as an additional create/delete guarantee.\n4. For `unsubscriber-list`, preserve `page` as 1-based with range 1-100,\n `limit` as 1-100, defaults of 1 and 10, optional `includeTotal`, optional\n `pageAfter`, and exact dotted filters `filter.customer`, `filter.channel`,\n and `filter.regionCode`. Parse the successful response as the merged Page\n envelope with required `offset`, `limit`, `length`, resource `items`, optional\n `total`, and optional `cursor`; `offset` is response metadata. Treat `total`\n as optional and present only when\n requested. Cursor traversal must use the returned opaque `cursor.after`\n unchanged and stop when it is absent. Add project-owned safety guards for an\n empty page, a repeated cursor, and a configured page/item budget. Do not\n synthesize a cursor from offsets, infer completion from `total`, or silently\n switch/mix page and cursor strategies beyond behavior confirmed by the\n contract.\n5. Keep `GET /unsubscribers/{customer}` distinct: it returns an array, not an\n `UnsubscriberPage`, and documents `404`. Composite retrieve and delete also\n document `404`; list and create declare only `200`. Use reviewed runtime\n behavior for generic errors and do not invent endpoint-specific statuses.\n6. Keep provider contract separate from local policy. Confirmation UX, local\n consent rules, audit retention, eligibility caches, retry budgets, and\n reconciliation are application-owned. A timeout or lost response to create\n or delete has an ambiguous outcome. The contract defines no general\n idempotency key, so never replay either mutation automatically. Honor\n `Retry-After` before later traffic without treating it as replay authority.\n7. Use placeholders such as `<YCLOUD_API_KEY>` and `<E164_CUSTOMER>` and fully\n synthetic fixtures. Keep credentials server-side and hand credential work to\n Authentication. Do not read `.env`, secret stores, production logs, live\n Contacts, Unsubscribers, or Messages.\n\n## Eligibility-policy evidence\n\nAn exact composite retrieve, a customer-wide list, or a deliberately complete\nand defensively traversed filtered list can produce an evidence object for the\nMessages capability. Include the queried customer/channel, match or no-match,\noperation and source provenance, observation time/freshness, pagination\ncompleteness, and unknown-value warnings. A local cache entry or incomplete\npage traversal is not authoritative negative evidence.\n\nThis evidence is an input to the application's message-eligibility policy. It\ndoes not submit or suppress a message by itself and is not a YCloud/WhatsApp\nfinal status. Never label it sent, accepted, queued, failed, delivered, read, or\nprovider-rejected. Messages owns request-time policy (including whether to use\n`filterUnsubscribed`) and provider response/webhook interpretation.\n\n## Validation and evidence\n\nFor local implementation, add no-network tests for exact routes, required body\nfields, E.164 string preservation and path encoding, composite identity,\narray-versus-complete-page-envelope response shapes, all list parameters and dotted filters,\noptional total, opaque cursor continuation, absent/repeated cursor termination,\nempty pages, configured traversal budgets, `404` handling, standard errors and\nrequest IDs, and unknown fields/enum values. Add mutation tests for explicit\nauthorization, ambiguous outcomes, and proof of no automatic replay. Mocks must\nprove that no network client is invoked.\n\nReturn these sections, adapted to the requested deliverable:\n\n1. **Matched contract** — source hash, selected operations, exact request and\n response shapes, and description-only constraints.\n2. **Construction or implementation** — placeholder design, changed artifacts,\n and project facts still needed.\n3. **Contract versus policy** — provider facts separated from local consent,\n eligibility, cache, pagination-budget, retry, and audit choices.\n4. **Tests and evidence** — synthetic cases, actual no-network results, and\n pagination completeness.\n5. **CANNOT** — live calls, credentials/customer data, unsupported operations,\n guessed SDK methods, automatic mutation replay, unconfirmed idempotency, or\n provider send/delivery/final-status claims.\n6. **Handoff** — consume confirmed customer identity evidence from Contact;\n produce provenance-bearing eligibility-policy evidence for\n `ycloud-whatsapp-messages`; return capability status, artifacts, tests,\n unknowns, and outgoing handoffs to Architect. Do not claim a Contact exists\n merely because an Unsubscriber exists, or that an eligible result guarantees\n a message will be accepted or delivered.\n\n## Safety stop\n\nYCloud Provider API calls are prohibited during Skill execution, including\nnominally read-only GETs. All mutations are mock-only. Stop before any request\nthat would use a real API key, customer identifier, Contact, Unsubscriber,\nMessage, or other live YCloud data.\n"
}SHA-256 of public snapshot: 073744e25338591435526f35577b4c72a89b1284f274ef4813c86b4ad5b579c0