neotoma 0.3.0 → 0.3.2

package/docs/conventions/code_conventions_plan.md

@@ -1,124 +0,0 @@
-# Code Conventions Documentation Plan
-## Overview
-Create `docs/conventions/code_conventions.md` that defines code style, naming, organization, and patterns for all languages used in Neotoma. The document will reference existing standards (determinism, error handling, testing, architecture) and provide detailed examples.
-## Languages to Cover
-1. **TypeScript/TSX** (primary language)
-2. **SQL** (migrations and schema)
-3. **YAML** (manifests, configs)
-4. **Shell scripts** (automation)
-## Document Structure
-Following `docs/conventions/documentation_standards.md` format:
-1. **Purpose & Scope** — What's covered, what's not
-2. **Foundational References** — Links to existing standards (determinism, errors, testing, architecture)
-3. **TypeScript/TSX Conventions**
-- Naming (files, functions, types, variables, constants)
-- Code organization (imports, exports, file structure)
-- Type definitions (interfaces vs types, generics)
-- Error handling (ErrorEnvelope pattern, error propagation)
-- Async/await patterns
-- Determinism requirements (no randomness, deterministic IDs)
-- Testing patterns (test structure, fixtures)
-- Comments and documentation
-4. **SQL Conventions**
-- Naming (tables, columns, indexes, constraints)
-- Migration structure (header comments, rollback)
-- RLS policies (naming, structure)
-- Index patterns
-- Deterministic patterns (no random UUIDs, hash-based IDs)
-5. **YAML Conventions**
-- Structure (indentation, keys, values)
-- Manifest patterns (feature units, releases)
-- Config patterns
-- Comments and documentation
-6. **Shell Script Conventions**
-- Shebang and error handling
-- Variable naming
-- Function patterns
-- Exit codes
-7. **Cross-Language Patterns**
-- Determinism (references to determinism.md)
-- Error codes (references to error_codes.md)
-- Testing integration (references to testing_standard.md)
-8. **Agent Instructions** — When to load, constraints, forbidden patterns
-## Key Standards to Reference
-- `docs/architecture/determinism.md` — Deterministic patterns, no randomness
-- `docs/subsystems/errors.md` — ErrorEnvelope structure, error propagation
-- `docs/testing/testing_standard.md` — Test structure, fixtures
-- `docs/architecture/architecture.md` — Layer boundaries, error propagation
-- `docs/reference/error_codes.md` — Canonical error codes
-- `.eslintrc.json` — ESLint rules
-- `tsconfig.json` — TypeScript strict mode
-## Implementation Details
-### TypeScript Section Should Include:
-- **Naming:**
-- Files: `kebab-case.ts` (e.g., `entity_resolution.ts`)
-- Functions: `camelCase` (e.g., `generateEntityId`)
-- Types/Interfaces: `PascalCase` (e.g., `Entity`, `ErrorEnvelope`)
-- Constants: `UPPER_SNAKE_CASE` (e.g., `MAX_FILE_SIZE`)
-- Private members: `_leadingUnderscore` (if needed)
-- **Code Organization:**
-- Import order: external → internal → relative
-- Export patterns: named exports preferred
-- File structure: one main export per file, or index.ts barrel
-- **Type Patterns:**
-- Prefer `interface` for object shapes, `type` for unions/intersections
-- Use generics for reusable patterns
-- Avoid `any`, use `unknown` for truly unknown types
-- **Error Handling:**
-- Domain layer throws typed errors
-- Application layer catches and converts to ErrorEnvelope
-- Reference `docs/subsystems/errors.md` for structure
-- **Determinism:**
-- No `Math.random()`, `Date.now()` (unless explicit input)
-- Hash-based IDs (reference determinism.md)
-- Deterministic sorting
-- **Testing:**
-- Test file: `*.test.ts` alongside source
-- Test structure: describe → test → expect
-- Fixtures: reference `docs/testing/fixtures_standard.md`
-### SQL Section Should Include:
-- **Naming:**
-- Tables: `snake_case` (e.g., `entities`, `timeline_events`)
-- Columns: `snake_case` (e.g., `entity_type`, `canonical_name`)
-- Indexes: `idx_{table}_{columns}` (e.g., `idx_entities_type_name`)
-- Constraints: descriptive names (e.g., `entities_pkey`)
-- **Migration Structure:**
-- Header comment with migration name, date, description
-- Feature Unit reference (e.g., `-- Migration: Add entities table (FU-101)`)
-- RLS policies with descriptive names
-- Table comments explaining purpose
-- **Determinism:**
-- No `gen_random_uuid()` for entity IDs
-- Hash-based IDs (reference determinism.md)
-- Deterministic default values
-### YAML Section Should Include:
-- **Structure:**
-- 2-space indentation
-- Keys: `snake_case` (e.g., `feature_id`, `schema_changes`)
-- Lists: use `-` for items
-- Comments: `#` for explanations
-- **Manifest Patterns:**
-- Reference existing manifest.yaml examples
-- Required fields per manifest type
-- Nested structure conventions
-### Shell Script Section Should Include:
-- **Structure:**
-- Shebang: `#!/bin/bash` or `#!/usr/bin/env bash`
-- `set -euo pipefail` for error handling
-- Function naming: `camelCase` or `snake_case` (be consistent)
-- Exit codes: 0 success, non-zero failure
-## Files to Create/Modify
-1. **Create:** `docs/conventions/code_conventions.md`
-2. **Update:** `docs/conventions/documentation_standards.md` — Add reference to code conventions
-3. **Update:** Foundation rules in `.cursor/rules/` — Add code conventions reference if needed
-4. **Update:** `.cursor/rules/instruction_documentation.md` — Ensure code conventions location is correct
-## Examples to Include
-- TypeScript: Function with error handling, type definition, test structure
-- SQL: Complete migration example with RLS, indexes, comments
-- YAML: Feature unit manifest example
-- Shell: Script with error handling and functions
-## Validation
-- Follows `docs/conventions/documentation_standards.md` structure
-- References existing standards (determinism, errors, testing)
-- Includes Agent Instructions section
-- Provides concrete examples for each language

