@vyuhlabs/dxkit 2.5.2 → 2.7.0

package/templates/.claude/skills/dxkit-action/SKILL.md

@@ -11,7 +11,7 @@ This skill takes a dxkit report and drives the fix loop with the user. Reach for
 
 ```
 [1] Read the report          → understand what's flagged
-[2] Prioritize               → severity + reachability + cost
+[2] Prioritize               → severity + reachability + blast radius + cost
 [3] Plan                     → ordered list of edits
 [4] Execute                  → fix one finding at a time
 [5] Verify                   → re-run the analyzer, confirm score moved
@@ -20,6 +20,14 @@ This skill takes a dxkit report and drives the fix loop with the user. Reach for
 
 Don't skip [5]. Re-running the analyzer is the only way to confirm the fix landed correctly.
 
+For the richest input, read the **detailed** report with graph context attached:
+
+```bash
+npx vyuh-dxkit vulnerabilities --detailed --graph-context   # or test-gaps / quality
+```
+
+`--graph-context` adds a "Graph context" column (the module a finding lives in + its blast radius — how many files call into it) so you can plan the fix without separately discovering structure. It's a structural HINT, not ground truth — read "Graph context" below for how to use it safely.
+
 ## Priority order
 
 Walk findings in this order (highest to lowest):
@@ -33,6 +41,18 @@ Walk findings in this order (highest to lowest):
 
 Skip items where reachability is "no" (graphify can't find a call path) UNLESS the finding is a secret leak (those don't depend on reachability).
 
+## Graph context (structural blast radius)
+
+When the report was generated with `--graph-context`, each finding carries a "Graph context" cell: the module/role it belongs to and its **blast radius** (`role · N caller files`) — how many other files call into the finding's file. Use it to sharpen prioritization and planning, under three hard rules.
+
+**1. Additive only — it never overrides severity or reachability.** Blast radius is a tie-breaker between findings of similar severity, not a re-ranking of the priority list above. Among two HIGH findings, fix the one with the larger blast radius first (more depends on it). A LOW finding never jumps a HIGH one because its blast radius is bigger.
+
+**2. A blank or zero blast radius is NOT "safe to change".** The cell reads `blast radius n/a (call graph)` for languages whose call graph the analyzer can't resolve (C# is the known case — cross-assembly references aren't followed, so heavily-used files look like they have zero callers). Treat n/a — and even a literal `0 caller files` — as **unknown**, never as evidence the file is safe to edit freely. When blast radius is n/a, fall back to the module/role label (that part is reliable) and verify callers the normal way (grep / read) before a risky edit. Do **not** deprioritize a real finding just because its blast radius is empty.
+
+**3. Confirm the symbol before you act on it.** The context may name an enclosing symbol (the function the finding sits in). It's a best-effort guess (the graph stores declaration lines, not end lines), so open the file and confirm the finding is actually inside that symbol before editing or writing a test against it.
+
+Used within those rules, the win is concrete: a high blast radius tells you which caller files to re-check and re-test in step [5] after the fix, and the module label orients you fast. Same-name symbols can inflate the count — a suspiciously huge number is usually conflation, not reality.
+
 ## Common fix recipes
 
 ### Secret in code
@@ -47,15 +67,17 @@ npx vyuh-dxkit vulnerabilities --json | jq '.summary.findings'
 
 Don't try to redact the secret in place — the git history still has it. Rotation is the only true fix.
 
+If the "secret" is actually a placeholder in test code (e.g., `"sk_test_xxxxxxxxxxxx"` with no real credential value), confirm with the developer and allowlist via `dxkit-allow:test-fixture` — see "Allowlisting (when fix is not viable)" below.
+
 ### SAST finding (semgrep)
 
 ```bash
 # 1. Read the finding's rule + line range from the report
 # 2. Open the file, understand why semgrep flagged it
-# 3. Either FIX (preferred) or SUPPRESS (carefully)
+# 3. Either FIX (preferred) or ALLOWLIST (carefully — see below)
 ```
 
-Suppression is `// nosemgrep: <rule-id>` on the offending line. Use sparingly — every suppression is a future maintenance burden. Better: fix the underlying issue.
+If the finding is a true false positive or intentional pattern (test fixture, mitigated externally), suppress via dxkit's allowlist — NOT via semgrep's `// nosemgrep:`. The dxkit allowlist is the canonical surface (single source of truth across every scanner), carries a typed category + reason, and is audit-trackable through `vyuh-dxkit allowlist audit`. See "Allowlisting (when fix is not viable)" below.
 
 ### Dependency vulnerability
 
