diff --git a/.claude/skills/fetch-protos/SKILL.md b/.claude/skills/fetch-protos/SKILL.md index 9c0c3e237..678101df9 100644 --- a/.claude/skills/fetch-protos/SKILL.md +++ b/.claude/skills/fetch-protos/SKILL.md @@ -29,6 +29,7 @@ version changed. ## Pre-flight context - Pinned versions: !`grep -E "^(ocp|flipcash2)-client-protocol = " gradle/libs.versions.toml` +- Local override: !`grep -E "^protoLocalRoot" local.properties 2>/dev/null || echo "none — building against the pins above"` - Git status: !`git status --short gradle/libs.versions.toml services/` ## Input @@ -56,9 +57,25 @@ gh release list --repo code-payments/-client-protocol --limit 10 Compare against the pin in `gradle/libs.versions.toml`. If the pinned version is already the latest and no version was requested, say so and stop. -If the contract change you want has **not been released**, it has to land in the -client repo first: sync its protos at the upstream SHA, regenerate, and publish. -That repo's README covers it — this skill does not do it. +If the contract change you want has **not been released**, do not reach for a release. +Publishing is for CI release builds; Maven Central will not take a version number +twice, so cutting one to try a field burns a real version. Build against the client +checkout instead, by adding the workspace root to `local.properties`: + +```properties +protoLocalRoot=/Users/you/dev/bmcreations/code +``` + +`settings.gradle.kts` includes `ocp-client-protocol` and `flipcash2-client-protocol` +from there as composite builds, and Gradle substitutes them for the published +coordinates because the group and module match — so the pins in +`gradle/libs.versions.toml` are ignored while it is set. `local.properties` is +untracked and CI never writes it. + +That covers consuming an unreleased contract. Producing one — editing a `.proto` and +syncing it into the client repo — happens in the client repo, and the orchestrator's +`/contract-change` skill drives both halves. Skip Step 2 and Step 3 in this mode: there +is no pin to bump, and the diff is whatever is in your checkout. ### Step 2 — Bump the pin @@ -98,6 +115,9 @@ Build the service module that consumes the artifact: Only build the targets that were bumped. If the build fails, show errors and stop — a removed or renamed field breaks compilation here, which is the point. +With `protoLocalRoot` set, this also builds the client repo, so a broken `.proto` in +your checkout surfaces as a codegen failure in the included build rather than here. + ### Step 5 — Detect service layer impact #### 5a — RPC changes @@ -298,6 +318,10 @@ feat(): scaffold service stubs for new RPCs ## Never +- Leave `protoLocalRoot` set when you hand the branch off or move on. It silently overrides the + pinned versions for whoever builds next, and the failure looks like a mystery version mismatch. +- Cut a release of a client package just to try a change. Use the local override; release when the + change is settled and a build you do not control needs it. - Try to edit the generated protobuf code — it lives in the published artifact - Commit without user approval - Skip build verification