feat(web): add CLI page

[caio-pizzol]

Summary

• add a /cli page with install, usage, authentication, and agent skill steps
• link the CLI from the homepage and navigation, with prerendering and SEO support
• update the MCP page for its current tools, authentication, and stateless MCP 2026-07-28 support

Testing

• bun run check
• bun run --cwd apps/web build
• bun test tests/web/
• checked /cli and /mcp at desktop and mobile widths

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

---

View medium (1)

🟠 **Medium**

1. Clipboard copy can throw ✓ 🐞

Description

CommandBlock calls navigator.clipboard.writeText() without feature detection or error handling
and sets “Copied” immediately. In browsers/contexts where Clipboard API is unavailable or the write
is rejected, clicking Copy can throw or produce an unhandled promise rejection while still showing
success.

Code

apps/web/src/pages/Cli.tsx[R98-101]

+	const copy = () => {
+		navigator.clipboard.writeText(command);
+		setCopied(true);
+		setTimeout(() => setCopied(false), 2000);

Relevance

●●● Strong

They accept reliability guards/try-catch to prevent runtime failures and false success states.

PR-#15

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new CLI page’s copy handler directly calls the clipboard API and immediately updates state, with
no await, catch, or null-check, so failures become runtime errors/unhandled rejections and still
present a success state.

apps/web/src/pages/Cli.tsx[87-103]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`CommandBlock.copy()` assumes `navigator.clipboard.writeText` exists and succeeds. If the Clipboard API is missing or rejects (permissions/unsupported context), the click handler can throw or emit an unhandled rejection, and the UI still flips to “Copied”.

## Issue Context
This is new code on the newly added `/cli` page. Similar copy buttons may exist elsewhere, but this finding is scoped to the new implementation.

## Fix Focus Areas
- apps/web/src/pages/Cli.tsx[87-103]

## Suggested fix
- Make `copy` async and wrap the clipboard call in `try/catch`.
- Feature-detect `navigator.clipboard?.writeText` and either disable the button or fall back (e.g., select text + `document.execCommand('copy')` if you still support it).
- Only set `copied=true` after a successful write.
- Optionally clear the timeout on unmount to avoid setting state after navigation (store timeout id in a ref + cleanup in `useEffect`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

---

Context

✅ Compliance rules (platform): 11 rules

Review mode: 🚀 Fast: This is a small, self-contained clipboard-status change in one UI component, with no security-sensitive or broad behavioral impact.

---

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

---

Powered by Qodo

[cubic-dev-ai]

All reported issues were addressed across 7 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[caio-pizzol]

Addressed Qodo’s clipboard finding in 819ebd2. The CLI page now waits for the clipboard write before showing success and reports “Copy failed” when the API is unavailable or rejects. Verified with bun run check, the web build and tests, and a browser interaction check.