diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 36c5ebdae..1be501fe8 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -60,6 +60,77 @@ If no user-facing changelog entry is needed, apply the skip-changelog label to t
 
 ---
 
+## Risk Assessment
+
+<!--
+Evaluate the risk level of this PR and potential impact on production.
+This helps reviewers prioritize and determine the appropriate review rigor.
+-->
+
+**Risk Level:** <!-- Choose one: Low | Medium | High | Critical -->
+
+**Potential Impact:**
+<!-- Describe what could go wrong if this change has bugs. Examples:
+- Low: Typo in documentation, minor style tweak
+- Medium: New feature in isolated component, refactor with test coverage
+- High: Changes to core authentication, database schema changes
+- Critical: Payment processing, security fixes, data migrations
+-->
+
+**Mitigation Steps:**
+<!-- What steps have been taken to reduce risk? Examples:
+- Comprehensive test coverage (unit, integration, E2E)
+- Feature flag for gradual rollout
+- Tested in staging environment
+- Reversible database migration
+- Monitoring and alerting in place
+-->
+
+---
+
+## How to Test
+
+<!--
+Provide clear, step-by-step instructions for testing this PR.
+Include:
+- Prerequisites (data setup, feature flags, environment variables)
+- User flows to test
+- Expected results for each step
+- Edge cases to verify
+- Screenshots or videos demonstrating the changes (for UI changes)
+-->
+
+### Prerequisites
+
+<!-- Example:
+- Create a test user account
+- Enable feature flag: `FEATURE_NEW_DASHBOARD=true`
+- Seed database with sample data: `npm run db:seed`
+-->
+
+### Test Steps
+
+1. **Step 1:** <!-- Describe action and expected result -->
+2. **Step 2:** <!-- Describe action and expected result -->
+3. **Step 3:** <!-- Describe action and expected result -->
+
+### Expected Results
+
+<!-- Describe what success looks like. Include screenshots or videos for UI changes. -->
+
+### Edge Cases to Verify
+
+<!-- List edge cases that should be tested. Examples:
+- [ ] Empty state (no data)
+- [ ] Maximum data (performance test)
+- [ ] Error handling (network failure, invalid input)
+- [ ] Mobile/responsive design
+- [ ] Accessibility (keyboard navigation, screen reader)
+- [ ] Browser compatibility (Chrome, Firefox, Safari)
+-->
+
+---
+
 ### Checklist (Global DoD / PR)
 
 - [ ] All AC met and demonstrated
@@ -69,6 +140,8 @@ If no user-facing changelog entry is needed, apply the skip-changelog label to t
 - [ ] Security/perf impact reviewed where relevant
 - [ ] Code/design reviews approved
 - [ ] CI green; linked issues closed; release notes prepared (if shipping)
+- [ ] Risk assessment completed above
+- [ ] Testing instructions provided above
 
 ---
 
diff --git a/.github/workflows/label-sync.yml b/.github/workflows/label-sync.yml
new file mode 100644
index 000000000..2208bd731
--- /dev/null
+++ b/.github/workflows/label-sync.yml
@@ -0,0 +1,403 @@
+---
+name: Label Sync • Organization-wide Label Management
+
+# This workflow syncs labels from the canonical labels.yml to repositories
+# and detects orphan labels that don't match the organization standard.
+
+on:
+  # Run on push to labels.yml
+  push:
+    branches: [develop, main]
+    paths:
+      - '.github/automation/labels.yml'
+      - '.github/workflows/label-sync.yml'
+
+  # Run on schedule (weekly on Monday)
+  schedule:
+    - cron: '0 9 * * 1' # 9 AM UTC every Monday
+
+  # Allow manual trigger
+  workflow_dispatch:
+    inputs:
+      dry_run:
+        description: 'Dry run mode (preview changes without applying)'
+        required: false
+        default: 'false'
+        type: choice
+        options:
+          - 'true'
+          - 'false'
+      target_repo:
+        description: 'Target repository (org/repo) or "all" for all repos'
+        required: false
+        default: 'all'
+        type: string
+
+  # Reusable workflow for child repositories
+  workflow_call:
+    inputs:
+      labels_source_repo:
+        description: 'Repository containing canonical labels.yml'
+        required: false
+        default: 'lightspeedwp/.github'
+        type: string
+      labels_source_path:
+        description: 'Path to labels.yml in source repository'
+        required: false
+        default: '.github/automation/labels.yml'
+        type: string
+      dry_run:
+        description: 'Dry run mode (preview only)'
+        required: false
+        default: false
+        type: boolean
+
+permissions:
+  contents: read
+  issues: write
+  pull-requests: write
+
+env:
+  LABELS_SOURCE_REPO: ${{ inputs.labels_source_repo || 'lightspeedwp/.github' }}
+  LABELS_SOURCE_PATH: ${{ inputs.labels_source_path || '.github/automation/labels.yml' }}
+  DRY_RUN: ${{ inputs.dry_run || 'false' }}
+
+jobs:
+  sync-labels:
+    name: Sync Labels from Canonical Source
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: |
+          npm install --no-save js-yaml @actions/core @actions/github
+
+      - name: Fetch canonical labels
+        id: fetch-labels
+        uses: actions/github-script@v7
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const yaml = require('js-yaml');
+            const fs = require('fs');
+
+            // Fetch canonical labels.yml from source repository
+            const sourceRepo = process.env.LABELS_SOURCE_REPO.split('/');
+            const sourcePath = process.env.LABELS_SOURCE_PATH;
+
+            let canonicalLabels;
+
+            try {
+              // If running in the .github repo itself, read from local file
+              if (context.repo.owner === sourceRepo[0] && context.repo.repo === sourceRepo[1]) {
+                core.info('Running in source repository, reading local labels.yml');
+                canonicalLabels = yaml.load(fs.readFileSync(sourcePath, 'utf8'));
+              } else {
+                // Fetch from remote repository
+                core.info(`Fetching canonical labels from ${process.env.LABELS_SOURCE_REPO}/${sourcePath}`);
+                const { data } = await github.rest.repos.getContent({
+                  owner: sourceRepo[0],
+                  repo: sourceRepo[1],
+                  path: sourcePath,
+                  ref: 'develop'
+                });
+
+                const content = Buffer.from(data.content, 'base64').toString('utf8');
+                canonicalLabels = yaml.load(content);
+              }
+
+              core.info(`Loaded ${canonicalLabels.length} canonical labels`);
+              core.setOutput('canonical_labels', JSON.stringify(canonicalLabels));
+
+              return canonicalLabels;
+            } catch (error) {
+              core.setFailed(`Failed to fetch canonical labels: ${error.message}`);
+              throw error;
+            }
+
+      - name: Get current repository labels
+        id: current-labels
+        uses: actions/github-script@v7
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const labels = await github.paginate(github.rest.issues.listLabelsForRepo, {
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              per_page: 100
+            });
+
+            core.info(`Found ${labels.length} existing labels in repository`);
+            core.setOutput('current_labels', JSON.stringify(labels));
+
+            return labels;
+
+      - name: Sync labels to repository
+        id: sync
+        uses: actions/github-script@v7
+        env:
+          DRY_RUN: ${{ env.DRY_RUN }}
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const canonicalLabels = JSON.parse('${{ steps.fetch-labels.outputs.canonical_labels }}');
+            const currentLabels = JSON.parse('${{ steps.current-labels.outputs.current_labels }}');
+            const dryRun = process.env.DRY_RUN === 'true';
+
+            // Validate label arrays using ajv
+            const Ajv = require('ajv');
+            const ajv = new Ajv();
+            const labelSchema = {
+              type: 'array',
+              items: {
+                type: 'object',
+                properties: {
+                  name: { type: 'string' }
+                },
+                required: ['name'],
+                additionalProperties: true
+              }
+            };
+            const validate = ajv.compile(labelSchema);
+            if (!validate(currentLabels)) {
+              throw new Error('currentLabels JSON does not match expected schema: ' + ajv.errorsText(validate.errors));
+            }
+            if (!validate(canonicalLabels)) {
+              throw new Error('canonicalLabels JSON does not match expected schema: ' + ajv.errorsText(validate.errors));
+            }
+            const changes = {
+              added: [],
+              updated: [],
+              deleted: [],
+              orphaned: []
+            };
+
+            // Create map of current labels for quick lookup
+            const currentLabelMap = new Map(
+              currentLabels.map(l => [l.name.toLowerCase(), l])
+            );
+
+            // Create map of canonical labels
+            const canonicalLabelMap = new Map(
+              canonicalLabels.map(l => [l.name.toLowerCase(), l])
+            );
+
+            // Sync canonical labels (add or update)
+            for (const label of canonicalLabels) {
+              const current = currentLabelMap.get(label.name.toLowerCase());
+
+              if (!current) {
+                // Label doesn't exist, create it
+                changes.added.push(label.name);
+
+                if (!dryRun) {
+                  await github.rest.issues.createLabel({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    name: label.name,
+                    color: label.color,
+                    description: label.description || ''
+                  });
+                  core.info(`✅ Created label: ${label.name}`);
+                } else {
+                  core.info(`[DRY RUN] Would create label: ${label.name}`);
+                }
+              } else if (
+                current.color.toLowerCase() !== label.color.toLowerCase() ||
+                (current.description || '') !== (label.description || '')
+              ) {
+                // Label exists but needs update
+                changes.updated.push(label.name);
+
+                if (!dryRun) {
+                  await github.rest.issues.updateLabel({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    name: label.name,
+                    color: label.color,
+                    description: label.description || ''
+                  });
+                  core.info(`🔄 Updated label: ${label.name}`);
+                } else {
+                  core.info(`[DRY RUN] Would update label: ${label.name}`);
+                }
+              }
+            }
+
+            // Detect orphan labels (exist in repo but not in canonical)
+            for (const current of currentLabels) {
+              if (!canonicalLabelMap.has(current.name.toLowerCase())) {
+                // Fetch usage count for the orphan label
+                let usageCount = 0;
+                try {
+                  const searchQuery = `label:"${current.name}" repo:${context.repo.owner}/${context.repo.repo}`;
+                  const searchResult = await github.rest.search.issuesAndPullRequests({
+                    q: searchQuery,
+                    per_page: 1 // We only need the total_count
+                  });
+                  usageCount = searchResult.data.total_count || 0;
+                } catch (error) {
+                  core.warning(`Failed to fetch usage count for label "${current.name}": ${error.message}`);
+                }
+                changes.orphaned.push({
+                  name: current.name,
+                  color: current.color,
+                  description: current.description || '',
+                  usage_count: usageCount
+                });
+                core.warning(`⚠️  Orphan label detected: ${current.name} (used on ${usageCount} issues/PRs)`);
+              }
+            }
+
+            // Output summary
+            core.summary
+              .addHeading('Label Sync Summary')
+              .addHeading(`Mode: ${dryRun ? '🔍 DRY RUN (Preview Only)' : '✅ Live Sync'}`, 3)
+              .addTable([
+                [
+                  { data: 'Action', header: true },
+                  { data: 'Count', header: true }
+                ],
+                ['Added', changes.added.length.toString()],
+                ['Updated', changes.updated.length.toString()],
+                ['Orphaned', changes.orphaned.length.toString()]
+              ]);
+
+            if (changes.added.length > 0) {
+              core.summary.addHeading('Added Labels', 3);
+              core.summary.addList(changes.added);
+            }
+
+            if (changes.updated.length > 0) {
+              core.summary.addHeading('Updated Labels', 3);
+              core.summary.addList(changes.updated);
+            }
+
+            if (changes.orphaned.length > 0) {
+              core.summary.addHeading('Orphaned Labels (Not in Canonical Set)', 3);
+              core.summary.addRaw(
+                'The following labels exist in this repository but are not defined in the canonical labels.yml. ' +
+                'Consider either adding them to labels.yml or removing them if they are no longer needed.'
+              );
+              core.summary.addList(changes.orphaned.map(l =>
+                `**${l.name}** - ${l.description || 'No description'}`
+              ));
+            }
+
+            await core.summary.write();
+
+            core.setOutput('changes', JSON.stringify(changes));
+            core.setOutput('orphaned_count', changes.orphaned.length);
+
+            return changes;
+
+      - name: Create orphan labels issue
+        if: steps.sync.outputs.orphaned_count > 0 && env.DRY_RUN == 'false'
+        uses: actions/github-script@v7
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const changes = JSON.parse('${{ steps.sync.outputs.changes }}');
+
+            if (changes.orphaned.length === 0) {
+              return;
+            }
+
+            // Check if there's already an open issue about orphan labels
+            const existingIssues = await github.rest.issues.listForRepo({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              state: 'open',
+              labels: 'type:automation,area:labels',
+              per_page: 100
+            });
+
+            const orphanIssue = existingIssues.data.find(issue =>
+              issue.title.includes('Orphan Labels Detected')
+            );
+
+            const orphanList = changes.orphaned.map(l =>
+              `- \`${l.name}\` - ${l.description || '_No description_'}`
+            ).join('\n');
+
+            const issueBody = `## Orphan Labels Detected
+
+            The label sync workflow has detected ${changes.orphaned.length} label(s) that exist in this repository but are not defined in the canonical [labels.yml](https://github.com/lightspeedwp/.github/blob/develop/.github/automation/labels.yml).
+
+            ### Orphaned Labels
+
+            ${orphanList}
+
+            ### Recommended Actions
+
+            1. **Add to canonical labels.yml** - If these labels should be organization-wide, add them to [lightspeedwp/.github](https://github.com/lightspeedwp/.github/blob/develop/.github/automation/labels.yml)
+            2. **Remove from this repository** - If these labels are no longer needed, remove them
+            3. **Repository-specific labels** - If these are repository-specific, document them in this repository's README
+
+            ### How to Add to Canonical Labels
+
+            \`\`\`yaml
+            # Add to .github/automation/labels.yml in lightspeedwp/.github repository
+            ${changes.orphaned.map(l => `
+            - name: ${l.name}
+              color: ${l.color}
+              description: "${l.description || 'TODO: Add description'}"
+            `).join('')}
+            \`\`\`
+
+            ---
+
+            **Detected by:** [Label Sync Workflow](https://github.com/${context.repo.owner}/${context.repo.repo}/actions/workflows/label-sync.yml)
+            **Last Run:** ${new Date().toISOString()}
+            `;
+
+            if (orphanIssue) {
+              // Update existing issue
+              await github.rest.issues.update({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: orphanIssue.number,
+                body: issueBody
+              });
+
+              await github.rest.issues.createComment({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: orphanIssue.number,
+                body: `🔄 Updated orphan labels list. ${changes.orphaned.length} orphan label(s) currently detected.`
+              });
+
+              core.info(`Updated existing orphan labels issue #${orphanIssue.number}`);
+            } else {
+              // Create new issue
+              const newIssue = await github.rest.issues.create({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                title: `🏷️ Orphan Labels Detected (${changes.orphaned.length})`,
+                body: issueBody,
+                labels: ['type:automation', 'area:labels', 'status:needs-triage']
+              });
+
+              core.info(`Created new orphan labels issue #${newIssue.data.number}`);
+            }
+
+      - name: Summary
+        if: always()
+        run: |
+          echo "### Label Sync Complete 🎉" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "See the workflow summary above for details on added, updated, and orphaned labels." >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "**Source:** \`${{ env.LABELS_SOURCE_REPO }}/${{ env.LABELS_SOURCE_PATH }}\`" >> $GITHUB_STEP_SUMMARY
+          echo "**Mode:** \`${{ env.DRY_RUN == 'true' && 'DRY RUN' || 'LIVE SYNC' }}\`" >> $GITHUB_STEP_SUMMARY
diff --git a/CODEOWNERS b/CODEOWNERS
index 102b87bfb..94990582b 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1,7 +1,43 @@
 # CODEOWNERS for LightSpeed WP Scripts
