Thank you for investing time in W Agent. This project is intended as a serious, self-hosted system—not a demo toy. Contributions should preserve safety defaults, keep the provider adapter clean, and leave CI green.
- Read docs/security.md. Changes that weaken injection handling, approval, or rate limits need explicit justification.
- Read docs/architecture.md. Prefer extending
WhatsAppProviderover leaking Baileys or Graph types into agent/MCP code. - Use a dedicated WhatsApp number for any live bridge testing. Ban risk is real (docs/providers.md).
Requirements: Node.js 22+, pnpm 9+, Docker (Compose services and Vitest testcontainers).
git clone https://github.com/Chessing234/w-agent.git
cd w-agent
pnpm install
cp .env.example .env
# Set at least OPENAI_API_KEY for agent/embed paths you exercise locally
docker compose up -d postgres redis
pnpm migrate
pnpm dev # bridge + workers
pnpm dashboard:dev # optional UI on DASHBOARD_PORTUseful checks:
pnpm lint
pnpm typecheck
pnpm test # needs Docker for Postgres suites
pnpm test:coverage # enforces ≥80% lines/functions on src/safety + src/agent| Area | Expectation |
|---|---|
| Language | TypeScript (NodeNext ESM), Zod for env config |
| Formatting | Prettier via ESLint (pnpm lint:fix) |
| Logging | Pino; no secrets in log fields |
| WhatsApp I/O | Only through WhatsAppProvider |
| Outbound | Draft/outbox by default; do not add ungated send paths |
| Migrations | SQL via node-pg-migrate; both Up and Down sections |
| Tests | Vitest; Postgres via @testcontainers/postgresql for storage/lifecycle |
If you add WhatsApp capability:
- Extend the interface in
src/bridge/provider.tswhen the capability is cross-backend. - Implement on Baileys and/or Cloud API as appropriate; stub or reject clearly when unsupported.
- Keep
src/agent,src/queue, andsrc/mcpfree of vendor SDK imports.
Do not “fix” user friction by:
- Skipping the injection guard on inbound third-party content
- Auto-approving drafts globally
- Disabling quiet hours / daily caps by default
- Returning raw env secrets to the model
If a feature needs a dangerous escape hatch, gate it behind an explicit, documented env flag defaulting to off.
| Suite | Role |
|---|---|
Unit (tests/*.test.ts) |
Engagement matrix, guard classifier, rate limiter, tools, MCP, Cloud API normalize |
| Storage / lifecycle | Real Postgres (testcontainers): persist, outbox, embed/search, full draft→approve→send |
| Coverage gate | src/safety/** and src/agent/** (OpenAI SDK adapter provider.ts excluded) |
When changing behavior, add or update tests in the same PR. CI runs lint, typecheck, and pnpm test:coverage on Node 22.
- Scope — One concern per PR when practical (feature, fix, docs, chore).
- Description — What changed, why, risk notes (especially send path / auth / migrations).
- Verification — Commands you ran (
pnpm lint,pnpm test, manual QR check, etc.). - Docs — Update README or
docs/when behavior or setup changes. - Secrets — Never commit
.env, auth directories, tokens, or production database dumps.
Commit messages: short imperative summary; explain why in the body when the diff is non-obvious.
- Bug reports: expected vs actual, version/commit, provider (
baileys/meta), relevant logs with secrets redacted. - Feature requests: problem statement first; propose how it fits the provider adapter and approval model.
- Ban / disconnect reports against Baileys: useful as operational data, but usually not a patchable application CVE—see docs/security.md.
Be precise and respectful in review. Assume good intent; require evidence for security-sensitive claims. Harassment or deliberate sabotage of safety controls will not be accepted.
By contributing, you agree that your contributions are licensed under the same MIT License that covers this repository.