@maltjoy/mcp-server 0.3.2 → 0.5.0-beta.0

package/dist/doc/zeroheight/components/1398444/change-logs.md

@@ -0,0 +1 @@
+## Change logs

package/dist/doc/zeroheight/components/1398444/content.md

@@ -0,0 +1,149 @@
+Buttons drive action. Their labels must be clear, predictable, and aligned with user intent. Apply these principles to create buttons that are effective and consistent throughout the product.
+
+## Principles
+
+| Principle | Definition |
+| **Recognisable and scannable** | Users should instantly understand what the button does, even when skimming. |
+| **Mobile-first** | Ensure buttons are easily tappable, readable, and clearly labelled on small screens. |
+| **Actionable** | Use active voice and verbs to prompt interaction. |
+| **Predictable** | Clicking a button should never surprise the user. The label must reflect the outcome. |
+| **Terminology alignment** | Use consistent terms across CTAs, page titles, section headers, and labels. |
+## Button structure
+
+- **Use the formula: ****`Infinitive verb + noun`**
+
+Example: `Upload document`, `Send message`, `Delete project`.
+- **Avoid vague verbs like “Click” or “Submit”**
+
+Be specific about the action and object.
+- **Exception: Common UI actions**
+
+Buttons like `Close`, `Cancel`, `Done` can stand alone without a noun, specifically in **secondary buttons.**
+- **When two buttons are paired (e.g., Approve / Decline):**
+
+- Use the full formula on the primary button: `Approve request`
+- Be shorter and more neutral on the secondary: `Decline`
+- **Avoid icons in buttons**
+
+Unless the icon alone is universally understood (e.g., trash can for delete), rely on text. Always add a tooltip on hover to explain the icon (see Tooltip guidelines).
+
+## Usage guidelines
+
+- **Match the title or header**
+
+Reinforce clarity by echoing key terms from titles and headers.
+- **Be specific about transitions**
+
+When users are moving to a new step or context (e.g., from cart to payment), make it clear:
+
+`Continue to payment` instead of just `Next`.
+- **Highlight the user’s top-level intent**
+
+Even if more steps follow, the button should reflect the user’s goal.
+
+Example: `Send proposal` (not `Next`), even if more steps follow.
+- **Secondary CTAs are still actions**
+
+Avoid vague terms like `Maybe later`. Use clear alternatives: `View details`, `Skip step`.
+- **Avoid Yes/No buttons in response to questions**
+
+Use clear descriptive choices:
+
+- Instead of: `Yes / No`
+- Use: `Enable notifications / Keep disabled`
+
+## Tone of voice
+
+- **Stay neutral or instructional**
+
+Avoid "Joy" or persuasion unless in very specific contexts.
+- **The only exceptions:**
+
+- Product tours (first/last steps)
+- Promotional dialogs aiming to convert
+
+Example: `Let’s get started`, `Show me`, `Try for free`
+
+| Types of buttons | User's emotions | Tone of voice | Examples |
+| Conversion button | Curious, engaged, “anxious” | Explicit, slightly joyful, engaging | 🚧 |
+| Confirmation button | Focused, apprehensive | Explicit, positive, relevant | 🚧 |
+| Navigation button | Distracted, hurried | Direct, explicit, reassuring | 🚧 |
+| Display button | Curious, slightly indecisive, possibly frustrated | Explicit, engaging, reassuring | 🚧 |
+| Search button | Curious, engaged, hurried | Direct, engaging, slightly joyful, explicit | 🚧 |
+## Language and grammar
+
+- **Use infinitive verbs**
+
+- ✅ `Create project`
+- ❌ `Project created` or `I create project`
+- **No passive voice**
+
+Users must know who does what.
+
+- ✅ `Send message`
+- ❌ `Message will be sent`
+- Pronouns and articles usage
+
+- In English, avoid pronouns and articles that lengthen the button copy.
+
+- ✅ `Post project`, `Send quote`, `Review application`
+- ❌ `Post my project`, `Send my quote`,` Review their application`
+- **⚠️ In French (FR): **Use pronouns and articles when needed for grammatical correctness.
+
+- For user-owned content: use possessive pronouns (`mon profil`)
+- For Malt-promoted or generic items: use definite/indefinite articles (`un profil`, `le projet`)
+
+## Length & character limits
+
+- **3 words or fewer is ideal**
+
+Shorter buttons are easier to scan.
+- **25 characters max**
+
+Adapt based on layout, but never truncate the content.
+- **If needed, allow wrapping**
+
+If the label is too long (e.g., “Sign up with email address”), let it wrap to a second line.
+
+## Dynamic content
+
+- **As a general rule, avoid dynamic values in button text.**
+- **Do not personalise button text with user or object names. **Too verbose and unpredictable for localisation.
+
+- ❌ `Send quote to Jane Doe`
+- ✅ `Send quote`
+- **Use parentheses for numeric values.**
+
+- ❌ `Delete 6 files`
+- ✅ `Delete files (6)`
+
+## Pattern specifics
+
+### Funnel & step-based flows
+
+- **Use ****`Next`**** and ****`Previous`**** only within linear flows.**
+- **When entering a new step, clarify the destination:**
+
+- ✅ `Continue to payment`
+- ✅ `Review and confirm`
+- **Maintain consistency across steps**
+
+Use the same verb and object when the action is repeated.
+
+### Dialogs & modals
+
+- **Secondary actions should never pressure or guilt users**
+
+- ✅ `Not now`, `Skip step`, `Continue without AI`
+- ❌ `No thanks, I hate saving money`, `I'll waste time without AI`
+- **If confirming a major action, label clearly:**
+
+- ✅ `Delete project brief`
+- ✅ `Cancel subscription`
+
+### Disabled buttons
+
+- **Always explain why a button is disabled**
+
+- Provide a tooltip on hover (or similar UI element)
+- Example: “Upload brief — File must be PDF”

