[brionmario]

Purpose

Both samples start at 1.0.0, and the release workflow always bumps the version before tagging. That means v1.0.0 would never be released, and a first patch release would come out as v1.0.1.

This PR resets both samples to 0.0.0 so that the first release can be v1.0.0.

Approach

Sample	File	Before	After
self-care/account	package.json	1.0.0	0.0.0
integrations/flutter-app-auth	pubspec.yaml	1.0.0+1	0.0.0+1

Flutter's +1 build number stays as it is. It becomes the Android versionCode and the iOS build number, which should only go up, and the workflow increments it on every release.

First release: run 🚀 Release with bump_type: major and confirm_major ticked. That gives v1.0.0 (Flutter 1.0.0+2) and the tags sample/self-care/account/v1.0.0 and sample/integrations/flutter-app-auth/v1.0.0. After that, use patch or minor as usual.

No sample has been released yet, so no existing tag or release is affected.

Related Issues

• Add a release workflow to thunder-id/samples thunderid#5780

Related PRs

• Add release workflow for sample apps + Refactor repo #4

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
  • Ran the bump-version action script against both samples after the reset:
    • major gives account 1.0.0 and flutter-app-auth 1.0.0+2.
    • patch gives 0.0.1 and minor gives 0.1.0+2.
  • The lockfiles (pnpm-lock.yaml, pubspec.lock) don't record the sample's own version, so they don't need to change.
• Documentation provided. (Add links if there are any)
• Tests provided. (Add links if there are any)
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.

Security checks

• Followed secure coding standards.
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.