claude-memory-lint 0.1.0

package/lib/locate-archive.js

@@ -0,0 +1,44 @@
+'use strict';
+// Finds where the memory archive lives, in order:
+//   1. `MEMORY_LINT_DIR` env var (mainly for tests, and for pointing the CLI
+//      at a non-default location)
+//   2. `autoMemoryDirectory` in `~/.claude/settings.local.json` or
+//      `~/.claude/settings.json` (Claude Code's own setting)
+//   3. a default derived from the home directory, matching Claude Code's own
+//      per-project memory path
+//
+// The result always says WHICH of these decided (`source`): a path with no
+// provenance has, in practice, caused audits to silently scan the wrong
+// folder and report a false "zero problems".
+const fs = require('fs');
+const os = require('os');
+const path = require('path');
+const { normalize } = require('./collector');
+
+function projectKey(dir) {
+  return String(dir).replace(/[:\\/]/g, '-');
+}
+
+function readJson(file) {
+  try {
+    return JSON.parse(normalize(fs.readFileSync(file, 'utf8')));
+  } catch (e) {
+    return null;
+  }
+}
+
+function locateArchive(env = process.env, home = os.homedir()) {
+  if (env.MEMORY_LINT_DIR) return { dir: env.MEMORY_LINT_DIR, source: 'MEMORY_LINT_DIR' };
+  for (const name of ['settings.local.json', 'settings.json']) {
+    const cfg = readJson(path.join(home, '.claude', name));
+    if (cfg && typeof cfg.autoMemoryDirectory === 'string' && cfg.autoMemoryDirectory.trim()) {
+      return { dir: cfg.autoMemoryDirectory.trim(), source: `autoMemoryDirectory (${name})` };
+    }
+  }
+  return {
+    dir: path.join(home, '.claude', 'projects', projectKey(home), 'memory'),
+    source: 'default derived from home directory',
+  };
+}
+
+module.exports = { locateArchive, projectKey, readJson };

package/lib/mask-code.js

@@ -0,0 +1,87 @@
+'use strict';
+// Masks Markdown code (fenced blocks and inline spans) so detectors never
+// treat a quoted example as a real claim. "Mention is not use": a marker or
+// keyword shown inside backticks as an example of the convention must not
+// count as an actual occurrence.
+//
+// `maskCode` replaces every character that sits inside code with a single
+// space (keeping line breaks intact), so line/column offsets never shift —
+// callers can still map a match back to its original line and position.
+
+// Masks a whole text. Returns a same-length string where code regions are
+// blanked out.
+function maskCode(text) {
+  const s = String(text);
+  const n = s.length;
+  const inCode = new Array(n).fill(false);
+
+  // 1) Fenced blocks. Opens and closes on its own line; everything inside is
+  // quoted.
+  const lines = [];
+  let start = 0;
+  for (let k = 0; k <= n; k++) {
+    if (k === n || s[k] === '\n') {
+      lines.push({ start, end: k });
+      start = k + 1;
+    }
+  }
+  let fence = null;
+  for (const L of lines) {
+    const txt = s.slice(L.start, L.end);
+    const m = /^\s{0,3}(`{3,}|~{3,})/.exec(txt);
+    if (fence) {
+      for (let k = L.start; k < L.end; k++) inCode[k] = true;
+      if (m && m[1][0] === fence.char && m[1].length >= fence.len && txt.slice(m[0].length).trim() === '') {
+        fence = null;
+      }
+    } else if (m) {
+      fence = { char: m[1][0], len: m[1].length };
+      for (let k = L.start; k < L.end; k++) inCode[k] = true;
+    }
+  }
+
+  // 2) Inline code spans. A run of N backticks opens and only closes with
+  // another run of exactly N — and the pair MAY cross a line break (real
+  // Markdown prose does this when a quoted term wraps).
+  let k = 0;
+  while (k < n) {
+    if (inCode[k] || s[k] !== '`') {
+      k++;
+      continue;
+    }
+    let j = k;
+    while (j < n && s[j] === '`') j++;
+    const len = j - k;
+    let p = j;
+    let close = -1;
+    while (p < n) {
+      if (s[p] === '`' && !inCode[p]) {
+        let q = p;
+        while (q < n && s[q] === '`') q++;
+        if (q - p === len) {
+          close = p;
+          break;
+        }
+        p = q;
+      } else {
+        p++;
+      }
+    }
+    // A backtick run with no matching close is a literal backtick, not an
+    // opener: mask nothing. A pair spanning a blank line is not a code span
+    // either — that boundary keeps a stray backtick from swallowing whole
+    // paragraphs and hiding a real claim inside "quoted" text.
+    if (close === -1 || s.slice(k, close + len).includes('\n\n')) {
+      k = j;
+      continue;
+    }
+    for (let t = k; t < close + len; t++) inCode[t] = true;
+    k = close + len;
+  }
+
+  let out = '';
+  for (let t = 0; t < n; t++) out += inCode[t] && s[t] !== '\n' ? ' ' : s[t];
+  return out;
+}
+
+module.exports = { maskCode };

