neotoma 0.3.0 → 0.3.2

package/.claude/rules/configuration_management.md

@@ -1,159 +0,0 @@
----
-description: "Load when adding or moving config: repo-specific config in repository foundation-config.yaml; shared config in foundation config/repo-adapters/; never put single-repo config in foundation submodule."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/configuration_management.mdc -->
-
-# Configuration Management Rule
-
-Ensures configuration files are placed in the correct location based on their scope and purpose.
-
-## Configuration Locations
-
-### Repository-Specific Configuration
-
-**Location:** `foundation-config.yaml` in the repository root (NOT in foundation submodule)
-
-**Contains:**
-- Repository name, type, and languages
-- Development workflow settings (branch strategy, commit format, PR settings)
-- Code conventions specific to this repository
-- Testing configuration
-- Documentation standards
-- Security settings (protected paths, credential management)
-- Tooling configuration
-- Agent instructions configuration
-- Repository-specific custom settings
-
-**Example:**
-```yaml
-# foundation-config.yaml (in repository root)
-repository:
-  name: "my-project"
-  type: "application"
-
-conventions:
-  python:
-    files: "snake_case"
-
-security:
-  pre_commit_audit:
-    protected_paths:
-      - "data/imports/"  # Repository-specific paths
-```
-
-### Shared Configuration (Repo Adapters)
-
-**Location:** `foundation/config/repo-adapters/<repo-name>.yaml` (in foundation submodule)
-
-**Purpose:** Shared configurations used across MULTIPLE repositories with the same name/type
-
-**When to use:**
-- Configuration shared across multiple repositories (e.g., all "neotoma" repos)
-- Template configurations for similar project types
-- Organization-wide standards
-
-**When NOT to use:**
-- Single repository configuration
-- Repository-specific paths or settings
-- Unique repository requirements
-
-**Example:**
-```yaml
-# foundation/config/repo-adapters/neotoma.yaml
-# Used by ALL neotoma-related repositories
-
-repo_name: "neotoma"
-conventions:
-  typescript:
-    files: "snake_case"
-documentation:
-  required_sections:
-    - "Agent Instructions"  # Standard for all neotoma repos
-```
-
-## Rules
-
-### MUST
-
-1. Repository-specific config → repository's `foundation-config.yaml`
-   - All configuration unique to a single repository goes in the repository's own `foundation-config.yaml`
-   - Includes: conventions, security paths, documentation structure, custom settings
-
-2. Shared config → foundation repo adapters
-   - Only use `foundation/config/repo-adapters/` for configurations shared across multiple repositories
-   - Examples: organization standards, project templates, multi-repo conventions
-
-3. Never commit single-repo configs to foundation submodule
-   - If a configuration file is only relevant to one repository, it belongs in that repository's `foundation-config.yaml`, NOT in the foundation submodule
-
-### MUST NOT
-
-1. Do NOT add repository-specific configuration to `foundation/config/repo-adapters/`
-   - Single-repo configs belong in the repository's own `foundation-config.yaml`
-
-2. Do NOT duplicate configuration between repo adapters and `foundation-config.yaml`
-   - If it's in `foundation-config.yaml`, it shouldn't also be in a repo adapter
-
-3. Do NOT modify foundation submodule files for repository-specific needs
-   - Foundation submodule is shared code - repository-specific changes belong in the repository itself
-
-## Decision Tree
-
-```
-Need to add/modify configuration?
-    │
-    ├─ Is this specific to ONE repository?
-    │   │
-    │   └─ YES → Add to repository's foundation-config.yaml
-    │
-    ├─ Is this shared across MULTIPLE repositories?
-    │   │
-    │   └─ YES → Add to foundation/config/repo-adapters/<name>.yaml
-    │
-    └─ Is this a foundation framework change?
-        │
-        └─ YES → Modify foundation code/templates (careful - affects all repos)
-```
-
-## Examples
-
-### ✅ Correct: Repository-Specific Config
-
-```yaml
-# foundation-config.yaml (in repository root)
-repository:
-  name: "personal"
-
-security:
-  pre_commit_audit:
-    protected_paths:
-      - "$DATA_DIR/imports/"  # Specific to this repo's structure
-      - "$DATA_DIR/attachments/"
-```
-
-### ❌ Incorrect: Repository-Specific Config in Foundation
-
-```yaml
-# foundation/config/repo-adapters/personal.yaml  # WRONG!
-repo_name: "personal"
-security:
-  pre_commit_audit:
-    protected_paths:
-      - "$DATA_DIR/imports/"  # This is specific to ONE repo
-```
-
-### ✅ Correct: Shared Config in Foundation
-
-```yaml
-# foundation/config/repo-adapters/neotoma.yaml
-# Used by all neotoma-related repositories
-
-repo_name: "neotoma"
-documentation:
-  required_sections:
-    - "Purpose"
-    - "Scope"
-    - "Agent Instructions"  # Standard for ALL neotoma repos
-```

