Update title and sidebar for services introduction

.cursor/rules/content-types.mdc

@@ -0,0 +1,106 @@
+---
+description: Maps folder conventions to Diataxis content types so AI tools produce the right structure for each doc category.
+globs: **/*.md,**/*.mdx
+alwaysApply: false
+---
+
+# Content types (Diataxis)
+
+This repository follows the [Diataxis framework](https://diataxis.fr/) to organize documentation by
+function. The folder a file lives in usually determines the content type and structure expectations.
+`get-started/` is a mix of onboarding topics; see that section for when quickstart rules apply.
+
+## Folder-to-type mapping
+
+### `concepts/` and `learn/` - Explanation
+
+- Explain **why** something exists and **how** it works at a high level.
+- Provide context: design decisions, historical reasons, trade-offs, and alternatives.
+- Make connections to other parts of the system or to broader concepts.
+- Do not include step-by-step instructions. Link to related guides or quickstarts instead.
+- Keep explanation closely bounded. Do not let instructions or reference details creep in.
+- End every concept page with a "Next steps" section linking to actionable content.
+- Example: `smart-accounts-kit/concepts/smart-accounts.md`
+
+### `guides/` and `how-to/` - How-to
+
+- Goal-oriented steps that help the reader achieve a specific outcome.
+- Title the page with the goal (for example, "Configure gas limits"), not a generic label.
+- State the goal in the first sentence or heading.
+- List prerequisites before the first step.
+- Number the steps. Each step should contain one action.
+- Assume the reader has basic knowledge of the product.
+- Omit the unnecessary. Practical usability matters more than completeness.
+- Do not digress into explanations or teaching. Link to concept pages instead.
+- Example: `smart-accounts-kit/guides/advanced-permissions/execute-on-metamask-users-behalf.md`
+
+### `quickstart/` and `get-started/`
+
+The folder name alone does not imply a single content type for every file under `get-started/`.
+
+**Tutorial-adjacent quickstart** (end-to-end, copy-paste-and-run path to a working integration)
+applies only when:
+
+- The file lives under a `quickstart/` directory, or
+- The file lives under `get-started/` and **quickstart** appears in the file or directory name
+  (for example, `smart-account-quickstart/index.md`).
+
+For those quickstart pages:
+
+- State what the reader will build or achieve.
+- Provide complete, working code that can be copied and pasted.
+- Keep the scope narrow. Link to guides for extended scenarios.
+
+**Other `get-started/` pages** are onboarding essentials readers should see before the rest of
+the docs: installation, system requirements, supported networks, supported clients, dashboard
+setup, and similar. They are not necessarily quickstarts. Choose structure based on the topic
+(how-to steps, short explanation, or reference-style facts) and match conventions of neighboring
+pages in the same `get-started/` section.
+
+Examples:
+
+- Quickstart: `smart-accounts-kit/get-started/smart-account-quickstart/index.md`
+- Onboarding in `get-started/` (not quickstart): `smart-accounts-kit/get-started/install.md`
+
+### `reference/` - Reference
+
+- Precise, complete, structured descriptions of APIs, methods, parameters, and return values.
+- Describe and only describe. Be austere, neutral, and factual.
+- Match the parameter format used in surrounding reference pages. Some areas use tables (name,
+  type, required/optional, description); others use nested bulleted lists (for example, JSON-RPC
+  method docs in Services). Be consistent with the existing convention in the same product section.
+- Adopt standard patterns. Consistent structure lets readers find information quickly.
+- Mirror the structure of the API or code itself (for example, one section per method or endpoint).
+- Include short usage examples to illustrate parameters and return values.
+- Keep explanatory prose to the minimum needed to use the API correctly.
+- Do not include tutorials or extended how-to steps.
+- Examples: `snaps/reference/config-options.md`,
+  `smart-accounts-kit/reference/delegation/delegation-scopes.md`,
+  `services/reference/solana/json-rpc-methods`
+
+### `tutorials/` - Tutorial
+
+- Learning-oriented, reproducible, end-to-end walkthrough.
+- State what the reader will build or accomplish at the very start.
+- Do not assume the reader has prior knowledge of the subject or tools.
+- Deliver visible results early and often. Each step should produce output the reader can verify.
+- Show expected output (for example, "You should see `Server running on port 3000`").
+- Ruthlessly minimize explanation. Keep the focus on doing, not theory. Link to concept pages for
+  deeper understanding.
+- Ignore options and alternatives. Guide the reader along a single path to a successful conclusion.
+- Provide a complete working project or code sample.
+- Aspire to perfect reliability. Test every step. A learner who doesn't get the expected result
+  loses confidence immediately.
+- Example: `src/pages/tutorials/create-wallet-ai-agent.md`
+
+### `troubleshooting/` - Problem/solution
+
+- State the symptom or error message first, then the fix.
+- One problem per section or page.
+- Include the exact error text when available so readers can search for it.
+- Example: `smart-accounts-kit/troubleshooting/allowance-exceeded.md`
+
+## Frontmatter
+
+For required and optional documentation frontmatter (`description`, `keywords`, `sidebar_label`,
+`title` vs duplicate H1), see **Frontmatter** in `markdown-formatting.mdc`.

.cursor/rules/contributor-workflow.mdc

@@ -0,0 +1,96 @@
+---
+description: Workflow rules for contributors and reviewers covering sidebar updates, redirects, verification, and PR expectations.
+alwaysApply: true
+---
+
+# Contributor workflow
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for the full contribution process. The rules below highlight
+the requirements that are most often missed.
+
+## Sidebar updates
+
+Every new documentation page must be added to the appropriate sidebar file:
+
+| Product             | Sidebar file              |
+| ------------------- | ------------------------- |
+| MetaMask Connect    | `mm-connect-sidebar.js`   |
+| Embedded Wallets    | `ew-sidebar.js`           |
+| Smart Accounts Kit  | `gator-sidebar.js`        |
+| Agent Wallet        | `agent-wallet-sidebar.js` |
+| Services            | `services-sidebar.js`     |
+| Developer dashboard | `dashboard-sidebar.js`    |
+| Snaps               | `snaps-sidebar.js`        |
+
+## Redirects
+
+Every deleted, renamed, or moved page must have a redirect added in `vercel.json`. Docusaurus is
+configured with `onBrokenLinks: 'throw'`, so broken internal links will fail the build.
+
+Follow the trailing-slash rules in `vercel-redirects.mdc`: use a **slash-terminated `source`**
+only (no duplicate no-slash entry), and a slash-terminated `destination` for normal paths.
+
+## Factual accuracy
+
+Do not state as fact any API behavior, parameter, or return value that you have not verified
+against the codebase or published reference. If you are uncertain, add a review comment or
+admonition noting the uncertainty. This rule applies to both human and AI-assisted contributions.
+
+## Images
+
+Place images in the product's designated asset folder:
+
+- `metamask-connect/*/_assets/`
+- `static/img/embedded-wallets/` (Embedded Wallets product images)
+- `smart-accounts-kit/assets/`
+- `services/images/`
+- `snaps/assets/`
+- `static/img/` (for site-wide assets)
+
+## Update rule files for structural changes
+
+When a change affects the structure, naming, or conventions of a product area, update the
+corresponding `.cursor/rules/` file in the same PR. Examples of changes that require a rule update:
+
+- Renaming a product or changing its branding (update the product rule file and `terminology.mdc`).
+- Adding, removing, or renaming top-level content folders (update the product rule file and
+  `content-types.mdc` if a new folder pattern is introduced).
+- Changing the parameter documentation format in a reference section (update the product rule file
+  and `content-types.mdc`).
+- Moving image storage to a different directory (update `contributor-workflow.mdc` and the product
+  rule file).
+- Adding a new product area to the repository (create a new `product-*.mdc` rule file and add the
+  product to the table in `contributor-workflow.mdc` and `AGENTS.md`).
+- Changing sidebar file names or adding new sidebar files (update the sidebar table above and the
+  product rule file).
+- Introducing new shared partials or generated-content patterns (update the product rule file).
+
+Keeping rule files current prevents stale guidance from producing incorrect contributions.
+
+## CI linting
+
+Pull requests run **`npm run format:check`** (Prettier against `.prettierrc` and `.prettierignore`). Run
+**`npm run format`** locally to fix style before pushing. Generated Snaps API pages under
+`snaps/reference/snaps-api/` are excluded from formatting in git (see `.prettierignore`).
+
+After **`npm install`**, [Husky](https://typicode.github.io/husky/) installs a Git **`pre-commit`** hook
+that runs [**`lint-staged`**](https://github.com/lint-staged/lint-staged) using the rules in
+`package.json`. Staged files matching those patterns are auto-formatted with Prettier (and other
+commands in `lint-staged`, such as ESLint on `src/`). Restage if the hook edits files. Hooks are
+local only and are not required for CI to pass.
+
+Pull requests are checked by a Vale-based linter
+([docs-spelling-check](https://github.com/Consensys/github-actions/tree/main/docs-spelling-check))
+that enforces Microsoft style, Consensys terminology, and spelling. Fix any linter warnings before
+requesting review. If a warning is a false positive, add the term to the Vale vocabulary file rather
+than rewriting valid technical language.
+
+## Pull requests
+
+- Summarize what changed and why in the PR description. Do not just list files.
+- Link the related issue using `fixes #<number>` when applicable.
+- Preview locally with `npm start` before requesting review.
+
+## Cross-product links
+
+See the **Links** section in `markdown-formatting.mdc`.

.cursor/rules/editorial-voice.mdc

@@ -0,0 +1,70 @@
+---
+description: Editorial voice and tone rules aligned with the Microsoft Writing Style Guide and Consensys documentation standards.
+globs: **/*.md,**/*.mdx
+alwaysApply: false
+---
+
+# Editorial voice
+
+Follow the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/)
+and the [Consensys documentation style guide](https://docs-template.consensys.net/contribute/style-guide).
+The rules below are the most actionable subset for AI-assisted editing.
+
+## Voice and tone
+
+- Use active voice and present tense.
+- Write in second person. Address the reader as "you."
+- Use contractions naturally ("it's," "don't"). Be informal but not sloppy.
+- Refer to the reader's application as "your dapp" (not "the dapp" or "your application").
+- Refer to the reader as "you" (not "the developer," "the user," or "users").
+- Dapp developers (our readers) in turn have users. It's ok to use "users" in that context.
+
+## Clarity
+
+- Get to the point in the first sentence of every section. Does it answer "what," "why," and "when"?
+- Use short, simple sentences. Remove nonessential or redundant words.
+- Break up three or more paragraphs with subheadings, lists, tables, code samples, or admonitions.
+- Write for developers who want to accomplish a task or learn a skill, not for marketing purposes.
+
+## Sentence construction
+
+- Lead with what's most important. Front-load keywords for scanning.
+- Start sentences with a verb when possible. Edit out "you can" and "there is/are" phrasing.
+- Use the Oxford (serial) comma in lists of three or more items (for example, "Android, iOS, and
+  Windows").
+- Do not start sentences with "So," "Basically," or "Actually."
+
+## Lists
+
+- Include at least two items but, if possible, no more than seven.
+- Keep items short enough that the reader can see two or three at a glance. A couple of short
+  paragraphs per item is acceptable, but don't exceed that length often.
+- Make all items consistent in structure (for example, each item is a noun or a phrase that starts
+  with a verb).
+
+## Punctuation and formatting
+
+- Do not use em dashes (—) to set off extra information. Use commas, parentheses, semicolons, or rephrase the sentence.
+- Use only one space after periods, question marks, and colons.
+- Use sentence case for all headings and titles. Never use title case.
+- Do not end headings, subheadings, or UI titles with periods.
+- Use backticks for inline code, file names, and URLs referenced in prose.
+- In general, do not use bold to emphasize words in a paragraph. Use bold sparingly:
+  - For UI element names (buttons, menu items, field labels).
+  - For emphasis in exceptional cases such as critical security warnings when an admonition is not enough.
+
+## Developer content
+
+- List prerequisites before the first step. Suggest good practices (for example, "secure private
+  keys," "protect RPC endpoints in production").
+- Write code samples that are readable, can be copied and pasted, and work as expected. Do not
+  include shell prompts (for example, `user@host $`) in code blocks.
+- Use angle-bracket placeholders for user-supplied values (for example, `<YOUR_API_KEY>`).
+
+## What to avoid
+
+- No marketing language, superlatives, or promotional tone ("best-in-class," "powerful," "seamless").
+- No slang, figures of speech, or culturally specific idioms.
+- No run-on sentences.
+- No jargon without definition. If a term must be used, define it on first use or link to a
+  glossary entry.

.cursor/rules/markdown-formatting.mdc

@@ -0,0 +1,69 @@
+---
+description: Markdown formatting conventions for the MetaMask documentation site (Docusaurus).
+globs: **/*.md,**/*.mdx
+alwaysApply: false
+---
+
+# Markdown formatting
+
+Follow the [Consensys Markdown formatting guide](https://docs-template.consensys.net/contribute/format-markdown)
+for full details. The rules below cover the most common conventions.
+
+## Line length and sentence breaks
+
+- Wrap lines at roughly 100 columns.
+- Start each new sentence on a new line, even if the previous line is short. This makes diffs
+  easier to review.
+
+## Links
+
+- Use relative file paths for links within the same product (for example, `./concepts/scopes.md`).
+- Use absolute URL paths for cross-product links (for example, `/snaps/learn/about-snaps`).
+- Use descriptive link text. Do not use "click here" or bare URLs.
+- Use absolute links on `CardList` components.
+
+## Code blocks
+
+- Always specify the language on fenced code blocks (` ```javascript `, ` ```bash `, etc.).
+- Indent code with two spaces, not four.
+- In JavaScript, TypeScript, JSX, and TSX samples, use single-quoted string literals.
+- In JSON samples, keep double-quoted keys and strings (required by JSON syntax).
+- In any other language (for example, Swift, Kotlin, Dart, Solidity, Python, shell), follow that
+  language's normal conventions for string quotes.
+- After editing documentation, run `npm run format` so Prettier applies these rules to fenced code
+  in Markdown/MDX (see `.prettierrc`).
+- For npm install commands, use ` ```bash npm2yarn ` fences to produce automatic npm/yarn tabs.
+- Write code samples that can be copied, pasted, and run as-is. Do not include shell prompts
+  (for example, `user@host $`) or trailing comments that break execution.
+- Use angle-bracket placeholders for values the reader must supply
+  (for example, `<YOUR_INFURA_API_KEY>`).
+
+## Tabs
+
+- Use Docusaurus `<Tabs>` and `<TabItem>` components to display parallel content such as code
+  samples in different languages or package-manager commands.
+- Import `Tabs` and `TabItem` from `@theme/Tabs` and `@theme/TabItem` at the top of the file.
+
+## Admonitions
+
+- Use Docusaurus admonitions: `:::note`, `:::tip`, `:::caution`, `:::info`, `:::danger`.
+- Add a custom title on the same line only when it helps scanning (for example, `:::caution important`).
+- Do not nest admonitions.
+
+## Tables
+
+- Align table columns in the source Markdown for readability.
+- Use a tool like [Markdown Table Formatter](https://markdowntable.com/) if needed.
+
+## Frontmatter
+
+- Required: `description` (one sentence for SEO and previews).
+- Recommended: `keywords` (array).
+- `sidebar_label`: optional. Use sparingly; only when the default sidebar text (usually from the
+  page title) would be too long or wordy for the navigation. Omit when the default is fine.
+- If the frontmatter contains a `title` field, do not add a separate top-level `# Heading` to
+  avoid a duplicate H1.
+
+## File and folder names
+
+- Use lowercase letters and dashes only (for example, `send-transactions.md`, not `sendTransactions.md`).