@bli-cockpit/telemetry-core 0.1.41 → 0.1.42

package/dist/secret-guards-content-rules.d.ts

@@ -0,0 +1,60 @@
+/**
+ * Which CONTENT looks like a secret — the detector, in the order it decides.
+ *
+ * Owned by `secret-guards.ts` (BLI-3986). Two kinds of rule live here and the
+ * difference between them is the whole D13 precision argument: a credential
+ * NAME is a leak only when it carries an assignment and an opaque value, while
+ * a self-identifying VALUE (a PEM block, a JWT, `ghp_…`, `AKIA…`) is a leak
+ * wherever it appears. `SECRET_LIKE_CONTENT_PATTERNS` is that order — the
+ * name-with-value rule first, then the value shapes as listed — and
+ * `secret-guards-masking.ts` reads the same list, so a rule added here without
+ * a masking rule beside it still redacts (coarsely) rather than costing a
+ * session.
+ *
+ * `SECRET_NAME_MATCH_SOURCE` and `SECRET_ASSIGNMENT_SOURCE` are exported for
+ * that sibling alone and are deliberately NOT re-exported by
+ * `secret-guards.ts`: the masking rule has to be built from the same fence as
+ * the detector, and a second spelling of it is the BLI-3116 hole again.
+ */
+/**
+ * Credential names live INSIDE longer identifiers, so `\b` is the wrong fence
+ * (BLI-3116).
+ *
+ * Every name fragment above used to be wrapped in `\b(?:…)\b`. Underscore is a
+ * word character, so there is no word boundary between `AWS_` and `SECRET`:
+ * `AWS_SECRET_ACCESS_KEY=AKIA…` — the most common real spelling of the most
+ * common real leak — never matched and uploaded unmasked from every fleet
+ * machine, while the bare `SECRET_ACCESS_KEY=…` matched fine. The same hole hid
+ * `AZURE_OPENAI_API_KEY`, `VITE_SUPABASE_ANON_KEY`, `GITHUB_ACCESS_TOKEN`,
+ * `MY_APP_CLIENT_SECRET` and every other prefixed spelling: the bug was the
+ * fence, not the vocabulary, so the whole list is fenced differently now.
+ *
+ * `_`, `-` and `.` are identifier JOINERS here, not boundaries:
+ *
+ * - leading `(?<![A-Za-z0-9])` — the fragment may begin right after a joiner or
+ *   at a real boundary, but a letter or digit immediately before it still
+ *   blocks the match (`notapikey=…` stays out, as before).
+ * - trailing `[A-Za-z0-9_-]{0,40}` — a bounded identifier tail, so
+ *   `OPENAI_API_KEY_2=…` and `AWS_SECRET_ACCESS_KEY_ID=…` are seen too.
+ *
+ * Prose is unaffected because the assignment requirement below is unchanged:
+ * "rotate your secret access key" has no `=`/`:` + opaque value and is not a
+ * leak. The guard's job is assignments, not vocabulary.
+ */
+export declare const SECRET_NAME_MATCH_SOURCE: string;
+/**
+ * The assignment operator, with the closing quote of a JSON/YAML key allowed
+ * before it. Found while auditing the fence above: `{"aws_secret_access_key":
+ * "…"}` never matched either, because the name was followed by `"` and the
+ * pattern demanded `[:=]` immediately. Transcripts are JSONL, so this is the
+ * shape a leaked credential most often has on the way in. The sibling redactor
+ * in harvest-analysis (`study/prepare.ts`) already allowed it; this one did not.
+ */
+export declare const SECRET_ASSIGNMENT_SOURCE = "[\"']?\\s*[:=]\\s*[\"']?";
+export declare const SECRET_LIKE_CONTENT_PATTERNS: RegExp[];
+/**
+ * Does this text carry something the fleet must not upload as it stands? The
+ * one question the collector and the ingest door both ask, so a laptop and the
+ * server can never disagree about which bytes were secret-shaped.
+ */
+export declare function containsSecretLikeContent(value: string): boolean;

package/dist/secret-guards-content-rules.js

