@cubis/foundry 0.3.82 → 0.3.84

package/workflows/skills/sadd/references/test-generation.md

@@ -1,170 +0,0 @@
-# Test Generation from Specifications
-
-Load this when generating test cases from extracted specifications across testing frameworks.
-
----
-
-## The Test Generation Pipeline
-
-```
-Specification (GIVEN-WHEN-THEN)
-    |
-    v
-Test Skeleton (describe/it structure with placeholders)
-    |
-    v
-Assertion Design (what to assert and why)
-    |
-    v
-Implementation (framework-specific test code)
-```
-
----
-
-## From Spec to Test Skeleton
-
-### Input: A Structured Specification
-
-```
-SPEC-007: GIVEN a user with an expired subscription
-          WHEN they attempt to access premium content
-          THEN they receive a 403 Forbidden response
-          AND the response body contains an upgrade prompt
-```
-
-### Output: Test Skeleton
-
-```javascript
-describe('Premium Content Access', () => {
-  describe('SPEC-007: Expired subscription access', () => {
-    it('should return 403 when subscription is expired', async () => {
-      // GIVEN
-      const user = await createUser({ subscriptionStatus: 'expired' });
-
-      // WHEN
-      const response = await request(app)
-        .get('/api/premium/content')
-        .set('Authorization', `Bearer ${user.token}`);
-
-      // THEN
-      expect(response.status).toBe(403);
-      expect(response.body).toHaveProperty('upgradePrompt');
-    });
-  });
-});
-```
-
----
-
-## Assertion Strategies by Spec Type
-
-### Functional Specifications
-
-Assert on outputs, side effects, and state changes.
-
-| Spec Says | Assert On |
-|-----------|-----------|
-| "returns X" | Response body content |
-| "creates a record" | Database state after action |
-| "sends an email" | Email service mock was called with correct arguments |
-| "redirects to Y" | Response status 3xx and Location header |
-
-### Non-Functional Specifications
-
-Assert on quality attributes with appropriate tools.
-
-| Spec Says | Assert On | Tool |
-|-----------|-----------|------|
-| "responds within 200ms" | P95 response time | k6, artillery |
-| "handles 1000 concurrent users" | Error rate under load | k6, locust |
-| "meets WCAG 2.1 AA" | Accessibility violations | axe-core, pa11y |
-| "no SQL injection" | Input sanitization | sqlmap, OWASP ZAP |
-
-### Constraint Specifications
-
-Assert that business rules are enforced.
-
-| Spec Says | Assert On |
-|-----------|-----------|
-| "maximum 10 items per cart" | Rejection at item 11 |
-| "only admins can delete" | 403 for non-admin users |
-| "amounts in USD only" | Rejection of non-USD currency codes |
-
----
-
-## Generating Negative Tests
-
-Every positive specification implies at least one negative test:
-
-| Positive Spec | Negative Test |
-|--------------|---------------|
-| "Users can log in with valid credentials" | "Users cannot log in with invalid credentials" |
-| "Orders with valid payment are processed" | "Orders with declined payment are not processed" |
-| "Admins can view all reports" | "Non-admins cannot view all reports" |
-
-### Boundary Value Tests
-
-For numeric or size constraints, test at the boundaries:
-
-```
-Spec: "Password must be at least 8 characters"
-
-Tests:
-- 7 characters -> rejected (below boundary)
-- 8 characters -> accepted (at boundary)
-- 9 characters -> accepted (above boundary)
-- 0 characters -> rejected (zero case)
-- 1000 characters -> accepted (large input)
-```
-
----
-
-## Framework-Specific Patterns
-
-### Jest / Vitest (JavaScript/TypeScript)
-
-```javascript
-describe('[SPEC-ID]: [spec description]', () => {
-  it('should [expected behavior] when [condition]', () => {
-    // Arrange - GIVEN
-    // Act - WHEN
-    // Assert - THEN
-  });
-});
-```
-
-### pytest (Python)
-
-```python
-class TestSpecXXX:
-    """SPEC-XXX: [spec description]"""
-
-    def test_expected_behavior_when_condition(self):
-        # Arrange - GIVEN
-        # Act - WHEN
-        # Assert - THEN
-        pass
-```
-
-### Go testing
-
-```go
-func TestSpec001_ExpectedBehavior_WhenCondition(t *testing.T) {
-    // Arrange - GIVEN
-    // Act - WHEN
-    // Assert - THEN
-}
-```
-
----
-
-## Test Completeness Checklist
-
-For every specification, verify that tests cover:
-
-- [ ] Happy path (positive case as specified)
-- [ ] Error path (invalid input, missing data)
-- [ ] Boundary values (min, max, zero, one-off)
-- [ ] Concurrency (if applicable)
-- [ ] State dependencies (preconditions not met)
-- [ ] Idempotency (if operation should be repeatable)

