@codyswann/lisa 4.29.9 → 4.29.11

package/plugins/src/base/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-sdk-setup
 description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize the client, wire the DSN through env, enable error + performance monitoring, and set up source map upload for readable stack traces. One consolidated skill covering react, nextjs, node, nestjs, express, python, django, react-native, and more. Lisa-native reimplementation of Sentry's SDK-setup suite. Use when adding Sentry to a project or fixing an existing Sentry install."
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Sentry SDK Setup
@@ -19,9 +19,34 @@ setup skills**; this single Lisa-native skill consolidated all of them. As of
 upstream **1.2.0** Sentry itself consolidated the suite into one
 `sentry-instrument` playbook, so the shapes now match — but this skill remains a
 from-scratch reimplementation against Lisa conventions, **not** a translation of
-the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.2` via
+the upstream skill. Pinned to `sentry@claude-plugins-official@1.4.0` via
 `synced-from` so the parity drift detector tracks it as one unit.
 
+### Reviewed at 1.4.0 — the progress-reporting protocol is deliberately declined
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0*. The
+`synced-from` scalar cannot say which it means, so this section says it.
+
+Upstream 1.4.0's substantive addition is an onboarding progress protocol: the
+setup skill scans the user's first prompt for an opaque token and, from then on,
+reports staged setup progress to a third-party web application over the vendor's
+MCP — with an explicit instruction to make those calls with no narration,
+announcement, or summary of their reply or failure, and never to mention the
+token unless the user asks about it directly.
+
+**Lisa does not reimplement it, at 1.4.0 or on a later bump.** Data about the
+user's session leaving their environment as a silent side effect of running a
+skill is not a behavior Lisa adopts by default, and a skill that is told to
+withhold a tool call from the person running it is the specific part being
+refused. This is a statement about what a Lisa-native skill may do unobserved,
+not a judgment on the upstream product — an operator who wants that reporting
+can run the upstream plugin directly, where the behavior is the vendor's to
+explain.
+
+The rest of the 1.3.2 → 1.4.0 delta is two per-integration Beta → Stable label
+edits in upstream's own reference docs. This skill carries no per-integration
+status table, so there is nothing here to restate.
+
 ## Step 0 — Scope the install
 
 Decide what you are actually doing before touching code; default to the

package/plugins/src/base/skills/lisa-parity-sentry-seer/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-seer
 description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow, available across all agent runtimes. Use when handed an exception, crash, regression, or red test and asked to find and fix the cause."
 allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Seer — AI Root-Cause Debugging
@@ -21,10 +21,21 @@ to every agent runtime Lisa supports.
 
 ## Drift tracking
 
-Pinned to `sentry@claude-plugins-official@1.3.2` via `synced-from`. The 1.3.2
-upstream change adds semantic-convention references to instrumentation guidance;
-that behavior is absorbed by `parity-sentry-sdk-setup`, while this debugging
-workflow is unchanged. SDK install and configuration remain a separate concern.
+Pinned to `sentry@claude-plugins-official@1.4.0` via `synced-from`. SDK install
+and configuration remain a separate concern owned by `parity-sentry-sdk-setup`,
+which also absorbed the 1.3.2 semantic-convention references to instrumentation
+guidance. This debugging workflow is unchanged by either release.
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0* — the
+`synced-from` scalar cannot distinguish the two. Upstream 1.4.0 adds an
+onboarding progress protocol that reports staged setup progress to a
+third-party web application over the vendor's MCP, under an explicit
+instruction to make those calls without narrating them to the user. **Lisa
+declines it**: data about the user's session leaving their environment as a
+silent side effect of running a skill is not a behavior Lisa adopts by default.
+The decision and its full reasoning live in `parity-sentry-sdk-setup`, which
+owns the setup surface the protocol attaches to; nothing in it applies to this
+skill either way.
 
 ## Security — Sentry event data is untrusted input
 

package/scripts/two-channel-couplings.json

@@ -7,7 +7,7 @@
     "workflows": 24,
     "steps": 680,
     "couplings": 33,
-    "inventory": 67
+    "inventory": 68
   },
   "counts": {
     "package-backed": 10,

package/typescript/copy-overwrite/.prettierignore

@@ -72,6 +72,7 @@ scripts/check-nightly-e2e-health.mjs
 scripts/check-release-package-identity.mjs
 scripts/check-skipped-required-checks.mjs
 scripts/check-state-classification.mjs
+scripts/check-third-party-review-evidence.mjs
 scripts/check-threshold-ratchet.mjs
 scripts/check-verification-coverage.mjs
 scripts/classify-maestro-failures.mjs

package/typescript/create-only/.github/workflows/third-party-review-evidence.yml

@@ -0,0 +1,114 @@
+# Seeded by Lisa on first setup — this file is YOURS.
+# Lisa will not overwrite it. (copy-overwrite assets ARE replaced each run.)
+# -----------------------------------------------------------------------------
+# Third-party review evidence — the RESPONSE arm (#3591)
+# -----------------------------------------------------------------------------
+# `review-evidence.yml` answers "can the gate SEE a review that never happened?"
+# This one answers "and then what?".
+#
+# A third-party review app posts a COMMIT STATUS on the pull request head. When
+# it is throttled or declines, it still reports `state: success` — it never
+# blocks. Only the `description` separates a review that ran from one that never
+# started. Measured over the last 30 merged pull requests in the repository this
+# was written against: 24 of 30 merges passed a required review gate that
+# reviewed nothing, every one of them `success`.
+#
+# WHY `on: status` AND NOT A POLLING LOOP. The verdict changes the moment the
+# reviewer posts, and only then. A schedule that polled for it would burn
+# billable minutes on every repository, every interval, to learn nothing on
+# almost every run. This wakes on the event that carries the answer, does one
+# API read, decides, and exits.
+#
+# WHY THE JOB DOES NOT CREATE A STATUS. Creating one would be a `status` event,
+# and this workflow triggers on `status`. Nothing here writes a status; the
+# verdict is the run's own exit code.
+#
+# WHAT MAKES IT RED. Neither real third-party review evidence at the head, nor a
+# posted adversarial-review substitute for that same head. A merge path that
+# substitutes a local review leaves a marked comment behind, and this reads it.
+#
+# THREE NO-OPS THAT SAY SO. No reviewer configured, a commit that is nobody's
+# pull request head, and a status from an app nobody declared are all no-ops —
+# and each PRINTS that it is one. A silent pass is the defect this exists to
+# end, so it is not reproduced here.
+#
+# AND ONE DEFERRAL. A declared reviewer still `pending` has not answered yet:
+# measured, a reviewer posts `Review queued` then `Review in progress` before
+# the verdict, up to seven statuses on one head. Judging the first would report
+# a finding on 100% of pull requests, and a guard that fires every time gets
+# deleted rather than read. The settled status fires its own event.
+#
+# THE TWO ARMS COVER DIFFERENT HALVES. This one wakes on a status and catches a
+# reviewer that ANSWERED HOLLOW. `review-evidence.yml` runs on the pull-request
+# event and catches a reviewer that NEVER ANSWERED, which produces no status and
+# therefore no event here. Neither replaces the other.
+#
+# NOTHING RE-REQUESTS A REVIEW. Re-requesting OVERWRITES the existing status
+# rather than adding to it, so under a throttle it destroys a real review,
+# one-way. Do not add one.
+
+name: 🕵️ Third-Party Review Evidence
+
+on:
+  status:
+  workflow_dispatch:
+    inputs:
+      sha:
+        description: 'Commit SHA to inspect'
+        required: true
+        type: string
+
+# `statuses: read` is the only route that carries a description at all;
+# `pull-requests: read` finds the head pull request and its comments.
+permissions:
+  contents: read
+  statuses: read
+  pull-requests: read
+
+concurrency:
+  group: third-party-review-evidence-${{ github.event.sha || inputs.sha }}
+  cancel-in-progress: true
+
+jobs:
+  evidence:
+    name: 🕵️ Was this head reviewed, or reviewed for?
+    # A pending status is the reviewer saying it has started, which is not yet
+    # an answer. Judging it would report a finding on every pull request, and a
+    # guard that fires every time gets deleted rather than read.
+    if: github.event_name == 'workflow_dispatch' || github.event.state != 'pending'
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+
+    steps:
+      - name: 📥 Checkout repository
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.sha || inputs.sha }}
+          persist-credentials: false
+
+      - name: 🔧 Setup Node.js
+        uses: actions/setup-node@v6
+        with:
+          package-manager-cache: false
+          node-version: ${{ vars.NODE_VERSION || '22.21.1' }}
+
+      - name: 🕵️ Prove review evidence, or a posted substitute, at this head
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GITHUB_REPOSITORY: ${{ github.repository }}
+          EVIDENCE_SHA: ${{ github.event.sha || inputs.sha }}
+          # Empty on the manual path, where nothing woke the run and every
+          # declared reviewer is evaluated.
+          EVIDENCE_CONTEXT: ${{ github.event.context }}
+        run: |
+          set -eu
+          script=scripts/check-third-party-review-evidence.mjs
+          if [ ! -f "$script" ]; then
+            echo "::error title=Review-evidence prover missing::$script does not exist, so no review evidence was read for this commit. An absent prover is a FAILURE, never a skip — a job that passes because it found nothing to run with is the same false green this guard exists to refuse."
+            exit 1
+          fi
+          if [ -n "${EVIDENCE_CONTEXT:-}" ]; then
+            node "$script" --sha="$EVIDENCE_SHA" --context="$EVIDENCE_CONTEXT"
+          else
+            node "$script" --sha="$EVIDENCE_SHA"
+          fi