openclaw/vendor/a2ui/CONTRIBUTING.md
Jon Shapiro 92697edb7c fix(venice): add compat settings to prevent HTTP 400 errors
Venice's API doesn't support certain OpenAI-compatible parameters that
Clawdbot sends by default:

- `store`: Venice returns HTTP 400 with no body when this is present
- `developer` role: Not supported by Venice's API

This adds VENICE_COMPAT settings (supportsStore: false,
supportsDeveloperRole: false) to all Venice model definitions, both
from the static catalog and dynamically discovered models.

Fixes issues reported in PR #1666 where users experienced silent
failures (HTTP 400, no body) when using Venice models.

Co-authored-by: jonisjongithub <jonisjongithub@users.noreply.github.com>
Co-authored-by: Clawdbot <bot@clawd.bot>
2026-01-26 17:56:01 -08:00

2.2 KiB

How to contribute to A2UI

We'd love to accept your patches and contributions to this project.

Before you begin

Sign our Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project.

If you or your current employer have already signed the Google CLA (even if it was for a different project), you probably don't need to do it again.

Visit https://cla.developers.google.com/ to see your current agreements or to sign a new one.

Review our community guidelines

This project follows Google's Open Source Community Guidelines.

Contribution process

Code reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Contributor Guide

You may follow these steps to contribute:

  1. Fork the official repository. This will create a copy of the official repository in your own account.
  2. Sync the branches. This will ensure that your copy of the repository is up-to-date with the latest changes from the official repository.
  3. Work on your forked repository's feature branch. This is where you will make your changes to the code.
  4. Commit your updates on your forked repository's feature branch. This will save your changes to your copy of the repository.
  5. Submit a pull request to the official repository's main branch. This will request that your changes be merged into the official repository.
  6. Resolve any linting errors. This will ensure that your changes are formatted correctly.

Here are some additional things to keep in mind during the process:

  • Test your changes. Before you submit a pull request, make sure that your changes work as expected.
  • Be patient. It may take some time for your pull request to be reviewed and merged.