Initial commit: Clean DSS implementation

Migrated from design-system-swarm with fresh git history.
Old project history preserved in /home/overbits/apps/design-system-swarm

Core components:
- MCP Server (Python FastAPI with mcp 1.23.1)
- Claude Plugin (agents, commands, skills, strategies, hooks, core)
- DSS Backend (dss-mvp1 - token translation, Figma sync)
- Admin UI (Node.js/React)
- Server (Node.js/Express)
- Storybook integration (dss-mvp1/.storybook)

Self-contained configuration:
- All paths relative or use DSS_BASE_PATH=/home/overbits/dss
- PYTHONPATH configured for dss-mvp1 and dss-claude-plugin
- .env file with all configuration
- Claude plugin uses ${CLAUDE_PLUGIN_ROOT} for portability

Migration completed: $(date)
🤖 Clean migration with full functionality preserved

.knowledge/adrs/archived/operational/SLACK_ANNOUNCEMENT_TEMPLATE.md

@@ -0,0 +1,118 @@
+# Slack Announcement Template
+
+Copy this message and post to [YOUR_TEAM_SLACK_CHANNEL] when ready to launch the pilot.
+
+Replace [PLACEHOLDERS] with your team-specific details.
+
+---
+
+## Message
+
+> 🎯 **DSS Principles Pilot: Architecture Decision Records**
+>
+> Hey team! We're running a 4-week pilot to strengthen our DSS principles adoption—and we want [PILOT_TEAM_MEMBER_1], [PILOT_TEAM_MEMBER_2], and [PILOT_TEAM_MEMBER_3] to be our partners in testing it.
+>
+> **The Experiment**
+> We're using lightweight "Architecture Decision Records" (ADRs) to capture the rationale behind significant decisions we make. This helps us:
+> - 📝 Capture "why" while it's fresh (not reconstruct from git history months later)
+> - 🧅 Onboard new people with context, not just code
+> - 💡 Make our core principles real, not just a document
+>
+> **The Pilot Team**
+> This starts with the `dss_sync_figma` project. [PILOT_TEAM_NAMES], we're kicking off a 30-min sync on **[DAY], [DATE], [TIME]** to show how this works and get your feedback.
+>
+> **Why You?**
+> You're building something complex right now with interesting trade-offs. Perfect for piloting this process. We want your **honest feedback**—if this feels valuable, great. If it feels like noise, tell us that too.
+>
+> **Learn More**
+> Check out `.knowledge/adrs/README.md` for the full context and how this works.
+>
+> Questions? Drop them below or in the kickoff meeting.
+>
+> Let's go! 🚀
+
+---
+
+## Customization Checklist
+
+- [ ] Replace `[YOUR_TEAM_SLACK_CHANNEL]` with actual channel name
+- [ ] Replace `[PILOT_TEAM_MEMBER_1], [PILOT_TEAM_MEMBER_2], [PILOT_TEAM_MEMBER_3]` with actual names
+- [ ] Replace `[DAY]` with day of week (Thursday, Friday, etc.)
+- [ ] Replace `[DATE]` with date (Dec 12, etc.)
+- [ ] Replace `[TIME]` with meeting time (2:00 PM, etc.)
+
+---
+
+## Timing
+
+Post this message **24-48 hours before the kickoff meeting** to give team time to:
+- Read the README
+- Ask questions
+- Mentally prepare
+
+## Alternative (Longer Version)
+
+If your team prefers more context, use this expanded version:
+
+> 🎯 **DSS Principles Pilot: Let's Try Something New**
+>
+> We've spent the last month defining DSS's core principles—the "why" behind every decision we make. Now the real work begins: **bringing those principles to life in how we actually work.**
+>
+> **The Challenge**
+> Principles are only as good as their adoption. And one of our biggest challenges is that decision rationale gets lost. You write code today, and six months later, a new team member asks, "Why did we do it this way?" Git history says *what* changed, but not *why*. That context is in Slack, in commit messages, or just in your head. It's lost.
+>
+> **The Experiment**
+> We're testing a lightweight process: **Architecture Decision Records (ADRs)**. When we make a significant decision, we spend 15 minutes capturing:
+> - What is the decision?
+> - Why did we choose it?
+> - What alternatives did we consider and reject?
+> - What are the consequences?
+>
+> That's it. One file. Done.
+>
+> **The Pilot Team**
+> [PILOT_TEAM_NAMES], you're building `dss_sync_figma` right now, and that project has *exactly* the kind of architectural decisions this is designed for. We're asking you to be our test pilots.
+>
+> **What We're NOT Asking**
+> - Don't create ADRs for every decision (just the big, consequential ones)
+> - Don't spend hours on documentation (15 mins, max)
+> - Don't adopt new tools or learn new syntax (it's just Markdown)
+>
+> **What We ARE Asking**
+> - Create 1-3 ADRs over the next month for the biggest decisions
+> - Give us honest feedback: Does this help? Or is it just bureaucracy?
+> - Help us understand what works and what doesn't
+>
+> **Kickoff Meeting**
+> [DAY], [DATE], [TIME] – 30 minutes
+> We'll show you the template (it's tiny), write your first ADR together, and answer questions.
+>
+> **Learn More**
+> - `.knowledge/adrs/README.md` – Full overview
+> - `.knowledge/adrs/001-...md` – The meta-ADR explaining why we chose this approach
+>
+> Thanks for being our partners in this. Your feedback is what makes it work. 🚀
+
+---
+
+## Post-Kickoff Follow-up (Optional)
+
+After the kickoff meeting, consider sending this short note:
+
+> **ADR Kickoff Recap**
+>
+> Thanks everyone for the great kickoff! Here's what to do next:
+>
+> 📍 **Create ADRs** for your top 2-3 `dss_sync_figma` decisions over the next month
+> 📝 **Template**: Copy `.knowledge/adrs/000-template.md`
+> 🔗 **Link in PRs**: Add to the "DSS Principles Check" section
+> 💬 **Questions**: Post in thread or grab me directly
+>
+> Check-ins: I'll reach out around week 2-3 to see how it's going.
+> Retro: We'll do a 30-minute retrospective in Week 4 to gather your feedback.
+>
+> Let's see if this helps us move faster. 🎯
+
+---
+
+**Ready to send?** Replace the placeholders, copy, and paste to Slack!