@@ -70,6 +92,8 @@ For peer-dep conflicts: `npm install <pkg>@<patched-version> --legacy-peer-deps`
 
 For Python: `pip install --upgrade <pkg>=<patched>` then re-pip-freeze. For Go: `go get <pkg>@<patched>` then `go mod tidy`. For Ruby: edit Gemfile, `bundle update <pkg>`. For Rust: `cargo update -p <pkg> --precise <patched>`.
 
+If no patched version exists OR the upgrade breaks other constraints AND the risk is mitigated externally (network policy, WAF, runtime guard), allowlist with `category=mitigated-externally` and a reason describing the mitigation. If the team is accepting the risk while waiting on a fix, `category=accepted-risk` + an expiry tied to the fix deadline.
+
 ### Test gap
 
 ```bash
@@ -93,6 +117,88 @@ Don't write tests that just import the module — write tests that exercise beha
 
 If the finding is a false positive, add `// slop-ok: <reason>` on the offending line (or `# slop-ok` for non-JS).
 
+## Allowlisting (when fix is not viable)
+
+**Fix first.** The allowlist is the SECOND option, not the first. When you reach for it, choose deliberately — every allowlist entry is a future maintenance burden the customer's team will revisit.
+
+Five typed categories signal WHY the suppression is in place:
+
+| Category | Meaning | Where it lives |
+|---|---|---|
+| `false-positive` | Scanner is wrong about this code | Inline annotation OR file-level |
+| `test-fixture` | Intentional pattern in a fixture / test file | Inline annotation OR file-level |
+| `mitigated-externally` | Real risk but neutralized at runtime (WAF, env, etc.) | Inline annotation OR file-level |
+| `accepted-risk` | Real risk, accepted by the team, signed off | File-level only (needs expiry + acknowledged severity) |
+| `deferred` | Real, will fix later, tracked work | File-level only (needs expiry) |
+
+`accepted-risk` and `deferred` require an `expiresAt` date because they describe assertions that should age out — by default the CLI sets 90 days. `false-positive`, `test-fixture`, and `mitigated-externally` describe assertions that don't naturally stale; they may omit expiry.
+
+### The two surfaces
+
+**Inline annotation** is the natural fit for source-anchored findings (secrets, code, config, dep-vuln, hygiene) with an inline-compatible category. The annotation lives next to the line it suppresses:
+
+```python
+api_key = "sk_test_xxxx"  # dxkit-allow:test-fixture reason="placeholder in unit test"
+```
+
+Or, for long source lines, above:
+
+```typescript
+// dxkit-allow:false-positive reason="regex matches intentional placeholder"
+const apiKey = "sk_test_xxxx";
+```
+
+The grammar is uniform across every language; only the comment marker varies (`#` for python/ruby, `//` for typescript/go/rust/csharp/kotlin/java). Don't type it by hand — let dxkit insert it for you (see CLI below).
+
+**File-level allowlist** lives at `.dxkit/allowlist.json` and is the surface for:
+
+- Cross-file or whole-file findings (duplication, coverage-gap, test-gap, god-file, large-file, stale-file)
+- Findings with no stable single-line attachment (dep-vuln, secret-hmac)
+- Any `accepted-risk` or `deferred` suppression regardless of kind
+
+### Add an allowlist entry (canonical path)
+
+Don't hand-edit the annotation comment or the JSON file — let the CLI insert it correctly:
+
+```bash
+# Inline annotation at file:line — for source-anchored findings
+# with an inline-compatible category
+npx vyuh-dxkit allowlist add src/auth/oauth.ts:42 \
+    --category=test-fixture --reason="placeholder in unit test"
+
+# File-level entry — for everything else (kind + fingerprint required;
+# both come straight from the guardrail check's output)
+npx vyuh-dxkit allowlist add --fingerprint=a3f9c0e8b7d2e1f4 \
+    --kind=dep-vuln --category=accepted-risk \
+    --reason="WAF rule X mitigates this CVE" --expires=2026-08-22
+```
+
+The guardrail's block message gives you the exact command to paste for every blocked finding — file path + line for inline-compatible kinds, fingerprint + kind for everything else. Just copy-paste.
+
+### When the finding only carries an id (sanitized / ref-based baseline)
+
+If you're seeing a blocked finding labelled `<sanitized>` (in `baseline show` output) OR with no `file`/`line` columns in the PR-comment table, the repo's baseline mode is `committed-sanitized` or `ref-based` and the human-readable locator was stripped at write time. Two options:
+
+- **Inspect the finding in the current scan.** The fingerprint pairs against the live scan's output, which is rich (always). Re-run the matching analyzer (`vyuh-dxkit vulnerabilities`, `vyuh-dxkit health`, etc.) and grep the JSON output for the fingerprint — that finding has full file:line context.
+- **Allowlist by fingerprint anyway.** File-level allowlist entries only need fingerprint + kind, both of which the guardrail message still provides. The category + reason apply regardless of whether the locator is visible at baseline time.
+
+The fingerprint contract is preserved across all three modes — `committed-full`, `committed-sanitized`, `ref-based` all produce the same identity bytes for the same finding. Sanitization only strips the human-readable rendering; it doesn't change which findings pair across runs.
+
+### Review what's allowlisted
+
+```bash
+npx vyuh-dxkit allowlist list             # all entries (text)
+npx vyuh-dxkit allowlist show <fingerprint>  # one entry's full detail
+npx vyuh-dxkit allowlist audit            # expired / soon-to-expire / missing-rationale
+npx vyuh-dxkit allowlist prune            # remove expired entries
+```
+
+Run `audit` periodically — `accepted-risk` and `deferred` entries that pass their expiry should either be re-justified (renew expiry) or pruned (remove the entry; the underlying finding will re-flag on the next scan).
+
+### Stale annotations
+
+If the underlying finding is fixed but the inline annotation lingers, the next scan emits a `stale-allow` finding pointing at the orphaned comment. The remediation is always to remove the annotation — dxkit refuses to allowlist a stale-allow finding (allowlisting the warning that an annotation is stale would defeat the entire model).
+
 ## Verification — never skip
 
 After each fix:
