refactor(rules): consolidate type safety content and clean software development ruleset

- Remove duplicate content and restore file integrity in software_development.mdc
- Add comprehensive Type Safety Enforcement section to type_safety_guide.mdc
- Clean up file structure and eliminate corruption from duplicate sections
- Move type safety patterns and guidelines to appropriate specialized guide

.cursor/rules/development/type_safety_guide.mdc

@@ -40,6 +40,23 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 
    - Avoid `(obj as any)[k]`.
 
+## Type Safety Enforcement
+
+### Core Type Safety Rules
+- **No `any` Types**: Use explicit types or `unknown` with proper type guards
+- **Error Handling Uses Guards**: Implement and reuse type guards from `src/interfaces/**`
+- **Dynamic Property Access**: Use `keyof` + `in` checks for type-safe property access
+
+### Type Guard Patterns
+- **API Errors**: Use `isApiError(error)` guards for API error handling
+- **Database Errors**: Use `isDatabaseError(error)` guards for database operations
+- **Axios Errors**: Implement `isAxiosError(error)` guards for HTTP error handling
+
+### Implementation Guidelines
+- **Avoid Type Assertions**: Replace `as any` with proper type guards and interfaces
+- **Narrow Types Properly**: Use type guards to narrow `unknown` types safely
+- **Document Type Decisions**: Explain complex type structures and their purpose
+
 ## Minimal Special Cases (document in PR when used)
 
 - **Vue refs / instances**: Use `ComponentPublicInstance` or specific component

.cursor/rules/software_development.mdc

@@ -1,6 +1,3 @@
----
-alwaysApply: true
----
 
 # Software Development Ruleset
 
@@ -89,90 +86,59 @@ Specialized guidelines for software development tasks including code review, deb
 - [ ] Solution complexity justified by evidence
 - [ ] Simpler alternatives considered and documented
 - [ ] Impact on existing systems assessed
-# Software Development Ruleset
+- [ ] Dependencies validated and accessible
+- [ ] Environment impact assessed for team members
+- [ ] Pre-build validation implemented where appropriate
 
-## Purpose
+## Additional Core Principles
-Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing.
 
-## Core Principles
+### 4. Dependency Management & Environment Validation
+- **Pre-build Validation**: Always validate critical dependencies before executing build scripts
+- **Environment Consistency**: Ensure team members have identical development environments
+- **Dependency Verification**: Check that required packages are installed and accessible
+- **Path Resolution**: Use `npx` for local dependencies to avoid PATH issues
 
-### 1. Evidence-First Development
+## Additional Required Workflows
-- **Code Citations Required**: Always cite specific file:line references when making claims
-- **Execution Path Tracing**: Trace actual code execution before proposing architectural changes
-- **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based"
 
-### 2. Code Review Standards
+### Dependency Validation (Before Proposing Changes)
-- **Trace Before Proposing**: Always trace execution paths before suggesting changes
+- [ ] **Dependency Validation**: Verify all required dependencies are available and accessible
-- **Evidence Over Inference**: Prefer code citations over logical deductions
-- **Scope Validation**: Confirm the actual scope of problems before proposing solutions
 
-### 3. Problem-Solution Validation
+### Environment Impact Assessment (During Solution Design)
-- **Problem Scope**: Does the solution address the actual problem?
+- [ ] **Environment Impact**: Assess how changes affect team member setups
-- **Evidence Alignment**: Does the solution match the evidence?
-- **Complexity Justification**: Is added complexity justified by real needs?
-- **Alternative Analysis**: What simpler solutions were considered?
 
-## Required Workflows
+## Additional Competence Hooks
 
-### Before Proposing Changes
+### Dependency & Environment Management
-- [ ] **Code Path Tracing**: Map execution flow from entry to exit
+- **"What dependencies does this feature require and are they properly declared?"**
-- [ ] **Evidence Collection**: Gather specific code citations and logs
+- **"How will this change affect team member development environments?"**
-- [ ] **Assumption Surfacing**: Identify what's proven vs. inferred
+- **"What validation can we add to catch dependency issues early?"**
-- [ ] **Scope Validation**: Confirm the actual extent of the problem
 
-### During Solution Design
+## Dependency Management Best Practices
-- [ ] **Evidence Alignment**: Ensure solution addresses proven problems
-- [ ] **Complexity Assessment**: Justify any added complexity
-- [ ] **Alternative Evaluation**: Consider simpler approaches first
-- [ ] **Impact Analysis**: Assess effects on existing systems
 
-## Software-Specific Competence Hooks
+### Pre-build Validation
+- **Check Critical Dependencies**: Validate essential tools before executing build scripts
+- **Use npx for Local Dependencies**: Prefer `npx tsx` over direct `tsx` to avoid PATH issues
+- **Environment Consistency**: Ensure all team members have identical dependency versions
 
-### Evidence Validation
+### Common Pitfalls
-- **"What code path proves this claim?"**
+- **Missing npm install**: Team members cloning without running `npm install`
-- **"How does data actually flow through the system?"**
+- **PATH Issues**: Direct command execution vs. npm script execution differences
-- **"What am I assuming vs. what can I prove?"**
+- **Version Mismatches**: Different Node.js/npm versions across team members
 
-### Code Tracing
+### Validation Strategies
-- **"What's the execution path from user action to system response?"**
+- **Dependency Check Scripts**: Implement pre-build validation for critical dependencies
-- **"Which components actually interact in this scenario?"**
+- **Environment Requirements**: Document and enforce minimum Node.js/npm versions
-- **"Where does the data originate and where does it end up?"**
+- **Onboarding Checklist**: Standardize team member setup procedures
 
-### Architecture Decisions
+### Error Messages and Guidance
-- **"What evidence shows this change is necessary?"**
+- **Specific Error Context**: Provide clear guidance when dependency issues occur
-- **"What simpler solution could achieve the same goal?"**
+- **Actionable Solutions**: Direct users to specific commands (`npm install`, `npm run check:dependencies`)
-- **"How does this change affect the existing system architecture?"**
+- **Environment Diagnostics**: Implement comprehensive environment validation tools
-
-## Integration with Other Rulesets
-
-### With base_context.mdc
-- Inherits generic competence principles
-- Adds software-specific evidence requirements
-- Maintains collaboration and learning focus
-
-### With research_diagnostic.mdc
-- Enhances investigation with code path tracing
-- Adds evidence validation to diagnostic workflow
-- Strengthens problem identification accuracy
-
-## Usage Guidelines
 
-### When to Use This Ruleset
+### Build Script Enhancements
-- Code reviews and architectural decisions
+- **Early Validation**: Check dependencies before starting build processes
-- Bug investigation and debugging
+- **Graceful Degradation**: Continue builds when possible but warn about issues
-- Performance optimization
+- **Helpful Tips**: Remind users about dependency management best practices
-- Feature implementation planning
-- Testing strategy development
-
-### When to Combine with Others
-- **base_context + software_development**: General development tasks
-- **research_diagnostic + software_development**: Technical investigations
-- **All three**: Complex architectural decisions or major refactoring
 
-## Self-Check (model, before responding)
+- **Narrow Types Properly**: Use type guards to narrow `unknown` types safely
-- [ ] Code path traced and documented
+- **Document Type Decisions**: Explain complex type structures and their purpose
-- [ ] Evidence cited with specific file:line references
-- [ ] Assumptions clearly flagged as proven vs. inferred
-- [ ] Solution complexity justified by evidence
-- [ ] Simpler alternatives considered and documented
-- [ ] Impact on existing systems assessed