📦 deps(thirdparty): update snapshots

antigravity-awesome-skills/skills/logic-diff/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: logic-diff
+description: Compare two code versions for semantic equivalence via semi-formal tracing of both versions side-by-side. Trigger when the user shares a refactor, rewrite, migration, or A/B implementation and wants to confirm behavior is unchanged — "did I break anything", "is this equivalent", "are...
+risk: unknown
+source: https://github.com/hyhmrright/logic-lens/tree/main/skills/logic-diff
+source_repo: hyhmrright/logic-lens
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/logic-lens/blob/main/LICENSE
+---
+
+# Logic-Lens — Semantic Diff
+## When to Use
+
+Use this skill when you need compare two code versions for semantic equivalence via semi-formal tracing of both versions side-by-side. Trigger when the user shares a refactor, rewrite, migration, or A/B implementation and wants to confirm behavior is unchanged — "did I break anything", "is this equivalent", "are...
+
+
+## Setup
+
+Use lazy loading per `../_shared/common.md` §13:
+1. Read `../_shared/common.md` only for language, Iron Law, Verdict header, scope routing, Remedy discipline, config fields, and loading budget.
+2. Read only the relevant step in `logic-diff-guide.md` as you reach it.
+3. Load `../_shared/logic-risks.md`, `../_shared/semiformal-guide.md`, `../_shared/semiformal-checklist.md`, and `../_shared/report-template.md` on demand when the current step needs them.
+
+## Process
+
+**Step 0. Language + scope routing.** Detect language per `common.md` §1. Confirm two versions are provided. If only one version, switch to logic-review.
+
+**Step 1. Identify the shared specification** (guide Step 1) — what inputs should both versions handle; what outputs/side effects are expected. If the user states the refactor intentionally changed behavior in a specific area (e.g., "I changed the error path to raise instead of returning None"), record that as a **declared spec change** and treat divergences within that area as expected. Flag only divergences outside the declared change as findings.
+
+**Step 2. Build independent premises for each version** (guide Step 2) — apply the Premises Construction Checklist to Version A and Version B separately.
+
+**Step 3. Trace both versions for the common case** (guide Step 3) — parallel trace, same input, note the first divergence if any.
+
+**Step 4. Trace boundary cases** (guide Step 4) — empty/null/zero, max/min, error inputs, first/last of collections. Start with at most three highest-risk boundary scenarios unless the user asks for exhaustive equivalence or the shared specification requires more.
+
+**Step 5. Identify and classify semantic divergences** (guide Step 5) — each divergence is a finding with Premises → Trace → Divergence → Trigger → Remedy and an L-code.
+
+**Step 6. Equivalence verdict** (guide Step 6) — one of: `✅ Semantically Equivalent`, `⚠️ Conditionally Equivalent` (state the condition precisely), `❌ Semantically Divergent`.
+
+**Step 7. Output** (guide Step 7) — Report Template with the Verdict header per `common.md` §5; localize headers if the user wrote in Chinese. **Format is mandatory even for trivially short snippets: every divergence finding MUST use the five labeled fields (Premises / Trace / Divergence / Trigger / Remedy); never substitute with a plain paragraph or table.**
+
+**Mode line in report:** `Semantic Diff` (Chinese: `语义对比`).
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

antigravity-awesome-skills/skills/logic-diff/logic-diff-guide.md

@@ -0,0 +1,75 @@
+# Semantic Diff — Step-by-Step Guide
+
+## Step 1: Identify the Shared Specification
+
+Two versions are semantically equivalent if they produce identical behavior for all inputs in the shared specification. Establish it:
+- What inputs are both versions expected to handle?
+- What outputs or side effects should both produce?
+- Are there inputs one version handles that the other doesn't? (This may itself be the divergence.)
+
+If the user hasn't stated the spec, derive it from shared tests, the commit message/PR description, or the function's documented contract. State the derived specification explicitly.
+
+## Step 2: Build Independent Premises for Each Version
+
+Apply the full **Premises Construction Checklist** at `../_shared/semiformal-checklist.md` to Version A and Version B **separately**:
+- Name resolution: same identifier, same resolution in both?
+- Type contracts: same type assumptions at call sites?
+- State preconditions: same preconditions required?
+- Control flow: same branches for same inputs?
+
+This step often surfaces the divergence before the trace begins — a renamed import, a changed conditional, a different default value.
+
+## Step 3: Trace Both Versions for the Common Case
+
+```
+Scenario: [describe the input]
+
+Version A — Trace:
+1. [step]
+2. [step]
+Result: [value / side effect]
+
+Version B — Trace:
+1. [step]
+2. [step]
+Result: [value / side effect]
+
+Verdict: [Equivalent / Divergent at step N]
+```
+
+If both produce the same result, proceed to Step 4. If they diverge, jump to Step 5.
+
+## Step 4: Trace Boundary Cases
+
+Rank boundary conditions by how likely they are to expose a behavior change, then trace Version A and B separately for the top scenarios:
+- Empty/null/zero inputs (catches L3 divergences)
+- Maximum values (integer overflow in one version but not the other)
+- Error inputs (which version raises, which returns a default?)
+- First and last elements of collections (off-by-one in one version)
+
+Default budget: trace the common case plus at most three boundary scenarios. Expand only when the user asks for exhaustive comparison, the shared specification names more required cases, or a traced path exposes a new boundary that must be confirmed.
+
+## Step 5: Identify Semantic Divergences
+
+A semantic divergence is any scenario where A and B produce different behavior. Classify each:
+- Bug in A corrected in B (intended)
+- Regression: B breaks something A handled (unintended)
+- Behavioral change: both work, but differently — user must decide which is correct
+- Scope expansion: B handles inputs A didn't
+
+For each divergence, write a five-field finding (Premises → Trace → Divergence → Trigger → Remedy) with the L-code that best describes the cause.
+
+## Step 6: Classify Equivalence
+
+- **✅ Semantically Equivalent:** No divergence found for all traced scenarios.
+- **⚠️ Conditionally Equivalent:** Equivalent for all common cases; diverges only when [specific condition — state precisely].
+- **❌ Semantically Divergent:** Confirmed behavioral difference at [location] for [scenario].
+
+Note: "No divergence found" is not "provably equivalent." State which scenarios were traced and acknowledge untested scenarios may still diverge.
+
+## Step 7: Output
+
+Use the Report Template from `report-template.md`. Replace Logic Score with the equivalence verdict. In Summary:
+1. The verdict
+2. The most significant divergence (or "no divergences found under traced scenarios")
+3. Any untraced scenarios that should be verified manually