neotoma 0.3.0 → 0.3.2

package/foundation/.cursor/rules/checkpoint_management.mdc

@@ -1,191 +0,0 @@
----
-description: "Ensures checkpoints are automatically updated in status.md when their trigger batches complete. Load when working in repos with status.md and checkpoint batches."
-alwaysApply: false
----
-# Checkpoint Management Rule
-
-**Reference:** `foundation/development/release_workflow.md` — Checkpoint sections
-
-Configuration is read from `foundation-config.yaml`.
-
-Ensures checkpoints are automatically updated in `status.md` when their trigger batches complete, preventing checkpoints from remaining `pending` after completion criteria are met.
-
-## Checkpoint Trigger Rules
-
-Checkpoints are configured in `manifest.yaml` with `checkpoint_{id}_after_batch` fields:
-
-```yaml
-checkpoints:
-  checkpoint_0.5_after_batch: 0.6 # Review milestone after Batch 0.6
-  checkpoint_1_after_batch: 4 # Mid-release review after Batch 4
-```
-
-**Checkpoint 2 (Pre-Release Sign-Off)** is always triggered when all batches are complete and release status is `ready_for_deployment` or `completed`.
-
-## Automatic Checkpoint Completion
-
-### When a Batch Completes
-
-1. **Check manifest.yaml for checkpoint triggers:**
-
-   - Look for `checkpoint_{id}_after_batch` fields
-   - If current batch ID matches any checkpoint trigger → mark checkpoint as `completed`
-
-2. **Update status.md checkpoint section:**
-
-   - Change checkpoint status from `pending` to `completed`
-   - Add completion notes with:
-     - Batch that triggered completion
-     - Key items completed in that batch (FUs or tasks)
-     - Brief validation summary
-
-3. **Checkpoint 2 completion:**
-   - When all batches complete → automatically mark Checkpoint 2 as `completed`
-   - Add notes: batch completion count, release status, critical item completion status
-
-### Example Checkpoint Update
-
-**Before (Batch 0.6 completes):**
-
-```markdown
-- **Checkpoint 0.5 — Foundation Review**: `pending`
-  - Configured after Batch 0.6 (foundation architecture complete).
-```
-
-**After (automatic update):**
-
-```markdown
-- **Checkpoint 0.5 — Foundation Review**: `completed`
-  - Configured after Batch 0.6 (foundation architecture complete).
-  - Batch 0.6 completed: [Key items] all complete.
-  - Foundation architecture validated.
-```
-
----
-
-## Agent Actions
-
-### During Batch Execution
-
-**After marking a batch as `completed` in status.md:**
-
-1. **Check for checkpoint triggers:**
-
-   ```javascript
-   // Pseudo-code logic
-   const completedBatchId = batch.batch_id;
-   const checkpointTriggers = manifest.checkpoints;
-
-   for (const [checkpointKey, triggerBatch] of Object.entries(
-     checkpointTriggers
-   )) {
-     if (triggerBatch === completedBatchId) {
-       // Mark checkpoint as completed
-       updateCheckpointStatus(checkpointKey, "completed", {
-         batch: completedBatchId,
-         items: batch.items,
-         timestamp: new Date().toISOString(),
-       });
-     }
-   }
-   ```
-
-2. **Update status.md:**
-   - Find checkpoint section
-   - Change status from `pending` to `completed`
-   - Add completion notes
-
-### After All Batches Complete
-
-1. **Check if Checkpoint 2 exists:**
-
-   - Look for "Checkpoint 2 — Pre-Release Sign-Off" in status.md (or similar final checkpoint name)
-
-2. **If exists and still `pending`:**
-   - Mark as `completed`
-   - Add completion notes:
-     - Total batches completed
-     - Release status
-     - Critical item completion count
-
----
-
-## Integration Points
-
-### Release Orchestrator
-
-The release orchestrator script should:
-
-- After each batch completes → check and update checkpoints
-- After all batches complete → ensure Checkpoint 2 is completed
-
-### Manual Batch Updates
-
-When manually updating `status.md` to mark a batch complete:
-- Also check and update any triggered checkpoints
-- Verify checkpoint status matches batch completion state
-
-### Report Generation
-
-Report generation reads checkpoint status from `status.md`:
-
-- If checkpoints are incorrectly `pending` → report will show incorrect metrics
-- Always verify checkpoint status matches batch completion before generating reports
-
----
-
-## Validation Rules
-
-**Before marking release as `ready_for_deployment`:**
-
-1. **Verify all checkpoints are completed:**
-
-   - Checkpoint 0 (Planning) → should be `completed` at start
-   - Checkpoint 0.5 → should be `completed` if trigger batch is complete
-   - Checkpoint 1 → should be `completed` if trigger batch is complete
-   - Checkpoint 2 → should be `completed` if all batches are complete
-
-2. **If any checkpoint is incorrectly `pending`:**
-   - STOP and update checkpoint status
-   - Add completion notes
-   - Then proceed with release status update
-
-## Error Prevention
-
-**Common Issues:**
-
-1. **Checkpoint remains `pending` after batch completes:**
-
-   - **Cause:** Manual batch update without checkpoint check
-   - **Prevention:** Always check checkpoint triggers when updating batch status
-
-2. **Checkpoint marked `completed` before batch completes:**
-
-   - **Cause:** Premature checkpoint update
-   - **Prevention:** Only update checkpoint when batch status is `completed`
-
-3. **Checkpoint 2 not completed:**
-   - **Cause:** Overlooked when all batches complete
-   - **Prevention:** Explicit check after all batches complete
-
----
-
-## Constraints
-
-- Do NOT mark checkpoint as `completed` before trigger batch is `completed`
-- Always add completion notes when updating checkpoint status
-- Always verify checkpoint status matches batch completion state
-- Do NOT skip checkpoint updates - they are required for accurate reporting
-
-## Configuration
-
-Checkpoint management uses paths from `foundation-config.yaml`:
-
-```yaml
-orchestration:
-  release:
-    enabled: true
-    directory: "docs/releases/"  # Or configured path
-    status_file: "status.md"
-    manifest_file: "manifest.yaml"
-```

package/foundation/.cursor/rules/configuration_management.mdc

@@ -1,156 +0,0 @@
----
-description: "Place configuration in correct location by scope (repo foundation-config.yaml vs foundation repo-adapters). Load when adding or moving config."
-alwaysApply: false
----
-# 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/foundation/.cursor/rules/content_style_enforcement.mdc

@@ -1,138 +0,0 @@
----
-description: "Enforce anti-AI patterns and authentic human voice in essays, posts, docs, and marketing copy. Load when creating or editing publishable content."
-alwaysApply: false
----
-
-# 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/foundation/.cursor/rules/dependency_installation.mdc

@@ -1,146 +0,0 @@
----
-description: "Install required dependencies when code or scripts need missing packages. Load when imports fail, tools are missing, or setup requires npm/pip/etc."
-alwaysApply: false
----
-# 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
-- **MUST NOT leave missing dependencies unresolved** - Install or report failure; do not proceed with broken imports or missing tools
-- **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