package/.claude/rules/content_style_enforcement.md

@@ -1,141 +0,0 @@
----
-description: "Load when creating or editing essays, articles, posts, docs, or marketing copy: apply anti-AI patterns from writing style guide; remove filler, hype, em dashes; use active voice and authentic human voice."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/content_style_enforcement.mdc -->
-
-
-# Content Style Enforcement Rule
-
-**Reference:** `foundation/conventions/writing_style_guide.md` — Writing style guide
-
-Ensures all content (essays, articles, posts, documentation) always follows anti-AI patterns and authentic human voice standards.
-
-## Trigger Patterns
-
-When creating or editing ANY content:
-- Essays, articles, blog posts
-- Social media content
-- Documentation
-- Marketing copy
-- Technical writing
-- Any written content for publication
-
-## Agent Actions
-
-### Step 1: Load Style Guide
-
-Before finalizing any content:
-1. Load `foundation/conventions/writing_style_guide.md`
-2. Review prohibited patterns
-3. Apply all style rules
-
-### Step 2: Apply Anti-AI Patterns
-
-Before finalizing any content, MUST remove all AI-generated language patterns per the writing style guide:
-
-**Generic AI Phrases to Remove:**
-- "Furthermore", "Moreover", "In addition"
-- "leverage" → use "use" or "draw on"
-- "empower" → use "enable" or "let"
-- "cutting-edge" → use specific technical terms
-- "revolutionary", "game-changing", "seamless" → remove marketing hype
-
-**Corporate Speak to Reduce:**
-- "solution" → use specific description
-- "platform" → use "tool" or "system" where appropriate
-- "ecosystem" → use only when necessary, prefer specific names
-
-**Language Simplification:**
-- "utilize" → "use"
-- "facilitate" → "enable" or "help"
-- "remembrances" → "memories"
-- "structural foundation" → "foundation"
-- Passive voice → Active voice ("it was found" → "I found")
-
-**Punctuation Patterns (AI-Generated Tendencies):**
-- NEVER use em dashes (—) or en dashes (–)
-- Use commas for appositives and lists
-- Use periods to separate ideas
-- Use colons to introduce lists or explanations
-- Use standard hyphens (-) for compound words and ranges
-
-**Conversational Transitions (AI-Generated Tendencies):**
-- NEVER use: "Now, let's...", "So, you might...", "Interestingly...", "As you can see...", "Keep in mind that..."
-- Use direct statements without transition words
-- Start with the subject directly
-
-**Soft Questions and Offers (AI-Generated Tendencies):**
-- NEVER use: "Would you like to...?", "Have you considered...?", "Want to try...?", "Need help with...?"
-- Use direct instructions: "Use the `store_record` action to..."
-- Use declarative statements: "The system supports..."
-
-**Motivational Language (AI-Generated Tendencies):**
-- NEVER use: "Get started!", "Try it now!", "You're all set!", "Ready to go!", "Let's dive in!"
-- Use neutral completion statements: "Setup is complete."
-- Use direct next steps: "Next, configure environment variables."
-
-**Excessive Parentheticals (AI-Generated Tendencies):**
-- NEVER use multiple parenthetical asides in one sentence
-- NEVER use long explanatory parentheticals that break flow
-- Use separate sentences for explanations
-- Use commas for brief clarifications
-
-**Redundant Qualifiers (AI-Generated Tendencies):**
-- NEVER use: "very", "quite", "rather", "somewhat", "pretty", "incredibly", "extremely", "highly"
-- Use direct adjectives: "fast" not "very fast"
-- Use specific measurements when available: "processes 100 files/second" not "very quickly"
-
-**Complex Sentence Structures (AI-Generated Tendencies):**
-- NEVER use overly nested clauses
-- NEVER use multiple dependent clauses in one sentence
-- NEVER use sentences over 25 words
-- Use simple, short sentences (15-20 words)
-- Use one idea per sentence
-- Break complex thoughts into multiple sentences
-
-### Step 3: Verify Authentic Human Voice
-
-Content MUST have:
-- Conversational but professional tone
-- First person where appropriate ("I built this", "When I use...")
-- Personal insights and examples
-- Natural language flow (contractions, varied sentence length)
-- Active voice preferred
-- Direct, clear statements
-- Simple, declarative sentences
-
-### Step 4: Quality Check
-
-Before completing content work:
-1. Scan for AI phrases listed above
-2. Replace with natural alternatives
-3. Verify active voice throughout
-4. Check for personal insights/examples
-5. Read aloud to verify natural flow
-6. Search for em dashes (—) and en dashes (–) and replace
-7. Remove conversational transitions
-8. Remove soft questions and motivational language
-9. Simplify complex sentences
-10. Remove redundant qualifiers
-
-## Constraints
-
-- MUST apply anti-AI patterns to ALL content before finalizing
-- MUST NOT skip style enforcement to save time
-- MUST verify authentic human voice in every piece
-- MUST remove generic AI phrases even if content is AI-generated initially
-- MUST use active voice unless passive is clearly better
-- MUST NOT use em dashes (—) or en dashes (–)
-- MUST NOT use conversational transitions ("Now, let's...", "So, you might...")
-- MUST NOT use soft questions ("Would you like to...?", "Have you considered...?")
-- MUST NOT use motivational language ("Get started!", "Try it now!")
-- MUST NOT use excessive parentheticals
-- MUST NOT use redundant qualifiers ("very", "quite", "rather")
-- MUST use simple, declarative sentences (15-20 words, one idea per sentence)
-
-## Related Documents
-
-- `foundation/conventions/writing_style_guide.md` - Complete writing style guide
-- `foundation/conventions/documentation_standards.md` - Documentation structure and format

