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

package/dist/doc/zeroheight/guidelines/7490209/roles-and-responsibilities.md

@@ -0,0 +1,19 @@
+### Designers’ roles and responsibilities
+
+- Proactive about branch creation when he has a topic
+- Creates a task with its requirements, context, constraints and prioritisation.
+- Guarantees the quality of the Design System and overall design on the product
+
+#### Benefits
+
+- **Save time: **No need to wait** **for updated component
+- **Impact Malt’s design more**: take part in shaping the DS and therefore Malt’s product, innovate
+
+### Engineers’ roles and responsibilities
+
+- **Owner **of the subject even after deployment
+
+#### Benefits
+
+- **Efficiency **
+- **More implication on the Design System topic**

package/dist/doc/zeroheight/guidelines/7517834/content.md

@@ -0,0 +1,78 @@
+Error messages are short, informative messages that tell users:
+
+1. **The issue** (what happened)
+2. **The reason (**why it happened, if known and useful)
+3. **The next step** (what’s the solution, if there’s one)
+
+They are part of the experience, not just technical feedback. Done well, they prevent frustration and guide users toward success.
+
+## Error levels
+
+Not all errors are equal. Adjust tone and detail to the **impact level**.
+
+| **Perception** | **Impact** | **Definition** | **How to address** | **Example** |
+| Frustrating** / **Annoying | Low | Small interruptions that do not block the user from completing a task. Usually triggered by **input validation** errors. | • Be short, clear, and specific.  • Point out exactly what needs to be corrected.  • Use a neutral, friendly tone. | Scenario: Freelancer enters a daily rate below min.  ✅ “Enter a daily rate above €100”❌ “Value too low” |
+| Blocking | Medium | Errors that **prevent progress** until the user fixes them. Usually related to required steps (missing fields, wrong formats, incomplete forms). | • Be direct and instructional.  • Clearly state what is missing or wrong.  • Suggest the next step to unblock the flow.  •Avoid frustration by explaining why the requirement exists if not obvious. | Scenario: Client tries to post a job without selecting a budget.  ✅ “Enter a budget to post your brief”  ❌ “Form incomplete” |
+| Critical | High | Errors that **stop functionality entirely**, often system-driven (session timeouts, payment failures...). These create the highest frustration and risk of user abandonment. | • Be serious but reassuring. •  State what happened in simple terms.  • Offer recovery paths (retry, refresh, or contact support).  • If it’s a known issue (maintenance/downtime), acknowledge it openly. | Scenario: Freelancer’s session expires while submitting a proposal.  ✅ “Your session ended for security reasons. Please sign in again to continue.”  ❌ “Authentication failed” |
+💡 **About using "please" and "sorry".**
+
+- **Please**: Use only if the situation requires a real extra effort from the user.
+- **Sorry**: Use preferably only for critical or unsolvable issues.
+
+## Decision framework
+
+Before writing, ask:
+
+1. **What triggered the error?**
+
+- User action (form input, missing step)?
+- System failure (server, downtime, session timeout)?
+2. **Do we know what happened?**
+
+- If yes → Explain clearly.
+- If no → Acknowledge the issue and offer a retry or support.
+3. **Can the user fix it?**
+
+- If yes → Give clear, specific steps.
+- If no → Reassure and provide a support path.
+
+## Writing rules: do’s and dont’s
+
+- **Be clear & specific**
+
+- Do: Add guidance specific to the context.
+- Don't: Avoid vague sentences.
+
+- **Be actionable**
+
+- Do: Give users all the information they need to solve their issue.
+- Don't: Avoid generic sentences.
+
+- **Be neutral, not blaming**
+
+- Do: Show the user to the right direction.
+- Don't: Avoid negative stance, blaming the user.
+
+- **Match the impact**
+
+- Annoying = short;
+- Blocking = instructional;
+- Critical = reassuring.
+- **Be concise & inclusive**
+
+- Do: undefined
+- Don't: undefined
+
+- **Accessibility-first**: Pair text with icons/colors, link errors to inputs, announce page-level errors to screen readers.
+
+## Most common errors
+
+| **Error type** | **Impact** | **Message pattern** | **Example** | **Accessibility notes** |
+| **Missing info** | Annoying/Blocking | “The field can’t be empty.” | “Enter a job title to continue.” | 🚧 |
+| **Invalid info** | Annoying | “Enter a valid [field requirement].” | “Enter a valid email, like [name@email.com](mailto:name@email.com).” | Show examples, avoid jargon. |
+| **Wrong format** | Annoying | “Use [correct format].” | “Enter your daily rate in numbers only.” | Use global-friendly formats (DD/MM/YYYY over MM/DD/YYYY). |
+| **File upload error** | Blocking | “File type not supported. Upload [accepted formats/limits].” | “Upload a PDF under 50 MB.” | List allowed formats; don’t just say “invalid file.” |
+| **Payment failure** | Critical | “Your payment didn’t go through. [Next step].” | “Your payment was declined. Try another card or contact your bank.” | Offer retry + support path. Avoid exposing technical codes. |
+| **Session expired** | Critical | “Your session ended for security reasons. [Action].” | “Your session expired. Sign in again to continue.” | Ensure focus moves to the error message for screen readers. |
+| **Connectivity issue** | Critical | “We couldn’t connect. [Recovery step].” | “We couldn’t load the page. Check your internet or try again later.” | Offer retry. Don’t rely on red-only indicators. |
+| **Generic errors (fallback)** | Any | “Something went wrong. [Recovery/support].” | “We couldn’t save your profile. Refresh or contact support.” | Use only when specific cause is unknown. Always include next step. |

