-
Notifications
You must be signed in to change notification settings - Fork 2.9k
CLAUDE.md: OpenAPI.json maintenance
#22326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -462,6 +462,23 @@ export class UmbDocumentActionButton extends LitElement { | |
| - Remove unused imports, functions, variables | ||
| - Clean up console.logs before committing | ||
|
|
||
| ### Feature Parity with Core Equivalents | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we will have to rethink or remove this paragraph. We are currently trying to make agents treat the documentation files as the source of truth and only secondarily look for similar implementations in the codebase. This paragraph might end up confusing the agent 🤔 My suggestion is to add specific documentation for the area this should cover. Please see how it is already done for other client-side concepts and extensions: concept and pattern explanations in the documentation, followed by guided implementation steps in a skill. |
||
|
|
||
| When implementing a new component that mirrors an existing core or sibling implementation (e.g. a new collection action alongside document/media/member equivalents), do a side-by-side comparison against the core version before considering it done. | ||
|
|
||
| **Checklist**: | ||
|
|
||
| 1. **Full API surface**: Read the reference implementation's controller/API usage line by line. Every method call, callback, and property access on controllers in the reference must have a counterpart in the new implementation — don't cherry-pick only the obvious ones. | ||
| 2. **Error handling**: Match the core's error handling pattern (e.g. `.catch(() => {})` on `execute()` calls) to prevent unhandled promise rejections. | ||
| 3. **Type hierarchy**: Before defining new interfaces, search for existing base types (e.g. `UmbNamedEntityModel` vs `UmbEntityModel`) that already declare the fields you need. Use the most specific base. | ||
| 4. **UI consistency**: Check CSS from sibling implementations (e.g. `max-height` on scroll containers, icon fallbacks like `?? 'icon-document'`). | ||
| 5. **Context-appropriate strings**: Don't reuse localization keys from another domain (e.g. `create_noDocumentTypes` in an elements context). Either create a new key or use only the inline fallback text. | ||
|
|
||
| **Core components to compare against** (common patterns): | ||
| - Collection create actions: `src/packages/core/collection/action/create/collection-create-action.element.ts` | ||
| - Entity create option modals: `src/packages/core/entity-action/common/create/modal/entity-create-option-action-list-modal.element.ts` | ||
| - Document/media/member equivalents in their respective `src/packages/` directories | ||
|
|
||
| ### Patterns to Avoid | ||
|
|
||
| **Don't**: | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a perfect fit for a skill, and not something that is needed in general knowledge.
Should we also include steps to generate the client-side SDK?