neotoma 0.3.0 → 0.3.2

package/foundation/CONTRIBUTING.md

@@ -1,202 +0,0 @@
-# Contributing to Foundation
-
-Thank you for contributing to Foundation! This document explains how to contribute improvements and maintain the shared processes.
-
-## Principles
-
-1. **Keep it generic** - Remove project-specific content
-2. **Make it configurable** - Use `foundation-config.yaml` for customization
-3. **Maintain backward compatibility** - Don't break existing consumers
-4. **Document everything** - All changes need documentation
-5. **Test thoroughly** - Verify changes work across different repos
-
-## How to Contribute
-
-### 1. Set Up Development Environment
-
-```bash
-# Clone foundation repository
-git clone <foundation-repo>
-cd foundation
-
-# Test changes in a consuming repository
-cd ../test-project
-git submodule add ../foundation foundation
-```
-
-### 2. Make Changes
-
-- Edit files in the foundation repository
-- Test changes in a consuming repository
-- Ensure configuration is flexible
-
-### 3. Test Your Changes
-
-```bash
-# In a test repository
-./foundation/scripts/validate-setup.sh
-
-# Test specific components
-./foundation/security/pre-commit-audit.sh
-./foundation/development/worktree-setup.sh test-branch
-```
-
-### 4. Submit Changes
-
-```bash
-# In foundation repository
-git add .
-git commit -m "Add: description of changes"
-git push origin main
-```
-
-## Types of Contributions
-
-### Adding New Processes
-
-1. Create new files in appropriate directory
-2. Add configuration options to `foundation-config.yaml`
-3. Update README.md with new component
-4. Add integration scripts if needed
-
-**Example: Adding a new security check**
-
-```bash
-# Create new security check
-vim foundation/security/new-check.sh
-chmod +x foundation/security/new-check.sh
-
-# Add configuration
-vim foundation/config/foundation-config.yaml
-# security:
-#   new_check:
-#     enabled: false
-
-# Document
-vim foundation/security/README.md
-
-# Test
-./foundation/security/new-check.sh
-```
-
-### Improving Existing Processes
-
-1. Identify improvement area
-2. Make changes
-3. Test in consuming repositories
-4. Update documentation
-
-### Fixing Bugs
-
-1. Create issue describing bug
-2. Fix bug in foundation
-3. Test fix in consuming repositories
-4. Reference issue in commit message
-
-## Code Standards
-
-### Scripts
-
-- Use `#!/bin/bash` shebang
-- Use `set -e` for error handling
-- Add help text with `-h` flag
-- Use colors for output (see existing scripts)
-- Make scripts executable: `chmod +x`
-
-### Documentation
-
-- Follow documentation standards in `conventions/documentation-standards.md`
-- Use clear, directive language
-- Include examples
-- Update README.md when adding new components
-
-### Configuration
-
-- Add new options to `foundation-config.yaml`
-- Provide sensible defaults
-- Document all options with comments
-- Test with options enabled/disabled
-
-## Testing Checklist
-
-Before submitting changes:
-
-- [ ] Changes work in at least 2 different repositories
-- [ ] Configuration is flexible and documented
-- [ ] No project-specific content included
-- [ ] Scripts are executable and have help text
-- [ ] Documentation is updated
-- [ ] Backward compatibility maintained
-- [ ] `validate-setup.sh` passes
-- [ ] Security checks still work
-
-## Review Process
-
-1. **Self-review** - Check your own changes thoroughly
-2. **Test in multiple repos** - Verify works across different projects
-3. **Update docs** - Ensure documentation is current
-4. **Get feedback** - Share with team/community if applicable
-
-## Breaking Changes
-
-If you need to make breaking changes:
-
-1. Document the breaking change
-2. Provide migration guide
-3. Update MIGRATION.md
-4. Increment major version
-5. Notify consuming repositories
-
-## Maintenance
-
-### Adding New Language Support
-
-To add support for a new language:
-
-1. Add language section to `conventions/code-conventions.md`
-2. Add naming patterns to `conventions/naming-patterns.yaml`
-3. Add configuration to `foundation-config.yaml`
-4. Add examples
-
-### Updating Configuration Schema
-
-When changing configuration:
-
-1. Update `foundation-config.yaml` template
-2. Update all repo adapters
-3. Document new options
-4. Provide backward-compatible defaults
-
-## Best Practices
-
-1. **Test before committing** - Always test in consuming repos
-2. **Keep changes focused** - One improvement per commit
-3. **Write clear commit messages** - Explain why, not just what
-4. **Update documentation** - Keep docs in sync with code
-5. **Consider backward compatibility** - Don't break existing users
-
-## Questions?
-
-If you have questions about contributing:
-
-1. Check existing documentation
-2. Review similar components in foundation
-3. Ask in foundation repository issues/discussions
-
-## License
-
-By contributing to Foundation, you agree that your contributions will be licensed under the same license as the project.
-
-
-
-
-
-
-
-
-
-
-
-
-
-

