docs(react-native): AI-agent docs layer — scoped LLM indexes, Quick References, and kit-vs-docs fixes (ENG-38205) - #476
Open
suraj-chauhan-cometchat wants to merge 14 commits into
Open
Conversation
…e docs (ENG-38205)
RN-G14 — the Podfile requirement that BREAKS EVERY FIRST BARE-RN INSTALL.
The UI Kit is a Swift pod depending on SPTPersistentCache and
DVAssetLoaderDelegate, neither of which defines a module, so on a
static-library build — the React Native default — `pod install` fails
outright. Both official sample apps already carry the two modular_headers
lines; the integration page never mentioned them. Added, with the verbatim
error so it is searchable, plus the LANG=en_US.UTF-8 note (CocoaPods dies
with an opaque Encoding::CompatibilityError when the locale is unset, and
the trace points at Ruby rather than at the real cause).
RN-G8 — accordion coverage 91% -> 100% (55/55 pages).
Added the AI Integration Quick Reference to call-features,
calling-integration, campaigns, core-features and extensions. Each carries
the trap for its area, not filler: core-features states reactions and
mentions are CORE in v5 so enabling the legacy dashboard extensions is
unnecessary; extensions states most render themselves once enabled so
emitting client code duplicates them; calling-integration states that
INSTALLING the package is the enable switch (there is no
setCallingEnabled() in RN) and that simulators capture no camera or mic.
RN-G11 — the events page named five APIs that do not exist as exports.
CometChatMessageEvents -> MessageEvents (un-prefixed) · CometChatCallEvents
-> CallUIEvents · CometChatGroupEventListener -> CometChatGroupsEvents
(plural) · CometChatConversationEventListener -> CometChatConversationEvents
· CometChatUserEventListener -> CometChatUIEvents. All five replacements
verified present in the kit's public exports, and ccUserBlocked confirmed to
live in CometChatUIEvents.ts before accepting that last mapping.
RN-G9 (partial) — three docs-side import bugs fixed:
mentions-formatter-guide imported TextStyle from the kit; it is a
react-native type. Now imported from 'react-native'.
call-logs imported CallLogRequestBuilder from the CHAT sdk. It lives in the
CALLS sdk and is only reachable as CometChatCalls.CallLogRequestBuilder —
wrong on both counts.
ai-assistant-chat-history imported ChatHistoryStyle purely to annotate an
object literal; dropped, the type is inferred.
NOT fixed here — these are KIT bugs, not doc bugs. OutgoingCallConfiguration,
EnterKeyBehavior, SingleLineMessageComposerConfiguration and CometChatReceipt
are all DOCUMENTED public API that src/index.ts does not export. The docs
describe the intended behaviour correctly; the barrel is incomplete. Deleting
those sections would remove documented capability, and EnterKeyBehavior is a
STRING ENUM so a literal will not type-check either — there is no doc-side
workaround. Each needs a one-line export in the kit, which is a different
repo and a public-API decision.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…s schema
The Quick Reference is the FIRST thing an agent reads when a skill fetches a
page, so it has to carry that page's whole contract — not just a name list.
The JavaScript SDK already does this (median 10 rows across its 20 documented
pages); React Native's were a name list or a bare code snippet.
13 hot-path pages upgraded to the same field schema — Package · Import ·
Key methods · Key classes · Primary output · Prerequisites · Constraints ·
Listeners registered · Request builder · Related.
RN SDK pages with a real contract table: 6 -> 16. Median rows: 5 -> 8.
The two fields that were missing everywhere are the ones that matter most,
and every value is verified against the installed .d.ts:
Primary output — is it a Promise, what does it resolve to, what does it
reject with. Without it an agent does not know to await, or what to catch.
e.g. deleteMessage resolves a TOMBSTONE not void; getLoggedinUser returns
User | NULL and null is the normal no-session answer; markAsRead is
untyped; addMessageListener returns VOID, not a subscription.
Constraints — what the API will NOT do, which a page cannot express by
omission. e.g. there is no sendCardMessage() (card/interactive messages
are receive-only, and an agent will infer one from the three send*
methods that do exist); login is VARIADIC AND UNTYPED so TypeScript
catches nothing; startTyping/endTyping return void so do not await them;
blockUsers takes an ARRAY; reactions are core in v5 with no extension to
enable; ban is half a round trip and needs BannedMembersRequestBuilder +
unbanGroupMember shipped alongside it.
Existing code snippets are preserved beneath each table — the table answers
"what is the contract", the snippet answers "what does it look like".
Zero phantom methods: every CometChat.* named in the new tables verified
present in the SDK catalog.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
… JS SDK's schema" This reverts commit 604e898.
…g index
Reverted the previous commit — it deepened the Quick References toward the JS
SDK's full contract schema, which is the wrong direction.
The Quick Reference's job is ROUTING, not documentation. Pages are long. An
agent scans the accordion to decide "is the method I need on this page?" — if
yes it opens the page, if no it moves to the next one. Making the accordion
long forces the agent to read a long accordion instead of a long page, which
saves nothing. Compact and COMPLETE beats rich and partial.
So the real defect was never depth — it was MISSES. A method a page covers
but does not list is invisible: the agent scans, does not see it, and moves
on, even though the answer was right there.
receive-messages was the worst — 7 methods covered but unindexed, including
getMessageDetails and ALL FOUR unread-count variants. Anyone asking "how do
I get the unread count" would have skipped the page that answers it.
Fixed both shapes:
2 pages had a table whose Key Methods row was incomplete -> completed
30 pages had a SNIPPET-ONLY accordion with no index at all -> added a
compact Key Methods + Key Classes index above the existing snippet
SDK pages with a method index: 6 -> 36. Routing misses: 16 -> 0.
init/login/logout/getLoggedinUser are deliberately excluded from non-setup
pages: they appear in nearly every example as boilerplate, and indexing them
everywhere would make the index useless. The index must say what a page is
ABOUT, not what its example happens to call.
Every method verified present in the SDK catalog; the original snippets are
untouched beneath each index.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
…dexes Same fix as the SDK side, applied to the UI Kit: a component a page demonstrates but does not list in its Quick Reference is invisible — the agent scans the index, sees nothing, and moves to the next page even though the answer was there. 15 pages fixed. The biggest was component-styling, which styles 21 components and indexed none of them — anyone asking "how do I style the avatar / badge / action sheet" would have skipped the one page that answers it. Also fixed: components-overview (the component index itself did not list Conversations, MessageHeader or MessageList), the four formatter guides, and four task guides. Scaffolding is deliberately EXCLUDED from pages it is not about, exactly as init/login are on the SDK side. CometChatThemeProvider, CometChatI18nProvider, CometChatUIEventHandler, CometChatUiKitConstants and CometChatUIKit wrap or support nearly every example; indexing them everywhere would stop the index discriminating, which is the one thing it exists to do. Each is kept on the page that IS about it (theme, localize, events, methods, integration). 8 pages are left untouched by design: they use a JSON-format accordion whose `"component"` key already names the page's subject — CometChatConversations on conversations, CometChatMessageList on message-list, and so on. Their apparent "misses" are incidental example usage (an Avatar inside a custom-view sample), not what the page documents. Mutating structured JSON that may be parsed downstream is riskier than the routing benefit. Result: 32 pages were already complete, 15 fixed, 8 correct in a different format. Every component named is verified present in catalogs/rn-v5.json. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
…form The AI Integration Quick Reference is a routing index: the agent scans it to decide whether to open the page. 18 RN pages were carrying a shape that cannot serve that job. UI Kit (14) — replaced the JSON-blob accordion that docs#446 deleted from all 35 React component pages. Those blobs inlined the whole prop contract at 33-120 lines each, so there was nothing left to open the page for. Now a Field/Value table: Component, Package, Import, Data props, Primary output, Other actions, View slots, Styling, Prerequisites, Stitching -- names only, each linking into the section that holds the detail. SDK (4) — ai-agents, delivery-read-receipts, retrieve-group-members and additional-message-filtering carried code dumps instead of the field table their docs#466 twins use. Method and class names verified against the shipped RN SDK, not copied from JS: createUploadFileRequest/uploadAttachments do not exist in the RN SDK, so nothing from JS's upload-files table was reused. Also fixes ccCallFailled -> ccCallFailed in call-buttons, incoming-call and outgoing-call. All three shipped kits (5.3.0, 5.3.2, 5.3.4) emit ccCallFailed; the misspelling would have sent the agent looking for an event that is never fired. The v4 archive still carries it and was left alone. Conceptual pages (overview, key-concepts, rate-limits, upgrading-from-v3, message-structure-and-hierarchy, users-overview) were left untouched: docs#466 deliberately gives their JS twins no Quick Reference at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…References docs#466 puts a consistent ~10-row field set on all 19 JS SDK method pages. Ours had the right table form but a fraction of the rows: Package appeared on 1 page and Import on 0, against 19/19 in the reference PR. Import is the single row an agent most needs to write working code, so its absence defeated the routing index on every SDK page. Adds the three mechanical rows -- Package, Import, Prerequisites -- which carry the same value on every page and need no per-page judgement. Package and Import lead the table, matching #466's row order. setup-sdk and authentication-overview are skipped for Prerequisites: they are themselves the pages the row links to, and must not cite themselves. Still thinner than #466 and tracked separately: Primary output (4/38), Related (5/38), Constraints (0/38) and Full reference (0/38) each need per-page authoring rather than a mechanical fill. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ference on 38 pages Completes the docs#466 field set. Package/Import/Key Methods tell an agent what to call; these four tell it what comes back, what will break, what to read next, and what the returned objects can do. Every return type is read from the shipped RN SDK's CometChat.d.ts, not carried over from the JS PR. That matters -- several are not what the JS docs would suggest: startTyping / endTyping / sendTransientMessage -> void, not Promise connect / disconnect / ping -> void getConnectionStatus -> string, synchronous markAsDelivered / markAsRead -> any, fire-and-forget leaveGroup / deleteGroup / kickGroupMember -> Promise<boolean> transferGroupOwnership / deleteConversation -> Promise<string> An agent that awaits a void return, or expects a message object back from markAsRead, writes code that silently does nothing -- which is exactly what the Primary output row now prevents. Constraints is the anti-hallucination row. send-message states plainly that sendCardMessage() does not exist (verified: 0 occurrences in the SDK; the real send methods are sendMessage, sendMediaMessage, sendCustomMessage, sendDirectMessage, sendGroupMessage, sendInteractiveMessage, sendTransientMessage), because an agent asked to send a card will otherwise invent it by symmetry. Two claims were corrected against the SDK before landing: GROUP_TYPE exposes four constants for three wire values -- PROTECTED and PASSWORD both resolve to "password" -- so create-group and groups-overview now say so rather than listing three types and leaving PROTECTED unexplained. All 143 rows verified: every /sdk/reference anchor resolves to a real heading and every Related link to a real page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ad prop
message-list — new warning under "Filtering Messages". CometChatMessageList
builds its request from the configured data source:
requestBuilder.setTypes(ChatConfigurator.dataSource.getAllMessageTypes());
requestBuilder.setCategories(ChatConfigurator.dataSource.getAllMessageCategories());
so a custom type must be registered for FETCH, not only for render. Overriding
getAllMessageTemplates alone gets a bubble that appears optimistically on send
and vanishes on reload, with no error anywhere. Documents all four required
overrides and the after-login() registration order (login() re-runs
ChatConfigurator.init(), discarding any earlier data source).
This was documented in no RN page and no React page. A real integration lost
hours to it.
users — removed `onBack` from the routing index and the prop list. The kit's
CometChatUsers source contains zero occurrences of it; the callback never fires.
Groups, Conversations, GroupMembers and CallLogs all DO have it, which is exactly
why the claim looked plausible.
Refs AUDIT-094 in the skills pack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit added the render/fetch split to message-list under "Filtering Messages", but left the page's AI Integration Quick Reference unchanged -- so the routing index did not know the page now covered it. That defeats the index's whole purpose. An agent scans the Quick Reference to decide whether a page is worth opening; with no row for custom message types it would conclude the page has nothing and move on, which is the exact failure the new section exists to prevent. Adds a row naming all four required overrides, marking which two are render and which two are fetch, and pointing at the section. Lesson worth keeping: adding a capability to a page is not finished until the routing index announces it. Content the index does not mention is content the agent never reaches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RELEASE_GUIDE_CHAT_SDK.md and react-v6-vs-rn-v5-comparison.md were analysis notes produced while auditing the kit against the docs. They were swept in by an over-broad `git add` in e3f4318 and do not belong on the docs site: neither is referenced by docs.json or any page, so both are orphaned files sitting at the repo root, and a release checklist / a v6-vs-v5 comparison table are not customer documentation. Removing them from the PR. The analysis they hold is already reflected in the work itself -- the comparison drove the RN coverage decisions, and the release notes belong in the SDK repo, not here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ENG-38205 prerequisite. Two unlisted-but-indexed routing indexes for AI coding agents, following the React v7 / Angular v5 / JS SDK v4 precedent: - ui-kit/react-native/llms-react-native-v5.mdx (incl. Task guides (recipes)) - sdk/react-native/llms-react-native-v4.mdx Both cover every page in their directory (redirect stubs excluded) and add a "Platform rules" section for the React Native specifics an agent gets wrong by default: no CSS/DOM, required native peer deps, one screen per route, CLI vs Expo toolchains, and listener cleanup on the SDK side. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first pass listed @gorhom/bottom-sheet + react-native-reanimated as required peers. They are not. Replaced with the list verified against @cometchat/chat-uikit-react-native@5.4.0 and the integration pages, and added the async-storage v3 Android local_repo Gradle gotcha to both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
suraj-chauhan-cometchat
changed the title
…gin API Two gaps in llms-react-native-v5, both found by asking what an agent searching for "add a custom message type" would actually match. 1. NOTHING TO MATCH. The index promises "pick the page for the intent", but every entry was a bare page name. The custom-message-type contract lives on Message List, and no agent scanning a list of component names would ever guess that. The index routed to all 55 pages and still could not answer the question. New "Customization & extensibility" section keyed on the API rather than the page title: DataSourceDecorator, ChatConfigurator.enable, the four required overrides split into render vs fetch, getMessageOptions/getAuxiliaryOptions, CometChatUIEvents. Now greppable by the terms someone would actually search. 2. THE BIGGEST API DIVERGENCE WAS UNSTATED. Platform rules covered CSS, peer deps, Gradle and navigation but never said React's CometChatMessagePlugin / CometChatPluginRegistry DO NOT EXIST here. An agent porting React knowledge emits them and does not compile. Added, with the decorator chain as the replacement and the after-login() registration order. Also carries the docs-gap note: DataSourceDecorator / MessageDataSource / ExtensionsDataSource still have no dedicated RN page (RN-G10). All links verified to resolve. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything React Native needs for the v5 skills pack to route through the docs. Combines what was previously split across #476 and #474 — one change, since the index and the pages it points at only work together.
Structure and conventions follow the reference PRs for the same feature: #446 (React v7), #466 (JS SDK), #471 (Angular v5).
1. Scoped LLM indexes
ui-kit/react-native/llms-react-native-v5.mdxsdk/react-native/llms-react-native-v4.mdxMirrors React's
llms-react-v7.mdxsection-for-section, plus two RN-specific ones — Platform rules — React Native is not the web and Text formatters. Not registered indocs.json: #446, #466 and #471 all leave it untouched, because the index is fetched by URL rather than navigated.2. AI Integration Quick References
The routing index an agent scans to decide whether a page is worth opening.
conversationsandmessage-listwent 120 → 19 lines.Packagewas on 1 page andImporton none — the single row an agent most needs to write working code.Conceptual pages (
overview,key-concepts,rate-limits,upgrading-from-v3,message-structure-and-hierarchy,users-overview) are deliberately left alone — #466 gives their JS twins no Quick Reference either.3. Fixes found by auditing the kit against the docs
Every symbol verified against the shipped RN kit and SDK, never carried over from JS:
ccCallFailled→ccCallFailedoncall-buttons,incoming-call,outgoing-call. All three shipped kits (5.3.0/5.3.2/5.3.4) emitccCallFailed; the misspelling had the agent waiting on an event that never fires.onBackremoved fromusers—CometChatUsers's source contains zero occurrences. Groups, Conversations, GroupMembers and CallLogs all do have it, which is exactly why the claim looked plausible.message-list.CometChatMessageListbuilds its request fromgetAllMessageTypes()/getAllMessageCategories(), so overridinggetAllMessageTemplatesalone renders a bubble that vanishes on reload — no error anywhere. Documented in no RN page and no React page; a real integration lost hours to it.modular_headers, RN-G8 accordion coverage, RN-G9 import corrections, RN-G11 five wrong event API names.Return types come from the SDK's own
CometChat.d.ts— several are not what the JS docs would suggest:startTyping/endTyping/sendTransientMessage/connect/disconnectreturn void,getConnectionStatusis synchronous,markAsDelivered/markAsReadare fire-and-forget.Verification
/sdk/reference/anchor resolves to a real heading; every Related link to a real page; every index link resolves.Still open (owner: docs)
DataSourceDecorator/MessageDataSource/ExtensionsDataSourceremain undocumented end to end. What's added here covers the half that silently breaks builds, not the whole surface.CometChatOngoingCallis exported by the RN kit and documented for React, but no RN page covers it.Supersedes #474.