From 822784e60c2f7e6b4b9449a9acd9411bb4ca0250 Mon Sep 17 00:00:00 2001 From: konsalex Date: Sun, 25 Jan 2026 22:41:13 +0100 Subject: [PATCH 1/2] feat: add Agents.MD and openspec support --- .cursor/commands/openspec-apply.md | 23 ++ .cursor/commands/openspec-archive.md | 27 ++ .cursor/commands/openspec-proposal.md | 28 ++ .gitignore | 2 + AGENTS.md | 88 +++++ openspec/AGENTS.md | 456 ++++++++++++++++++++++++++ openspec/project.md | 127 +++++++ 7 files changed, 751 insertions(+) create mode 100644 .cursor/commands/openspec-apply.md create mode 100644 .cursor/commands/openspec-archive.md create mode 100644 .cursor/commands/openspec-proposal.md create mode 100644 AGENTS.md create mode 100644 openspec/AGENTS.md create mode 100644 openspec/project.md diff --git a/.cursor/commands/openspec-apply.md b/.cursor/commands/openspec-apply.md new file mode 100644 index 0000000..99a9148 --- /dev/null +++ b/.cursor/commands/openspec-apply.md @@ -0,0 +1,23 @@ +--- +name: /openspec-apply +id: openspec-apply +category: OpenSpec +description: Implement an approved OpenSpec change and keep tasks in sync. +--- + +**Guardrails** +- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. +- Keep changes tightly scoped to the requested outcome. +- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. + +**Steps** +Track these steps as TODOs and complete them one by one. +1. Read `changes//proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria. +2. Work through tasks sequentially, keeping edits minimal and focused on the requested change. +3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished. +4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality. +5. Reference `openspec list` or `openspec show ` when additional context is required. + +**Reference** +- Use `openspec show --json --deltas-only` if you need additional context from the proposal while implementing. + diff --git a/.cursor/commands/openspec-archive.md b/.cursor/commands/openspec-archive.md new file mode 100644 index 0000000..013eed4 --- /dev/null +++ b/.cursor/commands/openspec-archive.md @@ -0,0 +1,27 @@ +--- +name: /openspec-archive +id: openspec-archive +category: OpenSpec +description: Archive a deployed OpenSpec change and update specs. +--- + +**Guardrails** +- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. +- Keep changes tightly scoped to the requested outcome. +- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. + +**Steps** +1. Determine the change ID to archive: + - If this prompt already includes a specific change ID (for example inside a `` block populated by slash-command arguments), use that value after trimming whitespace. + - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends. + - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding. + - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet. +2. Validate the change ID by running `openspec list` (or `openspec show `) and stop if the change is missing, already archived, or otherwise not ready to archive. +3. Run `openspec archive --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work). +4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`. +5. Validate with `openspec validate --strict --no-interactive` and inspect with `openspec show ` if anything looks off. + +**Reference** +- Use `openspec list` to confirm change IDs before archiving. +- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off. + diff --git a/.cursor/commands/openspec-proposal.md b/.cursor/commands/openspec-proposal.md new file mode 100644 index 0000000..55e981a --- /dev/null +++ b/.cursor/commands/openspec-proposal.md @@ -0,0 +1,28 @@ +--- +name: /openspec-proposal +id: openspec-proposal +category: OpenSpec +description: Scaffold a new OpenSpec change and validate strictly. +--- + +**Guardrails** +- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. +- Keep changes tightly scoped to the requested outcome. +- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. +- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files. +- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval. + +**Steps** +1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification. +2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes//`. +3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing. +4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs. +5. Draft spec deltas in `changes//specs//spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant. +6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work. +7. Validate with `openspec validate --strict --no-interactive` and resolve every issue before sharing the proposal. + +**Reference** +- Use `openspec show --json --deltas-only` or `openspec show --type spec` to inspect details when validation fails. +- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones. +- Explore the codebase with `rg `, `ls`, or direct file reads so proposals align with current implementation realities. + diff --git a/.gitignore b/.gitignore index 6ca7740..ca64364 100644 --- a/.gitignore +++ b/.gitignore @@ -27,3 +27,5 @@ dist-ssr *__pycache__/ .yarn/install-state.gz + +openspec/changes \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..4b3b2bc --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,88 @@ +# Agent Development Guide for Hopp + +## Project Overview + +Hopp is an open-source pair programming app with screen sharing, remote control, and multi-user rooms. Built with Tauri (desktop), Go (backend), and Rust (core engine). + +## Directory Structure + +- `backend/` — Go API server (Echo, PostgreSQL, Redis) +- `core/` — Rust screen capture/remote control engine +- `tauri/` — Tauri desktop app (React + TypeScript frontend) +- `web-app/` — React web application +- `docs/` — Astro documentation site + +## Commands + +All commands use [Taskfile](https://taskfile.dev). Run `task --list` in any directory to see available tasks. + +Avoid running the following commands as an agent, as this is preferred to run from a user in their terminal and navigate in the Desktop app. + +**Backend (Go):** +```bash +cd backend +task run # Run with hot reload (Air) +task test # Run tests +``` + +**Core (Rust):** +```bash +cd core +cargo build +cargo test +cargo fmt # Format code +``` + +**Tauri App:** +```bash +cd tauri +task dev # Dev mode with hot reload +task build # Production build +``` + +**Web App:** +```bash +cd web-app +yarn dev +yarn build +``` + +## Code Style + +- **JS/TS:** Prettier (120 cols). Runs via pre-commit. +- **Rust:** `cargo fmt` per crate (`core/`, `tauri/src-tauri/`). +- **Go:** `gofmt` + `golangci-lint` (config: `.golangcli.yml`). + +Pre-commit hooks enforce all formatting automatically. + +## Testing + +- **Go:** Integration tests in `backend/test/integration/` +- **Rust:** Unit tests + visual integration tests in `core/tests/` +- **Frontend:** Linting + typechecking (no unit test runner configured) + +## Key Conventions + +- Use `@` alias for imports in TS/React code (maps to `src/`) +- API contracts defined in `backend/api-files/openapi.yaml` +- Desktop app launches `hopp_core` binary and communicates over socket +- Cross-platform: macOS, Windows, Linux all supported + + +# OpenSpec Instructions + +These instructions are for AI assistants working in this project. + +Always open `@/openspec/AGENTS.md` when the request: +- Mentions planning or proposals (words like proposal, spec, change, plan) +- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work +- Sounds ambiguous and you need the authoritative spec before coding + +Use `@/openspec/AGENTS.md` to learn: +- How to create and apply change proposals +- Spec format and conventions +- Project structure and guidelines + +Keep this managed block so 'openspec update' can refresh the instructions. + + diff --git a/openspec/AGENTS.md b/openspec/AGENTS.md new file mode 100644 index 0000000..6c1703e --- /dev/null +++ b/openspec/AGENTS.md @@ -0,0 +1,456 @@ +# OpenSpec Instructions + +Instructions for AI coding assistants using OpenSpec for spec-driven development. + +## TL;DR Quick Checklist + +- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search) +- Decide scope: new capability vs modify existing capability +- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`) +- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability +- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement +- Validate: `openspec validate [change-id] --strict --no-interactive` and fix issues +- Request approval: Do not start implementation until proposal is approved + +## Three-Stage Workflow + +### Stage 1: Creating Changes +Create proposal when you need to: +- Add features or functionality +- Make breaking changes (API, schema) +- Change architecture or patterns +- Optimize performance (changes behavior) +- Update security patterns + +Triggers (examples): +- "Help me create a change proposal" +- "Help me plan a change" +- "Help me create a proposal" +- "I want to create a spec proposal" +- "I want to create a spec" + +Loose matching guidance: +- Contains one of: `proposal`, `change`, `spec` +- With one of: `create`, `plan`, `make`, `start`, `help` + +Skip proposal for: +- Bug fixes (restore intended behavior) +- Typos, formatting, comments +- Dependency updates (non-breaking) +- Configuration changes +- Tests for existing behavior + +**Workflow** +1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context. +2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes//`. +3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement. +4. Run `openspec validate --strict --no-interactive` and resolve any issues before sharing the proposal. + +### Stage 2: Implementing Changes +Track these steps as TODOs and complete them one by one. +1. **Read proposal.md** - Understand what's being built +2. **Read design.md** (if exists) - Review technical decisions +3. **Read tasks.md** - Get implementation checklist +4. **Implement tasks sequentially** - Complete in order +5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses +6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality +7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved + +### Stage 3: Archiving Changes +After deployment, create separate PR to: +- Move `changes/[name]/` → `changes/archive/YYYY-MM-DD-[name]/` +- Update `specs/` if capabilities changed +- Use `openspec archive --skip-specs --yes` for tooling-only changes (always pass the change ID explicitly) +- Run `openspec validate --strict --no-interactive` to confirm the archived change passes checks + +## Before Any Task + +**Context Checklist:** +- [ ] Read relevant specs in `specs/[capability]/spec.md` +- [ ] Check pending changes in `changes/` for conflicts +- [ ] Read `openspec/project.md` for conventions +- [ ] Run `openspec list` to see active changes +- [ ] Run `openspec list --specs` to see existing capabilities + +**Before Creating Specs:** +- Always check if capability already exists +- Prefer modifying existing specs over creating duplicates +- Use `openspec show [spec]` to review current state +- If request is ambiguous, ask 1–2 clarifying questions before scaffolding + +### Search Guidance +- Enumerate specs: `openspec spec list --long` (or `--json` for scripts) +- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available) +- Show details: + - Spec: `openspec show --type spec` (use `--json` for filters) + - Change: `openspec show --json --deltas-only` +- Full-text search (use ripgrep): `rg -n "Requirement:|Scenario:" openspec/specs` + +## Quick Start + +### CLI Commands + +```bash +# Essential commands +openspec list # List active changes +openspec list --specs # List specifications +openspec show [item] # Display change or spec +openspec validate [item] # Validate changes or specs +openspec archive [--yes|-y] # Archive after deployment (add --yes for non-interactive runs) + +# Project management +openspec init [path] # Initialize OpenSpec +openspec update [path] # Update instruction files + +# Interactive mode +openspec show # Prompts for selection +openspec validate # Bulk validation mode + +# Debugging +openspec show [change] --json --deltas-only +openspec validate [change] --strict --no-interactive +``` + +### Command Flags + +- `--json` - Machine-readable output +- `--type change|spec` - Disambiguate items +- `--strict` - Comprehensive validation +- `--no-interactive` - Disable prompts +- `--skip-specs` - Archive without spec updates +- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive) + +## Directory Structure + +``` +openspec/ +├── project.md # Project conventions +├── specs/ # Current truth - what IS built +│ └── [capability]/ # Single focused capability +│ ├── spec.md # Requirements and scenarios +│ └── design.md # Technical patterns +├── changes/ # Proposals - what SHOULD change +│ ├── [change-name]/ +│ │ ├── proposal.md # Why, what, impact +│ │ ├── tasks.md # Implementation checklist +│ │ ├── design.md # Technical decisions (optional; see criteria) +│ │ └── specs/ # Delta changes +│ │ └── [capability]/ +│ │ └── spec.md # ADDED/MODIFIED/REMOVED +│ └── archive/ # Completed changes +``` + +## Creating Change Proposals + +### Decision Tree + +``` +New request? +├─ Bug fix restoring spec behavior? → Fix directly +├─ Typo/format/comment? → Fix directly +├─ New feature/capability? → Create proposal +├─ Breaking change? → Create proposal +├─ Architecture change? → Create proposal +└─ Unclear? → Create proposal (safer) +``` + +### Proposal Structure + +1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique) + +2. **Write proposal.md:** +```markdown +# Change: [Brief description of change] + +## Why +[1-2 sentences on problem/opportunity] + +## What Changes +- [Bullet list of changes] +- [Mark breaking changes with **BREAKING**] + +## Impact +- Affected specs: [list capabilities] +- Affected code: [key files/systems] +``` + +3. **Create spec deltas:** `specs/[capability]/spec.md` +```markdown +## ADDED Requirements +### Requirement: New Feature +The system SHALL provide... + +#### Scenario: Success case +- **WHEN** user performs action +- **THEN** expected result + +## MODIFIED Requirements +### Requirement: Existing Feature +[Complete modified requirement] + +## REMOVED Requirements +### Requirement: Old Feature +**Reason**: [Why removing] +**Migration**: [How to handle] +``` +If multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs//spec.md`—one per capability. + +4. **Create tasks.md:** +```markdown +## 1. Implementation +- [ ] 1.1 Create database schema +- [ ] 1.2 Implement API endpoint +- [ ] 1.3 Add frontend component +- [ ] 1.4 Write tests +``` + +5. **Create design.md when needed:** +Create `design.md` if any of the following apply; otherwise omit it: +- Cross-cutting change (multiple services/modules) or a new architectural pattern +- New external dependency or significant data model changes +- Security, performance, or migration complexity +- Ambiguity that benefits from technical decisions before coding + +Minimal `design.md` skeleton: +```markdown +## Context +[Background, constraints, stakeholders] + +## Goals / Non-Goals +- Goals: [...] +- Non-Goals: [...] + +## Decisions +- Decision: [What and why] +- Alternatives considered: [Options + rationale] + +## Risks / Trade-offs +- [Risk] → Mitigation + +## Migration Plan +[Steps, rollback] + +## Open Questions +- [...] +``` + +## Spec File Format + +### Critical: Scenario Formatting + +**CORRECT** (use #### headers): +```markdown +#### Scenario: User login success +- **WHEN** valid credentials provided +- **THEN** return JWT token +``` + +**WRONG** (don't use bullets or bold): +```markdown +- **Scenario: User login** ❌ +**Scenario**: User login ❌ +### Scenario: User login ❌ +``` + +Every requirement MUST have at least one scenario. + +### Requirement Wording +- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative) + +### Delta Operations + +- `## ADDED Requirements` - New capabilities +- `## MODIFIED Requirements` - Changed behavior +- `## REMOVED Requirements` - Deprecated features +- `## RENAMED Requirements` - Name changes + +Headers matched with `trim(header)` - whitespace ignored. + +#### When to use ADDED vs MODIFIED +- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding "Slash Command Configuration") rather than altering the semantics of an existing requirement. +- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details. +- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name. + +Common pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren’t explicitly changing the existing requirement, add a new requirement under ADDED instead. + +Authoring a MODIFIED requirement correctly: +1) Locate the existing requirement in `openspec/specs//spec.md`. +2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios). +3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior. +4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`. + +Example for RENAMED: +```markdown +## RENAMED Requirements +- FROM: `### Requirement: Login` +- TO: `### Requirement: User Authentication` +``` + +## Troubleshooting + +### Common Errors + +**"Change must have at least one delta"** +- Check `changes/[name]/specs/` exists with .md files +- Verify files have operation prefixes (## ADDED Requirements) + +**"Requirement must have at least one scenario"** +- Check scenarios use `#### Scenario:` format (4 hashtags) +- Don't use bullet points or bold for scenario headers + +**Silent scenario parsing failures** +- Exact format required: `#### Scenario: Name` +- Debug with: `openspec show [change] --json --deltas-only` + +### Validation Tips + +```bash +# Always use strict mode for comprehensive checks +openspec validate [change] --strict --no-interactive + +# Debug delta parsing +openspec show [change] --json | jq '.deltas' + +# Check specific requirement +openspec show [spec] --json -r 1 +``` + +## Happy Path Script + +```bash +# 1) Explore current state +openspec spec list --long +openspec list +# Optional full-text search: +# rg -n "Requirement:|Scenario:" openspec/specs +# rg -n "^#|Requirement:" openspec/changes + +# 2) Choose change id and scaffold +CHANGE=add-two-factor-auth +mkdir -p openspec/changes/$CHANGE/{specs/auth} +printf "## Why\n...\n\n## What Changes\n- ...\n\n## Impact\n- ...\n" > openspec/changes/$CHANGE/proposal.md +printf "## 1. Implementation\n- [ ] 1.1 ...\n" > openspec/changes/$CHANGE/tasks.md + +# 3) Add deltas (example) +cat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF' +## ADDED Requirements +### Requirement: Two-Factor Authentication +Users MUST provide a second factor during login. + +#### Scenario: OTP required +- **WHEN** valid credentials are provided +- **THEN** an OTP challenge is required +EOF + +# 4) Validate +openspec validate $CHANGE --strict --no-interactive +``` + +## Multi-Capability Example + +``` +openspec/changes/add-2fa-notify/ +├── proposal.md +├── tasks.md +└── specs/ + ├── auth/ + │ └── spec.md # ADDED: Two-Factor Authentication + └── notifications/ + └── spec.md # ADDED: OTP email notification +``` + +auth/spec.md +```markdown +## ADDED Requirements +### Requirement: Two-Factor Authentication +... +``` + +notifications/spec.md +```markdown +## ADDED Requirements +### Requirement: OTP Email Notification +... +``` + +## Best Practices + +### Simplicity First +- Default to <100 lines of new code +- Single-file implementations until proven insufficient +- Avoid frameworks without clear justification +- Choose boring, proven patterns + +### Complexity Triggers +Only add complexity with: +- Performance data showing current solution too slow +- Concrete scale requirements (>1000 users, >100MB data) +- Multiple proven use cases requiring abstraction + +### Clear References +- Use `file.ts:42` format for code locations +- Reference specs as `specs/auth/spec.md` +- Link related changes and PRs + +### Capability Naming +- Use verb-noun: `user-auth`, `payment-capture` +- Single purpose per capability +- 10-minute understandability rule +- Split if description needs "AND" + +### Change ID Naming +- Use kebab-case, short and descriptive: `add-two-factor-auth` +- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-` +- Ensure uniqueness; if taken, append `-2`, `-3`, etc. + +## Tool Selection Guide + +| Task | Tool | Why | +|------|------|-----| +| Find files by pattern | Glob | Fast pattern matching | +| Search code content | Grep | Optimized regex search | +| Read specific files | Read | Direct file access | +| Explore unknown scope | Task | Multi-step investigation | + +## Error Recovery + +### Change Conflicts +1. Run `openspec list` to see active changes +2. Check for overlapping specs +3. Coordinate with change owners +4. Consider combining proposals + +### Validation Failures +1. Run with `--strict` flag +2. Check JSON output for details +3. Verify spec file format +4. Ensure scenarios properly formatted + +### Missing Context +1. Read project.md first +2. Check related specs +3. Review recent archives +4. Ask for clarification + +## Quick Reference + +### Stage Indicators +- `changes/` - Proposed, not yet built +- `specs/` - Built and deployed +- `archive/` - Completed changes + +### File Purposes +- `proposal.md` - Why and what +- `tasks.md` - Implementation steps +- `design.md` - Technical decisions +- `spec.md` - Requirements and behavior + +### CLI Essentials +```bash +openspec list # What's in progress? +openspec show [item] # View details +openspec validate --strict --no-interactive # Is it correct? +openspec archive [--yes|-y] # Mark complete (add --yes for automation) +``` + +Remember: Specs are truth. Changes are proposals. Keep them in sync. diff --git a/openspec/project.md b/openspec/project.md new file mode 100644 index 0000000..ca37d85 --- /dev/null +++ b/openspec/project.md @@ -0,0 +1,127 @@ +# Project Context + +## Purpose +Hopp is an open-source **pair programming** app with: +- High-quality, low-latency screen sharing (WebRTC) +- Multi-user rooms (“mob programming”) +- Remote control (mouse/keyboard) and remote cursors +- Team/workspace concepts (users, teams, invitations) + +The desktop app is built with **Tauri** and a separate Rust “core process” (`hopp_core`). WebRTC infrastructure is powered by **LiveKit**. + +## Tech Stack +This repo is a monorepo (Yarn workspaces) with multiple runtimes. + +### Monorepo / Tooling +- **Yarn 4** workspaces (`packageManager: yarn@4.9.2`) with `nodeLinker: node-modules` +- **Node.js**: `v20` (`.nvmrc`) +- **Taskfile** (`task`) is the primary dev/build entrypoint across workspaces +- **Formatting / linting** enforced via pre-commit: + - JS/TS: **Prettier** (`printWidth: 120`) via `pretty-quick --staged` + - Rust: `cargo fmt` (per-crate) + - Go: `golangci-lint` + `gofmt` (via `.golangcli.yml`) + +### Backend (`/backend`) +- **Go 1.25** (`go.mod`) +- HTTP framework: **Echo** +- Datastores: + - **PostgreSQL** (primary) + - **Redis** (pub/sub + realtime event fanout; used for call notifications, etc.) +- API spec: **OpenAPI** (`backend/api-files/openapi.yaml`) +- ORM / persistence: **GORM** (Postgres driver; SQLite driver also present for testing) +- Auth: JWT + social auth (Google/GitHub via Goth) +- Integrations observed in deps: + - Payments: **Stripe** + - Observability: **Sentry**, **Prometheus** + - Comms: **Slack**, **Resend** (email), Telegram notifications + - Realtime: **Gorilla WebSocket**, **LiveKit server SDK** + +### Desktop App (`/tauri`) +- **Tauri 2** (Rust backend + Vite frontend) +- Rust crate: `tauri/src-tauri` (Tauri plugins: updater, autostart, global shortcut, deep-link, etc.) +- Frontend: **React + TypeScript + Tailwind CSS** (Vite) +- Observability: Sentry (optional via `SENTRY_AUTH_TOKEN`) +- Updater: GitHub Releases (`latest.json` endpoint in `tauri.conf.json`) + +### Core Process (`/core`) +- **Rust** “core engine” (`hopp_core`) handling: + - Screen capture + streaming integration with LiveKit + - Remote cursor rendering overlay + - Remote input control (mouse/keyboard) +- The Tauri app launches the core process and communicates over a socket. + +### Web App (`/web-app`) +- **React + TypeScript** (Vite) +- Routing: React Router (`react-router-dom`) +- Data fetching: TanStack React Query (and generated OpenAPI types) +- UI: Radix + Headless UI; styling via Tailwind CSS +- Build output is bundled as a single-file asset and injected into the backend’s `backend/web/*.html` + +### Documentation (`/docs`) +- **Astro + Starlight** (Tailwind) + +## Project Conventions + +### Code Style +- **Prettier** is the source of truth for JS/TS formatting (`.prettierrc`, 120 cols). +- **Rust** must be formatted with `cargo fmt` (pre-commit hook runs per crate: `core/`, `tauri/src-tauri/`). +- **Go** must be formatted with `gofmt` and pass `golangci-lint` (enabled linters are `govet`, `ineffassign`, `unused`, `staticcheck`). +- **Imports / aliases**: + - JS/TS code uses `@` as an alias to `src/` (Vite config in both `tauri/` and `web-app/`). +- **Frontend security (XSS/URLs)**: + - Prefer normal React bindings (`{value}`) over HTML injection. + - Avoid `dangerouslySetInnerHTML` unless sanitized (e.g. DOMPurify). + - Prefer `new URL()` / `URLSearchParams` for building URLs and query params over string concatenation. + +### Architecture Patterns +- **Three-layer product shape**: + - `core/`: low-level capture/remote-control engine (Rust) + - `tauri/`: desktop shell + UI (Tauri + React) + - `backend/`: API + auth + billing + integrations (Go) + - `web-app/`: browser app/UI that can also be served/embedded via the backend +- **API contracts**: + - The OpenAPI spec (`backend/api-files/openapi.yaml`) is treated as the contract; type-safe clients are generated from it. +- **Local dev ergonomics**: + - `task` is used to coordinate multi-service dev (backend + livekit + webapp builds). + - Web app assets are built and injected into `backend/web/` for backend-driven pages. + +### Testing Strategy +- **Backend (Go)**: + - Integration tests live under `backend/test/integration/`. +- **Core (Rust)**: + - Rust unit tests are limited; there are **visual integration tests** under `core/tests/` (see `core/tests/README.md`). +- **Frontend (web-app/tauri)**: + - Linting + typechecking + manual QA are currently the primary guardrails (no dedicated unit test runner is configured in package manifests). + +### Git Workflow +- Use feature branches and open PRs against the default branch. +- Expect pre-commit hooks to run on commit (Prettier, `cargo fmt`, `golangci-lint`). +- Keep commits focused and descriptive; avoid mixing formatting-only changes with behavioral changes unless necessary. + +## Domain Context +- **Rooms**: sessions where multiple participants can join for pairing/mobbing. +- **Sharer vs controller**: + - The **sharer** is streaming their screen and can allow remote control. + - **Controllers** view the stream and can send input events (mouse/keyboard) over WebRTC data channels. +- **LiveKit**: + - Used for media (video) and data channels (control events, cursor positions, etc.). +- **Desktop UX**: + - Tauri provides tray/window surfaces; `hopp_core` does capture + overlay rendering and interacts with OS APIs. + +## Important Constraints +- **Cross-platform desktop**: macOS/Windows/Linux constraints and platform APIs matter (capture, overlays, input simulation). +- **Local HTTPS requirement**: backend local dev uses mkcert-generated certs for HTTPS/websocket flows (WebKit requirements). +- **Fixed dev port expectations**: Tauri dev expects a fixed Vite dev port (default `1420`). +- **Bundling constraint**: the desktop bundle includes the `hopp_core` binary as an external resource. +- **License**: AGPL-3.0-only (see root `package.json` / repo license). + +## External Dependencies +- **LiveKit** (self-hosted or cloud) for WebRTC rooms/streaming +- **PostgreSQL** database +- **Redis** for pub/sub and realtime events +- **Sentry** for error reporting (Go + desktop UI) +- **PostHog** for product analytics (web/desktop UI) +- **Stripe** for billing/subscriptions +- **Slack** integration +- **Resend** for transactional email +- **GitHub Releases** for Tauri updater artifacts (`latest.json`) From 61072c912b58559982627fc2b9de0cb376f73b40 Mon Sep 17 00:00:00 2001 From: Iason Paraskevopoulos Date: Tue, 27 Jan 2026 18:06:24 +0000 Subject: [PATCH 2/2] add core agents.md file --- core/AGENTS.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 core/AGENTS.md diff --git a/core/AGENTS.md b/core/AGENTS.md new file mode 100644 index 0000000..540f0de --- /dev/null +++ b/core/AGENTS.md @@ -0,0 +1,26 @@ +# Core Agent Guide + +## Scope +This directory contains the Rust screen capture and remote control engine (`hopp_core`) plus supporting crates (`socket_lib`, `sentry_utils`). + +## Key Commands +- See `Taskfile.yml` in this directory for the full, up-to-date command list. + +## Formatting & Linting +- `cargo fmt` is required (pre-commit formats staged Rust files). +- CI runs `cargo fmt --all -- --check` and `cargo clippy -D warnings`. +- Rust edition: 2021. + +## Testing +- Do not run core tests as an agent. +- For validation, only use build commands (see `Taskfile.yml`). +- Full testing details live in `tests/README.md`. + +## Conventions & Structure +- Platform-specific modules live in `src/**/{linux,macos,windows}.rs`. +- Core subsystems: `capture/`, `graphics/`, `input/`, `room_service/`. +- Logging uses `env_logger`; set `RUST_LOG=hopp_core=info` (use `debug` only when needed). + +## Related Docs +- `README.md` for architecture and diagrams. +- `tests/README.md` for test setup and commands (manual only).