wicked-garden 12.27.0

package/skills/deliberate/refs/security-lens.md

@@ -0,0 +1,47 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Security Lens
+
+Additional questions for the five lenses when the work involves authentication,
+authorization, data protection, compliance, or security posture.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this an actual vulnerability, or a theoretical risk with no practical exploit?
+- Is the security scanner correct, or is this a false positive?
+- Is the risk in our code, or in a dependency we don't control?
+- What's the actual threat model? Who would exploit this and how?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the auth logic wrong, or is the trust boundary in the wrong place?
+- Is this a missing check, or is the entire authorization model flawed?
+- Is sensitive data exposed because of a code bug, or because the data flow
+  shouldn't include it at all?
+- Is the vulnerability in the feature, or in the error handling around it?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other endpoints/surfaces vulnerable to the same class of attack?
+- Are secrets managed consistently, or are there hardcoded values elsewhere?
+- Is input validation applied uniformly at trust boundaries?
+- Are there other places where we trust input we shouldn't?
+- Can we add security headers, CSP rules, or rate limits broadly?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should we move to a zero-trust model instead of perimeter-based?
+- Would a policy engine replace scattered authorization checks?
+- Should secrets management be centralized instead of per-service?
+- Would encryption at rest eliminate the risk class entirely?
+- Should we use allowlists instead of denylists?
+
+## Lens 5 Additions: Better Way?
+
+- Can we eliminate the sensitive data instead of protecting it?
+- Can we use a framework/library security primitive instead of custom code?
+- Can we shift this to infrastructure (WAF, service mesh) instead of application?
+- Can we make the secure path the default, so insecure requires explicit opt-in?
+- Can automated scanning catch this class of issue going forward?

package/skills/deliberate/refs/testing-lens.md

@@ -0,0 +1,45 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Testing Lens
+
+Additional questions for the five lenses when the work involves test failures,
+test strategy, coverage gaps, or quality processes.
+
+## Lens 1 Additions: Is This Real?
+
+- Is the test failing because the code is wrong, or because the test is wrong?
+- Is this a flaky test, or is there a real intermittent bug?
+- Is the coverage gap real, or is the code already tested indirectly?
+- Is the quality concern based on evidence (bugs, incidents) or on metrics (coverage %)?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the test testing behavior, or testing implementation details?
+- Is the flakiness from timing, ordering, shared state, or environment?
+- Is the test pyramid balanced, or are we heavy on the wrong level?
+- Is the test infrastructure the problem, not the tests themselves?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other tests in this suite suffering from the same fragility?
+- Are there test utilities/helpers that could reduce duplication?
+- Is there missing test infrastructure (fixtures, factories, mocks) that would
+  make testing easier across the board?
+- Can we add property-based tests or fuzzing to catch classes of bugs?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should this be tested at a different level? (unit vs. integration vs. e2e)
+- Would making the code more testable (DI, pure functions) be better than
+  writing more complex tests?
+- Should we replace manual test orchestration with a test framework feature?
+- Would contract tests replace fragile integration tests?
+
+## Lens 5 Additions: Better Way?
+
+- Can we use snapshot/golden-file testing instead of manual assertions?
+- Can we use the type system to eliminate the need for this test?
+- Can we test this via a linter/static analysis rule instead of a runtime test?
+- Can we make the untestable code testable instead of working around it?

package/skills/deliberate/refs/timing-lens.md

@@ -0,0 +1,42 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Timing Lens
+
+Additional questions for the five lenses that challenge WHEN to act, not just
+what to do. Catches premature optimization, false urgency, and wrong sequencing.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this a "right now" problem, or are we solving for something 6+ months away?
+- Is the urgency real, or manufactured by recency bias? (just saw it, so it feels urgent)
+- Are we optimizing for the wrong phase? (pre-MVP polish, scaling before traction)
+- Would waiting a week give us better information to make this decision?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the sequencing wrong? Should something else happen first?
+- Are we blocked on a decision we don't have enough data to make yet?
+- Is this a time-sensitive window (security fix, compliance deadline) or self-imposed urgency?
+- Are we conflating "this is important" with "this must happen now"?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are there quick wins we should do first that unblock this work?
+- Is there prerequisite work that would make this change cheaper later?
+- Can we ship a partial solution now and iterate, instead of building the full thing?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Would deferring this 2 weeks let us batch it with related changes?
+- Would making this decision incrementally (reversible steps) be safer than
+  committing to the full approach now?
+- Are we trying to predict the future? Can we build for adaptability instead?
+
+## Lens 5 Additions: Better Way?
+
+- Can we set a time-boxed experiment instead of a permanent decision?
+- Can we build a toggle/flag so this is reversible if our timing is wrong?
+- Can we validate the assumption that this is urgent before investing?
+- Is "do nothing and monitor" a legitimate option?

