docs: update release process for automated npm publishing

[kherembourg]

Summary

• Update RELEASE.md to reflect the new automated publish via GitHub releases
• Update CLAUDE.md CI/CD section to document both workflows (ci.yml + publish.yml)
• Ensure an AI agent can follow the release process end-to-end

Key changes

RELEASE.md:

• Replace manual ./publish.sh (step 12) with gh release create which triggers CI + publish automatically
• Add verification step (step 13) with npm view commands
• Add npm Trusted Publisher setup section (one-time config)
• Add troubleshooting for OIDC/publish failures
• Add step 6 to update CLAUDE.md during releases
• Remove macOS/Xcode/Android Studio from prerequisites (CI handles builds)

CLAUDE.md:

• Document both workflows (ci.yml and publish.yml) in a table
• Explain publish.yml trigger, OIDC flow, and version tag format
• Note that release tags must be bare versions (no v prefix)

Test plan

• Documentation review — steps are complete and automatable

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR updates RELEASE.md and CLAUDE.md to document the new automated npm publish pipeline, replacing the manual ./publish.sh invocation with a gh release create command that triggers the publish.yml GitHub Actions workflow via OIDC (no stored npm tokens required).

Key changes:

• RELEASE.md: Adds gh release create {VERSION} as the new Step 12, documents the OIDC/Trusted Publisher flow, adds a one-time npm setup section, adds a verification step (Step 13), and removes the local macOS/Xcode build step that is now handled entirely by CI.
• CLAUDE.md: Adds a workflow comparison table (ci.yml vs publish.yml), removes the outdated standalone build-library CI job (now correctly embedded inside build-android and build-ios steps), and documents the bare-version tag requirement.
• The documentation accurately reflects the actual publish.yml workflow: CI runs first via workflow_call, versions are verified against the release tag, and all 5 packages are published with --provenance.
• Potential issue: The npm Trusted Publisher setup and troubleshooting sections reference Purchasely/Purchasely-ReactNative (mixed case), while the repository path in GitHub OIDC tokens appears to be purchasely/purchasely-reactnative (lowercase). A case mismatch here would silently break every automated publish.

Confidence Score: 4/5

• Safe to merge after verifying the repository name casing used in the npm Trusted Publisher configuration.
• The changes are documentation-only and the updated process accurately mirrors the real publish.yml workflow. The only actionable concern is the repository name casing in the npm Trusted Publisher setup section, which could silently break automated publishing if misconfigured. Everything else — step ordering, tag format, OIDC explanation, CI job list — is accurate and well-documented.
• RELEASE.md lines 191–193 and 223 — verify the repository name casing (Purchasely-ReactNative) matches what is actually registered on npmjs.com for Trusted Publishers.

Important Files Changed

Filename	Overview
RELEASE.md	Replaces manual publish script with automated gh release create flow; well-structured with clear steps, but the repository name casing in the npm Trusted Publisher setup section (Purchasely-ReactNative) may not match the actual GitHub repo path and could cause OIDC publish failures.
CLAUDE.md	CI/CD section updated to add workflow table and document the new publish.yml; accurately removes the standalone build-library job (now embedded in build-android/build-ios steps) and correctly describes OIDC flow and bare-version tag requirement.

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant CI as ci.yml
    participant PUB as publish.yml
    participant NPM as npmjs.com

    Dev->>GH: gh pr create (version/{VERSION} → main)
    GH->>CI: trigger on pull_request
    CI-->>GH: lint / test / build-android / build-ios ✓
    Dev->>GH: gh pr merge --merge
    Dev->>GH: gh release create {VERSION} --target main
    GH->>PUB: trigger on release (published)
    PUB->>CI: workflow_call (full CI)
    CI-->>PUB: all jobs pass ✓
    PUB->>PUB: verify all package.json versions == {VERSION}
    PUB->>NPM: npm publish --provenance (×5 packages) via OIDC
    NPM-->>Dev: packages live at {VERSION}
    Dev->>NPM: npm view <package> version (verify)

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: RELEASE.md
Line: 191-193

Comment:
**Repository name casing may not match actual GitHub repo**

The npm Trusted Publisher setup instructs users to enter `Purchasely-ReactNative` as the repository name, and the troubleshooting section also refers to `Purchasely/Purchasely-ReactNative`. However, the repository URL used throughout the PR metadata and in OIDC tokens issued by GitHub Actions is `purchasely/purchasely-reactnative` (all lowercase).

npm's Trusted Publisher verification uses the OIDC token's `repository` claim, which GitHub sets from the actual repository path. If the case doesn't match exactly what was configured on npmjs.com, every publish attempt will fail with the "forbidden" or OIDC error described in the troubleshooting section below.

Please verify the exact case of the repository name as it appears on `github.com` and ensure the npm Trusted Publisher configuration (and the troubleshooting note at line 223) uses the correct casing.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: RELEASE.md
Line: 119

Comment:
**`gh pr merge` strategy may conflict with branch protection rules**

The `--merge` flag creates a merge commit. If the repository's branch protection rules require squash merges (a common setting for a clean `main` history), this command will fail. Consider documenting the expected merge strategy or using `--squash` if that is the project convention.

```suggestion
gh pr merge --squash
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: e6dc1df}

[greptile-apps]

Repository name casing may not match actual GitHub repo

The npm Trusted Publisher setup instructs users to enter Purchasely-ReactNative as the repository name, and the troubleshooting section also refers to Purchasely/Purchasely-ReactNative. However, the repository URL used throughout the PR metadata and in OIDC tokens issued by GitHub Actions is purchasely/purchasely-reactnative (all lowercase).

npm's Trusted Publisher verification uses the OIDC token's repository claim, which GitHub sets from the actual repository path. If the case doesn't match exactly what was configured on npmjs.com, every publish attempt will fail with the "forbidden" or OIDC error described in the troubleshooting section below.

Please verify the exact case of the repository name as it appears on github.com and ensure the npm Trusted Publisher configuration (and the troubleshooting note at line 223) uses the correct casing.

Prompt To Fix With AI

This is a comment left during a code review.
Path: RELEASE.md
Line: 191-193

Comment:
**Repository name casing may not match actual GitHub repo**

The npm Trusted Publisher setup instructs users to enter `Purchasely-ReactNative` as the repository name, and the troubleshooting section also refers to `Purchasely/Purchasely-ReactNative`. However, the repository URL used throughout the PR metadata and in OIDC tokens issued by GitHub Actions is `purchasely/purchasely-reactnative` (all lowercase).

npm's Trusted Publisher verification uses the OIDC token's `repository` claim, which GitHub sets from the actual repository path. If the case doesn't match exactly what was configured on npmjs.com, every publish attempt will fail with the "forbidden" or OIDC error described in the troubleshooting section below.

Please verify the exact case of the repository name as it appears on `github.com` and ensure the npm Trusted Publisher configuration (and the troubleshooting note at line 223) uses the correct casing.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

gh pr merge strategy may conflict with branch protection rules

The --merge flag creates a merge commit. If the repository's branch protection rules require squash merges (a common setting for a clean main history), this command will fail. Consider documenting the expected merge strategy or using --squash if that is the project convention.

Suggested change

	gh pr merge --merge
	gh pr merge --squash

Prompt To Fix With AI

This is a comment left during a code review.
Path: RELEASE.md
Line: 119

Comment:
**`gh pr merge` strategy may conflict with branch protection rules**

The `--merge` flag creates a merge commit. If the repository's branch protection rules require squash merges (a common setting for a clean `main` history), this command will fail. Consider documenting the expected merge strategy or using `--squash` if that is the project convention.

```suggestion
gh pr merge --squash
```

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}