@@ -0,0 +1,122 @@
+/**
+ * Which CONTENT looks like a secret — the detector, in the order it decides.
+ *
+ * Owned by `secret-guards.ts` (BLI-3986). Two kinds of rule live here and the
+ * difference between them is the whole D13 precision argument: a credential
+ * NAME is a leak only when it carries an assignment and an opaque value, while
+ * a self-identifying VALUE (a PEM block, a JWT, `ghp_…`, `AKIA…`) is a leak
+ * wherever it appears. `SECRET_LIKE_CONTENT_PATTERNS` is that order — the
+ * name-with-value rule first, then the value shapes as listed — and
+ * `secret-guards-masking.ts` reads the same list, so a rule added here without
+ * a masking rule beside it still redacts (coarsely) rather than costing a
+ * session.
+ *
+ * `SECRET_NAME_MATCH_SOURCE` and `SECRET_ASSIGNMENT_SOURCE` are exported for
+ * that sibling alone and are deliberately NOT re-exported by
+ * `secret-guards.ts`: the masking rule has to be built from the same fence as
+ * the detector, and a second spelling of it is the BLI-3116 hole again.
+ */
+// Constructed from parts so the literal privileged key name never appears in
+// this source file (the public-package pack scanner bans it as a content
+// pattern, just as the original guard did).
+const PRIVILEGED_SUPABASE_KEY_NAME = ["SUPABASE", "SERVICE", "ROLE", "KEY"].join("_");
+const SUPABASE_SERVICE_ROLE_NAME = ["SUPABASE", "SERVICE", "ROLE"].join("_");
+const OPENAI_KEY_NAME = ["OPENAI", "API", "KEY"].join("_");
+const MEM0_KEY_NAME = ["MEM0", "API", "KEY"].join("_");
+const SECRET_NAME_PATTERN_SOURCE = [
+    "(?:NEXT_PUBLIC_)?SUPABASE_ANON_KEY",
+    PRIVILEGED_SUPABASE_KEY_NAME,
+    SUPABASE_SERVICE_ROLE_NAME,
+    OPENAI_KEY_NAME,
+    MEM0_KEY_NAME,
+    "SERVICE[_\\s-]?ROLE(?:[_\\s-]?KEY)?",
+    "LANGFUSE_(?:PUBLIC|SECRET)_KEY",
+    "api[_-]?key",
+    "access[_-]?token",
+    "refresh[_-]?token",
+    "private[_-]?key",
+    "client[_-]?secret",
+    "secret[_-]?access[_-]?key",
+].join("|");
+/**
+ * Credential names live INSIDE longer identifiers, so `\b` is the wrong fence
+ * (BLI-3116).
+ *
+ * Every name fragment above used to be wrapped in `\b(?:…)\b`. Underscore is a
+ * word character, so there is no word boundary between `AWS_` and `SECRET`:
+ * `AWS_SECRET_ACCESS_KEY=AKIA…` — the most common real spelling of the most
+ * common real leak — never matched and uploaded unmasked from every fleet
+ * machine, while the bare `SECRET_ACCESS_KEY=…` matched fine. The same hole hid
+ * `AZURE_OPENAI_API_KEY`, `VITE_SUPABASE_ANON_KEY`, `GITHUB_ACCESS_TOKEN`,
+ * `MY_APP_CLIENT_SECRET` and every other prefixed spelling: the bug was the
+ * fence, not the vocabulary, so the whole list is fenced differently now.
+ *
+ * `_`, `-` and `.` are identifier JOINERS here, not boundaries:
+ *
+ * - leading `(?<![A-Za-z0-9])` — the fragment may begin right after a joiner or
+ *   at a real boundary, but a letter or digit immediately before it still
+ *   blocks the match (`notapikey=…` stays out, as before).
+ * - trailing `[A-Za-z0-9_-]{0,40}` — a bounded identifier tail, so
+ *   `OPENAI_API_KEY_2=…` and `AWS_SECRET_ACCESS_KEY_ID=…` are seen too.
+ *
+ * Prose is unaffected because the assignment requirement below is unchanged:
+ * "rotate your secret access key" has no `=`/`:` + opaque value and is not a
+ * leak. The guard's job is assignments, not vocabulary.
+ */
+export const SECRET_NAME_MATCH_SOURCE = `(?<![A-Za-z0-9])(?:${SECRET_NAME_PATTERN_SOURCE})[A-Za-z0-9_-]{0,40}`;
+/**
+ * The assignment operator, with the closing quote of a JSON/YAML key allowed
+ * before it. Found while auditing the fence above: `{"aws_secret_access_key":
+ * "…"}` never matched either, because the name was followed by `"` and the
+ * pattern demanded `[:=]` immediately. Transcripts are JSONL, so this is the
+ * shape a leaked credential most often has on the way in. The sibling redactor
+ * in harvest-analysis (`study/prepare.ts`) already allowed it; this one did not.
+ */
+export const SECRET_ASSIGNMENT_SOURCE = `["']?\\s*[:=]\\s*["']?`;
+/**
+ * Credential names that are only a leak when assigned a value (D13). The value
+ * shape mirrors the long-standing generic pattern: an assignment operator
+ * followed by a 12+ char opaque value. A bare env var reference (name only) and
+ * `GRANT ... TO service_role` (no assignment) do not match; the same name with
+ * an assigned value does.
+ */
+const SECRET_NAME_WITH_VALUE_PATTERN = new RegExp(`${SECRET_NAME_MATCH_SOURCE}${SECRET_ASSIGNMENT_SOURCE}[A-Za-z0-9_./+=-]{12,}`, "i");
+/**
+ * Self-identifying secret values — blocked regardless of context because the
+ * token shape itself is the credential, with no benign reading.
+ *
+ * `\b` is deliberately KEPT here, unlike the name fragments above (BLI-3116).
+ * These patterns are whole tokens, not fragments of a longer identifier: a
+ * `ghp_`/`sk-`/`AKIA…` run that continues into surrounding alphanumerics is not
+ * that provider's token, and unanchoring them would mask ordinary identifiers
+ * (`chart_m0_2024_revenue…`) for no safety gain. A real leak of any of these
+ * shapes is preceded by a quote, whitespace, `=`, `:` or `/` — all of which
+ * `\b` already admits.
+ */
+const SECRET_VALUE_PATTERNS = [
+    /-----BEGIN [A-Z ]*PRIVATE KEY-----/,
+    /\bBearer\s+[A-Za-z0-9._~+/=-]{16,}/,
+    /\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b/,
+    /\b(?:sk|pk)_(?:live|test)_[A-Za-z0-9]{16,}/,
+    /\bsk-[A-Za-z0-9_-]{16,}/,
+    /\bgh[pousr]_[A-Za-z0-9_]{16,}/,
+    /\bgithub_pat_[A-Za-z0-9_]{20,}/,
+    /\blin_api_[A-Za-z0-9]{16,}/,
+    /\bsb_secret_[A-Za-z0-9_]{16,}/,
+    /\bxox[baprs]-[A-Za-z0-9-]{16,}/,
+    /\b(?:AKIA|ASIA)[A-Z0-9]{16}\b/,
+    /\b(?:pk|sk)-lf-[A-Za-z0-9_-]{16,}\b/i,
+    /\bm0[-_][A-Za-z0-9_-]{16,}\b/i,
+];
+export const SECRET_LIKE_CONTENT_PATTERNS = [
+    SECRET_NAME_WITH_VALUE_PATTERN,
+    ...SECRET_VALUE_PATTERNS,
+];
+/**
+ * Does this text carry something the fleet must not upload as it stands? The
+ * one question the collector and the ingest door both ask, so a laptop and the
+ * server can never disagree about which bytes were secret-shaped.
+ */
+export function containsSecretLikeContent(value) {
+    return SECRET_LIKE_CONTENT_PATTERNS.some((pattern) => pattern.test(value));
+}