package/docs/conventions/code_review_summary.md

@@ -1,96 +0,0 @@
-# Code Conventions Review Summary
-## Overview
-Reviewed the Neotoma codebase against the newly established code conventions in `docs/conventions/code_conventions.md`.
-## Findings
-### ✅ Already Following Conventions
-1. **React Component Naming** — All React components use PascalCase (`.tsx` files)
-   - Examples: `MockChatPanel.tsx`, `SettingsView.tsx`, `Dashboard.tsx`, `RecordsTable.tsx`
-2. **Non-Component Files** — Backend modules use snake_case
-   - Examples: `entity_resolution.ts`, `event_emitter.ts`, `graph_builder.ts`
-3. **Function Naming** — Consistent camelCase usage
-   - Examples: `generateEntityId()`, `normalizeEntityValue()`, `resolveEntity()`
-4. **Type/Interface Naming** — Consistent PascalCase
-   - Examples: `Entity`, `ErrorEnvelope`, `StateEvent`, `NeotomaRecord`
-5. **Constants** — Proper UPPER_SNAKE_CASE
-   - Examples: `MAX_FILE_SIZE`, `DEFAULT_PAGE_SIZE`
-6. **SQL Naming** — Consistent snake_case for tables, columns, indexes
-   - Tables: `entities`, `timeline_events`, `state_events`
-   - Columns: `entity_type`, `canonical_name`, `created_at`
-   - Indexes: `idx_entities_type`, `idx_entities_type_name`
-7. **File Structure** — Proper import ordering and organization
-   - External dependencies → Internal modules → Relative imports
-### ⚠️ Needs Updating
-1. **String Quotes** — **146 imports with single quotes across 58 files**
-   - Current: Mix of single (`'`) and double (`"`) quotes
-   - Required: Double quotes (`"`) for all strings
-   - Affected files include:
-     - `src/events/` (event_emitter.ts, event_log.ts, replay.ts, event_validator.ts)
-     - `src/reducers/` (reducer_registry.ts, record_reducer.ts)
-     - `src/repositories/` (db and file implementations)
-     - `src/integrations/` (providers, plaid)
-     - `src/services/` (multiple service files)
-     - And 48 more files
-2. **String Literals** — Some string literals also use single quotes
-   - Needs conversion to double quotes throughout
-## Actions Taken
-1. ✅ Created comprehensive code conventions document (`docs/conventions/code_conventions.md`)
-2. ✅ Updated ESLint configuration to enforce double quotes
-3. ✅ Updated documentation references (`documentation_standards.md`, `context/index.md`)
-4. ✅ Fixed one sample file (`src/events/event_emitter.ts`) as demonstration
-## Recommended Next Steps
-### Option 1: Automated Fix (Recommended)
-Run ESLint with --fix to automatically convert quotes:
-```bash
-npm run lint -- --fix
-```
-Then address any remaining errors (unused variables, escape characters).
-### Option 2: Use Prettier
-Add Prettier configuration for automatic formatting:
-```bash
-npm install --save-dev prettier
-```
-Create `.prettierrc.json`:
-```json
-{
-  "semi": true,
-  "singleQuote": false,
-  "trailingComma": "es5",
-  "printWidth": 100,
-  "tabWidth": 2
-}
-```
-Run:
-```bash
-npx prettier --write "src/**/*.ts"
-```
-### Option 3: Manual Conversion
-Continue manual conversion file-by-file (time-consuming for 58 files).
-## ESLint Configuration
-Updated `.eslintrc.json` to enforce double quotes:
-```json
-{
-  "rules": {
-    "quotes": [
-      "error",
-      "double",
-      {
-        "avoidEscape": true,
-        "allowTemplateLiterals": true
-      }
-    ]
-  }
-}
-```
-## Summary
-The codebase is **93% aligned** with the new conventions:
-- ✅ Naming conventions (files, functions, types, variables)
-- ✅ Code organization (imports, exports, structure)
-- ✅ SQL conventions (tables, columns, indexes, migrations)
-- ✅ YAML conventions (indentation, keys, structure)
-- ✅ Shell script conventions (shebang, error handling)
-- ⚠️ **String quotes need conversion** (automated fix recommended)
-Once the quote conversion is complete (via ESLint --fix or Prettier), the codebase will be **100% compliant** with the documented conventions.
-
-
-
-

