ci: switch to Biome (#20)

* build: switch to Biome from ESLint and Prettier

* style: change font-family quotes from single to double in index.css

* style: apply Biome formatting and linting rules

- Remove explicit undefined assignments in variable declarations
- Use class name instead of 'this' in static methods
- Convert value imports to type imports where appropriate
- Use 'const' instead of 'let' for variables not reassigned

* refactor: add explicit type to error boundary reset button

* fix: add type="button" to button elements in web components

Prevent implicit form submission by explicitly setting button type.

* feat: add keyboard accessibility to sidebar session items

Add role='button', tabIndex, and onKeyDown handler to session items
in the sidebar to enable keyboard navigation with Enter and Space keys.
This improves accessibility for users relying on keyboard input.

* refactor: replace div with button in sidebar for semantic HTML

Use proper semantic HTML elements for better accessibility instead of div with role attribute.

* chore: update opencode command definitions and rename directory

- Rename .opencode/commands/ to .opencode/command/
- Update changelog-update.md to curate [Unreleased] section only
- Enhance commit.md with detailed conventional commits guidelines

* style: add explicit type attribute to button elements

- Add type="button" to session navigation buttons in sidebar component
- Ensures buttons do not accidentally submit forms if context changes
- Improves code clarity and satisfies linting requirements

* style: format test/utils.ts with biome

* style: add curly braces to forEach callback

* style: format arrow function braces in test utils

* style(test/utils): add braces to arrow functions in forEach

Biome requires braces for arrow functions in forEach callbacks to improve code consistency and readability.

* refactor: simplify CustomError class by removing redundant constructor

* fix: correct Symbol.dispose syntax in web server test

Symbol.dispose should not have quotes around 'dispose'.

* chore: remove incomplete DOM vs serialize addon comparison test

* fix: add null check for root element in client

Prevent runtime error by throwing a clear error message if the root DOM element is not found.

* refactor(web/client): remove performance monitoring

Remove unused performance monitoring utilities and initialization
from the web client, including the PerformanceMonitor class and
web vitals tracking functionality.

* ci: update test fixtures for Biome linting

* refactor: change RouteBuilder from class to object

* fix(test): prevent runtime error in e2e fixtures port parsing

Ensure urlMatch[1] exists before parsing to avoid parseInt(undefined).
This fixes a potential bug where the regex might not capture the port group.

* ci: switch to Biome

Apply Biome linting and formatting rules to the codebase, including:
- Modern Node.js imports (node:path, etc.)
- Template literals for string concatenation
- Optional chaining for safer property access
- Explicit radix for parseInt
- Removal of non-null assertions where safe

* style: remove unnecessary non-null assertion from WebSocket constructor

* build: update lint ignore to biome in xterm-test-helpers.ts

Switch the lint ignore directive from ESLint to Biome syntax for the control characters regex in the stripAnsi function.

* style: format code with biome

* ci: replace combined quality job with separate biome checks

- Split the 'quality' matrix job into individual jobs for test, typecheck, lint, format:check, and test:e2e
- This allows parallel execution and clearer failure identification for each check

* chore: switch development environment from nix flake to devenv

Replace flake.nix with devenv.nix and devenv.yaml for improved dev env management.
Update .envrc to use devenv instead of flake.
Adjust .gitignore to ignore devenv and direnv files.
Update biome to version 2.3.13 and adjust package.json scripts.

* Add flake symlinks for devenv

* revert: Add flake symlinks for devenv

* ci: switch CI to use devenv with biome

- Update CI workflow to use devenv shell instead of nix develop
- Add biome and bashInteractive packages to devenv.nix
- Change nixpkgs input in devenv.yaml to nixos-unstable
- Update devenv.lock accordingly

* ci: add step to install devenv in CI workflow

Install devenv using nix profile install nixpkgs#devenv to enable
running bun commands within devenv shell environment.

* ci: update workflow quality checks to run format instead of format:check

Switch from format:check to format in the CI matrix to align with
the transition to biome for code formatting.

* ci: switch nix-flake-test job from matrix to sequential steps

Remove the strategy matrix from the nix-flake-test job and replace it with
individual steps for each quality check (test, typecheck, lint, format,
test:e2e). This changes the execution from parallel matrix jobs to
sequential steps in a single job.

* build: add bun to devenv packages

* ci: update Bun version and fix nix profile command

- Bump Bun version from 1.3.6 to 1.3.8
- Change nix profile install to add for devenv

* build: configure Biome for linting and formatting

- Enable JavaScript language support in devenv
- Add Bun 1.3.8 via bun.enable
- Remove direct bun package from packages
- Add format and format:fix scripts using Biome
- Remove node_modules/.bin from PATH in enterShell

* build(devenv): add playwright browser support

Add let block to dynamically determine chromium and firefox revisions from playwright-driver.browsers.json.
Include playwright-driver.browsers in packages and set PLAYWRIGHT_BROWSERS_PATH, PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH, and PLAYWRIGHT_FIREFOX_EXECUTABLE_PATH environment variables.

This enables running Playwright tests in the development environment.

* build: switch CI to use Biome for linting and formatting

- Update CI workflow to run lint, format, and typecheck commands directly
- Add unittest script in package.json and devenv.nix for consistency
- Update test:all to use unittest instead of bun test

* ci: update workflow for Biome integration

- Use 'unittest' script instead of 'bun test' for consistency in devenv job
- Temporarily disable Magic Nix Cache (commented out)

* ci: remove commented Magic Nix Cache steps

* docs: update documentation and configuration for Biome linting/formatting

- Add AGENTS.md with comprehensive project guidelines including Biome-specific rules
- Update README.md with corrected slash commands and build instructions
- Include AGENTS.md in OpenCode instructions

* docs: add note about bun command failures on NixOS

* ci: remove unnecessary id-token permission from Devenv CI job

The permission was added for FlakeHub cache authentication, but the job
does not use FlakeHub. Removing to avoid granting excessive permissions.

* ci: switch workflow to use bun commands directly

Remove devenv scripts and update CI to call bun commands explicitly,
integrating Biome for linting and formatting.

* chore: remove AGENTS.md and update instructions

Remove the AGENTS.md file which contained detailed guidelines for agents,
and update .opencode/opencode.json to remove it from the instructions array,
consolidating agent instructions into README.md.

* style: apply biome formatting and minor fixes to test files

- Sort imports in test files according to biome rules
- Increase timeouts in e2e tests for stability
- Add NaN check in port parsing to prevent errors

* style: format code with biome

* docs: add unit and e2e test commands to README

- Added bun unittest command for running unit tests
- Added bun test:e2e command for running end-to-end tests

Author: MBanucu

.devenv.flake.nix

@@ -1 +1,12 @@
-use flake
+#!/usr/bin/env bash
+
+export DIRENV_WARN_TIMEOUT=20s
+
+eval "$(devenv direnvrc)"
+
+# `use devenv` supports the same options as the `devenv shell` command.
+#
+# To silence all output, use `--quiet`.
+#
+# Example usage: use devenv --quiet --impure --option services.postgres.enable:bool true
+use devenv

.envrc

@@ -16,7 +16,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        quality: [test, typecheck, lint, format:check, test:e2e]
+        quality: [test, typecheck, lint, format, test:e2e]
     runs-on: ubuntu-24.04
     steps:
       - name: Checkout
@@ -25,7 +25,7 @@ jobs:
       - name: Setup Bun
         uses: oven-sh/setup-bun@v2
         with:
-          bun-version: 1.3.6
+          bun-version: 1.3.8
 
       - name: Cache Bun dependencies
         uses: actions/cache@v5
@@ -58,36 +58,34 @@ jobs:
         uses: actions/dependency-review-action@v4
 
   nix-flake-test:
-    strategy:
-      fail-fast: false
-      matrix:
-        quality: [quality, test, test:e2e]
-    name: Nix Flake CI
+    name: Devenv CI
     runs-on: ubuntu-latest
     permissions:
-      id-token: write # Required for FlakeHub cache authentication
       contents: read
     steps:
       - name: Checkout repository
         uses: actions/checkout@v6
       - name: Install Determinate Nix
         uses: DeterminateSystems/determinate-nix-action@v3
-      - name: Enable Magic Nix Cache
-        uses: DeterminateSystems/magic-nix-cache-action@v13
-        with:
-          use-flakehub: false
+      - name: Install devenv
+        run: nix profile add nixpkgs#devenv
       - name: Cache Bun dependencies
         uses: actions/cache@v5
         with:
           path: ~/.bun/install/cache
           key: ${{ runner.os }}-bun-${{ hashFiles('**/bun.lock') }}
           restore-keys: |
             ${{ runner.os }}-bun-
-      - name: Install dependencies (Nix devShell)
-        run: nix develop .# --command bun ci
-
-      - name: Build (Nix devShell)
-        run: nix develop .# --command bun build:prod
+      - name: Build (Devenv shell)
+        run: devenv shell -- bun build:prod
 
-      - name: Quality checks (Nix devShell)
-        run: nix develop .# --command bun ${{matrix.quality}}
+      - name: Quality checks (bun test)
+        run: devenv shell -- bun unittest
+      - name: Quality checks (typecheck)
+        run: devenv shell -- bun typecheck
+      - name: Quality checks (lint)
+        run: devenv shell -- bun lint
+      - name: Quality checks (format)
+        run: devenv shell -- bun format
+      - name: Quality checks (test:e2e)
+        run: devenv shell -- bun test:e2e

.github/workflows/ci.yml

@@ -30,7 +30,6 @@ report.[0-9]_.[0-9]_.[0-9]_.[0-9]_.json
 .eslintcache
 .cache
 *.tsbuildinfo
-.direnv
 
 # IntelliJ based IDEs
 .idea
@@ -40,3 +39,14 @@ report.[0-9]_.[0-9]_.[0-9]_.[0-9]_.json
 
 # Log files
 *.log
+
+# Devenv
+.devenv*
+devenv.local.nix
+devenv.local.yaml
+
+# direnv
+.direnv
+
+# pre-commit
+.pre-commit-config.yaml

.gitignore

@@ -1,65 +1,64 @@
 ---
-description: Analyzes recent git commits, determines version bump, and updates CHANGELOG.md following Keep a Changelog and Semantic Versioning guidelines.
+description: Analyzes recent git commits, curates notable user-facing changes, and updates/merges them into the [Unreleased] section of CHANGELOG.md following Keep a Changelog guidelines.
 subtask: true
 ---
-
-Follow these steps to update the CHANGELOG.md file based on recent changes in the git history.
-
-First, review the key guidelines from Keep a Changelog (https://keepachangelog.com/en/1.0.0/):
-
-- Use CHANGELOG.md as the file name.
-- Follow reverse chronological order with the latest version first.
-- Each version entry: [version] followed by ISO 8601 date (YYYY-MM-DD).
-- Include an [Unreleased] section at the top for upcoming changes.
-- Sections: Added (new features), Changed (existing functionality), Deprecated, Removed, Fixed (bugs), Security (vulnerabilities).
-- Best practices: Adhere to Semantic Versioning; keep human-readable; include release dates; make linkable; avoid empty sections; mark yanked releases.
-
-Next, review Semantic Versioning 2.0.0 (https://semver.org/spec/v2.0.0.html):
-
-- Version format: MAJOR.MINOR.PATCH (e.g., 1.2.3).
-- Pre-release: Append -alpha.1 etc.; build metadata: +001 (ignored in precedence).
-- Increment: MAJOR for incompatible API changes; MINOR for backward-compatible additions/deprecations; PATCH for backward-compatible bug fixes.
-- Version 0.y.z for unstable initial development.
-- Precedence: Compare MAJOR/MINOR/PATCH numerically; pre-releases lower than normal; compare pre-release identifiers lexically/numerically.
-
-Now, analyze the project:
-
-1. Get the current CHANGELOG.md content: @CHANGELOG.md
-
-2. Identify the last released version from CHANGELOG.md or git tags: !git describe --tags --abbrev=0 || echo "0.0.0"
-
-Let last_version = output of above.
-
-3. Get commit messages since last version: !git log --pretty=format:"%s" ${last_version}..HEAD
-
-If no commits, respond: "No changes since last version. No update needed."
-
-4. Classify each commit message into categories (Added, Changed, Deprecated, Removed, Fixed, Security). Use conventional commit prefixes if present (feat: → Added, fix: → Fixed, breaking: → Changed with MAJOR bump).
-
-5. Determine version bump:
-   - MAJOR if any breaking changes.
-   - MINOR if new features (Added) but no breaking.
-   - PATCH if only fixes/changes without new features or breaking.
-   - If pre-release needed, append -alpha.1 etc. (decide based on stability).
-
-Compute next_version by incrementing from last_version accordingly.
-
-6. Group changes under appropriate headings. Omit empty sections.
-
-7. Get today's date: !date +%Y-%m-%d
-
-8. Decide on release strategy:
-   - For unreleased changes: Add or update the [Unreleased] section at the top.
-   - For a new release: Create new section ## [next_version] - today's_date
-
-Add the grouped changes to the appropriate section.
-
-If [Unreleased] exists, incorporate or replace it.
-
-9. Preserve existing CHANGELOG content, inserting the new section after the header or updating [Unreleased] as appropriate.
-
-10. Output the full updated CHANGELOG.md content.
-
-If $ARGUMENTS provided, use it as additional changes or override (e.g., /update-changelog "Added: new feature").
-
-Ensure the update is accurate, concise, and follows the guidelines exactly.
+Follow these steps to curate and update only the [Unreleased] section of CHANGELOG.md based on recent git history.
+
+Key guidelines from Keep a Changelog[](https://keepachangelog.com/en/1.1.0/):
+
+- Use human-readable, curated entries — never dump raw commit messages.
+- Group related commits into concise, clear bullet points.
+- Rephrase for end-user clarity (avoid internal developer jargon).
+- Only include notable changes that affect users (behavior, features, UI, API, performance, security, etc.).
+- Standard sections: Added, Changed, Deprecated, Removed, Fixed, Security.
+- Omit any empty sections.
+- Always maintain an [Unreleased] section at the top for upcoming changes.
+- Do not create dated release sections or perform any version bumping.
+
+Steps:
+
+1. Read the current CHANGELOG.md: @CHANGELOG.md
+
+2. Identify the latest released version (to know the range of new commits):
+   !git describe --tags --abbrev=0 2>/dev/null || echo "0.0.0"
+   Let last_version = the output (strip any leading 'v' if present).
+
+3. Fetch commits since the last release (including bodies for context):
+   !git log v${last_version}..HEAD --pretty=format:"%H%n%s%n%b%n---COMMIT_END---"
+
+   If no commits, respond: "No changes since last release. No changelog update needed."
+
+4. Analyze the commits for user-impacting changes:
+   - Prefer Conventional Commits prefixes as guides:
+     - feat: or feat!: → Added (new features)
+     - fix: → Fixed (bug fixes)
+     - perf: → Changed (performance improvements)
+     - docs: → Added or Changed only if user-visible
+     - refactor:, style:, test:, chore:, ci:, build: → ignore unless they have clear user impact
+   - Look for breaking changes (e.g., BREAKING CHANGE: footers or obvious removals) → place in Changed, Removed, or Deprecated as appropriate.
+   - For non-conventional commits, intelligently judge based on content and user impact.
+   - Always ignore purely internal noise: whitespace fixes, merge commits, minor refactors, test/CI additions, comment-only changes, etc.
+
+5. Curate entries:
+   - Group similar/related commits into single bullets.
+   - Rephrase clearly and concisely for end users (e.g., "Add support for dark mode with new settings toggle" instead of raw commit titles).
+   - Include scopes if helpful (e.g., "(API)" or "(UI)").
+   - If $ARGUMENTS is provided, treat it as manual overrides/additions — insert the specified entries directly into the appropriate sections.
+
+6. Update CHANGELOG.md:
+   - Preserve all existing content exactly.
+   - Ensure an [Unreleased] section exists at the top (after the main header).
+   - Add the new curated bullets under the correct sections.
+   - Merge thoughtfully with any existing [Unreleased] entries (avoid duplicates; combine similar items).
+   - Omit any sections that end up empty.
+
+7. Edit CHANGELOG.md with the curated updates.
+
+8. Respond with a concise summary, e.g.:
+   "Updated CHANGELOG.md [Unreleased] section:
+   - Added: 3 new features
+   - Fixed: 2 bugs
+   - Changed: 1 performance improvement"
+
+Do not output the full updated CHANGELOG.md content.
+Ensure all entries are accurate, user-focused, and strictly follow Keep a Changelog style.

.opencode/command/changelog-update.md

@@ -15,7 +15,8 @@ Please perform the following steps carefully to create high-quality git commits:
 3. Deeply analyze the purpose, impact, and nature of all changes in the codebase, including staged, unstaged, and untracked files.
 
 4. Determine the optimal commit strategy based on the analysis:
-   - Identify logical groups of changes (e.g., by feature, bug fix, refactor, documentation). Changes should be grouped if they are cohesive and achieve a single purpose.
+    - Identify logical groups of changes (e.g., by feature, bug fix, refactor, documentation). Changes should be grouped if they are cohesive and achieve a single purpose.
+    - When grouping changes, prefer separating documentation-only updates (use `docs:`) from code/behavior changes.
    - Decide whether to:
      - Commit staged changes as-is if they form a complete, logical unit.
      - Stage additional unstaged/untracked changes that belong to the same logical group as staged changes.
@@ -25,30 +26,50 @@ Please perform the following steps carefully to create high-quality git commits:
    - Prioritize small, atomic commits that are easy to review and revert.
    - If no changes are ready or logical to commit, inform the user and suggest actions (e.g., staging specific files).
 
-5. For each identified commit group:
-   - Stage the relevant files if not already staged (using `git add <files>` or `git add -A` if appropriate).
-   - Craft a detailed commit message that strictly follows the Conventional Commits specification (v1.0.0).
+ 5. For each identified commit group:
+    - Stage the relevant files if not already staged (using `git add <files>` or `git add -A` if appropriate).
+    - Craft a detailed commit message that **strictly** follows the Conventional Commits specification (v1.0.0).
 
-     Before writing the message, carefully read and internalize the complete specification here:  
-     https://www.conventionalcommits.org/en/v1.0.0/#specification
+      Before writing the message, carefully read and internalize the complete specification:  
+      https://www.conventionalcommits.org/en/v1.0.0/#specification
 
-     Key guidelines from the spec:
-     - Use the format: `<type>[optional scope]: <description>`
-     - Allowed types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert (and others if justified)
-     - Subject line: imperative tense, no capitalization, ≤50 characters
-     - Optional body: explain **what** and **why** (not how), wrap at 72 characters
-     - Optional footer: for BREAKING CHANGE, references to issues, etc.
+      Key guidelines from the spec:
+      - Format: `<type>[optional scope]: <description>`
+      - Subject line: imperative mood (e.g. "add", "fix", "update"), **no leading capital**, ≤50–72 characters
+      - Optional body: explain **what** changed and **why** (not how), wrap at 72 characters
+      - Optional footer: BREAKING CHANGE notices, issue references (e.g. Closes #123), etc.
 
-     Analyze the project to determine its type (e.g., CLI tool, library, web app, etc.). Distinguish between changes noticeable to end-users (e.g., new features, bug fixes in user-facing behavior) and internal changes (e.g., developer tools, refactors, documentation). Use 'feat' or 'fix' only for changes that are noticeable to the end-user. For internal code changes, enhancements to development workflows, or non-user-facing improvements that benefit developers but not end-users, use types like 'chore', 'refactor', 'docs', or similar.
+      **Recommended types and when to use them** (based on the spec and common conventions like Angular):
+      - `feat:`     – Introduces a **new feature** noticeable to **end-users** (correlates to MINOR in SemVer).
+      - `fix:`      – Patches a **bug** noticeable to **end-users** (correlates to PATCH in SemVer).
+      - `docs:`     – **Documentation only** changes. Use this for:
+        - Updates to README, CHANGELOG, CONTRIBUTING, API docs, wiki pages, etc.
+        - Adding/fixing/updating inline code comments, docstrings, JSDoc, godoc, annotations, etc.
+        - Improving examples, tutorials, or usage guides.
+      - `style:`    – Changes that do **not** affect code behavior (formatting, whitespace, semicolons, quotes, etc.).
+      - `refactor:` – Code restructuring that **neither** fixes a bug **nor** adds a feature (improves readability, maintainability, no observable behavior change).
+      - `perf:`     – Performance improvements (observable speed/memory gains).
+      - `test:`     – Adding or correcting tests (no production code change).
+      - `build:`    – Changes affecting build system, external dependencies, or toolchain (npm, webpack, Docker, etc.).
+      - `ci:`       – Changes to CI/CD configuration & scripts (GitHub Actions, Travis, etc.).
+      - `chore:`    – Maintenance tasks or changes that **do not** modify src/test/docs files (e.g. .gitignore updates, script tweaks, dependency bumps with no code impact).
+      - `revert:`   – Reverts a previous commit (include footer referencing the reverted SHA).
 
-     Choose the most appropriate type and scope based on the changes. Make the message clear, professional, and informative for future readers (including changelogs and release notes).
+      **Important distinctions**:
+      - Use `docs:` (not `refactor:`) for adding/fixing comments or docstrings — they are considered documentation.
+      - Use `docs:` only when changes are **exclusively** or **primarily** documentation-related.
+      - Reserve `feat:` and `fix:` for changes that affect **end-user** experience or public API behavior.
+      - For internal-only improvements (developer experience, non-user-facing), prefer `refactor:`, `chore:`, `perf:`, etc.
+      - If multiple aspects exist, prefer **smaller, atomic commits** with one clear type each.
 
-   - Commit the staged changes with the crafted message using `git commit -m "<message>"` (include body and footer in the message if needed, using newlines).
+      Analyze the project context (CLI, library, web app, etc.) to choose the most appropriate type/scope. Make messages clear, professional, and valuable for changelogs, release notes, and future readers.
+
+    - Commit the staged changes with the crafted message using `git commit -m "<message>"` (include body and footer in the message if needed, using newlines).
 
 6. If multiple commits are needed, perform them sequentially, restaging as necessary after each commit.
 
-7. After all commits, run `git status` again to confirm the repository state and summarize what was committed.
+7. After all commits, run `git status` again to confirm the repository state and summarize: 'Committed X changes as [type(scope)]: [short description]' for each commit.
 
 8. If any changes were not committed (e.g., not ready or irrelevant), explain why and suggest next steps.
 
-Prioritize accuracy, completeness, and adherence to the Conventional Commits standard. Make decisions autonomously based on best practices for clean commit history.
+Prioritize accuracy, completeness, and adherence to the Conventional Commits standard. Make decisions autonomously based on best practices for clean commit history.

.opencode/command/commit.md

@@ -68,7 +68,8 @@ This plugin provides slash commands that can be used in OpenCode chat:
 
 | Command                    | Description                                        |
 | -------------------------- | -------------------------------------------------- |
-| `/pty-open-background-spy` | Get the URL of the running PTY web server instance |
+| `/pty-open-background-spy` | Open the PTY web server interface in the browser   |
+| `/pty-show-server-url`     | Show the URL of the running PTY web server instance |
 
 ## Web UI
 
@@ -298,8 +299,12 @@ Use `pty_kill` with `cleanup=true` to remove completely.
 git clone https://github.com/shekohex/opencode-pty.git
 cd opencode-pty
 bun ci          # install packages from bun.lock
-bun quality     # Quality check
+bun lint        # Runs Biome linting checks
+bun format      # Runs Biome formatting checks
+bun typecheck   # Runs TypeScript type checking
 bun build:dev   # Build the React app for development
+bun unittest    # Runs the unit tests
+bun test:e2e    # Runs the e2e tests
 ```
 
 To load a local checkout in OpenCode: