scip-query 0.10.12 → 0.12.0

package/skills/scip-hyper-optimization/SKILL.md

@@ -1,104 +1,107 @@
 ---
 name: scip-hyper-optimization
-description: Run scientific performance optimization campaigns with scip-query evidence, hierarchical profiling, command ledgers, and benchmark corpora. Use when the user asks to hyper optimize, make commands blazing fast, speed up a CLI/tool/app, find bottlenecks, benchmark regressions, optimize cold or warm paths, or compare targeted tuning against radically different implementations.
+description: Optimize performance scientifically with scip-query evidence. Use for benchmarking, profiling, speeding up commands, workflows, indexers, detectors, app paths, cold/warm regressions, memory/cost reduction, or comparing current-pipeline tuning with alternative designs.
+commands:
+  - template: "scip-query bench --json"
+    when: "Target and harness: baseline timings for a scip-query command target."
+  - template: "scip-query bench --json --cold-index --include-heavy --timeout-ms 600000"
+    when: "Target and harness: cold-path and heavy-detector timings."
+  - template: "scip-query plan-context <entry-symbol-or-file>"
+    when: "Trace behavior: pre-edit context for the profiled entry point."
+  - template: "scip-query call-graph <entry-symbol>"
+    when: "Trace behavior: callers/callees for the pipeline under test."
+  - template: "scip-query complexity <hot-symbol>"
+    when: "Diagnose: branches, cyclomatic estimate, fan-in/out for a hot symbol."
+  - template: "scip-query change-surface <touched-file> --json --full"
+    when: "Verify and report: blast radius of the optimization change."
 ---
 
-# SCIP Hyper Optimization
-
-Use this skill to make a command, workflow, service, page, or tool as fast as
-feasibly possible without changing its observable result. Hyper optimization is
-a bounded campaign that improves runtime, memory use, or computational cost
-against objective measurements; every accepted change is proven by a repeatable
-benchmark and unchanged output.
-
-A measurement harness is the repeatable set of commands, fixtures, corpora,
-environment notes, and result documents used to decide whether performance
-changed. A run history is the durable time-series of those measurements: one
-record per run, command, subprocess, or profiled stage, with enough metadata to
-compare commits and draw charts later. A profile span is one named timed piece
-of work inside the target process, such as input loading, cache reads, database
-queries, graph traversal, rendering, or a child process. Hierarchical profiling
-is using coarse spans to find the dominant stage, then recursively splitting
-only that stage until the expensive operation is concrete enough to fix. A
-command ledger is the living document for one target: what it returns, what code
-runs, where time is spent, what was tried, and what evidence accepted or
-rejected each idea.
+# scip-hyper-optimization
+
+Use this skill to make a command, workflow, service, page, or tool faster without changing its observable result. Hyper optimization is a bounded campaign that improves runtime, memory, or computational cost against repeatable measurements.
+
+Campaign-level conduct — delegation, handoff verification, benchmark pre-registration across multiple phases — is `scip-conductor`; this skill is the performance-domain method that runs inside it (or standalone for a single target).
+
+Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
+
+## Scale Gate
+
+Choose the mode before starting:
+
+- **QUICK** — a single command/function target with an obvious hot path: capture one `docs/benchmarks/runs/YYYY-MM-DD-<target>.jsonl` baseline, skip the ledger and the rest of the campaign artifact set, fix the hypothesis, measure after, done.
+- **CAMPAIGN** — multiple targets, an unclear bottleneck, or a decision between competing designs: run the full machinery below (baseline doc, ledger, profiling, alternative-design track).
+
+One sentence to decide: if you can already name the one function you expect to fix and a single before/after number will settle it, use QUICK; if naming that function requires investigation or the fix might be architectural, use CAMPAIGN.
+
+<!-- BEGIN GENERATED SKILL COMMANDS -->
+## Commands for this skill
+
+| Command | Purpose | When |
+| --- | --- | --- |
+| `scip-query bench --json` | Benchmark indexing and command runtimes for this repository | Target and harness: baseline timings for a scip-query command target. |
+| `scip-query bench --json --cold-index --include-heavy --timeout-ms 600000` | Benchmark indexing and command runtimes for this repository | Target and harness: cold-path and heavy-detector timings. |
+| `scip-query plan-context <entry-symbol-or-file>` | Pre-edit planning context for a symbol, file, or module | Trace behavior: pre-edit context for the profiled entry point. |
+| `scip-query call-graph <entry-symbol>` | Show incoming callers and outgoing callees for a symbol | Trace behavior: callers/callees for the pipeline under test. |
+| `scip-query complexity <hot-symbol>` | Per-symbol complexity: branches, cyclomatic estimate, fan-in/out, callees | Diagnose: branches, cyclomatic estimate, fan-in/out for a hot symbol. |
+| `scip-query change-surface <touched-file> --json --full` | Pre-change briefing: exports, consumers, and blast-radius risk | Verify and report: blast radius of the optimization change. |
+
+Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
+<!-- END GENERATED SKILL COMMANDS -->
+
+## Terms
+
+A measurement harness is the repeatable set of commands, fixtures, corpora, environment notes, and result documents used to decide whether performance changed.
+
+A run history is the durable time series of measurements, with one record per run, command, subprocess, or profiled stage.
+
+A profile span is one named timed piece of work inside the target process, such as input loading, cache reads, database queries, graph traversal, rendering, or a child process.
+
+Hierarchical profiling is measuring coarse spans first, then recursively splitting only the dominant span until the expensive operation is concrete enough to fix.
+
+A command ledger is the living document for one target: output contract, current pipeline, timings, tried ideas, and decisions.
 
 ## Rules
 
