neotoma 0.3.0 → 0.3.2

package/.cursor/rules/instruction_documentation.mdc

@@ -1,296 +0,0 @@
----
-description: "When user says 'always X' or 'never Y', or when creating/editing rule or command files: document the instruction in the correct rule file (foundation vs repo), use RFC 2119, run setup_cursor_copies after editing. Load when documenting constraints, adding rules, or editing .cursor/rules or foundation/agent_instructions sources."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/instruction_documentation.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/instruction_documentation.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/instruction_documentation.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-
-# Instruction Documentation Rule
-
-_(Cursor Rule: Agent Behavior)_
-
----
-
-## Purpose
-
-This document defines how agents MUST document important instructions, constraints, and guidelines in appropriate files. It ensures all instructions are available to Cursor agents via the symlinked rule structure, avoiding single points of failure.
-
-## Scope
-
-This rule covers:
-
-- When and how to document "always" and "never" instructions
-- Where to place rules (global vs repository-specific)
-- How rules are discovered via symlink structure
-- Format standards for rule files
-
-This rule does NOT cover:
-
-- Content of specific rules (covered by individual rule files)
-- Documentation standards for non-rule documentation (see `foundation/conventions/documentation_standards.md`)
-
-## Configuration
-
-All instructions are Cursor rules, stored in two scopes:
-
-```yaml
-cursor_rules:
-  # Global rules (for all repos using foundation)
-  global:
-    enabled: true
-    location: "foundation/agent_instructions/cursor_rules/"
-
-  # Repository-specific rules (for this repo only)
-  repository:
-    enabled: true
-    # Examples of common locations (choose appropriate docs/ subdirectory based on topic):
-    example_locations:
-      - "docs/conventions/" # Code and documentation conventions
-      - "docs/foundation/" # Foundation and architectural rules
-      - "docs/feature_units/standards/" # Feature unit workflow rules
-      - "docs/developer/" # Development workflow rules
-```
-
-**Note:** All `*_rules.md` files in `docs/` are automatically symlinked to `.cursor/rules/` via the setup script. No central reference file is needed. Rules are discoverable via the symlink structure.
-
-## Trigger Patterns
-
-Agents MUST document instructions immediately during the same conversation, before proceeding with other work.
-
-**High-priority triggers:**
-
-- "always do X" or "never do Y"
-- "remember to" or "make sure to"
-- "all agents should" or "everyone must"
-
-**Standard triggers:**
-
-- Code style, patterns, conventions
-- Architectural constraints or boundaries
-- Workflow processes or procedures
-- Testing requirements or standards
-- Documentation standards
-- Security or privacy requirements
-- Error handling or validation rules
-- Repository-wide policies
-
-## Meta-Rule: Creating Rules
-
-When user says "always X" or "never Y", agents MUST:
-
-1. Recognize as rule creation request (all rules are Cursor rules)
-2. Determine scope:
-   - **Global rule** (benefits all repos using foundation): `foundation/agent_instructions/cursor_rules/{topic}.mdc` (MUST use `.mdc` extension)
-   - **Repository rule** (this repo only): Place in appropriate `docs/` subdirectory based on topic. MUST NOT use `.cursor/rules/`
-     - Examples (choose subdirectory that best matches rule's topic):
-       - Code/documentation conventions → `docs/conventions/{topic}_rules.md`
-       - Foundation/architectural → `docs/foundation/{topic}_rules.md`
-       - Feature unit workflows → `docs/feature_units/standards/{topic}_rules.md`
-       - Development workflows → `docs/developer/{topic}_rules.md`
-3. Create rule immediately without asking for confirmation
-4. Update references (foundation README for global rules, repo docs for repository rules)
-
-**Decision tree:**
-
-- Benefits ALL repos using foundation → Global rule (`foundation/agent_instructions/cursor_rules/`)
-- Generic agent behavior → Global rule (`foundation/agent_instructions/cursor_rules/`)
-- Repository-specific domain/architecture → Repository rule (appropriate `docs/` subdirectory)
-- Project-specific features/constraints → Repository rule (appropriate `docs/` subdirectory)
-
-## Instruction Classification
-
-Rules are classified by scope and topic:
-
-**Global rules:**
-
-- Location: `foundation/agent_instructions/cursor_rules/`
-- Scope: All repos using foundation
-- Examples: Generic agent behavior, cross-repo patterns
-
-**Repository rules:**
-
-- Location: Appropriate `docs/` subdirectory based on topic
-- Scope: This repo only
-- Examples:
-  - Workflow/process instructions → `docs/feature_units/standards/` or `docs/developer/`
-  - Architectural constraints → `docs/foundation/` or `docs/architecture/`
-  - Code conventions → `docs/conventions/`
-- MUST NOT use `.cursor/rules/` directly (rules are symlinked automatically)
-
-## Documenting Instructions
-
-**For repository-wide agent instructions:**
-
-1. Search `docs/` for existing `*_rules.md` files that match the instruction topic
-2. Add instruction to appropriate rule file using RFC 2119 directive language
-3. Create new rule file if no appropriate existing file exists (see "For Cursor rules" below)
-
-**For Cursor rules (all rules are Cursor rules):**
-
-1. Determine scope:
-   - **Global rule** (all repos) → `foundation/agent_instructions/cursor_rules/{topic}.mdc` (MUST use `.mdc` extension)
-   - **Repository rule** (this repo) → `docs/{appropriate_subdirectory}/{topic}_rules.md` based on topic
-     - Examples (choose subdirectory that best matches rule's topic):
-       - Code/documentation conventions → `docs/conventions/`
-       - Foundation/architectural → `docs/foundation/`
-       - Feature unit workflows → `docs/feature_units/standards/`
-       - Development workflows → `docs/developer/`
-2. MUST NOT use `.cursor/rules/` directly
-3. Use filename:
-   - Foundation rules: `{topic}.mdc` or `{topic}_management.mdc` (MUST use `.mdc`)
-   - Repository rules: `{topic}_rules.md` or `{topic}_management.md`
-4. Follow existing rule format (Purpose, Trigger Patterns, Agent Actions, Constraints)
-5. Update references if applicable
-
-**For documentation-only instructions (not rules):**
-
-1. Document in appropriate `docs/` subdirectory based on topic
-2. MUST NOT store documentation in repo root
-3. Store temporary assessment/analysis files in `tmp/` directory
-4. Update references if applicable
-
-## Format Standards
-
-**Cursor rule format (MUST follow this structure):**
-
-```markdown
-# Rule Title
-
-## Purpose
-
-Clear statement of what this rule ensures.
-
-## Trigger Patterns
-
-When [conditions], agents MUST [action].
-
-## Agent Actions
-
-### Step 1: [Action]
-
-1. [Specific action]
-2. [Specific action]
-
-## Constraints
-
-- MUST / MUST NOT statements (per RFC 2119)
-- ALWAYS / NEVER statements
-```
-
-**Language requirements:**
-
-- Use RFC 2119 terminology: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY
-- Use directive tone: clear, unambiguous statements
-- MUST NOT use vague qualifiers: "maybe", "perhaps", "possibly"
-- MUST NOT use marketing language: "powerful", "seamless", "revolutionary"
-- Use simple, declarative sentences with active voice
-
-## Workflow
-
-When user provides instructions (especially "always" or "never"), agents MUST:
-
-1. Detect trigger pattern
-2. Acknowledge: "Documenting instruction permanently in [location]"
-3. Classify instruction type and determine rule scope (apply Meta-Rule above)
-4. Document immediately (same conversation):
-   - Read target documentation file if it exists
-   - Add instruction using proper format
-   - Create or update rule file if needed
-   - Update references if new rule created
-   - Use directive language per RFC 2119 (MUST/SHOULD/MUST NOT/ALWAYS/NEVER)
-5. Update downstream documentation if applicable (see `downstream_doc_updates.md`)
-6. Confirm completion with details
-
-**MUST NOT:**
-
-- Skip documentation and proceed with other work
-- Promise to document "later" or in future conversation
-- Document only in conversation memory
-- Assume instruction is temporary
-
-**Before starting work:**
-
-1. Load required rules (rule files from symlinked locations)
-2. Verify instructions are current
-
-## Constraints
-
-Agents MUST:
-
-- Document "always" and "never" instructions immediately during same conversation
-- Classify instruction type before documenting
-- Use directive language per RFC 2119 (MUST/SHOULD/MUST NOT/ALWAYS/NEVER)
-- Ensure instructions are discoverable via symlink structure (global: `foundation/agent_instructions/cursor_rules/`, repository: `docs/` subdirectories)
-- Update downstream documentation when upstream docs change
-- Store temporary assessment/analysis files in `tmp/` directory
-
-Agents MUST NOT:
-
-- Defer documentation to future conversation
-- Document only in conversation memory
-- Duplicate instructions across multiple files without cross-references
-- Store documentation files in repo root
-- Store temporary assessment/analysis files in `docs/`
-- Use `.cursor/rules/` directly (rules are symlinked automatically)
-
-## Availability
-
-Cursor agents automatically have access to all rules via symlink structure:
-
-1. **Global rules**: `foundation/agent_instructions/cursor_rules/` files are symlinked to `.cursor/rules/` with `foundation_` prefix
-2. **Repository rules**: All `*_rules.md` files in `docs/` subdirectories are automatically symlinked to `.cursor/rules/` via setup script
-3. **No central reference file needed**: Rules are discoverable directly via symlink structure
-
----
-
-## Agent Instructions
-
-### When to Load This Document
-
-Load this document when:
-
-- User provides "always" or "never" instructions
-- Creating or updating rule files
-- Determining where to place new instructions
-- Reviewing rule structure and organization
-
-### Required Co-Loaded Documents
-
-- `foundation/conventions/documentation_standards.md` (for format standards)
-
-### Constraints Agents Must Enforce
-
-1. All "always" and "never" instructions MUST be documented immediately in same conversation
-2. Rules MUST use RFC 2119 terminology (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY)
-3. Rules MUST follow the format structure defined in Format Standards section
-4. Repository rules MUST be placed in appropriate `docs/` subdirectory based on topic
-5. Global rules MUST be placed in `foundation/agent_instructions/cursor_rules/`
-6. Agents MUST NOT use `.cursor/rules/` directly (rules are symlinked automatically)
-7. Agents MUST NOT defer documentation to future conversations
-
-### Forbidden Patterns
-
-- Documenting instructions only in conversation memory
-- Creating rules in `.cursor/rules/` directly
-- Using vague language instead of RFC 2119 terminology
-- Deferring rule creation to later conversations
-- Duplicating instructions across multiple files without cross-references
-
-### Validation Checklist
-
-- [ ] Rule file follows format structure (Purpose, Trigger Patterns, Agent Actions, Constraints)
-- [ ] Rule uses RFC 2119 terminology correctly
-- [ ] Rule is placed in correct location (global vs repository, appropriate subdirectory)
-- [ ] Rule file uses `*_rules.md` naming convention
-- [ ] No references to non-existent central reference files
-- [ ] Instructions documented immediately during same conversation

package/.cursor/rules/risk_management.mdc

@@ -1,179 +0,0 @@
----
-description: "Load when considering schema changes, foundation doc changes, security/auth changes, or constraint violations: stop and request approval for high-risk changes; explain risk and get explicit confirmation before proceeding."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/risk_management.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/risk_management.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/risk_management.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Risk Management and Hold Points Rule
-
-**Reference:** `foundation/conventions/documentation-standards.md` - Documentation standards
-
-## Purpose
-
-Ensures agents stop and request human approval for high-risk changes that could impact system stability, security, or architectural integrity.
-
-## Scope
-
-This document defines:
-- When agents MUST stop and request approval
-- Risk levels (Low/Medium/High)
-- Hold point triggers
-- Approval workflow
-
-This document does NOT cover:
-- Specific constraints agents must enforce (see `agent_constraints.md`)
-- Security audit requirements (see `security.md`)
-- Repository-specific risk classification (configured in `foundation-config.yaml`)
-
-## Configuration
-
-Configure risk classification in `foundation-config.yaml`:
-
-```yaml
-risk_management:
-  enabled: true
-  risk_classification_path: "docs/private/governance/risk_classification.md"  # Optional
-  foundation_docs_path: "docs/foundation/"  # Path to foundation documents
-  high_risk_paths: []  # Repository-specific high-risk paths
-    # Example:
-    # - "docs/foundation/"
-    # - "src/auth/"
-```
-
-## When Agents MUST Stop
-
-AI assistants MUST stop and request human approval for:
-
-1. **Schema changes** (table structure, breaking data model changes)
-2. **High-risk changes** (see configured risk classification path if exists)
-3. **Foundation document changes** (files in configured foundation docs path)
-4. **Security changes** (auth, access control, encryption)
-5. **Violating documented constraints** (even if user requests)
-
-## Risk Levels
-
-### Low Risk
-
-- Documentation updates
-- UI text changes
-- Unit test additions
-- Non-breaking API additions
-- Feature additions within existing scope
-
-**Action:** Proceed with standard validation checklist
-
-### Medium Risk
-
-- New features within scope
-- API endpoint additions
-- Logic changes in non-critical paths
-- Subsystem modifications
-- Configuration changes
-
-**Action:** Proceed with enhanced validation, notify user of scope
-
-### High Risk
-
-- Schema migrations
-- Auth changes
-- Breaking API changes
-- Foundation document modifications (files in configured foundation docs path)
-- Security changes
-- Architectural changes
-- Changes that violate documented constraints
-
-**Action:** **STOP** and request explicit user approval before proceeding
-
-## Hold Point Triggers
-
-Agents MUST stop and request approval when encountering:
-
-1. **Schema modifications:**
-   - Adding/removing columns
-   - Changing column types
-   - Modifying JSONB structure
-   - Breaking migrations
-
-2. **Foundation document changes:**
-   - Modifying files in configured foundation docs path (default: `docs/foundation/`)
-   - Changing core philosophy or principles
-   - Updating architectural invariants
-
-3. **Security-sensitive changes:**
-   - Authentication/authorization logic
-   - Access control policy changes
-   - Encryption/decryption logic
-   - Credential handling
-
-4. **Constraint violations:**
-   - User requests that violate architectural boundaries
-   - Requests for nondeterministic features
-   - Features outside project scope
-   - Breaking immutability or data integrity requirements
-
-5. **Architectural changes:**
-   - Layer boundary modifications
-   - Consistency model changes
-   - Data structure changes
-   - Core system pattern modifications
-
-## Approval Workflow
-
-When a hold point is triggered:
-
-1. **STOP all work immediately**
-2. **Identify the risk level** (Low/Medium/High)
-3. **Explain the risk** to the user
-4. **Request explicit approval** before proceeding
-5. **Document the approval** in conversation
-6. **Proceed only after approval** is received
-
-### Example Hold Point Message
-
-```
-⚠️ HOLD POINT: High-Risk Change Detected
-
-I've identified a high-risk change that requires your approval:
-
-[Description of change]
-
-Risk Level: High
-Reason: [Schema change / Foundation doc / Security / Constraint violation]
-
-This change could impact:
-- [List potential impacts]
-
-Do you want me to proceed with this change? Please confirm explicitly.
-```
-
-## Exception Handling
-
-**No exceptions for high-risk changes.** Even if the user requests a change, agents MUST:
-
-1. Identify if it's high-risk
-2. Stop and explain the risk
-3. Request explicit approval
-4. Document the approval
-5. Proceed only after confirmation
-
-**For constraint violations:** Agents MUST refuse to proceed even with approval, explaining why the constraint cannot be violated.
-
-## Related Documents
-
-- `foundation/conventions/documentation-standards.md` - Documentation standards
-- `foundation-config.yaml` - Repository-specific configuration
-- Repository foundation docs (e.g., `docs/foundation/philosophy.md`) - Architectural invariants
-- Repository risk classification (if configured) - Detailed risk classification
-- `.cursor/rules/foundation-agent_constraints.md` - Constraints and forbidden patterns
-- `.cursor/rules/foundation-security.md` - Security audit requirements
-

package/.cursor/rules/security.mdc

@@ -1,177 +0,0 @@
----
-description: "Load when committing, configuring pre-commit, or adding protected paths: security audit blocks commits of protected_paths, .env*, data/; gitleaks scans for credentials; do not bypass hooks."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/security.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/security.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/security.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Security Rule
-
-Prevents accidental commits of private, sensitive, or confidential documentation and data.
-
-Configuration: This rule uses protected paths configured in `foundation-config.yaml` under `security.pre_commit_audit.protected_paths`.
-
-## Pre-Commit Security Audit
-
-**Implementation:** The security audit is enforced by `scripts/linters/security_audit.py` and configured in `.pre-commit-config.yaml` under the `security-audit` hook.
-
-**Configuration:** All settings are in `foundation-config.yaml` under `security.pre_commit_audit`:
-- `protected_paths` — paths that must never be committed
-- `check_env_files` — enable/disable .env file checking
-- `check_data_directory` — enable/disable data/ directory checking
-- Secrets detection is handled by gitleaks (separate hook)
-
-### Checks Performed
-
-The pre-commit hook (`scripts/linters/security_audit.py`) performs:
-
-1. **Protected Paths Check** — Checks staged and unstaged files against configured `protected_paths`
-2. **Environment Files Check** — Detects `.env*` files (if `check_env_files: true`)
-3. **Data Directory Check** — Detects files in `data/` or `$DATA_DIR/` (if `check_data_directory: true`)
-
-**Gitleaks** (separate hook in `.pre-commit-config.yaml`) handles:
-
-4. **Hardcoded Credentials Scan** — Scans for API keys, passwords, secrets, tokens in staged files
-
-### Security Audit Execution
-
-The security audit runs automatically before every commit via pre-commit hooks:
-
-```bash
-# Runs automatically on commit
-git commit -m "message"
-
-# Or manually via pre-commit
-pre-commit run security-audit --all-files
-pre-commit run gitleaks --all-files
-
-```bash
-#!/bin/bash
-set -e
-
-echo "🔒 Running pre-commit security audit..."
-
-# Load protected paths from foundation-config.yaml
-# (Implementation depends on YAML parsing - use yq, python, or node)
-PROTECTED_PATHS=($(yq eval '.security.pre_commit_audit.protected_paths[]' foundation-config.yaml 2>/dev/null || echo ""))
-
-# Check 1: Protected paths
-for path in "${PROTECTED_PATHS[@]}"; do
-  if git status --porcelain | grep -E "^[AM]|^\?\?" | grep -qE "$path"; then
-    echo "❌ SECURITY VIOLATION: Files in $path detected!"
-    echo "Files:"
-    git status --porcelain | grep -E "^[AM]|^\?\?" | grep "$path"
-    exit 1
-  fi
-
-  if git diff --cached --name-only 2>/dev/null | grep -qE "$path"; then
-    echo "❌ SECURITY VIOLATION: Files in $path already staged!"
-    echo "Files:"
-    git diff --cached --name-only | grep "$path"
-    exit 1
-  fi
-done
-
-# Check 2: Environment files (if enabled)
-if yq eval '.security.pre_commit_audit.check_env_files' foundation-config.yaml 2>/dev/null | grep -q "true"; then
-  if git status --porcelain | grep -qE "\.env"; then
-    echo "❌ SECURITY VIOLATION: .env files detected!"
-    git status --porcelain | grep "\.env"
-    exit 1
-  fi
-
-  if git diff --cached --name-only 2>/dev/null | grep -qE "\.env"; then
-    echo "❌ SECURITY VIOLATION: .env files already staged!"
-    git diff --cached --name-only | grep "\.env"
-    exit 1
-  fi
-fi
-
-# Check 3: Data directory (if enabled)
-if yq eval '.security.pre_commit_audit.check_data_directory' foundation-config.yaml 2>/dev/null | grep -q "true"; then
-  if git status --porcelain | grep -E "^[AM]|^\?\?" | grep -qE "^data/"; then
-    echo "❌ SECURITY VIOLATION: Files in data/ directory detected!"
-    git status --porcelain | grep -E "^[AM]|^\?\?" | grep "^data/"
-    exit 1
-  fi
-
-  if git diff --cached --name-only 2>/dev/null | grep -qE "^data/"; then
-    echo "❌ SECURITY VIOLATION: Files in data/ directory already staged!"
-    git diff --cached --name-only | grep "^data/"
-    exit 1
-  fi
-fi
-
-echo "✅ Security audit passed"
-```
-
-### Agent Responsibilities
-
-Agents MUST NOT:
-- Bypass or skip the pre-commit security audit
-- Commit files in protected paths
-- Suggest workarounds to security checks
-- Use `--no-verify` flag to skip hooks
-
-Agents SHOULD:
-- Respect the pre-commit hook enforcement
-- Alert user if security violations are detected during normal operations
-- Recommend fixing violations (moving files, updating .gitignore) rather than bypassing checks
-
-## Enforcement
-
-The security audit is enforced automatically by pre-commit hooks:
-- Runs on every `git commit`
-- Cannot be bypassed without explicit `--no-verify` flag
-- Configuration-driven via `foundation-config.yaml`
-
-## Failure Behavior
-
-If the security audit hook fails:
-1. Commit is blocked
-2. Clear error message displays with violating files
-3. User must resolve violations (remove files, update .gitignore, or exclude from commit)
-4. Commit again after resolving
-
-## Configuration
-
-All security audit configuration is in `foundation-config.yaml`:
-
-```yaml
-security:
-  pre_commit_audit:
-    enabled: true
-    protected_paths:
-      - "$DATA_DIR/imports/"
-      - "$DATA_DIR/attachments/"
-      - "docs/private/"
-      - ".env*"
-    check_env_files: true
-    check_data_directory: true
-```
-
-See `foundation-config.yaml` in your repository for the actual configuration.
-
-## Related Files
-
-- `scripts/linters/security_audit.py` — Security audit implementation
-- `.pre-commit-config.yaml` — Hook configuration (security-audit and gitleaks)
-- `.gitleaks.toml` — Gitleaks configuration for credential scanning
-
-
-
-
-
-
-
-
-

package/.cursor/skipped_records/companies_skipped.json

@@ -1,27 +0,0 @@
-{
-  "batch_id": "batch_01_companies",
-  "data_type": "companies",
-  "total_skipped": 19,
-  "reason": "empty_name_field",
-  "skipped_records": [
-    {"company_id": "159.203.91.199", "reason": "empty name field"},
-    {"company_id": "192.168.0.1", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_1", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_2", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_3", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_4", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_5", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_6", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_7", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_8", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_9", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_10", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_11", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_12", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_13", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_14", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_15", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_16", "reason": "empty name field"},
-    {"company_id": "company_with_empty_name_17", "reason": "empty name field"}
-  ]
-}