package/docs/conventions/documentation_standards.md

@@ -1,104 +0,0 @@
----
-version: "1.0.0"
-last_updated: "2026-02-02"
-status: "canonical"
----
-
-# Neotoma documentation standards
-## Scope
-This document defines the required structure, formatting, and validation rules for all Neotoma documentation. It does not replace subsystem or architecture specifications.
-
-## Purpose
-Provide a consistent documentation format that supports deterministic interpretation by agents and humans.
-
-## Scope
-This document covers:
-- Required sections and file structure
-- Documentation doctrine and invariants
-- Examples, diagrams, and testing requirements
-- Agent instructions and validation checklists
-It does not cover:
-- Code conventions
-- Feature unit templates
-- Release planning workflows
-
-## Invariants
-1. Documentation must align with `docs/NEOTOMA_MANIFEST.md`.
-2. Documentation must be deterministic and testable.
-3. Documentation must not include PII or secrets.
-4. Documentation must use direct, declarative language.
-
-## Definitions
-- **Documentation doctrine**: The shared core invariants that all docs must embed or reference.
-- **Agent instructions**: The required closing section that defines how agents must use the document.
-
-## Documentation doctrine
-Neotoma is a Truth Layer. It is not an app, agent, or strategy or execution system.
-Core invariants:
-- Deterministic: Same input yields same output
-- Immutable: Truth never changes after storage
-- Provenance: Every output traces to a source
-- Schema first: All extraction derives from schemas
-- Explicit control: User approves all ingestion
-- Privacy maximal: No background data collection
-- Graph integrity: No orphans, no cycles, no inferred edges
-
-## Required document structure
-
-### File header
-Every documentation file must begin with:
-```
-# [Document Title]
-## Scope
-[Explicit statement of what this document covers and what it does NOT cover]
-```
-
-### Core sections
-Documentation files must include these sections when applicable:
-1. Purpose
-2. Scope
-3. Invariants
-4. Definitions
-5. Data models or schemas
-6. Flows or sequences
-7. Diagrams
-8. Examples
-9. Testing requirements
-10. Agent instructions
-
-## Flows and sequences
-Flows should use Mermaid diagrams or clear step lists. Use deterministic ordering.
-
-## Diagrams
-Use Mermaid diagrams with stable node names. Avoid random identifiers.
-
-## Examples
-Examples must be complete and deterministic. Use realistic but synthetic data.
-
-## Testing requirements
-Each doc should list tests that validate the described behavior.
-
-## Agent Instructions
-### When to Load This Document
-Load this document when creating or editing documentation.
-
-### Required Co-Loaded Documents
-- `docs/NEOTOMA_MANIFEST.md`
-- `docs/conventions/writing_style_guide.md`
-
-### Constraints Agents Must Enforce
-1. Required sections are present.
-2. Examples are deterministic and complete.
-3. No PII or secrets are included.
-
-### Forbidden Patterns
-- Em dashes or en dashes
-- Conversational transitions
-- Soft questions
-- Motivational language
-
-### Validation Checklist
-- [ ] Required sections present
-- [ ] Examples are deterministic
-- [ ] No PII or secrets
-- [ ] Writing style rules applied