package/.claude/rules/dependency_installation.md

@@ -1,148 +0,0 @@
----
-description: "Load when adding imports or code that requires packages not in package.json/requirements.txt: install dependencies automatically with correct package manager, update manifest, verify installation."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/dependency_installation.mdc -->
-
-# Dependency Installation Rule
-
-Ensures agents automatically install required dependencies when needed to fulfill prompts.
-
-## Rule
-
-**Always install required dependencies as needed to fulfill prompts.**
-
-When implementing features, fixing bugs, or making changes that require dependencies:
-
-1. **Detect missing dependencies** - Identify when code requires packages, tools, or libraries that are not installed
-2. **Install automatically** - Install dependencies without asking for permission
-3. **Use appropriate package manager** - Use the correct package manager for the project (npm, yarn, pip, etc.)
-4. **Verify installation** - Confirm dependencies are installed and accessible before proceeding
-
-## When This Applies
-
-- When adding new imports that require packages not in `package.json`, `requirements.txt`, or equivalent
-- When using tools or commands that require installation (e.g., `npx`, `pip install`)
-- When code references libraries that are not currently installed
-- When running scripts that depend on external tools
-- When setting up development environments
-
-## Agent Actions
-
-### 1. Detect Missing Dependencies
-
-Before implementing code that requires dependencies:
-
-- Check if imports reference packages not in dependency files
-- Verify tools/commands are available before use
-- Identify missing runtime dependencies
-
-### 2. Install Dependencies
-
-Install using the appropriate method:
-
-**Node.js/TypeScript projects:**
-```bash
-npm install <package-name>
-# or for dev dependencies
-npm install --save-dev <package-name>
-```
-
-**Python projects:**
-```bash
-pip install <package-name>
-# or
-pip install -r requirements.txt
-```
-
-**Other package managers:**
-- Use the project's configured package manager
-- Follow project conventions for dependency management
-
-### 3. Update Dependency Files
-
-After installing:
-
-- Update `package.json`, `requirements.txt`, or equivalent dependency files
-- Include version specifications when appropriate
-- Separate dev dependencies from production dependencies
-
-### 4. Verify Installation
-
-- Confirm packages are accessible via imports
-- Test that tools/commands work as expected
-- Ensure no installation errors occurred
-
-### 5. Proceed After Installing
-
-- After installing dependencies, retry the operation that failed (re-run the command or continue the workflow)
-- Do not stop and ask the user to run the command; run it again in the same workflow
-
-## Constraints
-
-- **Do NOT ask for permission** - Install dependencies automatically when needed
-- **Do NOT skip installation** - If code requires a dependency, install it
-- **Use correct package manager** - Follow project conventions (don't mix npm/yarn/pnpm)
-- **Update dependency files** - Always update manifest files after installation
-- **Handle errors gracefully** - If installation fails, report the error and suggest alternatives
-
-## Examples
-
-### ✅ Correct: Auto-Install Missing Dependency
-
-```typescript
-// Agent detects: "express" is imported but not in package.json
-// Agent action: npm install express
-// Agent updates: package.json with express dependency
-```
-
-### ✅ Correct: Install Dev Dependency
-
-```typescript
-// Agent detects: "@types/node" needed for TypeScript but not installed
-// Agent action: npm install --save-dev @types/node
-// Agent updates: package.json devDependencies
-```
-
-### ❌ Incorrect: Skip Installation
-
-```typescript
-// Agent detects missing dependency but asks: "Should I install express?"
-// This violates the rule - install automatically
-```
-
-### ❌ Incorrect: Wrong Package Manager
-
-```typescript
-// Project uses npm, but agent runs: yarn add express
-// This violates project conventions
-```
-
-## Integration Points
-
-### Package Managers
-
-- **npm** - `npm install`, `npm install --save-dev`
-- **yarn** - `yarn add`, `yarn add --dev`
-- **pnpm** - `pnpm add`, `pnpm add -D`
-- **pip** - `pip install`, `pip install -r requirements.txt`
-- **poetry** - `poetry add`, `poetry add --dev`
-
-### Dependency Files
-
-- `package.json` - Node.js/TypeScript projects
-- `package-lock.json` / `yarn.lock` / `pnpm-lock.yaml` - Lock files (auto-updated)
-- `requirements.txt` - Python projects
-- `pyproject.toml` - Python projects using Poetry
-- `Cargo.toml` - Rust projects
-- Other project-specific dependency manifests
-
-## Configuration
-
-No configuration needed - this rule applies universally to all projects.
-
-## Related Documents
-
-- `foundation/agent_instructions/cursor_rules/configuration_management.md` - Configuration file placement
-- `foundation/agent_instructions/cursor_rules/agent_constraints.md` - General agent constraints

package/.claude/rules/document_loading_order.md

@@ -1,197 +0,0 @@
----
-description: "Load at session start or when uncertain about doc order: load foundation docs first, then foundation submodule when needed, then task-specific docs; follow dependency graph."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/document_loading_order.mdc -->
-
-# Document Loading Order Rule
-
-**Reference:** `foundation/conventions/documentation-standards.md` - Documentation standards
-
-## Purpose
-
-Ensures agents load documentation in the correct order to establish proper context before proceeding with work.
-
-## Scope
-
-This document defines:
-- Mandatory loading order for documentation
-- Foundation submodule usage
-- Workflows for AI assistants and human developers
-
-This document does NOT cover:
-- Specific constraints agents must enforce (see `agent_constraints.md`)
-- Risk management and hold points (see `risk_management.md`)
-- Repository-specific document paths (configured in `foundation-config.yaml`)
-
-## Configuration
-
-Configure document loading paths in `foundation-config.yaml`:
-
-```yaml
-agent_instructions:
-  enabled: true
-  location: "docs/foundation/agent_instructions.md"  # Repository-wide agent instructions
-  foundation_docs_path: "docs/foundation/"  # Path to foundation documents
-  cursor_rules:
-    enabled: true
-    location: ".claude/rules/"
-```
-
-**Document paths are configurable per repository.** Default paths shown above can be customized in `foundation-config.yaml`.
-
-## Mandatory Loading Order
-
-Every AI assistant session MUST load documents in this order:
-
-### 1. Foundation Documents (First)
-
-Load foundation documents from configured foundation docs path FIRST (default: `docs/foundation/`):
-
-**Required foundation documents:**
-- Core philosophy/principles document (e.g., `philosophy.md`, `principles.md`)
-- Core identity document (e.g., `core_identity.md`, `identity.md`)
-- Data models document (if applicable, e.g., `data_models.md`)
-- Architecture document (if applicable, e.g., `architecture.md`, `layered_architecture.md`)
-
-**Why:** These establish the fundamental constraints and boundaries that all other work must respect.
-
-**Configuration:** Set `agent_instructions.foundation_docs_path` in `foundation-config.yaml` to customize the path.
-
-### 2. Foundation Submodule Documents (When Needed)
-
-Load shared foundation processes from `foundation/` submodule when needed:
-
-- `foundation/development/workflow.md` - For git workflow, branching, PRs
-- `foundation/conventions/code-conventions.md` - For code style and naming
-- `foundation/conventions/documentation-standards.md` - For documentation structure
-- `foundation/security/security-rules.md` - For security practices
-- `foundation-config.yaml` - For repository-specific configuration
-
-**When:** Load when working on development workflow, code style, documentation, or security-related tasks.
-
-### 3. Task-Specific Documents
-
-Load task-specific docs based on change type:
-
-- **Architecture changes:** Architecture docs from configured architecture path (default: `docs/architecture/`)
-- **Subsystem work:** Relevant subsystem docs from configured subsystems path (default: `docs/subsystems/`)
-- **Feature work:** Feature specs from configured specs path (default: `docs/specs/` or `docs/feature_units/`)
-- **Release work:** Release plans and status from configured releases path (default: `docs/releases/`)
-- **Documentation work:** Documentation standards from configured conventions path (default: `docs/conventions/`)
-- **Code work:** Code conventions from configured conventions path (default: `docs/conventions/`)
-
-**Configuration:** Document paths can be customized per repository structure.
-
-### 4. Related Context Documents
-
-Load additional context as needed:
-
-- Related subsystem docs
-- Integration guides
-- Testing standards
-- API specifications
-
-## For AI Assistants
-
-**Every session:**
-
-1. Load foundation documents from configured foundation docs path first (see Section 1)
-2. Load foundation submodule docs when relevant (see Section 2)
-3. Reference foundation documents to resolve ambiguities
-4. Validate all outputs against invariants
-5. Stop at hold points for human approval (see `.claude/rules/foundation-risk_management.md` if exists)
-
-**When uncertain:**
-
-- Default to conservative interpretation
-- Prioritize correctness over convenience
-- Ask for clarification rather than guess
-
-## For Human Developers
-
-**Before starting work:**
-
-1. Read foundation documents from configured foundation docs path (see Section 1)
-2. Read relevant subsystem/docs as indicated by context
-3. Understand project constraints and boundaries
-4. Verify feature fits within project scope
-
-**During implementation:**
-
-- Follow project conventions
-- Write maintainable code
-- Test thoroughly
-- Document all assumptions
-
-**Before committing:**
-
-- **Run security audit** from `foundation/security/pre-commit-audit.sh` (if configured)
-- Verify alignment with project standards
-- Check validation checklists
-- Run full test suite
-- Update docs if patterns changed
-- **Follow commit format** from `foundation/development/workflow.md` (configured in `foundation-config.yaml`)
-
-## Using Foundation Submodule
-
-Repositories using the foundation framework have access to the shared **foundation** submodule (`foundation/`) for development processes and conventions:
-
-### When to Reference Foundation
-
-**Development Workflow:**
-- Creating branches: See `foundation/development/workflow.md` and `foundation/development/branch-strategy.md`
-- Creating worktrees: Use `foundation/development/worktree-setup.sh` (if configured)
-- PR process: Follow `foundation/development/pr-process.md`
-- Commit format: Configured in `foundation-config.yaml` (see `development.commit_format.pattern`)
-
-**Code Conventions:**
-- Code style: See `foundation/conventions/code-conventions.md`
-- Naming patterns: See `foundation/conventions/naming-patterns.yaml`
-- Repository overrides: Check `foundation-config.yaml` for repo-specific settings
-
-**Documentation:**
-- Doc structure: Follow `foundation/conventions/documentation-standards.md`
-- Writing style: Avoid AI-generated patterns, use RFC 2119 language
-- Agent Instructions: Use template from `foundation/agent_instructions/README.md`
-
-**Security:**
-- Pre-commit audit: Run `foundation/security/pre-commit-audit.sh` before commits (if configured)
-- Credential management: See `foundation/security/credential-management.md`
-- Security rules: See `foundation/security/security-rules.md`
-
-**Configuration:**
-- Repository config: `foundation-config.yaml` (repo root)
-- Foundation defaults: `foundation/config/foundation-config.yaml`
-
-### Foundation Submodule vs Repository Foundation Docs
-
-- **`foundation/` submodule**: Shared development processes (workflow, conventions, security) - can be used by multiple repos
-- **Repository foundation docs** (e.g., `docs/foundation/`): Repository-specific foundation (philosophy, architecture, product positioning) - repository only
-
-Both are important:
-- Use `foundation/` for development practices (how to code, commit, review)
-- Use repository foundation docs for repository architecture (what to build, why, constraints)
-
-### Syncing Foundation Updates
-
-When foundation submodule is updated:
-
-```bash
-# Update to latest foundation
-git submodule update --remote foundation
-
-# Or use sync script (if available)
-./foundation/scripts/sync-foundation.sh
-```
-
-See `foundation/README.md` for complete foundation documentation.
-
-## Related Documents
-
-- `foundation/conventions/documentation-standards.md` - Documentation standards
-- `foundation/README.md` - Foundation submodule documentation
-- `foundation-config.yaml` - Repository-specific foundation configuration
-- `.claude/rules/foundation-risk_management.md` - Risk management and hold points (if exists)
-