feat(threat-intel): recognize the CISA Known Exploited Vulnerabilities (KEV) catalog - #133
Conversation
Adds a new threat-intel adapter alongside the existing STIX/MISP/TAXII/ OpenCTI family: POST /api/threat-intel/cisa-kev fetches the CISA Known Exploited Vulnerabilities catalog (a single well-known public JSON feed, https://www.cisa.gov/known-exploited-vulnerabilities-catalog) and upserts one `cve`-typed ThreatIndicator per entry, keyed by CVE ID, severity escalated to Critical when CISA has tied the CVE to a known ransomware campaign (High otherwise — mere inclusion in the catalog already signals CISA-confirmed active exploitation). - src/kev_import.rs: pure parser (`parse_kev_document`), mirroring the misp_import/opencti_import/stix_import module shape exactly. Accepts the real catalog shape (`{"vulnerabilities": [...]}`) or a bare array. KEV entries carry no IP/domain/URL/hash observable, so `dnsbl` stays empty (kept only for ThreatFeedImport parity). - src/lib.rs: `import_kev_feed` handler follows the phishing-database fetch-by-URL pattern (not the MISP/STIX/OpenCTI paste-a-document pattern) since KEV has one canonical, stable, publicly known URL that every consumer wants pulled automatically rather than hand-relayed. Reuses the existing `fetch_text_feed`/`apply_threat_feed_import` plumbing untouched. `validate_http_url` gained a third `allowed_hosts` parameter (was hardcoded to the phishing-database allowlist) so KEV gets its own `www.cisa.gov`-only default, matching the SSRF-safety posture phishing-database already has (opt-out via `allow_non_default_hosts`); all other call sites updated. - crates/waf-ids-core: new buyer-evidence-manifest endpoint entry. - docs/architecture.md, docs/security/compliance-mapping.md: documented alongside the other threat-intel adapters. Deliberately not adding a cargo-fuzz target: none of the five existing JSON-import adapters (misp_import, opencti_import, stix_import, suricata_eve, coraza_audit) have one today — CLAUDE.md's fuzzed-surface list (request scorer, state deserializer, admin-token parser, DNSBL zone export) doesn't cover this adapter family. Matched the existing convention instead: a `parse_never_panics_on_arbitrary_text` unit test, same as its siblings. Verified: cargo fmt --check, cargo test --locked --workspace (all pass except the pre-existing root-sandbox-only `load_surfaces_state_rewrite_failures` flake tracked by PR #93, unrelated to this change), cargo clippy --locked --workspace --all-targets -- -D warnings.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughCISA KEV 카탈로그를 CVE 위협 지표로 가져오는 기능을 추가했습니다. 피드별 지표 소유권을 추적합니다. CVE 지표는 콘텐츠 점수에 사용하지 않습니다. KEV URL은 내장 CISA URL을 사용합니다. 시작 전 종료 신호 등록과 관련 문서 및 테스트를 갱신했습니다. ChangesCISA KEV 통합
종료 신호 등록
Estimated code review effort: 4 (Complex) | ~60 minutes Merge Risk: 🟡 Moderate · up to The PR adds an authenticated server-side CISA KEV refresh that updates shared threat state and removes indicators no longer present. Concurrent refreshes can apply an older catalog snapshot after a newer one, and legacy records lack ownership metadata needed for reconciliation, so these lifecycle risks should be fixed or explicitly accepted before merging. Sequence Diagram(s)sequenceDiagram
participant 관리자
participant import_kev_feed
participant CISA
participant ThreatStore
관리자->>import_kev_feed: POST /api/threat-intel/cisa-kev
import_kev_feed->>CISA: 허용된 URL로 KEV 카탈로그 요청
CISA-->>import_kev_feed: KEV JSON 응답
import_kev_feed->>ThreatStore: CVE 지표와 피드 소유권 갱신
ThreatStore-->>관리자: KevImportResult 응답
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 2📝 Generate docstrings 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Devin Review flagged (PR #133): every KEV-imported CVE indicator was entering score_request's generic substring matcher at High/Critical severity. A legitimate request that happens to reference a cataloged CVE literally (e.g. a vulnerability-management dashboard's own traffic hitting `/api/cve/CVE-2021-44228` through the gateway) would score high enough to trip a default block-mode route -- a real false-positive/ denial-of-service risk, not a hypothetical one. A CVE identifier is vulnerability-catalog metadata, not a request- content attack observable (unlike domain/url/hash/ip indicators from the other threat-intel adapters, which genuinely can appear in malicious traffic). Fix: score_request now short-circuits indicator_type "cve" to never content-match, mirroring the existing ip-type special case. The indicator stays fully visible via /api/threats, feed freshness, KPIs, and buyer evidence -- only request-content scoring is excluded. Added a core-crate unit test (score_request_never_content_matches_cve_indicators) and an HTTP-level regression test (kev_cve_indicators_never_block_legitimate_requests: imports a KEV catalog, creates a default block-mode route, and asserts a request literally containing the cataloged CVE ID is NOT blocked). Verified both fail without the fix and pass with it.
This branch forked from main before #132's shutdown-handler fix merged, so its copy of src/main.rs still had the pre-existing race (readiness announced before the signal handler was registered), making tests/binary.rs::binary_serves_then_shuts_down_on_sigterm flaky here too -- unrelated to this PR's KEV work but blocking its CI green. Ported the identical fix rather than waiting on #132 to merge first; it will no-op once main carries it.
Devin Review flagged (PR #133) that this substantive feature PR was missing the research grounding AGENTS.md's org rule requires (commit paper PDFs + full citations, or cite+link+summarize when redistribution isn't permitted). Added a "Further reading" section to docs/architecture.md (matching docs/fuzzing.md's existing citation convention) citing: - CISA's BOD 22-01, the directive establishing KEV's confirmed-active- exploitation inclusion criterion -- why catalog membership alone already implies at least High severity in kev_import.rs. - Jacobs et al. (2021), the EPSS paper -- the data-driven basis for treating exploitation evidence as a stronger prioritization signal than static CVSS severity. - Shimizu & Hashimoto (2025, arXiv:2506.01220, CC BY 4.0) -- empirical evidence that KEV-first triage cuts urgent-remediation workload ~95% but still misses exploited CVEs EPSS catches, supporting KEV as one adapter among the existing STIX/MISP/TAXII/OpenCTI family rather than a standalone replacement. Committed the arXiv PDF (CC BY 4.0, redistribution explicitly permitted) into docs/papers/, matching the one existing precedent (the fuzzing survey PDF cited from docs/fuzzing.md). The EPSS paper is ACM/SSRN-hosted without a redistributable PDF, so it is cited+linked per AGENTS.md's explicit fallback instead of attached.
… default CodeQL flagged (PR #133, critical severity, rust/request-forgery at src/lib.rs:2646 on the pre-fix commit): "The URL of this request depends on a user-provided value" -- import_kev_feed fetched request.kev_url directly, so a JSON body field flowed into the outbound HTTP client call. validate_kev_import_request already allowlists the host (www.cisa.gov) unless allow_non_default_hosts is set, but that's a value-equality check a couple of calls away from the fetch, not a pattern static analysis reliably recognizes as a sanitizer for the same tainted string reused later. Removed the taint at the source instead of arguing with the analyzer: on the default (non-override) path, the fetch now uses the hardcoded KEV_DEFAULT_URL constant, never request.kev_url -- there is no request-controlled string reaching the HTTP client unless the operator explicitly sets allow_non_default_hosts: true (the same opt-in gate that already exists for the host allowlist). All existing tests point at a local mock server via that same flag, so they're unaffected and still pass. Note: the identical fetch-an-operator-supplied-URL-after-an-allowlist- check pattern also exists in the pre-existing phishing-database and TAXII-poll endpoints (unmodified by this PR) -- out of scope here, but worth the same treatment in a follow-up if CodeQL flags them too.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Devin Review flagged (PR #133): with allow_non_default_hosts false, validate_kev_import_request still checked kev_url against the CISA host allowlist even though import_kev_feed (65d60a9) now always fetches the hardcoded default in that mode -- so a validated same-host custom path was silently discarded, and the validation itself was misleading (accept-then-ignore). Chose Devin's second suggested option over restoring same-host customization: honoring a validated-but-still-request-controlled URL on the default path is exactly the pattern that triggered the original CodeQL SSRF alert, so reintroducing it isn't a real fix. Instead, kev_url is now only validated when allow_non_default_hosts is true (the one mode where it's actually fetched) -- and once opted in, any well-formed http(s) URL is accepted with no host restriction, matching how that same flag already works for phishing-database and TAXII. KEV_ALLOWED_HOSTS is removed as dead code; there is no longer a partial-trust "same host, no opt-in" tier to enforce. Replaced the now-invalid kev_feed_import_rejects_disallowed_host_by_default HTTP test (there is no more "disallowed host" rejection under the new contract) with a validate_kev_import_request unit test covering both modes directly.
CodeQL's critical SSRF alert (rust/request-forgery) was still firing on the previous fix (65d60a9): gating the tainted request.kev_url behind an allow_non_default_hosts runtime flag doesn't register as a sanitizer to CodeQL's dataflow analysis -- the string still originates from the HTTP request body and still reaches fetch_text_feed on that code path, so the alert (rightly, from a pure taint-tracking standpoint) persisted. Rather than keep trying to convince the analyzer a runtime guard is safe, removed the taint source outright: kev_url and allow_non_default_hosts are gone from KevImportRequest entirely. import_kev_feed always fetches AppState::kev_catalog_url, which is deployment-time config only -- set via the new KEV_CATALOG_URL env var (validated at startup, alongside run_from_env's other env parsing) or AppState::with_kev_catalog_url() in tests -- never sourced from a client request. There is now no code path in this handler where request-supplied data reaches an outbound fetch at all. This is a stronger fix than the previous one on the merits too, not just for the analyzer: KEV genuinely has one canonical, stable, government-published URL, so per-request override was never load- bearing functionality, just a testing convenience that's now served by the AppState builder instead. Updated the three affected tests to point AppState::kev_catalog_url at a local mock server instead of the request body, and replaced the now-obsolete kev_url validation test with a plain feed-metadata validation test. CLAUDE.md's Runtime Configuration section documents the new env var.
|
Update on the CodeQL critical SSRF alert ( Pushed a stronger fix instead (1cf1010): removed
Generated by Claude Code |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
fetch_text_feed's url parameter is fed by phishing-database's request-supplied domain_url/ip_url (a pre-existing, admin-gated "fetch from an operator-chosen URL" design on main). Routing the KEV catalog pull through that same shared function -- confirmed via diff against origin/main that fetch_text_feed/validate_http_url were otherwise byte-identical -- was enough for CodeQL's rust/request-forgery query to keep flagging the shared sink as newly touched by this PR, even after KEV_CATALOG_URL was made config-only. Give KEV its own fetch_kev_catalog function (same pattern already used by fetch_taxii_objects) so the config-only path never shares a function with the request-URL adapters, and revert validate_http_url to its original two-argument form now that KEV no longer needs a custom allowed-hosts list. Also add KEV_CATALOG_URL to clear_run_env: Devin Review flagged that an inherited value would leak across run_from_env tests, since the list omitted it while validating every other run_from_env env var.
|
Root cause found for the CodeQL The flagged sink was Fix pushed in Also fixed the "KEV environment escapes test cleanup" finding: Not actioned: the "environment controls privileged catalog fetches" 🟨 finding (no host allowlist on
Generated by Claude Code |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Devin Review flagged that KEV_CATALOG_URL had no host allowlist, so an unintended inherited or misconfigured value could redirect this privileged catalog fetch -- a real SSRF sub-pattern (env-var-sourced URLs are externally influenceable via container/orchestrator inheritance, not just via request bodies), which lines up with why CodeQL kept flagging feed_http.get(url) here even after the previous commit fully decoupled the fetch from any request-derived data. Add validate_kev_catalog_url, enforced both at startup (fail fast on a bad env var) and again immediately before the fetch: the host must be www.cisa.gov or loopback (loopback only so tests can point it at a local mock server), with no override -- unlike the operator-URL adapters, KEV has no legitimate reason to fetch from anywhere else.
|
Commit Re-reading Devin's earlier 🟨 finding on this same PR (" Pushed
Generated by Claude Code |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…allowlist Devin Review caught that AppState::with_kev_catalog_url's doc comment still promised support for pointing KEV_CATALOG_URL at an internal mirror, which the host-allowlist fix in 3a47ce8 now rejects at startup -- a real contract mismatch, not just stale wording. There was never an actual mirror requirement (that phrase was leftover illustrative language from an earlier draft); update the builder's doc comment and CLAUDE.md's Runtime Configuration entry to describe the real contract (CISA's own host, or loopback for local test mocking) rather than inventing a mirror-allowlist feature nobody asked for.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
CodeRabbit review, both real: - kev_import.rs: any non-empty cveID (e.g. "not-a-cve") was accepted and stored as a cve threat indicator. Add is_valid_cve_id, checking CVE.org's CVE-<4-digit year>-<4+ digit sequence> syntax case-insensitively; entries that fail it are now Skipped like a missing cveID already was. Panic-safe on arbitrary catalog text via str::get instead of direct slicing (added a multi-byte-boundary case to parse_never_panics_on_arbitrary_text to cover it). - main.rs: install_shutdown_signal's second definition was gated on cfg(not(unix)), but its body calls tokio::signal::windows::ctrl_c, which only exists on Windows -- any other non-Unix target would fail to compile there. Scope the cfg to windows specifically.
|
Addressing CodeRabbit's 4 findings on commit
Also: Generated by Claude Code |
|
Status update on the CodeQL Summarizing the full trail across four independently-designed fixes, each verified at the code level before pushing:
Each of these was verified to actually close the specific gap it targeted (confirmed via direct source-level diffing and, for #2, byte-for-byte comparison against At this point I think it's more likely than not that this is a modeling gap in CodeQL's Rust/Axum support — specifically, that I don't want to keep reshaping code against an alert that hasn't moved through three structurally different, verified-effective attempts — that's very likely chasing a tool limitation rather than fixing anything real at this point. Flagging for a human with Security-tab access: could someone open the alert ( Everything else on this PR is green locally ( Generated by Claude Code |
Devin Review flagged a real bug in the feed-ownership reconciliation logic introduced by an external merge (192ffba, authored outside this session): apply_threat_feed_import removed every key the refreshing feed had previously owned from the global threats collection unconditionally, without checking whether another feed's ownership record still claimed the same indicator_type+value+source key. Two feeds sharing a key (e.g. the same CVE imported under a shared `source`) meant refreshing either one made the indicator vanish from enforcement until the other feed's next refresh happened to re-add it. Track "still owned by some other feed" via the current (post-replace) ownership table and only reap a dropped key when no feed claims it any more. Also switches previous_keys from a Vec to a HashSet, which incidentally fixes a second (lower-severity) finding on the same commit: the per-threat previous_keys.contains() scan was O(n) per retained item, made O(1) here. Added feed_refresh_preserves_indicators_still_owned_by_another_feed, which fails against the pre-fix logic (the shared indicator disappears after the first feed's refresh) and passes with it -- verified by reasoning through both code paths. Not actioned (informational/acceptable trade-offs, not bugs): - "Upgraded feeds retain withdrawn indicators": state persisted before this feature existed has no ownership history, so the first refresh per feed after upgrade can't retroactively reconcile pre-existing drift. Self-heals from each feed's first post-upgrade refresh onward; there's no safe way to backfill ownership for data imported before it was tracked. - "DNSBL refresh remains append-only": reconciliation covers threats only, matching the scope of the original finding this responds to (KEV catalogs carry no DNSBL entries). Extending it to DNSBL entries for the other four adapters is a follow-up, not a regression here.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
CodeRabbit's latest walkthrough flags "Merge Risk: 🟠 High" based on commit
Current head ( Generated by Claude Code |
…to admin creds Devin Review, both real: - kev_import.rs: apply_threat_feed_import now reconciles (a refresh treats keys missing from the new snapshot as withdrawn and removes them). kev_material_from_value's only acceptance bar was "at least one usable cveID," so a catalog that's mostly unparsable -- a fetch truncated mid-transfer, a CISA response format regression -- would have been accepted and, via reconciliation, read as a mass withdrawal of still-exploited CVEs instead of the bad fetch it actually was. Require a real majority of entries to have parsed (skipped_entries <= threats.len()) before trusting a snapshot as authoritative. Adjusted skips_entries_with_malformed_cve_id's fixture to stay under the new bar and added rejects_catalog_where_most_entries_are_unparsable. - credentials.rs: bootstrap_secrets set the registry-wide CredentialSource to File whenever ANY key -- including a file that supplies only kev_catalog_url -- came from the credentials file, even when ADMIN_TOKEN/ADMIN_TOKENS actually came from env. CredentialSource is documented and reported via HealthStatus/support bundle as admin credential provenance specifically, so this misreported security- relevant operational state. Track admin-credential file/env provenance independently of kev_catalog_url's, matching the documented contract. Added file_only_kev_catalog_url_does_not_misreport_env_admin_token_as_file_backed. Not actioned in this commit -- flagging separately for the user's scope decision: Devin also noted that apply_threat_feed_import's reconciliation now applies uniformly to all five existing feed adapters (STIX/MISP/TAXII/OpenCTI/phishing-database), not just KEV, which changes their prior upsert-only semantics; anyone relying on incremental/partial imports under a reused feed_id across the other four adapters would now see earlier entries treated as withdrawn. This is a cross-adapter behavior/policy question outside what a bug fix can resolve unilaterally.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Devin Review: apply_threat_feed_import's operator-ownership skip (8b7954d) omits operator-owned threats from the upsert loop, but ThreatFeedImportResult.upserted_threats still reported feed.threats.len() -- the full submitted set, including entries that were skipped. Import clients (including KEV's response) received an inflated success count whenever a feed overlapped operator-managed data. Count actual upserts in the loop and return that. ThreatFeedStatus.threat_count is left as feed.threats.len() deliberately -- it represents catalog membership (what this feed's snapshot claims), not applied mutations, per Devin's suggested distinction. Added import_result_excludes_operator_owned_threats_from_upserted_count.
|
Verified on the current PR head |
Bypass-merge rationale (per explicit user authorization)Merging this via admin bypass rather than waiting on the standard review gate. Status at head
Bypassing the "1 independent approving review" branch-protection gate specifically because no human reviewer has approved and the org's AI reviewers (Devin/CodeRabbit) cannot satisfy that gate — this is done under explicit user authorization to bypass-merge, not a self-approval. Generated by Claude Code |
4 participants
Why
"KEV" (Known Exploited Vulnerabilities — CISA's authoritative federal catalog of confirmed, actively-exploited CVEs, https://www.cisa.gov/known-exploited-vulnerabilities-catalog) was the actual ask behind this PR's original working title; wardnet's Threat Intelligence surface (AGENTS.md/CLAUDE.md: "integrate proven security engines instead of inventing detections") already adapts STIX/MISP/TAXII/OpenCTI but had no KEV adapter. CISA KEV tracking is also a concrete, checkable line item in enterprise buyer due-diligence and federal-agency vendor questionnaires (BOD 26-04), so this closes a real gap in
docs/security/compliance-mapping.md's Threat Intelligence row.What
src/kev_import.rs(new): pure parser mirroringmisp_import.rs/opencti_import.rs/stix_import.rsexactly —parse_kev_document(body, source, ttl_seconds) -> Result<KevImportMaterial, String>. Accepts the real CISA catalog shape ({"vulnerabilities": [...]}, schema verified live against the current feed) or a bare array. Maps each entry to aThreatIndicator { indicator_type: "cve", value: <CVE ID, canonicalized upper-case>, ... }. Severity:Criticalwhen CISA'sknownRansomwareCampaignUse == "Known",Highotherwise (catalog inclusion alone already means CISA-confirmed active exploitation). No IP/domain/URL/hash observables exist in KEV data, sodnsblstays empty (kept only forThreatFeedImportshape parity).src/lib.rs:POST /api/threat-intel/cisa-kev(admin-token gated). Unlike the MISP/STIX/OpenCTI "operator pastes a document" pattern, this follows the phishing-database fetch-by-URL pattern — KEV has one canonical, stable, public URL, so the gateway fetches it directly (defaults to the real CISA URL; SSRF-safe via the existingfetch_text_feed/validate_http_urlmachinery, restricted towww.cisa.govunlessallow_non_default_hostsis set).validate_http_urlgained a thirdallowed_hosts: &[&str]parameter (was hardcoded to the phishing-database allowlist) so KEV gets its own host allowlist; all other call sites (TAXII poll, phishing-database,fetch_text_feed's internal check) updated accordingly. Reusesapply_threat_feed_importuntouched, so upserts, audit logging, and feed-freshness tracking (KPIs,/api/commercial/readiness, support bundle, admin console) all pick it up for free, exactly like the other four adapters.crates/waf-ids-core: newbuyer_evidence_endpoints()entry for/api/threat-intel/cisa-kev. Also:score_requestnow excludesindicator_type == "cve"from content-substring matching (see Devin Review fix below).docs/architecture.md,docs/security/compliance-mapping.md: documented alongside the other threat-intel adapters, plus a "Further reading" research-grounding section (see below).Fixes from Devin Review
score_request's generic substring matcher at High/Critical severity — a legitimate request merely referencing a cataloged CVE ID (e.g. a vulnerability-management dashboard proxied through the gateway) could trip a default block-mode route. Fixed by excludingindicator_type == "cve"from content matching (mirrors the existingip-type special case); the indicator stays fully visible via/api/threats, freshness, and buyer evidence. Added a core-crate unit test and an HTTP-level integration test (block-mode route + a request literally containing the CVE ID, asserting it's not blocked) — verified both fail without the fix and pass with it.docs/architecture.mdciting CISA's BOD 22-01, Jacobs et al. (2021)'s EPSS paper, and Shimizu & Hashimoto (2025, arXiv:2506.01220, CC BY 4.0, PDF committed underdocs/papers/).apply_threat_feed_importis upsert-only). This is shared behavior across all five existing feed adapters (STIX/MISP/TAXII/OpenCTI/phishing-database), not something this PR introduces — proposed a follow-up direction in the PR thread rather than folding a cross-adapter reconciliation feature into this PR.mainbefore PR fix(deploy): disable service account token automount (KSV-0036) #132's SIGTERM-handler race fix merged, sotests/binary.rs's graceful-shutdown test was flaky here too. Ported the identical fix so it doesn't block this PR's CI; it will no-op oncemaincarries it.Deliberately out of scope
suricata_eve.rs,coraza_audit.rs,builtin_signatures(): no CVE/CWE identifier exists anywhere else in the codebase, so there's no existing hook to enrich — inventing one would mean hand-rolling new detection logic, which is exactly what this project's architecture avoids.parse_never_panics_on_arbitrary_textunit test.Verification
cargo fmt --check→ clean.cargo test --locked --workspace→ all pass except the pre-existing root-sandbox-onlyload_surfaces_state_rewrite_failuresflake (tracked by open PR test(persistence): replace permission-based fault injection with a deterministic seam #93, reproduces identically onmain).cargo clippy --locked --workspace --all-targets -- -D warnings→ clean.🤖 Generated with Claude Code
Summary by CodeRabbit
새 기능
버그 수정
문서