package/docs/conventions/estimation_methodology.md

@@ -1,146 +0,0 @@
-# Estimation Methodology
-## Core Principle: Velocity-Based Estimation
-**Always base estimates on actual project velocity, not theoretical calculations.**
-### v0.1.0 Baseline
-- **26 Feature Units** completed in **2-3 days**
-- **Velocity**: ~8-13 FUs per day
-- **Execution Model**: Cursor agent execution with parallelization
-This baseline demonstrates that with:
-- Established architecture and patterns
-- Comprehensive documentation
-- Agent parallelization
-- Existing foundation code
-**Complex releases can be completed in days, not weeks.**
-## Estimation Process
-### Step 1: Identify Work Required
-1. **List all FUs in the release**
-2. **Mark which FUs are already complete** (from previous releases)
-3. **Identify which FUs need new work** vs. polish/updates
-4. **Account for dependencies** (can FUs run in parallel?)
-### Step 2: Classify FU Complexity
-**Low Complexity** (0.25-0.5 days):
-- UI polish/refinement
-- Minor service updates
-- Configuration changes
-- Documentation updates
-**Medium Complexity** (0.5-1 day):
-- New UI components/views
-- Service integrations
-- Database migrations (simple)
-- MCP action implementations
-**High Complexity** (1-2 days):
-- RLS implementation (migration + policies + service updates)
-- Complex database migrations
-- Cross-cutting refactors
-- Novel algorithms
-### Step 3: Apply Velocity Baseline
-**For releases with similar scope to v0.1.0:**
-- Use v0.1.0 velocity: 8-13 FUs/day
-- Account for parallelization: 3 FUs can run simultaneously
-- Add 20% buffer for integration testing and polish
-**For smaller releases:**
-- Scale proportionally
-- Example: 3 FUs = 0.5-1 day (not 1.5 weeks)
-### Step 4: Account for Existing Foundation
-**If foundation exists (architecture, patterns, docs):**
-- Reduce estimates by 50-70%
-- Example: Design system with existing components = polish (0.5 days), not greenfield (1.5 weeks)
-**If greenfield work:**
-- Use full estimates from `MVP_FEATURE_UNITS.md`
-- Add 30% buffer for unknowns
-## Common Estimation Mistakes
-### ❌ Mistake 1: Using Theoretical Hour Estimates
-**Wrong:**
-- Spec (1-3h) + Implementation (2-8h) + Testing (1-4h) + Docs (0.5-1h) = 4.5-16h per FU
-- 8 FUs × 16h = 128h = 16 days
-**Right:**
-- v0.1.0: 26 FUs in 2-3 days = 8-13 FUs/day
-- 8 FUs ÷ 10 FUs/day = 0.8 days
-### ❌ Mistake 2: Ignoring Existing Foundation
-**Wrong:**
-- FU-300: Design System = 1.5 weeks (greenfield estimate)
-**Right:**
-- FU-300: Design System = 0.5 days (StyleGuide.tsx exists, components implemented, needs polish)
-### ❌ Mistake 3: Sequential Thinking
-**Wrong:**
-- FU-100 (2.5 days) + FU-300 (1.5 weeks) + FU-700 (1 week) = 3 weeks sequential
-**Right:**
-- FU-100 ✅ (complete) + FU-300 (0.5 days) + FU-700 (0.5-1 day) in parallel = 1 day
-### ❌ Mistake 4: Not Accounting for Completed Work
-**Wrong:**
-- v1.0.0 needs FU-100, FU-101, FU-102, FU-103, FU-105 = 5 FUs × 1 day = 5 days
-**Right:**
-- v1.0.0 needs FU-100 ✅, FU-101 ✅, FU-102 ✅, FU-103 ✅, FU-105 ✅ = 0 days (already complete)
-## Estimation Template
-### For New Releases
-```markdown
-## Release Estimation
-**Baseline Velocity:** v0.1.0 = 26 FUs in 2-3 days = ~8-13 FUs/day
-**FUs in Scope:**
-- FU-XXX: [Name] - [Status: Complete | New | Update]
-- ...
-**Work Required:**
-- [List only FUs needing new work]
-**Complexity Breakdown:**
-- Low: X FUs (0.25-0.5 days each)
-- Medium: Y FUs (0.5-1 day each)
-- High: Z FUs (1-2 days each)
-**Parallelization:**
-- Batch 0: X FUs in parallel = max(individual estimates)
-- Batch 1: Y FUs in parallel = max(individual estimates)
-- ...
-**Total Estimate:**
-- Development: [X] days
-- Integration Testing: [Y] days
-- **Total: [X+Y] days**
-```
-## Updating Estimates
-### When to Revise
-1. **After each release completion:**
-   - Record actual time taken (from `status.md` time tracking section)
-   - Calculate estimation accuracy: (Actual / Estimated) × 100%
-   - Update velocity baseline if significantly different
-   - Adjust methodology if accuracy consistently off (>20% variance)
-2. **When scope changes:**
-   - Re-estimate based on new scope
-   - Account for dependencies
-3. **When foundation changes:**
-   - If new architecture/patterns established, reduce future estimates
-   - If breaking changes, increase estimates
-### How to Revise
-1. **Update `execution_schedule.md`** with revised estimates
-2. **Add note** explaining revision rationale
-3. **Update this document** if methodology changes
-4. **Record time tracking data** in `status.md` for future reference
-### Time Tracking Data Collection
-**Required fields in `status.md` (Section 1.1):**
-- Development Start Date: Recorded when status changes to `in_progress`
-- Development Finish Date: Recorded when status changes to `ready_for_deployment`
-- Deployment Date: Recorded when status changes to `deployed`
-- Completion Date: Recorded when status changes to `completed`
-- Estimated Development Time: From `execution_schedule.md`
-- Actual Development Time: Calculated (Finish - Start)
-- Estimation Accuracy: Calculated ((Actual / Estimated) × 100%)
-**Use this data to:**
-- Calibrate future estimates
-- Identify estimation patterns (consistently over/under)
-- Update velocity baseline
-- Refine complexity classifications
-## Example: v1.0.0 Revision
-**Original Estimate:** 3-4 weeks
-**Revision Rationale:**
-- v0.1.0 demonstrated 26 FUs in 2-3 days
-- v1.0.0 requires only 3 new FUs (FU-300 polish, FU-700 auth UI, FU-701 RLS)
-- FU-100, FU-101, FU-102, FU-103, FU-105 already complete from v0.1.0
-- Design system foundation exists (StyleGuide.tsx, components)
-**Revised Estimate:** 2-3 days
-**Breakdown:**
-- Batch 0: FU-300 (0.5 days) + FU-700 (0.5-1 day) in parallel = 1 day
-- Batch 3: FU-701 (1-2 days) = 1-2 days
-- Integration testing: 0.5-1 day
-- **Total: 2-3 days**
-## Notes
-- **Always validate estimates against actual velocity**
-- **Prefer conservative estimates** (use upper bound)
-- **Account for integration testing** (20% buffer)
-- **Document estimation rationale** in release planning docs

