Docs/skills v5 temp - #482
Open
raj-dubey1 wants to merge 75 commits into
Open
Conversation
Adds ui-kit/angular/llms-angular-v5.mdx — a machine-readable, Angular-v5-scoped routing index of all 91 v5 pages as .md twins, for AI coding agents. Mirrors the shape of ui-kit/react/llms-react-v7.mdx (branch docs/react-v7-feature-guides). - Unlisted, NOT hidden: omitted from docs.json navigation so it never shows in the human sidebar, but still built, served as a .md twin, and indexed. Using `hidden: true` would auto-apply noindex and drop it from search + the global llms.txt, which defeats the purpose. docs.json is deliberately untouched. - Scoped to v5 only; the 2.0/, 3.0/ and v4/ trees are excluded so agents are never routed at dead API surfaces. - Angular-specific framing the React index has no equivalent for: kebab-case selectors, @input() rather than props, content-projection/TemplateRef rather than render props, and env config in src/environments/environment.ts. Also fixes four content defects surfaced while building the index: - api-reference/formatter-config-service.mdx, api-reference/ rich-text-editor-service.mdx and guides/rich-text-formatting.mdx shipped with NO frontmatter at all despite being in docs.json navigation, so they rendered untitled. Adds title/description per house style (see api-reference/chat-state-service.mdx) and drops the two leading H1s that would now duplicate the frontmatter title. - overview.mdx "AI Integration Quick Reference" listed peer deps as @cometchat/chat-sdk-javascript + dompurify, missing @cometchat/cards-angular@^1.0.0 which @cometchat/chat-uikit-angular@5.1.0 added. Verified against the published package. NOT fixed here, needs an owner decision: the same accordion claims Angular "v18, v19, v20, v21, v22" but the published peer range at 5.1.0 is @angular/core ">=17.0.0 <22.0.0" — v22 is excluded (install hard-fails with ERESOLVE) and v17 is supported but undocumented. Either the docs or the peer range is wrong; that is a support-policy call, not a typo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…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)
…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)
…ent pages Every value is read from the kit's own component declarations (@cometchat/chat-uikit-angular 5.1.0), so the accordion cannot drift from the shipped API — regenerate after a kit bump rather than hand-editing. Schema follows #466 but adapted for a UI component: its SDK rows (Key methods, Listeners registered) become Selector / Key inputs / Key outputs / View slots. Import and Selector are separate rows because the exported class name and the template selector differ, and confusing them is a known failure mode. Bubbles get different Mounting/Prerequisites/Constraints rows: the message list renders them when a matching message arrives, so telling an author to add one to imports[] would be wrong guidance. notification-feed.mdx is left untouched — its hand-authored accordion carries per-input types, defaults and automaticBehaviors that cannot be generated from type declarations, and a generated table would be a regression.
… 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)
…dex (#446 shape) Follows the shape landed for React in #446. The point is what it removes: no prop dump, so an agent can scan the accordion and only read on if what it needs is listed. Props/Events/Customization become anchors into the page's own sections — all 99 verified to resolve. Adds rows that are not derivable from type declarations and are where composition actually goes wrong: Primary output, Stitching, Automatic behaviour (what the kit already does, so it is not hand-rolled). Authored for the 12 mountable surfaces; bubbles get the short form since you never mount them. Mechanical rows (component, selector, CSS root class, imports) come from the kit's own declarations and its stylesheets — 71 of 81 selectors have a verifiable root class. notification-feed.mdx preserved: its hand-authored accordion is richer than anything generatable here.
…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>
…ents-overview, conversations
Every change verified against the public API surface of the CometChatUIKitSwift
5.1.19 xcframework (the artifact github.com/cometchat/cometchat-uikit-ios pins,
sha256 a0f19887…). Nothing here is inferred from prose or from another page.
components-overview.mdx
- Removes the "Composite Components" section and every reference to
CometChatMessages / CometChat{Users,Groups,Conversations}WithMessages. These
are v4 components; 5.1.19 contains none of them (0 occurrences in the public
.swiftinterface, no ObjC @interface, absent from the source tree). The page
was actively RECOMMENDING them as the quick-integration path.
- Replaces them with the host-composed pattern the clean recipe pages already
teach: a list component + your own chat screen (MessageHeader + MessageList
+ MessageComposer), linking to ios-conversation / ios-one-to-one-chat /
ios-tab-based-chat rather than duplicating them.
- Rewrites "Configurations": MessageHeaderConfiguration, MessageListConfiguration
and MessageComposerConfiguration do not exist in v5 either — that whole section
described the v4 pass-config-into-a-composite model. Now shows per-instance
configuration with verified API: set(user:), set(controller:), set(subtitleView:),
set(emptyView:), set(errorView:), placeholderText, hideBackButton.
- Re-roots the hierarchy diagram at YourNavigationController / MessagesVC so the
ownership boundary is explicit.
- AI Quick Reference: compositeComponents -> a `composition` block that positively
states no composite ships and names the three parts. An agent reading only that
block now gets the right answer instead of a phantom.
conversations.mdx
- Six styles + onSearchClick are public VARS, not set(label:) methods. Converted
to property assignment: conversations.avatarStyle = …, .badgeStyle, .dateStyle,
.receiptStyle, .statusIndicatorStyle, .typingIndicatorStyle, .onSearchClick.
- CometChatMentionTextFormatter and CometChatURLTextFormatter do not exist. The
kit ships CometChatTextFormatter and CometChatMentionsFormatter (plural) only —
there is no URL formatter at all, so the example no longer implies one.
- Custom empty state: the API takes a UIView, not a closure. Now assigns
emptyStateView (inherited from CometChatListBase) with set(emptyView:) noted as
the builder equivalent, plus emptyStateTitleText/emptyStateSubTitleText for the
keep-the-default case.
- CometChatMessages -> your own MessagesVC, with user/group passed from
conversation.conversationWith.
- AI Quick Reference slot names: tailView -> trailView, loadingStateView ->
loadingView, and emptyStateView/errorStateView retyped as UIView rather than
() -> UIView.
Both pages now pass the docs-vs-kit API check with zero findings.
Ref: cometchat-skills DOCS-BACKLOG G12 / features.ios-v5.json IOS-DOCS-001.
CometChatSearch's documented API diverged furthest from the shipped component.
Every replacement below is taken from the 5.1.19 public .swiftinterface.
Removed — these do not exist on CometChatSearch:
set(onError:) / set(onEmpty:) failures and empty results are VIEWS, not
callbacks: set(errorView:), set(emptyView:),
errorStateTitleText, errorStateSubTitleText
set(conversationsRequestBuilder:) no request builder at all; scope with
set(messagesRequestBuilder:) set(searchIn:) + set(searchFilters:initialFilter:),
or user/group for a single conversation
set(initialView:) no pre-search view API exists — section removed
rather than left describing something unbuildable
set(leadingViewForMessage:) the ForMessage granular slots do not exist. The
set(titleViewForMessage:) only message-level slot is set(listItemViewForMessage:)
set(subtitleViewForMessage:) (plus the per-media variants). The granular slots
set(trailingViewForMessage:) exist for CONVERSATIONS only, as assignable
properties: leading/title/subtitle/tailViewForConversation
Documented correctly for the first time:
SearchScope = .conversations | .messages
SearchFilter = .messages | .conversations | .unread | .groups | .photos | .videos
| .links | .documents | .audio
AI Quick Reference (the block agents read first) had nine wrong entries. Fixed:
dropped the two request builders, onBack/onError/onEmpty, and hideNavigationBar/
hideBackButton/hideReceipts — CometChatSearch inherits UIViewController, NOT
CometChatListBase, so it has none of the list-base chrome. Added the five
per-media listItemViewFor* slots that were missing, and marked
onConversationClicked/onMessageClicked as assignable properties.
Also replaced the CometChatMessages composite references (IOS-DOCS-001) with the
host-composed MessagesVC, and repointed an itemView cross-reference from
CometChatMessages to CometChatMessageList.
search.mdx now passes the docs-vs-kit API check with zero findings.
Running total across ui-kit/ios: 19 pages / 76 findings -> 17 pages / 55 findings.
…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>
…, thread pattern All three verified against the shipped 5.1.19 .swiftinterface and the docs themselves, not taken on trust. BLOCKING — message-header.mdx: the example passed a closure to set(options:), but CometChatMessageHeader declares func set(options: [CometChatPopupMenu.MenuItem]?) -> CometChatMessageHeader i.e. the ARRAY directly. The closure-taking set(options:) overloads belong to Conversations / Users / Groups / GroupMembers, each returning their own option type — the header has no such overload, so the example could not compile. Now builds the two MenuItems (init is title:icon:action:, confirmed) and passes [viewProfileOption, muteOption]. Comment added naming why the header differs. P1 — groups.mdx: the Actions table listed `onSelectedItemProceed` twice; the replacement row was added without removing the pre-existing one. Dropped the stale duplicate, kept the row that names the multi-select context. P1 — message-list.mdx (2 sites): thread-opening pushed MessagesVC() and called .set(user:) / .set(parentMessage:) on it. ios-conversation.mdx defines MessagesVC with only `var user` / `var group` and no setters at all, so our own pages contradicted each other. Switched both to the pattern guide-threaded-messages.mdx already teaches: ThreadedMessagesVC() with `parentMessage` assigned as a property. MessagesVC is the root-conversation VC, not a thread host. Re-compiled all three pages against the real framework: 135 fences, 0 remaining failures of the reported classes. The 2 residual groups.mdx errors are the pre-existing CometChatGroupOption(id:title:icon:backgroundColor:onClick:) label mismatch — untouched by this PR and tracked with the wider backlog. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…MessageSent The v6 Events page kept the subscription boilerplate but lost the per-event list that v4 and v5 both carry, so a reader could see how to attach a listener but not what there was to listen for. - restores all seven CometChatMessageEvents entries - documents the emit direction: a message sent with CometChat.send*Message rather than through CometChatMessageComposer must emit ccMessageSent, or an already-mounted CometChatMessageList never shows it (CometChat does not deliver a client its own sends over the real-time listener, so the list only picks them up on its next fetch - invisible when a chat screen is opened fresh each time, visible as soon as a list stays mounted) - notes the MessageStatus name collision: ccMessageSent takes the core constants enum, the barrel exports a different enum of the same name, so the import needs a prefix - for overriding as well as emitting - adds the missing flutter/material import to the listener example Snippets compiled against cometchat_chat_uikit 6.1.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ompose and bump version numbers to 6.0.6
…sure types Raj's review on #477: the Quick Reference accordion was corrected but the human-readable "Custom View Slots" table below it still carried the old names, so an agent reading the full page picks up slots that do not exist. Verified each against the shipped 5.1.19 .swiftinterface and master-v5 source rather than taken on trust — one of them did not hold: tailView -> trailView CometChatConversations exposes set(trailView:) taking a closure over Conversation. `public var tailView: UIStackView` DOES exist, but on a different type, so the old row was not simply a typo. loadingStateView -> loadingView CometChatListBase (which Conversations inherits) declares `loadingView`; `loadingStateView` appears nowhere in source. emptyStateView () -> UIView is a UIView you ASSIGN, not a closure. errorStateView () -> UIView same — set(errorStateView: UIView). That last row is a FOURTH instance of the same defect, not in the review: the three Raj listed all shared the closure-vs-property confusion, and errorStateView sat in the same table with the same wrong shape. Also renamed the stale `### tailView` section heading to `### trailView` — its body already used set(trailView:) correctly, so heading and code disagreed. No inbound #tailview anchors exist. Re-compiled the page against the real framework: 50 fences, 0 slot-name errors. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The v6 Flutter pages documented 150 props across the twelve component tables. The widgets actually expose 494. An agent reading these pages either invented a prop name that would not compile or missed a capability the kit already ships and hand-rolled it. Tables are now generated from the pinned cometchat_chat_uikit 6.1.0 and each prop is verified against the analyzer before being listed, so nothing here is a guess. - 150 -> 494 documented props across 12 pages - 127 existing hand-written descriptions preserved; only type and default were taken from source, so no editorial work was lost - 23 documented props REMOVED - the analyzer reports them as undefined on the widget (showBackButton/placeholder on Search, disableTypingIndicator and hideUserStatus on MessageHeader, title and hideMessageComposer on ThreadedHeader, and others). Same defect class as the earlier thread/search signature fixes - 2 genuine type corrections: MessageHeader.backButton is a WidgetBuilder, not a Widget; Conversations.disableSoundForMessages is nullable Only the widget's own table was touched. Filter, style and option-visibility tables on the same pages describe request builders and style objects and were left alone. 158 rows land with no description - neither the page nor the kit's /// comments had one. Those are listed as a writing worklist; filling them in on the kit fields is preferable, since the generator harvests those comments. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…istener removal From an inventory of barrel-exported members that appear nowhere in the docs. events.mdx: - NEW Call Events section. The page had none at all, so ccOutgoingCall, ccCallAccepted, ccCallRejected and ccCallEnded were undiscoverable along with addCallEventsListener/removeCallEventsListener - Message Events: onFormMessageReceived, onSchedulerMessageReceived, onCustomInteractiveMessageReceived - Conversation Events: ccUpdateConversation, with the override in the example - UI Events: requestComposerFocus, lockBottomPadding, unlockBottomPadding connection-status.mdx: - removeConnectionListener documented; the page explained how to add a connection listener and never how to remove one - fixed the snippet's own typo, addConnctionListener -> addConnectionListener Every signature compiled against cometchat_chat_uikit 6.1.0 and cometchat_sdk 5.0.6: the four call events, the three message callbacks, ccUpdateConversation and the three UI events were all implemented against their real mixins in a probe that analyzes clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found by the new docs-grounding linter: cometchat-flutter-v6-customization asserted that CometChatTheme is now only a mergeThemeExtensions helper, and the docs never mentioned the method - a RULES.md 20 violation that predates the linter and that nothing would have caught. Documented rather than labelled as a stopgap, because the claim is correct and the API is genuinely useful: assigning extensions: replaces whatever an ancestor ThemeData provided, so theming a subtree silently drops inherited extensions unless you merge. CometChatTheme holds no palette of its own; the helper is the whole class. Snippet compiled against cometchat_chat_uikit 6.1.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Docs/android llms indexes
fix(ios): correct v5 UI Kit docs against the shipped 5.1.19 kit
docs(react-native): AI-agent docs layer — scoped LLM indexes, Quick References, and kit-vs-docs fixes (ENG-38205)
docs(ui-kit/angular): Angular v5 skills docs — LLM index + AI Integration Quick References (ENG-38204)
docs(android): Update UI Kit v6 docs to 6.0.5
Added CLI Docs
Added AI Integration references
Docs/react v7 feature guides
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
Flutter was the only platform with none. On the skills-v5-temp base, react has 128 Quick References and 3 llms indexes, android 112/2, angular 81/1, react-native 56/2, ios 34/2 - and flutter 0 and 0. This closes the index half. Structure and conventions follow the reference PRs for the same feature: #446 (React v7), #466 (JS SDK), #471 (Angular v5), #476 (React Native). Unlisted rather than hidden, for the reason those PRs give: in Mintlify hidden auto-applies noindex, which would drop the page from search and from the auto global llms.txt - and the whole point is that an agent can discover it. Not registered in docs.json, same as every prior index. ui-kit/flutter/llms-flutter-v6.mdx 70 links, all 54 UI Kit pages sdk/flutter/llms-flutter-v5.mdx 58 links, all 52 SDK pages Both are 100 percent page coverage with zero dead links, verified by resolving every href against the tree. The Platform rules section is the part that carries real weight, and every claim in it was verified against cometchat_chat_uikit 6.1.0 rather than recalled: - TWO barrels with different surfaces. Chat widgets do not resolve from the calls barrel and vice versa, so a screen showing both imports both. This is the most common Flutter-specific compile failure. - Lists need a bounded box or layout throws at render, not at build. - Kit widgets paint their own surface; the app ThemeData does not reach inside. - Theming is ThemeExtension, and registering on only one of light/dark silently leaves the other on kit defaults. - v5's CometChatUIKit.getDataSource() is gone; v6 uses MessageTemplateUtils. - Custom message types need addTemplate, not templates - templates only registers the bubble and the message is filtered out before it can render, with no error. A hand-rolled MessagesRequestBuilder does not help because the list always overrides uid/guid/types/categories on it. - Messages sent with CometChat.send*Message must emit ccMessageSent or a mounted list never shows them. - SDK: onSuccess AND onError are both required - compile-checked, omitting onError is missing_required_argument. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ent pages Flutter had 0 of these while react has 128, android 112, angular 81, react-native 56 and ios 34. This closes the UI Kit half. Format follows the reference PRs (#446, #466, #471, #476): an Accordion straight after the frontmatter, a Field/Value table, and rows that let an agent decide whether the page is worth opening at all. Generated from the compiler-verified prop tables rather than hand-written, so every prop named here provably exists on the widget and the row cannot drift from the kit on the next release. 35 in-page anchors, all resolving. Two rows are Flutter-specific and are the reason a generic template would not have done: - Import carries the RIGHT BARREL per widget. Calling widgets resolve only from cometchat_calls_uikit.dart, so call-buttons, incoming-call, outgoing-call and call-logs also get an explicit Barrel row saying so. Importing a calling widget from the chat barrel is the most common Flutter compile failure and no other platform has this split. - Layout warns that list widgets fill their parent and need an Expanded or a sized box, because the failure is an unbounded-height throw at render rather than a build error. Plus the two traps found by building on the kit: message-list carries the addTemplate-not-templates rule, and message-composer carries the ccMessageSent requirement for messages sent outside it. Classification is by TYPE, not name, after three passes got it wrong: messagesRequestBuilder ends in Builder but is data, hideThreadView ends in View but is a bool toggle, headerView is a HeaderFooterBuilder typedef with neither Widget nor Function in its name, and onError is typed OnError? so only the on-plus-capital convention identifies it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ree broken snippets fixed Completes the Quick Reference set for Flutter: 14 UI Kit pages landed earlier, 38 SDK pages here - the same count React Native shipped. Key methods and Key classes are extracted from each page's OWN dart fences and ranked by how often the page uses them, so the rows describe what the page actually teaches rather than a generic API list. Every extracted method was then put to the analyzer, and that is what turned up the snippet bugs below. 263 links and reference anchors, all resolving. The Constraints row carries the one thing true of nearly every call on this platform and that no Promise-based SDK's docs can say: onSuccess and onError are BOTH required, and awaiting the call alone gives you nothing to act on. Three phantom methods the pages documented, none of which exist on CometChat: - login-listeners: addLoginListener -> addloginListener. The SDK really does spell it with a lowercase l while removeLoginListener uses a capital L, so the page's snippet could not compile. Added a note, because the inconsistency is surprising enough that a reader will assume the doc is the typo. - reactions: removeMessageReactionListener -> removeMessageListener. The page registers a MESSAGE listener and then removed a reaction listener that has never existed; reaction events arrive through the message listener. - receive-messages: getUnreadMessageCountForUser does not exist on Flutter at all - there is no per-user variant, only ForAllUsers and ForGroup. Replaced the two pseudo-code snippets (they were positional, the real API is named parameters) with getUnreadMessageCountForAllUsers plus a map lookup. markAsUnread was flagged too but is correct in place: it appears in upgrading-from-v4-guide only as a note that v5 removed it. Worth noting these survived the earlier 90-to-0 audit because that gate ran over ui-kit pages only; the SDK pages have never been compile-checked. All three replacements compile against cometchat_sdk 5.0.6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…te at sdk pages The 90-to-0 audit ran over ui-kit pages only. Pointing the same Tier-2 gate at sdk/flutter found six kit-API errors; two were correct-as-written and four were real. reactions.mdx was written against an API that does not exist: - message.getReactions() -> message.reactions. getReactions() exists only on internal request/API classes, never on BaseMessage. Also .reactions is non-nullable, so no null-aware access is needed. - MessageReaction is not a class in this SDK. ReactionRequest.fetchNext returns List<Reaction>, so the loop variable and the updateMessageWithReactionInfo parameter are both Reaction. Fixed the two loops, the prose, and the helper snippet. delivery-read-receipts.mdx: markConversationAsDelivered and markConversationAsRead each take TWO positional arguments (conversationWithId, conversationType) plus required onSuccess/onError. Both snippets passed a single Conversation object, which cannot compile. Replaced with the id plus CometChatConversationType form. Correct as written, left alone: the two upgrading-from-v4-guide errors are Before-v4 snippets demonstrating removed APIs, exactly like upgrading-from-v5 on the ui-kit side. That page needs the same --exclude the ui-kit gate already gives its migration page. After the fixes: 52 files, 163 fences, 139 analyzed, 0 kit-API errors. 24 fences still parse in no shape and are NOT checked - a real coverage gap on this page set, not a pass. Every replacement compiles against cometchat_sdk 5.0.6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…Kit pages Correcting an earlier claim. I said the Quick Reference set was closed after the 14 component pages; rechecking against the platforms in the reference PRs shows it was not. Measured on CURRENT-version pages only - earlier counts were inflated by v4/v5 archive subdirectories that git grep matched recursively: ui-kit/react-native 56 of 56 sdk/react-native 44 of 54 ui-kit/ios 34 of 52 sdk/ios 52 of 61 ui-kit/android 33 of 62 sdk/android 46 of 55 ui-kit/react 29 of 40 ui-kit/flutter 14 of 54 <- lowest of any platform React Native has one on every single UI Kit page, guides and hubs included, so component-only coverage was not the convention. This takes flutter to 54 of 54. Non-component pages get page-appropriate rows rather than a fixed schema, which is what the other platforms do: guides name Key widgets, Init and Related; theming names the mechanism and its constraints; hub pages route. Classes and methods are extracted from each page's own fences and ranked by use, with a fallback to inline code spans for the seven hub pages that carry no fences at all - a stub block on those would have been worse than none. Six pages carry a hand-written row for something no extraction can know: theme-introduction and component-styling explain that a kit widget paints its own surface so the app ThemeData never reaches inside; message-template carries the addTemplate-not-templates rule; customization-datasource records that getDataSource is gone in v6; events carries the ccMessageSent requirement; and upgrading-from-v5 notes its Before snippets are v5 and are meant not to compile. 122 links and anchors across the 54 blocks, all resolving. Fence gate still clean at 355 analyzed, 0 kit-API errors. sdk/flutter stays at 38 of 52 by design: the 14 without a block are conceptual and hub pages, which #476 deliberately left alone on React Native for the same reason. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the known gap this PR shipped with. Every prop row on the twelve component pages now carries a description; there are zero "—" cells left. CometChatMessageList 64 CometChatSearch 35 (was 35 of 35 empty) CometChatGroupMembers 34 CometChatUsers 25 The descriptions are not written into the pages by hand. They come from /// comments added to the kit fields themselves in cometchat-team/chat-uikit-flutter#581, and the table generator harvests them - so the docs pick up future edits on the next run instead of drifting from the kit. That PR takes the kit to 1033 of 1033 constructor fields documented across 81 widgets, so the same regeneration will fill descriptions well beyond these twelve pages once it lands. Tables stay pinned to the published 6.1.0 API. Only descriptions were taken from the newer source; no field was added, removed or retyped, so the pages continue to describe the version people actually have. Existing hand-written descriptions were left alone - only cells reading "—" were touched. One thing worth noting for anyone regenerating: the harvest keeps the whole /// comment when it fits a table cell rather than cutting at the first sentence. Cutting lost the half that mattered on the props that most need it - addTemplate read "Merges templates with the defaults." and dropped the clause explaining that it also folds the type into the fetch filter, which is the entire reason to prefer it over templates. Fence gate clean at 355 analyzed, 0 kit-API errors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-api-corrections docs(flutter): AI-agent docs layer — scoped LLM indexes, Quick References, and kit-vs-docs fixes
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
6 participants
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.
Description
Related Issue(s)
Type of Change
Checklist
Additional Information
Screenshots (if applicable)