-1. Do not optimize until a measurement harness exists or has been created.
-2. Use scip-query for code understanding: `status`, `plan-context`, `trace`,
-   `call-graph`, `code`, `dataflow`, `complexity`, `diff-impact`, `diff-gate`.
-3. Capture representative inputs, required output behavior, and correctness
-   checks before editing.
-4. Record every benchmark in a machine-readable run history before and after
-   each optimization; Markdown summaries are secondary.
-5. Measure cold-index, cold-cache or evidence-fill, warm steady-state, and
-   repeated focused paths separately when they can diverge.
-6. Profile the target's internal chain before editing. A bare command duration
-   is enough to rank targets, not enough to choose a fix.
-7. Treat profiling as a search algorithm: place coarse spans first, split the
-   biggest span, and stop descending only when the slow operation is identifiable
-   as a specific repeated lookup, initialization, scan, traversal, subprocess,
-   serialization step, or wait.
-8. Attach counts to spans: files, rows, symbols, candidates, cache hits/misses,
-   subprocesses, bytes, edges, nodes, retries, and output rows. Time without
-   cardinality hides the cause.
-9. Work both tracks: tune the current pipeline and evaluate radically different
-   algorithms or data models that preserve the same result.
-10. Keep only changes that improve real workloads without reducing accuracy,
-    diagnostics, safety checks, or supported inputs.
-
-## Phase 0: Target And Measurement Harness
-
-If the target repository is not already a reliable scip-query workspace, invoke
-`scip-query-setup` first. Do not run setup-ci in this workflow.
-
-Choose the optimization target explicitly. Use user-reported pain, production
-telemetry, benchmark ranking, regression data, cost, frequency, or risk to
-justify why this target comes first. Do not optimize the slowest thing by habit
-if another path dominates real user time or compute spend.
-
-Create or update a benchmark note and a run-history store before code changes.
-Prefer the repo's existing convention; otherwise use
-`docs/benchmarks/YYYY-MM-DD-<target>-baseline.md` and
-`docs/benchmarks/runs/YYYY-MM-DD-<target>.jsonl`. Include target, machine/date
-context, corpus or fixture list, cold/warm/correctness commands, baseline
-timings, output-contract evidence, and slowest stages. Append a structured run
-record for each measurement with at least timestamp, commit/version, target,
-corpus, scenario, command, duration, exit status, output hash or size, and
-notes for outliers.
-
-Choose the measurement mechanism from the target's real workload. For app
-paths, use the app's benchmark, test, route smoke, build, profiler, load test,
-or timing script; if none exists, create the smallest repeatable timing command.
-For scip-query command, detector, or indexer targets, benchmark the relevant
-command matrix:
+1. Do not optimize until a measurement harness exists or is created.
+2. Capture representative inputs, output contract, and correctness checks before editing.
+3. Record every benchmark in machine-readable run history.
+4. Measure cold and warm paths separately when they can diverge.
+5. Profile the internal chain before choosing a fix.
+6. Attach cardinality to spans: files, rows, symbols, candidates, cache hits/misses, bytes, edges, nodes, retries, or output rows.
+7. Work both tracks: tune the current pipeline and evaluate alternative algorithms or data models.
+8. Keep only changes that improve real workloads without reducing accuracy, diagnostics, safety, or supported inputs.
+
+## Workflow
+
+### 1. Target and harness
+
+If the repo is not a reliable scip-query workspace, invoke `scip-setup` first. Choose the target from user pain, telemetry, benchmark ranking, regression data, cost, frequency, or risk.
+
+Create or update:
+
+- `docs/benchmarks/YYYY-MM-DD-<target>-baseline.md` (CAMPAIGN only — QUICK skips this)
+- `docs/benchmarks/runs/YYYY-MM-DD-<target>.jsonl` (both modes — the one required artifact)
+
+For scip-query command targets, start with:
 
 ```bash
 scip-query bench --json
 scip-query bench --json --cold-index --include-heavy --timeout-ms 600000
 ```
 
-For long benchmark matrices, prefer progress output or incremental JSONL writes
-so the current command, subprocess, elapsed time, and completed measurements are
-visible while the run is still active and useful if interrupted.
+This step is complete only when baseline timings, output identity evidence, corpus, environment, and run-history location exist.
+
+### 2. Create the ledger
 
-## Phase 1: Command Ledger
+CAMPAIGN only — QUICK mode skips this step and goes straight to tracing behavior with the single run-history file as its record.
 
-Create one ledger per target:
-`docs/benchmarks/YYYY-MM-DD-<target>-ledger.md`. Include Output Contract,
-Target Selection, Current Pipeline, Run History Location, Profile Spans,
-Bottleneck Candidates, Measurements, Current-Pipeline Optimizations,
-Alternative Designs, and Decisions.
+Write `docs/benchmarks/YYYY-MM-DD-<target>-ledger.md` with Output Contract, Target Selection, Current Pipeline, Run History Location, Profile Spans, Bottleneck Candidates, Measurements, Current-Pipeline Optimizations, Alternative Designs, and Decisions.
 
-## Phase 2: Trace Current Behavior
+This step is complete only when the ledger can explain what must not change.
 
-Trace the target end to end and write the actual path into the ledger:
+### 3. Trace behavior
 
 ```bash
-scip-query status --capabilities
-# If stale, missing, or unknown: scip-query reindex
 scip-query plan-context <entry-symbol-or-file>
 scip-query trace <entry-symbol>
 scip-query call-graph <entry-symbol>
@@ -108,119 +111,42 @@ scip-query complexity <hot-symbol>
 scip-query change-surface <touched-file> --json --full
 ```
 