@@ -111,14 +217,19 @@ If the finding's still there: the fix didn't work, try again.
 
 ## Baseline decisions
 
-Once a finding is fixed AND verified gone, the workflow depends on what changed:
+Once a finding is processed (fixed, allowlisted, or accepted), the workflow depends on which path you took:
 
 | Scenario | Action |
 |---|---|
-| Fix landed via a code change | Commit the code. Baseline is unchanged. Future scans confirm the fix held. |
+| Fix landed via a code change | Commit the code. Baseline + allowlist are unchanged. Future scans confirm the fix held. |
+| Genuine false positive OR intentional pattern | `vyuh-dxkit allowlist add` with `category=false-positive` or `test-fixture`. Commit the annotation / allowlist file. Baseline is unchanged. |
+| Real risk neutralized externally (WAF, runtime guard) | `vyuh-dxkit allowlist add` with `category=mitigated-externally` + a reason describing the mitigation. Baseline unchanged. |
+| Real risk, accepted by team, won't fix | `vyuh-dxkit allowlist add` with `category=accepted-risk` + `--expires=YYYY-MM-DD` (defaults 90 days). Acknowledged-severity required for high/critical. |
+| Real risk, will fix later (tracked work) | `vyuh-dxkit allowlist add` with `category=deferred` + `--expires=YYYY-MM-DD`. The expiry forces re-review when the deadline passes. |
 | Fix landed via a config change (e.g., new entry in `.dxkit-ignore`) | Re-baseline: `npx vyuh-dxkit baseline create --force`. Commit both `.dxkit-ignore` and the new baseline. |
