Thanks for considering a contribution. CARL's source is not open for arbitrary public contribution today — the code, spec, and prompts are proprietary to Wentzel.ai, which is the sole maintaining entity (see ownership). Source is available to authorized contributors — Wentzel.ai staff and individuals explicitly invited to contribute — under a Developer Certificate of Origin sign-off. There is no separate CLA for authorized contributors, but being authorized is itself a prerequisite: this is not a fork-and-PR-from-anyone project.

Developer Certificate of Origin (DCO)

Every commit to the repository MUST be signed off with a Signed-off-by trailer. This is done automatically by committing with git commit -s:

git commit -s -m "fix(engine): handle repos without package.json gracefully"

The -s flag appends a line like:

Signed-off-by: Your Name <you@example.com>

By adding this line you certify the full DCO text:

Developer Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

The sign-off is checked during review. If you forget, git commit --amend -s adds the trailer to your most recent commit; for older commits use git rebase --signoff.

You may use a pseudonym as your committer name, but the DCO still applies and the email must be one you can receive at.

How to file an issue

• Bug — use the bug report template. Include a reproducer, the CARL commit hash, and your environment.
• Feature / enhancement — explain the problem before the proposed solution.
• Standard change — reference the spec section, provide current and proposed text, explain rationale, note any backward-compat impact.
• Security vulnerability — do not open a public issue. Email security@wentzel.ai per SECURITY.md.

Please search existing issues before opening a new one.

How to submit a pull request

Larger changes — anything touching the standard, a new package, a new criterion in the catalog — should start as an issue so scope can be agreed before implementation.

Development setup

Requirements: Node 22 LTS and pnpm 9+.

nvm install 22
nvm use                # reads .nvmrc
corepack enable        # enables pnpm
pnpm install

Every package under packages/* has its own scripts; Turbo runs them cohesively:

pnpm dev               # runs every package's dev task
pnpm build
pnpm test
pnpm lint

See each package's README.md for package-specific instructions, and CLAUDE.md for agent-assisted development context.

Code standards

Enforced by CI and by the husky + lint-staged pre-commit hook:

• ESLint 9 flat config — zero errors allowed.
• Prettier 3 — zero diffs allowed.
• TypeScript strict — including noUncheckedIndexedAccess, noImplicitOverride, exactOptionalPropertyTypes.
• No any, @ts-ignore, @ts-expect-error without an inline justification comment and a tracking issue.
• No console.log in production code paths. Use the per-package logger.
• No direct process.env reads in business logic. Read env once with Zod validation and export typed values.
• Zod validation on every Server Action, API handler, and external input.
• No barrel files (index.ts re-exports) unless they define a deliberate public API boundary.
• One component per file; file name matches the default export.
• Imports grouped and ordered: external → internal, alphabetical within groups (ESLint enforces).

Testing expectations

• Coverage thresholds: 80% minimum across branches / functions / lines / statements; 90% target for new code.
• Every exported function in lib/ has a unit test.
• Every Server Action has an integration test covering auth, validation, happy path, and at least one error path.
• Every critical user journey has a Playwright E2E test.
• Tests use data-testid or role-based selectors — never CSS class selectors.
• No shared mutable state between tests. Use transactions or per-test schemas.

Privacy & security invariants (non-negotiable)

• No source code from assessed repos is persisted. The reportFindings.evidenceSummary column stores structural observations only, never raw file contents.
• OAuth tokens are encrypted at rest and used in-memory only for the assessment job.
• Ephemeral Worker isolates — in-memory only (no disk), outbound network egress allowlist, discarded when the request returns.
• Audit log is append-only. No UPDATE / DELETE statements against it in application code.

If you believe you need to bend one of these for a legitimate reason, open an issue first.

Code of Conduct

Participation is governed by CODE_OF_CONDUCT.md (Contributor Covenant 2.1). Report violations to conduct@wentzel.ai.

Questions

If something about this process is unclear — particularly the DCO sign-off workflow if you're new to it — open a discussion issue and we'll help.

Related

• Ownership — who can merge, who decides.
• Changelog — release history.
• License — proprietary, all rights reserved.
• Trademark — usage of CARL marks.