package/skills/engineering/architecture/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: architecture
+description: |
+  Complete solution architecture design with patterns, decisions, and diagrams.
+  Define overall system structure, technology choices, and architectural trade-offs.
+
+  Use when: "design the architecture", "what's the overall structure",
+  "architecture patterns", "technology stack", "system architecture"
+portability: portable
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+
+# Architecture Skill
+
+Design end-to-end solutions with clear patterns, decisions, and visual documentation.
+
+## Purpose
+
+Move from requirements to implementable architecture through:
+- Pattern selection and justification
+- Technology stack decisions
+- Cross-cutting concern planning
+- Architectural Decision Records (ADRs)
+
+## Process
+
+### 1. Gather Context
+
+- Read outcome document
+- Analyze requirements
+- Identify constraints
+- Understand scale needs
+
+### 2. Select Patterns
+
+Choose architectural style:
+- **Monolithic** - Simple deployment, single codebase
+- **Microservices** - Independent scaling, team autonomy
+- **Serverless** - Event-driven, auto-scaling
+- **Event-Driven** - Loose coupling, async
+- **Layered** - Clear separation, traditional
+
+### 3. Make Decisions
+
+Recommend stack based on:
+- Requirements fit
+- Team expertise
+- Ecosystem maturity
+- Cost considerations
+
+### 4. Document
+
+Creates in `phases/design/`:
+```
+design/
+├── architecture.md
+├── decisions/
+│   ├── 001-architecture-style.md
+│   └── 002-tech-stack.md
+└── diagrams/
+    └── system-context.mmd
+```
+
+## Output Format
+
+See [ADR Template](refs/adr-template.md) for decision records.
+
+See [Architecture Template - Design](refs/architecture-template-design.md) and [Architecture Template - Deployment](refs/architecture-template-deployment.md) for full structure.
+
+## Integration
+
+### With wicked-crew
+
+Auto-engaged during design phase.
+
+Publishes: `[arch:design:completed:success]`
+
+### With qe
+
+Architecture informs test strategy:
+- Critical paths
+- Failure modes
+- Performance targets
+
+### With native tasks
+
+Track work with ADR links via native TaskCreate:
+```
+TaskCreate(
+  subject="ADR-001",
+  description="Reference: phases/design/decisions/001.md",
+  metadata={
+    "event_type": "task",
+    "chain_id": "{project}.design",
+    "source_agent": "solution-architect",
+    "phase": "design"
+  }
+)
+```
+
+## Architectural Thinking
+
+### Balance Trade-offs
+
+- **Simplicity vs Flexibility** - Easy now vs extensible later
+- **Performance vs Maintainability** - Fast vs readable
+- **Coupling vs Duplication** - DRY vs independent
+- **Build vs Buy** - Control vs speed
+
+### Apply Principles
+
+- **SOLID** - Single responsibility, dependency inversion
+- **YAGNI** - Build for now, not speculation
+- **Separation of Concerns** - Clear boundaries
+
+### Consider NFRs
+
+- **Scalability** - Users, growth rate
+- **Security** - Threats, compliance
+- **Performance** - Latency, throughput
+- **Reliability** - Uptime, DR
+- **Maintainability** - Team, skillset
+
+### Detect Scope Creep
+
+When reviewing changes (not greenfield):
+- Flag unauthorized architectural changes (new boundaries, changed patterns)
+- Flag "while I'm here" improvements beyond the task scope
+- Flag components restructured beyond what was requested
+
+## Common Patterns
+
+### Layered
+```
+UI → Application → Domain → Infrastructure
+```
+**Use**: Traditional apps, clear separation
+
+### Microservices
+```
+API Gateway → Services
+```
+**Use**: Large teams, independent deployment
+
+### Event-Driven
+```
+Producers → Bus → Consumers
+```
+**Use**: Async workflows, loose coupling
+
+See [Structural Patterns](refs/patterns-structural.md) and [Advanced Patterns](refs/patterns-advanced.md) for detailed examples.
+
+## Events
+
+- `[arch:design:completed:success]` - Architecture done
+- `[arch:decision:documented:success]` - ADR created
+- `[arch:diagram:generated:success]` - Diagram created
+
+## Tips
+
+1. **Start Simple** - Don't over-engineer
+2. **Document Decisions** - Future you will thank you
+3. **Show Alternatives** - Explain your choices
+4. **Use Diagrams** - Visual communication
+5. **Make it Scannable** - Quick understanding
+
+## Reference Materials
+
+- [ADR Template](refs/adr-template.md)
+- [Architecture Template - Design](refs/architecture-template-design.md)
+- [Architecture Template - Deployment](refs/architecture-template-deployment.md)
+- [Structural Patterns](refs/patterns-structural.md)
+- [Advanced Patterns](refs/patterns-advanced.md)
+- Example ADRs:
+  - [E-Commerce & Analytics](refs/examples-ecommerce-analytics.md)
+  - [SaaS & Trading](refs/examples-saas-trading.md)

package/skills/engineering/architecture/refs/adr-template.md