-| Finding accepted as known + not blocking | Re-baseline with explicit reason in the commit message. Future scans treat it as pre-existing, not net-new. |
-| Finding is genuinely a false positive | First try suppression on the offending line. If you can't suppress, re-baseline. |
+| Brownfield acceptance (the whole CURRENT state is known mess; future regressions must be net-new) | Re-baseline with an explicit reason in the commit message. Reserve this for the deliberate "draw a line here" moment, not per-finding suppression. |
+
+**Prefer the allowlist over re-baselining for per-finding decisions.** The allowlist carries a typed category + reason + (when relevant) expiry; the baseline carries only "this finding was here." Future maintainers reading `vyuh-dxkit allowlist show <fingerprint>` see WHY the suppression is in place; reading the baseline file shows only that the finding existed at capture time. Per-finding decisions belong in the allowlist; codebase-wide brownfield acceptance belongs in the baseline.
 
 **Never** re-baseline a finding silently — the commit message should explain why the regression is accepted. Future maintainers reading `git log .dxkit/baselines/` should see the rationale.
 
@@ -134,17 +245,20 @@ Exit 0 = your fixes didn't introduce any net-new regressions (you only removed/f
 
 ## When fixes get expensive
 
-Sometimes the right call is: don't fix, accept as baseline.
+Sometimes the right call is: don't fix, allowlist (or re-baseline if it's brownfield-wide).
 
 Examples:
-- Legacy code on a deprecation path (sunset > fix)
-- A SAST finding in vendored code you don't maintain
-- A test gap on a one-off script that doesn't merit tests
+- Legacy code on a deprecation path (sunset > fix) → `accepted-risk` with expiry matching the sunset date
+- A SAST finding in vendored code you don't maintain → `mitigated-externally` if the vendor patches separately, else `accepted-risk`
+- A test gap on a one-off script that doesn't merit tests → `accepted-risk`
+- An import line flagged by a scanner that you've reviewed and confirmed safe → `false-positive` inline annotation at the import
 
-In those cases: accept-as-baseline with a commit message explaining the call. dxkit's baseline IS designed to support this — the brownfield contract is "today's mess is acknowledged; tomorrow's must be a real improvement." Use it.
+In those cases: `vyuh-dxkit allowlist add` is the right tool for per-finding decisions (typed reason + expiry where relevant). Reserve "accept as baseline" for the deliberate one-shot brownfield moment ("this entire current state is known mess; today's findings are the new baseline"). The two surfaces complement each other — allowlist for individual judgment calls, baseline for the codebase-wide line in the sand.
 
 ## Hand-offs
 
 - For ignore-file edits as part of a fix → `dxkit-config` skill
 - For hook-related issues during a fix push → `dxkit-hooks` skill
 - For re-running reports between fixes → `dxkit-reports` skill