package/dist/secret-guards-masking.d.ts

@@ -0,0 +1,32 @@
+import type { RawEvidenceRedactionMetadata, RawEvidenceRedactionSource } from "./secret-guards-metadata.js";
+/**
+ * How a match is MASKED, and which rule gets to name it.
+ *
+ * Owned by `secret-guards.ts` (BLI-3986). `SECRET_REDACTION_RULES` is a table
+ * and its INDEX is a priority: the earliest rule that reaches a span wins, so
+ * the reason label a dashboard reads (`[REDACTED:openai_token]`,
+ * `rule_counts[].rule_id`) is decided by position in that list and by nothing
+ * else. Reordering it, or inserting a rule in the middle, relabels live
+ * redactions — `secret-guards-lock.test.ts` records the answers so that cannot
+ * happen by accident.
+ *
+ * Below the whole table sits the fallback (`unnamed_secret_shape`), ranked
+ * after every real rule: masking is best-effort and NEVER drops a file, so a
+ * detector hit no rule can pinpoint is masked coarsely rather than costing the
+ * session (the BLI-3116 note on the first rule explains what that cost was).
+ */
+export interface SecretRedactionResult {
+    redacted: boolean;
+    text: string;
+    metadata: RawEvidenceRedactionMetadata | null;
+}
+/**
+ * Mask every secret-shaped span and keep the rest of the text, because a
+ * session is never dropped for carrying one: this returns the redacted bytes
+ * plus the receipt that says which rules fired, where, and how much was
+ * replaced.
+ */
+export declare function redactSecretLikeContent(value: string, options?: {
+    appliedBy?: RawEvidenceRedactionSource;
+    redactedFields?: string[];
+}): SecretRedactionResult;

