speexor 0.1.0

package/ARCHITECTURE.md

@@ -0,0 +1,548 @@
+# Speexor Architecture
+
+**Version:** 0.1.0 — **Package:** `@speexjs/speexor`
+
+---
+
+## 1. Overview
+
+Speexor (Agent Orchestrator) is a plugin-based, agent-agnostic orchestrator for multi-AI coding agents. It manages the full lifecycle of autonomous coding agents across repositories — spawning agents in isolated worktrees, routing between provider backends, reacting to CI/PR events, and providing a real-time dashboard.
+
+**Philosophy:**
+
+- **Plugin-first architecture** — every capability is a pluggable module behind a typed interface.
+- **Agent-agnostic** — the orchestrator does not care which coding agent runs. OpenCode, Claude Code, Aider, and Codex are all first-class citizens.
+- **Isolation by design** — each agent works in its own `git worktree` with its own runtime session (tmux or subprocess).
+- **Event-driven** — lifecycle events, tracker events, and reaction triggers flow through a shared EventBus.
+- **Provider routing** — per-project configuration of primary and fallback agents with concurrency and cost limits.
+
+---
+
+## 2. High-Level Architecture
+
+```
+┌──────────────────────────────────────────────────────────────────────┐
+│                         CLI (Commander)                              │
+│  start  |  agent spawn  |  list  |  stop  |  logs  |  config-help   │
+└──────────────────────────┬───────────────────────────────────────────┘
+                           │
+                           ▼
+┌──────────────────────────────────────────────────────────────────────┐
+│                      SpeexorLifecycle                                │
+│                                                                      │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────────────────┐  │
+│  │  Plugin  │  │  Plugin  │  │  Plugin  │  │   Session Manager  │  │
+│  │ Registry │  │  Loader  │  │  Context │  │   (in-memory Map)  │  │
+│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────────────────────┘  │
+│       │             │             │                                  │
+│       ▼             ▼             ▼                                  │
+│  ┌──────────────────────────────────────────────────────────────┐   │
+│  │                      EventBus                                │   │
+│  │              (EventEmitter3 wrapper)                         │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+└──────────────────────────────────────────────────────────────────────┘
+         │            │              │              │
+         ▼            ▼              ▼              ▼
+┌─────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────────┐
+│  Agent      │ │ Runtime  │ │Workspace │ │ Tracker  │  SCM  │
+│  Adapters   │ │ Adapters │ │ Adapters │ │ Adapters│Adapt. │
+│ (4 impls)   │ │ (2 impls)│ │ (1 impl) │ │ (1 impl)│(1impl)│
+└─────────────┘ └──────────┘ └──────────┘ └──────────────────┘
+                           │
+                           ▼
+┌──────────────────────────────────────────────────────────────────────┐
+│                    Dashboard Server (Node.js HTTP)                   │
+│  /api/status | /api/projects | /api/sessions | /api/health |  /     │
+│  (4 JSON endpoints + single-page HTML dashboard, auto-refresh 5s)   │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+The lifecycle is the central orchestrator. It holds a plugin registry (keyed by slot), an in-memory session map, and the EventBus. Plugins are loaded via `loadAllPlugins()`, registered by slot, and collaborate through the shared `PluginContext` (config + EventBus + logger).
+
+---
+
+## 3. Plugin Architecture
+
+### 3.1 Base Interface
+
+Every plugin implements the `PluginModule` interface:
+
+```typescript
+interface PluginModule {
+  name: string
+  version: string
+  type: PluginSlot
+  initialize(context: PluginContext): Promise<void>
+  destroy(): Promise<void>
+}
+
+interface PluginContext {
+  config: SpeexorConfig
+  eventBus: EventBus
+  logger: (msg: string) => void
+}
+```
+
+### 3.2 Seven Plugin Slots
+
+| Slot | Interface | Purpose |
+|------|-----------|---------|
+| `agent` | `AgentPlugin` | Spawn, communicate with, and kill coding agents |
+| `runtime` | `RuntimePlugin` | Create/destroy terminal sessions (tmux or process) |
+| `workspace` | `WorkspacePlugin` | Manage isolated git worktrees |
+| `tracker` | `TrackerPlugin` | Fetch issues and subscribe to tracker events |
+| `scm` | `SCMPlugin` | Branch, commit, PR, and CI operations |
+| `notifier` | `NotifierPlugin` | Desktop notifications (macOS/Win/Linux) |
+| `terminal` | `TerminalPlugin` | Interactive terminal attach/detach (interface only) |
+
+### 3.3 Slot Interface Definitions
+
+**AgentPlugin**
+
+```typescript
+interface AgentPlugin extends PluginModule {
+  type: 'agent'
+  spawn(task: AgentTask, runtime: RuntimeSession): Promise<AgentSession>
+  sendInput(sessionId: string, input: string): Promise<void>
+  getStatus(sessionId: string): Promise<AgentStatus>
+  kill(sessionId: string): Promise<void>
+}
+```
+
+**RuntimePlugin**
+
+```typescript
+interface RuntimePlugin extends PluginModule {
+  type: 'runtime'
+  createSession(worktreePath: string): Promise<RuntimeSession>
+  destroySession(sessionId: string): Promise<void>
+  sendInput(sessionId: string, input: string): Promise<void>
+  getOutput(sessionId: string): Promise<string>
+  getLiveStream(sessionId: string): AsyncIterable<string>
+  getStatus(sessionId: string): Promise<'running' | 'stopped' | 'error'>
+}
+```
+
+**WorkspacePlugin**
+
+```typescript
+interface WorkspacePlugin extends PluginModule {
+  type: 'workspace'
+  createWorktree(task: AgentTask): Promise<WorktreeSession>
+  removeWorktree(sessionId: string): Promise<void>
+  getWorktreePath(sessionId: string): string
+  listActive(): Promise<WorktreeSession[]>
+  cleanupStale(): Promise<string[]>
+}
+```
+
+**TrackerPlugin**
+
+```typescript
+interface TrackerPlugin extends PluginModule {
+  type: 'tracker'
+  fetchIssues(filter?: TrackerFilter): Promise<TrackerIssue[]>
+  getIssue(id: string): Promise<TrackerIssue | null>
+  onEvent(handler: (event: TrackerEvent) => void): void
+}
+```
+
+**SCMPlugin**
+
+```typescript
+interface SCMPlugin extends PluginModule {
+  type: 'scm'
+  createBranch(baseBranch: string, newBranch: string): Promise<void>
+  commitAndPush(branch: string, message: string): Promise<string>
+  createPullRequest(title: string, desc: string, head: string, base: string): Promise<PRInfo>
+  getPRStatus(prId: string): Promise<PRStatus>
+  getPRComments(prId: string): Promise<PRComment[]>
+  getCIRuns(prId: string): Promise<CIRun[]>
+  mergePR(prId: string, method?: 'merge' | 'squash' | 'rebase'): Promise<void>
+  onEvent(handler: (event: TrackerEvent) => void): void
+}
+```
+
+**NotifierPlugin**
+
+```typescript
+interface NotifierPlugin extends PluginModule {
+  type: 'notifier'
+  notify(level: 'info' | 'warn' | 'error' | 'success', title: string, message: string): Promise<void>
+}
+```
+
+**TerminalPlugin**
+
+```typescript
+interface TerminalPlugin extends PluginModule {
+  type: 'terminal'
+  attach(sessionId: string): Promise<void>
+  detach(sessionId: string): Promise<void>
+  write(sessionId: string, data: string): Promise<void>
+  onData(sessionId: string, handler: (data: string) => void): void
+}
+```
+
+---
+
+## 4. Plugin Implementations
+
+The built-in registry (`src/plugins/index.ts`) includes 10 implementations loaded at startup:
+
+| Plugin | Class | Slot | Dependencies |
+|--------|-------|------|-------------|
+| OpenCode Agent | `OpenCodeAgent` | agent | — |
+| Claude Code Agent | `ClaudeCodeAgent` | agent | — |
+| Aider Agent | `AiderAgent` | agent | — |
+| Codex Agent | `CodexAgent` | agent | — |
+| tmux Runtime | `TmuxRuntime` | runtime | `tmux -V` (Unix) |
+| Process Runtime | `ProcessRuntime` | runtime | shell (Windows fallback) |
+| Git Worktree | `GitWorktreeWorkspace` | workspace | `git` |
+| GitHub Tracker | `GitHubTracker` | tracker | `gh` CLI |
+| GitHub SCM | `GitHubSCM` | scm | `gh` CLI |
+| Desktop Notifier | `DesktopNotifier` | notifier | osascript / PowerShell / notify-send |
+
+**Runtime fallback logic:** The loader registers both `TmuxRuntime` and `ProcessRuntime`. `TmuxRuntime.initialize()` throws if `tmux` is not available; lifecycle initialization failure is caught per-plugin, allowing `ProcessRuntime` to serve as the fallback on Windows.
+
+---
+
+## 5. Data Flow
+
+### 5.1 Startup Sequence
+
+```
+speexor start <repo-url>
+    │
+    ├─ 1. generateDefaultConfig(repo)  →  speexor.config.yaml
+    │
+    ├─ 2. loadConfig(cwd)  →  parse YAML  →  Zod validate  →  SpeexorConfig
+    │
+    ├─ 3. new SpeexorLifecycle(config)
+    │       │
+    │       ├─ createEventBus()  (EventEmitter3)
+    │       └─ status = 'initializing'
+    │
+    ├─ 4. lifecycle.initialize()
+    │       └─ status = 'active'
+    │
+    ├─ 5. loadAllPlugins()
+    │       ├─ new OpenCodeAgent()
+    │       ├─ new ClaudeCodeAgent()
+    │       ├─ new AiderAgent()
+    │       ├─ new CodexAgent()
+    │       ├─ new TmuxRuntime()
+    │       ├─ new ProcessRuntime()
+    │       ├─ new GitWorktreeWorkspace()
+    │       ├─ new GitHubTracker()
+    │       ├─ new GitHubSCM()
+    │       └─ new DesktopNotifier()
+    │
+    ├─ 6. for each plugin → lifecycle.registerPlugin(plugin)
+    │       └─ plugin slot → Map<PluginSlot, PluginModule[]>
+    │
+    └─ 7. new DashboardServer(lifecycle, port).start()
+            └─ HTTP server listening on :3000
+```
+
+### 5.2 Agent Spawn Flow
+
+```
+speexor agent spawn --task <id> [--agent opencode]
+    │
+    ├─ 1. loadConfig() → SpeexorConfig
+    ├─ 2. new SpeexorLifecycle(config).initialize()
+    ├─ 3. loadAllPlugins() → register all
+    │
+    ├─ 4. lifecycle.spawnAgent(task)
+    │       │
+    │       ├─ 4a. workspacePlugin.createWorktree(task)
+    │       │       ├─ git branch speexor/<task-id>
+    │       │       ├─ git worktree add .speexor/worktrees/<id> <branch>
+    │       │       └─ emit 'worktree:created'
+    │       │
+    │       ├─ 4b. runtimePlugin.createSession(worktreePath)
+    │       │       ├─ [tmux] tmux new-session -d -s speexor-<id> -c <path>
+    │       │       └─ [proc] spawn(shell, { cwd: <path> })
+    │       │
+    │       ├─ 4c. agentPlugin.spawn(task, runtimeSession)
+    │       │       ├─ creates AgentSession { id, taskId, provider, status, runtimeSessionId }
+    │       │       └─ emit 'session:created'
+    │       │
+    │       └─ return AgentSession
+    │
+    └─ 5. SessionStore persists session to .speexor/state.json
+```
+
+### 5.3 Agent Teardown Flow
+
+```
+lifecycle.stopSession(sessionId)
+    │
+    ├─ 1. agentPlugin.kill(sessionId)
+    ├─ 2. runtimePlugin.destroySession(runtimeSessionId)
+    │       ├─ [tmux] tmux kill-session -t speexor-<id>
+    │       └─ [proc] SIGTERM → SIGKILL after 5s
+    ├─ 3. workspacePlugin.removeWorktree(worktreeId)
+    │       ├─ git worktree remove <path>
+    │       └─ git branch -D speexor/<task-id>
+    ├─ 4. sessions.delete(sessionId)
+    └─ 5. emit 'session:completed'
+```
+
+---
+
+## 6. Config System
+
+### 6.1 Format
+
+YAML files, validated at startup with Zod. The loader searches these candidates in order:
+
+1. `speexor.config.yaml`
+2. `speexor.config.yml`
+3. `.speexor.yaml`
+4. `.speexor.yml`
+5. `speexor.yaml`
+
+### 6.2 Schema
+
+```yaml
+version: "1"                   # literal, must be "1"
+projects:
+  - name: my-project           # string, required
+    repository: <url>          # string, required
+    path: <local-path>         # string, optional
+    branch: main               # string, optional
+    provider:
+      primary: opencode        # enum: opencode | claude-code | aider | codex
+      fallback:                # array, optional
+        - claude-code
+      concurrentLimit: 3       # number (1-20), optional
+      costLimit: 1000          # number, optional (cents)
+    reactions:                 # optional
+      ci-failed:               # reaction rule
+        auto: true
+        action: fix            # enum: fix | notify | escalate | skip
+        retries: 3             # number (0-10)
+        escalateAfter: 30      # minutes (1-1440)
+      changes-requested:
+        auto: true
+        action: fix
+        retries: 2
+        escalateAfter: 60
+      approved-and-green:
+        auto: false
+        action: notify
+        retries: 0
+        escalateAfter: 0
+    plugins:                   # optional per-project plugin overrides
+      tracker: github-tracker
+      scm: github-scm
+      runtime: tmux-runtime
+      notifier: desktop-notifier
+```
+
+### 6.3 Default Reaction Rules
+
+```typescript
+const DEFAULT_REACTION_RULES = {
+  'ci-failed':         { auto: true,  action: 'fix',    retries: 3, escalateAfter: 30 },
+  'changes-requested': { auto: true,  action: 'fix',    retries: 2, escalateAfter: 60 },
+  'approved-and-green':{ auto: false, action: 'notify', retries: 0, escalateAfter: 0  },
+}
+```
+
+If a project omits the `reactions` block, all three defaults are applied. Partial overrides merge with defaults per event type.
+
+---
+
+## 7. Reaction Engine
+
+The `ReactionEngine` listens to `TrackerEvent` instances and executes configurable automated responses.
+
+### 7.1 Event Types
+
+```typescript
+type TrackerEventType =
+  | 'issue-opened'
+  | 'issue-closed'
+  | 'ci-failed'
+  | 'ci-passed'
+  | 'changes-requested'
+  | 'approved'
+```
+
+### 7.2 Reaction Pipeline
+
+```
+TrackerEvent
+    │
+    ▼
+ReactionEngine.processEvent(event)
+    │
+    ├─ Find handlers matching event.type
+    │
+    ├─ For each handler:
+    │     │
+    │     ├─ Check retry count (key = issueId:eventType)
+    │     │
+    │     ├─ if retries >= rule.retries → escalate or skip
+    │     │
+    │     ├─ if !rule.auto → emit 'reaction:triggered' (notify)
+    │     │
+    │     └─ executeReaction(event, rule, project)
+    │           │
+    │           ├─ action = 'fix'
+    │           │     └─ autoFix() → create AgentTask → lifecycle.spawnAgent()
+    │           │
+    │           ├─ action = 'notify'
+    │           │     └─ emit 'reaction:triggered' with action 'notify'
+    │           │
+    │           ├─ action = 'escalate'
+    │           │     └─ emit 'reaction:triggered' with action 'escalate'
+    │           │
+    │           └─ action = 'skip'
+    │                 └─ no-op
+    │
+    └─ Increment retry count
+```
+
+### 7.3 Retry Tracking
+
+Retries are tracked per `issueId:eventType` key in a `Map<string, number>`. Once the configured retry limit is reached, further events of that type for the same issue are escalated or skipped.
+
+---
+
+## 8. Dashboard
+
+### 8.1 REST API
+
+| Method | Endpoint | Description |
+|--------|----------|-------------|
+| `GET` | `/api/status` | Lifecycle status, project count, active sessions, uptime |
+| `GET` | `/api/projects` | All configured projects with provider routing |
+| `GET` | `/api/sessions` | Active agent sessions, worktrees, runtimes |
+| `GET` | `/api/health` | Health check with memory usage and timestamp |
+| `GET` | `/` or `/dashboard` | Single-page HTML dashboard |
+
+All JSON endpoints return CORS headers (`Access-Control-Allow-Origin: *`).
+
+### 8.2 Frontend
+
+The dashboard is served as an inline HTML string from `DashboardServer.serveDashboardHTML()`. It features:
+
+- **Dark theme** (GitHub-inspired `#0d1117` background)
+- **Stat cards**: project count, active agents, system status, uptime
+- **Projects table**: name, repository, primary agent, fallback agents
+- **Sessions table**: session ID, task, provider, status, start time
+- **Auto-refresh**: polls all 3 JSON endpoints every 5 seconds via `setInterval`
+- **No build step** — single HTML file with embedded `<style>` and `<script>`
+
+### 8.3 Architecture
+
+```
+DashboardServer
+    │
+    ├─ Owns: http.Server, DashboardState, routes[]
+    │
+    ├─ Subscribes to lifecycle.eventBus
+    │     ├─ 'session:created' → DashboardState.addSession()
+    │     └─ 'session:completed' → DashboardState.removeSession()
+    │
+    ├─ DashboardState (in-memory)
+    │     ├─ SpeexorState { sessions, worktrees, runtimes, projects }
+    │     └─ listener pattern for reactive updates
+    │
+    └─ Routes:
+          ├─ /api/status   → lifecycle.getStatus(), lifecycle.listSessions()
+          ├─ /api/projects → lifecycle.getConfig().projects
+          ├─ /api/sessions → lifecycle.listSessions()
+          ├─ /api/health   → { status, timestamp, memory }
+          ├─ /             → serveDashboardHTML()
+          └─ 404           → { error: 'Not found' }
+```
+
+---
+
+## 9. Session Management
+
+### 9.1 In-Memory (Runtime)
+
+The `SpeexorLifecycle` maintains a `Map<string, AgentSession>` for active sessions. Sessions are created by `spawnAgent()` and removed by `stopSession()`.
+
+### 9.2 Persistent Store
+
+The `SessionStore` class manages a JSON file at `.speexor/state.json`:
+
+```typescript
+interface SpeexorState {
+  sessions: AgentSession[]
+  worktrees: WorktreeSession[]
+  runtimes: RuntimeSession[]
+  projects: ProjectConfig[]
+}
+```
+
+- Synchronous read/write (simplicity over performance)
+- Auto-creates `.speexor/` directory on instantiation
+- Methods: `addSession`, `updateSession`, `removeSession`, `addWorktree`, `removeWorktree`, `setProjects`, `clear`
+
+### 9.3 Directory Layout
+
+```
+.speexor/
+├── state.json            # Persistent session state
+├── worktrees/            # Git worktree targets
+│   └── <task-id>/        # Isolated working directory per agent
+├── logs/                 # Runtime session logs
+│   └── <session-id>.log  # stdio capture (ProcessRuntime only)
+└── config.yaml           (optional, manual)
+```
+
+---
+
+## 10. Extension Points
+
+### 10.1 Adding a New Agent Provider
+
+Implement `AgentPlugin`, register in `loadAllPlugins()`:
+
+```typescript
+export class DeepSeekAgent implements AgentPlugin {
+  name = 'deepseek-agent'
+  version = '0.1.0'
+  type = 'agent' as const
+  // implement spawn(), sendInput(), getStatus(), kill()
+}
+```
+
+Add the provider string to the `AgentProvider` union type and the Zod schema enum in `config.ts`.
+
+### 10.2 Adding a New Plugin Slot
+
+1. Define the interface in `src/core/types.ts` extending `PluginModule`
+2. Add the slot name to `PluginSlot` union type
+3. Implement the plugin class
+4. Register it in `loadAllPlugins()` — it will be auto-loaded by the lifecycle
+
+### 10.3 Custom Runtime
+
+Implement `RuntimePlugin` for Docker, SSH, or Kubernetes sessions. The lifecycle uses `getFirstPlugin<RuntimePlugin>('runtime')`, so the first registered runtime wins.
+
+### 10.4 Custom Tracker/SCM
+
+Implement `TrackerPlugin` for Jira, Linear, or GitLab issues. Implement `SCMPlugin` for GitLab or Bitbucket PRs. Both follow the same `onEvent(handler)` subscription pattern for event-driven reactions.
+
+---
+
+## Key Design Decisions
+
+| Decision | Rationale |
+|----------|-----------|
+| EventBus over direct calls | Loose coupling — plugins and dashboard observe without knowing each other |
+| `getFirstPlugin()` slot resolution | Single active adapter per slot per lifecycle; multiple registrations possible for fallback |
+| YAML + Zod config | Strict validation with human-editable format |
+| Synchronous JSON state file | Simplicity — avoids database dependency for session tracking |
+| Inline HTML dashboard | Zero build step, zero dependencies for the UI |
+| `gh` CLI dependency | Avoids GitHub API token management; delegates auth to `gh` |
+| Reverse-order destroy | Dependencies destroyed before dependents (terminal → notifier → scm → tracker → workspace → runtime → agent) |

