chore(claude): point the proto tracer at the published packages

.claude/agents/proto-change-tracer.md

@@ -39,21 +39,23 @@ Flipcash/Core/Session/, Flipcash/Core/Controllers/, Flipcash/Core/Screens/**
 
 **Package/tool boundaries:**
 - Generated Swift arrives from the two published packages, which `FlipcashAPI` re-exports; service wrappers live in `FlipcashCore`; screens live in the `Flipcash` app target. Read generated sources from the resolved checkouts under `.build/checkouts/` (or `~/Library/Developer/Xcode/DerivedData/**/SourcePackages/checkouts/`), not from this repo.
-- The Core and Payments messaging services share basenames, but they are separate modules now, so the Swift type prefixes (`Flipcash_` vs `Ocp_`) are the only thing keeping them apart.
+- The Core and Payments messaging services share basenames, but they are separate modules, so the Swift type prefixes (`Flipcash_` vs `Ocp_`) are the only thing keeping them apart.
 
 ## Analysis Process
 
 ### 1. Identify what changed in the generated Swift
 
-`proto/` is wiped and re-cloned on every fetch, so diff the **generated Swift**, which
-is the durable signal:
+The generated Swift lives in the published packages, so the version change in
+`FlipcashAPI/Package.swift` names the range to diff:
 
 ```bash
-git diff FlipcashAPI/Sources/FlipcashAPI/Core/Generated FlipcashAPI/Sources/FlipcashAPI/Payments/Generated
-git diff FlipcashAPI/Sources/FlipcashAPI/*/proto   # secondary, for intent
+git diff FlipcashAPI/Package.swift
+gh api repos/code-payments/<package>/compare/<old-tag>...<new-tag> --jq '.files[].filename'
 ```
 
-Identify:
+Under `FLIPCASH_PROTO_LOCAL` there is no version change; diff the client checkout instead
+(`git -C "$FLIPCASH_PROTO_LOCAL/<package>" diff`). Read the changed `.pb.swift` /
+`.grpc.swift` files from the resolved checkouts and identify:
 - New services or RPCs (new methods on a `<Namespace>.Client`)
 - Changed request/response message fields
 - New or modified **result enum** values (`.pb.swift`)

.claude/skills/fetch-protos/SKILL.md

@@ -132,8 +132,8 @@ rename that orphaned a Swift type reference) before proceeding.
 Dispatch the **proto-change-tracer** agent to map the changes through the codebase:
 
 ```
-Use the proto-change-tracer agent to trace the proto changes just fetched
-(see `git diff FlipcashAPI/`) through the service → client → consumer chain.
+Use the proto-change-tracer agent to trace <package> <old-tag> → <new-tag>
+(from `git diff FlipcashAPI/Package.swift`) through the service → client → consumer chain.
 ```
 
 The agent reports the full impact chain (generated → `*Service.swift` →
@@ -243,7 +243,7 @@ extension FlipClient {  // or Client, for Payments
 
 ### Step 7 — Review and commit
 
-Show the user a summary of all changes (proto/generated updates + any scaffolded
+Show the user a summary of all changes (the version bump + any scaffolded
 service code). Offer to commit only after approval, with a conventional message:
 
 ```

.claude/skills/triage/SKILL.md

@@ -20,14 +20,11 @@ allowed-tools:
 
 # Triage
 
-<!-- `ultrathink` escalates the harness to max thinking budget. The harness scans for it as a standalone token, so it must remain on its own line and not be wrapped in code fences or prose. -->
-ultrathink
-
 You are running the daily Bugsnag triage ritual. The deliverable is **one lean review brief** at `.claude/plans/<YYYY-MM-DD>-bugsnag-<short_id>.md`. The brief is the user's review artifact — see `references/brief-template.md` for the structure and word cap.
 
 ## Hard rules
 
-1. **Max effort, no shortcuts.** Read full stack traces. Read each source file the trace touches in full, not snippets. Trace through callers when the crash site is ambiguous. Never skip an expert review when the trigger applies.
+1. **Read the evidence in full.** Read full stack traces. Read each source file the trace touches in full, not snippets. Trace through callers when the crash site is ambiguous. Never skip an expert review when the trigger applies.
 2. **No claim without a citation.** Every assertion in the brief (stack lines, "this is the root cause", "this code path runs first") must be followed by a `file.swift:NN` reference or a quoted log/breadcrumb excerpt. If unable to cite, mark as "hypothesis, unverified" and propose how to verify.
 3. **Root cause must be reachable from evidence.** The Root cause section is a short chain: `evidence → inference → evidence → inference → cause`. No leaps. If the chain breaks, the section is renamed "Leading hypothesis" and the Proposed direction becomes "Verification steps".
 4. **No mid-flow questions.** The brief is the review checkpoint. Don't ask the user anything until it's written.