+- For broken dxkit install (hooks not firing, vyuh-dxkit not on PATH) → `dxkit-fix` skill
+- For allowlist management beyond the per-finding `add` path (auditing existing entries, pruning expired ones, reviewing the team's overall suppression posture) → run `npx vyuh-dxkit allowlist audit` / `list` / `prune` directly; no separate skill yet

package/templates/.claude/skills/dxkit-onboard/SKILL.md

@@ -113,7 +113,19 @@ Don't auto-execute baseline capture here — step 5 has a values-laden warning t
 
 This is the step with permanent consequences. The baseline records the fingerprint of every finding currently in the repo and tells future scans "these are pre-existing — don't block on them."
 
-Before running `baseline create` on a fresh customer:
+Before running `baseline create` on a fresh customer, ASK about disclosure posture (the baseline file is committed to git):
+
+> **About to capture the first baseline. One quick choice first — which posture fits this repo?**
+>
+> The baseline file lives at `.dxkit/baselines/main.json`. Three modes trade disclosure for diagnostic richness:
+>
+> - **`committed-full`** (default for private repos) — Rich entries with file paths, package names, advisory IDs. Best diagnostic quality. Fine when only your team reads the repo.
+> - **`committed-sanitized`** (compliance-conscious private) — Stripped to fingerprint + kind only. Hides location detail; matching still works. Good when many people have repo read access.
+> - **`ref-based`** (default for public repos) — No baseline file at all. Each guardrail check recomputes the prior side from a git ref (e.g. `origin/main`). Zero disclosure.
+>
+> Auto-pick: run `vyuh-dxkit baseline create` and dxkit picks the right default by probing `gh repo view`. Or pin explicitly via `--mode=<X>` or `.dxkit/policy.json`.
+
+Then the standard "lock-in" warning:
 
 > **About to capture the first baseline.**
 >
@@ -125,14 +137,30 @@ Before running `baseline create` on a fresh customer:
 
 If they want to triage first, hand off to `dxkit-action` — that skill prioritizes findings before baseline lock-in. Come back to step 5 after triage.
 
-If they confirm baseline:
+If they confirm baseline (and they're happy with auto-picked mode):
 
 ```bash
 npx vyuh-dxkit baseline create
-git add .dxkit/baselines/
+git add .dxkit/baselines/   # only if mode wrote a file (committed-*)
 git commit -m "chore: capture dxkit baseline"
 ```
 
+If they want to PIN the mode explicitly (so every developer + CI run agrees), write `.dxkit/policy.json`:
+
+```bash
+mkdir -p .dxkit
+cat > .dxkit/policy.json <<'JSON'
+{
+  "baseline": {
+    "mode": "ref-based",
+    "ref": "origin/main"
+  }
+}
+JSON
+git add .dxkit/policy.json
+git commit -m "chore: pin baseline mode in policy.json"
+```
+
 ### 6. Pre-commit ASK
 
 Pre-commit is opt-in even under `--full` because it re-runs every analyzer on every commit (~1-3 min on 500+ file repos). Most teams skip it.

package/templates/.claude/skills/dxkit-reports/SKILL.md

@@ -19,7 +19,9 @@ This skill runs dxkit analyzers and reads their output back to the user. It's th
 | "License inventory" | `npx vyuh-dxkit licenses` | Every dependency's declared license |
 | "Bill of materials" | `npx vyuh-dxkit bom` | Licenses + dep vulnerabilities joined (15-col XLSX-ready output) |
 | "Run everything" | `npx vyuh-dxkit report` | Every analyzer in one shot, ~3-5 min |
-| "Show me the dashboard" | `npx vyuh-dxkit dashboard` | Single HTML view of all reports — opens at `.dxkit/reports/dashboard.html` |
+| "Show me the dashboard" | `npx vyuh-dxkit dashboard` | Single HTML view of all reports — opens at `.dxkit/reports/dashboard.html`, incl. an interactive **Graph** tab (code structure) |
+| "What does this repo do / where is X" | `npx vyuh-dxkit explore <sub>` | Query the code graph: entry-points / hot-files / communities / file / feature / api-surface |
+| "Token-efficient context for a query" | `npx vyuh-dxkit context <query>` | Slim structural slice for an LLM (also a fix-time hint via `--graph-context`) |
 
 ## Where output lands
 

package/templates/AGENTS.md.template

@@ -114,12 +114,19 @@ Reach for the relevant skill when working in this repo. They wrap the `vyuh-dxki
 | Test coverage gaps | `npx vyuh-dxkit test-gaps` |
 | Code quality + slop | `npx vyuh-dxkit quality` |
 | Bill of materials | `npx vyuh-dxkit bom` |
-| Dashboard (HTML) | `npx vyuh-dxkit dashboard` |
+| Dashboard (HTML, incl. interactive Graph tab) | `npx vyuh-dxkit dashboard` |
+| What does this repo do / where does X live | `npx vyuh-dxkit explore <sub>` |
+| Token-efficient structural context for a query | `npx vyuh-dxkit context <query>` |
 | Guardrail check (baseline diff) | `npx vyuh-dxkit guardrail check` |
 | Doctor (verify setup) | `npx vyuh-dxkit doctor` |
 
 The pre-push hook runs `guardrail check` automatically — blocks net-new regressions before they leave your machine.
 
+When fixing findings, run the detailed report with `--graph-context`
+(e.g. `npx vyuh-dxkit vulnerabilities --detailed --graph-context`) — it
+attaches each finding's module + blast radius so you can navigate by the
+code graph instead of repeated whole-file reads.
+
 ## Security rules — never violate
 
 1. **Never output, log, or commit secrets** — no API keys, tokens, passwords, or credentials in code, commits, or files Claude writes

package/dist/baseline/producers/licenses.d.ts

@@ -1,23 +0,0 @@
-/**
- * Licenses → baseline-entry producer.
- *
- * One kind: `license` — per-package license attribution.
- * `(package, version, licenseType)` is the identity tuple, so a
- * re-licensing event on the same pinned version (compliance teams'
- * canonical concern) registers as a fresh finding even when no
- * version bump happened.
- *
- * Reads from `CapabilityReport.licenses.findings` — already in the
- * cached `AnalysisResult`, no extra gather work needed. Pure
- * function over its input.
- */
-import type { BaselineEntry } from '../types';
-import type { LicensesResult } from '../../languages/capabilities/types';
-/**
- * Build `license` entries from a licenses capability envelope.
- * Findings with an empty `licenseType` are emitted with the literal
- * `'UNKNOWN'` so identity stays stable across runs even when the
- * underlying tool can't resolve the SPDX id.
- */
-export declare function licensesToBaselineEntries(licenses: LicensesResult | undefined): BaselineEntry[];
-//# sourceMappingURL=licenses.d.ts.map

package/dist/baseline/producers/licenses.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"licenses.d.ts","sourceRoot":"","sources":["../../../src/baseline/producers/licenses.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAGH,OAAO,KAAK,EAAE,aAAa,EAAwB,MAAM,UAAU,CAAC;AACpE,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,oCAAoC,CAAC;AAEzE;;;;;GAKG;AACH,wBAAgB,yBAAyB,CAAC,QAAQ,EAAE,cAAc,GAAG,SAAS,GAAG,aAAa,EAAE,CAoB/F"}

package/dist/baseline/producers/licenses.js

@@ -1,46 +0,0 @@
-"use strict";
-/**
- * Licenses → baseline-entry producer.
- *
- * One kind: `license` — per-package license attribution.
- * `(package, version, licenseType)` is the identity tuple, so a
- * re-licensing event on the same pinned version (compliance teams'
- * canonical concern) registers as a fresh finding even when no
- * version bump happened.
- *
- * Reads from `CapabilityReport.licenses.findings` — already in the
- * cached `AnalysisResult`, no extra gather work needed. Pure
- * function over its input.
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.licensesToBaselineEntries = licensesToBaselineEntries;
-const finding_identity_1 = require("../finding-identity");
-/**
- * Build `license` entries from a licenses capability envelope.
- * Findings with an empty `licenseType` are emitted with the literal
- * `'UNKNOWN'` so identity stays stable across runs even when the
- * underlying tool can't resolve the SPDX id.
- */
-function licensesToBaselineEntries(licenses) {
-    if (!licenses)
-        return [];
-    const out = [];
-    for (const f of licenses.findings) {
-        const licenseType = f.licenseType.length > 0 ? f.licenseType : 'UNKNOWN';
-        const input = {
-            kind: 'license',
-            package: f.package,
-            version: f.version,
-            licenseType,
-        };
-        out.push({
-            id: (0, finding_identity_1.identityFor)(input),
-            kind: 'license',
-            package: f.package,
-            version: f.version,
-            licenseType,
-        });
-    }
-    return out;
-}
-//# sourceMappingURL=licenses.js.map

package/dist/baseline/producers/licenses.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"licenses.js","sourceRoot":"","sources":["../../../src/baseline/producers/licenses.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;GAYG;;AAYH,8DAoBC;AA9BD,0DAAkD;AAIlD;;;;;GAKG;AACH,SAAgB,yBAAyB,CAAC,QAAoC;IAC5E,IAAI,CAAC,QAAQ;QAAE,OAAO,EAAE,CAAC;IACzB,MAAM,GAAG,GAAoB,EAAE,CAAC;IAChC,KAAK,MAAM,CAAC,IAAI,QAAQ,CAAC,QAAQ,EAAE,CAAC;QAClC,MAAM,WAAW,GAAG,CAAC,CAAC,WAAW,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,SAAS,CAAC;QACzE,MAAM,KAAK,GAAyB;YAClC,IAAI,EAAE,SAAS;YACf,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,WAAW;SACZ,CAAC;QACF,GAAG,CAAC,IAAI,CAAC;YACP,EAAE,EAAE,IAAA,8BAAW,EAAC,KAAK,CAAC;YACtB,IAAI,EAAE,SAAS;YACf,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,WAAW;SACZ,CAAC,CAAC;IACL,CAAC;IACD,OAAO,GAAG,CAAC;AACb,CAAC"}