-
+# Assign reviewers for critical paths in the repository
 # See <https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners>
 
-# All files in the repo
-
+# Global Owner (fallback for all files)
 * @ashleyshaw @lightspeedwp
+
+# Governance and Documentation
+/GOVERNANCE.md @ashleyshaw @krugazul
+/CONTRIBUTING.md @ashleyshaw @krugazul
+/CODE_OF_CONDUCT.md @ashleyshaw
+/SECURITY.md @ashleyshaw @krugazul
+/README.md @ashleyshaw
+
+# Workflows and Automation (critical for org-wide automation)
+/.github/workflows/ @ashleyshaw @krugazul
+/.github/automation/ @ashleyshaw @krugazul
+
+# Labels and Issue Types (critical for automation)
+/.github/automation/labels.yml @ashleyshaw @krugazul
+/.github/automation/issue-types.yml @ashleyshaw @krugazul
+/.github/automation/labeler.yml @ashleyshaw
+
+# AI and Copilot Instructions
+/.github/custom-instructions.md @ashleyshaw
+/.github/agents/ @ashleyshaw
+/.github/chatmodes/ @ashleyshaw
+/.github/prompts/ @ashleyshaw
+/CLAUDE.md @ashleyshaw
+/GEMINI.md @ashleyshaw
+/AGENTS.md @ashleyshaw
+
+# Core Documentation
+/docs/ @ashleyshaw @krugazul
+
+# Scripts (validation, automation, testing)
+/scripts/ @ashleyshaw @eleshar
+
+# Tests (quality assurance)
+/tests/ @ashleyshaw @eleshar
+
+# Schemas (JSON validation)
+/schemas/ @ashleyshaw
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index 46af728ba..0e52a2093 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -51,6 +51,120 @@ Contributors may be promoted to maintainer after a significant number of high-qu
 ## Change Process
 
 - Governance changes are proposed via pull request and require review and approval from at least one maintainer.
+- All changes must follow the standard contribution workflow defined in [CONTRIBUTING.md](CONTRIBUTING.md).
+
+---
+
+## Exception Process
+
+### When Repositories Can Override Defaults
+
+While this `.github` repository provides organization-wide defaults, individual repositories may need to deviate from these standards in specific circumstances.
+
+#### Permitted Exceptions
+
+1. **Repository-Specific Labels** – Additional labels beyond the canonical set for domain-specific needs
+2. **Custom Workflows** – Project-specific automation or CI/CD requirements
+3. **Alternative Templates** – Specialized issue/PR templates for unique workflows
+4. **Branch Protection Rules** – Stricter or alternative rules for security/compliance
+
+#### Exception Documentation Requirements
+
+All exceptions must be documented in the repository's README.md with:
+
+- **Rationale** – Clear explanation of why the exception is necessary
+- **Scope** – What specifically deviates from org-wide standards
+- **Review Date** – When the exception will be revisited (maximum 6 months)
+- **Owner** – Maintainer responsible for the exception
+
+**Example:**
+
+```markdown
+## Governance Exceptions
+
+### Custom Labels
+
+**Exception:** This repository uses additional labels not in the canonical set:
+- `priority:p0` - Production outage (beyond `priority:critical`)
+- `team:platform` - Platform team ownership
+
+**Rationale:** Platform team requires finer-grained priority levels for on-call rotation.
+
+**Review Date:** 2025-06-01
+
+**Owner:** @ashleyshaw
+```
+
+#### Requesting Exceptions
+
+1. Open a discussion in the `.github` repository explaining the need
+2. Maintainers review and provide feedback within 5 business days
+3. If approved, document the exception per requirements above
+4. Revisit exceptions during scheduled governance reviews
+
+#### Revisiting Divergence
+
+- **Quarterly Reviews** – Maintainers review all documented exceptions every quarter
+- **Consolidation** – Successful exceptions may be promoted to org-wide standards
+- **Deprecation** – Unnecessary exceptions are deprecated with 30-day notice
+
+---
+
+## Release Cadence
+
+### Organization-Wide Repository Updates
+
+This `.github` repository follows a regular release cadence to ensure predictable updates across the organization:
+
+#### Release Schedule
+
+- **Minor Updates** – Fortnightly (every 2 weeks) on Wednesdays
+- **Major Updates** – Quarterly (January, April, July, October)
+- **Hotfixes** – As needed for critical fixes, within 24 hours
+
+#### Release Process
+
+1. **Planning** – Updates planned and scoped in GitHub Projects
+2. **Development** – Changes developed in feature branches following [BRANCHING_STRATEGY.md](.github/automation/BRANCHING_STRATEGY.md)
+3. **Testing** – All changes tested with CI/CD before merge to `develop`
+4. **Review** – Minimum one maintainer approval required
+5. **Release** – Tagged release created with changelog and migration guide
+6. **Notification** – Organization notified via GitHub Discussions announcement
+
+#### Maintenance Windows
+
+- **Standard Updates** – No maintenance window, changes are backwards-compatible
+- **Breaking Changes** – Announced 2 weeks in advance with migration guide
+- **Emergency Hotfixes** – Immediate deployment with post-deployment notification
+
+#### Rollback Steps
+
+If a release causes issues in dependent repositories:
+
+1. **Identify Issue** – Report via GitHub issue with `priority:critical` label
+2. **Assess Impact** – Maintainers assess severity and scope within 2 hours
+3. **Rollback Decision** – Determine if rollback or forward fix is appropriate
+4. **Execute Rollback** – Revert to previous release tag and deploy
+5. **Post-Mortem** – Document incident and preventive measures
+
+**Rollback Commands:**
+
+```bash
+# Rollback to previous release
+git checkout tags/v1.2.3
+git push origin develop --force-with-lease
+
+# Or create hotfix branch from previous stable
+git checkout -b hotfix/rollback-v1.2.4 tags/v1.2.3
+```
+
+#### Version Compatibility
+
+- **Backwards Compatibility** – Minor releases maintain backwards compatibility
+- **Deprecation Policy** – Features deprecated with 3-month notice before removal
+- **Migration Support** – Breaking changes include automated migration scripts where possible
+
+---
 
 ## Reporting & Contact
 