package/dist/secret-guards-masking.js

@@ -0,0 +1,206 @@
+import { SECRET_ASSIGNMENT_SOURCE, SECRET_LIKE_CONTENT_PATTERNS, SECRET_NAME_MATCH_SOURCE, } from "./secret-guards-content-rules.js";
+import { RawEvidenceRedactionMetadataSchema } from "./secret-guards-metadata.js";
+// Same fence as the detector (BLI-3116) — the two must agree or a prefixed
+// name would be detected and then left unredacted, which costs whole sessions
+// (see findSecretRedactionMatches).
+const SECRET_ASSIGNMENT_REDACTION_PATTERN = new RegExp(`(${SECRET_NAME_MATCH_SOURCE}${SECRET_ASSIGNMENT_SOURCE})([A-Za-z0-9_./+=-]{12,})`, "gi");
+const SECRET_REDACTION_RULES = [
+    {
+        ruleId: "credential_assignment",
+        pattern: SECRET_ASSIGNMENT_REDACTION_PATTERN,
+        secretGroup: 2,
+    },
+    {
+        ruleId: "private_key_block",
+        pattern: /-----BEGIN [A-Z ]*PRIVATE KEY-----[\s\S]*?-----END [A-Z ]*PRIVATE KEY-----/g,
+    },
+    {
+        ruleId: "private_key_header",
+        pattern: /-----BEGIN [A-Z ]*PRIVATE KEY-----/g,
+    },
+    {
+        ruleId: "bearer_token",
+        pattern: /\b(Bearer\s+)([A-Za-z0-9._~+/=-]{16,})/gi,
+        secretGroup: 2,
+    },
+    {
+        ruleId: "jwt",
+        pattern: /\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b/g,
+    },
+    {
+        ruleId: "stripe_token",
+        pattern: /\b(?:sk|pk)_(?:live|test)_[A-Za-z0-9]{16,}/g,
+    },
+    {
+        ruleId: "openai_token",
+        pattern: /\bsk-[A-Za-z0-9_-]{16,}/g,
+    },
+    {
+        ruleId: "github_token",
+        pattern: /\b(?:gh[pousr]_[A-Za-z0-9_]{16,}|github_pat_[A-Za-z0-9_]{20,})/g,
+    },
+    {
+        ruleId: "linear_token",
+        pattern: /\blin_api_[A-Za-z0-9]{16,}/g,
+    },
+    {
+        ruleId: "supabase_secret_token",
+        pattern: /\bsb_secret_[A-Za-z0-9_]{16,}/g,
+    },
+    {
+        ruleId: "slack_token",
+        pattern: /\bxox[baprs]-[A-Za-z0-9-]{16,}/g,
+    },
+    {
+        ruleId: "aws_access_key_id",
+        pattern: /\b(?:AKIA|ASIA)[A-Z0-9]{16}\b/g,
+    },
+    {
+        ruleId: "langfuse_token",
+        pattern: /\b(?:pk|sk)-lf-[A-Za-z0-9_-]{16,}\b/gi,
+    },
+    {
+        ruleId: "mem0_token",
+        pattern: /\bm0[-_][A-Za-z0-9_-]{16,}\b/gi,
+    },
+];
+/**
+ * Mask every secret-shaped span and keep the rest of the text, because a
+ * session is never dropped for carrying one: this returns the redacted bytes
+ * plus the receipt that says which rules fired, where, and how much was
+ * replaced.
+ */
+export function redactSecretLikeContent(value, options = {}) {
+    const matches = findSecretRedactionMatches(value);
+    if (matches.length === 0) {
+        return { redacted: false, text: value, metadata: null };
+    }
+    let text = "";
+    let cursor = 0;
+    const ruleCounts = new Map();
+    for (const match of matches) {
+        text += value.slice(cursor, match.start);
+        text += `[REDACTED:${match.ruleId}]`;
+        cursor = match.end;
+        const existing = ruleCounts.get(match.ruleId) ?? {
+            rule_id: match.ruleId,
+            match_count: 0,
+            redacted_char_count: 0,
+        };
+        existing.match_count += 1;
+        existing.redacted_char_count += match.end - match.start;
+        ruleCounts.set(match.ruleId, existing);
+    }
+    text += value.slice(cursor);
+    const metadata = RawEvidenceRedactionMetadataSchema.parse({
+        schema_version: "raw-evidence-redaction.v1",
+        status: "sanitized",
+        mode: "deterministic_text_replacement",
+        applied_by: [options.appliedBy ?? "local_collector"],
+        rule_counts: [...ruleCounts.values()].sort((a, b) => a.rule_id.localeCompare(b.rule_id)),
+        secret_like_match_count: matches.length,
+        redacted_fields: options.redactedFields ?? [],
+        redacted_ranges: matches.slice(0, 200).map((match) => ({
+            start: match.start,
+            end: match.end,
+            rule_id: match.ruleId,
+        })),
+    });
+    return { redacted: true, text, metadata };
+}
+/**
+ * Every region the detector considers a secret, redacted — precisely where a
+ * rule can pinpoint the value, coarsely where none can.
+ *
+ * `containsSecretLikeContent` and `SECRET_REDACTION_RULES` are two lists that
+ * have to agree, and nothing used to make them. When the detector matched and
+ * no rule produced a range, `redactSecretLikeContent` reported
+ * `redacted: false`, and the caller dropped the entire session file
+ * (`secret_like_content_guard`). Drift between the lists cost whole sessions:
+ * 78 fleet-wide as of 2026-08-14, 3 of Viet's 17 Claude sessions.
+ *
+ * The two lists can still drift — regexes are like that — but drift now costs
+ * precision instead of evidence. A detector hit with no matching rule redacts
+ * the whole matched span, so `redactSecretLikeContent` always reports the
+ * redaction it performed and the transcript survives with the value removed.
+ */
+function findSecretRedactionMatches(value) {
+    const accepted = acceptNonOverlapping(secretRuleCandidates(value));
+    const uncovered = detectorFallbackCandidates(value).filter((candidate) => !overlapsAny(candidate, accepted));
+    if (uncovered.length === 0)
+        return accepted;
+    return acceptNonOverlapping([...accepted, ...uncovered]);
+}
+function secretRuleCandidates(value) {
+    const candidates = [];
+    SECRET_REDACTION_RULES.forEach((rule, priority) => {
+        const pattern = cloneGlobalPattern(rule.pattern);
+        for (const match of value.matchAll(pattern)) {
+            const fullMatch = match[0];
+            const matchIndex = match.index;
+            if (!fullMatch || matchIndex === undefined)
+                continue;
+            const secret = rule.secretGroup ? match[rule.secretGroup] : fullMatch;
+            if (!secret)
+                continue;
+            const relativeStart = fullMatch.indexOf(secret);
+            if (relativeStart < 0)
+                continue;
+            candidates.push({
+                start: matchIndex + relativeStart,
+                end: matchIndex + relativeStart + secret.length,
+                ruleId: rule.ruleId,
+                priority,
+            });
+        }
+    });
+    return candidates;
+}
+/**
+ * Ranked below every real rule, so a rule that can name the credential always
+ * wins and the coarse span is only used where nothing else reached.
+ */
+function detectorFallbackCandidates(value) {
+    const candidates = [];
+    const basePriority = SECRET_REDACTION_RULES.length;
+    SECRET_LIKE_CONTENT_PATTERNS.forEach((pattern, offset) => {
+        for (const match of value.matchAll(cloneGlobalPattern(pattern))) {
+            const fullMatch = match[0];
+            const matchIndex = match.index;
+            if (!fullMatch || matchIndex === undefined)
+                continue;
+            candidates.push({
+                start: matchIndex,
+                end: matchIndex + fullMatch.length,
+                ruleId: "unnamed_secret_shape",
+                priority: basePriority + offset,
+            });
+        }
+    });
+    return candidates;
+}
+function overlapsAny(candidate, accepted) {
+    return accepted.some((other) => candidate.start < other.end && other.start < candidate.end);
+}
+function acceptNonOverlapping(candidates) {
+    const ordered = [...candidates].sort((a, b) => {
+        if (a.start !== b.start)
+            return a.start - b.start;
+        if (a.priority !== b.priority)
+            return a.priority - b.priority;
+        return b.end - b.start - (a.end - a.start);
+    });
+    const accepted = [];
+    let lastEnd = -1;
+    for (const candidate of ordered) {
+        if (candidate.start < lastEnd)
+            continue;
+        accepted.push(candidate);
+        lastEnd = candidate.end;
+    }
+    return accepted;
+}
+function cloneGlobalPattern(pattern) {
+    const flags = pattern.flags.includes("g") ? pattern.flags : `${pattern.flags}g`;
+    return new RegExp(pattern.source, flags);
+}

