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

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

@@ -0,0 +1,13 @@
+{
+  "source": "https://zeroheight.com/6bf479565/p/92b4a3--seamless",
+  "title": "✪ Seamless",
+  "slug": "seamless",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7490164,
+  "pageUid": "7490164",
+  "fetchedAt": "2026-07-15T08:24:45.683Z",
+  "tabs": [],
+  "imagesPath": "packages/core-vue/static/zeroheight/seamless/",
+  "extraction": "zeroheight-api"
+}

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

@@ -0,0 +1 @@
+Foster genuine **human** connection.

package/dist/doc/zeroheight/guidelines/7490166/introduction.md

@@ -0,0 +1,13 @@
+## Overview
+
+## Our users …
+
+- feel understood (personalization) and valued (trust markers, visibility)
+- confidently staff or join the next superteam
+- understand and connect with Malt’s mission
+
+## Our design …
+
+- creates visibility on people and their stories
+- enables direct and trusted relationships between people
+- is conversational and conveys a sense of human touch

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

@@ -0,0 +1,13 @@
+{
+  "source": "https://zeroheight.com/6bf479565/p/673c95--human",
+  "title": "✪ Human",
+  "slug": "human",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7490166,
+  "pageUid": "7490166",
+  "fetchedAt": "2026-07-15T08:24:45.681Z",
+  "tabs": [],
+  "imagesPath": "packages/core-vue/static/zeroheight/human/",
+  "extraction": "zeroheight-api"
+}

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

@@ -0,0 +1 @@
+Create **momentum** through uplifting interactions.

package/dist/doc/zeroheight/guidelines/7490167/introduction.md

@@ -0,0 +1,13 @@
+## Overview
+
+## Our users …
+
+- know they are succeeding at every step of the way
+- feel rewarded when (autonomously) achieving their goals
+- build a sense of belonging to Malt’s mission and community
+
+## Our design …
+
+- ignites purposeful moments of joy
+- conveys Malt’s mission and community through messaging and content
+- fosters meaningful interactions with Malt’s brand

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

@@ -0,0 +1,13 @@
+{
+  "source": "https://zeroheight.com/6bf479565/p/093f80--momentum",
+  "title": "✪ Momentum",
+  "slug": "momentum",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7490167,
+  "pageUid": "7490167",
+  "fetchedAt": "2026-07-15T08:24:45.683Z",
+  "tabs": [],
+  "imagesPath": "packages/core-vue/static/zeroheight/momentum/",
+  "extraction": "zeroheight-api"
+}

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

@@ -0,0 +1 @@
+Figma branches provide a safe space for designers to experiment and make changes to the main Design System file. They allow for isolated work and collaboration, ensuring that new components and updates are reviewed and approved before being merged.

package/dist/doc/zeroheight/guidelines/7490191/how-to-use-branches.md

@@ -0,0 +1,3 @@
+## How to use branches?
+
+Full tutorial about the usage of branches on Figma:

package/dist/doc/zeroheight/guidelines/7490191/introduction.md

@@ -0,0 +1,31 @@
+![Branches on Figma](/uploads/hZHjwJthLMk-9aTtfZksyA.png)
+
+## What is a branch ?
+
+It’s a functionality that allows you to create a copy of a project and modify it independently of the master version. When the work is finished, and you need to make changes to the master project — the branch merges with the master version. Everything is just like the developers.
+
+## Why using branch ?
+
+Branches are exploratory spaces that enable designers to safely try new ideas without making changes to the main, or existing, file.Rather than auto-saving to the main file, changes from branches are merged into the main file when you're ready.
+
+## When to consider branching ?
+
+### Maintaining and contributing to a design library
+
+- Adding or modifying shared styles
+- Modifying existing components and Variants
+- Creating new components for a library
+
+### Sharing with collaborators and stakeholders
+
+- Collaborate or share progress and get feedback from stakeholders
+- Share a file or prototype link directly to the branch.
+
+### Freezing feature work for development handoff
+
+- Gives them a clear view of any new assets and design work
+- Collaborators can have a back-and-forth conversation within the branch as the feature is being built
+
+### Isolated design experiments and user testing
+
+- Branches allow you to test prototypes of derivative design explorations

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

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Figma Branches",
+  "slug": "figma-branches",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7490191,
+  "pageUid": "7490191",
+  "fetchedAt": "2026-07-15T08:24:45.754Z",
+  "tabs": [
+    "Introduction",
+    "How to use branches",
+    "Resources"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/figma-branches/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/7490191/resources.md

@@ -0,0 +1 @@
+### Figma Branches ressources

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

@@ -0,0 +1 @@
+This collaborative model outlines how teams and individuals contribute to and maintain the Design System. It establishes clear processes, roles, and responsibilities to ensure all contributions are consistent, high-quality, and align with the system's overall vision.

package/dist/doc/zeroheight/guidelines/7490209/full-process.md

@@ -0,0 +1 @@
+## Full collaborative model process

package/dist/doc/zeroheight/guidelines/7490209/introduction.md

@@ -0,0 +1,9 @@
+### Why?
+
+**Malt decided to switch to collaborative contribution model for a ****faster**** ****& ****more adopted**** Design System**
+
+### **From a centralized to a collaborative model**
+
+Empower squad designers and engineers to directly contribute to the system, with the core Design System team providing review and validation.
+
+![Design System Collaboration Models](/uploads/nwcwPHecGxsbCFnHYrWkOA.png)

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

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Collaborative model",
+  "slug": "collaborative-model",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 7490209,
+  "pageUid": "7490209",
+  "fetchedAt": "2026-07-15T08:24:45.719Z",
+  "tabs": [
+    "Introduction",
+    "Need identification",
+    "Roles and responsibilities",
+    "Full process"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/collaborative-model/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/7490209/need-identification.md

@@ -0,0 +1,9 @@
+### How to identify the needs
+
+- Did other people have the same need
+- It’s that a need for a new component or an evolution
+- Is there already a component that can answer the need?
+
+### Resource decision tree
+
+![image](/uploads/LRwziJCVW2-k-0d37BxvlQ.png)

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"
+}