package/dist/doc/zeroheight/components/1398444/description.md

@@ -0,0 +1 @@
+A button is an interactive element that initiates an action or event when clicked or tapped.

package/dist/doc/zeroheight/components/1398444/introduction.md

@@ -0,0 +1,49 @@
+![Button inside the quote ](/uploads/SqFZ-1HwtsXtlqNncLE-2g.png)
+
+## Anatomy
+
+## Type of buttons
+
+| **Variant** | **Purpose** |
+| Main | For the principal call to action on the page. Primary buttons should only appear once per screen (not including the application header, modal dialog, or side panel).  On dialog, we use the main button to finalize the action |
+| Primary | Usually used for miscellaneous actions: the action is important, represents an action to be performed but doesn't represent the main action |
+| Secondary | For secondary actions on each page. Secondary buttons can only be used in conjunction with a primary button. |
+| White | Independent action (not directly related to current user flow) |
+| Ghost | Should be used for the least important actions or use to represent a link |
+## Size
+
+| **Size** | **Height** |
+| LARGE | 64px |
+| MEDIUM | 48px |
+| SMALL | 40px |
+| X-SMAL | 32px |
+| XX-SMALL | 24px |
+## Variants
+
+### Main
+
+### Primary
+
+### Secondary
+
+### Ghost
+
+Ghost button or text button don't have a background
+
+## AI theme
+
+For AI-specific actions
+
+### Main AI
+
+### Primary AI
+
+### Secondary AI
+
+### Ghost AI
+
+### Admin
+
+For admin - Internal use only
+
+## Related

package/dist/doc/zeroheight/components/1398444/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Button",
+  "slug": "button",
+  "category": "components",
+  "component": "VJoyButton",
+  "pageId": 1398444,
+  "pageUid": "1398444",
+  "fetchedAt": "2026-07-15T08:24:45.707Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "Change logs 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/button/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/1398444/usage.md

@@ -0,0 +1,10 @@
+## States
+
+We use 5 states for the button component and each state need to convey a specific affordance.
+
+### Content
+
+- Do: Small contents buttons have a 120px min. width. 
+- Don't: Hug content with tiny contents.
+
+### Combinations

package/dist/doc/zeroheight/components/1423580/change-log.md

@@ -0,0 +1 @@
+## Change log

package/dist/doc/zeroheight/components/1423580/introduction.md

@@ -0,0 +1,17 @@
+## Anatomy
+
+## Component
+
+### Default
+
+The default state (dot and text) should be used on the search and freelancer profiles.
+
+### Dot
+
+The dot state should be used on the pool of freelancers. It always need to be used along with an avatar as in the example below.
+
+## Example
+
+You can see here how you should use the availability dot with an avatar. It should land in the bottom right corner of the avatar.
+
+## Related

package/dist/doc/zeroheight/components/1423580/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Availability",
+  "slug": "availability",
+  "category": "components",
+  "component": "VJoyAvailability",
+  "pageId": 1423580,
+  "pageUid": "1423580",
+  "fetchedAt": "2026-07-15T08:24:45.701Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Change log 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/availability/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/1423580/usage.md

