Skip to main content

​
Contributing

WednesdayAI welcomes contributions — bug fixes, new plugins, channel adapters, hook packs, and documentation.

​
Before you start

Read CONTRIBUTING.md for the full guide. Key points:
  • Fork philosophy: lean core, highly extensible. If it can be a plugin, it should be.
  • Stability over features: we prefer a stable, well-tested core over feature parity with upstream openclaw.
  • Extension scope: new extensions use @wednesdayai/*, not @openclaw/*.
  • Plugin version pinning: bundled extensions carry no openclaw peer dependency — fork-base compatibility is expressed by our SemVer version and the forkBase marker in dist/build-info.json (ADR 0005). Third-party plugins target our published SemVer, never an upstream 2026.x range.

​
Setup

​
Development workflow

1

Create a branch from main

Branch first — do not work directly on main.
2

Write tests first

TDD is preferred. Colocate *.test.ts next to the source.
3

Implement the change

Keep changes scoped; do not bundle unrelated refactors.
4

Run checks before committing

5

Commit with the committer script

Use Conventional Commit format: type(scope): description.
6

Open a PR

Use the template in .github/pull_request_template.md.
pnpm tsgo must exit 0 before you commit. The native checker is the source of truth for type correctness; a green editor is not sufficient.

​
Documentation requirements

WednesdayAI tracks completed work in two places. Both are required for new features and committed with the PR branch:
  • Dev log — create dev-docs/logs/YYYY-MM-DD-<feature-slug>.md (Summary / Goal / Changes / Impact / Benefits / References). The logs are flat and dated; see dev-docs/STRUCTURE.md in the core repo for the format.
  • CHANGELOG entry — add a pointer record to dev-docs/CHANGELOG.md (the narrative index) linking to the dev log. The release CHANGELOG.md is generated by release-please from Conventional Commits — do not hand-edit it.
Bugfix-only PRs need only a CHANGELOG entry (no dev log required unless the fix is complex).

​
PR checklist

Before opening a PR, verify:
  • pnpm tsgo exits 0
  • pnpm build && pnpm check && pnpm test pass
  • Fork philosophy: lean core, stable contracts, correct naming
  • If new extension: @wednesdayai/* scope, plugin-sdk contract, no openclaw peer pin (ADR 0005), no workspace:* in dependencies
  • If touching plugin-sdk exports: no any, no breaking changes without a migration path
  • User-facing changes described in commit messages (release-please generates CHANGELOG.md)
  • Dev log created for new features at dev-docs/logs/YYYY-MM-DD-<slug>.md (pointer added to dev-docs/CHANGELOG.md)
  • AI-assisted PRs marked as such in the title or description

​
Review criteria

PRs are evaluated against the fork philosophy:
  1. Lean core — does this add to core, or could it be a plugin/hook/SDK extension?
  2. Stable contracts — does this change public plugin-sdk, hook, or gateway API? If so, is there a migration path?
  3. Naming — user-facing text uses WednesdayAI; code/config/imports use openclaw.
  4. Extension scope — new WednesdayAI-native extensions use @wednesdayai/*.

​
Cherry-picks from upstream openclaw

We selectively adopt changes from upstream openclaw. The bar:
  1. Does it improve stability or extensibility?
  2. Does it touch core contracts (plugin-sdk, hooks, gateway, routing)? If so, a detailed stability rationale is required.
  3. Does it add platform-specific dependencies that belong in a transport integration?
Propose a cherry-pick in an issue before opening a PR. We decline wholesale upstream rewrites.

​
Reporting security issues

Report security vulnerabilities via GitHub Security Advisories or email security@expansionx.com.au. Do not post publicly before a fix is ready. See SECURITY.md for the trust model and what qualifies as a vulnerability.

​
Getting help