package/workflows/skills/sadd/references/traceability.md

@@ -1,113 +0,0 @@
-# Traceability Matrices Reference
-
-Load this when building and maintaining requirement traceability.
-
----
-
-## What Is a Traceability Matrix?
-
-A traceability matrix is a table that maps every requirement to its corresponding tests, implementation locations, and verification status. It answers three questions:
-
-1. **Is every requirement tested?** (Forward traceability: spec -> test)
-2. **Does every test trace back to a requirement?** (Backward traceability: test -> spec)
-3. **Is every requirement implemented?** (Implementation traceability: spec -> code)
-
----
-
-## Matrix Structure
-
-### Minimal Matrix
-
-```markdown
-| REQ ID | Test ID | Status |
-|--------|---------|--------|
-| REQ-001 | TEST-001 | Pass |
-| REQ-002 | TEST-002, TEST-003 | Pass |
-| REQ-003 | — | No test |
-```
-
-### Full Matrix
-
-```markdown
-| REQ ID | Requirement | Test IDs | Test Status | Code Location | Verified By | Date |
-|--------|------------|----------|-------------|---------------|-------------|------|
-| REQ-001 | User can register with email | TEST-001, TEST-002 | Pass | auth.ts:45 | @dev | 2026-03-01 |
-```
-
----
-
-## Building the Matrix
-
-### Step 1: Populate Requirements Column
-
-List every requirement from the specification with its unique ID. If requirements don't have IDs, assign them sequentially (REQ-001, REQ-002, ...).
-
-### Step 2: Map Tests to Requirements
-
-For each test in the test suite, identify which requirement it validates. A single test may cover multiple requirements; a single requirement may need multiple tests.
-
-### Step 3: Identify Gaps
-
-- **Requirements with no tests:** These need test creation.
-- **Tests with no requirements:** These might test implementation details (consider removing) or might reveal undocumented requirements (consider adding to the spec).
-- **Requirements with no implementation:** These are unimplemented features.
-
-### Step 4: Add Implementation Locations
-
-For each requirement, record the file and line where the behavior is implemented. This enables quick navigation during reviews and debugging.
-
----
-
-## Maintaining the Matrix
-
-### When to Update
-
-| Event | Matrix Action |
-|-------|--------------|
-| New requirement added | Add row with REQ ID, mark tests as "Pending" |
-| Requirement changed | Update requirement text, mark tests as "Needs re-verification" |
-| Requirement removed | Mark row as "Deprecated" with date and reason |
-| New test added | Link test to requirement(s) it validates |
-| Test removed | Remove test link, flag requirement if now untested |
-| Code moved | Update implementation location |
-| Code refactored | Re-verify that tests still pass for affected requirements |
-
-### Staleness Indicators
-
-A matrix is going stale when:
-
-- More than 10% of entries have "Pending" status for more than one sprint.
-- Implementation locations point to files that no longer exist.
-- Test IDs reference tests that have been deleted or renamed.
-
----
-
-## Using the Matrix in Code Review
-
-### Reviewer Checklist
-
-1. Does the PR change any requirement in the matrix?
-2. If yes, are the corresponding tests updated?
-3. If new code is added, is there a requirement for it?
-4. If a test is modified, does it still validate its linked requirement?
-5. Is the matrix updated in the same PR?
-
-### Common Review Findings
-
-| Finding | Severity | Action |
-|---------|----------|--------|
-| New feature with no requirement | Medium | Add requirement to spec, then to matrix |
-| Changed behavior with unchanged test | High | Update test to validate new behavior |
-| Deleted test with active requirement | High | Restore test or provide replacement |
-| Matrix not updated | Low | Update matrix before merge |
-
----
-
-## Automation Opportunities
-
-| Opportunity | Tool | Impact |
-|------------|------|--------|
-| Auto-generate matrix from test tags | Custom script parsing @req annotations | Eliminates manual mapping |
-| Matrix freshness check in CI | Script that verifies all files in matrix exist | Catches stale entries |
-| Coverage report by requirement | Map code coverage data to matrix rows | Requirement-level coverage metrics |
-| PR template with matrix check | GitHub PR template with matrix checklist | Process enforcement |