package/dist/secret-guards-metadata.d.ts

@@ -0,0 +1,102 @@
+import { z } from "zod";
+/**
+ * What a secret scan RECORDS: the redaction receipt every uploaded object
+ * carries, and the one builder of the clean half of it.
+ *
+ * Owned by `secret-guards.ts` (BLI-3986); the rules that produce these records
+ * live in `secret-guards-content-rules.ts` and `secret-guards-masking.ts`.
+ * Nothing here decides what a secret IS — it decides what a reader downstream
+ * is told about a scan that already ran, which is why the per-status
+ * invariants below are the load-bearing part: a record that claims a
+ * sanitization that never happened is worse than a missing record.
+ */
+export declare const RawEvidenceRedactionSourceSchema: z.ZodEnum<{
+    local_collector: "local_collector";
+    server_commit: "server_commit";
+    legacy_upload: "legacy_upload";
+}>;
+export type RawEvidenceRedactionSource = z.infer<typeof RawEvidenceRedactionSourceSchema>;
+export declare const RawEvidenceRedactionRuleCountSchema: z.ZodObject<{
+    rule_id: z.ZodString;
+    match_count: z.ZodNumber;
+    redacted_char_count: z.ZodNumber;
+}, z.core.$strict>;
+export type RawEvidenceRedactionRuleCount = z.infer<typeof RawEvidenceRedactionRuleCountSchema>;
+export declare const RawEvidenceRedactionRangeSchema: z.ZodObject<{
+    start: z.ZodNumber;
+    end: z.ZodNumber;
+    rule_id: z.ZodString;
+}, z.core.$strict>;
+export type RawEvidenceRedactionRange = z.infer<typeof RawEvidenceRedactionRangeSchema>;
+/**
+ * The verdict of a secret scan — NOT "did the bytes change" (BLI-3277).
+ *
+ * `sanitized` means the scan matched and the uploaded bytes differ from what was
+ * read. `scanned_clean` means the same scan ran over the same bytes and matched
+ * nothing, so the uploaded bytes are the original ones. The second value exists
+ * because every reader downstream asks "was this scanned?", and for 70% of
+ * transcripts — the ones with no secret in them — the honest answer used to be
+ * an absent record, which reads identically to "nobody ever looked".
+ */
+export declare const RawEvidenceRedactionStatusSchema: z.ZodEnum<{
+    sanitized: "sanitized";
+    scanned_clean: "scanned_clean";
+}>;
+export type RawEvidenceRedactionStatus = z.infer<typeof RawEvidenceRedactionStatusSchema>;
+export declare const RawEvidenceRedactionMetadataSchema: z.ZodObject<{
+    schema_version: z.ZodLiteral<"raw-evidence-redaction.v1">;
+    status: z.ZodEnum<{
+        sanitized: "sanitized";
+        scanned_clean: "scanned_clean";
+    }>;
+    mode: z.ZodLiteral<"deterministic_text_replacement">;
+    applied_by: z.ZodArray<z.ZodEnum<{
+        local_collector: "local_collector";
+        server_commit: "server_commit";
+        legacy_upload: "legacy_upload";
+    }>>;
+    rule_counts: z.ZodArray<z.ZodObject<{
+        rule_id: z.ZodString;
+        match_count: z.ZodNumber;
+        redacted_char_count: z.ZodNumber;
+    }, z.core.$strict>>;
+    secret_like_match_count: z.ZodNumber;
+    redacted_fields: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    redacted_ranges: z.ZodDefault<z.ZodArray<z.ZodObject<{
+        start: z.ZodNumber;
+        end: z.ZodNumber;
+        rule_id: z.ZodString;
+    }, z.core.$strict>>>;
+    original_content_hash_sha256: z.ZodOptional<z.ZodString>;
+    sanitized_content_hash_sha256: z.ZodOptional<z.ZodString>;
+    original_byte_size: z.ZodOptional<z.ZodNumber>;
+    sanitized_byte_size: z.ZodOptional<z.ZodNumber>;
+    applied_at: z.ZodOptional<z.ZodString>;
+}, z.core.$strict>;
+export type RawEvidenceRedactionMetadata = z.infer<typeof RawEvidenceRedactionMetadataSchema>;
+/**
+ * The receipt for a file the scan cleared (BLI-3277, moved here by BLI-3280).
+ *
+ * Same schema, same `mode` — the deterministic ruleset is what ran — with the
+ * verdict `scanned_clean` and zero of everything else. The content fields are
+ * the point: an evidence ref is only readable downstream when its redaction
+ * record hashes the bytes that are actually in the bucket, and for a clean file
+ * those are the original bytes, so both halves carry the same digest and size.
+ *
+ * It lives in telemetry-core rather than in the collector because two callers
+ * now build this exact record and they must never drift: the collector writes
+ * it at upload time, and the BLI-3280 operator backfill writes it onto refs
+ * that were stored before the receipt existed. Both must satisfy the same
+ * `sanitized_content_hash_sha256 === content_hash_sha256` /
+ * `sanitized_byte_size === byte_size` equality the digest reader checks, and a
+ * second copy of this function is a second chance to get that wrong.
+ *
+ * `appliedBy` is who ran the scan, and it is not decoration: a backfill passes
+ * `legacy_upload` so a reader can tell "the collector scanned this before it
+ * uploaded" apart from "an operator scanned the stored bytes afterwards".
+ */
+export declare function scannedCleanRedactionMetadata(bytes: Uint8Array, options?: {
+    appliedBy?: RawEvidenceRedactionSource;
+    /** ISO-8601 with offset. Omitted entirely when absent (BLI-3290). */
+    appliedAt?: string;
+}): RawEvidenceRedactionMetadata;