-Record the chain reaction from entry point to result: input parsing, option
-resolution, subprocesses, lookups, database queries, graph traversal, source
-scans, semantic calls, cache reads/writes, rendering, output serialization, and
-verification. The trace should be concrete enough that each major step can be
-timed as a profile span.
-
-Before adding spans, use the trace to predict span boundaries. Good first spans
-usually match the target's real pipeline nouns: load inputs, compute candidates,
-read cache, compute misses, write cache, build graph, score, render, serialize,
-and child process. Use `call-graph` to find nested helpers inside the slow
-stage, `dataflow` to follow the expensive object or cache key, `refs` to learn
-whether a suspected fix affects other paths, and `complexity` to avoid spending
-the first profiling pass on low-risk glue.
-
-## Phase 3: Profile The Timed Chain
-
-Before editing, produce a stage profile for the selected target. Prefer existing
-runtime profilers, tracing systems, structured logs, or benchmark hooks. If none
-exist, add temporary or permanent instrumentation that names timed spans without
-changing observable output. For CLIs and build tools, include child processes
-and worker tasks; for services, include request handlers, database calls,
-network calls, queue jobs, cache hits/misses, rendering, and serialization.
-
-Use this discovery ladder:
-
-1. Measure the target unprofiled so the user-facing baseline is real.
-2. Measure it profiled once. If profiled and unprofiled times are close, the
-   profiler is diagnostic overhead, not the bottleneck. If profiling dominates,
-   fix the harness before trusting fine spans.
-3. Measure distinct states separately: cold index, cold derived-cache/evidence
-   fill, warm cache hit, repeated focused run, and production-like mixed state.
-4. Add coarse spans that cover the whole chain. If span time does not explain
-   wall time, look for uninstrumented child processes, async waits, I/O, process
-   startup, or profiler gaps.
-5. Pick the largest span by wall time multiplied by real workload frequency.
-   Split only that span into child spans.
-6. Repeat until a fixable operation appears: a repeated singleton creation, a
-   per-item lookup, a broad scan, a wrapper traversal, a cache miss storm, a
-   subprocess startup, a serialization step, or a wait.
-7. Add cardinality metadata to every split: count of rows/files/symbols/nodes,
-   cache hits/misses, bytes, output rows, and skipped items.
-8. Record the before profile in the ledger before touching code.
-
-Write profile records to the run history with parent/child span names when
-possible. Separate wall time from CPU time when the tools allow it. Mark cache
-state explicitly: cold index, cold evidence/cache fill, warm cache hit, repeated
-focused run, or production-like mixed state.
-
-## Phase 4: Diagnose And Find Speedups
-
-Classify the dominant span before choosing a fix:
-
-| Profile shape                                         | Likely cause                                                                   | First fixes to test                                                                                               |
-| ----------------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
-| Cold path huge, warm path fast                        | Derived evidence/cache fill, expensive initialization, or cache invalidation   | Persist the derived result, reuse compatible cache versions, batch cache fills, hoist initialization              |
-| Warm path still slow                                  | Cache scan, query shape, deserialization, reshaping, rendering, or output size | Narrow query, add indexes, store compact payloads, stream or avoid repeated object shaping                        |
-| Same expensive setup repeated across many files/items | Singleton/client/checker/session/project built inside a loop                   | Preload required inputs, create once after inputs are stable, cache per project/process                           |
-| Many medium-cost per-item operations                  | N+1 lookups, scalar provider calls, repeated source reads                      | Batch by provider/file/key, load rows in bulk, group work by locality                                             |
-| Traversal span grows with AST/source nodes            | Wrapper allocation or broad source scan                                        | Use lower-level APIs, prefilter by exact names only when output identity proves equivalence, index reusable facts |
-| Database time dominates                               | Broad scan, missing index, many statements, repeated prepares                  | Push filters into SQL, batch queries, cache prepared statements, add measured indexes                             |
-| Child process or startup dominates                    | Too many subprocesses or cold tool startup                                     | Reuse workers, batch commands, keep warm daemons, collapse process boundaries                                     |
-| Serialization/output dominates                        | Large JSON, repeated formatting, full materialization                          | Stream, summarize, avoid duplicate fields, or add an explicit compact mode                                        |
-
-For the current pipeline, look for repeated work, broad scans, N+1 lookups,
-uncached pure work, avoidable source or semantic reads, large arrays, late
-filters, batchable per-file work, excessive subprocess startup, serialization
-cost, cache invalidation churn, and safe parallelism. Prioritize by measured
-span cost multiplied by real workload frequency; do not chase a large cold-only
-span if the stated purpose depends on warm interactive latency.
-
-Favor fixes in this order when they preserve output:
-
-1. Remove accidental repetition: hoist, memoize, reuse, or preload.
-2. Batch scalar work by provider, file, database key, network endpoint, or
-   process.
-3. Move stable derived work from the hot path into an index/cache with a clear
-   invalidation key.
-4. Replace broad scans with indexed lookups or candidate-first retrieval.
-5. Replace high-overhead wrapper APIs with lower-level APIs only after output
-   identity checks prove equivalence.
-6. Add pruning only when it is mathematically equivalent or output-identity
-   checks across representative corpora prove no observable change.
-
-For alternative designs, restate the output contract first. Ask whether SQLite
-can answer directly, an index/cache/precomputed table can move work out of the
-hot path, batch queries can replace loops, a cheap pruning stage can precede
-exact work, or workers can run independent phases safely.
-
-## Phase 5: Implement And Verify
-
-Make the smallest reversible change that tests one performance hypothesis.
-Update the ledger and run history with hypothesis, changed files/symbols,
-before/after timings, profile-span deltas, output comparison, tests, and gates.
-
-After each candidate fix, run the smallest valid before/after matrix for the
-target scenario: unprofiled control, profiled profile, output hash or semantic
-identity check, and representative correctness tests. If a faster change alters
-the output contract, reject or revert it unless the user explicitly approved a
-behavior change.
-
-Run the narrow correctness check, benchmark cases, `scip-query diff-impact
---json`, and `scip-query diff-gate --json`; reindex first if freshness is not
-proven. Also run postchecks matching the change type. End with starting time,
-final time, percentage change, accepted changes, rejected ideas, remaining
-bottlenecks, and the next target. If results conflict, keep the change only when
-the target scenario and output contract justify it; otherwise revert and record
-the rejected hypothesis.
-
-## Phase 6: Report And Visualize
-
-End every optimization round with a compact scoreboard generated from the run
-history, not hand-copied memory. At minimum, show starting value, current value,
-delta, scenario, corpus, commit/version, and output identity evidence. When the
-history has enough rows, produce a trend table or chart for the target command
-or workflow. Keep Markdown readable for humans, but treat the structured
-history as the source of truth.
+Record input parsing, option resolution, subprocesses, lookups, database queries, graph traversal, source scans, semantic calls, cache reads/writes, rendering, serialization, and verification.
+
+This step is complete only when each major pipeline step can be timed as a profile span.
+
+### 4. Profile the chain
+
+0. Check whether the target app already has an instrumentation layer before adding spans — a bespoke profiling harness competes with the one the codebase already trusts. When the target is scip-query itself, its instrumentation is `src/instrumentation/profile.ts` (`profileSpan`, env-gated by `SCIP_QUERY_PROFILE`/`SCIP_QUERY_PROFILE_OUT`, with `SCIP_QUERY_PROFILE_CACHE_STATE` for cache-state labels) — use it, don't add a parallel one.
+1. Measure the target unprofiled.
+2. Measure profiled once and compare overhead.
+3. Measure distinct states: cold index, cold evidence/cache fill, warm cache hit, repeated focused run, production-like mixed state.
+4. Add coarse spans covering the whole chain.
+5. Split the largest workload-weighted span.
+6. Repeat until the slow operation is a repeated lookup, initialization, scan, traversal, subprocess, serialization step, or wait.
+7. Write span records with cardinality to run history.
+
+This step is complete only when the dominant cost is concrete enough to form a falsifiable hypothesis.
+
+### 5. Diagnose and test one hypothesis
+
+Classify the dominant shape: cold-only setup, warm slow path, repeated setup, N+1 work, broad scan, database time, subprocess startup, serialization, or cache invalidation. Prefer fixes in this order:
+
+1. Remove accidental repetition.
+2. Batch scalar work.
+3. Move stable derived work to an index/cache with invalidation.
+4. Replace broad scans with indexed lookups.
+5. Replace wrapper APIs only after output identity proves equivalence.
+6. Add pruning only when mathematically equivalent or corpus-proven.
+
+Make the smallest reversible change that tests one hypothesis.
+
+This step is complete only when before/after timings, profile deltas, and output identity are recorded.
+
+### 6. Verify and report
+
+Run the narrow correctness check, benchmark cases, routed postchecks, and invoke `scip-verify`.
+
+Reject faster changes that alter the output contract unless the user approved a behavior change.
+
+End with a scoreboard from run history: starting value, current value, delta, scenario, corpus, commit/version, output identity, accepted changes, rejected ideas, remaining bottlenecks, and next target.

