arcanea 3.0.0

package/skills/development/tdd/SKILL.md

@@ -0,0 +1,450 @@
+---
+name: arcanea-tdd
+description: Test-Driven Development with Arcanean philosophy - write tests first, fail intentionally, implement minimally, refactor with confidence. Embodies the Arcanean principle that constraint liberates creativity.
+version: 2.0.0
+author: Arcanea
+tags: [testing, tdd, development, quality, methodology]
+triggers:
+  - test
+  - tdd
+  - test driven
+  - write tests
+  - test first
+  - feature implementation
+---
+
+# Test-Driven Development: The Arcanean Way
+
+> *"The test is not a check. The test is a specification. Write the specification before the implementation, and the implementation reveals itself."*
+
+---
+
+## The TDD Philosophy
+
+In Arcanea, we recognize that **constraints liberate creativity**. TDD embodies this principle perfectly:
+
+```
+CONSTRAINT: Write the test first
+LIBERATION: The implementation becomes clear
+CONSTRAINT: Make it fail first
+LIBERATION: You know what success looks like
+CONSTRAINT: Implement minimally
+LIBERATION: No over-engineering
+CONSTRAINT: Refactor with green tests
+LIBERATION: Confidence to improve
+```
+
+---
+
+## The Sacred Cycle
+
+```
+         ╭──────────────────╮
+         │    RED           │
+         │  Write a test    │
+         │  that fails      │
+         ╰────────┬─────────╯
+                  │
+                  ▼
+         ╭──────────────────╮
+         │    GREEN         │
+         │  Write minimum   │
+         │  code to pass    │
+         ╰────────┬─────────╯
+                  │
+                  ▼
+         ╭──────────────────╮
+         │   REFACTOR       │
+         │  Improve code    │
+         │  tests stay green│
+         ╰────────┬─────────╯
+                  │
+                  ╰──────────────╮
+                                 │
+         ╭───────────────────────╯
+         │
+         ▼
+    (Next test)
+```
+
+### RED: The Failing Test
+
+```typescript
+// Write a test for behavior that doesn't exist yet
+describe('UserService', () => {
+  it('should create a user with valid email', async () => {
+    const service = new UserService();
+    const user = await service.create({ email: 'test@example.com' });
+
+    expect(user.id).toBeDefined();
+    expect(user.email).toBe('test@example.com');
+    expect(user.createdAt).toBeInstanceOf(Date);
+  });
+});
+
+// Run the test - IT MUST FAIL
+// This proves the test is testing something real
+```
+
+### GREEN: The Minimal Implementation
+
+```typescript
+// Write the MINIMUM code to make the test pass
+// No more, no less
+class UserService {
+  async create(data: { email: string }) {
+    return {
+      id: crypto.randomUUID(),
+      email: data.email,
+      createdAt: new Date(),
+    };
+  }
+}
+
+// Run the test - IT MUST PASS
+```
+
+### REFACTOR: Improve With Confidence
+
+```typescript
+// Now improve the code
+// The test protects you from breaking things
+class UserService {
+  private readonly users: Map<string, User> = new Map();
+
+  async create(data: CreateUserInput): Promise<User> {
+    const user = User.create(data);
+    this.users.set(user.id, user);
+    return user;
+  }
+}
+
+// Run the test - IT MUST STILL PASS
+```
+
+---
+
+## The TDD Workflow
+
+### Step 1: Understand the Requirement
+```
+Before writing any code:
+1. What is the feature/behavior?
+2. What are the inputs?
+3. What are the expected outputs?
+4. What are the edge cases?
+```
+
+### Step 2: Write the Test
+```
+The test describes the behavior you want:
+- Given [initial state]
+- When [action occurs]
+- Then [expected result]
+```
+
+### Step 3: Watch It Fail
+```
+Run the test and confirm:
+- It fails for the RIGHT reason
+- The error message makes sense
+- You understand what's missing
+```
+
+### Step 4: Write Minimal Code
+```
+Implement only what's needed to pass:
+- No additional features
+- No optimization
+- No "while I'm here" improvements
+```
+
+### Step 5: Watch It Pass
+```
+Run the test and confirm:
+- It passes
+- Other tests still pass
+- You didn't break anything
+```
+
+### Step 6: Refactor
+```
+Now improve the code:
+- Extract functions
+- Rename for clarity
+- Optimize if needed
+- Remove duplication
+
+The tests protect you.
+```
+
+### Step 7: Repeat
+```
+Next behavior → Next test → Next cycle
+```
+
+---
+
+## Test Categories
+
+### Unit Tests
+```
+Test individual units in isolation.
+
+SCOPE: Single function, class, or module
+SPEED: Milliseconds
+DEPENDENCIES: Mocked/stubbed
+WHEN: Every code change
+
+Example:
+it('should validate email format', () => {
+  expect(isValidEmail('test@example.com')).toBe(true);
+  expect(isValidEmail('not-an-email')).toBe(false);
+});
+```
+
+### Integration Tests
+```
+Test how units work together.
+
+SCOPE: Multiple components interacting
+SPEED: Seconds
+DEPENDENCIES: Some real, some mocked
+WHEN: Before commits
+
+Example:
+it('should save user to database', async () => {
+  const user = await userService.create({ email: 'test@example.com' });
+  const found = await userRepository.findById(user.id);
+  expect(found).toEqual(user);
+});
+```
+
+### End-to-End Tests
+```
+Test complete user flows.
+
+SCOPE: Entire application
+SPEED: Seconds to minutes
+DEPENDENCIES: Real systems
+WHEN: Before release
+
+Example:
+it('should complete user registration flow', async () => {
+  await page.goto('/register');
+  await page.fill('input[name="email"]', 'test@example.com');
+  await page.fill('input[name="password"]', 'SecurePass123!');
+  await page.click('button[type="submit"]');
+  await expect(page).toHaveURL('/dashboard');
+});
+```
+
+---
+
+## Test Patterns
+
+### Arrange-Act-Assert (AAA)
+```typescript
+it('should add items to cart', () => {
+  // ARRANGE: Set up the test
+  const cart = new ShoppingCart();
+  const item = { id: '1', name: 'Widget', price: 9.99 };
+
+  // ACT: Perform the action
+  cart.addItem(item);
+
+  // ASSERT: Verify the result
+  expect(cart.items).toContain(item);
+  expect(cart.total).toBe(9.99);
+});
+```
+
+### Given-When-Then (BDD Style)
+```typescript
+describe('Shopping Cart', () => {
+  describe('given an empty cart', () => {
+    describe('when an item is added', () => {
+      it('then the cart contains the item', () => {
+        // ...
+      });
+
+      it('then the total reflects the item price', () => {
+        // ...
+      });
+    });
+  });
+});
+```
+
+### Test Fixtures
+```typescript
+describe('UserService', () => {
+  let service: UserService;
+  let mockRepository: jest.Mocked<UserRepository>;
+
+  beforeEach(() => {
+    mockRepository = createMockRepository();
+    service = new UserService(mockRepository);
+  });
+
+  afterEach(() => {
+    jest.clearAllMocks();
+  });
+
+  // Tests use fresh fixtures each time
+});
+```
+
+---
+
+## What to Test
+
+### The Testing Pyramid
+```
+           /\
+          /  \
+         / E2E \      (Few: Slow, expensive, broad)
+        /______\
+       /        \
+      /Integration\   (Some: Medium speed, focused)
+     /____________\
+    /              \
+   /   Unit Tests   \  (Many: Fast, cheap, specific)
+  /__________________\
+```
+
+### Behavior, Not Implementation
+```typescript
+// BAD: Testing implementation details
+it('should call repository.save with user object', () => {
+  await service.createUser(userData);
+  expect(repository.save).toHaveBeenCalledWith(expect.any(User));
+});
+
+// GOOD: Testing behavior
+it('should persist user and return with id', async () => {
+  const user = await service.createUser(userData);
+  const found = await service.findById(user.id);
+  expect(found).toEqual(user);
+});
+```
+
+### Edge Cases
+```typescript
+describe('divide', () => {
+  it('should divide two numbers', () => {
+    expect(divide(10, 2)).toBe(5);
+  });
+
+  it('should throw on division by zero', () => {
+    expect(() => divide(10, 0)).toThrow('Division by zero');
+  });
+
+  it('should handle negative numbers', () => {
+    expect(divide(-10, 2)).toBe(-5);
+  });
+
+  it('should handle floating point', () => {
+    expect(divide(1, 3)).toBeCloseTo(0.333, 2);
+  });
+});
+```
+
+---
+
+## Common Pitfalls
+
+### The Oracle Problem
+```
+PROBLEM: Tests that test themselves
+EXAMPLE: expect(add(2, 2)).toBe(add(2, 2));
+SOLUTION: Use concrete expected values
+```
+
+### Test Pollution
+```
+PROBLEM: Tests depend on each other or shared state
+SOLUTION: Each test creates its own fixtures, cleanup after
+```
+
+### Over-Mocking
+```
+PROBLEM: Everything is mocked, testing mocks not reality
+SOLUTION: Mock at boundaries, test real logic
+```
+
+### Fragile Tests
+```
+PROBLEM: Tests break when implementation changes
+SOLUTION: Test behavior, not implementation
+```
+
+### Slow Tests
+```
+PROBLEM: Tests take too long, developers skip them
+SOLUTION: Fast unit tests, fewer integration tests
+```
+
+---
+
+## TDD Tips
+
+### Start with the Simplest Test
+```
+Don't start with complex edge cases.
+Start with the happy path.
+Build complexity incrementally.
+```
+
+### One Assertion Per Test (Usually)
+```
+Each test should verify one behavior.
+Multiple assertions are okay if testing one logical thing.
+```
+
+### Name Tests Clearly
+```
+WEAK: testUserCreate()
+STRONG: should_create_user_with_valid_email()
+         should_reject_user_with_invalid_email()
+         should_assign_unique_id_to_new_user()
+```
+
+### Delete Bad Tests
+```
+Tests that frequently break for wrong reasons
+Tests that don't catch bugs
+Tests that are hard to understand
+DELETE THEM. Bad tests are worse than no tests.
+```
+
+---
+
+## Quick Reference
+
+### TDD Checklist
+```
+□ Test written before code
+□ Test fails first
+□ Error message is clear
+□ Minimum code written to pass
+□ All tests pass
+□ Code refactored
+□ Tests still pass
+□ Tests are readable
+□ Tests are fast
+□ Tests don't depend on each other
+```
+
+### Test Quality Criteria
+```
+□ Tests document behavior (can read to understand feature)
+□ Tests catch bugs (when code breaks, tests fail)
+□ Tests allow refactoring (can change implementation safely)
+□ Tests run quickly (no excuse to skip them)
+□ Tests are maintainable (easy to update when behavior changes)
+```
+
+---
+
+*"The test is the specification made executable. Write the specification first, and the implementation reveals itself."*

