You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gap analysis (CloudKit JS / Web Services vs openapi.yaml)
A coverage review of openapi.yaml against Apple's CloudKit JS (CloudKit.Database.acceptShares, cloudkitjs.md:804-806) and the Web Services "Sharing Records" reference (webservices.md:1610-1672) confirms this endpoint is entirely unimplemented — there is no records/accept path and no share data model anywhere in the spec (grep -i "share|participant|shortGUID" → none).
What needs to be done
1. New endpoint — acceptShares equivalent: accept a share identified by a shortGUID on behalf of the current (web-auth) user. Add the path + operationId + request/response bodies.
2. New schemas:
Share — the cloudKit.share record model (shortGUID, forRecord/root record, publicPermission, participants, owner, currentUserParticipant).
ShareParticipant — permission, acceptanceStatus, type (see CloudKit.ShareParticipant, cloudkitjs.md:4632-4652).
3. Share-creation keys on the modify request / RecordOperation (openapi.yaml:114-123, 1215-1225): createShortGUID on the record, and for cloudKit.share records forRecord / publicPermission / participants (webservices.md:1612-1658).
Same limitation as noted on #41, restated here so it isn't missed on this endpoint.
No live-service call was made for records/accept, and Apple's archived reference carries no verbatim JSON examples for it. Field names come from the type dictionaries on Types.html and AcceptingShareRecords.html, not from an observed payload. Local .claude/docs/webservices.md omits the endpoint.
acceptShares is a mutating operation, which makes it the higher-risk of the two: a wrong request field name doesn't just mis-decode, it can cause the accept to fail or silently not take effect. I'd gate this on a live call more firmly than records/resolve.
Auth shape worth a second opinion: the operation hard-codes .public(.requires(.webAuth)) and exposes nodatabase: parameter, following the fetchCaller() precedent — Apple fixes the path scope to public and the operation acts on behalf of the current user. That is a deliberately removed choice rather than a silent default, consistent with the no-silent-policy-defaults rule. But if a share can ever be accepted in another scope, that signature would need revisiting, and changing it later is source-breaking.
Suggested gate before release: accept a real share against a live container with middleware logging at .debug, and confirm both that the request is accepted and that the share actually appears in the target database afterward — success status alone won't prove the second part.
Activity
leogdion commentedon May 25, 2026
Gap analysis (CloudKit JS / Web Services vs
openapi.yaml)A coverage review of
openapi.yamlagainst Apple's CloudKit JS (CloudKit.Database.acceptShares, cloudkitjs.md:804-806) and the Web Services "Sharing Records" reference (webservices.md:1610-1672) confirms this endpoint is entirely unimplemented — there is norecords/acceptpath and no share data model anywhere in the spec (grep -i "share|participant|shortGUID"→ none).What needs to be done
1. New endpoint —
acceptSharesequivalent: accept a share identified by ashortGUIDon behalf of the current (web-auth) user. Add the path +operationId+ request/response bodies.2. New schemas:
Share— thecloudKit.sharerecord model (shortGUID,forRecord/root record,publicPermission,participants,owner,currentUserParticipant).ShareParticipant—permission,acceptanceStatus,type(seeCloudKit.ShareParticipant, cloudkitjs.md:4632-4652).3. Share-creation keys on the modify request /
RecordOperation(openapi.yaml:114-123, 1215-1225):createShortGUIDon the record, and forcloudKit.sharerecordsforRecord/publicPermission/participants(webservices.md:1612-1658).4. Share response fields on
RecordResponse(openapi.yaml ~1019-1043):shortGUID,share,publicPermission,participants,owner,currentUserParticipant(webservices.md:1660-1672).Related
records/resolve) depends on the sameShareschema groundwork.Sources/MistKitOpenAPI/— changeopenapi.yamland regenerate via./Scripts/generate-openapi.sh.leogdion commentedon Aug 20, 2026
Moving from the v1.0.0-beta.3 milestone to v1.0.0-beta.4 — work not yet complete.
leogdion commentedon Aug 20, 2026
Verification caveat for #428
Same limitation as noted on #41, restated here so it isn't missed on this endpoint.
No live-service call was made for
records/accept, and Apple's archived reference carries no verbatim JSON examples for it. Field names come from the type dictionaries on Types.html and AcceptingShareRecords.html, not from an observed payload. Local.claude/docs/webservices.mdomits the endpoint.acceptSharesis a mutating operation, which makes it the higher-risk of the two: a wrong request field name doesn't just mis-decode, it can cause the accept to fail or silently not take effect. I'd gate this on a live call more firmly thanrecords/resolve.Auth shape worth a second opinion: the operation hard-codes
.public(.requires(.webAuth))and exposes nodatabase:parameter, following thefetchCaller()precedent — Apple fixes the path scope to public and the operation acts on behalf of the current user. That is a deliberately removed choice rather than a silent default, consistent with the no-silent-policy-defaults rule. But if a share can ever be accepted in another scope, that signature would need revisiting, and changing it later is source-breaking.Suggested gate before release: accept a real share against a live container with middleware logging at
.debug, and confirm both that the request is accepted and that the share actually appears in the target database afterward — success status alone won't prove the second part.🤖 Generated with Claude Code
Add records/resolve and records/accept share operations
Add records/resolve and records/accept share operations
Add records/resolve and records/accept share operations (#41, #42, #428)
leogdion commentedon Aug 28, 2026
Resolved on
v1.0.0-beta.4via #428 (commit 9e6b9d6).records/acceptimplemented asacceptShares(_:).Add records/resolve and records/accept share operations (#41, #42, #428)
v1.0.0 beta.4 (#439)