package/skills/scip-integrity-audit/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: scip-integrity-audit
+description: Audit whether implementations are real with scip-query. Use for suspected faked or half-implemented features, decorative checkers or verifiers that never fail, dead code paths hidden behind graceful fallbacks, metrics that may be lying, or a "does any of this actually work" interrogation of a system.
+commands:
+  - scip-query refs <symbol>
+  - scip-query code <symbol>
+  - scip-query trace <symbol>
+  - scip-query call-graph <symbol>
+  - scip-query twin-drift -s <scope> --json
+  - scip-query twin-ab <symbolA> <symbolB>
+  - scip-query outline <file> --signatures
+---
+
+# scip-integrity-audit
+
+Use this skill to interrogate whether a system's claims are backed by real
+implementations. Structural review asks "is this well organized?"
+(`scip-maintainability`); this skill asks **"is this real?"** — it hunts
+decorative checkers, adapters written against imagined data, features that
+have silently never run, and numbers nobody ever recomputed.
+
+Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
+
+## The Stance
+
+A green result you have never seen fail is unverified. Every status word,
+banner, and metric is testimony from the code, not evidence about the code —
+cross-examine the producer before believing it. The most dangerous code is
+not broken code; it is code that reports success without doing the work.
+
+## Drills
+
+Run all five over the chosen scope. Each has a checkable exit.
+
+### 1. Falsify every checker
+
+Inventory everything in scope that accepts/rejects, passes/fails, or
+validates (checkers, gates, verifiers, validators — find producers with
+`refs`/`call-graph` on the status words in output). For each one, construct
+an input that MUST fail — a wrong binding, a corrupt file, an impossible
+value — and run it. A checker that passes its should-fail input is
+decorative: file it as a defect, not a note.
+Complete only when every checker in scope has been witnessed rejecting a
+constructed should-fail input, or is listed with a reason it cannot be.
+
+### 2. Diff every adapter against captured reality
+
+For each parser/adapter of an external format (tool output, XML/JSON
+schemas, protocol messages): obtain ONE real sample from the actual source
+and diff it against the code's assumptions and the tests' fixtures. Ask of
+every fixture: was this generated from reality, or imagined? A parser and a
+hand-written fixture can validate each other's shared hallucination
+indefinitely.
+Complete only when every adapter has been checked against at least one
+captured-real sample.
+
+### 3. Autopsy every fallback
+
+Graceful degradation is where dead features hide: a primary path that has
+never worked looks identical to a healthy fallback. For every catch block,
+`?? fallback`, and degraded mode in scope: produce an execution witness that
+the PRIMARY path runs (a test, a probe, a log). Use `scip-probe-reachability`
+for parser/AST branch reachability. A fallback that always fires means the
+feature above it is dead — date of death: birth.
+Complete only when every fallback's primary path has a witness or a filed
+defect.
+
+### 4. Hand-compute every metric twice
+
+For each number the system reports (scores, counts, estimates): pick two
+concrete instances, compute the expected value by hand from first
+principles, and compare. Off-by-a-factor errors (double counting, inflated
+estimates) survive for years because nobody ever recomputes one sample.
+Complete only when every reported metric has two hand-verified samples.
+
+### 5. Cross-examine same-concept twins
+
+Where one concept is computed in more than one place, feed both the same
+input and require the same answer. `twin-drift` finds the same-name cases
+mechanically; for same-concept-different-name pairs, trace the concept's
+consumers with `refs` and compare implementations with `code`. Once a pair
+is identified, `scip-query twin-ab <symbolA> <symbolB>` scaffolds a
+table-driven vitest file that imports both and asserts equal output —
+fill in the input table and run it. Disagreement between twins means at
+least one is wrong — determine which before consolidating.
+Complete only when every discovered twin pair has been compared on a shared
+input.
+
+## Severity
+
+Rank findings by what the failure does to a user who trusted the output:
+a decorative checker or false "verified" banner outranks everything; a
+dead-but-fallbacked feature outranks a wrong metric; a wrong metric outranks
+structural mess. Route structural findings to `scip-maintainability` —
+they are real but they are not lies.
+
+## Reporting
+
+File each finding with: the claim as displayed, the producer (file:line),
+the drill that exposed it, the should-fail input or real sample used, and
+the fix. The audit is complete only when every drill's exit criterion is
+met for the scope, and every defect found has a regression artifact — a
+test, fixture, or model that fails on the pre-fix behavior.

package/skills/scip-integrity-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "scip integrity audit"
+  short_description: "Interrogate whether implementations are real: falsify checkers, diff adapters against reality, autopsy fallbacks."
+  default_prompt: "Run the scip-integrity-audit drills over this codebase and report every decorative checker, dead-behind-fallback feature, and lying metric."