📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: logic-locate
|
||||
description: Locate the root cause of a CONFIRMED failure via backward-then-forward semi-formal tracing. Trigger when the user provides a stack trace, failing assertion, error message, or specific wrong-value observation — "find the bug", "this test is failing", "track down this crash", "why is...
|
||||
risk: unknown
|
||||
source: https://github.com/hyhmrright/logic-lens/tree/main/skills/logic-locate
|
||||
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 — Fault Locate
|
||||
## When to Use
|
||||
|
||||
Use this skill when you need locate the root cause of a CONFIRMED failure via backward-then-forward semi-formal tracing. Trigger when the user provides a stack trace, failing assertion, error message, or specific wrong-value observation — "find the bug", "this test is failing", "track down this crash", "why is...
|
||||
|
||||
|
||||
## Setup
|
||||
|
||||
Use lazy loading per `../_shared/common.md` §13:
|
||||
1. Read `../_shared/common.md` only for language, Iron Law, Fault Confidence, scope routing, Remedy discipline, config fields, and loading budget.
|
||||
2. Read only the relevant step in `logic-locate-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 a concrete failure exists (stack trace, failing assertion, specific wrong value). If only a suspicion, switch to logic-review.
|
||||
|
||||
**Step 1. Understand the failure** (guide Step 1) — observed behavior, expected behavior, reproduction path.
|
||||
|
||||
**Step 2. Identify the entry point** (guide Step 2) — failing test, outermost application frame, or request handler — whichever is closest to the failure. Stay inside the failure cone first: stack frames, failing test fixture, directly called local functions, and config/env values read on that path. Do not scan unrelated modules unless the trace crosses into them.
|
||||
|
||||
**Step 3. Trace backward from the failure point** (guide Step 3) — walk each value and state back to its origin, building premises at every hop.
|
||||
|
||||
**Step 4. Trace forward to confirm** (guide Step 4) — from the suspected root, verify the trace reaches the observed symptom.
|
||||
|
||||
**Step 5. Interprocedural tracing if a callee is implicated** (guide Step 5) — trace into the callee; check return values under observed conditions, unhandled exceptions, shared-state mutation. Apply the depth limit and Call-Chain Context Label format defined in `semiformal-guide.md` §Call-Chain Context Labels; at the limit, state the remaining callee path as a premise assumption and downgrade to **Medium confidence** (per `common.md` §7).
|
||||
|
||||
**Step 6. Identify the root divergence and classify** (guide Step 6) — state the exact line/expression, the violated premise, the actual behavior, the propagation chain to the symptom; pick the L-code.
|
||||
|
||||
**Step 7. Output the focused report** (guide Step 7) — Fault Confidence (High/Medium/Low, per `common.md` §7); Primary Fault (single five-field finding); optionally Contributing Factors; a minimal Remedy per `common.md` §10. **Format is mandatory even for simple one-function bugs: always emit the labeled Premises / Trace / Divergence / Trigger / Remedy fields and the Fault Confidence line. Never answer with a plain fix suggestion.**
|
||||
|
||||
**Mode line in report:** `Fault Locate` (Chinese: `故障定位`).
|
||||
|
||||
**Output format:** the Findings section has ONE Primary Fault, not a full Critical/Warning/Suggestion split. The Logic Score line is replaced by **Fault Confidence:** High / Medium / Low.
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,85 @@
|
||||
# Fault Locate — Step-by-Step Guide
|
||||
|
||||
## Step 1: Understand the Failure
|
||||
|
||||
Characterize it precisely:
|
||||
- **Observed behavior:** exact error message, wrong output value, or symptom
|
||||
- **Expected behavior:** from the test assertion, documentation, or user description
|
||||
- **Reproduction path:** which inputs, environment, sequence of operations
|
||||
|
||||
If a stack trace is available, note the innermost frame (actual crash point) separately from the function that caused it (which may be higher in the stack).
|
||||
|
||||
## Step 2: Identify the Entry Point
|
||||
|
||||
Start from the closest code entry point to the failure:
|
||||
- Failing test → the test function
|
||||
- Stack trace → the outermost **application** frame (not a library frame)
|
||||
- Described symptom ("API returns 500") → the request handler
|
||||
|
||||
Do not start from `main()` — start from the function closest to the failure.
|
||||
|
||||
Start inside the **failure cone**:
|
||||
- Stack trace frames from application code
|
||||
- The failing test and fixtures directly setting up the failing state
|
||||
- Local callees reached by the failing path
|
||||
- Config/env values read by those frames
|
||||
|
||||
Do not inspect unrelated modules, alternative endpoints, or neighboring tests unless the backward trace reaches them.
|
||||
|
||||
## Step 3: Trace Backward from the Failure Point
|
||||
|
||||
Working from the failure site, trace backward: "Where did this value/state come from?"
|
||||
|
||||
At each step:
|
||||
- Follow the value to its origin: declaration, assignment, callee return, external state
|
||||
- Build premises: what was assumed about this value? What is its actual value?
|
||||
|
||||
**Minimum thresholds** (per `../_shared/semiformal-guide.md`): ≥ 3 substantive hops and ≥ 2 location anchors. Otherwise downgrade Fault Confidence to Low.
|
||||
|
||||
**Good backward trace:**
|
||||
```
|
||||
Symptom: TypeError at service.py:7 — 'NoneType' object is not subscriptable on `result['transaction_id']`.
|
||||
←1. [service.py:7] `result` came from line 6.
|
||||
←2. [service.py:6] `result = charge(order)`; `charge` resolves to `payments.gateway.charge`.
|
||||
←3. [gateway.py:3-4] `charge` returns None when `order.amount == 0`; all other paths return a dict.
|
||||
←4. Failing test passes an order with `amount == 0`.
|
||||
Root: gateway.py returns None on amount==0; service.py assumes dict unconditionally — L6.
|
||||
```
|
||||
|
||||
## Step 4: Trace Forward to Confirm
|
||||
|
||||
From the suspected fault location, trace forward:
|
||||
- Does execution reach the failure site?
|
||||
- Does the fault produce exactly the observed symptom?
|
||||
|
||||
If yes, the hypothesis is confirmed. If not, revise — the actual fault may be earlier or in a different branch.
|
||||
|
||||
## Step 5: Interprocedural Tracing
|
||||
|
||||
If the backward trace implicates a callee, trace into it:
|
||||
- Does the callee return `None` under the observed conditions?
|
||||
- Does the callee raise an exception the caller doesn't handle?
|
||||
- Does the callee mutate shared state affecting the caller's subsequent behavior?
|
||||
|
||||
The fault is often not in the function being looked at — it is in a callee that doesn't behave as assumed (L6), or in a name that resolves differently (L1).
|
||||
|
||||
Depth budget: follow the concrete failing path first and stop after the root cause is confirmed. If more than four local calls are required, state the remaining call-chain assumption and downgrade Fault Confidence unless a test or stack trace directly confirms the deeper hop.
|
||||
|
||||
## Step 6: Identify the Root Divergence
|
||||
|
||||
State precisely:
|
||||
- The specific line/expression where the divergence **originates** (not the crash site — the cause of the crash)
|
||||
- The premise that was violated
|
||||
- The actual value or behavior
|
||||
- Why this propagated to the observed failure
|
||||
|
||||
Contributing Factors: conditions that enabled the fault (not findings themselves, but context for the fix).
|
||||
|
||||
## Step 7: Classify and Output
|
||||
|
||||
1. Assign the L-code (L1–L9) that best describes the root fault.
|
||||
2. Assess Fault Confidence:
|
||||
- **High:** trace fully confirms — Premises→Trace→Divergence form a complete chain from cause to symptom.
|
||||
- **Medium:** trace strongly implicates, but one step rests on an unverified assumption.
|
||||
- **Low:** plausible fault, but alternative causes cannot be ruled out without execution.
|
||||
3. Output: Primary Fault (five-field finding for root cause) + Contributing Factors + Remedy.
|
||||
Reference in New Issue
Block a user