add release workflow

[elenamik]

Pull Request

Checklist

• If this PR changes a package, I’ve added an entry to the CHANGELOG.md

Description

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
valence-ts-example	Error		Sep 22, 2025 8:26pm

[gemini-code-assist]

Summary of Changes

Hello @elenamik, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on updating package dependencies within a monorepo structure. Specifically, it transitions @valence-protocol/domain-clients-core and @valence-protocol/domain-clients-react from workspace:* references to a fixed version 0.4.0 in their respective package.json files. This change is typically performed to stabilize dependencies for a release, ensuring that published packages rely on specific, immutable versions rather than local workspace links, which aligns with the PR's title hinting at a 'release workflow'.

Highlights

• Dependency Version Update for domain-clients-react: The packages/domain-clients-react/package.json file has been updated to change the dependency on @valence-protocol/domain-clients-core from a workspace:* reference to a fixed version 0.4.0.
• Dependency Version Updates for domain-modal-react: The packages/domain-modal-react/package.json file now specifies fixed versions 0.4.0 for both @valence-protocol/domain-clients-core and @valence-protocol/domain-clients-react, replacing their previous workspace:* references.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This PR appears to be part of a release preparation, pinning workspace dependencies to a specific version. While this is a necessary step for publishing, I have a couple of suggestions regarding dependency versioning. Manually changing workspace:* to a fixed version can be error-prone and is usually automated by release tooling in a monorepo. Additionally, using exact versions for dependencies can be overly restrictive. My review comments provide suggestions to use semantic versioning ranges for more flexibility.

A couple of other points:

• The PR title 'add release workflow' is a bit misleading as no workflow file is being added. Something like 'chore: Prepare for 0.4.0 release' would be more accurate.
• The changelogs look updated, so you can tick the checkbox in the PR description.

[gemini-code-assist]

Using an exact version for this dependency is quite restrictive. It would be better to use a caret range (^) to allow for non-breaking updates. This allows consumers of your package to get bug fixes and compatible new features from @valence-protocol/domain-clients-core without you needing to publish a new version of this package.

Suggested change

	"@valence-protocol/domain-clients-core": "0.4.0"
	"@valence-protocol/domain-clients-core": "^0.4.0"

[gemini-code-assist]

For peerDependencies, it's often better to specify a compatible range rather than an exact version. This gives consumers of your library more flexibility in managing their own dependencies. Using a caret range (^) would allow for any compatible 0.x version, which is generally recommended for peer dependencies to avoid dependency conflicts in the consumer's project.

    "@valence-protocol/domain-clients-core": "^0.4.0",
    "@valence-protocol/domain-clients-react": "^0.4.0"