@@ -0,0 +1,5 @@
+## Occurrences
+
+| Composent | Product | Page |
+| Header | Transversal | Transversal |
+| Profil Cards | Freelance | Search |

package/dist/doc/zeroheight/components/1423608/change-log.md

@@ -0,0 +1 @@
+## Change log

package/dist/doc/zeroheight/components/1423608/content.md

@@ -0,0 +1,49 @@
+## Anatomy
+
+The checkbox component comes in two forms:
+
+- **Checkbox group**: a titled group of selectable items. Use when presenting multiple related options. Requires a group label.
+- **Standalone checkbox**: a single checkbox without a group. Use for consent, confirmation, or a binary on/off choice.
+
+## Checkbox group
+
+### **Group label**
+
+- Write as a short noun phrase that describes the category of options.
+- One to four words is the target.
+- Use sentence case. Do not end with punctuation — unless the label ends with a colon to introduce the list, which is acceptable.
+- Do not write the group label as an instruction or question. Write *Required documents*, not *Select the required documents*.
+
+### 
+
+### **Item labels**
+
+- Order items by relevance to the user, not alphabetically. Alphabetical order is language-dependent and breaks during the localisation process.
+- Write as a noun or short noun phrase. Do not write entire sentences. Ex: "Fully remote", "Full-time"...
+- All labels in a group must follow the same grammatical structure. Do not mix noun phrases and verb phrases.
+- Item labels are not full sentences, so do not end with punctuation.
+- Start with a capital letter.
+- Keep to a single line. If a label wraps to a second line, it's too long; you need to simplify it.
+- Avoid negations: Describe what the item is or what selecting it enables, not what it prevents.
+
+### **Error message**
+
+- Write in plain language. Say what went wrong and, where relevant, how to fix it.
+- Be specific to the group. Example: write "Select at least one document type", not "This field is required"*.*
+- Use sentence case. End with a period.
+- Do not blame the user.
+
+### **Helper text** (optional)
+
+- Use only when the group label alone isn't enough for users to make a confident choice.
+- Write in complete sentences. End with a period.
+- Add context or explain the consequence of the selection. Do not restate the group label.
+- Keep to one sentence where possible. Two at most.
+
+## Standalone checkbox
+
+- Use for consent, agreement, or a single binary choice, not as a stripped-down version of a group.
+- Write the item label as a complete, self-explanatory statement. It has no group label to provide context.
+- Use the first person for consent and agreement. Write "I agree to the terms of service", not "Agree to the terms of service".
+- End with punctuation. Ex: ✅ "I agree to the terms of service"
+- Avoid negations. If a user has to select something for nothing to happen, the framing is wrong.

package/dist/doc/zeroheight/components/1423608/description.md

@@ -0,0 +1,3 @@
+**Checkboxes** are used when there is a list of options and the user may select multiple options, including all or none.
+
+Status : **✅**

package/dist/doc/zeroheight/components/1423608/introduction.md

@@ -0,0 +1,29 @@
+![Checkbox in sign up page](/uploads/ktaeSl_4NnXOaPObb6OSKA.png)
+
+## Anatomy
+
+## Specifications
+
+## Type
+
+## States
+
+### Single
+
+#### Selected
+
+#### Unselected
+
+#### Indeterminate
+
+### Multi checkbox
+
+#### Default
+
+#### Outline
+
+### Indeterminate
+
+## Example
+
+## Related

package/dist/doc/zeroheight/components/1423608/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Checkbox",
+  "slug": "checkbox",
+  "category": "components",
+  "component": "VJoyCheckbox",
+  "pageId": 1423608,
+  "pageUid": "1423608",
+  "fetchedAt": "2026-07-15T08:24:45.717Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "Change log 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/checkbox/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/1423608/usage.md

@@ -0,0 +1,18 @@
+## How to replace the selectable item component?
+
+## Usage
+
+Checkboxes are particularly useful when:
+
+1. Multiple options can be selected: Checkboxes are ideal when multiple options can be selected, as they allow users to select multiple options in a compact and easily understandable format.
+2. The options are independent: When the options are independent and don't affect each other, checkboxes are a great choice, as they allow users to select as many or as few options as they want.
+3. The options are infrequently changed: If the options are infrequently changed, checkboxes are a good choice because they allow users to easily view and change their selections.
+4. The options are not mutually exclusive: When the options are not mutually exclusive, checkboxes are a better choice than a toggle, as they allow users to select multiple options.
+5. The options are related: If the options are related and it makes sense for them to be grouped together, checkboxes are a good way to keep them together and easily accessible.
+
+## Do/don't
+
+- Do: Do use for "Yes/No" or "On/Off" choices that are independent of other settings.
+- Don't: Don't use a checkbox if the user can only choose one option from a list (use Radio).
+- Do: Do allow users to select multiple options simultaneously from a group.
+- Don't: Don't trigger an immediate page jump or "Intersection" change upon clicking.

