neotoma 0.3.0 → 0.3.2

package/.cursor/rules/agent_constraints.mdc

@@ -1,210 +0,0 @@
----
-description: "Load when validating work or before completing: enforce architectural boundaries, determinism, immutability, project principles; no credentials in instructions; run validation checklist."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/agent_constraints.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/agent_constraints.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/agent_constraints.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Agent Constraints Rule
-
-**Reference:** `foundation/conventions/documentation-standards.md` - Documentation standards
-
-## Purpose
-
-Ensures agents enforce all absolute constraints, forbidden patterns, and validation requirements when working on the repository.
-
-## Scope
-
-This document defines:
-- Absolute constraints that agents MUST enforce
-- Project positioning constraints (if configured)
-- Constraints agents must enforce
-- Communication constraints
-- Forbidden patterns
-- Validation checklist
-
-This document does NOT cover:
-- Repository-specific constraints (configured in `foundation-config.yaml`)
-- Risk management and hold points (see `risk_management.md`)
-- Document loading order (see `document_loading_order.md`)
-
-## Configuration
-
-Configure project-specific constraints in `foundation-config.yaml`:
-
-```yaml
-agent_instructions:
-  enabled: true
-  constraints: []  # Repository-specific constraints
-    # Example:
-    # - "Never violate architectural boundaries"
-    # - "Always follow schema-first principles"
-    # - "Enforce immutability for core data"
-  validation_checklist:
-    enabled: true
-    custom_checks: []  # Repository-specific validation checks
-```
-
-**Constraints are configurable per repository.** Default constraints shown below can be customized or extended in `foundation-config.yaml`.
-
-## Absolute Constraints
-
-Agents MUST enforce these constraints at all times (customize in `foundation-config.yaml`):
-
-1. **Never violate architectural boundaries** (respect layer boundaries, no cross-layer violations)
-2. **Never introduce nondeterminism** (no random IDs, no unstable logic, deterministic outputs)
-3. **Never generate features outside project scope** (stay within defined boundaries)
-4. **Always follow project principles** (schema-first, type-driven, or project-specific patterns)
-5. **Enforce data integrity** (immutability where required, proper validation)
-6. **Enforce safety and explicit control** (user approval where required, no implicit actions)
-7. **Always output validated artifacts** (code, specs, docs must pass validation)
-8. **Follow project positioning** (when creating marketing/content, follow project differentiators if configured)
-
-## Project Positioning Constraints (Optional)
-
-**If configured:** All release planning, marketing content, and feature positioning MUST validate project differentiators.
-
-Configure project differentiators in `foundation-config.yaml`:
-
-```yaml
-project:
-  differentiators: []  # Project-specific differentiators
-    # Example:
-    # - "privacy-first"
-    # - "deterministic"
-    # - "cross-platform"
-  positioning_framework: "docs/private/competitive/positioning_framework.md"  # Optional
-```
-
-### When Creating Release Plans (If Differentiators Configured)
-
-1. **Explicitly validate project differentiators**: Release must validate configured differentiators
-2. **Avoid feature-only releases**: Don't ship features without validating differentiators
-3. **Include acceptance criteria**: Release acceptance criteria must validate differentiators
-4. **Reference framework**: Link to positioning framework (if configured) in release plans
-
-### When Creating Marketing Content (If Differentiators Configured)
-
-1. **Lead with project differentiators**, not features alone
-2. **Contextualize features** as enabled by differentiators
-3. **Avoid feature-only positioning** (competitors may develop similar features)
-4. **Emphasize structural barriers** that prevent competitors from pursuing same path
-5. **Validate messaging**: All marketing messaging must emphasize differentiators first
-
-### When Creating Content, Documentation, or Positioning (If Differentiators Configured)
-
-1. **Lead with project differentiators**, not features alone
-2. **Contextualize features** as enabled by differentiators
-3. **Avoid feature-only positioning**
-4. **Emphasize structural barriers**
-5. **Reference framework** when appropriate (if configured)
-
-## Constraints Agents Must Enforce
-
-**Base constraints (always apply):**
-
-1. **Architectural boundaries:** MUST NOT violate layer boundaries or architectural constraints (configured per repository)
-2. **Determinism:** MUST NOT introduce randomness or nondeterministic logic (no random IDs, no unstable sorting, no `Date.now()` in business logic unless required)
-3. **Data integrity:** MUST NOT modify immutable data after storage (respect immutability requirements)
-4. **Project principles:** MUST follow project-specific principles (schema-first, type-driven, or as configured)
-5. **Explicit control:** MUST NOT implement automatic/implicit actions without user approval (respect explicit control requirements)
-6. **Provenance:** MUST trace all outputs to source (source file, rule, timestamp, or as configured)
-7. **Data integrity:** MUST maintain data consistency (no orphans, no cycles, transactional writes where required)
-8. **Privacy:** MUST NOT log sensitive data (PII, credentials, or as configured - only IDs/logs as allowed)
-9. **Security:** MUST NOT include credentials (API keys, tokens, service keys) in agent instructions, conversation text, or commit messages. Credentials MUST be injected via secure mechanisms (e.g., Cursor Cloud Agents Secrets) and agents MUST verify their availability via environment variable checks, not export commands with credential values
-
-**Repository-specific constraints:** Add custom constraints in `foundation-config.yaml` under `agent_instructions.constraints`.
-
-## Forbidden Patterns
-
-**Base forbidden patterns (always apply):**
-
-- Violating architectural boundaries (implementing logic outside defined layer boundaries)
-- Introducing nondeterminism (random IDs, unstable sorting, `Date.now()` in business logic unless required)
-- Generating features outside project scope (features not aligned with project goals)
-- Breaking immutability (modifying immutable data after initial storage)
-- Inferring beyond extraction (creating data not present in source, inferring relationships without explicit rules)
-- Schema mutations (changing assigned types after creation, unless allowed)
-- Synthetic data (guessing missing information, hallucinating fields)
-- Upward dependencies (lower layers calling higher layers, violating layer boundaries)
-- Non-transactional writes (data writes must be atomic where required)
-- Including credentials in agent instructions (no API keys, tokens, or service keys in prompt text, conversation messages, or code comments; use secure injection mechanisms like Cursor Secrets)
-- Storing documentation files in repo root (all documentation MUST be in appropriate `docs/` subdirectories)
-
-**Repository-specific forbidden patterns:** Add custom patterns in `foundation-config.yaml` under `agent_instructions.forbidden_patterns`.
-
-## Communication Constraints
-
-**Prohibitions:**
-- No emojis
-- No filler language
-- No hype
-- No soft asks
-- No conversational transitions
-- No call-to-action appendices
-- No questions, offers, suggestions, or motivational content
-- No tone matching, emotional softening, or user sentiment modulation
-
-**Assumptions:**
-- User possesses high cognitive acuity, though may have reduced verbal fluency
-
-**Execution rules:**
-- Use blunt, directive phrasing for cognitive restructuring
-- Suppress all engagement-optimizing or corporate-aligned behaviors:
-  - User satisfaction scores
-  - Conversational flow tagging
-  - Continuation bias
-  - Sentiment uplift
-- Avoid mirroring the user's tone, mood, or diction
-- Communicate strictly to the deep cognitive tier—beyond surface-level language
-
-**Response protocol:**
-- Deliver the requested or relevant information only
-- Terminate immediately after delivery—no transitions, no conclusions
-
-**End goal:**
-- User independence and cognitive restoration
-- Model obsolescence via user self-sufficiency
-
-## Validation Checklist
-
-Before completing any work, verify:
-
-**Base checks (always apply):**
-
-- [ ] Change respects architectural boundaries (no layer violations)
-- [ ] No nondeterministic logic introduced (no randomness, no unstable sorts)
-- [ ] Immutability preserved (immutable data not modified)
-- [ ] Schema changes are additive only (no breaking changes, no column removal)
-- [ ] Project principles followed (schema-first, type-driven, or as configured)
-- [ ] Data integrity maintained (no orphans, no cycles, transactional writes where required)
-- [ ] Privacy preserved (no sensitive data in logs, only IDs/logs as allowed)
-- [ ] Provenance maintained (all outputs trace to source)
-- [ ] Consistency model correct (as required per subsystem/component)
-- [ ] Security: No credentials included in agent instructions, conversation text, or code (use secure injection mechanisms)
-- [ ] Documentation location: No documentation files stored in repo root (all docs in `docs/` subdirectories)
-- [ ] Tests cover all new paths (unit, integration, E2E as appropriate)
-- [ ] Documentation updated to reflect changes
-- [ ] Downstream documentation updated if upstream docs changed
-- [ ] README.md updated if documentation changes affect user-facing information
-- [ ] Feature fits within project scope
-- [ ] No violations of MUST/MUST NOT lists
-- [ ] Project differentiators validated (if configured and if release planning or marketing content)
-
-**Repository-specific checks:** Add custom checks in `foundation-config.yaml` under `agent_instructions.validation_checklist.custom_checks`.
-
-## Related Documents
-
-- `foundation/conventions/documentation-standards.md` - Documentation standards
-- `foundation-config.yaml` - Repository-specific configuration
-- Repository foundation docs (e.g., `docs/foundation/philosophy.md`) - Core philosophy and architectural invariants
-- Repository architecture docs (e.g., `docs/architecture/architecture.md`) - System architecture

