@bli-cockpit/telemetry-core 0.1.41 → 0.1.43

package/dist/collector-heartbeat.d.ts

@@ -112,6 +112,10 @@ export declare const CollectorHeartbeatSchema: z.ZodObject<{
         hook_chars_p50: z.ZodOptional<z.ZodNumber>;
         hook_chars_p95: z.ZodOptional<z.ZodNumber>;
         hook_chars_samples: z.ZodOptional<z.ZodNumber>;
+        hook_stop_runs_24h: z.ZodOptional<z.ZodNumber>;
+        hook_stop_failed_24h: z.ZodOptional<z.ZodNumber>;
+        hook_session_start_runs_24h: z.ZodOptional<z.ZodNumber>;
+        hook_session_start_failed_24h: z.ZodOptional<z.ZodNumber>;
         hook_stats_reason: z.ZodOptional<z.ZodString>;
         hook_performance: z.ZodOptional<z.ZodObject<{
             schema_version: z.ZodLiteral<"memory-hook-performance.v1">;

package/dist/index.d.ts

@@ -14,6 +14,7 @@ export * from "./memory-hook-stats.js";
 export * from "./memory-extract-context.js";
 export * from "./memory-hook-performance.js";
 export * from "./memory-install-receipt.js";
+export * from "./outbound-guard.js";
 export * from "./paths.js";
 export * from "./privacy.js";
 export * from "./risk-flags.js";

package/dist/index.js

@@ -14,6 +14,7 @@ export * from "./memory-hook-stats.js";
 export * from "./memory-extract-context.js";
 export * from "./memory-hook-performance.js";
 export * from "./memory-install-receipt.js";
+export * from "./outbound-guard.js";
 export * from "./paths.js";
 export * from "./privacy.js";
 export * from "./risk-flags.js";

package/dist/memory-install-receipt.d.ts

@@ -120,6 +120,10 @@ export declare const MemoryInstallReceiptSchema: z.ZodObject<{
     hook_chars_p50: z.ZodOptional<z.ZodNumber>;
     hook_chars_p95: z.ZodOptional<z.ZodNumber>;
     hook_chars_samples: z.ZodOptional<z.ZodNumber>;
+    hook_stop_runs_24h: z.ZodOptional<z.ZodNumber>;
+    hook_stop_failed_24h: z.ZodOptional<z.ZodNumber>;
+    hook_session_start_runs_24h: z.ZodOptional<z.ZodNumber>;
+    hook_session_start_failed_24h: z.ZodOptional<z.ZodNumber>;
     hook_stats_reason: z.ZodOptional<z.ZodString>;
     hook_performance: z.ZodOptional<z.ZodObject<{
         schema_version: z.ZodLiteral<"memory-hook-performance.v1">;

package/dist/memory-install-receipt.js

@@ -180,6 +180,30 @@ export const MemoryInstallReceiptSchema = z
     hook_chars_p50: z.number().int().min(0).optional(),
     hook_chars_p95: z.number().int().min(0).optional(),
     hook_chars_samples: z.number().int().min(0).optional(),
+    /**
+     * THE OTHER TWO HOOKS (BLI-4057).
+     *
+     * Everything above counts the PROMPT hook only — the recall. Three hooks
+     * are installed on every machine and until this ticket the fleet heard
+     * from exactly one of them, so a SAVE hook that stopped firing (the one
+     * that writes memory at all) was invisible everywhere: the install
+     * receipt said `hooks ok`, the counts said 40 prompt recalls, and nothing
+     * anywhere said that not one memory had been written in ten days.
+     *
+     * `hook_stop_runs_24h` is the save hook; `hook_session_start_runs_24h` is
+     * the session-start recall. Each has its own failure count beside it,
+     * because a hook that runs and fails every time is a different fact from
+     * one that never ran — and the first is invisible in a run count alone.
+     *
+     * Optional like every count above, and ABSENT MEANS NOT REPORTED: a
+     * collector older than this ticket sends none, and a zero here would read
+     * as "the save hook ran zero times", which is exactly the alarm this
+     * ticket exists to raise. A reader may never substitute one for the other.
+     */
+    hook_stop_runs_24h: z.number().int().min(0).optional(),
+    hook_stop_failed_24h: z.number().int().min(0).optional(),
+    hook_session_start_runs_24h: z.number().int().min(0).optional(),
+    hook_session_start_failed_24h: z.number().int().min(0).optional(),
     /** Named when the counts are absent because the file could not be read. */
     hook_stats_reason: ReasonLabelSchema.optional(),
     /** Observed ordinary invocations, not legacy floors or a full host trace. */

package/dist/outbound-guard.d.ts

@@ -0,0 +1,77 @@
+/**
+ * The one seam every outbound write passes through (BLI-4086).
+ *
+ * The secret detector in this package was called at roughly fifty sites and
+ * every one of them was INGRESS — evidence upload, memory save, receipt
+ * parsing, notes intake, harvest extraction. Nothing ran on the way out. So
+ * the system could tell that a laptop had uploaded a credential and was blind
+ * when the assistant mailed one to somebody, and the assistant reaches every
+ * send path we own through MCP (`mail_send`, `msg_send`, `work_comment_issue`,
+ * `docs_update`, `notes_share`).
+ *
+ * **Why one function and not a guard per surface.** Five surfaces already
+ * disagreed about almost everything else — mail throws `MailDoorError`, msg
+ * throws `MsgDoorError`, Slack throws a bare `Error` — and a rule that has to
+ * be re-implemented five times is a rule that holds in four places within a
+ * quarter. The precedent is the mandatory-AI-SDK seam: make the single path
+ * the only path and let a census test fail when a sixth surface appears
+ * without it. `outbound-guard-census.test.ts` in the dashboard is that test.
+ *
+ * **It masks; it never refuses.** Consistent with the standing order that
+ * nothing is dropped — a refused send is a person's message deleted by a
+ * regex, and this detector's own header explains at length why coarse
+ * false positives are tolerable only because masking never costs the content.
+ * A masked send still sends, with `[REDACTED:<rule_id>]` where the value was.
+ *
+ * **It lives here, not in the dashboard**, because the worker's Linear mirror
+ * is an egress path too and cannot import from `apps/dashboard`. One choke
+ * point that stops at an app boundary is two choke points.
+ */
+/** The surfaces that can carry text out of Tower. Named so a log line can be grouped. */
+export declare const OUTBOUND_SURFACES: readonly ["mail", "msg", "slack", "work", "docs", "linear_mirror", "cal"];
+export type OutboundSurface = (typeof OUTBOUND_SURFACES)[number];
+/** What was masked, for the caller that wants to say so in its own log line. */
+export interface OutboundGuardReport {
+    /** True when at least one field changed. */
+    masked: boolean;
+    /** Field names that changed — names only, never values. */
+    maskedFields: string[];
+    /** Which rule caught what, and how much. The rule id IS the reason label. */
+    ruleCounts: {
+        rule_id: string;
+        match_count: number;
+        redacted_char_count: number;
+    }[];
+    /** Total matches across every field. */
+    matchCount: number;
+}
+export interface OutboundGuardResult<T> {
+    /** The same shape that came in, with secret-shaped spans replaced. */
+    fields: T;
+    report: OutboundGuardReport;
+}
+type GuardableFields = Record<string, string | null | undefined>;
+/**
+ * Masks every secret-shaped span in `fields` and logs once if anything changed.
+ *
+ * `null` and `undefined` pass through untouched, so a caller can hand over an
+ * optional field (`html`, a patch's absent `title`) without a branch at every
+ * call site — the branch is what gets forgotten.
+ *
+ * The log line carries the surface, the field NAMES, the rule ids and the
+ * counts. It deliberately carries no fragment of the matched text: a guard
+ * that prints what it caught has moved the secret from a message into a log,
+ * which is the failure this whole family exists to prevent
+ * (`~/.claude/rules/security.md`, "never log PII").
+ */
+export declare function guardOutboundFields<T extends GuardableFields>(surface: OutboundSurface, fields: T): OutboundGuardResult<T>;
+/**
+ * The single-field shorthand, for a writer that has exactly one body to guard.
+ *
+ * Prefer `guardOutboundFields` when a writer has two or more — it produces ONE
+ * log line for the send rather than one per field, and a reader counting
+ * masked sends should not have to know how many columns a surface happens to
+ * have.
+ */
+export declare function guardOutboundText(surface: OutboundSurface, field: string, text: string): string;
+export {};

package/dist/outbound-guard.js

@@ -0,0 +1,119 @@
+import { redactSecretLikeContent } from "./secret-guards-masking.js";
+/**
+ * The one seam every outbound write passes through (BLI-4086).
+ *
+ * The secret detector in this package was called at roughly fifty sites and
+ * every one of them was INGRESS — evidence upload, memory save, receipt
+ * parsing, notes intake, harvest extraction. Nothing ran on the way out. So
+ * the system could tell that a laptop had uploaded a credential and was blind
+ * when the assistant mailed one to somebody, and the assistant reaches every
+ * send path we own through MCP (`mail_send`, `msg_send`, `work_comment_issue`,
+ * `docs_update`, `notes_share`).
+ *
+ * **Why one function and not a guard per surface.** Five surfaces already
+ * disagreed about almost everything else — mail throws `MailDoorError`, msg
+ * throws `MsgDoorError`, Slack throws a bare `Error` — and a rule that has to
+ * be re-implemented five times is a rule that holds in four places within a
+ * quarter. The precedent is the mandatory-AI-SDK seam: make the single path
+ * the only path and let a census test fail when a sixth surface appears
+ * without it. `outbound-guard-census.test.ts` in the dashboard is that test.
+ *
+ * **It masks; it never refuses.** Consistent with the standing order that
+ * nothing is dropped — a refused send is a person's message deleted by a
+ * regex, and this detector's own header explains at length why coarse
+ * false positives are tolerable only because masking never costs the content.
+ * A masked send still sends, with `[REDACTED:<rule_id>]` where the value was.
+ *
+ * **It lives here, not in the dashboard**, because the worker's Linear mirror
+ * is an egress path too and cannot import from `apps/dashboard`. One choke
+ * point that stops at an app boundary is two choke points.
+ */
+/** The surfaces that can carry text out of Tower. Named so a log line can be grouped. */
+export const OUTBOUND_SURFACES = [
+    "mail",
+    "msg",
+    "slack",
+    "work",
+    "docs",
+    "linear_mirror",
+    // BLI-4167. A calendar write is the widest egress on this list: Google
+    // EMAILS every attendee the moment the event lands, so the summary,
+    // description and location leave for addresses Tower does not control and
+    // no later edit unsends them. `lib/cal/write.ts` is the writer.
+    "cal",
+];
+/**
+ * Masks every secret-shaped span in `fields` and logs once if anything changed.
+ *
+ * `null` and `undefined` pass through untouched, so a caller can hand over an
+ * optional field (`html`, a patch's absent `title`) without a branch at every
+ * call site — the branch is what gets forgotten.
+ *
+ * The log line carries the surface, the field NAMES, the rule ids and the
+ * counts. It deliberately carries no fragment of the matched text: a guard
+ * that prints what it caught has moved the secret from a message into a log,
+ * which is the failure this whole family exists to prevent
+ * (`~/.claude/rules/security.md`, "never log PII").
+ */
+export function guardOutboundFields(surface, fields) {
+    const guarded = {};
+    const maskedFields = [];
+    const ruleTotals = new Map();
+    let matchCount = 0;
+    for (const [name, value] of Object.entries(fields)) {
+        if (typeof value !== "string" || value.length === 0) {
+            guarded[name] = value;
+            continue;
+        }
+        // `server_commit` is the honest source: the mask is applied by the server
+        // at the moment it commits the send. The enum has no `outbound` member and
+        // adding one would relabel live redaction receipts that
+        // `secret-guards-lock.test.ts` pins — a schema change for a log line is a
+        // bad trade, and no outbound mask is persisted as a receipt anyway.
+        const result = redactSecretLikeContent(value, {
+            appliedBy: "server_commit",
+            redactedFields: [name],
+        });
+        guarded[name] = result.text;
+        if (!result.redacted)
+            continue;
+        maskedFields.push(name);
+        for (const count of result.metadata?.rule_counts ?? []) {
+            const existing = ruleTotals.get(count.rule_id) ?? {
+                rule_id: count.rule_id,
+                match_count: 0,
+                redacted_char_count: 0,
+            };
+            existing.match_count += count.match_count;
+            existing.redacted_char_count += count.redacted_char_count;
+            ruleTotals.set(count.rule_id, existing);
+            matchCount += count.match_count;
+        }
+    }
+    const report = {
+        masked: maskedFields.length > 0,
+        maskedFields,
+        ruleCounts: [...ruleTotals.values()],
+        matchCount,
+    };
+    if (report.masked) {
+        console.warn("[outbound guard] masked", JSON.stringify({
+            surface,
+            masked_fields: report.maskedFields,
+            rule_counts: report.ruleCounts,
+            secret_like_match_count: report.matchCount,
+        }));
+    }
+    return { fields: guarded, report };
+}
+/**
+ * The single-field shorthand, for a writer that has exactly one body to guard.
+ *
+ * Prefer `guardOutboundFields` when a writer has two or more — it produces ONE
+ * log line for the send rather than one per field, and a reader counting
+ * masked sends should not have to know how many columns a surface happens to
+ * have.
+ */
+export function guardOutboundText(surface, field, text) {
+    return guardOutboundFields(surface, { [field]: text }).fields[field];
+}

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;