@jmruthers/pace-core 0.5.76 → 0.5.78

package/docs/style-guide.md

@@ -1,964 +0,0 @@
-# PACE Core Documentation Style Guide
-
-This comprehensive style guide ensures consistency, clarity, and maintainability across all PACE Core documentation. This is the single source of truth for documentation standards.
-
-> **📚 Navigation:** [← Documentation Home](./README.md) | [Review Report](../DOCUMENTATION_REVIEW_REPORT.md)
-
----
-
-**Last Updated:** 2025-01-XX | **Version:** v0.5.65+
-
-## 📋 Table of Contents
-
-1. [Writing Principles](#writing-principles)
-2. [Formatting Standards](#formatting-standards)
-3. [Content Structure](#content-structure)
-4. [Code Examples](#code-examples)
-5. [Cross-References](#cross-references)
-6. [Component Documentation](#component-documentation)
-7. [API Reference Standards](#api-reference-standards)
-8. [Troubleshooting Guidelines](#troubleshooting-guidelines)
-9. [Maintenance Checklist](#maintenance-checklist)
-10. [Quality Assurance](#quality-assurance)
-
-## 📝 Writing Principles
-
-### 1. Clarity First
-- **Use simple, clear language** - Avoid jargon and technical complexity
-- **Be specific** - Provide concrete examples and exact code snippets
-- **Explain the "why"** - Don't just show what to do, explain why it's important
-- **Use active voice** - "Create a component" not "A component should be created"
-- **Write for the user's context** - Consider their experience level and use case
-
-### 2. Developer-Focused
-- **Start with practical examples** - Show working code first
-- **Provide complete examples** - Include imports, setup, and usage
-- **Include error handling** - Show how to handle common issues
-- **Use realistic data** - Use meaningful variable names and values
-- **Show the complete flow** - From installation to implementation
-
-### 3. Consistent Structure
-- **Use consistent headings** - Follow the established hierarchy
-- **Standardize code blocks** - Use consistent formatting and syntax highlighting
-- **Maintain uniform examples** - Use consistent variable names and patterns
-- **Follow the template structure** - Use provided templates for consistency
-
-## 🎨 Formatting Standards
-
-### Headings
-
-```markdown
-# Main Title (H1) - Only in README files
-## Section Title (H2) - Major sections
-### Subsection (H3) - Subsections
-#### Detail (H4) - Specific details
-##### Note (H5) - Important notes
-```
-
-### Code Blocks
-
-**TypeScript/JavaScript:**
-```tsx
-// ✅ Good - Complete, runnable example
-import { useCan } from '@jmruthers/pace-core';
-
-function UserActions({ userId, scope }) {
-  const { hasPermission, isLoading } = useCan();
-  const [canEdit, setCanEdit] = useState(false);
-
-  useEffect(() => {
-    const checkPermission = async () => {
-      if (!isLoading) {
-        const editPerm = await hasPermission('update:users', { userId, scope });
-        setCanEdit(editPerm);
-      }
-    };
-    
-    checkPermission();
-  }, [hasPermission, isLoading, userId, scope]);
-
-  return (
-    <div>
-      {canEdit && <EditButton />}
-    </div>
-  );
-}
-```
-
-**SQL:**
-```sql
--- ✅ Good - Clear, commented SQL
-SELECT 
-  user_id,
-  organisation_id,
-  role,
-  status
-FROM rbac_organisation_roles 
-WHERE user_id = 'user-123' 
-  AND organisation_id = 'org-456'
-  AND status = 'active';
-```
-
-### Callouts and Alerts
-
-```markdown
-> **📚 New Developer?** Start with the [Quick Start Guide](./quick-start.md) to get up and running in 5 minutes.
-
-> **🔄 Migrating?** If you're upgrading from the legacy RBAC system, see the [Migration Guide](./migration/rbac-migration.md) for step-by-step instructions.
-
-> **⚠️ Important**: Always include organisation context in permission checks.
-
-> **💡 Tip**: Use batch permission checking for better performance when checking multiple permissions.
-```
-
-### Lists and Bullets
-
-```markdown
-- **Use bold for key terms** - Makes scanning easier
-- **Keep items parallel** - Use consistent grammar and structure
-- **Limit to 7 items** - Break longer lists into subsections
-- **Use numbered lists for steps** - When order matters
-```
-
-## 📚 Content Structure
-
-### File Organisation
-
-```
-docs/
-├── README.md                    # Main entry point
-├── INDEX.md                     # Complete documentation index
-├── getting-started/            # Onboarding content
-│   ├── installation.md
-│   ├── quick-start.md
-│   └── examples/
-├── core-concepts/              # Fundamental concepts
-│   ├── authentication.md
-│   ├── rbac-system.md
-│   └── permissions.md
-├── rbac/                       # RBAC module docs
-│   ├── README.md
-│   ├── quick-start.md
-│   ├── api-reference.md
-│   ├── examples.md
-│   ├── advanced-patterns.md
-│   └── troubleshooting.md
-├── implementation-guides/      # Practical guides
-│   ├── app-layout.md
-│   ├── permission-enforcement.md
-│   ├── data-tables.md
-│   ├── file-upload-storage.md  # NEW
-│   ├── inactivity-tracking.md  # NEW
-│   ├── organisation-security.md # NEW
-│   └── public-pages-advanced.md # NEW
-├── api-reference/              # Complete API docs
-│   ├── components.md
-│   ├── hooks.md
-│   └── types.md
-├── best-practices/             # Production patterns
-│   ├── security.md
-│   ├── performance.md
-│   └── testing.md
-├── migration/                  # Migration guides
-│   ├── MIGRATION_GUIDE.md      # NEW - Unified guide
-│   └── rbac-migration.md
-└── troubleshooting/            # Problem solving
-    ├── common-issues.md
-    └── debugging.md
-```
-
-### File Naming Conventions
-
-**Implementation Guides:**
-- `kebab-case.md` - Use hyphens for multi-word files
-- `feature-name.md` - Descriptive, feature-focused names
-- `advanced-feature-name.md` - For advanced/comprehensive guides
-
-**API Reference:**
-- `components.md` - Plural for main API files
-- `hooks.md` - Plural for hook collections
-- `types.md` - Plural for type collections
-
-**Migration Guides:**
-- `MIGRATION_GUIDE.md` - All caps for main reference
-- `v0.4.17-source-path-fix.md` - Version-specific with descriptive name
-- `rbac-migration.md` - Feature-specific migration
-
-**Troubleshooting:**
-- `common-issues.md` - General troubleshooting
-- `specific-issue-name.md` - Specific problem guides
-
-### Standard Sections
-
-Each documentation file should include:
-
-1. **Title and Description** - Clear purpose and overview
-2. **Prerequisites** - What readers need to know first
-3. **Quick Start** - Get up and running quickly
-4. **Detailed Guide** - Comprehensive coverage
-5. **Examples** - Practical, working examples
-6. **API Reference** - Complete technical details
-7. **Troubleshooting** - Common issues and solutions
-8. **Next Steps** - What to read next
-
-## 💻 Code Examples
-
-### Example Standards
-
-1. **Complete and Runnable**
-   ```tsx
-   // ✅ Good - Complete example with imports
-   import React, { useState, useEffect } from 'react';
-   import { useCan } from '@jmruthers/pace-core';
-
-   function UserActions({ userId, scope }) {
-     const { hasPermission, isLoading } = useCan();
-     const [canEdit, setCanEdit] = useState(false);
-
-     useEffect(() => {
-       const checkPermission = async () => {
-         if (!isLoading) {
-           const editPerm = await hasPermission('update:users', { userId, scope });
-           setCanEdit(editPerm);
-         }
-       };
-       
-       checkPermission();
-     }, [hasPermission, isLoading, userId, scope]);
-
-     if (isLoading) return <div>Loading permissions...</div>;
-
-     return (
-       <div>
-         {canEdit && <button>Edit User</button>}
-       </div>
-     );
-   }
-   ```
-
-2. **Error Handling Included**
-   ```tsx
-   // ✅ Good - Includes error handling
-   try {
-     const canEdit = await hasPermission('update:users', { userId, scope });
-     setCanEdit(canEdit);
-   } catch (error) {
-     console.error('Permission check failed:', error);
-     setCanEdit(false);
-   }
-   ```
-
-3. **Consistent Naming**
-   ```tsx
-   // ✅ Good - Consistent variable names
-   const userId = 'user-123';
-   const scope = { organisationId: 'org-456' };
-   const permission = 'update:users';
-   ```
-
-### Code Block Guidelines
-
-- **Use TypeScript** - Always use `.tsx` for React components
-- **Include imports** - Show all necessary imports
-- **Add comments** - Explain complex logic
-- **Handle edge cases** - Show loading states, error handling
-- **Use realistic data** - Use meaningful variable names and values
-
-## 🔗 Cross-References
-
-### Internal Links
-
-```markdown
-<!-- ✅ Good - Clear, descriptive links -->
-See the [RBAC Quick Start Guide](./rbac/quick-start.md) for a complete example.
-
-<!-- ❌ Avoid - Vague links -->
-See [this guide](./rbac/quick-start.md) for more info.
-```
-
-### Link Patterns
-
-- **Use descriptive text** - Link text should explain what the reader will find
-- **Keep links current** - Update links when files are moved or renamed
-- **Use relative paths** - Use `./` for same directory, `../` for parent directory
-- **Test all links** - Verify links work before publishing
-
-## 🧩 Component Documentation
-
-### Component Structure
-
-Each component should be documented with:
-
-1. **Overview** - What the component does
-2. **Props** - Complete prop interface with types
-3. **Usage** - Basic usage example
-4. **Variants** - Different variants and states
-5. **Accessibility** - Accessibility features and requirements
-6. **Examples** - Practical usage examples
-7. **Troubleshooting** - Common issues and solutions
-
-### Example Component Documentation
-
-```markdown
-## Button
-
-A versatile button component with multiple variants and states.
-
-### Props
-
-```typescript
-interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
-  variant?: 'default' | 'destructive' | 'outline' | 'secondary' | 'ghost' | 'link';
-  size?: 'default' | 'sm' | 'lg' | 'icon';
-  asChild?: boolean;
-  className?: string;
-}
-```
-
-### Usage
-
-```tsx
-import { Button } from '@jmruthers/pace-core';
-
-// Default button
-<Button onClick={handleClick}>
-  Click me
-</Button>
-
-// Destructive button
-<Button variant="destructive" size="lg">
-  Delete
-</Button>
-```
-
-### Variants
-
-- **default**: Primary button with solid background
-- **destructive**: Red button for dangerous actions
-- **outline**: Bordered button with transparent background
-- **secondary**: Secondary button with muted styling
-- **ghost**: Transparent button with hover effects
-- **link**: Button styled as a link
-
-### Accessibility
-
-- Supports keyboard navigation
-- Proper ARIA attributes
-- Focus management
-- Screen reader support
-```
-
-## 📋 API Reference Standards
-
-### Hook Documentation
-
-```markdown
-## useCan
-
-Hook for checking user permissions with caching and error handling.
-
-### Signature
-
-```typescript
-function useCan(): {
-  hasPermission: (permission: Permission, scope?: Scope) => Promise<boolean>;
-  hasAnyPermission: (permissions: Permission[], scope?: Scope) => Promise<boolean>;
-  hasAllPermissions: (permissions: Permission[], scope?: Scope) => Promise<boolean>;
-  isLoading: boolean;
-  error: Error | null;
-}
-```
-
-### Parameters
-
-- **permission**: The permission to check
-- **scope**: Optional scope context (organisation, event, etc.)
-
-### Returns
-
-- **hasPermission**: Function to check a single permission
-- **hasAnyPermission**: Function to check if user has any of the permissions
-- **hasAllPermissions**: Function to check if user has all permissions
-- **isLoading**: Whether the permission check is in progress
-- **error**: Any error that occurred during the check
-
-### Example
-
-```tsx
-import { useCan } from '@jmruthers/pace-core';
-
-function UserActions({ userId }) {
-  const { hasPermission, isLoading } = useCan();
-  const [canEdit, setCanEdit] = useState(false);
-
-  useEffect(() => {
-    const checkPermission = async () => {
-      const editPerm = await hasPermission('update:users', { userId });
-      setCanEdit(editPerm);
-    };
-    
-    checkPermission();
-  }, [hasPermission, userId]);
-
-  if (isLoading) return <div>Loading...</div>;
-
-  return (
-    <div>
-      {canEdit && <EditButton />}
-    </div>
-  );
-}
-```
-```
-
-## 🆘 Troubleshooting Guidelines
-
-### Common Issues Structure
-
-```markdown
-## Common Issues
-
-### Issue: Permission Check Always Returns False
-
-**Symptoms:**
-- Permission checks return false even for valid permissions
-- No error messages are displayed
-
-**Causes:**
-1. Missing organisation context
-2. Incorrect permission format
-3. User not authenticated
-
-**Solutions:**
-
-1. **Check Organisation Context**
-   ```tsx
-   // ❌ Wrong - Missing organisation context
-   const canEdit = await hasPermission('update:users');
-   
-   // ✅ Correct - Include organisation context
-   const canEdit = await hasPermission('update:users', { 
-     organisationId: currentOrganisation.id 
-   });
-   ```
-
-2. **Verify Permission Format**
-   ```tsx
-   // ❌ Wrong - Incorrect format
-   const canEdit = await hasPermission('update users');
-   
-   // ✅ Correct - Use colon format
-   const canEdit = await hasPermission('update:users');
-   ```
-
-3. **Check Authentication**
-   ```tsx
-   const { user, isLoading } = useUnifiedAuth();
-   
-   if (isLoading) return <div>Loading...</div>;
-   if (!user) return <div>Please log in</div>;
-   ```
-
-**Prevention:**
-- Always include organisation context in permission checks
-- Use TypeScript for permission type safety
-- Test permission checks in development
-```
-
-## 🔧 Maintenance Checklist
-
-### Before Publishing
-
-- [ ] **Accuracy** - All code examples work and are current
-- [ ] **Completeness** - All necessary information is included
-- [ ] **Clarity** - Content is easy to understand
-- [ ] **Consistency** - Follows style guide and patterns
-- [ ] **Code examples** - All code is tested and working
-- [ ] **Links** - All internal and external links work
-- [ ] **Formatting** - Consistent markdown formatting
-- [ ] **Images** - All images are optimized and accessible
-- [ ] **Navigation** - Clear path through the content
-- [ ] **Examples** - Practical, real-world examples
-- [ ] **Troubleshooting** - Common issues are addressed
-- [ ] **Next steps** - Clear guidance on what to do next
-
-### Regular Updates
-
-1. **Review quarterly** - Check for outdated information
-2. **Update examples** - Ensure code examples work with current versions
-3. **Test links** - Verify all links are still valid
-4. **Gather feedback** - Ask developers about confusing sections
-
-### Version Control
-
-- **Update with code changes** - Documentation should reflect current implementation
-- **Maintain changelog** - Track documentation changes
-- **Test before merging** - Verify all examples work
-- **Review with team** - Get feedback from other developers
-
-## 🎯 Quality Assurance
-
-### Content Review
-
-1. **Technical Accuracy**
-   - All code examples compile and run
-   - API references match actual implementation
-   - Import paths are correct
-   - Environment variables are accurate
-
-2. **Completeness**
-   - All exported components are documented
-   - All hooks have usage examples
-   - All props are documented with types
-   - Common use cases are covered
-
-3. **Consistency**
-   - Terminology is consistent throughout
-   - Code examples follow the same patterns
-   - Formatting is uniform
-   - Cross-references are accurate
-
-4. **User Experience**
-   - Clear navigation path
-   - Practical examples
-   - Troubleshooting guidance
-   - Next steps provided
-
-### Testing Process
-
-1. **Code Examples** - Test all code examples in isolation
-2. **Links** - Verify all internal and external links
-3. **Cross-References** - Check all cross-references are accurate
-4. **Import Paths** - Verify all import paths work
-5. **Environment Variables** - Check environment variable names
-
-### Review Process
-
-1. **Self-Review** - Author reviews against checklist
-2. **Technical Review** - Another developer reviews for accuracy
-3. **User Testing** - Test with new developers
-4. **Final Review** - Final check before publishing
-
-## 📊 Metrics and Monitoring
-
-### Documentation Health
-
-- **Broken Links** - Monitor and fix broken links
-- **Outdated Examples** - Track examples that need updates
-- **User Feedback** - Collect and act on user feedback
-- **Search Success** - Monitor search success rates
-
-### Improvement Areas
-
-- **Common Questions** - Document frequently asked questions
-- **Pain Points** - Address common developer pain points
-- **Missing Content** - Identify and fill content gaps
-- **Outdated Information** - Keep information current
-
-## 📋 Documentation Templates
-
-### Implementation Guide Template
-
-```markdown
-# [Feature Name]
-
-> **📝 Brief Description** | [← Back to Documentation](../README.md) | [↑ Table of Contents](#table-of-contents)
-
-[Brief overview of the feature and its purpose]
-
-## Overview
-
-[Detailed explanation of what the feature does and why it's useful]
-
-## Quick Start
-
-### 1. Basic Usage
-
-```tsx
-// Complete working example
-import { ComponentName } from '@jmruthers/pace-core';
-
-function MyComponent() {
-  return <ComponentName />;
-}
-```
-
-### 2. [Advanced Usage Pattern]
-
-```tsx
-// More complex example
-```
-
-## Components
-
-### [ComponentName]
-
-[Description of component]
-
-#### Props
-
-```typescript
-interface ComponentProps {
-  // Props interface
-}
-```
-
-#### Usage Examples
-
-[Multiple usage examples]
-
-## Hooks
-
-### [useHookName]
-
-[Description of hook]
-
-#### Interface
-
-```typescript
-interface UseHookReturn {
-  // Return type interface
-}
-```
-
-#### Usage Examples
-
-[Multiple usage examples]
-
-## [Additional Sections]
-
-[Feature-specific sections]
-
-## Troubleshooting
-
-### Common Issues
-
-[Common problems and solutions]
-
-## Next Steps
-
-- [Related documentation links]
-```
-
-### API Reference Template
-
-```markdown
-# [API Section] API Reference
-
-> **📚 Complete API Reference** | [← Back to Documentation](../README.md) | [↑ Table of Contents](#table-of-contents)
-
-[Brief description of the API section]
-
-## [Item Name]
-
-[Description of the item]
-
-### Props/Interface
-
-```typescript
-interface ItemProps {
-  // Interface definition
-}
-```
-
-### Usage
-
-```tsx
-// Basic usage example
-```
-
-### [Additional Sections]
-
-[Item-specific sections]
-```
-
-### Migration Guide Template
-
-```markdown
-# Migration Guide: [Version/Feature]
-
-> **🔄 Migration Instructions** | [← Back to Documentation](../README.md) | [↑ Table of Contents](#table-of-contents)
-
-[Brief description of what changed and why migration is needed]
-
-## Overview
-
-[Detailed explanation of changes]
-
-## Breaking Changes
-
-[List of breaking changes]
-
-## Migration Steps
-
-### 1. [Step Name]
-
-[Detailed step instructions]
-
-### 2. [Step Name]
-
-[Detailed step instructions]
-
-## Code Examples
-
-### Before
-
-```tsx
-// Old code
-```
-
-### After
-
-```tsx
-// New code
-```
-
-## Troubleshooting
-
-### Common Issues
-
-[Common migration problems and solutions]
-
-## Next Steps
-
-[What to do after migration]
-```
-
-### Troubleshooting Guide Template
-
-```markdown
-# [Issue Category] Troubleshooting
-
-> **🆘 Problem Solving** | [← Back to Documentation](../README.md) | [↑ Table of Contents](#table-of-contents)
-
-[Brief description of the issue category]
-
-## Common Issues
-
-### Issue: [Problem Description]
-
-**Symptoms:**
-- [Symptom 1]
-- [Symptom 2]
-
-**Causes:**
-1. [Cause 1]
-2. [Cause 2]
-
-**Solutions:**
-
-1. **[Solution Name]**
-   ```tsx
-   // Code solution
-   ```
-
-2. **[Solution Name]**
-   ```bash
-   # Command solution
-   ```
-
-**Prevention:**
-- [Prevention tip 1]
-- [Prevention tip 2]
-
-## Debug Mode
-
-[How to enable debug mode]
-
-## Getting Help
-
-[Additional resources]
-```
-
-## 🎯 Naming Conventions
-
-### File Names
-- **Implementation guides**: `kebab-case.md` (e.g., `file-upload-storage.md`)
-- **API references**: `plural-noun.md` (e.g., `components.md`, `hooks.md`)
-- **Migration guides**: `MIGRATION_GUIDE.md` or `v0.4.17-feature-name.md`
-- **Troubleshooting**: `common-issues.md` or `specific-issue-name.md`
-
-### Section Headings
-- **Use sentence case** - "Quick Start" not "Quick start"
-- **Be descriptive** - "File Upload & Storage System" not "Files"
-- **Use consistent hierarchy** - H2 for main sections, H3 for subsections
-
-### Code Examples
-- **Use realistic names** - `userId`, `organisationId`, `permission`
-- **Be consistent** - Same variable names across all examples
-- **Use meaningful values** - `'user-123'` not `'test'`
-
-### Cross-References
-- **Use descriptive link text** - "RBAC Quick Start Guide" not "this guide"
-- **Keep links current** - Update when files move
-- **Use relative paths** - `./file.md` for same directory
-
-## 📌 Quick Reference Standards
-
-### Essential Information Always Include
-
-Every documentation file should start with:
-
-```markdown
-# [Feature Name]
-
-> **🎯 Use Case**: When to use this  
-> **⏱️ Time Required**: How long to implement  
-> **Prerequisites**: What you need to know first
-
-[Brief overview - one paragraph]
-```
-
-### Standard File Structure
-
-Every guide should include:
-
-1. **Quick Start** - Complete, runnable code example that works immediately
-2. **Detailed Guide** - Comprehensive coverage
-3. **Examples** - Multiple real-world examples
-4. **Troubleshooting** - Common issues and solutions
-5. **Next Steps** - Links to related documentation
-
-## 📋 Pre-Publishing Checklist
-
-Before publishing any documentation, verify:
-
-### Content Quality
-- [ ] **Completeness**: All necessary information included
-- [ ] **Accuracy**: Information is current and correct
-- [ ] **Clarity**: Language is clear and accessible
-- [ ] **Consistency**: Follows style guide and conventions
-
-### Code Examples
-- [ ] **Complete Examples** - All code examples are runnable and complete
-- [ ] **Error Handling** - Examples include proper error handling
-- [ ] **TypeScript** - All examples use TypeScript with proper types
-- [ ] **Imports** - All necessary imports are shown
-- [ ] **Comments** - Complex logic is explained with comments
-- [ ] **Best Practices** - Examples follow PACE Core best practices
-
-### Navigation & Cross-References
-- [ ] **Navigation**: Proper breadcrumbs and cross-references
-- [ ] **Version Metadata**: Up-to-date version information
-- [ ] **Links**: All internal and external links verified
-- [ ] **Headings**: Proper heading hierarchy (H1 → H2 → H3)
-
-### Formatting & Structure
-- [ ] **Headings**: Use proper heading hierarchy
-- [ ] **Lists**: Use consistent list formatting
-- [ ] **Code Blocks**: Use proper language tags
-- [ ] **Tables**: Use proper table formatting
-- [ ] **Accessibility**: Proper formatting for screen readers
-
-### Review Process
-- [ ] **Self-Review**: Read aloud for clarity, test all examples
-- [ ] **Link Check**: Verify all links work
-- [ ] **Spell Check**: Use spell check tools
-- [ ] **Grammar Check**: Use grammar check tools
-
----
-
-## 🔄 Maintenance Procedures
-
-### When to Update Documentation
-
-**Automatically Update**:
-- When introducing breaking changes
-- When adding new features
-- When fixing bugs that affect documented behavior
-- When deprecating functionality
-
-**Regularly Review**:
-- Quarterly comprehensive audit
-- Monthly link verification
-- After major version releases
-
-### Deprecation Process
-
-```markdown
-> **⚠️ Deprecated**: This pattern is deprecated as of v0.5.65
-
-## Deprecated Pattern
-
-[Old way - marked as deprecated]
-
-## Recommended Replacement
-
-[New way - with migration guide]
-
-See [Migration Guide](./migration/) for details.
-```
-
-### Version References
-
-Always include version information:
-
-```markdown
-> **Version**: 0.5.65+  
-> **Breaking Changes**: None  
-> **New Features**: Auto-save functionality
-
-> **Version**: v2.0.0+  
-> **Breaking Changes**: Service architecture changes  
-> **Migration Required**: Yes - see [Migration Guide](./migration/)
-```
-
-## 🤖 Documentation Automation
-
-### Recommended Tools
-
-1. **Link Checking**: Automatic broken link detection
-2. **Code Validation**: Test code examples
-3. **Spell Checking**: Automated grammar/spell check
-4. **Version Checking**: Ensure version references are current
-
-### CI/CD Integration
-
-```yaml
-# Example GitHub Actions workflow
-name: Documentation Checks
-
-on: [push, pull_request]
-
-jobs:
-  docs:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v3
-      - run: npm install
-      - run: npm run docs:check  # Check all examples
-      - run: npm run docs:links  # Check all links
-      - run: npm run docs:spell  # Spell check
-```
-
-## 📊 Metrics and Success
-
-### Quality Metrics
-
-**Quantitative**:
-- 100% of exported features documented
-- 100% of code examples runnable
-- 0 broken internal links
-- 95%+ terminology consistency
-
-**Qualitative**:
-- Developer feedback scores
-- Time to first success
-- Support ticket reduction
-- Onboarding completion rate
-
-### Improvement Process
-
-1. **Collect Feedback**: Developer surveys, support tickets
-2. **Analyze Issues**: Identify pain points
-3. **Plan Updates**: Prioritize improvements
-4. **Implement Changes**: Update documentation
-5. **Measure Impact**: Track improvements
-
----
-
-This comprehensive style guide ensures that PACE Core documentation is consistent, helpful, and maintainable. Follow these guidelines to create excellent developer documentation that helps users succeed with the library.
-
-**Related Resources**:
-- [Documentation Style Checklist](./documentation-style-checklist.md) - Quick checklist for reviews
-- [Quick Reference](./quick-reference.md) - Common patterns and examples