Skip to content
Personal Web AlphaContent reviewed: 2026-09-23View Markdown

6.8 Testing and contributing

Identify the boundaries affected by a change before choosing tests. Assertions that simply copy constants from source code do not replace behavioral tests.

CommandCoverage
pnpm test:contractShared contracts and parsing
pnpm test:workBackend business logic and the database
pnpm test:nativeDSH adapter and execution authorization
pnpm test:bindingsClient bindings and interaction state
pnpm test:referencesRead-only MCP service and protocol
pnpm test:prototypeShared scripts and prototype logic
pnpm typecheckBuild and root type checking
pnpm check:clientClient build boundaries

Choose an environment for the check

PurposeRecommended environmentWhat to verify
Daily development and interaction debuggingNative Teloa and Harness with Docker PostgreSQLLocal paths, programs, permissions, and Web behavior
Backend integration and CI buildsIsolated databases or containers, according to test dependenciesBusiness rules, transactions, initialization, and dependency completeness
npm installation acceptanceA clean target system with the actual distribution packageIndependence from source and development caches, local execution, and service lifecycle
Compose deployment regressionApplication, Harness, and database in containersStartup, health checks, persistent volumes, and explicitly mounted files

Passing inside a container does not replace native installation acceptance. A successful shell command in a Linux container does not verify native macOS programs, Windows permissions, or the user's PATH. Record WSL2 and native Windows results separately as well.

npm release acceptance requirements

The npm installer has not been released. These are future release requirements, not completed test results:

  1. Install the actual npm tarball on a target system without source code, global pnpm, compilers, or existing development caches. After publication, install the same version from the registry.
  2. Check that the frontend, Harness, reference material, and presets are complete. Verify service readiness separately from model configuration.
  3. Test ordinary conversations and AI colleague tasks separately: read and write an authorized local directory, invoke a native program, and verify the resulting files. Also check unauthorized tools, out-of-scope writes, and revoked grants.
  4. Cover non-ASCII paths and spaces, read-only directories, missing PATH programs, port conflicts, and repeated or concurrent startup. Check error messages and log redaction.
  5. Verify that closing the initiating terminal leaves the service running, stop and restart preserve records, and npm updates or temporary-cache cleanup do not break the running service.
  6. Rehearse backup, restore, compatible upgrades, and data retention after uninstall. Restoring must not automatically repeat external actions. Claim support only for tested operating systems, CPUs, and Node versions.

When a change is complete

  1. For a bug fix, first provide a reproduction that fails.
  2. Run the affected tests and identify any environment-dependent checks you did not run.
  3. For changes across packages, verify their integration with a real database or host.
  4. Check user-facing interactions in a browser, including waiting, failure, and recovery.
  5. Update the documentation, version boundaries, and change records.

Database tests may create containers or temporary schemas. Check the environment and isolation requirements first. Tests using real models incur costs and must not run automatically as ordinary static checks.

Contribute

Use the source repository's contribution channels to submit a reproducible issue or change, following its CONTRIBUTING.md. Describe the trigger, resulting behavior, test results, and known limitations. Do not include runtime directories, personal photos, credentials, or data unrelated to the change.

One person, leading an AI team