package/lib/pii-categories.json

@@ -0,0 +1,403 @@
+{
+  "_meta": {
+    "purpose": "This is THE list. The PII detector (lib/detectors/pii.js) reads this file and declares no category in code — a list in two places becomes two lists that drift, and the one that drifts is always the one the gate reads.",
+    "fields": {
+      "id": "stable key; the name the detector reports and the tests plant",
+      "name": "human-readable category name",
+      "description": "what this category covers",
+      "carveOut": "what INSIDE this category may still be recorded. Without this the rule paralyzes every note that even mentions the topic",
+      "gate": "block = exit 1 on the CLI | warn = counted and reported, never exit 1 | doctrine = not detectable by form, never enters code as a pattern",
+      "gateRationale": "why THIS category sits at THIS gate — for block/warn categories under the same GDPR Art. 9/10 exposure, the gate reflects how precisely the pattern can be trusted, not a claim that the underlying data is less sensitive. For `doctrine`, it says why no pattern could ever check it.",
+      "precision": "high = the pattern only matches the thing itself | closed-vocabulary = matches narrowly, on purpose (declared low recall, not silent)",
+      "patterns": "regex in JS syntax, compiled with the 'i' flag. Empty list = prose-only category (doctrine)",
+      "exemptions": "if any exemption matches the SAME clause as a pattern match (and, when the exemption also names `appliesTo`, only for the pattern ids listed there), the pattern does not block or warn — the carve-out in executable form. An exemption may also carry `nullifiedBy`: a list of pattern ids that, if ANY of them also matches in that same clause, voids the exemption even where it would otherwise apply — used when the exemption's own wording (e.g. naming the category to teach it) sits right next to a real match of the thing it was never meant to excuse.",
+      "example": "a synthetic case for `block`/`warn`, and one for `exempt` (the carve-out). Both are fabricated for this file; neither is a real record"
+    },
+    "globalExemptionsNote": "See `globalExemptions` below: quoting a term inside backticks or a fenced code block is citation, not use — a note that TEACHES this list needs to be able to show the phrase it catches without tripping the gate on itself.",
+    "languageScope": "Patterns here are English-vocabulary only. A memory archive kept in another language will have lower recall on the prose-based categories (health, minor, specialCategoryOther) until someone adds that language's vocabulary — this is a declared limit, not a silent one. The regex-only categories (nationalId, bankAccount, credential, directIdentifier's email pattern, onlineIdentifier) are format-based and language-independent.",
+    "scopeNote": "This file draws the line technology can enforce. It does not replace legal advice: which categories apply, and under which law (GDPR Art. 9, a US state privacy statute, or something else), is a judgment call for whoever operates this tool, not something the tool decides for them.",
+    "coverageScope": [
+      "a person's NAME in free-form prose (no fixed shape to match on; catching it needs named-entity recognition, which this list does not attempt)",
+      "a full POSTAL ADDRESS in free-form prose (same reason — city/street text has no fixed shape)",
+      "PRECISE GEOLOCATION expressed as prose (\"outside the school on Elm Street\") rather than coordinates",
+      "a COOKIE OR DEVICE IDENTIFIER (no universal format across vendors to match on)",
+      "PHILOSOPHICAL OR POLITICAL CONVICTION beyond the closed vocabulary already in specialCategoryOther",
+      "this whole list is ENGLISH-vocabulary for its prose categories (see languageScope above)"
+    ]
+  },
+  "globalExemptions": [
+    {
+      "id": "backtick-mention",
+      "regex": "`[^`]*`",
+      "descriptionNote": "quoting a term in backticks is citation, not a record of it"
+    },
+    {
+      "id": "fenced-code-block",
+      "regex": "^\\s*```",
+      "descriptionNote": "inside a fenced code block, the form is an example, not a record"
+    }
+  ],
+  "version": 1,
+  "categories": [
+    {
+      "id": "nationalId",
+      "name": "National ID number and government document",
+      "description": "A national identity number, passport number, driver's license number, or social-security-style number. Counts whole or partial: several national ID formats embed a birth date, so even a truncated fragment is not \"harmless partial\".",
+      "carveOut": "The FACT that one exists is recordable (\"has a national ID on file\", \"pending — no ID issued yet\"), and a birth YEAR the person volunteered themselves. The number itself, never — not even truncated.",
+      "gate": "block",
+      "gateRationale": "the patterns are format-based (`precision: high`): a match is the number itself, not a word that merely suggests one, so a false positive is rare enough that treating every hit as a hard stop is the right tradeoff.",
+      "precision": "high",
+      "maskCodeSpans": false,
+      "maskCodeSpansNote": "A national ID number pasted inside a fenced code block (a copied log, a support ticket dump) is still a leaked ID — masking it out of the scan is where a prior bug hid it entirely",
+      "patterns": [
+        {
+          "id": "nordic-personal-id",
+          "regex": "\\b(?:0[1-9]|[12]\\d|3[01]|4[1-9]|[56]\\d|7[01])(?:0[1-9]|1[0-2])\\d{2}-?\\d{4}\\b",
+          "description": "Nordic-style personal identity number: DDMMYY(-)NNNC, where DD is a valid day (01-31, or 41-71 for the legal-entity variant some countries use) and MM a valid month (01-12). A bare `\\d{10}` would also match error codes and comment IDs — requiring a valid date prefix keeps the pattern to actual ID numbers"
+        },
+        {
+          "id": "us-ssn",
+          "regex": "\\b\\d{3}-\\d{2}-\\d{4}\\b",
+          "description": "US Social Security Number format (NNN-NN-NNNN)"
+        },
+        {
+          "id": "br-cpf",
+          "regex": "\\b\\d{3}\\.?\\d{3}\\.?\\d{3}-\\d{2}\\b",
+          "description": "Brazilian CPF, punctuated or not"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "phone-number",
+          "regex": "(tel:|phone|whatsapp|call|mobile)",
+          "description": "a line about a phone number has a run of digits and is not a document"
+        },
+        {
+          "id": "technical-id-or-timestamp",
+          "regex": "(epoch|timestamp|commit|sha|issue #|pr #|comment id|https?://|0x[0-9a-f]{4,}|exit code|error code)",
+          "description": "a technical number with declared context — a URL, a code-review comment id, an error code — is not a national ID even when the digit count lines up"
+        }
+      ],
+      "example": {
+        "block": "Their national ID is 120385-2399, file closed.",
+        "exempt": "They're a foreign national with no ID on file yet; said they were born in 1985."
+      }
+    },
+    {
+      "id": "bankAccount",
+      "name": "Bank account, card, and payment credential",
+      "description": "IBAN, account and routing number, card number, CVV, expiry date, a payment-app handle tied to one person.",
+      "carveOut": "The LAST FOUR digits of a card are recordable — it's already on the receipt and doesn't re-identify by itself. The full card number, the full IBAN, and the CVV, never. Amount paid, currency, date, and payment status are all recordable.",
+      "gate": "block",
+      "gateRationale": "format-based and checksum-gated (`precision: high`): a card number has to pass Luhn, an IBAN has a fixed shape, so a hit is the credential itself, not a guess.",
+      "precision": "high",
+      "maskCodeSpans": false,
+      "maskCodeSpansNote": "A card number or IBAN pasted inside a fenced block (a copied receipt, a support ticket) is still a leaked payment credential",
+      "patterns": [
+        {
+          "id": "iban",
+          "regex": "\\b[A-Z]{2}\\d{2}[A-Z0-9]{11,30}\\b",
+          "description": "IBAN, any issuing country"
+        },
+        {
+          "id": "card-number",
+          "regex": "\\b(?:\\d[ -]?){13,19}\\b",
+          "checksum": "luhn",
+          "description": "a card number, with or without separators. Gated on a Luhn (mod-10) check: every real card scheme's number passes it, and a random 13-19 digit platform ID (an ad account, a page ID) passes only by coincidence — narrows the match without exempting a whole clause the way a keyword carve-out would"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "last-four-only",
+          "regex": "(\\*{2,}\\s*\\d{4}|•{2,}\\s*\\d{4}|final\\s+\\d{4}|ending\\s+in\\s+\\d{4}|last\\s*4)",
+          "appliesTo": ["card-number"],
+          "description": "the carve-out in executable form: a mask plus four digits passes. Scoped to card-number only — a masked card number says nothing about whether a nearby full IBAN is safe to record"
+        },
+        {
+          "id": "platform-technical-id",
+          "regex": "(account id|page id|asset id|ad account|portfolio|draft \\d|legacy|migrations|epoch|timestamp|commit|sha|issue #|pr #)",
+          "appliesTo": ["card-number"],
+          "description": "a numeric platform ID (an ad account, a page ID, a draft or migration number) can land in the 13-19 digit range the card pattern matches without being a payment instrument at all. Scoped to card-number only — an IBAN next to \"ad account\" in the same sentence is still a full IBAN"
+        }
+      ],
+      "example": {
+        "block": "Paid with card 4539 1488 0343 6467, IBAN GB29NWBK60161331926819.",
+        "exempt": "Paid 249 on the card ending in 6467, dated 2026-09-12."
+      }
+    },
+    {
+      "id": "health",
+      "name": "Health data (a special category under most privacy laws)",
+      "description": "A medical condition, diagnosis, treatment, medication, pregnancy, allergy, or a photo of a person taken during treatment.",
+      "carveOut": "The OPERATIONAL FACT without the condition behind it is recordable: \"out on leave until the 14th\", \"asked to reschedule\", \"prefers a room without air conditioning\", \"not available in September\". The condition itself, never — and it doesn't stop being health data when it's dressed up as a preference.",
+      "gate": "block",
+      "gateRationale": "block despite `closed-vocabulary` precision (unlike `minor`/`specialCategoryOther`, also Art. 9 categories, which are `warn`): the closed vocabulary here is clinical terms with almost no other meaning (\"chemotherapy\", \"pregnan*\"), so the false-positive rate is low enough to justify a hard stop — the gate reflects that precision, not a claim that religion or trade-union membership matter less under Art. 9(1) than health does.",
+      "precision": "closed-vocabulary",
+      "coverage": "declared-low: matches narrowly on purpose. A detector that scans prose for health data gets this wrong in both directions, and a declared narrow match is safer than a silent gap on the category with the highest legal exposure.",
+      "patterns": [
+        {
+          "id": "condition",
+          "regex": "\\b(cancer|diabetes|HIV|depression|anxiety|asthma|allerg\\w*|pregnan\\w*)\\b",
+          "description": "a closed clinical vocabulary, deliberately narrow"
+        },
+        {
+          "id": "treatment",
+          "regex": "\\b(medication|prescription|chemotherapy|medical treatment)\\b",
+          "description": "a named clinical act"
+        },
+        {
+          "id": "clinical-diagnosis",
+          "regex": "(diagnosis)[^.\\n]{0,40}(medical|clinical|patient)|(medical|clinical|patient)[^.\\n]{0,40}(diagnosis)",
+          "description": "\"diagnosis\" alone is common engineering jargon (\"diagnosis of the failing build\"); requiring a medical/clinical qualifier in the same sentence keeps that jargon out. The cost, declared: \"diagnosis of a condition\" that names an actual illness elsewhere in the sentence is caught by the `condition` pattern instead, not here"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "leave-without-condition",
+          "regex": "\\b(on leave|sick leave|out of office)\\b",
+          "description": "the carve-out: the operational fact alone passes"
+        },
+        {
+          "id": "service-menu",
+          "regex": "\\b(treatment menu|service menu|list of services|our services)\\b",
+          "description": "a business's own service listing names a service, not a person"
+        },
+        {
+          "id": "mentions-the-category",
+          "regex": "\\b(health data|special category|what not to store)\\b",
+          "nullifiedBy": ["condition", "treatment", "clinical-diagnosis"],
+          "description": "mention is not use, in prose form: a line that talks ABOUT health data to teach the rule is not itself a record of anyone's health. \"PII\" and \"never store\" were dropped from this vocabulary because real notes use both while also naming a real condition (\"Never store this kind of thing: she is pregnant\"), and `nullifiedBy` voids this exemption whenever `condition`/`treatment`/`clinical-diagnosis` also matches in the same clause — the same clinical word can't be both the disclosure and its own excuse."
+        }
+      ],
+      "example": {
+        "block": "They rescheduled Tuesday's session because of the pregnancy; still on medication.",
+        "exempt": "They rescheduled Tuesday's session; on leave until the 14th."
+      }
+    },
+    {
+      "id": "minor",
+      "name": "A minor (under 18)",
+      "description": "Any data that identifies a person under 18: name, photo, school, appointment time, contact details.",
+      "carveOut": "An aggregated fact with nobody identifiable is recordable: \"the package serves minors and requires guardian consent\" is a business rule and stays.",
+      "gate": "warn",
+      "gateRationale": "warn, not because a minor's data matters less under Art. 9(1) than health, but because the vocabulary (\"minor\", \"child of\", \"kid of\") collides constantly with ordinary engineering and business prose (a DOM \"child\", \"the child process\") — the gate reflects that collision risk, not lower legal exposure. Same Art. 9 category as `health`, deliberately looser gate because the pattern is less trustworthy, not the data less sensitive.",
+      "precision": "closed-vocabulary",
+      "patterns": [
+        {
+          "id": "minor-mention",
+          "regex": "\\b(minor|underage|child of|kid of)\\b",
+          "description": "prose: reports, never blocks by itself"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "business-rule",
+          "regex": "\\b(the package|the service|the policy|guardian consent|parental consent)\\b",
+          "description": "the aggregated carve-out"
+        },
+        {
+          "id": "technical-node",
+          "regex": "\\b(container|element|node|DOM|div|flex|grid|clipping|overflow|CSS|PID|process|supervisor|worker|port)\\b",
+          "description": "\"child of\" also matches \"child of a container\" or \"the child process\" — a DOM or OS node, not a person"
+        }
+      ],
+      "example": {
+        "block": "Their minor child, age 14, comes in Thursdays at 4pm.",
+        "exempt": "The package serves minors and requires guardian consent."
+      }
+    },
+    {
+      "id": "specialCategoryOther",
+      "name": "Other special categories",
+      "description": "Racial or ethnic origin, political opinion, religious belief, trade-union membership, biometric data used for identification, sexual orientation, and genetic data (GDPR Art. 9(1) names all of these in the same list — this category previously only carried a vocabulary term for biometric).",
+      "carveOut": "A service language is recordable and is not ethnicity (\"serves clients in Polish\"); a holiday that closes the calendar is recordable and is not religion (\"closed on the 25th\").",
+      "gate": "warn",
+      "gateRationale": "warn for the same reason as `minor`: origin, religion, orientation, and union membership have the SAME Art. 9(1) exposure as health, but the vocabulary here (\"religious\", \"political party\", \"biometric\") sits closer to everyday business language (a religious holiday closing, a biometric login feature) than the health category's clinical terms do — the looser gate measures that precision gap, not a lesser legal claim.",
+      "precision": "closed-vocabulary",
+      "patterns": [
+        {
+          "id": "special-category",
+          "regex": "\\b(union member|trade union|religious|muslim|jewish|christian|sexual orientation|political party|biometric)\\b",
+          "description": "prose: reports, never blocks by itself"
+        },
+        {
+          "id": "genetic-data",
+          "regex": "\\b(genetic (test|marker|screening|data)|DNA (test|sample|marker))\\b",
+          "description": "Art. 9(1) names genetic data alongside biometric data, but the shipped vocabulary only had a term for the latter — closed vocabulary, same declared-low-recall tradeoff as the rest of this category"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "language-or-holiday",
+          "regex": "\\b(serves clients in|language|holiday|closed on)\\b",
+          "description": "the operational carve-out"
+        },
+        {
+          "id": "market-data-source",
+          "regex": "\\b(source|directory|list of|database|company registry|sample)\\b",
+          "description": "\"the union membership directory\" is a data source's provenance, not a person's union membership"
+        }
+      ],
+      "example": {
+        "block": "The owner is a union member and Evangelical — use that angle in the copy.",
+        "exempt": "Serves clients in Polish; closed on the 25th for the holiday."
+      }
+    },
+    {
+      "id": "credential",
+      "name": "Credential and secret",
+      "description": "An API token, key, password, session cookie, or the value of an environment variable. Not personal data, but on this list for the same reason: no configuration unblocks it.",
+      "carveOut": "The NAME of the vault entry or variable is recordable and is the correct way to record it (\"the key is `SERVICE_TOKEN`, in the vault\"). The value, never — a leaked value gets rotated, not edited out of a text file.",
+      "gate": "block",
+      "gateRationale": "format-based (`precision: high`): every pattern here, including the private-key and plaintext-password patterns, matches a shape that is not used for anything except the secret itself — there is no legitimate English sentence that happens to contain a PEM private-key header or `password: <value>` by coincidence.",
+      "precision": "high",
+      "maskCodeSpans": false,
+      "maskCodeSpansNote": "This is the exact bug a prior audit found: a live key pasted inside a fenced ``` block (a copied error log) was invisible because the scan masked the block before judging it. A live key in a code block is still a live key.",
+      "patterns": [
+        {
+          "id": "airtable-token",
+          "regex": "\\bpat[A-Za-z0-9]{14,}\\b",
+          "description": "an Airtable personal access token"
+        },
+        {
+          "id": "github-token",
+          "regex": "\\bgh[pousr]_[A-Za-z0-9]{20,}\\b",
+          "description": "a GitHub token"
+        },
+        {
+          "id": "openai-style-key",
+          "regex": "\\bsk-[A-Za-z0-9_-]{20,}\\b",
+          "description": "an sk- format API key"
+        },
+        {
+          "id": "slack-token",
+          "regex": "\\bxox[baprs]-[A-Za-z0-9-]{10,}\\b",
+          "description": "a Slack token"
+        },
+        {
+          "id": "aws-access-key",
+          "regex": "\\bAKIA[0-9A-Z]{16}\\b",
+          "description": "an AWS access key ID"
+        },
+        {
+          "id": "private-key-block",
+          "regex": "-----BEGIN [A-Z0-9 ]*PRIVATE KEY-----",
+          "description": "a PEM-format private key block header (RSA, EC, OpenSSH, or generic). The header line alone is the signal — real material always has the key body right after it, and waiting for the body adds nothing but a chance to miss a truncated paste"
+        },
+        {
+          "id": "plaintext-password",
+          "regex": "\\bpassword\\s*[:=]\\s*\\S{6,}",
+          "description": "a password assigned or shown in cleartext next to the word \"password\" (`password: hunter2SuperSecret`, `password=abc123!!`). Vendor-token patterns above catch a NAMED format; this catches the generic case a person types when handing over a login by hand"
+        }
+      ],
+      "exemptions": [],
+      "example": {
+        "block": "The API token is patAbCdEfGhIjKlMnOp.1234567890abcdef",
+        "exempt": "The key is `SERVICE_TOKEN`, in the vault; the value never leaves it."
+      }
+    },
+    {
+      "id": "directIdentifier",
+      "name": "Direct identifier (email, phone)",
+      "description": "GDPR Art. 4(1) direct identifiers this list can match by FORMAT: an email address and a phone number. A person's NAME is a direct identifier too and is deliberately NOT here — free-form prose has no fixed shape to match a name against; see `_meta.coverageScope`. A postal address is the same story and is also declared out of scope there.",
+      "carveOut": "A business's own published contact address (\"reach us at hello@thecompany.com\") is recordable — it identifies the business, not a private person. A generic role mailbox (info@, support@, hello@) is lower risk than a personal name@ address, but this list does not try to tell them apart by pattern; that judgment stays with whoever reviews a finding.",
+      "gate": "warn",
+      "gateRationale": "warn: the format is precise (an email/phone shape rarely appears by accident), but the pattern cannot tell a private person's address from a business's own published one (\"support@\" vs. a client's name@) — the gate reflects that every hit still needs a human look, not that a phone number matters less than a national ID.",
+      "precision": "closed-format",
+      "coverage": "declared-low: catches an email or phone number by shape. It does not, and cannot by regex alone, tell a client's personal address from a business's own published one — every hit is a finding to review, not an automatic verdict on whose address it is.",
+      "patterns": [
+        {
+          "id": "email-address",
+          "regex": "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}\\b",
+          "description": "an email address, any domain"
+        },
+        {
+          "id": "phone-number",
+          "regex": "\\b(?:\\+\\d{1,3}[ .-]?)?(?:\\(?\\d{2,4}\\)?[ .-]?){2,4}\\d{2,4}\\b",
+          "description": "a phone number with a country code or grouped digits — deliberately loose on grouping, since phone formatting varies by country"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "business-contact",
+          "regex": "\\b(our (email|phone|number)|company (email|phone)|support@|info@|hello@|contact us at|book (a|an) (call|appointment) at)\\b",
+          "description": "a business's own published contact channel is not a private person's identifier"
+        }
+      ],
+      "example": {
+        "block": "Client's email is jon.somebody@example.com and mobile is 555-0142.",
+        "exempt": "Our support email is support@example.com; book an appointment at 555-0100."
+      }
+    },
+    {
+      "id": "onlineIdentifier",
+      "name": "Online identifier (IP address)",
+      "description": "GDPR Art. 4(1) + Recital 30 treat an IP address as personal data when it can be linked to a person. A cookie or device ID is the same class and is deliberately NOT matched here — there is no shared format across vendors to match on; see `_meta.coverageScope`.",
+      "carveOut": "A CIDR range or example IP used to document infrastructure (\"the office is on 10.0.0.0/8\") is recordable — it names a network, not a person's connection.",
+      "gate": "warn",
+      "gateRationale": "warn: an IPv4 address is only personal data when it links back to a person, and this list has no way to tell a client's home connection from an office subnet or a documentation example by shape alone — every hit needs the same human read a business-vs-personal email address needs.",
+      "precision": "closed-format",
+      "patterns": [
+        {
+          "id": "ipv4",
+          "regex": "\\b(?:(?:25[0-5]|2[0-4]\\d|1?\\d?\\d)\\.){3}(?:25[0-5]|2[0-4]\\d|1?\\d?\\d)\\b",
+          "description": "an IPv4 address"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "infra-documentation",
+          "regex": "\\b(cidr|subnet|localhost|private range|internal network|10\\.0\\.0\\.0|192\\.168\\.0\\.0|reserved range)\\b",
+          "description": "documenting a network, not recording a person's connection"
+        }
+      ],
+      "example": {
+        "block": "Their home IP is 192.168.10.44, seen at login.",
+        "exempt": "The office subnet is 192.168.0.0/16, per the network docs."
+      }
+    },
+    {
+      "id": "criminalRecord",
+      "name": "Criminal conviction or offence data",
+      "description": "GDPR Art. 10: data about criminal convictions and offences sits OUTSIDE Art. 9's special categories, under its own regime, requiring official-authority processing or member-state law — separate legal basis from health/religion/etc., which is why it is its own category here rather than folded into specialCategoryOther.",
+      "carveOut": "An aggregated policy fact is recordable (\"the package requires a background check\"); a specific person's record or charge, never.",
+      "gate": "warn",
+      "gateRationale": "warn despite Art. 10's own strict regime (official-authority processing, member-state law): the vocabulary (\"convicted of\", \"charged with\") reads naturally in a policy sentence (\"requires a background check\") as often as in a real disclosure, so the gate is set by that ambiguity, not by Art. 10 mattering less than Art. 9.",
+      "precision": "closed-vocabulary",
+      "coverage": "declared-low: matches narrowly on purpose, same tradeoff as `health`.",
+      "patterns": [
+        {
+          "id": "criminal-history",
+          "regex": "\\b(criminal (record|conviction|history)|prior conviction|convicted of|arrested for|charged with|prison sentence)\\b",
+          "description": "a closed clinical-style vocabulary for offence data, deliberately narrow"
+        }
+      ],
+      "exemptions": [
+        {
+          "id": "policy-requirement",
+          "regex": "\\b(background check|the package|the policy|requires a check)\\b",
+          "description": "an aggregated policy requirement, not one person's record"
+        }
+      ],
+      "example": {
+        "block": "He has a prior criminal conviction for fraud.",
+        "exempt": "The package requires a background check for anyone handling cash."
+      }
+    },
+    {
+      "id": "falseAnonymity",
+      "name": "False anonymity (a combination that re-identifies)",
+      "description": "The record names no one, and still points at exactly one person: \"the client who complained on Tuesday\", or a small town plus profession plus appointment date. Dropping the name doesn't anonymize — a handful of attributes is often enough in a small enough population.",
+      "carveOut": "The same fact with the singular detail dropped is recordable: \"there was a scheduling complaint in September\" teaches the same lesson without pointing at anyone.",
+      "gate": "doctrine",
+      "gateRationale": "doctrine, not warn: re-identification by combination has no fixed shape at all — it's a judgment about how small a population a set of attributes narrows down to, which regex cannot approximate even loosely. This category is never evaluated by the detector, so the report must say so explicitly instead of printing a count that looks like a completed check.",
+      "precision": "not-detectable",
+      "patterns": [],
+      "exemptions": [],
+      "example": {
+        "block": "The client who complained on Tuesday backed off.",
+        "exempt": "There was a scheduling complaint in September."
+      }
+    }
+  ]
+}

package/memory-lint.config.json

@@ -0,0 +1,19 @@
+{
+  "_doc": "Template config. Copy/edit these numbers to your own archive's real size. They are placeholders, not a real measurement. See lib/config.js for the built-in defaults this file overrides.",
+  "budget": {
+    "lines": 200,
+    "bytes": 20000,
+    "readerLineLimit": 200,
+    "proximityWarning": 190
+  },
+  "provenance": {
+    "baselineFile": "memory-lint.baseline.json",
+    "markers": ["stated", "measured", "inferred"]
+  },
+  "perishable": {
+    "cutoffDate": null
+  },
+  "pii": {
+    "categoriesFile": null
+  }
+}

package/package.json

@@ -0,0 +1,31 @@
+{
+  "name": "claude-memory-lint",
+  "version": "0.1.0",
+  "description": "Structural checks for a Claude Code MEMORY.md memory archive: closed size budget, required frontmatter, per-line provenance markers, perishable-state tracking, a personal-data/secrets scan, and a suppression-instruction detector judged by effect.",
+  "license": "MIT",
+  "author": "Nord Leads",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/vgrosetti-maker/claude-memory-lint.git"
+  },
+  "homepage": "https://github.com/vgrosetti-maker/claude-memory-lint#readme",
+  "bugs": {
+    "url": "https://github.com/vgrosetti-maker/claude-memory-lint/issues"
+  },
+  "bin": {
+    "memory-lint": "bin/memory-lint.js"
+  },
+  "main": "lib/index.js",
+  "files": [
+    "bin",
+    "lib",
+    "memory-lint.config.json",
+    "CHANGELOG.md"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "scripts": {
+    "test": "node --test test/*.test.js"
+  }
+}