package/foundation/LICENSE

@@ -1,22 +0,0 @@
-MIT License
-
-Copyright (c) 2025 Mark Hendrickson
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-

package/foundation/MIGRATION.md

@@ -1,396 +0,0 @@
-# Migration Guide
-
-This guide helps you migrate from project-specific processes to Foundation.
-
-## Overview
-
-Migration involves:
-
-1. **Installing Foundation** - Add as submodule or symlink
-2. **Creating Configuration** - Define repo-specific settings
-3. **Migrating Content** - Move generic processes to foundation
-4. **Updating References** - Point to foundation instead of local docs
-5. **Testing** - Verify everything works
-
-## Step-by-Step Migration
-
-### Step 1: Install Foundation
-
-```bash
-# Method A: As git submodule (recommended)
-git submodule add <foundation-repo-url> foundation
-
-# Method B: As local symlink (for testing)
-ln -s ../foundation foundation
-```
-
-### Step 2: Create Configuration
-
-```bash
-# Copy template
-cp foundation/config/foundation-config.yaml ./foundation-config.yaml
-
-# Customize for your repository
-vim foundation-config.yaml
-```
-
-**Configure:**
-
-- Repository name and type
-- Branch naming patterns
-- Code conventions (file naming, string quotes, etc.)
-- Security rules (protected paths)
-- Enable/disable optional features
-
-### Step 3: Migrate Documentation
-
-**Identify Generic Documentation:**
-
-Look for documentation that could apply to any project:
-
-- Development workflow
-- Code conventions
-- Testing standards
-- Security practices
-
-**Keep Project-Specific Documentation:**
-
-Keep documentation that is unique to your project:
-
-- Product specifications
-- Architecture decisions
-- Business logic
-- Domain models
-
-**Update References:**
-
-```markdown
-<!-- Before -->
-See [Code Conventions](docs/conventions/code-conventions.md)
-
-<!-- After -->
-See [Code Conventions](foundation/conventions/code-conventions.md)
-```
-
-### Step 4: Migrate Scripts
-
-**Generic Scripts → Foundation:**
-
-Move scripts that could work in any project:
-
-- Worktree setup scripts
-- Security audit scripts
-- Environment setup scripts
-
-**Keep Project-Specific Scripts:**
-
-Keep scripts that are specific to your project:
-
-- Deployment scripts
-- Database migration scripts
-- Project-specific build scripts
-
-### Step 5: Update Git Configuration
-
-**Add to `.gitignore`:**
-
-```
-# Foundation local overrides
-foundation-config.local.yaml
-
-# Keep existing patterns
-.env*
-.secrets/
-```
-
-**Add git hooks (optional):**
-
-```bash
-# Copy pre-commit hook
-cp foundation/security/pre-commit-audit.sh .git/hooks/pre-commit
-chmod +x .git/hooks/pre-commit
-```
-
-### Step 6: Test Migration
-
-```bash
-# Validate setup
-./foundation/scripts/validate-setup.sh
-
-# Test key workflows
-./foundation/development/worktree-setup.sh test-branch
-./foundation/security/pre-commit-audit.sh
-
-# Run your tests
-npm test  # or your test command
-```
-
-### Step 7: Update Team Documentation
-
-Update onboarding docs and README to reference foundation:
-
-```markdown
-## Development
-
-This project uses [Foundation](foundation/README.md) for development processes.
-
-Key documents:
-- [Development Workflow](foundation/development/workflow.md)
-- [Code Conventions](foundation/conventions/code-conventions.md)
-- [Security Rules](foundation/security/security-rules.md)
-```
-
-## Common Migration Scenarios
-
-### Scenario 1: Migrating from Feature Branch Workflow
-
-**Before:** Traditional feature branches
-
-```bash
-git checkout -b feature/my-feature
-# ... develop ...
-git push origin feature/my-feature
-```
-
-**After:** Foundation workflow with worktrees
-
-```bash
-./foundation/development/worktree-setup.sh my-feature
-cd ../repo-my-feature
-# ... develop ...
-git push
-```
-
-**Configuration:**
-
-```yaml
-development:
-  workflow:
-    use_worktrees: true
-```
-
-### Scenario 2: Migrating Code Conventions
-
-**Before:** Project-specific conventions doc
-
-```
-docs/
-└── conventions.md  # All conventions in one file
-```
-
-**After:** Foundation conventions + repo adapter
-
-```
-foundation/conventions/code-conventions.md  # Generic conventions
-foundation-config.yaml                      # Repo-specific overrides
-
-# In foundation-config.yaml:
-conventions:
-  typescript:
-    files: "kebab-case"  # Override if different
-```
-
-### Scenario 3: Migrating Security Practices
-
-**Before:** Manual security checks
-
-```bash
-# Developer manually checks for secrets before commit
-grep -r "api_key" .
-```
-
-**After:** Automated security audit
-
-```bash
-# Automatic via git hook
-./foundation/security/pre-commit-audit.sh
-```
-
-## Handling Project-Specific Content
-
-### Option 1: Configuration
-
-For simple differences, use configuration:
-
-```yaml
-# foundation-config.yaml
-conventions:
-  typescript:
-    files: "kebab-case"  # Override foundation default
-```
-
-### Option 2: Repo Adapter
-
-For complex overrides, create a repo adapter:
-
-```yaml
-# foundation/config/repo-adapters/my-repo.yaml
-repo_name: "my-repo"
-
-# Override multiple settings
-conventions:
-  typescript:
-    files: "kebab-case"
-  sql:
-    tables: "PascalCase"  # Different from foundation
-
-security:
-  pre_commit_audit:
-    protected_paths:
-      - "sensitive/"  # Custom protected path
-```
-
-### Option 3: Extend Foundation
-
-For project-specific processes, keep separate:
-
-```
-docs/
-├── project-specific/
-│   ├── domain-model.md
-│   ├── api-spec.md
-│   └── deployment.md
-foundation/ (submodule)
-└── ...
-```
-
-## Rollback Plan
-
-If migration causes issues:
-
-1. **Remove foundation submodule:**
-
-```bash
-git submodule deinit foundation
-git rm foundation
-rm foundation-config.yaml
-```
-
-2. **Restore original documentation:**
-
-```bash
-git revert <migration-commit>
-```
-
-3. **Fix issues and try again later**
-
-## Gradual Migration
-
-You can migrate gradually:
-
-**Phase 1:** Install foundation, configure, but keep using existing docs
-
-```yaml
-# foundation-config.yaml
-documentation:
-  enforce_agent_instructions: false  # Don't enforce yet
-```
-
-**Phase 2:** Migrate development workflow
-
-- Start using foundation workflow
-- Update references in README
-
-**Phase 3:** Migrate conventions
-
-- Start using foundation conventions
-- Update linter configs
-
-**Phase 4:** Migrate security
-
-- Enable security checks
-- Add git hooks
-
-**Phase 5:** Full migration
-
-- Remove duplicate documentation
-- Enable all foundation features
-
-## Validation
-
-After migration, verify:
-
-- [ ] `./foundation/scripts/validate-setup.sh` passes
-- [ ] All team members can follow new workflow
-- [ ] CI/CD still works
-- [ ] Documentation is accessible
-- [ ] Scripts are executable
-- [ ] Configuration is correct
-
-## Troubleshooting
-
-### Issue: Submodule not updating
-
-```bash
-git submodule update --init --recursive
-git submodule update --remote foundation
-```
-
-### Issue: Scripts not executable
-
-```bash
-chmod +x foundation/scripts/*.sh
-chmod +x foundation/security/*.sh
-chmod +x foundation/development/*.sh
-```
-
-### Issue: Configuration not taking effect
-
-Check configuration file location and syntax:
-
-```bash
-# Should be in repository root
-ls foundation-config.yaml
-
-# Validate YAML syntax
-python -c "import yaml; yaml.safe_load(open('foundation-config.yaml'))"
-```
-
-### Issue: Git hooks not working
-
-```bash
-# Reinstall hooks
-cp foundation/security/pre-commit-audit.sh .git/hooks/pre-commit
-chmod +x .git/hooks/pre-commit
-
-# Test hook
-.git/hooks/pre-commit
-```
-
-## Getting Help
-
-If you encounter issues during migration:
-
-1. Check `foundation/README.md` for documentation
-2. Review `foundation-config.yaml` for configuration options
-3. Test in a separate branch first
-4. Ask for help in foundation repository
-
-## Post-Migration
-
-After successful migration:
-
-1. **Document your configuration** - Add comments to `foundation-config.yaml`
-2. **Train team** - Ensure everyone understands new processes
-3. **Monitor adoption** - Check that team is following foundation
-4. **Contribute back** - Share improvements with foundation
-5. **Stay updated** - Regularly sync foundation updates
-
-```bash
-# Regular updates
-git submodule update --remote foundation
-```
-
-
-
-
-
-
-
-
-
-
-
-
-
-