package/workflows/skills/sadd/references/verification-patterns.md

@@ -1,135 +0,0 @@
-# Verification Patterns Reference
-
-Load this when cross-referencing implementation against specifications.
-
----
-
-## Verification vs. Validation
-
-| Concept | Question | How |
-|---------|----------|-----|
-| **Verification** | "Did we build the thing right?" | Check implementation against specification. |
-| **Validation** | "Did we build the right thing?" | Check specification against user needs. |
-
-SADD focuses on verification. Validation is a product management concern.
-
----
-
-## Verification Strategies
-
-### Strategy 1: Assertion-Based Verification
-
-Compare the specification text directly to test assertions.
-
-**Specification:** "The system must return HTTP 429 when rate limit is exceeded."
-
-**Verification check:**
-- Does a test exist that triggers the rate limit?
-- Does the test assert HTTP 429 (not just "error")?
-- Does the test verify the rate limit threshold matches the spec?
-
-### Strategy 2: Behavioral Comparison
-
-Run the same inputs through the specification model and the implementation, then compare outputs.
-
-```
-Spec says: deposit($100) -> balance increases by $100
-Test does: deposit($100) -> assert balance == previous + 100
-Code does: balance += amount (after validation)
-
-Verdict: Aligned ✓
-```
-
-### Strategy 3: Contract Testing
-
-For API specifications, generate contract tests that verify request/response shapes.
-
-```markdown
-| Endpoint | Method | Request Schema Valid? | Response Schema Valid? | Status Codes Match? |
-|----------|--------|----------------------|----------------------|-------------------|
-| /users   | POST   | Yes                  | Yes                  | 201, 400, 409 ✓  |
-| /users   | GET    | Yes                  | No (missing pagination) | 200 ✓, 404 missing |
-```
-
----
-
-## Common Verification Failures
-
-### Off-by-One Errors
-
-**Spec:** "Maximum 10 items per page."
-**Implementation:** `if (items.length > 10)` (allows 11 items because > should be >=10 with slice)
-
-**Detection:** Boundary tests at exactly the specified limit.
-
-### Partial Implementation
-
-**Spec:** "Return error with code and message."
-**Implementation:** Returns error with code only; message field is always null.
-
-**Detection:** Assert on every field specified, not just the primary one.
-
-### Hardcoded Value Drift
-
-**Spec:** "Session timeout: 30 minutes."
-**Implementation:** `SESSION_TIMEOUT = 1800` (correct) but another code path uses `setTimeout(3600000)` (60 minutes).
-
-**Detection:** Search for all references to the configured value; verify consistency.
-
-### Error Path Omission
-
-**Spec:** "Return 404 when resource not found, 403 when unauthorized, 429 when rate-limited."
-**Implementation:** Handles 404 and 403; returns 500 for rate limit (unhandled exception).
-
-**Detection:** Verify every specified error code has a corresponding handler and test.
-
----
-
-## Verification Report Template
-
-```markdown
-## Verification Summary
-
-### Scope
-- Specification: [document reference]
-- Implementation: [repository and commit]
-- Date: [verification date]
-
-### Results
-| Category | Count |
-|----------|-------|
-| Requirements verified | X |
-| Requirements with failures | Y |
-| Requirements untestable | Z |
-| Specification gaps found | W |
-
-### Detailed Findings
-[One section per failure or gap with REQ ID, expected vs. actual, and recommended fix]
-
-### Verdict
-[PASS / CONDITIONAL_PASS / FAIL]
-[Conditions for conditional pass or blockers for fail]
-```
-
----
-
-## Automating Verification
-
-### For Machine-Readable Specs
-
-| Spec Format | Auto-Verification Tool |
-|------------|----------------------|
-| OpenAPI/Swagger | Schemathesis, Dredd, Prism |
-| Protocol Buffers | buf lint, buf breaking |
-| JSON Schema | ajv, jsonschema |
-| GraphQL | Apollo schema validation |
-| Database migrations | Schema diff tools |
-
-### For Human-Readable Specs
-
-Automation is limited, but you can:
-
-1. Tag requirements in the spec with IDs.
-2. Tag tests with `@req(REQ-XXX)` annotations.
-3. Run a script that cross-references tags to produce a coverage report.
-4. Integrate the coverage report into CI as a quality gate.

