fix(docs): correct SDK accessor paths for membership methods (membership → user client)#486
fix(docs): correct SDK accessor paths for membership methods (membership → user client)#486hrishikesh-p wants to merge 1 commit intomainfrom
Conversation
D1: assign-roles.mdx Node.js — scalekit.membership → scalekit.user
D2: assign-roles.mdx Python — scalekit_client.memberships → scalekit_client.users
+ fix import: memberships_pb2 → users_pb2
D3: assign-roles.mdx Java — scalekitClient.memberships() → scalekitClient.users()
D4: remove-users-from-organization.mdx Node.js — scalekit.users → scalekit.user
Found by Phase 4 docs audit (specs/proto-audit/results-docs.md)
WalkthroughUpdates SDK documentation across Node.js, Python, Go, and Java code examples to replace Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
✅ Deploy Preview for scalekit-starlight ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx (3)
30-50: 🧹 Nitpick | 🔵 TrivialError handling is inconsistent across language examples.
The Go and Java examples include error handling, but the Node.js and Python examples do not. Per coding guidelines, code examples should "show both success path AND error path." Consider adding basic error handling to Node.js and Python for consistency.
♻️ Suggested improvements for Node.js and Python
Node.js:
// Use case: Remove user during offboarding workflow triggered by HR system +try { await scalekit.user.deleteMembership({ organizationId: 'org_12345', userId: 'usr_67890' }) +} catch (error) { + console.error('Failed to remove user:', error.message) + throw error +}Python:
# Use case: Remove user during offboarding workflow triggered by HR system +try: scalekit_client.users.delete_membership( organization_id="org_12345", user_id="usr_67890" ) +except Exception as e: + print(f"Failed to remove user: {e}") + raise🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx` around lines 30 - 50, The Node.js and Python snippets lack error handling; update the Node example around scalekit.user.deleteMembership to show both success and error paths (e.g., await call wrapped in try/catch, logging success and calling console.error or rethrowing on failure) and update the Python example around scalekit_client.users.delete_membership to wrap the call in try/except with a success path and an error log/raise; keep examples minimal and consistent with the Go/Java style used elsewhere while referencing scalekit.user.deleteMembership and scalekit_client.users.delete_membership.
170-180: 🧹 Nitpick | 🔵 TrivialAdd a "what's next" signal at the end of the page.
Per coding guidelines, every page must end with a clear forward direction—either a
next:frontmatter link, a<LinkCard>, or an explicit paragraph pointing the reader forward. This page ends with the dashboard removal steps but provides no guidance on what to do next (e.g., link to re-adding users, viewing audit logs, or related user management tasks).♻️ Suggested addition after the Steps block
</Steps> + +## Related resources + +- [Add users to organizations](/authenticate/manage-organizations/add-users-to-organization/) — Re-add users who were previously removed +- [User management overview](/authenticate/manage-organizations/) — Learn about organization membership managementAlternatively, add a
next:link in the frontmatter if there's a logical next page in the user management journey.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx` around lines 170 - 180, This page (remove-users-from-organization.mdx) ends after the Steps block with no forward direction; add a clear "what's next" by either adding a next: frontmatter entry pointing to the logical follow-up (e.g., the add-users or organization-audit-logs page) or appending a short paragraph or a <LinkCard> after the Steps that links to related user-management pages (suggest: "Add users to organization" and "View organization audit logs") so readers have an explicit next step.
67-75:⚠️ Potential issue | 🔴 CriticalJava accessor should use
users()(plural), notuser().The Java code on line 70 uses the singular form
scalekitClient.user(), but all other Java examples in the documentation—includingassign-roles.mdx,add-users-to-organization.mdx, andcustom-user-attributes.mdx—use the plural formscalekitClient.users(). The commit message for this PR explicitly lists correcting Java accessors frommemberships()tousers()(plural), confirming that line 70 is an exception that needs to be fixed.Proposed fix
// Use case: Remove user during offboarding workflow triggered by HR system try { - scalekitClient.user().deleteMembership("org_123", "user_456"); + scalekitClient.users().deleteMembership("org_123", "user_456"); } catch (Exception e) { log.error("Failed to remove user: " + e.getMessage()); throw e; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx` around lines 67 - 75, The Java example uses the wrong accessor: replace scalekitClient.user() with the plural scalekitClient.users() so the call becomes scalekitClient.users().deleteMembership("org_123", "user_456");—update the example to use the users() accessor to match other docs and the intended API surface.src/content/docs/authenticate/authz/assign-roles.mdx (3)
34-34: 🧹 Nitpick | 🔵 TrivialAdd descriptive alt text to this image as well.
Suggested fix
- +🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/authz/assign-roles.mdx` at line 34, The image markdown "" lacks alt text; update that line by adding a concise, descriptive alt string (e.g., "! [Default organization member role diagram](`@/assets/docs/assign-roles/default_org_member_role.png`)") that describes the image content and purpose so screen readers and accessibility tools can convey the image meaning; edit the markdown in assign-roles.mdx where the image is referenced to include the alt text.
27-27: 🧹 Nitpick | 🔵 TrivialAdd descriptive alt text to images.
This image lacks alt text, which violates accessibility guidelines. While not part of this PR's changes, consider adding descriptive alt text.
Suggested fix
- +As per coding guidelines: "All images MUST have descriptive alt text — not empty
![]()syntax."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/authz/assign-roles.mdx` at line 27, Add descriptive alt text for the image referenced in assign-roles.mdx by replacing the empty markdown alt text syntax  with a meaningful description (e.g., ); ensure the alt string succinctly describes the image content and purpose for accessibility compliance.
345-358:⚠️ Potential issue | 🟡 MinorGo accessor should use
User()method, notMembership().Line 353 uses
scalekitClient.Membership().UpdateMembership(), but all other Go examples in the documentation consistently usescalekitClient.User()for membership operations (CreateUserAndMembership, DeleteMembership, ResendInvitation, etc.). This should be corrected to match the SDK's actual accessor pattern and documentation consistency.Proposed fix
- result, err := scalekitClient.Membership().UpdateMembership(ctx, updateRequest) + result, err := scalekitClient.User().UpdateMembership(ctx, updateRequest)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/authz/assign-roles.mdx` around lines 345 - 358, The call uses scalekitClient.Membership().UpdateMembership but the SDK examples use the User() accessor for membership operations; change the invocation to scalekitClient.User().UpdateMembership(ctx, updateRequest) and keep the same UpdateMembershipRequest construction (variables: validationResult.Data, updateRequest, scalekitClient, UpdateMembership) so the code matches the SDK accessor pattern used by CreateUserAndMembership, DeleteMembership, and ResendInvitation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@src/content/docs/authenticate/authz/assign-roles.mdx`:
- Line 34: The image markdown
"" lacks alt text;
update that line by adding a concise, descriptive alt string (e.g., "! [Default
organization member role
diagram](`@/assets/docs/assign-roles/default_org_member_role.png`)") that
describes the image content and purpose so screen readers and accessibility
tools can convey the image meaning; edit the markdown in assign-roles.mdx where
the image is referenced to include the alt text.
- Line 27: Add descriptive alt text for the image referenced in assign-roles.mdx
by replacing the empty markdown alt text syntax
 with a