diff --git a/README.md b/README.md
index c063f648c..bccaf6560 100644
--- a/README.md
+++ b/README.md
@@ -433,6 +433,309 @@ All LightSpeed repositories should:
 
 ---
 
+## Consumer Guide: Reusing Workflows and Syncing Labels
+
+This section provides practical examples for consuming repositories to adopt LightSpeed organization standards.
+
+### 1. Syncing Labels from Canonical Source
+
+All LightSpeed repositories should sync labels from the canonical [labels.yml](./.github/automation/labels.yml) to ensure consistency.
+
+#### Option A: Call Reusable Label Sync Workflow
+
+Create `.github/workflows/label-sync.yml` in your repository:
+
+```yaml
+name: Label Sync
+
+on:
+  schedule:
+    - cron: '0 9 * * 1' # Weekly on Monday at 9 AM UTC
+  workflow_dispatch:
+
+jobs:
+  sync:
+    uses: lightspeedwp/.github/.github/workflows/label-sync.yml@develop
+    with:
+      labels_source_repo: 'lightspeedwp/.github'
+      labels_source_path: '.github/automation/labels.yml'
+      dry_run: false
+    secrets: inherit
+```
+
+**What this does:**
+- Automatically syncs labels weekly
+- Adds missing labels from canonical source
+- Updates existing labels with new colors/descriptions
+- Detects and reports orphan labels
+
+#### Option B: Manual Label Sync (One-Time)
+
+Use the GitHub CLI to sync labels manually:
+
+```bash
+# Install GitHub CLI: https://cli.github.com/
+
+# Sync labels from canonical source
+gh label clone lightspeedwp/.github --repo yourorg/yourrepo
+```
+
+### 2. Reusing Issue/PR Labeling Workflow
+
+Adopt automated labeling based on file paths, branch names, and issue templates.
+
+Create `.github/workflows/labeling.yml`:
+
+```yaml
+name: Auto-Labeling
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened]
+  issues:
+    types: [opened, edited, reopened]
+
+jobs:
+  labeling:
+    uses: lightspeedwp/.github/.github/workflows/labeling.yml@develop
+    secrets: inherit
+```
+
+**What this does:**
+- Applies labels based on PR branch names (e.g., `feat/` → `type:feature`)
+- Applies labels based on modified file paths (e.g., `*.php` → `lang:php`)
+- Enforces status workflow (e.g., new issues → `status:needs-triage`)
+- Ensures exactly one status label per issue/PR
+
+### 3. Using Canonical Issue Templates
+
+Copy issue templates from this repository to ensure consistent triage and automation:
+
+```bash
+# Copy issue templates to your repository
+cp -r .github/ISSUE_TEMPLATE /path/to/your/repo/.github/
+
+# Or create a symlink (for local development)
+ln -s ../../.github/.github/ISSUE_TEMPLATE /path/to/your/repo/.github/ISSUE_TEMPLATE
+```
+
+**Available Templates:**
+- Bug Report (`bug-report.yml`)
+- Feature Request (`feature-request.yml`)
+- Documentation (`documentation.yml`)
+- Security Issue (`security.yml`)
+- Task (`task.yml`)
+- Chore (`chore.yml`)
+
+### 4. Adopting Pull Request Templates
+
+Use the canonical PR template with risk assessment and testing prompts:
+
+```bash
+# Copy PR template
+cp .github/pull_request_template.md /path/to/your/repo/.github/
+
+# Or reference it directly in your repository's settings
+# GitHub → Settings → Pull Requests → Template repository: lightspeedwp/.github
+```
+
+### 5. Implementing Branch Naming Conventions
+
+Adopt LightSpeed branch naming for automatic label application:
+
+**Format:** `{type}/{scope}-{description}`
+
+**Examples:**
+
+```bash
+# Features
+git checkout -b feat/user-authentication
+git checkout -b feat/dashboard-redesign
+
+# Bug Fixes
+git checkout -b fix/header-alignment-mobile
+git checkout -b fix/wp6-6-compatibility
+
+# Documentation
+git checkout -b docs/api-reference
+git checkout -b docs/installation-guide
+
+# Hotfixes
+git checkout -b hotfix/critical-xss-patch
+git checkout -b hotfix/payment-gateway-fix
+```
+
+**Auto-Applied Labels:**
+- `feat/*` → `type:feature`, `status:in-progress`
+- `fix/*` → `type:bug`, `status:in-progress`
+- `docs/*` → `type:documentation`, `area:documentation`
+- `hotfix/*` → `type:bug`, `priority:critical`
+
+See [Branching Strategy](./.github/automation/BRANCHING_STRATEGY.md) for complete conventions.
+
+### 6. Configuring Labeler Rules
+
+Create `.github/labeler.yml` to auto-apply labels based on file paths:
+
+```yaml
+# Copy canonical labeler configuration
+cp .github/automation/labeler.yml /path/to/your/repo/.github/
+
+# Or customize for your repository:
+
+# PHP files
+lang:php:
+  - '**/*.php'
+  - 'includes/**/*'
+
+# JavaScript files
+lang:javascript:
+  - '**/*.js'
+  - '**/*.jsx'
+  - '**/*.ts'
+  - '**/*.tsx'
+
+# CSS files
+lang:css:
+  - '**/*.css'
+  - '**/*.scss'
+  - 'styles/**/*'
+
+# Documentation
+area:documentation:
+  - '**/*.md'
+  - 'docs/**/*'
+
+# Tests
+area:tests:
+  - 'tests/**/*'
+  - '**/*.test.js'
+  - '**/*.spec.js'
+
+# GitHub workflows
+area:ci:
+  - '.github/workflows/**/*'
+```
+
+### 7. Enforcing Changelog Requirements
+
+Ensure all PRs include changelog entries:
+
+```yaml
+# Add to your repository's workflow
+name: Changelog Check
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize]
+
+jobs:
+  changelog:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Check changelog
+        run: |
+          if ! git diff origin/develop...HEAD --name-only | grep -q "CHANGELOG.md"; then
+            if ! gh pr view ${{ github.event.pull_request.number }} --json labels --jq '.labels[].name' | grep -q "meta:no-changelog"; then
+              echo "::error::PR requires changelog entry or meta:no-changelog label"
+              exit 1
+            fi
+          fi
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+### 8. Quick Setup Script
+
+For new repositories, use this setup script to adopt all LightSpeed standards:
+
+```bash
+#!/bin/bash
+# setup-lightspeed-standards.sh
+
+REPO_PATH=${1:-.}
+GITHUB_REPO="lightspeedwp/.github"
+
+echo "Setting up LightSpeed standards in: $REPO_PATH"
+
+# Create .github directory
+mkdir -p "$REPO_PATH/.github/workflows"
+
+# Copy issue templates
+cp -r .github/ISSUE_TEMPLATE "$REPO_PATH/.github/"
+
+# Copy PR template
+cp .github/pull_request_template.md "$REPO_PATH/.github/"
+
+# Copy labeler configuration
+cp .github/automation/labeler.yml "$REPO_PATH/.github/"
+
+# Create label sync workflow
+cat > "$REPO_PATH/.github/workflows/label-sync.yml" <<EOF
+name: Label Sync
+on:
+  schedule:
+    - cron: '0 9 * * 1'
+  workflow_dispatch:
+jobs:
+  sync:
+    uses: lightspeedwp/.github/.github/workflows/label-sync.yml@develop
+    secrets: inherit
+EOF
+
+# Create labeling workflow
+cat > "$REPO_PATH/.github/workflows/labeling.yml" <<EOF
+name: Auto-Labeling
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened]
+  issues:
+    types: [opened, edited, reopened]
+jobs:
+  labeling:
+    uses: lightspeedwp/.github/.github/workflows/labeling.yml@develop
+    secrets: inherit
+EOF
+
+echo "✅ LightSpeed standards setup complete!"
+echo "Next steps:"
+echo "1. Review and commit the new files"
+echo "2. Enable GitHub Actions in repository settings"
+echo "3. Run label sync workflow manually to sync labels"
+echo "4. Update README.md to reference LightSpeed standards"
+```
+
+### 9. Validation and Testing
+
+Before deploying to production, test your setup:
+
+```bash
+# Validate YAML files
+yamllint .github/**/*.yml
+
+# Test label sync in dry-run mode
+gh workflow run label-sync.yml -f dry_run=true
+
+# Verify labeler configuration
+gh api repos/:owner/:repo/contents/.github/labeler.yml
+
+# Test branch naming
+git checkout -b feat/test-branch
+git push origin feat/test-branch
+# Check that PR auto-applies: type:feature, status:in-progress
+```
+
+### 10. Monitoring and Maintenance
+
+Set up monitoring to ensure standards remain in sync:
+
+- **Weekly Label Sync** – Automated workflow keeps labels current
+- **Quarterly Reviews** – Review exceptions and custom configurations
+- **Breaking Changes** – Subscribe to [GitHub Discussions](https://github.com/lightspeedwp/.github/discussions) for announcements
+
+---
+
 ## Troubleshooting & Adoption
 
 - **Labels/Types not applied:** Confirm your repo references `.github/labels.yml` and `.github/issue-types.yml` here.
diff --git a/SECURITY.md b/SECURITY.md
index 186839081..8182958c0 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -2,12 +2,114 @@
 
 If you discover a security vulnerability in this project, please report it responsibly.
 
-- **Contact:** [support@lightspeedwp.agency](mailto:support@lightspeedwp.agency)
-- Please provide as much detail as possible so we can address the issue quickly.
+## Reporting a Vulnerability
 
-We follow the [WordPress Security Best Practices](https://developer.wordpress.org/security) and adhere to the [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/).
+### Contact Methods
 
-We aim to respond to security reports within 3 business days.
+- **Email:** [support@lightspeedwp.agency](mailto:support@lightspeedwp.agency)
+- **Subject Line:** Include `[SECURITY]` prefix for priority routing
+- **Private Disclosure:** Do NOT open a public GitHub issue for security vulnerabilities
+
+### What to Include in Your Report
+
+Please provide as much detail as possible to help us assess and address the issue quickly:
+
+- **Description** – Clear description of the vulnerability
+- **Impact** – Potential impact and severity (Low, Medium, High, Critical)
+- **Steps to Reproduce** – Detailed steps to reproduce the vulnerability
+- **Affected Versions** – Which versions are affected
+- **Proposed Fix** – Any suggestions for remediation (optional)
+- **Your Contact Info** – How we can reach you for follow-up
+
+**Example:**
+
+```markdown
+Subject: [SECURITY] XSS Vulnerability in Search Form
+
+Description: Cross-site scripting (XSS) vulnerability in search form due to unsanitised user input.
+
+Impact: High - Allows attackers to inject malicious scripts
+
+Steps to Reproduce:
+1. Navigate to /search
+2. Enter: <script>alert('XSS')</script>
+3. Observe script execution in search results
+
+Affected Versions: v1.0 - v1.5
+
+Proposed Fix: Sanitise search input using esc_html() before rendering
+
+Contact: security-researcher@example.com
+```
+
+## Service Level Agreement (SLA)
+
+We take security seriously and commit to the following response times:
+
+| Severity | Initial Response | Triage Complete | Fix Target | Public Disclosure |
+|----------|------------------|-----------------|------------|-------------------|
+| **Critical** | 4 hours | 24 hours | 48 hours | 7 days post-fix |
+| **High** | 1 business day | 3 business days | 7 days | 14 days post-fix |
+| **Medium** | 3 business days | 5 business days | 14 days | 30 days post-fix |
+| **Low** | 5 business days | 10 business days | 30 days | 60 days post-fix |
+
+**Severity Definitions:**
+
+- **Critical** – Remote code execution, authentication bypass, data breach
+- **High** – Privilege escalation, SQL injection, XSS affecting admin users
+- **Medium** – XSS affecting regular users, CSRF, information disclosure
+- **Low** – Denial of service (local), minor information leaks
+
+## Our Commitment
+
+1. **Acknowledgement** – We will acknowledge receipt of your report within the SLA timeframe
+2. **Assessment** – We will assess the vulnerability and provide an initial severity rating
+3. **Fix Development** – We will develop and test a fix according to the SLA target
+4. **Release** – We will release a security patch and notify affected users
+5. **Credit** – We will credit you in the security advisory (unless you prefer to remain anonymous)
+
+## Security Best Practices
+
+We follow industry-standard security practices:
+
+- [WordPress Security Best Practices](https://developer.wordpress.org/security)
+- [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/)
+- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
+
+### Our Security Measures
+
+- **Input Validation** – All user inputs are validated and sanitised
+- **Output Escaping** – All outputs are escaped to prevent XSS
+- **Prepared Statements** – SQL queries use prepared statements to prevent SQL injection
+- **Nonce Verification** – Forms and AJAX requests verify nonces
+- **Capability Checks** – Admin functions check user capabilities
+- **Security Headers** – Appropriate security headers are set
+- **Dependency Management** – Regular dependency updates and vulnerability scanning
+
+## Vulnerability Disclosure Policy
+
+- **Private Disclosure** – Report vulnerabilities privately before public disclosure
+- **Coordinated Disclosure** – We coordinate disclosure timelines with reporters
+- **Public Disclosure** – Security advisories published after fixes are released
+- **CVE Assignment** – Critical vulnerabilities receive CVE identifiers
+
+## Security Updates and Advisories
+
+- **GitHub Security Advisories** – Published at [github.com/lightspeedwp/.github/security/advisories](https://github.com/lightspeedwp/.github/security/advisories)
+- **Release Notes** – Security fixes documented in [CHANGELOG.md](./CHANGELOG.md)
+- **Notifications** – Critical security updates announced via GitHub Discussions
+
+## Past Security Advisories
+
+View historical security advisories: [Security Advisories](https://github.com/lightspeedwp/.github/security/advisories)
+
+## Questions or Concerns?
+
+For questions about this security policy, contact:
+- **Email:** [support@lightspeedwp.agency](mailto:support@lightspeedwp.agency)
+- **Lead Security Contact:** @ashleyshaw
+
+---
 
 ## License
 
diff --git a/docs/assets/README.md b/docs/assets/README.md
new file mode 100644
index 000000000..28e86c2c0
--- /dev/null
+++ b/docs/assets/README.md
@@ -0,0 +1,90 @@
+---
+title: 'Documentation Assets'
+description: 'Images, diagrams, and visual resources for LightSpeed documentation'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['assets', 'images', 'diagrams', 'documentation']
+---
+
+# Documentation Assets
+
+This directory contains images, diagrams, and other visual resources used throughout LightSpeed documentation.
+
+## Purpose
+
+Provides a centralized location for:
+
+- Documentation images and screenshots
+- Architecture diagrams and flowcharts
+- Visual examples and mockups
+- Logos, icons, and branding assets
+
+## Contents
+
+### Asset Types
+
+- **Images** – Screenshots, UI examples, and visual references
+- **Diagrams** – Architecture diagrams, flowcharts, and process flows
+- **Mockups** – Design mockups and wireframes
+- **Icons** – Icons and small graphics for documentation
+
+## Inputs
+
+- Documentation requirements for visual aids
+- Architecture and workflow diagrams
+- UI/UX screenshots and examples
+
+## Outputs
+
+- Referenced images in markdown documentation
+- Visual aids enhancing documentation clarity
+- Consistent branding across documentation
+
+## Usage Examples
+
+### Example 1: Embedding Images in Markdown
+
+```markdown
+![GitHub Workflow Diagram](../assets/github-workflow-diagram.png)
+```
+
+### Example 2: Architecture Diagrams
+
+```markdown
+![LightSpeed Architecture](../assets/architecture/lightspeed-overview.svg)
+```
+
+### Example 3: Screenshots
+
+```markdown
+![Issue Template Example](../assets/screenshots/issue-template-bug.png)
+```
+
+## File Organization
+
+```
+assets/
+├── architecture/     # Architecture diagrams
+├── screenshots/      # UI screenshots
+├── diagrams/        # Flowcharts and process diagrams
+├── mockups/         # Design mockups
+└── icons/           # Icons and small graphics
+```
+
+## Best Practices
+
+1. **File Naming** – Use descriptive, kebab-case names (e.g., `issue-template-bug-report.png`)
+2. **Image Formats** – Prefer SVG for diagrams, PNG for screenshots, WebP for photos
+3. **Image Optimization** – Compress images to reduce file size
+4. **Alt Text** – Always provide descriptive alt text in markdown
+5. **Attribution** – Document image sources and licenses in this README
+
+## Related Documentation
+
+- [Documentation Index](../README.md) – Main documentation hub
+- [Contributing Guidelines](../../CONTRIBUTING.md) – Contribution workflow
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/bugherd/README.md b/docs/bugherd/README.md
new file mode 100644
index 000000000..031f58d89
--- /dev/null
+++ b/docs/bugherd/README.md
@@ -0,0 +1,66 @@
+---
+title: 'BugHerd Documentation'
+description: 'BugHerd tagging, categorization, and workflow guides for LightSpeed projects'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['bugherd', 'tagging', 'workflow', 'bug-tracking']
+---
+
+# BugHerd Documentation
+
+This directory contains documentation for BugHerd integration, tagging strategies, and workflow guides for LightSpeed projects.
+
+## Purpose
+
+Provides standardized guidance for using BugHerd in LightSpeed projects, including:
+
+- Default tag taxonomies and categorization
+- Tagging examples and best practices
+- Workflow guides and explainers
+
+## Contents
+
+### Core Documentation Files
+
+- **bugherd-default-tags-v1-6.md** – Canonical BugHerd tag definitions and categories
+- **bugherd-tagging-examples-v1-2.md** – Practical examples of BugHerd tagging in action
+- **bugherd-tagging-guide-explainer-v1-1.md** – Comprehensive guide to BugHerd tagging strategy and workflow
+
+## Inputs
+
+- Client feedback and bug reports via BugHerd
+- Project requirements and issue categorization needs
+- Team workflow preferences
+
+## Outputs
+
+- Properly tagged and categorized bugs in BugHerd
+- Consistent triage and prioritization across projects
+- Clear communication between clients and development teams
+
+## Usage Examples
+
+### Example 1: Tagging a Visual Bug
+
+```
+Tag: visual-bug, priority:high, browser:chrome
+Description: Header alignment broken on mobile viewports
+```
+
+### Example 2: Categorizing Feature Requests
+
+```
+Tag: feature-request, scope:enhancement, priority:medium
+Description: Add user profile avatar upload functionality
+```
+
+## Related Documentation
+
+- [Issue Templates](../../.github/ISSUE_TEMPLATE/) – For converting BugHerd items to GitHub issues
+- [Label Strategy](../LABEL_STRATEGY.md) – Cross-reference with GitHub label taxonomy
+- [Automation Governance](../../.github/automation/AUTOMATION_GOVERNANCE.md) – Integration with automated workflows
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/frontmatter/README.md b/docs/frontmatter/README.md
new file mode 100644
index 000000000..eda593a9f
--- /dev/null
+++ b/docs/frontmatter/README.md
@@ -0,0 +1,86 @@
+---
+title: 'YAML Frontmatter Documentation'
+description: 'YAML frontmatter schemas and guidelines for LightSpeed documentation files'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['frontmatter', 'yaml', 'metadata', 'documentation']
+---
+
+# YAML Frontmatter Documentation
+
+This directory contains documentation for YAML frontmatter standards, schemas, and usage guidelines for LightSpeed documentation files.
+
+## Purpose
+
+Ensures consistent metadata and discoverability across all LightSpeed documentation by:
+
+- Defining standard frontmatter schemas for different file types
+- Providing templates and examples for common use cases
+- Enabling automated documentation indexing and validation
+
+## Contents
+
+### Core Documentation Files
+
+- **agents-md.md** – Frontmatter schema for AI agent specification files
+- **chatmodes.md** – Frontmatter schema for AI chat mode configuration files
+- **claude-agents.md** – Frontmatter schema for Claude agent instruction files
+- **copilot-instructions.md** – Frontmatter schema for GitHub Copilot instruction files
+- **gemini-md.md** – Frontmatter schema for Gemini AI instruction files
+- **issue-templates.md** – Frontmatter schema for GitHub issue template files
+- **pr-templates.md** – Frontmatter schema for GitHub pull request template files
+- **prompt-files.md** – Frontmatter schema for AI prompt library files
+- **saved-replies.md** – Frontmatter schema for GitHub saved reply files
+
+### Schema Definitions
+
+- **schemas/** – JSON Schema files for frontmatter validation
+
+## Inputs
+
+- Markdown files requiring standardized metadata
+- Documentation files for AI agents, templates, and workflows
+- Files requiring automated indexing or categorization
+
+## Outputs
+
+- Valid, consistent YAML frontmatter across all documentation
+- Automated documentation indexes and navigation
+- Enhanced discoverability and searchability
+- VS Code IntelliSense and validation for frontmatter fields
+
+## Usage Examples
+
+### Example 1: Agent File Frontmatter
+
+```yaml
+---
+title: 'Release Agent'
+description: 'Automates release notes and changelog generation'
+version: '1.0'
+agent_type: 'automation'
+capabilities: ['changelog', 'release-notes', 'versioning']
+---
+```
+
+### Example 2: Issue Template Frontmatter
+
+```yaml
+---
+name: 'Bug Report'
+about: 'Report a bug or defect'
+title: 'Bug: [short description]'
+labels: ['type:bug', 'status:triage']
+---
+```
+
+## Related Documentation
+
+- [YAML Frontmatter Guide](../YAML-Frontmatter.md) – Comprehensive frontmatter usage guide
+- [Chatmode Frontmatter](../CHATMODE-FRONTMATTER.md) – Detailed chatmode schema documentation
+- [Schemas Directory](../../schemas/README.md) – JSON Schema definitions for validation
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/git-workflow/README.md b/docs/git-workflow/README.md
new file mode 100644
index 000000000..3de3247e8
--- /dev/null
+++ b/docs/git-workflow/README.md
@@ -0,0 +1,110 @@
+---
+title: 'Git Workflow Documentation'
+description: 'Git workflow guides, branching strategies, and version control best practices for LightSpeed'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['git', 'workflow', 'branching', 'version-control', 'agile']
+---
+
+# Git Workflow Documentation
+
+This directory contains comprehensive Git workflow documentation, branching strategies, and version control best practices for LightSpeed projects.
+
+## Purpose
+
+Provides standardized Git workflows and branching strategies to ensure:
+
+- Consistent version control practices across all LightSpeed projects
+- Clear branch naming conventions and merge discipline
+- Integration with agile project management and automation
+- Efficient fork synchronization and upstream management
+
+## Contents
+
+### Core Documentation Files
+
+- **agile-project-management-guide-v1.md** – Agile methodologies integrated with Git workflows
+- **git-org-wide-branching-strategy.md** – Organization-wide branching conventions and rules
+- **git-org-wide-defaults-v1-3.md** – Default Git configurations for LightSpeed projects
+- **git-selective-fork-sync-v1.md** – Guide for selective synchronization of forked repositories
+- **git-workflow-playbook-v1-2.md** – Comprehensive Git workflow playbook with examples
+- **org-wide-branching-strategy-v1-1.md** – Canonical branching strategy documentation
+- **org-wide-issue-types-v1-11.md** – Issue type mapping to branch prefixes
+- **org-wide-labels-v1-13.md** – Label taxonomy and workflow integration
+- **org-wide-labels-v1-14.md** – Updated label definitions
+- **pr-workflow-guide-v1-1.md** – Pull request workflow best practices
+
+## Inputs
+
+- Development branches following naming conventions
+- Feature development, bug fixes, and hotfixes
+- Pull requests mapped to issue types
+
+## Outputs
+
+- Clean, maintainable Git history
+- Automated branch-to-label mapping
+- Consistent merge and release processes
+- Efficient collaboration across distributed teams
+
+## Usage Examples
+
+### Example 1: Feature Branch Workflow
+
+```bash
+# Create feature branch
+git checkout -b feat/user-authentication
+
+# Work on feature with descriptive commits
+git commit -m "feat(auth): add user login form"
+
+# Push and create PR
+git push -u origin feat/user-authentication
+```
+
+### Example 2: Hotfix Workflow
+
+```bash
+# Create hotfix branch from main
+git checkout -b hotfix/critical-security-patch main
+
+# Apply fix
+git commit -m "fix(security): patch XSS vulnerability"
+
+# Push and create urgent PR
+git push -u origin hotfix/critical-security-patch
+```
+
+### Example 3: Selective Fork Sync
+
+```bash
+# Sync specific branches from upstream
+git remote add upstream https://github.com/lightspeedwp/repo.git
+git fetch upstream
+git checkout -b sync/upstream-feature upstream/feature-branch
+```
+
+## Branch Naming Conventions
+
+| Prefix | Purpose | Example |
+|--------|---------|---------|
+| `feat/` | New features | `feat/cart-checkout-flow` |
+| `fix/` | Bug fixes | `fix/wp6-6-compatibility` |
+| `hotfix/` | Urgent production fixes | `hotfix/critical-security-patch` |
+| `docs/` | Documentation updates | `docs/readme-installation` |
+| `chore/` | Maintenance tasks | `chore/deps-update-2025` |
+| `refactor/` | Code refactoring | `refactor/user-service-cleanup` |
+
+See [git-org-wide-branching-strategy.md](./git-org-wide-branching-strategy.md) for complete conventions.
+
+## Related Documentation
+
+- [Branching Strategy](../../.github/automation/BRANCHING_STRATEGY.md) – Org-wide branching rules
+- [Automation Governance](../../.github/automation/AUTOMATION_GOVERNANCE.md) – Automated workflow integration
+- [PR Workflow Guide](./pr-workflow-guide-v1-1.md) – Pull request best practices
+- [Contributing Guidelines](../../CONTRIBUTING.md) – Contribution workflow
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/label-automation/README.md b/docs/label-automation/README.md
new file mode 100644
index 000000000..a5396bb8d
--- /dev/null
+++ b/docs/label-automation/README.md
@@ -0,0 +1,112 @@
+---
+title: 'Label Automation Documentation'
+description: 'Automated labeling strategies, workflows, and project synchronization for LightSpeed GitHub repositories'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['labels', 'automation', 'github', 'workflows', 'project-sync']
+---
+
+# Label Automation Documentation
+
+This directory contains comprehensive documentation for automated labeling strategies, issue/PR automation, and GitHub project synchronization workflows.
+
+## Purpose
+
+Ensures consistent, automated issue and PR management across LightSpeed repositories by:
+
+- Defining label taxonomies and automation rules
+- Documenting issue/PR labeling workflows
+- Providing project metadata synchronization strategies
+- Enabling automated triage and routing
+
+## Contents
+
+### Core Documentation Files
+
+- **ISSUE_LABELS-v1-1.md** – Issue label definitions and usage
+- **PR_LABELS-v1-1.md** – Pull request label definitions and usage
+- **changelog-release-automation-client-delivery-v1.md** – Changelog automation for client projects
+- **changelog-release-automation-product-development-v1.md** – Changelog automation for product development
+- **issue--pr-labelling-project-sync-automation-workflows-v1.md** – Workflow automation strategies (deprecated)
+- **issue-and-pr-labelling-examples-v1.md** – Practical labeling examples
+- **issue-and-pr-labelling-guide-explainer-v1.md** – Comprehensive labeling guide
+- **issue-pr-labelling-project-sync-automation-workflows-v1-1.md** – Current workflow automation strategies
+- **issues-pr-labels-project-meta-v1-1.md** – Project metadata and custom field mapping
+- **issues-pr-labels-project-meta.md** – Original project metadata documentation
+- **label-automation-strategy-v1-1.md** – Current label automation strategy
+- **label-automation-strategy-v1.md** – Original label automation strategy
+
+## Inputs
+
+- Issue and PR creation events
+- Branch name patterns and file path changes
+- Manual label applications and project assignments
+- Workflow triggers and automation rules
+
+## Outputs
+
+- Automatically applied labels based on:
+  - Issue/PR templates
+  - Branch naming conventions
+  - File path patterns
+  - Content analysis
+- Synchronized GitHub project boards with custom fields
+- Automated changelog generation
+- Release notes and version tracking
+
+## Usage Examples
+
+### Example 1: Automated Issue Labeling
+
+```yaml
+# Issue created with bug template
+Automatically applies: type:bug, status:triage
+
+# Issue assigned to milestone v2.0
+Automatically applies: version:2.0
+```
+
+### Example 2: PR Branch-Based Labeling
+
+```yaml
+# PR from branch: feat/user-dashboard
+Automatically applies: type:feature, status:in-progress
+
+# PR modifies files in: src/components/**
+Automatically applies: scope:frontend
+```
+
+### Example 3: Project Synchronization
+
+```yaml
+# PR merged to main
+Automatically updates:
+  - Project status: Done
+  - Project field "Release": v2.1.0
+  - Closes linked issues
+```
+
+## Label Families
+
+| Family | Purpose | Examples |
+|--------|---------|----------|
+| `type:*` | Issue/PR categorization | `type:bug`, `type:feature`, `type:docs` |
+| `status:*` | Workflow state | `status:triage`, `status:in-progress`, `status:blocked` |
+| `prio:*` | Priority level | `prio:critical`, `prio:high`, `prio:low` |
+| `scope:*` | Area of impact | `scope:frontend`, `scope:backend`, `scope:api` |
+| `version:*` | Release targeting | `version:2.0`, `version:2.1` |
+
+See [label-automation-strategy-v1-1.md](./label-automation-strategy-v1-1.md) for complete taxonomy.
+
+## Related Documentation
+
+- [Labels YAML](../../.github/automation/labels.yml) – Canonical label definitions
+- [Labeler Config](../../.github/automation/labeler.yml) – Automated file-path-based labeling rules
+- [Issue Types](../../.github/automation/ISSUE_TYPES.md) – Issue type to label mapping
+- [PR Labels](../../.github/automation/PR_LABELS.md) – PR label documentation
+- [Automation Governance](../../.github/automation/AUTOMATION_GOVERNANCE.md) – Org-wide automation strategy
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/labels.md b/docs/labels.md
new file mode 100644
index 000000000..f1893946d
--- /dev/null
+++ b/docs/labels.md
@@ -0,0 +1,470 @@
+---
+title: 'GitHub Labels Guide'
+description: 'Comprehensive guide to LightSpeed label semantics, usage examples, and automation workflows'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['labels', 'github', 'automation', 'workflow', 'triage']
+related_docs:
+  - '/.github/automation/labels.yml'
+  - '/.github/automation/ISSUE_LABELS.md'
+  - '/.github/automation/PR_LABELS.md'
+  - '/docs/label-automation/README.md'
+---
+
+# GitHub Labels Guide
+
+This guide explains the semantics, usage, and automation workflows for all LightSpeed GitHub labels defined in [labels.yml](../.github/automation/labels.yml).
+
+## Table of Contents
+
+- [Label Families](#label-families)
+- [Label Semantics](#label-semantics)
+- [Usage Examples](#usage-examples)
+- [Automation Workflows](#automation-workflows)
+- [Best Practices](#best-practices)
+
+---
+
+## Label Families
+
+LightSpeed uses a structured label taxonomy organized into families by prefix:
+
+| Family | Prefix | Purpose | Count |
+|--------|--------|---------|-------|
+| **Type** | `type:*` | Categorizes the nature of work (bug, feature, docs, etc.) | 23 |
+| **Status** | `status:*` | Tracks workflow state and progress | 9 |
+| **Priority** | `priority:*` | Indicates urgency and importance | 4 |
+| **Area** | `area:*` | Identifies system component or domain | 9 |
+| **Language** | `lang:*` | Specifies programming language | 3 |
+| **Release** | `release:*` | Indicates semantic version impact | 3 |
+| **Meta** | `meta:*` | Metadata flags for automation | 3 |
+| **Contributor** | `contrib:*` | Community engagement labels | 3 |
+| **Discussion** | `discussion:*` | Discussion categorization | 7 |
+
+---
+
+## Label Semantics
+
+### Type Labels (`type:*`)
+
+Categorize the nature of work being done. **Required** for all issues and PRs.
+
+| Label | When to Use | Example |
+|-------|-------------|---------|
+| `type:bug` | Defects, errors, or unintended behavior | "Header alignment broken on mobile" |
+| `type:feature` | New functionality or capabilities | "Add user profile avatar upload" |
+| `type:task` | General tasks or to-dos | "Update dependencies to latest versions" |
+| `type:story` | User stories (agile methodology) | "As a user, I want to save my preferences" |
+| `type:documentation` | Documentation updates | "Add API endpoint documentation" |
+| `type:refactor` | Code restructuring without changing behavior | "Extract utility functions into separate module" |
+| `type:build` | Build system, CI/CD, or tooling changes | "Update GitHub Actions to v4" |
+| `type:automation` | Workflow automation improvements | "Add automated label sync workflow" |
+| `type:performance` | Performance optimizations | "Reduce page load time by lazy-loading images" |
+| `type:test` | Testing and test coverage improvements | "Add unit tests for user service" |
+| `type:security` | Security vulnerabilities or hardening | "Patch XSS vulnerability in search form" |
+| `type:a11y` | Accessibility improvements | "Add ARIA labels to navigation menu" |
+| `type:design` | Design work, mockups, or visual changes | "Design new dashboard layout" |
+| `type:compatibility` | Compatibility fixes (browser, WP version, etc.) | "Fix compatibility with WordPress 6.6" |
+| `type:integration` | Third-party integrations | "Integrate Stripe payment gateway" |
+| `type:release` | Release preparation tasks | "Prepare v2.0 release notes" |
+| `type:maintenance` | Routine maintenance tasks | "Clean up deprecated code" |
+| `type:improve` | General improvements | "Improve error messaging clarity" |
+| `type:qa` | Quality assurance tasks | "QA test checkout flow" |
+| `type:chore` | Miscellaneous chores | "Update copyright year" |
+| `type:audit` | Code, security, or performance audits | "Audit API endpoint performance" |
+| `type:epic` | Large multi-scope initiatives | "Complete user authentication system" |
+| `type:research` | Research and investigation | "Research best CSS-in-JS library" |
+| `type:review` | Code or design review tasks | "Review PR #123 for security issues" |
+
+### Status Labels (`status:*`)
+
+Track workflow state and progress. **Automatically updated** by automation workflows.
+
+| Label | Meaning | When Applied | Next Action |
+|-------|---------|--------------|-------------|
+| `status:needs-triage` | Needs triage and prioritization | Automatically on new issues | Maintainer reviews and assigns labels |
+| `status:needs-planning` | Awaiting planning or scoping | Maintainer applies after triage | Team plans approach and assigns |
+| `status:ready` | Ready to start work | After planning is complete | Developer picks up and starts work |
+| `status:in-progress` | Work currently underway | When PR is opened or issue assigned | Continue work until ready for review |
+| `status:needs-review` | Awaiting code or design review | When PR is ready for review | Reviewer examines and provides feedback |
+| `status:needs-qa` | Quality assurance required | After code review approval | QA team tests functionality |
+| `status:blocked` | Blocked by dependency or issue | When external blocker prevents progress | Resolve blocker before continuing |
+| `status:on-hold` | Work temporarily paused | When work is deferred | Resume when circumstances change |
+| `status:done` | Completed and merged/closed | When PR is merged or issue resolved | Archive and celebrate! 🎉 |
+
+**Status Workflow:**
+
+```
+needs-triage → needs-planning → ready → in-progress → needs-review → needs-qa → done
+                                                         ↓
+                                                    blocked/on-hold
+```
+
+### Priority Labels (`priority:*`)
+
+Indicate urgency and importance. **Applied manually** during triage.
+
+| Label | Meaning | SLA | Example |
+|-------|---------|-----|---------|
+| `priority:critical` | Production blocking, urgent fix required | Fix within 24 hours | Site completely down, security breach |
+| `priority:important` | Must-do high priority | Address in current sprint | Major feature blocker, significant bug |
+| `priority:normal` | Default priority | Address in backlog order | Standard feature request, minor bug |
+| `priority:minor` | Low priority, nice-to-have | Address when capacity allows | Cosmetic issue, documentation typo |
+
+**Priority Assignment Rules:**
+
+- **Critical:** Production outages, data loss, security vulnerabilities
+- **Important:** Significant bugs affecting multiple users, key features
+- **Normal:** Default for all new issues unless otherwise specified
+- **Minor:** Cosmetic issues, small improvements, documentation tweaks
+
+### Area Labels (`area:*`)
+
+Identify system component or domain affected.
+
+| Label | Component | Example |
+|-------|-----------|---------|
+| `area:core` | Core infrastructure, shared utilities | "Refactor authentication service" |
+| `area:block-editor` | Gutenberg block editor | "Add custom block toolbar controls" |
+| `area:theme` | WordPress theme | "Update theme.json color palette" |
+| `area:ci` | Continuous integration | "Add automated accessibility testing" |
+| `area:documentation` | Documentation files | "Update README installation steps" |
+| `area:tests` | Test suites | "Add E2E tests for checkout flow" |
+| `area:scripts` | Build scripts, automation | "Optimize webpack build configuration" |
+| `area:assets` | Images, fonts, media | "Compress header images" |
+| `area:woocommerce` | WooCommerce integration | "Add custom product fields" |
+
+### Language Labels (`lang:*`)
+
+Specify primary programming language affected.
+
+| Label | Language | When to Use |
+|-------|----------|-------------|
+| `lang:php` | PHP | Backend code, WordPress functions |
+| `lang:javascript` | JavaScript/TypeScript | Frontend code, React components |
+| `lang:css` | CSS/SCSS | Styles, design system |
+
+### Release Labels (`release:*`)
+
+Indicate semantic versioning impact. **Required** for all user-facing changes.
+
+| Label | Version Impact | Example |
+|-------|----------------|---------|
+| `release:patch` | Bug fixes, patches (v1.0.0 → v1.0.1) | "Fix typo in error message" |
+| `release:minor` | New features, backwards-compatible (v1.0.0 → v1.1.0) | "Add user profile page" |
+| `release:major` | Breaking changes (v1.0.0 → v2.0.0) | "Remove deprecated API endpoints" |
+
+### Meta Labels (`meta:*`)
+
+Metadata flags for automation and workflow control.
+
+| Label | Purpose | When Applied |
+|-------|---------|--------------|
+| `meta:needs-changelog` | PR needs changelog entry | Automatically if no changelog detected |
+| `meta:no-changelog` | PR does not require changelog | Apply to internal-only changes |
+| `meta:duplicate` | Duplicate issue or PR | Apply when closing as duplicate |
+
+### Contributor Labels (`contrib:*`)
+
+Community engagement and contribution facilitation.
+
+| Label | Purpose | When to Use |
+|-------|---------|-------------|
+| `contrib:good-first-issue` | Beginner-friendly issue | Simple, well-scoped issues for new contributors |
+| `contrib:help-wanted` | Community help requested | Issues where maintainers welcome community PRs |
+| `contrib:discussion` | Community discussion topic | Open-ended discussions, RFCs, brainstorming |
+
+### Discussion Labels (`discussion:*`)
+
+Categorize GitHub Discussions topics.
+
+| Label | Category | When to Use |
+|-------|----------|-------------|
+| `discussion:announcement` | Official announcements | Product updates, release announcements |
+| `discussion:showcase` | Show & Tell | Community showcases, success stories |
+| `discussion:community` | Community/general | General community chat, introductions |
+| `discussion:feedback` | Feedback/suggestions | Product feedback, feature suggestions |
+| `discussion:support` | Support/troubleshooting | Help requests, troubleshooting |
+| `discussion:sponsorship` | Sponsorship/funding | Sponsorship inquiries, funding discussions |
+| `discussion:partnership` | Partnership/collaboration | Partnership opportunities, collaborations |
+
+---
+
+## Usage Examples
+
+### Example 1: Bug Report Triage
+
+**Scenario:** User reports header alignment issue on mobile.
+
+```yaml
+Labels Applied:
+  - type:bug                  # It's a defect
+  - priority:important        # Affects mobile users
+  - area:theme               # Theme-related issue
+  - lang:css                 # Requires CSS fix
+  - status:needs-planning    # After triage, needs scoping
+
+Workflow:
+1. Issue created → status:needs-triage (automatic)
+2. Maintainer triages → adds type:bug, priority:important, area:theme
+3. Maintainer scopes → changes to status:needs-planning
+4. Developer assigned → changes to status:ready
+5. PR opened → changes to status:in-progress
+6. PR ready → changes to status:needs-review
+7. PR approved → changes to status:needs-qa
+8. PR merged → changes to status:done
+```
+
+### Example 2: Feature Request Workflow
+
+**Scenario:** Add user profile avatar upload functionality.
+
+```yaml
+Labels Applied:
+  - type:feature              # New functionality
+  - priority:normal           # Standard priority
+  - area:core                # Core functionality
+  - lang:php                 # Backend work
+  - lang:javascript          # Frontend work
+  - release:minor            # New feature = minor version bump
+  - status:needs-planning    # Needs technical design
+
+Workflow:
+1. Issue created → status:needs-triage
+2. Maintainer approves → type:feature, priority:normal, release:minor
+3. Tech lead creates design doc → status:needs-planning
+4. Design approved → status:ready
+5. Developer starts work → status:in-progress
+6. PR opened with changelog entry → meta:needs-changelog removed
+7. Code review → status:needs-review
+8. QA testing → status:needs-qa
+9. Merged to main → status:done, issue closed
+```
+
+### Example 3: Security Vulnerability
+
+**Scenario:** XSS vulnerability discovered in search form.
+
+```yaml
+Labels Applied:
+  - type:security            # Security issue
+  - priority:critical        # Production vulnerability
+  - area:core               # Core search functionality
+  - lang:php                # Backend sanitization needed
+  - release:patch           # Security patch = patch version
+  - status:in-progress      # Immediate fix in progress
+
+Workflow:
+1. Private security report received
+2. Maintainer confirms → type:security, priority:critical
+3. Immediate fix starts → status:in-progress
+4. Hotfix PR created → release:patch, meta:no-changelog (security)
+5. Expedited review → status:needs-review (priority lane)
+6. Merged to main and patched → status:done
+7. Security advisory published (post-fix)
+```
+
+### Example 4: Documentation Update
+
+**Scenario:** Add API endpoint documentation.
+
+```yaml
+Labels Applied:
+  - type:documentation       # Docs update
+  - priority:normal          # Standard priority
+  - area:documentation      # Documentation files
+  - meta:no-changelog       # Internal-only, no user-facing changelog
+  - status:ready            # Simple task, ready to start
+
+Workflow:
+1. Issue created → status:needs-triage
+2. Maintainer approves → type:documentation, meta:no-changelog
+3. Contributor picks up → status:in-progress
+4. PR opened → status:needs-review
+5. Approved and merged → status:done
+```
+
+### Example 5: Performance Optimization
+
+**Scenario:** Reduce page load time by lazy-loading images.
+
+```yaml
+Labels Applied:
+  - type:performance         # Performance improvement
+  - priority:important       # Significant user experience impact
+  - area:theme              # Theme templates affected
+  - lang:javascript         # Lazy-loading script
+  - release:minor           # Enhancement = minor version
+  - status:needs-planning   # Needs performance testing plan
+
+Workflow:
+1. Issue created with performance metrics → status:needs-triage
+2. Maintainer prioritizes → type:performance, priority:important
+3. Performance testing plan created → status:ready
+4. Developer implements lazy-loading → status:in-progress
+5. PR includes before/after metrics → status:needs-review
+6. Performance validated → status:needs-qa
+7. Merged with changelog entry → status:done, release:minor
+```
+
+---
+
+## Automation Workflows
+
+### Automatic Label Application
+
+Labels are automatically applied based on:
+
+1. **Issue/PR Templates** – Template selection applies initial labels
+2. **Branch Names** – Branch prefix maps to labels (e.g., `feat/` → `type:feature`)
+3. **File Paths** – Modified files trigger area labels (e.g., `*.php` → `lang:php`)
+4. **Keywords** – Content keywords trigger labels (e.g., "security" → `type:security`)
+
+**Example: Branch-Based Auto-Labeling**
+
+```yaml
+Branch: feat/user-dashboard
+Auto-applied labels:
+  - type:feature
+  - status:in-progress
+
+Branch: fix/wp6-6-compat
+Auto-applied labels:
+  - type:bug
+  - type:compatibility
+  - status:in-progress
+
+Branch: docs/api-reference
+Auto-applied labels:
+  - type:documentation
+  - area:documentation
+  - status:in-progress
+```
+
+### Status Transitions
+
+Status labels are automatically updated during PR lifecycle:
+
+```yaml
+Event: PR opened
+Action: Apply status:in-progress
+
+Event: PR marked ready for review
+Action: Apply status:needs-review
+
+Event: PR approved by reviewer
+Action: Apply status:needs-qa
+
+Event: PR merged
+Action: Apply status:done, close linked issues
+```
+
+### Changelog Enforcement
+
+PRs without changelog entries are flagged:
+
+```yaml
+Condition: PR modifies user-facing code
+           AND PR does not update CHANGELOG.md
+           AND PR does not have meta:no-changelog
+Action: Apply meta:needs-changelog
+        Add comment requesting changelog entry
+```
+
+---
+
+## Best Practices
+
+### For Issue Creators
+
+1. **Use Issue Templates** – Templates apply correct initial labels automatically
+2. **Be Descriptive** – Detailed descriptions help maintainers apply accurate labels
+3. **Don't Over-Label** – Let maintainers apply type, priority, and area labels during triage
+4. **Do Apply Meta Labels** – If you know the change doesn't need a changelog, apply `meta:no-changelog`
+
+### For Maintainers
+
+1. **Triage Promptly** – Review `status:needs-triage` issues within 2 business days
+2. **Be Specific** – Apply all relevant labels (type, priority, area, language)
+3. **Explain Priority** – Add a comment justifying `priority:critical` or `priority:important`
+4. **Use Status Workflow** – Follow the canonical status progression
+5. **Keep Labels Clean** – Remove labels that no longer apply
+
+### For Contributors
+
+1. **Check Existing Labels** – Review labels before starting work to understand scope
+2. **Use Correct Branch Prefix** – Match your branch name to the issue type for auto-labeling
+3. **Update Status** – Move issues to `status:in-progress` when you start work
+4. **Add Changelog Entries** – All user-facing changes need changelog entries unless `meta:no-changelog`
+5. **Request Label Changes** – Ask maintainers to update labels if the scope changes
+
+### For Reviewers
+
+1. **Verify Labels** – Ensure PR labels match the actual changes
+2. **Update Status** – Move PRs through status workflow (review → QA → done)
+3. **Check Changelog** – Verify changelog entry exists for user-facing changes
+4. **Validate Priority** – Confirm priority labels match urgency and impact
+
+---
+
+## When to Use Each Label
+
+### Use `status:needs-info` vs `status:blocked`
+
+- **`status:needs-info`** – Missing information from reporter (user input required)
+- **`status:blocked`** – External dependency or technical blocker (not user input)
+
+**Example:**
+- Needs info: "Can you provide steps to reproduce this bug?"
+- Blocked: "Waiting for upstream library to fix API endpoint"
+
+### Use `type:bug` vs `type:improve`
+
+- **`type:bug`** – Unintended behavior, defect, or error
+- **`type:improve`** – Intentional behavior that could be better
+
+**Example:**
+- Bug: "Button doesn't submit form" (broken functionality)
+- Improve: "Button could have better hover animation" (enhancement)
+
+### Use `priority:critical` vs `priority:important`
+
+- **`priority:critical`** – Production down, data loss, security breach (fix immediately)
+- **`priority:important`** – Significant impact, key feature affected (fix this sprint)
+
+**Example:**
+- Critical: "Payment processing completely broken" (revenue impact)
+- Important: "Checkout flow has confusing UX" (user experience impact)
+
+### Use `meta:no-changelog` vs `meta:needs-changelog`
+
+- **`meta:no-changelog`** – Internal-only changes (refactors, tests, docs, CI)
+- **`meta:needs-changelog`** – User-facing changes missing changelog entry
+
+**Example:**
+- No changelog: "Refactor internal utility functions" (no user impact)
+- Needs changelog: "Add user profile page" (new user-facing feature)
+
+---
+
+## Label Sync Workflow
+
+All LightSpeed repositories should sync labels from the canonical [labels.yml](../.github/automation/labels.yml) using the automated label sync workflow.
+
+**See:** [Label Sync Workflow Documentation](../.github/workflows/label-sync.yml)
+
+---
+
+## Related Documentation
+
+- [Canonical Labels YAML](../.github/automation/labels.yml) – Single source of truth for all labels
+- [Issue Labels Guide](../.github/automation/ISSUE_LABELS.md) – Issue-specific label documentation
+- [PR Labels Guide](../.github/automation/PR_LABELS.md) – PR-specific label documentation
+- [Label Automation Strategy](./label-automation/README.md) – Comprehensive automation documentation
+- [Automation Governance](../.github/automation/AUTOMATION_GOVERNANCE.md) – Org-wide automation rules
+- [Contributing Guidelines](../CONTRIBUTING.md) – Contribution workflow
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../CONTRIBUTING.md)
diff --git a/docs/ls-projects/README.md b/docs/ls-projects/README.md
new file mode 100644
index 000000000..3da6c4666
--- /dev/null
+++ b/docs/ls-projects/README.md
@@ -0,0 +1,139 @@
+---
+title: 'LightSpeed Projects Documentation'
+description: 'GitHub Projects templates, automation, and field specifications for LightSpeed workflows'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['github-projects', 'automation', 'templates', 'workflows', 'project-management']
+---
+
+# LightSpeed Projects Documentation
+
+This directory contains GitHub Projects (Beta) templates, automation configurations, and field specifications for both client delivery and product development workflows.
+
+## Purpose
+
+Standardizes GitHub Projects configuration across LightSpeed repositories to ensure:
+
+- Consistent project board layouts and custom fields
+- Automated issue/PR routing and status updates
+- Tailored workflows for client delivery vs. product development
+- Integration with branch prefixes, labels, and changelog automation
+
+## Contents
+
+### Client Delivery Workflow Files
+
+- **branch-prefixes-client-delivery-v1-1.md** – Branch naming conventions for client projects
+- **changelog-release-automation-client-delivery-v1-1.md** – Changelog automation for client delivery
+- **client-delivery-automations-v1-1.md** – Automated workflow rules for client projects
+- **client-delivery-branch-prefixes-v1.md** – Detailed branch prefix documentation
+- **client-delivery-cadence-v1-1.md** – Release cadence and sprint planning for client projects
+- **client-delivery-changelog-release-automation-v1.md** – Comprehensive changelog automation
+- **client-delivery-field-specs-v1-1.md** – Custom field definitions for client project boards
+- **client-delivery-project-template-v1-6.md** – Complete project board template configuration
+- **client-delivery-views-v1-1.md** – Pre-configured project board views
+
+### Product Development Workflow Files
+
+- **branch-prefixes-product-development-v1-1.md** – Branch naming conventions for product development
+- **changelog-release-automation-product-development-v1-1.md** – Changelog automation for products
+- **product-development-automations-v1-1.md** – Automated workflow rules for product repos
+- **product-development-branch-prefixes-v1.md** – Detailed branch prefix documentation
+- **product-development-cadence-v1-1.md** – Release cadence and roadmap planning
+- **product-development-changelog-release-automation-v1.md** – Comprehensive changelog automation
+- **product-development-field-specs-v1-1.md** – Custom field definitions for product boards
+- **product-development-project-template-v1-6.md** – Complete project board template configuration
+- **product-development-views-v1-1.md** – Pre-configured project board views
+
+### Legacy Templates
+
+- **project-template-client-delivery-v1-5.md** – Previous version of client delivery template
+- **project-template-product-development-v1-5.md** – Previous version of product development template
+
+## Inputs
+
+- Issues and PRs created in LightSpeed repositories
+- Branch names matching defined prefixes
+- Label applications and milestone assignments
+- Manual project field updates
+
+## Outputs
+
+- Automatically configured GitHub project boards
+- Issues/PRs routed to appropriate project views
+- Custom fields populated based on labels and metadata
+- Automated status transitions during PR lifecycle
+- Integrated changelog and release tracking
+
+## Usage Examples
+
+### Example 1: Client Delivery Project Setup
+
+```bash
+# Apply client delivery project template
+# Includes custom fields: Client, Sprint, Priority, Status, Estimate
+# Automated views: Backlog, Current Sprint, Blocked, Ready for Review
+```
+
+### Example 2: Product Development Board
+
+```bash
+# Apply product development project template
+# Includes custom fields: Epic, Release, Component, Priority, Size
+# Automated views: Roadmap, In Progress, Ready to Ship, Backlog
+```
+
+### Example 3: Automated Field Population
+
+```yaml
+# PR created from branch: feat/checkout-flow
+Automatically populates:
+  - Type: Feature
+  - Component: Frontend
+  - Status: In Progress
+
+# Issue labeled: prio:critical, milestone:v2.0
+Automatically populates:
+  - Priority: Critical
+  - Release: v2.0
+  - Status: Triage
+```
+
+## Project Types
+
+| Type | Use Case | Cadence | Automation |
+|------|----------|---------|------------|
+| **Client Delivery** | Client projects, agency work | Sprint-based (1-2 weeks) | Label→Status, Sprint planning |
+| **Product Development** | Internal products, SaaS | Milestone-based (monthly/quarterly) | Epic tracking, Roadmap planning |
+
+## Custom Fields
+
+### Client Delivery Fields
+
+- **Client** – Client name (single select)
+- **Sprint** – Sprint identifier (text)
+- **Priority** – Priority level (single select)
+- **Status** – Workflow status (single select)
+- **Estimate** – Story points (number)
+
+### Product Development Fields
+
+- **Epic** – Epic tracking (single select)
+- **Release** – Target release (single select)
+- **Component** – System component (single select)
+- **Priority** – Priority level (single select)
+- **Size** – T-shirt sizing (single select)
+
+See field specification files for complete definitions and automation mappings.
+
+## Related Documentation
+
+- [Automation Governance](../../.github/automation/AUTOMATION_GOVERNANCE.md) – Org-wide automation strategy
+- [Branching Strategy](../../.github/automation/BRANCHING_STRATEGY.md) – Branch naming and workflow
+- [Label Automation](../label-automation/README.md) – Label-to-field mapping
+- [Git Workflow](../git-workflow/README.md) – Version control integration
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/wordpress/README.md b/docs/wordpress/README.md
new file mode 100644
index 000000000..69f32e891
--- /dev/null
+++ b/docs/wordpress/README.md
@@ -0,0 +1,114 @@
+---
+title: 'WordPress Development Documentation'
+description: 'Comprehensive WordPress development resources for block themes, Gutenberg, coding standards, and testing'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['wordpress', 'block-themes', 'gutenberg', 'coding-standards', 'testing']
+---
+
+# WordPress Development Documentation
+
+This directory contains comprehensive WordPress development documentation for LightSpeed projects, including block themes, Gutenberg development, coding standards, and testing strategies.
+
+## Purpose
+
+Provides in-depth WordPress development resources covering:
+
+- Block theme development and best practices
+- WordPress and PHP coding standards
+- Gutenberg block and editor development
+- WordPress testing strategies and frameworks
+
+## Contents
+
+### Subdirectories
+
+- **block-themes/** – Block theme development guides, templates, and patterns
+- **coding-standards/** – WordPress, PHP, and LightSpeed coding standards
+- **gutenberg/** – Gutenberg block editor development resources
+- **testing/** – WordPress testing strategies, tools, and frameworks
+
+Each subdirectory contains its own README with detailed purpose, contents, and examples.
+
+## Inputs
+
+- WordPress theme and plugin development projects
+- Custom block and pattern development
+- WordPress code reviews and quality audits
+- Testing and continuous integration workflows
+
+## Outputs
+
+- Standards-compliant WordPress themes and plugins
+- Custom Gutenberg blocks and editor extensions
+- Accessible, performant WordPress components
+- Well-tested, maintainable WordPress codebases
+
+## Usage Examples
+
+### Example 1: Block Theme Development
+
+```bash
+# Navigate to block theme documentation
+cd block-themes/
+
+# Reference theme.json configuration
+# Reference template hierarchy
+# Reference block pattern development
+```
+
+### Example 2: Gutenberg Block Development
+
+```bash
+# Navigate to Gutenberg documentation
+cd gutenberg/
+
+# Reference block registration
+# Reference block API documentation
+# Reference editor component usage
+```
+
+### Example 3: WordPress Testing
+
+```bash
+# Navigate to testing documentation
+cd testing/
+
+# Reference unit testing strategies
+# Reference integration testing with WordPress
+# Reference E2E testing with Playwright
+```
+
+## Documentation Structure
+
+```
+wordpress/
+├── block-themes/          # Block theme development
+│   ├── templates/         # Template file examples
+│   ├── patterns/          # Block pattern library
+│   └── theme-json/        # theme.json configuration
+├── coding-standards/      # Coding standards and linting
+│   ├── php/              # PHP and WordPress standards
+│   └── javascript/       # JavaScript and React standards
+├── gutenberg/            # Gutenberg block development
+│   ├── blocks/           # Custom block examples
+│   ├── components/       # Editor component usage
+│   └── api/              # Gutenberg API reference
+└── testing/              # WordPress testing
+    ├── unit/             # Unit testing strategies
+    ├── integration/      # Integration testing
+    └── e2e/              # End-to-end testing
+```
+
+## Related Documentation
+
+- [WordPress Guides](../wp-guides/README.md) – Quick reference checklists
+- [Coding Standards](../../.github/instructions/coding-standards.instructions.md) – LightSpeed coding standards
+- [Block Development Instructions](../../.github/instructions/php-block.instructions.md) – Block development guide
+- [Theme JSON Instructions](../../.github/instructions/theme-json.instructions.md) – theme.json configuration guide
+- [Pattern Development Instructions](../../.github/instructions/pattern-development.instructions.md) – Block pattern development
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)
diff --git a/docs/wp-guides/README.md b/docs/wp-guides/README.md
new file mode 100644
index 000000000..0cd3be34f
--- /dev/null
+++ b/docs/wp-guides/README.md
@@ -0,0 +1,92 @@
+---
+title: 'WordPress Development Guides'
+description: 'Quick reference guides and checklists for WordPress development at LightSpeed'
+version: '1.0'
+last_updated: '2025-11-12'
+maintainer: 'LightSpeed Team'
+tags: ['wordpress', 'guides', 'checklists', 'coding-standards', 'security']
+---
+
+# WordPress Development Guides
+
+This directory contains quick reference guides and checklists for WordPress development best practices at LightSpeed.
+
+## Purpose
+
+Provides concise, actionable checklists and guides for common WordPress development tasks:
+
+- Block development checklists
+- WordPress coding standards quick reference
+- Security best practices and vulnerability prevention
+
+## Contents
+
+### Core Documentation Files
+
+- **block-dev-checklist.md** – Comprehensive checklist for WordPress block development
+- **wp-coding-standards.md** – Quick reference for WordPress coding standards (PHP, JS, CSS)
+- **wp-security-checklist.md** – Security checklist for WordPress development
+
+## Inputs
+
+- WordPress block development projects
+- Custom theme and plugin development
+- Security audits and code reviews
+
+## Outputs
+
+- Blocks developed following WordPress best practices
+- Code adhering to WordPress coding standards
+- Secure, validated, and sanitized WordPress code
+- Accessible, performant WordPress components
+
+## Usage Examples
+
+### Example 1: Block Development Checklist
+
+```markdown
+- [ ] Block registered with proper metadata
+- [ ] Editor and frontend styles separated
+- [ ] Block attributes properly typed
+- [ ] Save/edit functions handle validation
+- [ ] Accessibility attributes included (ARIA, roles)
+- [ ] Block tested in editor and frontend
+- [ ] Block variations defined (if applicable)
+```
+
+### Example 2: Security Checklist
+
+```markdown
+- [ ] All user inputs sanitized (sanitize_text_field, esc_html, etc.)
+- [ ] All outputs escaped (esc_html, esc_url, wp_kses)
+- [ ] Nonces used for form submissions
+- [ ] Capability checks for privileged operations
+- [ ] SQL queries use prepared statements
+- [ ] File uploads validated and restricted
+```
+
+### Example 3: Coding Standards Reference
+
+```php
+// WordPress coding standards
+function lightspeed_get_post_title( $post_id ) {
+    // Use proper spacing, braces, and naming conventions
+    if ( ! $post_id ) {
+        return '';
+    }
+
+    $title = get_the_title( $post_id );
+    return esc_html( $title );
+}
+```
+
+## Related Documentation
+
+- [WordPress Development](../wordpress/README.md) – Comprehensive WordPress documentation
+- [Coding Standards](../../.github/instructions/coding-standards.instructions.md) – LightSpeed coding standards
+- [Security Policy](../../SECURITY.md) – Organization-wide security practices
+- [WordPress Block Instructions](../../.github/instructions/php-block.instructions.md) – Detailed block development guide
+
+---
+
+**Maintained by LightSpeed Team** • For updates or questions, see [CONTRIBUTING.md](../../CONTRIBUTING.md)