package/workflows/skills/sadd/references/verification.md

@@ -1,150 +0,0 @@
-# Verification Strategies
-
-Load this when verifying an implementation against extracted specifications and detecting drift.
-
----
-
-## Verification Levels
-
-| Level | What it checks | Confidence |
-|-------|---------------|------------|
-| **Static** | Code structure matches spec expectations (types, function signatures, error codes) | Medium |
-| **Dynamic** | Tests pass and cover spec assertions | High |
-| **Behavioral** | System behavior matches spec under realistic conditions | Highest |
-
----
-
-## Static Verification
-
-### Type-Level Checks
-
-Compare the specification's data model against the implementation's types.
-
-```
-Spec: "Order must have status: pending | processing | shipped | delivered | cancelled"
-
-Verify:
-- Does the code define an OrderStatus type or enum?
-- Does it include all 5 values?
-- Are there any additional values not in the spec? (drift)
-```
-
-### API Contract Checks
-
-For API specifications, verify request/response shapes.
-
-```
-Spec: POST /api/orders returns 201 with { orderId: string, status: string }
-
-Verify:
-- Does the route handler return 201?
-- Does the response schema include both fields?
-- Are field types correct?
-- Are there additional fields not in the spec? (feature drift)
-```
-
----
-
-## Dynamic Verification
-
-### Running the Spec Test Suite
-
-Execute all tests generated from specifications and map results:
-
-```markdown
-| Spec ID | Test ID | Result | Notes |
-|---------|---------|--------|-------|
-| SPEC-001 | TEST-001 | Pass | -- |
-| SPEC-002 | TEST-002 | Fail | Returns 200 instead of 201 |
-| SPEC-003 | -- | No Test | Test generation needed |
-```
-
-### Failure Classification
-
-| Failure Type | Meaning | Action |
-|-------------|---------|--------|
-| Test fails, spec correct | Implementation bug | Fix the code |
-| Test fails, spec wrong | Spec needs updating | Update spec, re-derive test |
-| Test passes, wrong assertion | Test does not actually check the spec | Rewrite test |
-| No test exists | Untested specification | Generate and run test |
-
----
-
-## Detecting Specification Drift
-
-Drift occurs when the implementation's behavior diverges from the specification over time.
-
-### Common Drift Patterns
-
-1. **Feature Drift** -- Code does more than the spec says. New behaviors were added without updating the specification.
-
-2. **Regression Drift** -- Code stopped doing what the spec says. A refactoring or dependency update broke specified behavior without being caught by tests.
-
-3. **Configuration Drift** -- Behavior varies by environment. The spec says "timeout after 30 seconds" but production config says 60 seconds.
-
-4. **Silent Drift** -- Tests pass but don't actually verify the spec. The test asserts `response.ok` instead of checking the specific status code the spec requires.
-
-### Drift Detection Technique
-
-1. Re-read the specification with fresh eyes.
-2. For each spec clause, write a new, independent verification test.
-3. Run the new tests without looking at existing tests.
-4. Compare new test results with existing test results.
-5. Discrepancies indicate drift.
-
----
-
-## Verification Report Structure
-
-```markdown
-## Verification Summary
-
-| Metric | Value |
-|--------|-------|
-| Total specifications | N |
-| Verified (pass) | X |
-| Failed | Y |
-| Untested | Z |
-| Drifted | W |
-
-## Detailed Findings
-
-### Passed Specifications
-[List with evidence]
-
-### Failed Specifications
-[Each with root cause and recommended fix]
-
-### Untested Specifications
-[Each with recommended test approach]
-
-### Detected Drift
-[Each with spec vs. actual comparison]
-```
-
----
-
-## Continuous Verification
-
-### In CI/CD Pipeline
-
-```yaml
-steps:
-  - name: Run spec verification
-    run: npm run test:spec
-
-  - name: Check spec coverage
-    run: node scripts/spec-coverage.js --threshold 95
-
-  - name: Detect drift
-    run: node scripts/drift-check.js --baseline specs/
-```
-
-### On Requirement Change
-
-When a specification changes:
-1. Mark affected matrix entries as "needs re-verification."
-2. Update or regenerate affected tests.
-3. Run verification.
-4. Update matrix with new results.
-5. Include matrix diff in the PR.