package/CHANGELOG.md

@@ -0,0 +1,52 @@
+# Changelog
+
+All notable changes to Speexor 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).
+
+## [0.1.0] — 2026-06-30
+
+### Added
+- Core orchestration lifecycle (SpeexorLifecycle) with plugin registry and session management
+- 7-plugin slot architecture with TypeScript interfaces
+- 4 AI agent adapters: OpenCode, Claude Code, Aider, Codex
+- 2 runtime backends: tmux (Unix) and Process (Windows)
+- Git worktree workspace isolation for parallel agent tasks
+- GitHub tracker plugin for reading issues via gh CLI
+- GitHub SCM plugin for PR/CI operations via gh CLI
+- Desktop notification plugin (macOS, Windows, Linux)
+- CLI with 6 commands: start, agent spawn, list, stop, logs, config-help
+- YAML configuration system with Zod validation
+- Built-in HTTP dashboard with REST API and HTML frontend
+- Reaction engine for automated CI/PR feedback loops
+- JSON-file session store for state persistence
+- Event bus system (EventEmitter3) for inter-module communication
+- In-memory reactive dashboard state management
+
+### Architecture
+- PluginModule base interface with initialize/destroy lifecycle
+- Provider routing with primary/fallback agent support
+- Configurable reaction rules (ci-failed, changes-requested, approved-and-green)
+- Graceful shutdown with SIGINT/SIGTERM handling
+
+## [0.2.0] — Planned
+
+### Added
+- Recursive task decomposition (DAG-based multi-agent orchestration)
+- Real-time WebSocket terminal streaming
+- Cost/usage tracking per provider
+
+## [0.3.0] — Planned
+
+### Added
+- Extension/marketplace system
+- Plugin SDK (@speexor/sdk)
+- Air-gapped mode support
+
+## [0.4.0] — Planned
+
+### Added
+- Multi-host distributed agent execution
+- Advanced observability (OpenTelemetry traces)
+- Webhook integration for third-party tools

package/CODE-OF-CONDUCT.md

@@ -0,0 +1,83 @@
+# 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, caste, color, 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:
+
+* 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
+* Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior:
+
+* The use of sexualized language or imagery, and sexual attention or advances
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Enforcement Responsibilities
+
+Project maintainers 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.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the project maintainers at opensource@superdevids.com.
+All complaints will be reviewed and investigated promptly and fairly.
+
+## Enforcement Guidelines
+
+Project maintainers will follow these Community Impact Guidelines:
+
+### 1. Correction
+**Community Impact:** Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome.
+**Consequence:** A private, written warning, providing clarity around the nature
+of the violation and an explanation of why the behavior was inappropriate.
+
+### 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 for a specified period of time.
+
+### 3. Temporary Ban
+**Community Impact:** A serious violation of community standards.
+**Consequence:** A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time.
+
+### 4. Permanent Ban
+**Community Impact:** Demonstrating a pattern of violation of community standards.
+**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][v2.1].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html