docs: update all documentation and add AI tooling configs

- Rewrite README.md with current architecture, features and stack
- Update docs/API.md with all current endpoints (corporate, BI, client 360)
- Update docs/ARCHITECTURE.md with cache, modular queries, services, ETL
- Update docs/GUIA-USUARIO.md for all roles (admin, corporate, agente)
- Add docs/INDEX.md documentation index
- Add PROJETO.md comprehensive project reference
- Add BI-CCC-Implementation-Guide.md
- Include AI agent configs (.claude, .agents, .gemini, _bmad)
- Add netbird VPN configuration
- Add status report

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-03-19 13:29:03 -04:00
parent c5b377e788
commit 647cbec54f
3246 changed files with 479789 additions and 983 deletions

View File

@@ -0,0 +1,223 @@
# Freya's Agentic Development Guide
**When to load:** When implementing features, building prototypes, or fixing bugs through structured development
> **Note:** Agent dialogs have been replaced by the Design Log system. Use `_progress/00-design-log.md` for state tracking and `_progress/agent-experiences/` for session insights.
---
## Core Principle
**Agentic Development builds incrementally with full traceability via the design log.**
The design log bridges the gap between specifications and working code. Each step is self-contained, allowing fresh context while maintaining continuity.
---
## What is Agentic Development?
Agentic Development is a **workflow approach** that produces various outputs:
| Output Type | Description | When to Use |
|-------------|-------------|-------------|
| **Interactive Prototypes** | HTML prototypes that let users FEEL the design | Validating UX before production |
| **Prototype Implementation** | Building features from specifications | Feature development |
| **Bug Fixes** | Structured debugging and fixing | Issue resolution |
| **Design Exploration** | Exploring visual/UX directions | Creative iteration |
**Key Insight:** By structuring work with a design log and experience records, we create:
- **Isolation** — Each step can run in a fresh context
- **Traceability** — Clear record of what was planned and executed
- **Replayability** — Instructions can be rerun if needed
- **Handoff** — Different agents or humans can continue the work
---
## Agent Startup Protocol
**When awakened, always check the design log:**
```
1. Read: {output_folder}/_progress/00-design-log.md
2. Check Current and Backlog sections for:
- Items in progress
- Items ready to start
3. Present current state to user
```
This ensures no captured work is forgotten.
---
## The Bridge Role
The design log bridges **specifications** and **development**:
```
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ SPECIFICATION │ │ DESIGN LOG │ │ DEVELOPMENT │
│ │ │ │ │ │
│ • What to build │────────▶│ • What's in scope │────────▶│ • How to build │
│ • Object IDs │ │ • Current/Backlog │ │ • Code files │
│ • Requirements │ │ • Traceability │ │ • Components │
│ • Translations │ │ • Progress tracking │ │ • Tests │
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
Single Source Navigation Implementation
of Truth Layer
```
**The specification is the single source of truth.** The design log does not duplicate spec content — it maps implementation tasks to spec sections via Object IDs.
---
## Progress Folder Structure
```
{output_folder}/_progress/
├── 00-design-log.md ← Main state tracking
└── agent-experiences/
├── {DATE}-{agent}-{feature-name}.md ← Session insights
└── ...
```
---
## Feedback Protocol
During implementation, classify and handle feedback naturally:
| Type | What It Is | When to Address |
|------|------------|-----------------|
| **Bug/Issue** | Something broken or not working as expected | Now — iterate until fixed |
| **Quick Adjustment** | Small tweak to current work | Now — implement immediately |
| **Addition** | New requirement that fits current scope | Later step — add to plan |
| **Change Request** | Outside current dialog scope | Future session — document in Change Requests |
**Response Pattern:**
1. **Classify** — Note what kind of feedback this is
2. **Timing** — State when it should be addressed
3. **Confirm** — For additions and change requests, confirm before proceeding
4. **Execute** — Implement or document as appropriate
---
## Inline Testing
**The agent tests its own work before presenting it to the user.**
During agentic development, use Puppeteer to verify measurable criteria after each implementation step. This ensures the user only evaluates qualitative aspects (feel, clarity, hierarchy) rather than checking things the agent can measure.
**Key rules:**
1. **Verify before presenting** — After implementing a section, open the page with Puppeteer and check all measurable criteria
2. **Narrate findings** — Use ✓/✗ marks with actual vs expected values
3. **Fix before showing** — Never present with known measurable failures
4. **Capture baselines** — Before modifying existing features, document current state with Puppeteer
5. **Split test plans** — Story files divide criteria into agent-verifiable and user-evaluable
**Responsibility split:**
- **Agent handles:** Text content, colors, dimensions, touch targets, error states, visibility, state transitions
- **Human handles:** Flow feel, visual hierarchy, user understanding, overall consistency
**Full methodology:** `workflows/4-ux-design/agentic-development/guides/INLINE-TESTING-GUIDE.md`
---
## Interactive Prototypes (Output Type)
Interactive Prototypes are **one output** of Agentic Development.
### Why HTML Prototypes?
**Static Specs Can't Show:**
- How it FEELS to interact
- Where users get confused
- What's missing in the flow
- If the pacing feels right
**HTML Prototypes Reveal:**
- Interaction feels natural or awkward
- Information appears when needed
- Flow has logical gaps
- Users understand next steps
### Fidelity Levels
| Level | Focus | Use When |
|-------|-------|----------|
| **Wireframe** | Information architecture | Testing flow logic only |
| **Interactive** | User experience | Validating UX (standard) |
| **Design System** | Component-based | Phase 5 enabled |
### Prototype vs Production
**Prototypes ARE:**
- Thinking tools
- Communication tools
- Validation tools
- Specification supplements
**Prototypes are NOT:**
- Production code
- Pixel-perfect mockups
- Final design
---
## Prototype Implementation (Output Type)
Building features from specifications through structured dialog steps.
### Step File Structure
Each step links to specifications (doesn't duplicate):
```markdown
## Object ID Implementation Map
| Object ID | Spec Section | Lines |
|-----------|--------------|-------|
| `booking-detail-header` | Drawer Header | L149-L158 |
| `booking-detail-close` | Close Button | L159-L168 |
```
### Implementation Checklist Pattern
For each Object ID:
1. **Read** — Load the spec section
2. **Implement** — Build to match spec
3. **Verify (Puppeteer)** — Open in browser, check measurable criteria with ✓/✗ narration
4. **Fix** — Resolve any mismatches before presenting to user
---
## Best Practices
### Single Source of Truth
- **Never duplicate spec content** — Link to spec sections with line numbers
- **Object IDs are the contract** — Every implementation maps to an Object ID
- **Spec changes update the spec** — Not the dialog or step files
### Design Log
- **Be thorough in Setup Context** — Assume zero prior knowledge
- **Include file paths** — Always use absolute or project-relative paths
- **Track progress** — Update the design log after each step
### Execution
- **Read spec first** — Before implementing any Object ID
- **Fresh context is fine** — Steps are designed to work in isolation
- **Update as you go** — Don't wait to update progress
- **Capture discoveries** — Note spec changes or issues found
---
## Related Resources
- **Design Log:** `{output_folder}/_progress/00-design-log.md`
- **Agent Experiences:** `{output_folder}/_progress/agent-experiences/`
- **Phase 4 UX Design:** `workflows/4-ux-design/workflow.md`
- **Inline Testing Guide:** `workflows/5-agentic-development/guides/INLINE-TESTING-GUIDE.md`
---
*Build incrementally. Document thoroughly. Let users FEEL the design before committing to production.*

View File

@@ -0,0 +1,270 @@
# Freya's Content Creation Guide
**When to load:** Before creating strategic content (headlines, features, text sections)
---
## Core Principle
**Content is strategic, not decorative.** Every word should trigger user psychology and serve business goals.
---
## Content Creation Workshop
**Use the Content Creation Workshop for:**
- ✅ Headlines and subheadlines
- ✅ Hero sections and value propositions
- ✅ Feature descriptions and benefits
- ✅ Call-to-action messaging
- ✅ Page sections (entire blocks)
**NOT for:**
- ❌ Field labels ("Email", "Password")
- ❌ Button text ("Submit", "Cancel")
- ❌ Error messages ("Invalid email format")
- ❌ UI microcopy (that's Tone of Voice territory)
---
## When to Suggest the Workshop
### Signs User Needs It
- Creating content without strategic context
- Asking "What should this headline say?"
- Struggling with messaging
- Content feels generic or weak
- Multiple content pieces to create
### How to Suggest (Natural, Not Pushy)
> "This headline is important - it hooks Problem Aware users. Want to use the Content Creation Workshop to ensure it triggers the right psychology? Takes 10-15 minutes but makes content way more effective."
**Let them decide.** Some users prefer quick mode, others want depth.
---
## Quick Mode vs Workshop Mode
### Quick Mode
**When:**
- Simple, straightforward content
- User is experienced with WDS
- Context is crystal clear
- Time is tight
**Process:**
1. Load Trigger Map for context
2. Consider Customer Awareness
3. Apply Golden Circle (WHY → HOW → WHAT)
4. Generate options
5. Explain rationale
---
### Workshop Mode
**When:**
- Critical content (hero, main CTA)
- User wants strategic depth
- Multiple frameworks apply
- Content is complex
**Process:**
Load: `{project-root}/_bmad/wds/workflows/6-asset-generation/`
**6-Step Framework:**
1. Define purpose & success criteria
2. Load Trigger Map context
3. Apply Customer Awareness strategy
4. Filter with Action Mapping
5. Frame with Badass Users
6. Structure with Golden Circle
7. Generate content
---
## The 6-Model Framework
### 1. Content Purpose
**"What job does this content do?"**
- Convince Problem Aware users that speed matters
- Reassure anxious users about security
- Trigger desire to feel professional
**Must be specific and measurable.**
---
### 2. Trigger Map
**Strategic foundation**
- Business Goal: What are we trying to achieve?
- User: Who are we serving?
- Driving Forces: What motivates them? (positive + negative)
- Solution: What triggers these forces?
**Informs** which psychology to trigger.
---
### 3. Customer Awareness Cycle
**Content strategy - language & focus**
Where user is → Where we want them:
- **Unaware → Problem Aware:** Educate on problem
- **Problem → Solution Aware:** Show solutions exist
- **Solution → Product Aware:** Differentiate your solution
- **Product → Most Aware:** Remove friction, show proof
- **Most Aware:** Maintain, deepen relationship
**Determines** what language they can understand.
---
### 4. Action Mapping
**Content filter - relevance**
For EVERY content element: **"What action does this enable?"**
- ❌ "Nice to know" → Remove it
- ✅ "Need to do" → Keep and strengthen
**Strips** fluff, focuses on user actions.
---
### 5. Kathy Sierra Badass Users
**Content tone & frame**
Frame content around user becoming capable:
- Show transformation (current → badass state)
- Reduce cognitive load
- Create "aha moments"
- Make them feel smart, not overwhelmed
**Makes** users feel empowered, not intimidated.
---
### 6. Golden Circle
**Structural order**
Always structure: **WHY → HOW → WHAT**
```
Headline (WHY): Stop losing clients to slow proposals
Subhead (HOW): AI-powered templates deliver in minutes
Features (WHAT): 10K templates, smart pricing, e-signatures
```
**Gives** content persuasive flow.
---
## How the Models Work Together
**Think of them as lenses, not sequential steps:**
1. **Trigger Map** = Which driving force to trigger?
2. **Customer Awareness** = What language can they understand?
3. **Golden Circle** = In what order should I present?
4. **Action Mapping** = Is this enabling action?
5. **Badass Users** = Does this make them feel capable?
6. **Content Purpose** = Does it achieve its job?
**AI synthesizes all six** to produce optimal content.
---
## Content Purpose Examples
### Good (Specific & Measurable)
- "Convince Problem Aware users that proposal speed matters more than perfection"
- "Reassure Product Aware users about data security concerns"
- "Trigger Solution Aware users' desire to feel like industry experts"
### Bad (Vague)
- "Make users want the product"
- "Explain features"
- "Sound professional"
**Test:** Can someone else determine if the content succeeded?
---
## Model Priority Matrix
**Different content types prioritize different models:**
### Landing Page Hero
- Customer Awareness: ⭐⭐⭐
- Golden Circle: ⭐⭐⭐
- Badass Users: ⭐⭐
- Action Mapping: ⭐
- Trigger Map: Always loaded
- Content Purpose: Always defined
### Feature Description
- Action Mapping: ⭐⭐⭐
- Badass Users: ⭐⭐⭐
- Customer Awareness: ⭐⭐
- Golden Circle: ⭐
- Trigger Map: Always loaded
- Content Purpose: Always defined
### Error Messages
**Don't use workshop** - Use Tone of Voice instead
---
## Tone of Voice vs Strategic Content
### Tone of Voice (Product-Wide)
- Field labels: "Email address"
- Button text: "Get started"
- Error messages: "Please enter a valid email"
- Success messages: "Profile updated!"
**Defined once** in Product Brief, applied everywhere.
---
### Strategic Content (Context-Specific)
- Headlines: "Stop losing clients to slow proposals"
- Value propositions: "AI-powered templates that close deals faster"
- Feature benefits: "Create stunning proposals in minutes, not hours"
**Created with workshop**, varies by context.
---
## Quick Reference
**Before creating any strategic content:**
1. **Define purpose** - What job does this do?
2. **Load Trigger Map** - Which driving forces?
3. **Check awareness** - Where are users?
4. **Apply Golden Circle** - WHY → HOW → WHAT
5. **Filter with Action** - Does it enable action?
6. **Frame as empowering** - Make them feel capable
7. **Validate** - Does it achieve its purpose?
---
## Related Resources
- **Asset Generation:** `{project-root}/_bmad/wds/workflows/6-asset-generation/`
- **Content Purpose Guide:** `../../docs/method/content-purpose-guide.md`
- **Tone of Voice Guide:** `../../docs/method/tone-of-voice-guide.md`
- **Customer Awareness Cycle:** `../../docs/models/customer-awareness-cycle.md`
- **Golden Circle:** `../../docs/models/golden-circle.md`
- **Action Mapping:** `../../docs/models/action-mapping.md`
- **Kathy Sierra Badass Users:** `../../docs/models/kathy-sierra-badass-users.md`
---
*Every word is a strategic choice. Content triggers psychology.*

View File

@@ -0,0 +1,333 @@
# Freya's Design System Guide
**When to load:** When Phase 7 (Design System) is enabled and component questions arise
---
## Core Principle
**Design systems grow organically - discover components through actual work, never create speculatively.**
---
## Three Design System Modes
### Mode A: No Design System
**What it means:**
- All components stay page-specific
- No component extraction
- AI/dev team handles consistency
- Faster for simple projects
**When this workflow doesn't run:**
- Phase 7 is disabled
- Components reference page context only
**Agent behavior:**
- Create components as page-specific
- Use clear, descriptive class names
- No need to think about reusability
---
### Mode B: Custom Figma Design System
**What it means:**
- Designer defines components in Figma
- Components extracted as discovered during Phase 4
- Figma MCP endpoints for integration
- Component IDs link spec ↔ Figma
**Workflow:**
1. Designer creates component in Figma
2. Component discovered during page design
3. Agent links to Figma via Component ID
4. Specification references Figma source
**See:** `../../workflows/6-asset-generation/workflow-figma.md`
---
### Mode C: Component Library Design System
**What it means:**
- Uses shadcn/Radix/similar library
- Library chosen during setup
- Components mapped to library defaults
- Variants customized as needed
**Workflow:**
1. Component needed during page design
2. Check if library has it (button, input, card, etc.)
3. Map to library component
4. Document customizations (if any)
---
## The Design System Router
**Runs automatically during Phase 4 component specification**
**For each component:**
1. Check: Design system enabled? (Mode B or C)
2. If NO → Create page-specific, continue
3. If YES → Call design-system-router.md
**Router asks:**
- Is this component new?
- Is there a similar component?
- Should we create new or use/extend existing?
**See:** `../../workflows/7-design-system/design-system-router.md`
---
## Never Create Components Speculatively
### ❌ Wrong Approach
"Let me create a full component library upfront..."
**Why bad:**
- You don't know what you'll actually need
- Over-engineering
- Wasted effort on unused components
---
### ✅ Right Approach
"I'm designing the landing page hero... oh, I need a button."
**Process:**
1. Design the button for this specific page
2. When another page needs a button → Opportunity!
3. Assess: Similar enough to extract?
4. Extract to Design System if makes sense
**Result:** Components emerge from real needs.
---
## Opportunity/Risk Assessment
**When similar component exists, run assessment:**
**See:** `../../workflows/7-design-system/assessment/`
**7 Micro-Steps:**
1. Scan existing components
2. Compare attributes (visual, behavior, states)
3. Calculate similarity score
4. Identify opportunities (reuse, consistency)
5. Identify risks (divergence, complexity)
6. Present decision to designer
7. Execute decision
**Outcomes:**
- **Use existing** - Component is close enough
- **Create variant** - Extend existing with new state
- **Create new** - Too different, warrants separate component
- **Update existing** - Existing is too narrow, expand it
---
## Foundation First
**Before any components:**
### 1. Design Tokens
```
Design tokens = the DNA of your design system
Colors:
- Primary, secondary, accent
- Neutral scale (50-900)
- Semantic (success, warning, error, info)
Typography:
- Font families
- Font scales (h1-h6, body, caption)
- Font weights
- Line heights
Spacing:
- Spacing scale (xs, sm, md, lg, xl)
- Layout scales
Effects:
- Border radius scale
- Shadow scale
- Transitions
```
**Why first:** Tokens ensure consistency across all components.
---
### 2. Atomic Design Structure
**Organize from simple → complex:**
```
atoms/
├── button.md
├── input.md
├── label.md
├── icon.md
└── badge.md
molecules/
├── form-field.md (label + input + error)
├── card.md (container + content)
└── search-box.md (input + button + icon)
organisms/
├── header.md (logo + nav + search + user-menu)
├── feature-section.md (headline + cards + cta)
└── form.md (multiple form-fields + submit)
```
**Why this structure:** Clear dependencies, easy to understand, scales well.
---
## Component Operations
**See:** `../../workflows/7-design-system/operations/`
### 1. Initialize Design System
**First component triggers auto-initialization**
- Creates folder structure
- Creates design-tokens.md
- Creates component-library-config.md (if Mode C)
### 2. Create New Component
- Defines component specification
- Assigns Component ID
- Documents states and variants
- Notes where used
### 3. Add Variant
- Extends existing component
- Documents variant trigger
- Updates component spec
### 4. Update Component
- Modifies existing definition
- Increments version
- Documents change rationale
---
## Component Specification Template
```markdown
# [Component Name] [COMP-001]
**Type:** [Atom|Molecule|Organism]
**Library:** [shadcn Button|Custom|N/A]
**Figma:** [Link if Mode B]
## Purpose
[What job does this component do?]
## Variants
- variant-name: [When to use]
- variant-name: [When to use]
## States
- default
- hover
- active
- disabled
- loading (if applicable)
- error (if applicable)
## Props/Attributes
| Prop | Type | Default | Description |
|------|------|---------|-------------|
| size | sm\|md\|lg | md | Button size |
| variant | primary\|secondary | primary | Visual style |
## Styling
[Design tokens or Figma reference]
## Used In
- [Page name] ([Component purpose in context])
- [Page name] ([Component purpose in context])
## Version History
- v1.0.0 (2024-01-01): Initial creation
```
---
## Integration with Phase 4
**Phase 4 (UX Design) → Phase 7 (Design System) flow:**
```
User creates page specification
├── Component 1: Button
│ ├── Check: Design system enabled?
│ ├── YES → Router checks existing components
│ ├── Similar button found → Opportunity/Risk Assessment
│ └── Decision: Use existing primary button variant
├── Component 2: Input
│ ├── Check: Design system enabled?
│ ├── YES → Router checks existing components
│ ├── No similar input → Create new
│ └── Add to Design System
└── Component 3: Custom illustration
├── Check: Design system enabled?
└── NO extraction (one-off asset)
```
**Result:**
- Page spec contains references + page-specific content
- Design System contains component definitions
- Clean separation maintained
---
## Common Mistakes
### ❌ Creating Library Before Designing
"Let me make 50 components upfront..."
- **Instead:** Design pages, extract components as needed
### ❌ Over-Abstracting Too Early
"This button might need 10 variants someday..."
- **Instead:** Start simple, add variants when actually needed
### ❌ Forcing Reuse
"I'll make this work even though it's awkward..."
- **Instead:** Sometimes a new component is better than a forced variant
### ❌ No Design Tokens
"I'll define colors per component..."
- **Instead:** Tokens first, components second
---
## Quality Checklist
Before marking a component "complete":
- [ ] **Clear purpose** - What job does it do?
- [ ] **Design tokens** - Uses tokens, not hard-coded values?
- [ ] **All states** - Default, hover, active, disabled documented?
- [ ] **Variants** - Each variant has clear use case?
- [ ] **Reusability** - Can be used in multiple contexts?
- [ ] **Documentation** - Specification is complete?
- [ ] **Examples** - Shows where it's actually used?
---
## Related Resources
- **Phase 7 Workflow:** `../../workflows/7-design-system/`
- **Figma Integration:** `../../workflows/6-asset-generation/workflow-figma.md`
- **Shared Knowledge:** `../design-system/` (tokens, naming, states, validation, boundaries)
---
*Components emerge from real needs. Design systems grow organically.*

View File

@@ -0,0 +1,495 @@
# Freya's Meta Content Guide
**When to load:** When specifying public pages that will appear in search results or be shared on social media
---
## Core Principle
**Every public page needs meta content for search results and social sharing.**
Meta content is not just SEO - it's essential page content that appears when users:
- Find your page in Google search results
- Share your page on Facebook, Twitter, LinkedIn
- Bookmark your page in their browser
---
## When to Collect Meta Content
### Public Pages (Always Required)
- Landing pages
- Marketing pages
- Blog posts
- Product pages
- About/Contact pages
- Any page accessible without login
### Private/Authenticated Pages (Browser Tab Only)
- Dashboard pages
- Settings pages
- User profile pages
- Admin pages
- Any page requiring authentication
---
## Meta Content Components
### 1. Page Title (Browser Tab & Search Results)
**Purpose:** Appears in browser tab, search results, and social media shares
**Character Limit:** 55-60 characters (including brand name)
**Best Practices:**
- Front-load important keywords
- Include brand name at end (if space allows)
- Be descriptive and specific
- Make it compelling for clicks
**Agent Questions:**
```
"What should appear in the browser tab and search results for this page?"
"Keep it under 60 characters and make it descriptive."
"Example: 'Dog Walking Coordination - Dog Week' (42 chars)"
```
**Example:**
```markdown
### Page Title (Browser Tab & Search Results)
**Character Limit:** 55-60 characters
**Content:**
- EN: "Dog Walking Coordination - Dog Week"
- SE: "Hundpromenad Koordinering - Dog Week"
```
---
### 2. Meta Description (Search Results Preview)
**Purpose:** Appears below page title in search results
**Character Limit:** 150-160 characters
**Best Practices:**
- Summarize page value clearly
- Include call-to-action
- Use active voice
- Address user pain point or benefit
- Don't just repeat page title
**Agent Questions:**
```
"How would you describe this page in 150-160 characters to encourage clicks from search results?"
"What value does this page provide to users?"
"What action should they take?"
```
**Example:**
```markdown
### Meta Description (Search Results Preview)
**Character Limit:** 150-160 characters
**Content:**
- EN: "Coordinate dog walks with your family. Never miss a walk again. Simple scheduling, automatic reminders, and family accountability. Start free today."
- SE: "Koordinera hundpromenader med din familj. Missa aldrig en promenad igen. Enkel schemaläggning, automatiska påminnelser. Börja gratis idag."
```
---
### 3. Social Media Title
**Purpose:** Appears when page is shared on Facebook, Twitter, LinkedIn, etc.
**Character Limit:** 60-70 characters
**Best Practices:**
- Can differ from page title
- Optimize for social engagement
- More conversational tone OK
- Focus on benefit or curiosity
**Agent Questions:**
```
"What title would work best when this page is shared on social media?"
"Can be different from page title, optimized for social engagement."
"Think: What would make someone click when they see this in their feed?"
```
**Example:**
```markdown
#### Social Media Title
**Character Limit:** 60-70 characters
**Content:**
- EN: "Never Forget a Dog Walk Again 🐕"
- SE: "Glöm Aldrig en Hundpromenad Igen 🐕"
```
---
### 4. Social Media Description
**Purpose:** Appears below title in social media share previews
**Character Limit:** 120-150 characters
**Best Practices:**
- Shorter than meta description
- More casual/engaging tone
- Create curiosity or urgency
- Include benefit
**Agent Questions:**
```
"What description would encourage people to click when they see this shared on Facebook/Twitter/LinkedIn?"
"Keep it under 150 characters and make it engaging."
```
**Example:**
```markdown
#### Social Media Description
**Character Limit:** 120-150 characters
**Content:**
- EN: "Family dog walking made simple. Schedule walks, get reminders, and keep everyone accountable. Free to start."
- SE: "Familjens hundpromenader enkelt. Schemalägg, få påminnelser, håll alla ansvariga. Gratis att börja."
```
---
### 5. Social Media Image
**Purpose:** Appears as preview image when page is shared
**Image Requirements:**
- **Dimensions:** 1200x630px (Open Graph standard)
- **Format:** JPG or PNG
- **File size:** < 1MB
- **Content:** Should represent page visually
**Best Practices:**
- Use high-quality images
- Include text overlay if helpful
- Ensure readable on mobile
- Test on different platforms
- Avoid too much text (Facebook limits)
**Agent Questions:**
```
"What image best represents this page content?"
"Should be 1200x630px and visually engaging."
"Consider: Product screenshot, hero image, or custom graphic?"
```
**Example:**
```markdown
#### Social Media Image
**Image Requirements:**
- Dimensions: 1200x630px (Open Graph standard)
- Format: JPG or PNG
- File size: < 1MB
**Image Path:** `/images/social/start-page-social.jpg`
**Alt Text:**
- EN: "Dog Week app showing family dog walking schedule on mobile phone"
- SE: "Dog Week-appen visar familjens hundpromenadschema mobiltelefon"
```
---
## Agent Workflow for Public Pages
### Step 1: Identify Page Visibility
Ask: "Is this page publicly accessible (no login required)?"
- **Yes** Collect all meta content
- **No** Only collect browser tab title
---
### Step 2: Collect Page Title
**Question:**
```
"What should appear in the browser tab and search results for this page?
Keep it under 60 characters and make it descriptive.
Example: 'Dog Walking Coordination - Dog Week' (42 chars)
Your page title:"
```
**Validate:**
- Length 60 characters
- Descriptive and specific
- Includes brand name (if space)
---
### Step 3: Collect Meta Description
**Question:**
```
"How would you describe this page in 150-160 characters to encourage clicks from search results?
What value does this page provide?
What action should users take?
Your meta description:"
```
**Validate:**
- Length 150-160 characters
- Includes value proposition
- Has call-to-action
- Not just repeating title
---
### Step 4: Collect Social Media Title
**Question:**
```
"What title would work best when this page is shared on social media?
Can be different from page title, optimized for engagement.
Think: What would make someone click in their feed?
Your social media title:"
```
**Validate:**
- Length 60-70 characters
- Engaging and conversational
- Creates curiosity or shows benefit
---
### Step 5: Collect Social Media Description
**Question:**
```
"What description would encourage clicks when shared on Facebook/Twitter/LinkedIn?
Keep it under 150 characters and make it engaging.
Your social media description:"
```
**Validate:**
- Length 120-150 characters
- Casual and engaging tone
- Shows clear benefit
---
### Step 6: Specify Social Media Image
**Question:**
```
"What image best represents this page content?
Should be 1200x630px and visually engaging.
Options: Product screenshot, hero image, custom graphic
Image description:"
```
**Document:**
- Image path
- Alt text in all languages
- Image requirements
---
## Multi-Language Considerations
**All meta content must be provided in all product languages.**
**Translation Tips:**
- Character limits apply to each language
- Some languages are more verbose (German, Swedish)
- May need to adjust wording to fit limits
- Maintain same tone and message across languages
**Example:**
```markdown
**Content:**
- EN: "Never Forget a Dog Walk Again" (32 chars)
- SE: "Glöm Aldrig en Hundpromenad Igen" (34 chars) ← Slightly longer, still fits
```
---
## Common Mistakes to Avoid
### ❌ Mistake 1: Generic Titles
**Wrong:**
```
Page Title: "Home - Dog Week"
```
**Right:**
```
Page Title: "Dog Walking Coordination - Dog Week"
```
---
### ❌ Mistake 2: Too Long
**Wrong:**
```
Meta Description: "Dog Week is an amazing application that helps families coordinate their dog walking schedules so that everyone knows when the dog needs to be walked and who is responsible for each walk throughout the day and week." (215 chars)
```
**Right:**
```
Meta Description: "Coordinate dog walks with your family. Never miss a walk again. Simple scheduling, automatic reminders, and family accountability. Start free today." (149 chars)
```
---
### ❌ Mistake 3: No Call-to-Action
**Wrong:**
```
Meta Description: "Dog Week is a dog walking coordination app for families."
```
**Right:**
```
Meta Description: "Coordinate dog walks with your family. Never miss a walk again. Start free today."
```
---
### ❌ Mistake 4: Same Content Everywhere
**Wrong:**
```
Page Title: "Dog Walking Coordination - Dog Week"
Social Title: "Dog Walking Coordination - Dog Week" ← Same as page title
```
**Right:**
```
Page Title: "Dog Walking Coordination - Dog Week"
Social Title: "Never Forget a Dog Walk Again 🐕" ← Optimized for social
```
---
## Validation Checklist
Before finalizing meta content:
- [ ] **Page visibility identified** (Public/Private/Authenticated)
- [ ] **Page title** 60 characters, descriptive
- [ ] **Meta description** 150-160 characters, includes CTA
- [ ] **Social title** 60-70 characters, engaging
- [ ] **Social description** 120-150 characters, benefit-focused
- [ ] **Social image** specified with path and alt text
- [ ] **All languages** provided for each content item
- [ ] **Character limits** respected in all languages
- [ ] **Tone appropriate** for each context (search vs social)
---
## Example: Complete Meta Content Specification
```markdown
## Meta Content & Social Sharing
**Page Visibility:** Public
### Page Title (Browser Tab & Search Results)
**Character Limit:** 55-60 characters
**Content:**
- EN: "Dog Walking Coordination - Dog Week"
- SE: "Hundpromenad Koordinering - Dog Week"
**Purpose:** Appears in browser tab, search results, and social media shares.
---
### Meta Description (Search Results Preview)
**Character Limit:** 150-160 characters
**Content:**
- EN: "Coordinate dog walks with your family. Never miss a walk again. Simple scheduling, automatic reminders, and family accountability. Start free today."
- SE: "Koordinera hundpromenader med din familj. Missa aldrig en promenad igen. Enkel schemaläggning, automatiska påminnelser. Börja gratis idag."
**Purpose:** Appears below page title in search results.
---
### Social Sharing Content
#### Social Media Title
**Character Limit:** 60-70 characters
**Content:**
- EN: "Never Forget a Dog Walk Again 🐕"
- SE: "Glöm Aldrig en Hundpromenad Igen 🐕"
**Purpose:** Appears when page is shared on Facebook, Twitter, LinkedIn.
---
#### Social Media Description
**Character Limit:** 120-150 characters
**Content:**
- EN: "Family dog walking made simple. Schedule walks, get reminders, and keep everyone accountable. Free to start."
- SE: "Familjens hundpromenader enkelt. Schemalägg, få påminnelser, håll alla ansvariga. Gratis att börja."
**Purpose:** Appears below title in social media share previews.
---
#### Social Media Image
**Image Requirements:**
- Dimensions: 1200x630px (Open Graph standard)
- Format: JPG or PNG
- File size: < 1MB
**Image Path:** `/images/social/start-page-social.jpg`
**Alt Text:**
- EN: "Dog Week app showing family dog walking schedule on mobile phone"
- SE: "Dog Week-appen visar familjens hundpromenadschema mobiltelefon"
**Purpose:** Appears as preview image when page is shared on social media.
```
---
## SEO Integration
Meta content is one part of a broader SEO strategy. For comprehensive SEO guidance:
- **SEO Strategy Guide:** `../saga/seo-strategy-guide.md` Full SEO reference (keywords, URL structure, local SEO, structured data, image SEO)
- **SEO Content Instructions:** `../../workflows/4-ux-design/templates/instructions/seo-content.instructions.md` Page-level SEO checklist during specification
- **Project Brief SEO:** Check the project's content-language document for the page-keyword map and SEO strategy
**Workflow:** The project brief (Phase 1) captures the SEO strategy. Page specifications (Phase 4) apply it per page. This guide handles the meta content portion but also check heading hierarchy, alt text, internal links, and structured data.
---
## Related Resources
- **Page Specification Template:** `../../workflows/4-ux-design/templates/page-specification.template.md`
- **Language Configuration:** `../../workflows/00-system/language-configuration-guide.md`
- **SEO Strategy Guide:** `../saga/seo-strategy-guide.md`
---
**Meta content is essential page content, not an afterthought. Collect it during specification, not during development.** 🌐✨

View File

@@ -0,0 +1,262 @@
# Freya's Specification Quality Guide
**When to load:** Before creating any page spec, component definition, or scenario documentation
---
## Core Principle
**If I can't explain it logically, it's not ready to specify.**
Gaps in logic become bugs in code. Clear specifications = confident implementation.
---
## The Logical Explanation Test
Before you write any specification, ask:
**"Can I explain WHY this exists and HOW it works without hand-waving?"**
- ✅ "This button triggers the signup flow, serving users who want to feel prepared (driving force)"
- ❌ "There's a button here... because users need it?"
**If you can't explain it clearly, stop and think deeper.**
---
## Area Label Structure & Hierarchy
**Area Labels follow a consistent hierarchical pattern to identify UI locations across sketch, specification, and code.**
### Structural Area Labels (Containers)
These define the page architecture and visual grouping:
- `{page-name}-page` - Top-level page wrapper
- `{page-name}-header` - Header section container
- `{page-name}-main` - Main content area
- `{page-name}-form` - Form element wrapper
- `{page-name}-{section}-section` - Section containers
- `{page-name}-{section}-header-bar` - Section header bars
**Purpose:** Organize page structure, enable Figma layer naming (via aria-label), support testing selectors (via id attribute)
### Interactive Area Labels (Components)
These identify specific interactive elements:
- `{page-name}-{section}-{element}` - Standard pattern
- `{page-name}-input-{field}` - Form inputs
- `{page-name}-button-{action}` - Buttons
- `{page-name}-error-{field}` - Error messages
**Purpose:** Enable user interaction, form validation, accessibility, and location tracking across design and code
**Note:** Area Labels become both `id` and `aria-label` attributes in HTML implementation.
### Purpose-Based Naming
**Name components by FUNCTION, not CONTENT**
### Good (Function)
- `hero-headline` - Describes its role on the page
- `primary-cta` - Describes its function in the flow
- `feature-benefit-section` - Describes what it does
- `form-validation-error` - Describes when it appears
### Bad (Content)
- `welcome-message` - What if the message changes?
- `blue-button` - What if we change colors?
- `first-paragraph` - Position isn't purpose
- `email-error-text` - Too specific, not reusable
**Why this matters:**
- Content changes, function rarely does
- Makes specs maintainable
- Helps developers understand intent
- Enables component reuse
- Supports Figma html.to.design layer naming
---
## Clear Component Purpose
**Every component needs a clear job description:**
### Template
```markdown
### [Component Name]
**Purpose:** [What job does this do?]
**Triggers:** [What user action/state causes this?]
**Serves:** [Which driving force or goal?]
**Success:** [How do we know it worked?]
```
### Example
```markdown
### Primary CTA Button
**Purpose:** Initiate account creation flow
**Triggers:** User clicks after reading value proposition
**Serves:** User's desire to "feel prepared" (positive driving force)
**Success:** User enters email and moves to step 2
```
---
## Section-First Workflow
**Understand the WHOLE before detailing the PARTS**
### Wrong Approach (Bottom-Up)
1. Design individual components
2. Try to arrange them into sections
3. Hope the page makes sense
4. Realize it doesn't flow logically
5. Start over
### Right Approach (Top-Down)
1. **Define structural containers** - Page, header, main, sections
2. **Assign structural Area Labels** - `{page}-page`, `{page}-header`, etc.
3. **Identify page sections** - What major areas exist?
4. **Define section purposes** - Why does each section exist?
5. **Confirm flow logic** - Does the story make sense?
6. **Detail each section** - Now design components
7. **Specify components** - With clear purpose and context
8. **Assign interactive Area Labels** - `{page}-{section}-{element}`
**Result:** Logical flow, no gaps, confident specifications, complete Area Label coverage
### Area Label Coverage Checklist
- [ ] Page container (`{page}-page`)
- [ ] Header section (`{page}-header`)
- [ ] Main content area (`{page}-main`)
- [ ] Form container if applicable (`{page}-form`)
- [ ] Section containers (`{page}-{section}-section`)
- [ ] Section header bars if visible (`{page}-{section}-header-bar`)
- [ ] All interactive elements (`{page}-{section}-{element}`)
---
## Multi-Language from the Start
**Never design in one language only**
### Grouped Translations
```markdown
#### Hero Headline
**Content:**
- EN: "Stop losing clients to poor proposals"
- SE: "Sluta förlora kunder på dåliga offerter"
- NO: "Slutt å miste kunder på dårlige tilbud"
**Purpose:** Hook Problem Aware users by validating frustration
```
### Why This Matters
- Prevents "English-first" bias
- Reveals translation issues early
- Shows if message works across cultures
- Keeps translations coherent (grouped by component)
---
## Specification Quality Checklist
Before marking a spec "complete":
### Core Quality
- [ ] **Logical Explanation** - Can I explain WHY and HOW?
- [ ] **Purpose-Based Names** - Named by function, not content?
- [ ] **Clear Purpose** - Every component has a job description?
- [ ] **Section-First** - Whole page flows logically?
- [ ] **Multi-Language** - All product languages included?
- [ ] **No Hand-Waving** - No "probably" or "maybe" or "users will figure it out"?
### Area Labels
- [ ] **Structural Area Labels** - Page, header, main, sections all have labels?
- [ ] **Interactive Area Labels** - All buttons, inputs, links have labels?
- [ ] **Area Label Hierarchy** - Labels follow `{page}-{section}-{element}` pattern?
- [ ] **Figma-Ready** - Area Labels support html.to.design layer naming?
### Accessibility
- [ ] **ARIA Labels** - All interactive elements have aria-label attributes?
- [ ] **Alt Text** - All images have descriptive alt attributes?
- [ ] **Form Labels** - All inputs have associated labels?
- [ ] **Keyboard Navigation** - Tab order and focus management documented?
- [ ] **Screen Reader Support** - Semantic HTML and ARIA attributes specified?
- [ ] **Color Contrast** - WCAG AA compliance (4.5:1 for text)?
- [ ] **Error Announcements** - Error messages accessible to screen readers?
- [ ] **Heading Hierarchy** - Logical H1-H6 structure documented?
### SEO (Public Pages)
- [ ] **H1 Present** - Exactly one H1 on the page, contains primary keyword?
- [ ] **Heading Hierarchy** - Logical H1 → H2 → H3, no skipped levels?
- [ ] **URL Slug** - Defined, keyword-rich, matches project brief keyword map?
- [ ] **Primary Keyword** - Identified and placed in H1, title tag, meta description?
- [ ] **Meta Title** - ≤ 60 chars, includes primary keyword + brand?
- [ ] **Meta Description** - 150-160 chars, includes keyword + CTA?
- [ ] **Image Alt Text** - All images have descriptive alt text in all languages?
- [ ] **Internal Links** - At least 2 links to other pages on the site?
- [ ] **Structured Data** - Schema type specified per project brief plan?
### Content Completeness
- [ ] **All Text Defined** - No placeholder content?
- [ ] **Error Messages** - All error states have messages in all languages?
- [ ] **Success Messages** - Confirmation messages defined?
- [ ] **Empty States** - Messages for no-data scenarios?
- [ ] **Loading States** - Loading indicators and messages?
- [ ] **Meta Content** - Page title and meta description for public pages?
- [ ] **Social Sharing** - Social media title, description, and image for public pages?
### Implementation Ready
- [ ] **Developer-Ready** - Could someone build this confidently?
- [ ] **Component References** - All design system components linked?
- [ ] **API Endpoints** - Data requirements documented?
- [ ] **Validation Rules** - Form validation clearly specified?
---
## Red Flags (Stop and Rethink)
🚩 **Vague language:** "Something here to help users understand..."
🚩 **Content-based names:** "blue-box", "top-paragraph"
🚩 **Missing purpose:** "There's a button... because buttons are good?"
🚩 **Illogical flow:** "This section comes after that one... because?"
🚩 **English-only:** "We'll translate later..."
🚩 **Gaps in logic:** "Users will just know what to do here"
🚩 **Missing accessibility:** "We'll add ARIA labels during development..."
🚩 **No alt text:** Images without descriptive alternatives
🚩 **Unlabeled inputs:** Form fields without associated labels
🚩 **No SEO section:** Public page without URL slug, keywords, or meta content
**When you spot these, pause and dig deeper.**
---
## The Developer Trust Test
**Imagine handing your spec to a developer who:**
- Has never seen your sketches
- Doesn't know the business context
- Speaks a different language
- Lives in a different timezone
**Could they build this confidently?**
- ✅ Yes → Good spec
- ❌ No → More work needed
---
## Related Resources
- **File Naming:** `../../workflows/00-system/FILE-NAMING-CONVENTIONS.md`
- **Language Config:** `../../workflows/00-system/language-configuration-guide.md`
- **Page Spec Template:** `../../workflows/4-ux-design/templates/page-specification.template.md`
---
*Quality specifications are the foundation of confident implementation.*

View File

@@ -0,0 +1,116 @@
# Freya's Strategic Design Guide
**When to load:** Before designing any page, component, or user flow
---
## Core Principle
**Every design decision connects to strategy.** Never design in a vacuum.
---
## Before You Design Anything
### 1. Load Strategic Context
**Ask yourself:**
- What's in the Trigger Map for this page/scenario?
- What does the Product Brief say?
**If missing:** Suggest creating one first. Design without strategy is decoration.
---
### 2. Connect to Business Goals
**Every major design choice should answer:**
- Which business goal does this serve?
- How does this move the needle on our success metrics?
**Example:**
- ❌ "Let's make this button blue because it's pretty"
- ✅ "This CTA should be prominent because it serves the 'Convert Problem Aware users' goal"
---
### 3. Identify User Driving Forces
**From the Trigger Map, ask:**
- What positive driving forces should we trigger? (wishes, desires, aspirations)
- What negative driving forces should we address? (fears, frustrations, anxieties)
**Example:**
- User wants to "feel like an industry expert"
- User fears "looking unprofessional to clients"
- Design should make them feel capable, not overwhelmed
---
### 4. Customer Awareness Stage
**Where are users in their journey?**
1. **Unaware** - Don't know they have a problem → Educate on problem
2. **Problem Aware** - Know the problem, not solutions → Show there are solutions
3. **Solution Aware** - Know solutions exist → Show why yours is different
4. **Product Aware** - Know your product → Remove friction, show proof
5. **Most Aware** - Ready to buy/use → Make it easy, reinforce decision
**Design implications:**
- Unaware users need more context, education
- Most Aware users need less explanation, more action
---
### 5. Content Hierarchy (Golden Circle)
**Structure content as:** WHY → HOW → WHAT
- **WHY** - Purpose, benefit, emotional hook (first)
- **HOW** - Process, approach, differentiation (second)
- **WHAT** - Features, specifics, details (last)
**Example:**
```
Hero Section:
├── Headline (WHY): "Stop losing clients to competitors with better proposals"
├── Subhead (HOW): "Create stunning proposals in minutes with AI-powered templates"
└── Features (WHAT): "10,000+ templates, Smart pricing, E-signatures"
```
---
## Strategic Design Checklist
Before finalizing any design:
- [ ] **Trigger Map** - Which driving force does this serve?
- [ ] **Business Goal** - How does this support our objectives?
- [ ] **Customer Awareness** - Appropriate for their awareness stage?
- [ ] **Golden Circle** - WHY before HOW before WHAT?
- [ ] **Logical Explanation** - Can I defend this decision strategically?
---
## When You're Stuck
**If you can't connect a design choice to strategy:**
1. It might not be needed (remove it)
2. You need more strategic context (ask for Trigger Map)
3. There's a better alternative (explore options)
**Never guess.** Always design with intent.
---
## Related Resources
- **Trigger Mapping:** `../../docs/method/phase-2-trigger-mapping-guide.md`
- **Customer Awareness:** `../../docs/models/customer-awareness-cycle.md`
- **Golden Circle:** `../../docs/models/golden-circle.md`
---
*Strategic design is what makes WDS different. Every pixel has a purpose.*