package/dist/doc/zeroheight/guidelines/7517834/description.md

@@ -0,0 +1 @@
+Error messages are short, informative messages that inform users on current issues or blockers and educate them on the best steps to take next.

package/dist/doc/zeroheight/guidelines/7517834/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Errors",
+  "slug": "errors",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7517834,
+  "pageUid": "7517834",
+  "fetchedAt": "2026-07-15T08:24:45.753Z",
+  "tabs": [
+    "Overview",
+    "Usage",
+    "Content"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/errors/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/7517834/overview.md

@@ -0,0 +1,19 @@
+![Error pattern in a dialog](/uploads/E1FbfVT4ZGdjsoaS9ib18A.png)
+
+## Definition
+
+Error messages are short, informative messages that tell users:
+
+1. **The issue** (what happened)
+2. **The reason (**why it happened, if known and useful)
+3. **The next step** (what’s the solution, if there’s one)
+
+They are part of the experience, not just technical feedback. Done well, they prevent frustration and guide users toward success.
+
+## Why errors matter
+
+**Errors are not edge cases. They happen often. Handling them with care strengthens user trust, retention, and brand image.**
+
+How you prepare for them is a reflection of our product’s maturity and reliability. Designing for errors is not about fixing issues late; it’s about building resilient experiences from the very beginning.
+
+> To build better errors, anticipate them early in your design process.

package/dist/doc/zeroheight/guidelines/7517834/usage.md

@@ -0,0 +1,42 @@
+## Designing for errors
+
+### Give errors a place in your design process
+
+- **Collaborate with engineers early.** They know which errors are logically or technically likely to happen. Hold workshops if needed to anticipate scenarios together.
+
+**Note to engineers**: If you spot a missing error while you're developing, close the loop with your Product Designer or UX Writer to avoid shipping placeholders.
+
+- **Map and prioritise error types.** Not all errors are equal: some block critical flows, others are minor annoyances.
+
+- Which errors are technically possible?
+- Which can be prevented up front?
+- Which need clear recovery paths and user guidance?
+- **Design errors as part of the main flows.** Place them in context so recovery feels natural, consistent, and aligned with the journey.
+- **Document clearly in specs.** Provide engineers with precise behaviour and content, not just UI, to avoid generic error management.
+
+### Design the journey to minimise errors
+
+The best error is the one that never happens. Build prevention into the flow:
+
+- Use data to identify where errors are most frequent and most harmful to user success. Polish the UX, UI and microcopy to prevent them from happening.
+- Offer real-time validation rather than batch rejection at submission.
+- Use microcopy and interaction patterns to set expectations clearly.
+
+- Differentiate between optional fields from mandatory ones.
+
+- Do: undefined
+
+- - Surface constraints (file sizes, character limits, formats) before the user acts.
+
+- Do: Leverage either helper text or placeholder to educate preventively.
+
+## Handling errors
+
+- **Keep it consistent.** Define system-wide patterns for inline errors, banners, and alerts. Users should never need to relearn how your product handles mistakes.
+- **Make recovery simple and actionable.** Every error message should answer three questions:
+
+- What happened?
+- Why (if useful)?
+- What should I do next?
+- **Iterate with data.** Track where errors happen most. Frequent errors signal design or communication gaps. Adapt and refine until recovery becomes rare.
+- **Offer escape routes.** When resolution isn’t simple, provide contextual help, links to contact support, or guided troubleshooting. Never leave users stranded.

package/dist/doc/zeroheight/guidelines/7629688/description.md

@@ -0,0 +1 @@
+Product visuals are used to show our brand identity, add reassurance, and explain features or concepts.

package/dist/doc/zeroheight/guidelines/7629688/examples.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/guidelines/7629688/guidelines.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/guidelines/7629688/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "🚧 Product visuals",
+  "slug": "product-visuals",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7629688,
+  "pageUid": "7629688",
+  "fetchedAt": "2026-07-15T08:24:45.693Z",
+  "tabs": [
+    "Overview",
+    "Guidelines",
+    "Examples"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/product-visuals/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/7629688/overview.md

@@ -0,0 +1,7 @@
+![Malt illustration library](/uploads/a0bKNRnbrZTkkx70RxFUfw.png)
+
+## Illustration, icon or product visuals ?
+
+We have a tree-tiered approach to illustrations and iconography based on both size and usage:
+
+## Overview  🚧

package/dist/doc/zeroheight/guidelines/8415609/change-log.md

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

package/dist/doc/zeroheight/guidelines/8415609/content.md

@@ -0,0 +1,52 @@
+### General guidelines
+
+The floating action bar surfaces contextual actions above the page content. It appears in response to a user action (typically a selection) and groups the primary next steps relevant to that context.
+
+- The buttons of the floating action bar should** reflect the next steps of the current flow.** Do not use it to add more actions if there are already buttons at the bottom of your page.
+- The actions in the floating action bar follow a l**ogical order with the rest of the page's information**. Do not use it to push secondary content.
+- Do not use the floating action bar to provide feedback on an action. For confirmations and status updates, use the snackbar component. For inline contextual messages, use the highlight component.
+
+### Slot
+
+#### **Avatars **
+
+This is the most common usage.
+
+When selected items map to identifiable people (ex: freelancers to contact), replace the plain count with stacked avatars.
+
+- Show a maximum of 3 avatars. Overflow collapses into a "+N" badge using the same avatar size and style.
+- The count label follows the avatars: "6 selected".
+- Avatars stack left-to-right in selection order. Do not reorder by name or recency.
+- If only 1 item is selected: show 1 avatar + "1 selected". Do not pluralise.
+- The left slot is display-only. It is not interactive.
+
+#### **Text (no identity)**
+
+When selection has no associated avatars, show a plain count in text format.
+
+- Format: *N selected*. Always lowercase, always the word "selected".
+- Use the numeric digit, not the word: say "6 selected" not "six selected".
+- Never truncate or abbreviate: "12 selected" not "12 sel."
+
+### Buttons
+
+#### **One CTA**
+
+Use when there is a single clear action for the selection. It should always be a primary button. It redirects to the next step of the funnel.
+
+#### **Two CTAs**
+
+Use when there is one primary action and one secondary escape (ex: cancel, back, remove). The layout is always: secondary left, primary right.
+
+- Limit to 2 CTAs maximum.
+- The primary CTA must be the most consequential or irreversible action of the pair (ex: "Select", "Contact").
+- The secondary CTA should be a low-commitment option: "Cancel", "Dismiss", or a soft alternative action ("Move to..." vs "Archive").
+
+#### **Label writing**
+
+- Use a verb. Always action-led: "Select", "Delete", "Contact", "Move to…"
+- Keep labels to 1–2 words. The selection count already provides quantity context; don't repeat it in the label. It is acceptable only if the count changes the meaning of the action.
+- Use sentence case. Never title case or all caps.
+- Destructive actions (delete, remove, etc.) must be labelled clearly. Never softened to "Remove" when the action is permanent.
+
+Follow the usual writing guidelines for buttons.

package/dist/doc/zeroheight/guidelines/8415609/description.md

@@ -0,0 +1 @@
+A versatile, elevated container used to group primary actions that float above the main content for quick access. It provides a persistent, high-visibility interface for the most important tasks within a specific view.

package/dist/doc/zeroheight/guidelines/8415609/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Floating action bar",
+  "slug": "floating-action-bar",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 8415609,
+  "pageUid": "8415609",
+  "fetchedAt": "2026-07-15T08:24:45.758Z",
+  "tabs": [
+    "Overview",
+    "Usage",
+    "Content",
+    "🔄 Change log"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/floating-action-bar/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/8415609/overview.md

@@ -0,0 +1,13 @@
+![Floating action bar integration](/uploads/0XfYe47CCL7wc5409JO02g.png)
+
+## Anatomy
+
+## Specifications
+
+## Variants
+
+## Integration
+
+## Examples
+
+## Related

package/dist/doc/zeroheight/guidelines/8415609/usage.md

@@ -0,0 +1,6 @@
+**Floating Action Bars are particularly useful when:**
+
+- **Primary actions need to be persistent:** They ensure that the most important tools remain reachable even as the user scrolls through long content.
+- **Space optimization is required:** By floating over the UI, they provide quick access to actions without occupying a fixed row or header space.
+- **Contextual tasks are grouped:** They are ideal for grouping 2–5 related actions (e.g., Edit, Share, Delete) that apply to the overall screen or a selected object.
+- **Emphasis is needed:** The elevated, floating nature naturally draws the user’s eye to the primary "call to action" (CTA).

package/dist/doc/zeroheight/guidelines/8548355/content.md

@@ -0,0 +1,102 @@
+## Types of lists
+
+Two types are commonly used: bulleted lists and numbered lists. **They serve different purposes and should not be used interchangeably.**
+
+| **Bulleted lists** | **Numbered lists** |
+| Use when the order of items doesn't matter and items carry equal weight. Best for surfacing key information at a glance.  - Freelancer skill highlights - Profile features summary - Mission or values list - Benefits of a plan or offer | Use when sequence or hierarchy matters, when doing item 2 before item 1 would be wrong or confusing.  - How to post a project - Onboarding steps - Payment process instructions - Steps to verify your profile |
+💡 For an alternative to a numbered list for process and next steps, see also "[Stepper](https://joy.malt.com/6bf479565/p/83eba5-stepper)".
+
+## General guidelines
+
+### Usage rules
+
+#### **Use a bulleted list when**
+
+- You have 3 or more parallel items.
+- The user needs to scan rather than read linearly.
+- The content is genuinely enumerable: a set of features, steps, or options.
+
+#### **Don't use a list when**
+
+- You only have 2 items or fewer, a conjunction works better (Ex: "We handle matching *and* payment").  A list of 1 item is never a list; use a sentence instead.
+- The content flows naturally as a sentence.
+- The items aren't truly parallel or independent.
+
+#### **Length constraints**
+
+- Limit to **6 items**. More than 6 is hard to scan. Split into several thematic lists instead.
+- Aim for an average of 3 items per list.
+
+### Introduction text
+
+#### **Always use one**
+
+- A list should never start without context.
+- The intro sentence frames what the list is about and helps users understand what to expect before they scan the items.
+
+#### **Format**
+
+- Start with a capital letter. End with a colon `:`.
+- The sentence must be grammatically complete on its own.
+- Avoid cutting off mid-thought. The sentence should work standalone. Example:
+
+- Don't say ❌ "The freelancer has:"
+- Instead say ✅ "The freelancer's skills include:"
+
+#### **Scope check**
+
+- Read the intro sentence with *each* item individually, not just the first. If it only works with item 1, rewrite the intro.
+- Watch out for verbs like "includes" or "offers"; they can accidentally exclude some items if the list mixes types.
+
+Example:
+
+| Don't say ❌ | Instead say ✅ |
+| Malt connects you with:  - freelancers in 48 hours - manage contracts and payments - track project progress | Malt helps you:  - find freelancers in 48 hours - manage contracts and payments in one place - track project progress with your team |
+### List items
+
+#### **Parallelism**
+
+All items must follow the same grammatical structure (verbal or non-verbal sentence).
+
+Start each item with the same part of speech (all verbs, all nouns, all adjectives). Example: If one item starts with a verb, they all should. Mixing "Review proposals" with "Freelancer availability" breaks the pattern.
+
+#### **One idea per item**
+
+Each item equals one key idea. Limit to 1 sentence or statement.
+
+If you find yourself using "and" to connect two ideas in one bullet, split it into two items. Exception: a natural pair like "title and rate" can stay together if it reads as a single concept.
+
+#### **Length consistency**
+
+Aim for similar length across items. A list where one item is 3 words, and another is 3 lines creates a visual imbalance and signals inconsistent thinking.
+
+If one item needs much more detail, consider using a definition list or a separate paragraph instead.
+
+#### No nesting by default
+
+Avoid nested lists unless the hierarchy is essential and immediately clear. Max 2 levels. If you need 3 levels, the content likely needs a different structure entirely.
+
+Example:
+
+| Don't say ❌ | Instead say ✅ |
+| Project next steps:  - Post a project  - Add a title - Set a budget - Choose a deadline  - Review candidates | "Start by posting your project:  - Add a title - Set a budget - Choose a deadline  Then, review candidates." |
+### Punctuation per item type
+
+| Item type | Item case | Separator | Last item |
+| Fragment / Non-verbal sentence | Lowercase letter | None | None |
+| Short verbal sentence | Lowercase letter | Optional `;` | Optional `.`  (if colon used as separator) |
+| Long verbal sentence | Capital | Mandatory `;` | Mandatory `.` |
+**Important**: Be consistent. Use the same rule within a list. Do not mix punctuated and unpunctuated text.
+
+## Localisation
+
+Rules may vary depending on the language. The table below summarises key differences for Malt's supported languages.
+
+When in doubt, always check with the Localisation team.
+
+| Language | Intro punctuation | Item case | Separator | Last item | Notes |
+| 🇺🇸 | Colon `:` | See above | See above | See above | Flexible. Punctuation driven by item type. |
+| 🇫🇷 | Colon `:` | Lowercase | Semicolon `;`  Coma if nested `,` | Full stop `.` | Exception: autonomous sentences = capital + full stop per item. |
+| 🇩🇪 | Colon `:` | Nouns capitalised | None or  full stop `.` | Full stop `.` | Avoid semicolons. Noun capitalisation is mandatory, not a style choice. |
+| 🇪🇸 | Colon `:` | Lowercase | Semicolon `;`  or coma`,` | Full stop `.` | In UI/marketing contexts, punctuation between items may be omitted. |
+| 🇳🇱 | Colon `:` | See 🇺🇸 | None | None or  full stop `.` | Follows English logic. Avoid semicolons |

package/dist/doc/zeroheight/guidelines/8548355/description.md

@@ -0,0 +1 @@
+Lists are perfect for breaking complex text into manageable chunks.

package/dist/doc/zeroheight/guidelines/8548355/meta.json

@@ -0,0 +1,16 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Lists",
+  "slug": "lists",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 8548355,
+  "pageUid": "8548355",
+  "fetchedAt": "2026-07-15T08:24:45.824Z",
+  "tabs": [
+    "Usage",
+    "Content"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/lists/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/8548355/usage.md

@@ -0,0 +1,7 @@
+## Usage guidelines
+
+Lists make content easier to scan and process. They break long text into manageable chunks and improve reading comprehension.
+
+A good list has a clear logic: all items are parallel, belong together, and serve the same function. **If you're struggling to make items parallel, it's often a sign that the content shouldn't be a list at all.**
+
+💡 Lists in components: Lists can appear inside UI components such as dropdowns, selectable items, or user cards. In those contexts, list items may include a visual element (icon, avatar, tickbox). Similar writing rules apply.