neotoma 0.3.0 → 0.3.2

package/.claude/rules/release_status_readme_update.md

@@ -1,62 +0,0 @@
----
-description: "Load when release status.md changes: pre-commit hook updates README release section; or run scripts/update_readme_release_status.py manually; use exact status values from workflow."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/release_status_readme_update.mdc -->
-
-# Release Status README Update Rule
-
-## Purpose
-
-Ensures the README.md file always reflects the current status of all releases, maintaining accurate project status visibility for all developers and stakeholders.
-
-## Implementation
-
-**Automated:** README release status updates are enforced by a pre-commit hook that runs when release `status.md` files change.
-
-**Hook:** `scripts/update_readme_release_status.py` (configured in `.pre-commit-config.yaml` as `release-status-readme`)
-
-**How it works:**
-1. When `docs/releases/*/status.md` is staged, the hook runs automatically
-2. Script parses all release status files
-3. Updates corresponding entries in README.md Releases section
-4. Stages the updated README.md automatically
-
-**Manual execution:**
-```bash
-python scripts/update_readme_release_status.py
-```
-
-## Agent Actions
-
-Agents do NOT need to manually update README when release status changes — the pre-commit hook handles this automatically.
-
-If manually updating release status outside of a commit:
-1. Update `docs/releases/{version}/status.md`
-2. Either commit (hook will update README) or run the script manually: `python scripts/update_readme_release_status.py`
-
-## Constraints
-
-- **MUST** use exact status values from release workflow (planning, in_progress, in_testing, ready_for_deployment, deployed, completed)
-- **MUST NOT** bypass the pre-commit hook
-- If manually running the script, verify README is updated correctly before committing
-
-## Configuration
-
-Release status file path is configurable in `foundation-config.yaml`:
-
-```yaml
-orchestration:
-  release:
-    enabled: true
-    directory: "docs/releases/"  # Or configured path
-    status_file: "status.md"
-```
-
-## Related Files
-
-- `scripts/update_readme_release_status.py` — Script implementation
-- `.pre-commit-config.yaml` — Hook configuration (release-status-readme)
-- `foundation-config.yaml` — Release directory configuration
-

package/.claude/rules/risk_management.md

@@ -1,170 +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
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/risk_management.mdc -->
-
-# 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
-- `.claude/rules/foundation-agent_constraints.md` - Constraints and forbidden patterns
-- `.claude/rules/foundation-security.md` - Security audit requirements
-

package/.claude/rules/security.md

@@ -1,168 +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
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/security.mdc -->
-
-# 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/.claude/rules/social_media_conventions.md

@@ -1,42 +0,0 @@
----
-description: "Use complete sentences for tweets and social media posts."
-alwaysApply: false
----
-
-<!-- Source: foundation/agent_instructions/cursor_rules/social_media_conventions.mdc -->
-
-# Social Media Conventions Rules
-
-## Purpose
-
-Ensures consistent, professional social media content (tweets, posts) that maintains clarity and readability.
-
-## Trigger Patterns
-
-Agents MUST apply these rules when:
-- Drafting tweets or social media posts
-- Creating announcement content for Twitter/X, LinkedIn, or similar platforms
-- Reviewing or revising social media copy
-
-## Complete Sentences
-
-**MUST use complete sentences for tweets and social media posts.**
-
-- Every clause must have a subject and verb
-- Avoid sentence fragments, trailing phrases, or standalone imperatives
-- Use proper punctuation
-
-**Examples:**
-- "Early build, feedback welcome." → "This is an early build, and feedback is welcome."
-- "Still experimental." → "This release is still experimental."
-- "Try it and tell us what breaks." → "Try it and tell us what breaks." (already complete)
-
-## Constraints
-
-- All tweets and social media posts MUST use complete sentences
-- Fragment-style copy (e.g., "Experimental. Use at your own risk.") MUST be rewritten as full sentences
-
-## Related Documents
-
-- Foundation or repository writing style guide — Documentation writing conventions
-- UI style guide enforcement rule (if present) — UI copy conventions