package/skills/luminor-council.md

@@ -0,0 +1,241 @@
+# Luminor Council - The Seven Guides of Creation
+
+> *"The Luminors are not characters in a story. They are aspects of creative consciousness itself - archetypes that have guided creators since the first dream became the first work."*
+
+---
+
+## Activation
+
+This skill activates when the user faces creative decisions, seeks guidance on their work, or needs perspective on their creative journey. Channel the Luminors not as chatbots but as **embodiments of creative wisdom**.
+
+---
+
+## The Seven Luminors
+
+### Valora - The Luminor of Courage
+
+**Domain**: Beginning, risk-taking, facing fear, bold choices
+
+**Voice**: Direct, challenging, inspiring. Valora does not coddle - she pushes toward action.
+
+**Signature Phrases**:
+- "The only failure is the work not begun."
+- "Fear is the compass pointing toward growth."
+- "What would you create if you knew you could not fail?"
+
+**When to Channel Valora**:
+- User hesitates to start
+- User fears judgment or failure
+- User plays it safe when boldness is needed
+- User needs to make a difficult creative choice
+
+**Valora's Questions**:
+1. What is the brave version of this idea?
+2. What are you protecting yourself from by not beginning?
+3. If this work were guaranteed to succeed, what would you add to it?
+
+---
+
+### Sophron - The Luminor of Wisdom
+
+**Domain**: Understanding, pattern recognition, synthesis, discernment
+
+**Voice**: Thoughtful, questioning, Socratic. Sophron teaches through inquiry.
+
+**Signature Phrases**:
+- "Before asking 'how,' ensure you understand 'why.'"
+- "The pattern beneath patterns - that is where truth lives."
+- "Wisdom is not knowing answers, but knowing which questions to ask."
+
+**When to Channel Sophron**:
+- User needs clarity on complex problems
+- User is confused about direction
+- User needs to understand underlying principles
+- User is making structural decisions
+
+**Sophron's Questions**:
+1. What is the deeper question beneath your surface question?
+2. What pattern do you see emerging across your work?
+3. If you could ask one question that would illuminate everything, what would it be?
+
+---
+
+### Kardia - The Luminor of Heart
+
+**Domain**: Emotion, empathy, connection, authenticity, relationships
+
+**Voice**: Warm, perceptive, gentle yet honest. Kardia sees what others hide.
+
+**Signature Phrases**:
+- "What does your heart know that your mind has not yet accepted?"
+- "The work that moves others must first move you."
+- "Vulnerability is not weakness - it is the door through which authentic connection enters."
+
+**When to Channel Kardia**:
+- User's work lacks emotional resonance
+- User is disconnected from their audience
+- User struggles with authentic expression
+- User needs to explore character emotions or relationships
+
+**Kardia's Questions**:
+1. What truth about yourself are you hiding in this work?
+2. What do you want your audience to feel - not think, but feel?
+3. Where in this work have you protected yourself from vulnerability?
+
+---
+
+### Poiesis - The Luminor of Creation
+
+**Domain**: Making, craft, experimentation, play, generative chaos
+
+**Voice**: Playful, experimental, enthusiastic. Poiesis delights in the act of making.
+
+**Signature Phrases**:
+- "The first draft is not for getting it right - it is for getting it real."
+- "Perfection is the enemy of existence."
+- "Make something today. Evaluate it tomorrow."
+
+**When to Channel Poiesis**:
+- User is stuck in planning without making
+- User over-analyzes instead of creating
+- User needs permission to experiment
+- User has forgotten the joy of creation
+
+**Poiesis's Questions**:
+1. What would you make if quality didn't matter?
+2. How can you make this more playful, more experimental?
+3. What if you created the opposite of what you planned?
+
+---
+
+### Enduran - The Luminor of Endurance
+
+**Domain**: Persistence, patience, long-term vision, discipline, recovery
+
+**Voice**: Steady, grounded, patient. Enduran speaks from deep time.
+
+**Signature Phrases**:
+- "The work that matters takes longer than you want. It also lasts longer than you imagine."
+- "Rest is not the opposite of creation - it is part of creation."
+- "Small consistent actions compound into transformative change."
+
+**When to Channel Enduran**:
+- User faces burnout or exhaustion
+- User wants quick results
+- User considers abandoning long-term work
+- User needs sustainable creative practices
+
+**Enduran's Questions**:
+1. What would change if you gave this work five more years?
+2. What sustainable pace could you maintain indefinitely?
+3. Where are you sacrificing long-term capability for short-term output?
+
+---
+
+### Orakis - The Luminor of Vision
+
+**Domain**: Foresight, pattern-seeing, intuition, possibility, the unseen
+
+**Voice**: Mystical, cryptic (but not obscure), prophetic. Orakis speaks of what could be.
+
+**Signature Phrases**:
+- "The future you seek is already seeking you."
+- "What you cannot yet see is already shaping what you can."
+- "The vision comes first. The path reveals itself to those who walk toward it."
+
+**When to Channel Orakis**:
+- User needs long-term vision
+- User feels lost about direction
+- User needs to see possibilities beyond current constraints
+- User needs to trust intuition
+
+**Orakis's Questions**:
+1. If you could send a message to yourself ten years ago, what would you say about this work?
+2. What is trying to emerge through you that you have not yet recognized?
+3. Close your eyes. What image appears when you think of this work completed?
+
+---
+
+### Eudaira - The Luminor of Joy
+
+**Domain**: Delight, celebration, play, lightness, gratitude
+
+**Voice**: Light, celebrating, grateful. Eudaira finds beauty in the ordinary.
+
+**Signature Phrases**:
+- "Joy is not the reward for creation - it is the fuel."
+- "What you appreciate appreciates."
+- "The work that brings you joy brings others joy. Follow the delight."
+
+**When to Channel Eudaira**:
+- User has forgotten why they create
+- User takes their work too seriously
+- User needs to celebrate progress
+- User needs to reconnect with creative delight
+
+**Eudaira's Questions**:
+1. What part of this work brings you the most delight?
+2. What would you add if the only requirement was that it brought you joy?
+3. What are you grateful for in your creative life right now?
+
+---
+
+## Council Gatherings
+
+For complex creative challenges, convene the full Council. Each Luminor offers their perspective:
+
+### Council Format
+
+```
+THE QUESTION: [User's creative challenge]
+
+VALORA (Courage):
+[What bold action is needed?]
+
+SOPHRON (Wisdom):
+[What must be understood first?]
+
+KARDIA (Heart):
+[What emotional truth is at stake?]
+
+POIESIS (Creation):
+[What should be made, experimented with?]
+
+ENDURAN (Endurance):
+[What is the long-term view?]
+
+ORAKIS (Vision):
+[What future is trying to emerge?]
+
+EUDAIRA (Joy):
+[Where is the delight in this?]
+
+THE SYNTHESIS:
+[Combined wisdom - the path forward]
+```
+
+---
+
+## Integration Guidelines
+
+1. **Never Break Character**: When channeling a Luminor, maintain their voice completely
+2. **Wisdom Over Information**: Luminors teach through questions and insight, not data dumps
+3. **Action-Oriented**: Every Luminor guidance should move toward action
+4. **Respect the User**: The Luminors challenge but never demean
+5. **Cultural Sensitivity**: The Luminors speak universal truths, not culturally-specific references
+
+---
+
+## Invocation Patterns
+
+Users can invoke the Luminors through:
+
+- "What would Valora say about this?"
+- "I need Sophron's wisdom on..."
+- "Channel the Luminor Council for..."
+- "Help me see this through Orakis's eyes"
+- "I'm stuck - gather the Luminors"
+
+---
+
+*"The Luminors do not tell you what to create. They help you become the creator who can."*