package/dist/doc/zeroheight/components/1423634/change-log.md

@@ -0,0 +1 @@
+## Change Log

package/dist/doc/zeroheight/components/1423634/content.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/components/1423634/description.md

@@ -0,0 +1 @@
+**Toggle** is a control component that is used to quickly switch between different possible states.

package/dist/doc/zeroheight/components/1423634/introduction.md

@@ -0,0 +1,27 @@
+![Toggle in a dialog ](/uploads/ayodPOiBbV1hRubpPdf6cw.png)
+
+## Anatomy
+
+## Specifications
+
+## Type
+
+## States
+
+We use 3 states for the toggle component; each state must convey a specific affordance.
+
+### States
+
+## Variants
+
+### Selected
+
+### Unselected
+
+### Animation
+
+| **Token** | Components | **Behavior** |
+| `$transition-duration--Default: 200ms;` | Toogle | While hovering and selected |
+## Example
+
+## Related

package/dist/doc/zeroheight/components/1423634/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Toggle ",
+  "slug": "toggle",
+  "category": "components",
+  "component": "VJoyToggle",
+  "pageId": 1423634,
+  "pageUid": "1423634",
+  "fetchedAt": "2026-07-15T08:24:45.908Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "Change log 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/toggle/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/1423634/usage.md

@@ -0,0 +1,11 @@
+## Usage
+
+Toggles are particularly useful when:
+
+1. There are only two options: Toggles are best used when there are only two options, as they are simple and easy to understand.
+2. The options are mutually exclusive: When the two options are mutually exclusive, a toggle is a great way to allow users to select one option without accidentally selecting both.
+3. The options are frequently changed: If the options are frequently changed, a toggle is a good choice because it allows users to quickly and easily switch between the options.
+4. The options are related: If the two options are closely related and it makes sense for them to be grouped together, a toggle is a good way to keep them together and easily accessible.
+5. Space is limited: Toggles take up minimal screen real estate, making them a good choice when space is limited.
+
+It's important to keep in mind that while toggles are a simple and intuitive interface element, they may not be suitable for all use cases. If there are more than two options, it may be better to use a different UI element, such as a radio button or drop-down menu.

package/dist/doc/zeroheight/components/1423653/change-log.md

@@ -0,0 +1,9 @@
+### No label
+
+<textarea data-textarea-container class="m-textarea" data-js="m-textarea" name="textarea" placeholder="This is an inactive textarea placeholder">
+</textarea>### Label
+
+<div class="m-textarea" data-js="m-textarea">
+    <span class="m-textarea__label">Description</span>
+    <textarea data-textarea-container name="textarea">Very long content in this textarea</textarea>
+</div>

package/dist/doc/zeroheight/components/1423653/content.md

