Skip to content

Add importer and redaction test coverage#5

Merged
x0ba merged 2 commits into
mainfrom
tests/import-redaction-coverage
Jun 8, 2026
Merged

Add importer and redaction test coverage#5
x0ba merged 2 commits into
mainfrom
tests/import-redaction-coverage

Conversation

@x0ba

@x0ba x0ba commented Jun 8, 2026

Copy link
Copy Markdown
Owner

Stack Context

This PR adds automated test coverage for the Peek MVP features that are already implemented from plans/product-plan.md.

What?

  • Adds redaction unit tests for API keys, tokens, emails, paths, URL secrets, env assignments, and private key blocks.
  • Adds importer and normalization tests for generic transcript/JSON/JSONL parsing.
  • Adds first-pass native importer coverage for Claude Code, Cursor, Codex, and Pi traces.

Why?

The product plan calls for unit tests around redaction, import parsing, normalization, and data-completeness behavior. These tests lock in the currently implemented client-side logic before adding more import/storage/analysis features.

Validation

  • vp test passes: 9 tests
  • vp check passes with 0 errors and 1 existing warning in src/lib/components/ui/liquid-metal-button/liquid-metal-button.svelte

@vercel

vercel Bot commented Jun 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
peek Ready Ready Preview, Comment Jun 8, 2026 6:09pm

@greptile-apps

greptile-apps Bot commented Jun 8, 2026

Copy link
Copy Markdown

Greptile Summary

This PR adds unit test coverage for the redaction and importer modules that were already implemented, and wires vp test into both the GitHub Actions and Depot CI workflows so tests are enforced on every push and PR.

  • Redaction tests (redact.test.ts): covers API keys, tokens, emails, absolute paths, URL query-param secrets, and private key blocks; all assertions align with the sequential-rule implementation in redact.ts.
  • Importer tests (parse.test.ts): covers generic transcript/JSON/JSONL parsing, normalizeCandidate stats and data-completeness metadata, and first-pass native parsers for Claude Code, Cursor, Codex, and Pi; role normalization, tool-event inference, and source-metadata propagation are all verified against the live implementations.
  • CI changes (.github/workflows/ci.yml, .depot/workflows/ci.yml): vp test is inserted before vp check and vp build, which is the correct gate order.

Confidence Score: 4/5

Safe to merge; the only findings are test-file hygiene issues that do not affect runtime behavior.

All four changed files are tests and CI configuration with no changes to production code. The test assertions are correctly aligned with the implementations they cover. Two minor concerns: synthetic credential strings in the redact tests closely match real secret formats and may trigger push-protection scanners on future branches, and the double-counting of a single env-assignment secret across the api-key and env-secret categories is not asserted, leaving that behavior untested.

src/lib/redaction/redact.test.ts — synthetic credential patterns and uncovered double-count behavior.

Important Files Changed

Filename Overview
src/lib/redaction/redact.test.ts New test file covering redaction of API keys, tokens, emails, paths, URL secrets, and private key blocks; synthetic credentials in the test file closely match real secret formats and could trigger GitHub secret scanning
src/lib/importers/parse.test.ts New test file with generic-parsing and native-importer (Claude Code, Cursor, Codex, Pi) coverage; assertions are well-aligned with the implementation but hasCommandOutputs: false assertion relies on implicit vitest→"test" kind classification that could silently regress
.github/workflows/ci.yml Adds vp test step before vp check in the GitHub Actions job; correct ordering, no issues
.depot/workflows/ci.yml Mirrors the GitHub Actions change for Depot CI; same correct ordering of test before check/build

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CI: vp test] --> B{Tests pass?}
    B -- No --> FAIL[Workflow fails]
    B -- Yes --> C[vp check]
    C --> D[vp run build]

    subgraph redact.test.ts
        R1[redacts API keys / tokens / emails / paths / URL secrets]
        R2[redacts private key blocks]
    end

    subgraph parse.test.ts
        P1[generic transcript parsing]
        P2[generic JSON / JSONL parsing]
        P3[normalizeCandidate stats + data-completeness]
        P4[Claude Code JSONL native parser]
        P5[Cursor markdown + fallback parser]
        P6[Codex rollout JSONL parser]
        P7[Pi session JSONL parser]
    end

    A -.runs.-> redact.test.ts
    A -.runs.-> parse.test.ts
Loading

Fix All in Cursor Fix All in Codex

Reviews (1): Last reviewed commit: "add gh actions for tests" | Re-trigger Greptile

Comment on lines +10 to +17
const input = [
"OPENAI_API_KEY=sk-proj_abcdefghijklmnopqrstuvwxyz123456",
"Authorization: Bearer abcdefghijklmnopqrstuvwxyz1234567890",
"GitHub token ghp_abcdefghijklmnopqrstuvwxyz123456",
"Email daniel@example.com",
"Path /Users/daniel/Code/private/.env",
"URL https://example.com/callback?token=super-secret-value&next=/app",
].join("\n");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Synthetic credentials match real token formats

The strings sk-proj_abcdefghijklmnopqrstuvwxyz123456, ghp_abcdefghijklmnopqrstuvwxyz123456, and the Bearer token value all satisfy the exact length and prefix constraints that GitHub secret scanning and similar tools use to detect live credentials. GitHub's push-protection scanner checks for the ghp_ pattern specifically; future pushes or forks may be blocked or flagged even though the values are clearly synthetic. Consider using obviously-invalid prefixes such as sk-test- or ghp-FAKE- that token scanners are trained to ignore.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Cursor Fix in Codex

Comment on lines +29 to +34
expect(countFor(result, "env-secret")).toBe(1);
expect(countFor(result, "token")).toBeGreaterThanOrEqual(2);
expect(countFor(result, "email")).toBe(1);
expect(countFor(result, "absolute-path")).toBe(1);
expect(countFor(result, "url-secret")).toBe(1);
});

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Double-counting behavior between api-key and env-secret rules is untested

Because the redaction rules run sequentially, OPENAI_API_KEY=sk-proj_… first triggers the api-key rule (replacing the value with [REDACTED:API_KEY], count api-key=1), then the env-secret rule fires again on the already-redacted line (count env-secret=1). The final text is correct ([REDACTED:ENV_SECRET]), but categories will contain both { category: "api-key", count: 1 } and { category: "env-secret", count: 1 } for what was a single secret, potentially inflating the reported redaction count shown to users. No assertion covers countFor(result, "api-key"), so a future fix that eliminates the double-count would not be caught by this test.

Fix in Cursor Fix in Codex

@x0ba
x0ba merged commit 406e1f4 into main Jun 8, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant