Add HealthOS bundle privacy foundation

[alanshurafa]

Summary

This is the first upstream-safe HealthOS integration slice from RFC #105.

It adds a privacy-first foundation before any HealthOS engine or connector code is migrated:

• adds SECURITY.md guidance for PHI-free contributions and incident response
• adds a privacy audit script and CI workflow
• adds a HealthOS Bundle v1 TypeScript contract and runtime validation
• adds an authenticated POST /api/healthos/import route using the existing HealthData table
• summarizes HEALTHOS_BUNDLE records before chat context injection instead of dumping raw JSON
• adds a synthetic bundle fixture and Vitest coverage

No private HealthOS runtime data, raw exports, reports, real fixtures, local paths, or person-specific clinical facts are included.

Verification

• npm run privacy:audit
• npm test
• npm run lint
• npm run build

npm run lint and npm run build report pre-existing React hook warnings in onboarding/chat/source components, but pass.

[gemini-code-assist]

Code Review

This pull request integrates HealthOS as a validated health data engine, introducing a new security policy, an RFC, and a privacy audit script to prevent sensitive data exposure. The implementation includes API endpoints for bundle imports, logic for summarizing health data in chat contexts, and a privacy scanner. Review feedback highlights opportunities to improve the privacy scanner's coverage of sensitive terms, ensure only validated fields are persisted in the database, optimize file I/O in the audit script, and replace magic numbers with named constants for better maintainability.

[gemini-code-assist]

The regex patterns for forbidden strings do not account for camelCase variants (e.g., advisorChat, rawPayload), which are explicitly listed in forbiddenKeys. Additionally, several other sensitive keys like mood_log and unapproved_genetics are missing from the string pattern check entirely. This could allow sensitive information to bypass the scanner if it appears within string values using these naming conventions.

const forbiddenStringPatterns = [
    /[A-Za-z]:\\/,
    /\/Users\/[^/\s]+/,
    /\bruntime\//i,
    /\.sqlite3?\b/i,
    /\.db\b/i,
    /\.pdf\b/i,
    /\.vcf\b/i,
    /\b(raw_?payload|rawPayload)\b/i,
    /\b(advisor[_ -]?chat|advisorChat)\b/i,
    /\b(mood_?log|moodLog)\b/i,
    /\b(unapproved_?genetics|unapprovedGenetics)\b/i,
];

[gemini-code-assist]

The parseHealthOsBundle function uses the spread operator (...input) when constructing the bundle object. This preserves any extra, unvalidated properties from the raw input and includes them in the final object. Since this object is subsequently stored in the database (via buildHealthOsImportData), this could lead to the persistence of unexpected or sensitive data that was not intended to be part of the HealthOS bundle schema. It is safer to explicitly pick the validated fields.

    const bundle: HealthOsBundleV1 = {
        bundle_version: HEALTHOS_BUNDLE_VERSION,
        generated_at: requireString(input, "generated_at"),
        source_freshness: validateFreshness(requireArray(input, "source_freshness")),
        landing_summary: validateLandingSummary(requireArray(input, "landing_summary")),
        clinician_packet: requireRecord(input, "clinician_packet") as HealthOsClinicianPacket,
        metrics: requireArray(input, "metrics") as JsonRecord[],
        provenance: requireArray(input, "provenance") as JsonRecord[],
        warnings: requireArray(input, "warnings").map((warning, index) => {
            if (typeof warning !== "string") throw new Error(`warnings[${index}] must be a string`);
            return warning;
        }),
    };

[gemini-code-assist]

The script reads the content of each file twice: once in isLikelyText to check for null bytes, and again here to perform the term search. For a large number of files, this significantly increases I/O overhead. Consider refactoring isLikelyText to return the file content if it's valid text, or caching the result to avoid redundant reads.

[gemini-code-assist]

The array slicing limits (12, 20, 8) are hardcoded magic numbers. Defining these as named constants at the top of the file would improve readability and make it easier to adjust these limits (e.g., for prompt token management) in the future.