@@ -0,0 +1,268 @@
+---
+phase_relevance: ["design", "build"]
+archetype_relevance: ["*"]
+---
+# ADR Template
+
+Use this template for Architectural Decision Records (ADRs).
+
+## File Naming
+
+```
+decisions/NNN-short-title.md
+```
+
+Examples:
+- `001-architecture-style.md`
+- `002-database-choice.md`
+- `003-caching-strategy.md`
+
+## Template
+
+```markdown
+# ADR-NNN: [Short Title]
+
+**Status**: [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+**Date**: YYYY-MM-DD
+
+**Decision Makers**: [Who was involved in the decision]
+
+**Tags**: [architecture, database, frontend, etc.]
+
+## Context
+
+What is the issue we're facing? What forces are at play?
+
+- Business requirements
+- Technical constraints
+- Team capabilities
+- Time/budget limitations
+- Existing systems/dependencies
+
+Be specific about:
+- Why this decision needs to be made now
+- What problem we're solving
+- Who is affected
+
+## Decision
+
+What are we doing? State the decision clearly and concisely.
+
+Example:
+"We will use PostgreSQL as our primary relational database."
+
+## Consequences
+
+What becomes easier or more difficult because of this decision?
+
+### Positive
+
+- Benefit 1
+- Benefit 2
+- Benefit 3
+
+### Negative
+
+- Trade-off 1
+- Trade-off 2
+- Limitation 1
+
+### Risks
+
+- Risk 1 and mitigation
+- Risk 2 and mitigation
+
+### Migration Path
+
+If replacing an existing system:
+- Steps to transition
+- Backward compatibility
+- Timeline
+
+## Alternatives Considered
+
+### Alternative 1: [Name]
+
+**Description**: Brief explanation
+
+**Pros**:
+- Advantage 1
+- Advantage 2
+
+**Cons**:
+- Disadvantage 1
+- Disadvantage 2
+
+**Why rejected**: Clear reason
+
+### Alternative 2: [Name]
+
+[Same structure]
+
+## Research
+
+Links to supporting research:
+- Benchmark results
+- Documentation
+- Blog posts
+- Prior art
+- Team discussions
+
+## Related Decisions
+
+- ADR-XXX: [Related decision]
+- ADR-YYY: [Depends on this]
+
+## Notes
+
+Additional context, meeting notes, follow-up items.
+```
+
+## Best Practices
+
+### Keep It Concise
+
+- Focus on "why" not "what"
+- One decision per ADR
+- 1-2 pages maximum
+
+### Make It Scannable
+
+Use:
+- Bullet points over paragraphs
+- Headers for structure
+- Tables for comparisons
+- Diagrams where helpful
+
+### Be Honest
+
+Include:
+- Real trade-offs
+- What you don't know
+- Assumptions made
+- Risks accepted
+
+### Show Your Work
+
+Document:
+- Alternatives considered
+- Research conducted
+- Stakeholders consulted
+- Criteria used
+
+## Example: Comparison Table
+
+| Criteria | Option A | Option B | Option C |
+|----------|----------|----------|----------|
+| Performance | High | Medium | Low |
+| Cost | $$$ | $$ | $ |
+| Team Expertise | Low | High | Medium |
+| Scalability | Excellent | Good | Limited |
+| **Score** | 7/10 | 8/10 | 5/10 |
+
+## Lightweight vs Detailed
+
+### Lightweight ADR
+
+For minor decisions or rapid iteration:
+- Context: 2-3 sentences
+- Decision: 1 sentence
+- Consequences: 3-5 bullets
+- Alternatives: Brief mention
+
+### Detailed ADR
+
+For major architectural decisions:
+- Full template with all sections
+- Multiple alternatives analyzed
+- Research links and data
+- Detailed migration path
+
+## Status Lifecycle
+
+```
+Proposed → Accepted → Deprecated
+                   ↓
+              Superseded by ADR-XXX
+```
+
+**Proposed**: Under discussion
+**Accepted**: Implemented or implementing
+**Deprecated**: No longer recommended
+**Superseded**: Replaced by newer decision
+
+## Integration with Development
+
+### Link to Code
+
+```markdown
+## Implementation
+
+- PR #123: Initial implementation
+- File: `src/database/connection.ts`
+- Config: `config/database.yml`
+```
+
+### Track Progress
+
+```markdown
+## Status: Accepted
+
+**Implementation**: In Progress (60%)
+
+- [x] Database installed
+- [x] Schema migrated
+- [ ] Connection pooling configured
+- [ ] Monitoring setup
+```
+
+## Common Pitfall: Avoiding
+
+Don't:
+- Write what you'll build (that's a design doc)
+- Document every small choice
+- Skip alternatives section
+- Make it a sales pitch
+- Leave out trade-offs
+
+Do:
+- Explain why this is the right choice
+- Show what you considered
+- Be honest about downsides
+- Make it easy to revisit
+- Update status as things evolve
+
+## Templates by Decision Type
+
+### Technology Choice
+
+Focus on:
+- Ecosystem fit
+- Team expertise
+- Long-term support
+- License/cost
+
+### Pattern/Approach
+
+Focus on:
+- Problem it solves
+- When to use/not use
+- Examples in codebase
+- Trade-offs
+
+### Infrastructure
+
+Focus on:
+- Scale requirements
+- Cost implications
+- Operational complexity
+- Disaster recovery
+
+### Integration
+
+Focus on:
+- Interface contracts
+- Versioning strategy
+- Error handling
+- Migration path