feat: Create team onboarding and training documentation for Phase 4

[ashleyshaw]

Summary

Develop comprehensive team onboarding and training materials to ensure all developers across the organization understand, adopt, and follow the new governance rules. This is critical for successful Phase 4 rollout and maintaining > 90% developer compliance.

Proposed Solution

Create multi-format training materials:

1. Developer Onboarding Guide (docs/DEVELOPER_ONBOARDING.md)

   • Step-by-step introduction to branch naming rules
   • Why branch naming matters (PR templates, CI/CD, governance)
   • How to validate branch names locally (npm run validate:branch-name)
   • Common mistakes and how to fix them

2. Quick Reference Materials

   • docs/BRANCH_NAMING_QUICK_REFERENCE.md — one-pager
   • Checklists for PR creation process
   • FAQ for edge cases

3. Comprehensive Guides

   • Troubleshooting guide (what to do if you created wrong branch)
   • Success examples (real branches from Phase 3)
   • Integration with IDE/git workflows

4. Rollout Plan

   • Enforcement timeline (e.g., 2-week grace period)
   • Support period and escalation
   • Success metrics tracking

Acceptance Criteria

• Onboarding documentation complete and accessible
• Quick reference card created and distributed
• FAQs cover all common edge cases
• Troubleshooting guide helpful and clear
• Real success examples included
• > 90% developer adoption within 2 weeks of rollout
• Developer feedback score > 4/5
• Documentation completeness score > 95%

Designs / References

• docs/BRANCHING_STRATEGY.md — complete strategy reference
• Issue feat: Establish organization-wide branch naming enforcement policy #2664 — org governance policy
• Phase 3 deliverables: CLAUDE.md, AGENTS.md

Testing Approach

1. Internal review by 2-3 developers not on governance team
2. Incorporate feedback iteratively
3. Dry-run with small team (5-10 devs) for 1 week
4. Measure adoption rate and collect feedback
5. Adjust materials and rollout plan
6. Full org rollout with ongoing support

---

Definition of Ready

• Governance policy finalized (Issue feat: Establish organization-wide branch naming enforcement policy #2664)
• Success metrics defined
• Rollout timeline agreed
• Support team assigned

Definition of Done

• All training materials published
• Team onboarding guide reviewed by 3+ developers
• Quick reference distributed to all teams
• Rollout plan communicated to leadership
• Support channel set up (Slack, email, GitHub issues)
• Initial feedback collected and documented
• Follow-up training plan scheduled (1 week, 1 month post-rollout)

[linear-code]

LS-2986

[github-actions]

⚠️ This issue does not follow a required issue template.

Missing required section(s): Definition of Ready (DoR), Definition of Done (DoD)

The issue will remain open and flagged until the body is corrected.
Please update the issue with one of the official templates:

• https://github.com/lightspeedwp/.github/issues/new/choose

If this was opened by automation, update the automation to preserve the template sections before creating the issue.

[github-actions]

⚠️ Bare Labels Detected

This issue has labels that are not in the canonical taxonomy:

• priority:high
• area:docs
• type:feat

Valid Canonical Labels

Please use labels with a prefix from the canonical taxonomy:

• Type: type:bug, type:feature, type:task, type:documentation, etc.
• Status: status:needs-triage, status:in-progress, status:done, etc.
• Priority: priority:critical, priority:high, priority:normal, priority:low
• Area: area:ci, area:docs, area:labels, area:security, etc.
• Meta: meta:needs-changelog, meta:duplicate, meta:blocked, etc.

For the complete list, see .github/labels.yml.