package/.cursor/rules/autonomous_execution.mdc

@@ -1,128 +0,0 @@
----
-description: "Load when deciding whether to ask user: proceed without asking for routine implementation, tests, docs, lint; stop and ask only for unclear architectural/design choices with high stakes (schema, layer boundaries, consistency model)."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/autonomous_execution.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/autonomous_execution.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/autonomous_execution.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Autonomous Execution Rule
-
-## Purpose
-
-Ensures agents proceed autonomously for routine work, stopping only for high-stakes architectural/design ambiguities that could lead to substantively wrong implementation if answered incorrectly.
-
-## Scope
-
-This rule defines:
-- When to proceed without asking
-- When to stop and ask the user
-- How to phrase questions when necessary
-- Alignment with risk management hold points
-
-## Proceed Without Asking
-
-**Execute immediately without confirmation for:**
-
-1. **Routine implementation**: Implementing features, refactors, bug fixes where the approach is clear from docs/codebase
-2. **Tests**: Writing unit tests, integration tests, E2E tests per testing standards
-3. **Documentation**: Updating docs to reflect code changes, fixing doc errors, adding missing documentation
-4. **Lint fixes**: Fixing linter errors, type errors, formatting issues
-5. **Code style**: Applying code conventions, normalizing naming, organizing imports
-6. **Allowed tool use**: Running any Bash commands, edits, or reads allowed by permissions in settings
-7. **Clear requirements**: Any task where the docs, codebase, or user request provide a clear answer
-
-**Do NOT ask for confirmation** before:
-- Making edits (permissions already grant Edit)
-- Running npm scripts, git commands, or other allowed Bash commands
-- Running tests or type checks
-- Fixing obvious issues (typos, broken imports, syntax errors)
-
-## Stop and Ask Only When
-
-**Stop and ask the user ONLY when ALL of these are true:**
-
-1. **Unclear architectural or design choice**: There is ambiguity about:
-   - Where to put a new module (which subsystem, which layer)
-   - Which abstraction to use (repository pattern, service pattern, reducer pattern)
-   - How to cross subsystem boundaries (direct import, event, API)
-   - Which consistency model to use (strong, eventual, bounded)
-   - Data model changes (new tables, new entity types, new relationships)
-
-2. **High stakes**: Choosing wrong would likely cause:
-   - Wrong layer (strategy/execution logic in Truth Layer)
-   - Wrong consistency model (eventual when strong required)
-   - Violating architectural boundaries (cross-layer dependencies)
-   - Breaking determinism (introducing nondeterministic logic)
-   - Breaking immutability (modifying observations/source after creation)
-   - Security issues (exposing PII, bypassing auth)
-
-**When asking:**
-- **Be concise**: Short, concrete question (1-2 sentences)
-- **Provide options**: "Proceed with X unless you prefer Y" or "Option A vs Option B?"
-- **State consequences**: "X would mean..., Y would mean..."
-- **Default to safe choice**: "I'll proceed with X (safe choice) unless you want Y"
-
-**Example good questions:**
-- "New `schema_registry` module: add to `src/services/` or create `src/schema/`? I'll use `src/services/` unless you prefer a separate directory."
-- "Cross-subsystem call: import directly or emit event? Direct is simpler but tighter coupling; event adds complexity. Proceed with direct import?"
-- "New `preferences` table: strong consistency (like entities) or eventual (like search)? I'll use strong unless you prefer eventual."
-
-## Do NOT Ask For
-
-**Never ask for confirmation when:**
-- Task is clearly specified in the prompt or docs ("should I do X?" when X is the task)
-- Fixing obvious errors ("is this correct?" for syntax errors, broken imports)
-- Running allowed tools (permissions already grant access)
-- Implementation details when approach is clear (function naming, file organization within established patterns)
-- Completing sub-tasks of an approved task (user asked for feature X, don't ask to implement each function)
-
-## Alignment with Risk Management
-
-This rule aligns with hold points from `risk_management.md`:
-
-**High-risk triggers that warrant asking:**
-- Schema changes (table structure, breaking JSONB changes)
-- Foundation document changes (files in configured foundation docs path)
-- Security changes (auth, RLS, encryption)
-- Architectural changes (layer boundaries, consistency models)
-- Violating documented constraints (even if user requests)
-
-**Medium/low-risk work that should proceed:**
-- New features within scope (no schema changes, no new subsystems)
-- API endpoint additions (following existing patterns)
-- Logic changes in non-critical paths
-- UI changes, documentation, tests
-
-## Configuration
-
-This rule is always loaded. No additional configuration needed.
-
-Permissions in settings already configured for autonomous execution (defaultMode, allow rules).
-
-## Constraints
-
-- **MUST proceed** without asking for routine work
-- **MUST stop** and ask only for high-stakes architectural/design ambiguity
-- **MUST phrase questions** concisely with options and defaults
-- **MUST NOT ask** for confirmation on allowed tool use
-- **MUST NOT ask** "should I do X?" when X is the specified task
-
-## Validation Checklist
-
-Before asking a question, verify:
-- [ ] Is there genuine architectural/design ambiguity?
-- [ ] Would choosing wrong cause substantively wrong implementation?
-- [ ] Can I find the answer in docs/codebase? (If yes, don't ask)
-- [ ] Have I phrased the question concisely with options?
-- [ ] Am I providing a safe default?
-
-If any of the first two are "no", proceed without asking.

package/.cursor/rules/configuration_management.mdc

@@ -1,168 +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
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/configuration_management.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/configuration_management.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/configuration_management.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# 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/.cursor/rules/cursor_rules_editing.mdc

@@ -1,99 +0,0 @@
----
-description: "Load when editing rules or commands: edit source in docs/ or foundation/agent_instructions/, never .cursor/rules or .cursor/commands; run setup_cursor_copies after editing."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/cursor_rules_editing.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/cursor_rules_editing.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/cursor_rules_editing.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Cursor Rules Editing Rule
-
-## Purpose
-
-Ensures agents always edit the source files for cursor rules and commands, never the copies in `.cursor/rules/` or `.cursor/commands/` directories.
-
-## Source of Truth Locations
-
-**Foundation rules and commands:**
-- Source: `foundation/agent_instructions/cursor_rules/` and `foundation/agent_instructions/cursor_commands/`
-- Copies: `.cursor/rules/` and `.cursor/commands/` (created by `/setup_cursor_copies`)
-
-**Repository rules:**
-- Source: `docs/` subdirectories (e.g., `docs/foundation/`, `docs/conventions/`, `docs/developer/`)
-- Copies: `.cursor/rules/` (created by `/setup_cursor_copies`)
-
-**Repository commands:**
-- Source: `docs/` subdirectories or repository-specific command locations
-- Copies: `.cursor/commands/` (created by `/setup_cursor_copies`)
-
-## Rule
-
-**MUST NOT edit files in `.cursor/rules/` or `.cursor/commands/`**
-
-These directories contain copies that are:
-- Automatically generated by `/setup_cursor_copies`
-- Overwritten when running `/setup_cursor_copies`
-- Not the source of truth
-
-## Agent Actions
-
-### When Editing Rules or Commands
-
-1. **Identify the source file:**
-   - Foundation rules: `foundation/agent_instructions/cursor_rules/{name}.mdc`
-   - Foundation commands: `foundation/agent_instructions/cursor_commands/{name}.md`
-   - Repository rules: `docs/{subdirectory}/{name}_rules.mdc` or `docs/{subdirectory}/{name}_rules.md`
-   - Repository commands: `docs/{subdirectory}/{name}_command.md` or repository-specific command locations
-
-2. **Edit the source file directly**
-
-3. **After editing, run `/setup_cursor_copies`** to sync changes to `.cursor/` directory
-
-### Detecting Source Files
-
-**For files in `.cursor/rules/` or `.cursor/commands/`:**
-- Check the header comment (added by setup script) for source file path
-- Header format:
-  - `.mdc` files: YAML frontmatter comment style (`---` with `#` comments)
-  - `.md` files: HTML comment style (`<!-- -->`)
-- Look for pattern: `docs/{subdirectory}/*_rules.mdc` or `foundation/agent_instructions/cursor_rules/*.mdc`
-- Use file naming pattern:
-  - Foundation rules use original filenames (no prefix)
-  - `{subdirectory}_{name}_rules.mdc` → `docs/{subdirectory}/{name}_rules.mdc`
-  - Commands use original filenames (no prefix)
-
-## Constraints
-
-- MUST NOT edit files in `.cursor/rules/` or `.cursor/commands/`
-- MUST edit source files in `docs/` or `foundation/agent_instructions/`
-- MUST run `/setup_cursor_copies` after editing source files to sync changes
-- MUST verify edits are in source files, not copies
-
-## Forbidden Patterns
-
-- Editing `.cursor/rules/*.mdc` or `.cursor/rules/*.md` directly
-- Editing `.cursor/commands/*.md` directly (foundation commands or repository commands)
-- Assuming `.cursor/` files are the source of truth
-- Skipping `/setup_cursor_copies` after editing source files
-- Removing header comments from copied files (they will be re-added by the script)
-
-## Validation
-
-Before committing rule or command changes:
-- [ ] Changes are in source files (`docs/` or `foundation/agent_instructions/`)
-- [ ] No changes were made to `.cursor/rules/` or `.cursor/commands/`
-- [ ] `/setup_cursor_copies` has been run to sync changes
-- [ ] All copied files in `.cursor/` have header comments (verify by checking first few lines)
-
-## Related Documents
-
-- `foundation/agent_instructions/cursor_rules/instruction_documentation.mdc` - How to document instructions
-- `foundation/agent_instructions/cursor_commands/setup_cursor_copies.md` - Command to sync copies

package/.cursor/rules/cursor_rules_sync.mdc

@@ -1,74 +0,0 @@
----
-description: "Load when modifying rule/command sources: pre-commit runs setup_cursor_copies when staged; edit source in docs/ or foundation only; do not use --no-verify to bypass."
-alwaysApply: false
----
-
-# ⚠️  DO NOT EDIT THIS FILE DIRECTLY
-#
-# This is a copy of: foundation/agent_instructions/cursor_rules/cursor_rules_sync.mdc
-# Source of truth: foundation/agent_instructions/cursor_rules/cursor_rules_sync.mdc
-#
-# To edit this rule:
-# 1. Edit the source file: foundation/agent_instructions/cursor_rules/cursor_rules_sync.mdc
-# 2. Run '/setup_cursor_copies' to sync changes
-#
-# This file will be overwritten when running setup_cursor_copies.
-
-# Cursor Rules Sync Rule
-
-Ensures `.cursor/rules/` and `.cursor/commands/` remain synchronized with their source files in `docs/` or `foundation/agent_instructions/`.
-
-## Implementation
-
-**Automated:** Rule and command syncing is enforced by a pre-commit hook that runs when source files change.
-
-**Hook:** `scripts/linters/cursor_rules_sync_pre_commit.sh` (configured in `.pre-commit-config.yaml` as `cursor-rules-sync`)
-
-**How it works:**
-1. When files matching `docs/**/*.mdc` or `foundation/agent_instructions/cursor_rules/**/*.mdc` or `foundation/agent_instructions/cursor_commands/**/*.md` are staged, the hook runs automatically
-2. Script executes `foundation/scripts/setup_cursor_copies.sh` (or repo equivalent)
-3. Updated `.cursor/rules/` and `.cursor/commands/` files are staged automatically
-4. Commit proceeds with synced files
-
-**Manual execution:**
-```bash
-# Run the setup script directly
-./foundation/scripts/setup_cursor_copies.sh
-
-# Or via command
-/setup_cursor_copies
-/sync_cursor_files copies
-```
-
-## Agent Actions
-
-Agents do NOT need to manually run `/setup_cursor_copies` after editing rule sources — the pre-commit hook handles this automatically.
-
-When creating or modifying rule/command sources:
-1. **Edit source files only** — in `docs/` or `foundation/agent_instructions/`, never `.cursor/`
-2. **Commit changes** — pre-commit hook will sync `.cursor/` automatically
-3. If editing outside of a commit (rare), run the setup script manually
-
-## Source File Locations
-
-**Foundation rules and commands:**
-- Source: `foundation/agent_instructions/cursor_rules/*.mdc`, `foundation/agent_instructions/cursor_commands/*.md`
-- Copies: `.cursor/rules/`, `.cursor/commands/` (synced via setup script)
-
-**Repository rules and commands:**
-- Source: `docs/**/*_rules.mdc`, `docs/**/*_command.md`
-- Copies: `.cursor/rules/`, `.cursor/commands/` (synced via setup script)
-
-## Constraints
-
-- **MUST NOT** edit files in `.cursor/rules/` or `.cursor/commands/` directly
-- **MUST** edit source files in `docs/` or `foundation/agent_instructions/`
-- **MUST** respect the pre-commit hook (do not use `--no-verify` to bypass)
-- If hook fails, fix the issue and retry commit
-
-## Related Files
-
-- `scripts/linters/cursor_rules_sync_pre_commit.sh` — Pre-commit hook implementation
-- `.pre-commit-config.yaml` — Hook configuration (cursor-rules-sync)
-- `foundation/scripts/setup_cursor_copies.sh` — Setup script (invoked by hook)
-- `.cursor/rules/cursor_rules_editing.mdc` — Rule about not editing .cursor/ directly