meaningful description (e.g., );
ensure the alt string succinctly describes the image content and purpose for
accessibility compliance.
- Around line 345-358: The call uses
scalekitClient.Membership().UpdateMembership but the SDK examples use the User()
accessor for membership operations; change the invocation to
scalekitClient.User().UpdateMembership(ctx, updateRequest) and keep the same
UpdateMembershipRequest construction (variables: validationResult.Data,
updateRequest, scalekitClient, UpdateMembership) so the code matches the SDK
accessor pattern used by CreateUserAndMembership, DeleteMembership, and
ResendInvitation.
In
`@src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx`:
- Around line 30-50: The Node.js and Python snippets lack error handling; update
the Node example around scalekit.user.deleteMembership to show both success and
error paths (e.g., await call wrapped in try/catch, logging success and calling
console.error or rethrowing on failure) and update the Python example around
scalekit_client.users.delete_membership to wrap the call in try/except with a
success path and an error log/raise; keep examples minimal and consistent with
the Go/Java style used elsewhere while referencing
scalekit.user.deleteMembership and scalekit_client.users.delete_membership.
- Around line 170-180: This page (remove-users-from-organization.mdx) ends after
the Steps block with no forward direction; add a clear "what's next" by either
adding a next: frontmatter entry pointing to the logical follow-up (e.g., the
add-users or organization-audit-logs page) or appending a short paragraph or a
<LinkCard> after the Steps that links to related user-management pages (suggest:
"Add users to organization" and "View organization audit logs") so readers have
an explicit next step.
- Around line 67-75: The Java example uses the wrong accessor: replace
scalekitClient.user() with the plural scalekitClient.users() so the call becomes
scalekitClient.users().deleteMembership("org_123", "user_456");—update the
example to use the users() accessor to match other docs and the intended API
surface.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ad9b296b-9a20-427e-a46f-f0efa3413d45
📒 Files selected for processing (2)
src/content/docs/authenticate/authz/assign-roles.mdxsrc/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdx
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
**/*.mdx
📄 CodeRabbit inference engine (.cursorrules)
**/*.mdx: Use clear, descriptive titles that explain the purpose of the document
Include comprehensive descriptions in frontmatter metadata
Organize content with logical heading hierarchy (H2, H3, H4)
Use tableOfContents property in frontmatter when content has multiple sections
Set appropriate sidebar labels for navigation in frontmatter
Use direct instruction writing style with phrases like 'This guide shows you how to...' and 'Create an authorization URL to...'
Use second person perspective ('your application', 'you receive', 'you must') in documentation
Keep sentences concise, aiming for under 25 words per sentence
Explain the 'why' in documentation with phrases like 'This prevents CSRF attacks by...' or 'Use this to validate that...'
Use action verbs in section headings: 'Store session tokens securely', 'Validate the state parameter', 'Exchange authorization code for tokens'
Use present tense for descriptions: 'Scalekit handles the complex authentication flow', 'The SDK provides methods to refresh tokens'
Use future tense for results: 'This will redirect users to...', 'You'll receive a JWT containing...', 'Scalekit returns an authorization code'
Use transition phrases between sections: 'After the user authenticates...', 'Once the state is validated...', 'Let's take a look at how to...'
Write 1-3 opening paragraphs that explain what users will accomplish, provide context about when/why, preview key concepts, and use direct instructional language
Begin introduction sections with a clear statement of what the guide covers and explain the problem being solved
Use collapsible sections in introduction for sequence diagrams, video demonstrations, data models, and JSON examples with appropriate icons
Use numbered format within Steps component:1. ## Titlewith all step content indented with exactly 3 spaces
Use action-oriented headings in step-by-step guides within Steps components
Include code examples in all 4 languages (Node.js, Python, Go, Java) within Steps co...
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
⚙️ CodeRabbit configuration file
**/*.mdx: You are reviewing Scalekit developer documentation written in MDX
(Astro + Starlight framework). Apply ALL of the following checks:Frontmatter
titleMUST be ≤ 60 characters and clearly state what the page does.descriptionMUST be ≤ 160 characters, action-oriented, unique per page.sidebar.labelMUST be present and ≤ 30 characters.sidebar.orderMUST be set on every page that lives inside a section
with siblings, to enforce the journey order in sidebar.config.ts.- Flag any missing
prev/nextlinks on pages that are clearly
part of a sequential flow (e.g., quickstart → implement-login →
complete-login → manage-session → logout).Voice & Style (CLAUDE.md standards)
- Voice: confident, direct, collaborative, instructional.
- Person: second person only ("you", "your application"). Reject "we",
"our", "the developer", "the user".- Tense: present tense for descriptions; imperative mood for instructions.
- Flag weasel words: "simply", "just", "easy", "straightforward",
"obviously", "of course", "note that".- Flag passive voice constructions where active voice is clearer.
- Headings must be sentence case, not Title Case (except proper nouns).
- No heading should end with a colon or period.
Content structure
- How-to guides MUST contain numbered
<Steps>(Starlight component).- Concept pages MUST NOT contain numbered steps — concepts explain, not instruct.
- API reference pages MUST list parameters in a table with Name / Type /
Required / Description columns.- Every page MUST end with a clear "what's next" signal — either a
next:frontmatter link, a<LinkCard>, or an explicit paragraph
pointing the reader forward in the sidebar journey.Code examples
- ALL code examples that show SDK usage MUST include all four language
tabs: Node.js, Python, Go, Java — using<Tabs syncKey="tech-stack">.- SDK variable names are STRICTLY:
scalekit(Node.js),
scalekit_client(Python),scalekitClient(Go), ...
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
**/*.{yml,yaml,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/browsecentral-labels.mdc)
**/*.{yml,yaml,md,mdx}: BrowseCentral labels should be maximum 3-5 words - keep concise but add context when needed
BrowseCentral labels should be action-oriented - start with verbs when possible
BrowseCentral labels should be specific and clear - add context when simple labels are ambiguous
BrowseCentral labels should be outcome-focused - describe what users accomplish and the context
BrowseCentral labels should use 'Action + Object' pattern (e.g., 'Invite users', 'Restrict sign-up', 'Set up SCIM')
BrowseCentral labels should use feature names (e.g., 'Enterprise SSO', 'Passwordless quickstart')
BrowseCentral labels should describe task completion (e.g., 'Run migrations', 'Migrate auth', 'Merge identities')
BrowseCentral labels should include specific context when needed (e.g., 'Configure Scalekit MCP server', 'Validate incoming API requests')
BrowseCentral labels should use integration context when applicable (e.g., 'Build MCP auth with your existing auth system')
BrowseCentral labels should avoid instructional prefixes: 'How to', 'Guide to', 'Implement', 'Configure', 'Learn', 'Understand'
BrowseCentral labels should avoid verbose phrases: 'Step-by-step guide', 'Complete tutorial', 'Detailed documentation'
BrowseCentral labels should avoid weak verbs: 'Enable', 'Allow', 'Provide', 'Support'
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/deno-docs-style.mdc)
**/*.{md,mdx}: Use sentence case for all titles and headings in MD/MDX documentation
Keep page titles short and descriptive (3–7 words when possible) in MD/MDX documentation
Use outcome-focused headings that describe results, not categories (e.g., 'Run a script' not 'Scripts')
Avoid gerunds in headings when an imperative works - prefer 'Configure proxies' over 'Configuring proxies'
Keep sidebar labels concise (1–3 words), use sentence case, and focus on outcomes or objects
Use sentence case in sidebar labels without punctuation
Set frontmatter title in sentence case with a clear outcome; description in one sentence (≤160 chars); sidebar.label as shorter form of title; enable tableOfContents on longer pages
Start documentation pages with a one-paragraph overview explaining what the page covers and when to use it
Present the primary use case (80% path) first in documentation, with edge cases later
Use numbered steps for task-focused sections in documentation, with each step beginning with a verb
Break up long documentation sections with subheadings every 3–6 paragraphs
Use asides for important notes, tips, cautions, and references in documentation
Provide runnable, minimal code examples that work as-is in documentation
Prefer CLI-first examples and show file layout when helpful in documentation
Label code blocks with titles for context (e.g., 'Terminal', 'main.ts') in documentation
Keep code block annotations brief and purposeful - annotate only what matters
Use consistent variable and file names across a documentation page
Use descriptive link text in documentation (e.g., 'See permission flags' not 'click here')
Prefer relative links for internal documentation pages and include anchors for section references
Reference APIs consistently using backticks for code, file names, CLI flags, and endpoints
Use backticks for code, file names, CLI flags, and endpoints in documentation
Use lists for options and features in documentation; tables only when comparisons are cleare...
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
src/content/docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
src/content/docs/**/*.{md,mdx}: Product-based documentation (MCP Auth, Agent Auth, Full Stack Auth, Modular SCIM, Modular SSO) MUST follow a journey-focused approach. Each product represents a developer's journey toward implementing authentication in their projects.
Proactively address common setup and configuration problems. Keep code examples simple, self-contained, and exportable.
Use imperative for procedures: 'Install', 'Create', 'Run', 'Configure', 'Test'. Front-load the action and start sentences with the verb or key concept.
Explain why when useful. Briefly justify non-obvious steps. Prefer examples over theory; show the common path first and link to details.
Every page MUST include frontmatter with at least:title(≤60 characters),description(≤160 characters), andsidebar.label(1-3 words). Usesidebar.orderonly when navigation ordering matters. Useprev/nextfor sequential guides; useseeAlsofor related guides. EnabletableOfContentsfor longer pages with multiple major sections.
Opening paragraphs (1-3) MUST state what users will accomplish, when/why they need it, and preview the workflow using direct instructional language
The Steps component requires a single continuous ordered list. Steps must start at column 0 with no leading spaces. Continuation content (images, text) must be indented with exactly 3 spaces. Sub-bullet lists use 3 spaces with no blank line before bullets. No blank line immediately after Steps opening tag.
Documentation must be organized into logical sections (FSA, SSO, Directory/SCIM, Connect, M2M, Guides, Reference) with proper sidebar configuration and navigation structure
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
src/content/docs/authenticate/**/*.mdx
⚙️ CodeRabbit configuration file
src/content/docs/authenticate/**/*.mdx: This page lives in the primary authentication section.
- If it's a quickstart or step-based guide, it MUST use
<Steps>.- Auth method pages (passwordless, social, SSO, passkeys) MUST include
a brief "when to use this" section before the implementation steps.- Any reference to tokens (idToken, accessToken, refreshToken) MUST
clarify: what it contains, its lifetime, and how to use it securely.- The FSA quickstart (
authenticate/fsa/quickstart.mdx) is the
canonical entry point — no other page should duplicate its 5-step
install→redirect→callback→session→logout structure.
Files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
🧠 Learnings (14)
📓 Common learnings
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-03T10:47:47.162Z
Learning: Applies to **/*.{md,mdx} : Use exact SDK variable names: Node.js: `scalekit`, Python: `scalekit_client`, Go: `scalekitClient`, Java: `scalekitClient` in all documentation and code examples
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/native-app.mdx:72-179
Timestamp: 2026-02-02T05:55:51.251Z
Learning: In the `src/content/docs/authenticate/fsa/multiapp/` directory, the multi-app authentication documentation (native-app.mdx, single-page-app.mdx, web-app.mdx, overview.mdx) currently uses conceptual shell/curl examples instead of multi-language SDK code examples because the Scalekit SDKs have not yet been built/updated for multi-app functionality. Once the SDKs are ready, these files should be updated to include all 4 languages (Node.js, Python, Go, Java) using `<Tabs syncKey="tech-stack">`.
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: .cursorrules:0-0
Timestamp: 2026-01-13T12:46:55.260Z
Learning: Keep documentation accurate and up-to-date with product changes, updating examples when APIs change
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: .cursorrules:0-0
Timestamp: 2026-01-13T12:46:55.260Z
Learning: Applies to **/*.mdx : Use consistent SDK variable naming: Node.js='scalekit', Python='scalekit_client', Go='scalekitClient', Java='scalekitClient'
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: .cursor/rules/documentation-guide.mdc:0-0
Timestamp: 2026-01-13T12:48:11.566Z
Learning: Applies to **/*.{md,mdx} : Update code examples when APIs or behaviors change
📚 Learning: 2026-03-03T10:47:47.162Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-03T10:47:47.162Z
Learning: Applies to **/*.{md,mdx} : Use exact SDK variable names: Node.js: `scalekit`, Python: `scalekit_client`, Go: `scalekitClient`, Java: `scalekitClient` in all documentation and code examples
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-01-30T18:18:50.883Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/manage-apps.mdx:31-49
Timestamp: 2026-01-30T18:18:50.883Z
Learning: In all Scalekit documentation files (MDX), treat the terms 'Applications', 'Single Page Application (SPA)', 'Native Application', and 'Web Application' as proper nouns and preserve their capitalization in headings and body text. Ensure these terms remain capitalized even when used in sentence case or within prose.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-04T12:47:16.544Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 412
File: src/content/docs/dev-kit/tools/scalekit-dryrun.mdx:1-23
Timestamp: 2026-02-04T12:47:16.544Z
Learning: In scalekit-inc/developer-docs, the MDX frontmatter field order is required only when the sidebar configuration points to a directory (for auto-generation). If the sidebar.config.ts references a specific file path, the order field is not required. Apply this check to all MDX files under src/content/docs: if a file contributes to an auto-generated sidebar (directory path), ensure order is present; if it’s linked to a concrete file, order can be omitted. Use sidebar.config.ts to determine whether a given MDX file falls under directory-based vs file-specific sidebar references.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-25T08:57:12.201Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/quickstart.mdx:2-10
Timestamp: 2026-02-25T08:57:12.201Z
Learning: In Scalekit developer-docs (Astro Starlight), do not auto-suggest adding tableOfContents in frontmatter unless the user explicitly overrides the default behavior. The default enables tableOfContents with minHeadingLevel 2 and maxHeadingLevel 3. Only set tableOfContents when you want to customize heading levels or disable it entirely; otherwise omit it for other docs.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-25T13:04:27.491Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:9-17
Timestamp: 2026-02-25T13:04:27.491Z
Learning: Allow page-level CSS overrides in MDX frontmatter (head: style) for readability and engagement, even if it customizes typography beyond defaults. This applies to per-page UX decisions, including heading sizes and style tweaks, but keep overrides purposeful, accessible, and within the repository's design guidelines. Use these overrides sparingly and document the rationale for maintainability.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-03-05T11:29:08.125Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 463
File: src/content/docs/agent-auth/providers.mdx:35-73
Timestamp: 2026-03-05T11:29:08.125Z
Learning: In src/content/docs/agent-auth/providers.mdx, the Card components intentionally use icon=" " (a space) to render consistent colored boxes since some Starlight icon names resolve to icons and others do not. Do not flag icon=" " as a placeholder issue for this file; treat this as a deliberate UX choice specific to this MDX page and avoid raising a placeholder-icon warning here.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-03-09T07:27:56.794Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 469
File: src/content/docs/guides/integrations/scim-integrations/azure-scim.mdx:95-107
Timestamp: 2026-03-09T07:27:56.794Z
Learning: Do not enforce the 3-space indentation rule for Steps component content as a hard style rule in MDX files under src/content/docs/**/*.mdx. Only flag/rectify it if it causes visible rendering problems in the UI. Otherwise, allow current formatting; apply this rule only when rendering issues are observed and document any fixes.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-03-09T07:32:38.426Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 467
File: src/content/docs/sso/guides/sso-user-attributes.mdx:108-148
Timestamp: 2026-03-09T07:32:38.426Z
Learning: In MDX code samples under src/content/docs (and similar conceptual snippets in scalekit-inc/developer-docs), when an example's sole purpose is to show how to access a specific value (e.g., reading JWT claims after token validation), omit error/non-happy-path handling to keep the snippet focused. Do not flag the absence of error paths in narrowly scoped conceptual snippets.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-25T03:34:41.147Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:31-31
Timestamp: 2026-02-25T03:34:41.147Z
Learning: In MDX files, import { Code } from 'astrojs/starlight/components' only if the MDX content actually uses the <Code> component. If the file uses only fenced code blocks (```), the import is not required. Apply this guideline to all MDX files (e.g., src/content/docs/**/*.mdx) to avoid unnecessary imports and reduce bundle size.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-25T18:41:00.639Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 446
File: src/content/docs/authenticate/m2m/api-auth-quickstart.mdx:78-78
Timestamp: 2026-02-25T18:41:00.639Z
Learning: Preserve full URLs inside code comments in MDX code blocks (bash/python/js) when the URLs are part of copyable examples. Do not flag these in code examples. Use relative paths in prose and hyperlinks within MDX; only enforce relative paths for markdown prose links, not for URLs inside code comments.
Applied to files:
src/content/docs/authenticate/manage-organizations/remove-users-from-organization.mdxsrc/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-01-13T12:46:55.260Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: .cursorrules:0-0
Timestamp: 2026-01-13T12:46:55.260Z
Learning: Applies to **/*.mdx : Use consistent SDK variable naming: Node.js='scalekit', Python='scalekit_client', Go='scalekitClient', Java='scalekitClient'
Applied to files:
src/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-02T05:55:51.251Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/native-app.mdx:72-179
Timestamp: 2026-02-02T05:55:51.251Z
Learning: In the `src/content/docs/authenticate/fsa/multiapp/` directory, the multi-app authentication documentation (native-app.mdx, single-page-app.mdx, web-app.mdx, overview.mdx) currently uses conceptual shell/curl examples instead of multi-language SDK code examples because the Scalekit SDKs have not yet been built/updated for multi-app functionality. Once the SDKs are ready, these files should be updated to include all 4 languages (Node.js, Python, Go, Java) using `<Tabs syncKey="tech-stack">`.
Applied to files:
src/content/docs/authenticate/authz/assign-roles.mdx
📚 Learning: 2026-02-10T05:32:59.967Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 424
File: public/api/scalekit.scalar.json:3451-3457
Timestamp: 2026-02-10T05:32:59.967Z
Learning: In scalekit-inc/developer-docs, the file public/api/scalekit.scalar.json is a generated OpenAPI artifact; reviewers should avoid direct edits. For inconsistencies (e.g., the /api/v1/permissions "type" query param description vs. enum), handle short-term via release/PR notes and track long-term fixes in the generator or source templates rather than modifying the generated JSON.
Applied to files:
src/content/docs/authenticate/authz/assign-roles.mdx
🔇 Additional comments (3)
src/content/docs/authenticate/authz/assign-roles.mdx (3)
254-260: LGTM!The Node.js accessor path is correctly updated to
scalekit.user.updateMembership, using the singularuserproperty as documented.
300-310: LGTM!The Python import path and accessor are correctly updated:
- Import from
scalekit.v1.users.users_pb2- Accessor uses
scalekit_client.users.update_membership(plural)
395-398: LGTM!The Java accessor path is correctly updated to
scalekitClient.users().updateMembership, using the pluralusers()method as documented.
Summary
assign-roles.mdxandremove-users-from-organization.mdxmembership/membershipssub-client does not exist — methods live on theuser/usersclientFindings fixed (D1–D4 from Phase 4 docs audit)
authenticate/authz/assign-roles.mdxscalekit.membership.updateMembership→scalekit.user.updateMembershipauthenticate/authz/assign-roles.mdxusers_pb2;scalekit_client.memberships→scalekit_client.usersauthenticate/authz/assign-roles.mdxscalekitClient.memberships().updateMembership→scalekitClient.users().updateMembershipauthenticate/manage-organizations/remove-users-from-organization.mdxscalekit.users.deleteMembership→scalekit.user.deleteMembership(singular)Correct accessor reference
scalekit.user(singular property)scalekit_client.users(plural)scalekitClient.User()(singular method)scalekitClient.users()(plural method)Test plan
scalekit.user(singular)scalekit.v1.users.users_pb2and accessor isscalekit_client.usersscalekitClient.users().updateMembership(...)🤖 Generated with Claude Code
Summary by CodeRabbit