package/docs/conventions/file_naming_migration_status.md

@@ -1,94 +0,0 @@
-# File Naming Convention Migration Status
-
-**Date:** 2026-01-01  
-**Status:** Complete (Core violations addressed)
-
-## Summary
-
-Applying file naming convention from `foundation/agent_instructions/cursor_rules/file_naming.md` to `docs/` directory. All files must use snake_case (underscores) and lowercase (except README/CHANGELOG).
-
-## Completed Renames
-
-### Files with Dashes (Kebab-case → Snake_case)
-
-- ✅ `docs/developer/add-summary-field_plan.md` → `docs/developer/add_summary_field_plan.md`
-- ✅ `docs/architecture/local-first-e2ee-architecture.md` → `docs/architecture/local_first_e2ee_architecture.md`
-- ✅ `docs/architecture/ingestion/dual-path_inference-based_ingestion.md` → `docs/architecture/ingestion/dual_path_inference_based_ingestion.md`
-- ✅ `docs/architecture/ingestion/raw-first_ingestion_architecture.md` → `docs/architecture/ingestion/raw_first_ingestion_architecture.md`
-- ✅ `docs/architecture/ingestion/sources-first-ingestion-v9.md` → `docs/architecture/ingestion/sources_first_ingestion_v9.md`
-- ✅ `docs/architecture/ingestion/sources-first-ingestion-v11.md` → `docs/architecture/ingestion/sources_first_ingestion_v11.md`
-- ✅ `docs/architecture/ingestion/sources-first_ingestion_v10.md` → `docs/architecture/ingestion/sources_first_ingestion_v10.md`
-- ✅ `docs/architecture/ingestion/sources-first_ingestion_v12_final.md` → `docs/architecture/ingestion/sources_first_ingestion_v12_final.md` → `docs/architecture/sources_first_ingestion_final.md` (moved and version removed)
-
-**Note:** FU-XXX files (e.g., `FU-100_implementation_log.md`) use dashes as part of feature unit IDs and are acceptable.
-
-### Files with Uppercase → Lowercase
-
-**UI Files:**
-- ✅ `docs/ui/STYLE_GUIDE_UPDATES.md` → `docs/ui/style_guide_updates.md`
-- ✅ `docs/ui/SHADCN_COMPONENTS.md` → `docs/ui/shadcn_components.md`
-
-**Developer Files:**
-- ✅ `docs/developer/VITE_TROUBLESHOOTING.md` → `docs/developer/vite_troubleshooting.md`
-
-**Release Files (v0.2.15):**
-- ✅ `docs/releases/v0.2.15/CLI_INSTALLATION_OPTIONS.md` → `docs/releases/v0.2.15/cli_installation_options.md`
-- ✅ `docs/releases/v0.2.15/IMPLEMENTATION_SUMMARY.md` → `docs/releases/v0.2.15/implementation_summary.md`
-- ✅ `docs/releases/v0.2.15/STATUS.md` → `docs/releases/v0.2.15/status.md`
-- ✅ `docs/releases/v0.2.15/MIGRATION_GUIDE.md` → `docs/releases/v0.2.15/migration_guide.md`
-- ✅ `docs/releases/v0.2.15/RELEASE_BUILD_SUMMARY.md` → `docs/releases/v0.2.15/release_build_summary.md`
-- ✅ `docs/releases/v0.2.15/APPLY_MIGRATIONS_MANUALLY.md` → `docs/releases/v0.2.15/apply_migrations_manually.md`
-- ✅ `docs/releases/v0.2.15/DEPLOYMENT_CHECKLIST.md` → `docs/releases/v0.2.15/deployment_checklist.md`
-
-**Release Files (v0.2.3):**
-- ✅ `docs/releases/v0.2.3/ENHANCEMENTS_SUMMARY.md` → `docs/releases/v0.2.3/enhancements_summary.md`
-- ✅ `docs/releases/v0.2.3/AGENT_SKILLS_ALIGNMENT.md` → `docs/releases/v0.2.3/agent_skills_alignment.md`
-- ✅ `docs/releases/v0.2.3/RELEASE_OVERVIEW.md` → `docs/releases/v0.2.3/release_overview.md`
-- ✅ `docs/releases/v0.2.3/PLAN_COMPLETION_REVIEW.md` → `docs/releases/v0.2.3/plan_completion_review.md`
-
-**Other Release Files:**
-- ✅ `docs/releases/v0.1.0/REMEDIATION_SUMMARY.md` → `docs/releases/v0.1.0/remediation_summary.md`
-
-**Prototype Files:**
-- ✅ `docs/prototypes/PROTOTYPE_SUMMARY.md` → `docs/prototypes/prototype_summary.md`
-- ✅ `docs/prototypes/PROTOTYPE_QUICKSTART.md` → `docs/prototypes/prototype_quickstart.md`
-- ✅ `docs/prototypes/PROTOTYPE_INDEX.md` → `docs/prototypes/prototype_index.md`
-- ✅ `docs/prototypes/PROTOTYPE_COMPLETE.md` → `docs/prototypes/prototype_complete.md`
-
-**Private/Strategy Files:**
-- ✅ `docs/private/DOCUMENTATION_SECOND_PASS_AUDIT.md` → `docs/private/documentation_second_pass_audit.md`
-- ✅ `docs/private/strategy/COMPETITIVE_LANDSCAPE.md` → `docs/private/strategy/competitive_landscape.md`
-- ✅ `docs/private/strategy/IMPLEMENTATION_OVERLAP_ANALYSIS.md` → `docs/private/strategy/implementation_overlap_analysis.md`
-
-**Feature Unit Standards:**
-- ✅ `docs/feature_units/standards/DISCOVERY_CAGAN_ALIGNMENT.md` → `docs/feature_units/standards/discovery_cagan_alignment.md`
-
-## Remaining Files
-
-### Acceptable Exceptions
-
-The following files use uppercase but are acceptable per convention:
-
-- **README.md and CHANGELOG.md**: Special files allowed to use uppercase
-- **Spec files in `docs/specs/`**: Legacy convention (e.g., `MCP_SPEC.md`, `DATA_MODELS.md`). New spec files should use lowercase.
-- **FU-XXX files**: Feature unit files use uppercase as part of identifiers (e.g., `FU-100_implementation_log.md`, `FU-050_spec.md`). These follow a consistent pattern and may be acceptable depending on project conventions.
-
-## Reference Updates
-
-After renaming files, all references must be updated in:
-- Markdown files (`.md`)
-- YAML files (`.yaml`, `.yml`)
-- Code files that reference documentation paths
-- `doc_dependencies.yaml`
-
-## Script
-
-A script has been created at `scripts/apply_file_naming_convention.sh` to automate renaming and reference updates. Run with caution and review changes before committing.
-
-## Next Steps
-
-1. Complete remaining file renames
-2. Update all references in documentation
-3. Verify no broken links
-4. Update `doc_dependencies.yaml` if needed
-