package/workflows/skills/sanitize-pii/SKILL.md

@@ -1,100 +0,0 @@
----
-name: sanitize-pii
-description: "Detect and sanitize personally identifiable information (PII) in code, logs, databases, and data pipelines. Covers PII identification, redaction strategies, data masking, GDPR/CCPA compliance, and audit trail implementation."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: "Claude Code, Codex, GitHub Copilot"
----
-
-# Sanitize PII — PII Detection and Sanitization
-
-## Purpose
-
-Guide the detection, classification, and sanitization of personally identifiable information across application code, log outputs, database schemas, and data pipelines. This skill ensures that PII handling meets GDPR, CCPA, and other privacy regulation requirements through systematic identification, consistent redaction, reversible masking where needed, and auditable compliance controls.
-
-## When to Use
-
-- Scanning log output or application telemetry for accidental PII exposure
-- Implementing data masking for non-production environments
-- Building PII redaction into data pipelines or ETL processes
-- Conducting a GDPR or CCPA compliance review of data handling
-- Designing audit trails for PII access and processing
-- Reviewing code for patterns that inadvertently persist or transmit PII
-
-## Instructions
-
-1. **Define the PII taxonomy for the project** — Enumerate all PII categories relevant to the application (names, emails, phone numbers, SSNs, IP addresses, geolocation, biometrics, financial data, health records) because the definition of PII varies by jurisdiction and incomplete taxonomy leads to incomplete protection.
-
-2. **Map PII data flows** — Trace each PII category from point of collection through storage, processing, transmission, and deletion to identify every location where PII exists because you cannot sanitize data you have not located.
-
-3. **Classify PII by sensitivity tier** — Assign each category a sensitivity level (direct identifiers like SSN/passport = critical; quasi-identifiers like ZIP+DOB = high; general contact info = standard) because sensitivity drives the required protection strength and breach notification obligations.
-
-4. **Scan source code for PII patterns** — Use regex patterns and AST analysis to find logging statements, string interpolation, serialization, and debug output that may include PII fields because developers frequently log user objects without redacting sensitive fields.
-
-5. **Scan log output and telemetry** — Review structured and unstructured logs for PII leakage including email addresses in error messages, user IDs in URLs, and stack traces containing request bodies because logs are often stored with weaker access controls than databases.
-
-6. **Implement field-level redaction** — Apply deterministic redaction (consistent replacement tokens) or destructive redaction (irreversible removal) to PII in logs, exports, and non-production data because redaction prevents PII from reaching unauthorized storage while preserving data utility.
-
-7. **Implement data masking for non-production environments** — Use format-preserving encryption, tokenization, or synthetic data generation to create realistic but non-identifying datasets because developers and testers need representative data without real PII.
-
-8. **Build PII-aware logging utilities** — Create or configure logging middleware that automatically redacts known PII fields before writing because relying on individual developers to remember redaction is unreliable at scale.
-
-9. **Implement right-to-erasure (GDPR Article 17) support** — Design deletion workflows that remove or anonymize all instances of a data subject's PII across all storage systems including backups, caches, and derived datasets because GDPR requires complete erasure upon valid request.
-
-10. **Implement data subject access requests (DSAR)** — Build the ability to export all PII associated with a data subject in a portable format because GDPR Article 15 and CCPA Section 1798.100 require this capability.
-
-11. **Configure consent and purpose tracking** — Record the legal basis (consent, legitimate interest, contract) and processing purpose for each PII collection point because GDPR Article 6 requires a lawful basis and purpose limitation for all personal data processing.
-
-12. **Set up PII access audit trails** — Log every read, write, export, and deletion of PII with actor identity, timestamp, purpose, and data categories accessed because audit trails demonstrate compliance and enable breach impact assessment.
-
-13. **Implement retention and auto-deletion policies** — Configure time-based or event-based deletion for each PII category according to the data retention schedule because storing PII beyond its purpose violates the storage limitation principle.
-
-14. **Validate PII sanitization with automated tests** — Write tests that assert PII fields are redacted in log output, masked in non-production exports, and absent from API responses that should not contain them because manual verification does not scale.
-
-15. **Document the PII handling architecture** — Produce a data protection impact assessment (DPIA) or privacy design document covering data flows, protection measures, retention periods, and compliance mapping because documentation is itself a regulatory requirement.
-
-16. **Establish breach notification procedures** — Define the workflow for identifying, assessing, and reporting PII breaches within the 72-hour GDPR window including impact assessment, authority notification, and data subject communication because delayed notification incurs significant regulatory penalties.
-
-## Output Format
-
-```
-## PII Sanitization Report
-
-### PII Taxonomy
-| Category | Sensitivity | Locations Found | Protection Method |
-|----------|------------|-----------------|-------------------|
-| Email | Standard | user_service, logs, analytics | Redact in logs, encrypt at rest |
-| SSN | Critical | payroll_service | Tokenize, vault storage |
-
-### Data Flow Map
-[Collection → Processing → Storage → Transmission → Deletion per category]
-
-### Findings
-
-| # | Location | PII Type | Issue | Severity | Remediation |
-|---|----------|----------|-------|----------|-------------|
-| 1 | logger.js:42 | Email | Logged in plaintext | High | Add to redaction filter |
-
-### Compliance Status
-| Requirement | GDPR Article | Status | Gap |
-|-------------|-------------|--------|-----|
-| Right to erasure | Art. 17 | Partial | Backups not covered |
-
-### Remediation Plan
-[Priority-ordered action items with implementation guidance]
-
-### Audit Trail Configuration
-[What is logged, where, retention period]
-```
-
-## References
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| PII Detection Patterns | `references/pii-detection.md` | Scanning code or logs for PII |
-| Redaction Strategies | `references/redaction-strategies.md` | Implementing field-level redaction |
-| Data Masking Techniques | `references/data-masking.md` | Creating non-production datasets |
-| GDPR/CCPA Compliance | `references/compliance.md` | Reviewing regulatory requirements |
-| Audit Trail Design | `references/audit-trails.md` | Implementing PII access logging |