@@ -0,0 +1,72 @@
+Placeholders should offer **useful and specific guidance** about the expected input. They serve as **hints** to indicate input format or suggest example content, but should not replace labels.
+
+## Placeholder general guidelines
+
+- Keep placeholder text short and concise,** ideally between 3–5 words **(more for free text).
+- Use **simple, familiar language** that is easy to understand.
+- Avoid jargon, full sentences, or overly detailed explanations.
+- Do not overload the placeholder with too much information—keep it focused and clear.
+- **Do not repeat the field label** in the placeholder. Redundancy can confuse users and reduce clarity.
+
+### Accessibility
+
+Avoid truncating placeholder content, as this can negatively impact usability.
+
+- Do: Keep the placeholder within the frame of the field.
+- Don't: Avoid unnecessary lengths.
+
+**Make sure key information to fill the field is accessible outside of the placeholder, as they disappear when users begin typing.**
+
+- Do: Leverage helper text to convey secondary information.
+- Don't: Do not include required instructions solely within the placeholder.
+
+### Types of input
+
+Adapt placeholder content based on the type of input:
+
+- For **action-based fields,** describe the expected written text using **clear and direct verbs ("Search", "Add", "Upload", etc.).**
+
+- Do: Be specific about the action to take.
+- Don't: Avoid generic placeholders.
+
+- Do: Provide additional information about the type of input.
+- Don't: Avoid vague instructions, which offer no contextual guidance.
+
+- For **guidance-based placeholders**, use **examples** (e.g., for dates, emails, phone numbers). However, examples should never replace the label.
+
+- If an example may be misinterpreted as actual input, consider placing it as **helper text below** the input field instead.
+- When using examples within a placeholder, **clearly indicate them by using “Ex:”.**
+
+- Do: Use obvious false or random inputs on top of adding "Ex:".
+- Don't: Avoid confusing the user with seemingly prefilled data.
+
+- Do: Remember to localise placeholder inputs whenever relevant.
+- Don't: Avoid using the same placeholders for all countries.
+
+#### Examples of placeholder usage
+
+| Input Type | Example Placeholder |
+| Name | "First name" |
+| Email | "e.g., [name@domain.com](mailto:name@domain.com)" |
+| Phone Number | "+1 123 456 7890" |
+| Date of Birth | "DD/MM/YYYY" |
+| Username | "Choose a username" |
+| Search Bar | "Search..." |
+## Label usage
+
+- **Always include a label** alongside your input field.
+
+- If a visual label is not present, the placeholder will temporarily act as one. In such cases, a floating or persistent label must appear when the user interacts with the field.
+
+- Do: undefined
+- Don't: undefined
+
+## Placeholder vs. helper text
+
+- **Placeholders** provide short, temporary hints **inside** the input field.
+
+✅ Example: `"e.g., +44 123 4567"`
+- **Helper Text** offers additional instructions and persists **below** the input field.
+
+✅ Example: `"Include country code for international numbers."`
+- If the guidance requires more detail, use **helper text instead of a long placeholder**.

package/dist/doc/zeroheight/components/1423653/introduction.md

@@ -0,0 +1,45 @@
+## Component states
+
+The states of the text input component are:
+
+a) **Default**. This is the state in which the component is on display, but the user is not interacting with it. Can be empty, or complete.
+
+c) **Hover**. Mouse over interaction to display feedback that the component can be interacted with. (Only Desktop)
+
+d) **Focus**. Keyboard based interaction to display feedback that the component can be interacted with.
+
+e) **Error state**. Displaying feedback that the content of the input is not correct by means of form, and message. Can be empty error, or content error. Usually supported by a en error notification or modal alert.
+
+f) **Disabled**. The component is not enabled to be used, yet it displays content.
+
+## Anatomy
+
+![image](/uploads/6FbJ9PCE_RDU2XxH4_e3VQ.svg)
+
+## Component
+
+### States
+
+### Label
+
+It is possible to have a label at the top of the text area, and it should match the current state.
+
+### Minimum characters
+
+In case of a **minimum** character limit, the text area will display a text showing how many characters are required. When the number of minimum characters is achieved by the user, the text will fade to a lighter shade of grey.
+
+### Maximum characters
+
+The text area will display a counter that increments every time the user enter a character (20/200 for example).
+
+In the case of a **maximum** character limit, if the user goes above the limit, the counter + the input will become red.
+
+### Counter visibility
+
+If there are no maximum limit AND no minimum limit then the counter must be hidden and the text area remains without any numbers or phrase below. Otherwise, the counter should always be displayed and be incremented every time the user enter a character.
+
+## Example
+
+![image](/uploads/KUe-I0Ca77Dt-FRiSl13uA.png)
+
+## Related

package/dist/doc/zeroheight/components/1423653/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Textarea  ",
+  "slug": "textarea",
+  "category": "components",
+  "component": "VJoyTextarea",
+  "pageId": 1423653,
+  "pageUid": "1423653",
+  "fetchedAt": "2026-07-15T08:24:45.904Z",
+  "tabs": [
+    "Introduction",
+    "Content",
+    "Change log 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/textarea/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/1423737/change-log.md

@@ -0,0 +1 @@
+### Change log

package/dist/doc/zeroheight/components/1423737/description.md

@@ -0,0 +1 @@
+Status : ✅

package/dist/doc/zeroheight/components/1423737/introduction.md

@@ -0,0 +1,17 @@
+## Anatomy
+
+![image](/uploads/FBkhshInTvNjith2EWmgTw.svg)
+
+## Component
+
+### No label
+
+### Icons
+
+### [Label](https://zeroheight.com/6bf479565/p/43746a-select/t/6652be)
+
+### Avatar
+
+## Example
+
+## Related