@lasso-ai/cli 1.0.0

package/ARCHITECTURE.md

@@ -0,0 +1,342 @@
+# Architecture
+
+> Product name: **Lasso**.
+
+## 1. Core principle
+
+Lasso edits **source code**, never the live DOM. A visual selection is a pointer into a
+codebase, not a target for direct manipulation. This decision shapes every component
+below — it's what separates a real dev tool from a demo that only works on static HTML.
+
+## 2. Repository layout
+
+```
+src/
+  cli/                    # the Node CLI (the coordinator)
+    index.ts              # entry point: `lasso` / `lasso dev`, framework detection dispatch, `daemon`/`projects`/`register`
+    project.ts            # project identity: `lasso init` (writes `{id, domain}`), `lasso dev` session resolution
+    auth.ts               # `lasso auth`: browser-OAuth login, credential store (~/.lasso/credentials.json), status, logout
+    bridge.ts             # WebSocket bridge the overlay connects to
+    server/
+      vite.ts             # Vite dev server with the source-mapping plugin injected in-memory
+      next.ts             # Next.js dev server integration (React _debugSource)
+    utils/
+      framework.ts        # framework/bundler detection
+    host/                 # Lasso Host: user-level local domains + app hosting
+      paths.ts            # host dir (~/.lasso/host), registry/pid/log paths, ports, the `.lasso` TLD
+      registry.ts         # domain → {projectId, directory} persistence (atomic, 0600), unique-domain generation
+      runtime.ts          # auto-start dev servers (Vite/Next), readiness polling, port picking
+      dns.ts              # UDP responder (*.lasso → 127.0.0.1, NXDOMAIN outside) + per-OS resolver config
+      daemon.ts           # the background host: HTTP+WS proxy, /_host/* control API, single-instance, crash guard
+      client.ts           # CLI-side helpers: health, registry read/register, stop/restart
+      install.ts          # `lasso daemon install/uninstall`, LaunchAgent, daemon spawn/status
+      vite-host-entry.js  # programmatic Vite with `.lasso` allow-listed (Vite rejects unknown Host headers)
+  overlay/
+    index.ts              # browser-side overlay (single file, bundled to dist/overlay.js)
+                          # also hosts the realtime client: presence, locks, comments, voice
+    audio/
+      transcribe.ts       # client-side audio capture (MediaRecorder) & STT relay
+```
+
+Two artifacts ship from `pnpm build`:
+
+- `dist/cli/index.js` — the CLI, compiled with `tsc`
+- `dist/overlay.js` — the browser overlay, bundled with `esbuild`
+
+## 3. System overview
+
+Three parties, all coordinating around one shared filesystem:
+
+```
+┌─────────────────────────────── Your machine ───────────────────────────────┐
+│                                                                             │
+│   Browser                        Local CLI                                │
+│  ┌──────────────┐   selection   ┌──────────────────┐   writes   ┌───────┐  │
+│  │ Overlay       │──────────────▶│ Bridge            │───────────▶│ Source │ │
+│  │ (lasso, UI)   │   + prompt    │ Source resolver   │            │ files  │ │
+│  │ Running app   │◀──────────────│ Diff preview      │            └───────┘ │
+│  │ (Vite/Next    │  diff/accept  │ Agent adapter     │                 │    │
+│  │  HMR)         │               └────────┬──────────┘                 │    │
+│  └──────────────┘                         │                    dev server │
+│                                            │                    watches ↓  │
+└────────────────────────────────────────────┼──────────────────────────────┘
+                                              │
+                                   ┌──────────┴──────────┐
+                                   │   Coding agent       │
+                                   │  (pluggable — see §6)│
+                                   └──────────────────────┘
+```
+
+Everything except the coding agent call runs locally. Nothing is ever written to disk
+without an explicit accept from the user. The agent is the only party that ever leaves the
+machine, and only with the exact context the CLI assembled for it.
+
+## 4. Browser layer (capture only)
+
+Responsibilities, and _only_ these:
+
+- Render the floating toolbar (idle / select-mode / selection-active states).
+- Lasso or click select. Match elements by **center-point containment**, not bounding-box
+  overlap (overlap over-selects parents whose edge merely brushes the lasso rect).
+- Resolve each selected DOM node to a `data-source` attribute (file, line, component name)
+  injected by the dev-time build plugin. Where no plugin is present, fall back to React's
+  `_debugSource` fiber data.
+- Take a screenshot of the selection (`html2canvas`) — visual context measurably improves
+  edit quality even when the AI has the source.
+- Show the inline prompt box anchored to the selection (never a blocking `prompt()`).
+- Render the diff/accept/undo UI once the CLI streams a proposed change back.
+- **Never mutate the DOM.** All visual changes the user sees post-edit come from the
+  framework's own HMR reload, not from this layer.
+
+Transport: a persistent **WebSocket** to the local CLI (`src/cli/bridge.ts`), not one-shot
+`fetch` calls — this lets the CLI push streaming diff previews and error states back
+without polling.
+
+## 5. Local CLI (the coordinator)
+
+A Node process that wraps the user's existing dev server. Entry: `src/cli/index.ts`.
+
+### 5.1 Responsibilities
+
+1. Detect framework/bundler on `npx lasso` (`src/cli/utils/framework.ts` reads
+   `vite.config.*`, `next.config.*`, `package.json`).
+2. Spawn the dev server programmatically with the source-mapping plugin injected in memory
+   (`src/cli/server/vite.ts`, `src/cli/server/next.ts`) — the user's own config files are
+   never touched on disk.
+3. Host the WebSocket bridge (`src/cli/bridge.ts`) the browser overlay connects to.
+4. On a selection + instruction: read the referenced source file(s), assemble context
+   (source snippet, imports, relevant CSS/Tailwind config, screenshot, instruction), and
+   hand it to the coding agent (§6).
+5. Hold the returned diff in memory and stream it to the browser for preview — never write
+   on receipt.
+6. On accept: snapshot the file's prior content (for undo), then apply the diff.
+7. On undo: restore the snapshot, full stop — no re-generation needed, so retries are free.
+
+### 5.2 Source resolution strategies
+
+| Setup                         | Method                                                                                                                                               |
+| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Vite (React/Vue/Svelte/Solid) | Native Vite plugin, spawned via `createServer()` — injects `data-source` attrs at transform time. No config file edits.                              |
+| Next.js                       | React's `_debugSource` fiber data, read at runtime — no build plugin needed, slightly less precise (nearest component boundary, not exact JSX line). |
+| Webpack-only / CRA / Angular  | **Not supported in v1.** The CLI should say so explicitly rather than fail silently.                                                                  |
+
+### 5.3 Diff format
+
+The agent returns **old-string/new-string pairs**, not a full-file rewrite. Full-file
+regeneration risks silently dropping code the model wasn't told about; a targeted
+find-and-replace is deterministic and safe to apply mechanically.
+
+### 5.4 Multi-instance handling
+
+Editing a component's source file affects every rendered instance, since the source is
+shared. This is usually correct, but the UI should say so explicitly at accept-time
+("this edits the component template — affects N instances on this page") so it never feels
+like the tool did something unexpected.
+
+## 6. Coding agent — pluggable, not hardcoded
+
+Lasso ships its own default agent, but the CLI's job is to assemble _context_, not to be
+married to one model.
+
+```
+context (source + screenshot + instruction)
+        │
+        ▼
+  ┌───────────────┐
+  │ Agent adapter  │   interface: given context, return old/new string pairs
+  └───────┬───────┘
+          │
+   ┌──────┼───────────────────┬─────────────────────┐
+   ▼      ▼                   ▼                      ▼
+ Built-in   Claude Code        User's own CLI coding   Any future
+ agent      (headless/         agent (Cursor CLI,      adapter
+ (default)  `claude -p`)       Aider, etc.)
+```
+
+- **Built-in agent** (`agent: "builtin"`): default path, zero setup, calls a hosted model
+  directly (`@anthropic-ai/sdk`) with the assembled context and the old/new-string contract
+  from §5.3.
+- **Claude Code passthrough** (`agent: "claude-code"`): the CLI shells out to Claude Code
+  in headless/print mode (`claude -p`), passing the assembled context as the prompt and
+  parsing its file edits back into the same diff-preview pipeline. This lets a user keep
+  using their existing Claude Code setup (subscription, project memory, MCP tools) while
+  still getting the point-and-select UX.
+- **Bring-your-own-agent** (`agent: "custom"`): define the adapter interface once (context
+  in, old/new-string pairs out) and let power users wire in whatever CLI coding tool they
+  already trust. Lasso's value in this mode is entirely the capture + context-assembly
+  pipeline (§4–5), not the model itself.
+
+Selection is a config choice, not an either/or product decision:
+
+```json
+// lasso.config.json (before `lasso init`)
+{
+  "agent": "builtin" // | "claude-code" | "custom"
+}
+
+// lasso.config.json (after `lasso init` — id is the only project field)
+{
+  "agent": "builtin",
+  "id": "proj_3f2a9c…" // workspace-scoped; commit it so teammates share the session
+}
+```
+
+## 7. Realtime collaboration (optional)
+
+The overlay also speaks to `collab-server` (a Socket.IO server in the monorepo) so
+teammates can collaborate on the same running app. Identity is split across two
+credentials: the **API key** (`lss_live_…` — who you are + which workspace) and
+the **project id** (which Lasso project you're opening). The API key comes from
+`LASSO_API_KEY`, or — after `lasso auth login` — from `~/.lasso/credentials.json`.
+Startup flows:
+
+```text
+0) lasso auth login (once per machine, device-style OAuth)
+   │  auth.ts POSTs /auth/cli/start → prints + opens the verification URL
+   │  (web /oauth/continue/cli?code=…, cookie auth) → /auth/cli/confirm mints an API key
+   │  in the user's first ACTIVE workspace; auth.ts polls /auth/cli/status
+   ▼
+   the key is delivered exactly once and stored at ~/.lasso/credentials.json (0600)
+
+1) lasso init (once per repo, API-key auth)
+   │  project.ts POSTs the app manifest to /collab/projects/register
+   ▼
+   collab-server hashes the key → api_keys → derives the workspace → creates or
+   reuses the project there (idempotent by git remote/name). CLI writes
+   lasso.config.json = { "id": "proj_…" }. Key never touches disk.
+
+2) lasso dev (every run, API-key auth)
+   │  reads lasso.config.json, POSTs /collab/projects/:projectId/session
+   ▼
+   collab-server resolves key → workspace, verifies the project belongs to it
+   (else 403 → realtime disabled, local editing continues), authenticates the
+   session (uid === projectId).
+   ▼  bridge sends { collab: { projectId, realtimeUrl, name, workspaceId } } with `config`
+   ▼
+   overlay io(realtimeUrl) → session:join { sessionId: projectId }
+   ◀ session joins are gated: the browser user must own the session's workspace
+```
+
+### Element identity
+
+Cross-user locks, comments, and spotlight key off a deterministic `elementKey`:
+
+1. `data-source` / `data-lasso-source` attribute (best — from the build plugin) → `attr:…`
+2. element `id` → `id:…`
+3. stable CSS path (an `nth-child` chain on the ancestors) → `css:…`
+
+This is **not** the random per-click `selectionId`. Two browsers looking at the same
+app derive the same key, so a lock acquired on "the hero heading" in one tab is visible
+and enforceable in the other. The overlay keeps an `elementRegistry` mapping key → local
+Element to re-highlight remote selections.
+
+### Flow pieces
+
+- **Presence**: every joined socket emits `presence:update` (≈ every 30 s) with
+  `selection: { elementId, label, sourceHint }`; the server broadcasts
+  `presence:changed` snapshots. Only the selected element is synced (not raw
+  coordinates), which keeps the wire tiny and the boxes meaningful.
+- **Lock mode**: before running an agent edit, the overlay `lock:acquire`s the
+  element. A `ok:false reason:"LOCKED"` ack means a teammate owns it → the edit is
+  blocked and a chip shows who. The lock is released when the edit is applied or
+  undone, and the client extends its held lock on the heartbeat.
+- **Comments**: `comments:add` with `elementId` + `meta` (source hint, label,
+  position); the panel can filter to the current element or the whole session.
+  Replies nest under a root comment via `parentId`.
+- **Spotlight**: clicking a presence avatar emits `collab:spotlight`; every tab
+  highlights the element (or the sender's own highlight) for ~2.6 s with a
+  "name → element" chip.
+- **Voice**: P2P WebRTC mesh. `voice:join` returns existing peers; the newcomer
+  creates a peer connection per peer and offers; existing members answer. Media
+  never touches the server. Muting is a right-click on the (live) voice button.
+
+Auth uses the app's own auth cookie (`withCredentials: true`) with `auth: { token }`
+read from `document.cookie` as a fallback. That works on `localhost` because
+cookie-origin and realtime-server-origin are same-site; production deployments keep
+both on the same registrable domain (documented in the collab-server README).
+
+## 8. Lasso Host (local domains + app hosting)
+
+Lasso Host turns every project into a first-class local URL. `lasso init` now also
+generates a stable unique domain for the project (`{ "id": "proj_…", "domain": "…" }`),
+so `http://app.lasso` maps to that project — no remembering ports, no manual
+`npm run dev`.
+
+- **Daemon**: `lasso daemon` starts a single-instance background process
+  (pid-guarded by holding the proxy port; extra invocations fail with
+  "already running"). Control endpoints under `/_host/*` (health, registry,
+  register, unregister, stop, restart). Logs to `~/.lasso/host/daemon.log`.
+- **Proxy**: binds `127.0.0.1` only. Any request with a `*.lasso` Host header is
+  resolved through the registry and reverse-proxied to that project's dev server;
+  non-`.lasso` hosts get a 404, so nothing outside the namespace is served.
+  WebSocket upgrades (HMR) pass through the same path.
+- **Auto-start**: a request to a stopped project spawns its dev server and waits
+  for readiness before proxying. Vite is launched programmatically
+  (`vite-host-entry.js`) with `*.lasso` allow-listed because Vite rejects unknown
+  Host headers; Next runs via `next dev --port`. Unknown frameworks report a clear
+  error rather than blindly running `npm run dev`. A crash guard stops restarts
+  after repeated immediate crashes.
+- **DNS**: `*.lasso` resolves to `127.0.0.1` via a tiny UDP responder (A record;
+  NXDOMAIN outside the namespace). Platform config behind a `DomainResolver`
+  interface: macOS `/etc/resolver/lasso` (the only `sudo` step; the responder's
+  port is otherwise unprivileged), Linux systemd-resolved split-DNS, and Windows
+  hosts entries. The HTTP proxy runs on port 6766 and the HTTPS proxy on 6767,
+  so registered URLs are shown as `http://app.lasso:6766` unless DNS is installed.
+- **Registry**: `~/.lasso/host/registry.json` (atomic write, `0600`) maps
+  domain → `{ projectId, directory, registeredAt }`. `lasso register` reuses an
+  existing registration for the same directory, never duplicates, and migrates
+  the old domain when a new one is given (also rewriting `lasso.config.json`).
+- **Trust**: no API keys or source paths in project config; only registered
+  domains proxy; the daemon listens on loopback by default.
+
+## 9. Speech-to-Text & Voice Input Architecture
+
+Lasso supports natural voice prompting in the prompt toolbar and voice dictation in component comment pins without requiring manual audio file management.
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ Browser Overlay                                             │
+│  - MediaRecorder captures audio (WebM/Opus / WAV)          │
+│  - Reactive mic animation (.recording / .transcribing)      │
+│  - Base64 payload packaging                                │
+└──────────────────────────────┬──────────────────────────────┘
+                               │
+                ┌──────────────┴──────────────┐
+                │ Bridge WebSocket or Fetch   │
+                └──────────────┬──────────────┘
+                               ▼
+┌─────────────────────────────────────────────────────────────┐
+│ Lasso Server /api/v1/transcribe (STTService)                │
+│                                                             │
+│   1. Attempt Gradium ASR (POST api.gradium.ai/speech/asr)   │
+│      - Fast streaming NDJSON transcription                 │
+│      - Credit check (402, 429, error signals)              │
+│                                                             │
+│   2. Automatic Fallback to Deepgram (Nova-2)                │
+│      - Seamless failover if Gradium credits finish/fail     │
+│      - 15-minute cooldown before retrying Gradium           │
+└─────────────────────────────────────────────────────────────┘
+```
+
+1. **Client Capture**: `src/overlay/audio/transcribe.ts` starts an audio stream via `navigator.mediaDevices.getUserMedia({ audio: true })`. Chunks are gathered into a single blob on stop.
+2. **Transport**: The client transmits base64-encoded audio either over the local CLI bridge socket (`{ type: "transcribe" }`) or directly to the server REST API (`POST /api/v1/transcribe`), avoiding cross-origin complexities.
+3. **Provider Pooling**: The backend `sttService` attempts Gradium first. If Gradium responds with a credit exhaustion code (402, 429, or out-of-credit status), it transparently falls back to Deepgram Nova-2 and returns the transcribed text to the client.
+
+## 10. Open questions for v1
+
+- Exact context window budget per request (full file vs. just the referenced function).
+- Whether the diff-preview UI lives in the browser overlay only, or also as a terminal
+  side panel for the CLI.
+- Rate limiting / cost guardrails when using a hosted default agent vs. a user's own
+  Claude Code subscription.
+- Extending source resolution beyond Vite and Next.js (Webpack/CRA/Angular).
+
+## 11. Trust model
+
+- **Telemetry-free by default.** Nothing about a user's source code leaves their machine
+  except what's explicitly sent to whichever agent they've configured.
+- **No writes without accept.** Diffs live in memory until the user confirms; undo restores
+  a pre-edit snapshot.
+- **Configs are never modified.** Build plugins are injected in memory via the CLI.
+
+See `SECURITY.md` for how to report anything that breaks this model.

package/CHANGELOG.md

@@ -0,0 +1,102 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+- Open-source documentation: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`,
+  `SECURITY.md`, `SUPPORT.md`, `LICENSE` (ISC), and this changelog.
+- **Lasso Host** (`src/cli/host/`) — a user-level local domain server + runtime
+  that serves registered projects through `*.lasso` domains. New commands:
+  - `lasso daemon [start|status|stop|restart|install|uninstall]` — background
+    single-instance daemon (reverse HTTP **and WebSocket/HMR proxy**), persistent
+    project registry at `~/.lasso/host/registry.json`, always-bound `127.0.0.1`.
+    `install` adds a macOS LaunchAgent (auto-start at login) and configures the
+    local DNS resolver (`/etc/resolver/lasso` via `sudo`); `uninstall` reverses it.
+  - `lasso register [domain]` — register the current project under a `.lasso`
+    domain (or reuse/generate one), syncs `lasso.config.json`, and replaces the
+    previous domain when it changes. Re-registering never creates duplicates.
+  - `lasso projects` — list registered domains with running/stopped state.
+  - `lasso init` now also generates a unique local domain (derived from the
+    project directory name), registers it with Lasso Host, and writes
+    `{ "id": "proj_…", "domain": "app.lasso" }`.
+  - Auto-start on traffic: a request to a stopped project starts its dev server
+    (Vite launched programmatically with `.lasso` allow-listed, Next dev via
+    `next dev --port`), waits for readiness, then proxies — no manual
+    `npm run dev`. Crashing projects are guarded (no runaway restarts).
+  - DNS: a tiny UDP responder answers `*.lasso → 127.0.0.1` (NXDOMAIN outside
+    the namespace); the platform resolver abstraction covers macOS
+    (`/etc/resolver/lasso`), Linux (systemd-resolved split-DNS), and Windows
+    (per-domain hosts entries, best-effort). No API keys or arbitrary paths are
+    exposed — only registered domains are proxied.
+- **`lasso auth` command group**: `lasso auth login` (browser OAuth — the CLI
+  prints/opens a verification URL, the logged-in dashboard user confirms, and the
+  CLI stores the minted API key in `~/.lasso/credentials.json` at `0600`),
+  `lasso auth status` (who's signed in + workspace + masked key), and
+  `lasso auth logout`. All credits feed `init`/`dev` automatically; `LASSO_API_KEY`
+  still overrides the stored credential.
+- **`lasso init`**: registers the app with your Lasso workspace (API-key
+  authenticated) and writes `lasso.config.json` containing only the project id
+  (`{ "id": "proj_…" }`). Idempotent — re-running reuses the id; commit the file
+  so teammates share the same project. The API key is **not** stored in config.
+- **`lasso dev` project session**: reads `lasso.config.json`, authenticates with
+  the API key (`LASSO_API_KEY` env / prompt), lets the realtime server resolve
+  the key → workspace → project and authenticate the project session. Renders
+  realtime collaboration unavailable (local editing unaffected) when there is no
+  config, no key, or the project belongs to another workspace.
+- **Realtime collaboration in the overlay**: presence avatars with online/away
+  dots, click-an-avatar spotlight, remote selection rings, live teammate cursors
+  with custom user colors and name badges, and a live activity strip.
+- **Live multiplayer cursors**: broadcast cursor movement via Socket.IO presence,
+  rendering smoothed remote pointers for teammates in real time.
+- **Component lock mode in the UI**: taking a suggestion acquires a lock on the
+  selected element; teammates see a refined "Locked by …" badge and the edit is
+  blocked until release or expiry.
+- **Speech-to-Text (STT) voice input & dictation**:
+  - Interactive microphone button in the prompt card with animated listening and
+    transcribing states.
+  - Voice dictation button in the comment compose bar.
+  - Client-side audio recording module (`src/overlay/audio/transcribe.ts`) using
+    the `MediaRecorder` API.
+  - Multi-provider pooling via the backend server: primary transcription via
+    Gradium (`api.gradium.ai`), with automatic failover to Deepgram (`api.deepgram.com`)
+    when credits finish or errors occur.
+  - CLI bridge support for local `transcribe` and `transcribe_result` relay.
+- **Comments panel**: thread comments anchored to the selected element (or whole
+  session), reply/resolve/reopen/delete, attachments, GIFs, and voice dictation.
+- **Clipboard & Snippets panel**: manage, copy, and share frequently used code
+  snippets, design tokens, and references with private and shared tabs.
+- **Voice chat**: P2P WebRTC mesh — join from the toolbar, mute with a right-click
+  while live.
+- CLI → overlay `config` message carries `collab: { projectId, realtimeUrl,
+  name, version, workspaceId }` so the overlay can join the right (workspace-
+  gated) session. The bridge only forwards a config it successfully authenticated.
+
+## [0.1.0] - 2026-09-21
+
+### Added
+
+- `lasso` CLI with `dev` command (default). Detects Vite or Next.js and starts the
+  dev server with the Lasso overlay attached.
+- Browser overlay: floating toolbar, select mode (click or lasso), center-point
+  element matching, inline prompt box, diff preview with accept/undo.
+- WebSocket bridge (`startBridge`) connecting the overlay to the local CLI.
+- Source mapping: Vite build plugin (`data-source` attributes, exact JSX lines);
+  Next.js via React `_debugSource` fiber data.
+- Pluggable agent adapters: `builtin` (Anthropic), `claude-code` (headless
+  passthrough), and `custom` — selectable via `lasso.config.json`.
+- In-memory diff contract: old-string/new-string pairs, no disk writes until accept.
+
+### Fixed
+
+- Nothing yet — 0.1.0 is the initial release of the working-name Lasso.
+
+### Notes
+
+- Version 0.1.0 was developed as an internal prototype. This changelog records
+  behavior from that point forward. The project uses the product name **Lasso**.

package/CODE_OF_CONDUCT.md

@@ -0,0 +1,129 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+[security@example.com](mailto:security@example.com).
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.