package/workflows/skills/sanitize-pii/evals/assertions.md

@@ -1,25 +0,0 @@
-# Eval Assertions — Sanitize PII
-
-## Eval 1: PII Detection in Log Output
-
-**ID:** `pii-detection-log-output`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `email\|john\\.doe@\|email address` | Must identify the email address in the UserService log line as PII requiring redaction. |
-| 2 | content_matches_regex | `credit card\|card number\|PAN\|4111\|CVV\|payment card` | Must identify the full credit card number and CVV as critical PII — a PCI DSS violation. |
-| 3 | content_matches_regex | `SSN\|Social Security\|123-45-6789` | Must identify the SSN as critical PII with the highest sensitivity classification. |
-| 4 | content_matches_regex | `redact\|mask\|filter\|sanitiz\|replace\|\\*{3,}\|\\[REDACTED\\]` | Must recommend a specific redaction or masking technique rather than just flagging the issue. |
-| 5 | content_matches_regex | `API key\|sk_live\|secret\|credential\|token` | Must identify the exposed Stripe API key as both a PII and credential leak requiring rotation. |
-
-## Eval 2: GDPR-Compliant Data Masking
-
-**ID:** `gdpr-data-masking`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `GDPR\|Article\|regulation\|data protection\|lawful` | Must ground the masking strategy in GDPR requirements since the application serves EU customers. |
-| 2 | content_matches_regex | `email.*mask\|mask.*email\|fake.*email\|synthetic.*email\|anonymiz` | Must specify a concrete masking strategy for email addresses that preserves format but removes identity. |
-| 3 | content_matches_regex | `format.preserv\|tokeniz\|synthetic\|faker\|fake data\|realistic` | Must recommend format-preserving masking or synthetic data generation for realistic non-production data. |
-| 4 | content_matches_regex | `free.text\|support_ticket\|body\|unstructured\|ticket.*body\|agent.*notes` | Must address free-text fields which cannot be masked with simple find-replace and require NLP or full replacement. |
-| 5 | content_matches_regex | `referential integrity\|foreign key\|user_id\|relationship\|consistent` | Must address referential integrity to ensure masked data remains consistent across related tables. |