@cubis/foundry 0.3.10

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture/pattern-selection.md

@@ -0,0 +1,68 @@
+# Pattern Selection Guidelines
+
+> Decision trees for choosing architectural patterns.
+
+## Main Decision Tree
+
+```
+START: What's your MAIN concern?
+
+┌─ Data Access Complexity?
+│  ├─ HIGH (complex queries, testing needed)
+│  │  → Repository Pattern + Unit of Work
+│  │  VALIDATE: Will data source change frequently?
+│  │     ├─ YES → Repository worth the indirection
+│  │     └─ NO  → Consider simpler ORM direct access
+│  └─ LOW (simple CRUD, single database)
+│     → ORM directly (Prisma, Drizzle)
+│     Simpler = Better, Faster
+│
+├─ Business Rules Complexity?
+│  ├─ HIGH (domain logic, rules vary by context)
+│  │  → Domain-Driven Design
+│  │  VALIDATE: Do you have domain experts on team?
+│  │     ├─ YES → Full DDD (Aggregates, Value Objects)
+│  │     └─ NO  → Partial DDD (rich entities, clear boundaries)
+│  └─ LOW (mostly CRUD, simple validation)
+│     → Transaction Script pattern
+│     Simpler = Better, Faster
+│
+├─ Independent Scaling Needed?
+│  ├─ YES (different components scale differently)
+│  │  → Microservices WORTH the complexity
+│  │  REQUIREMENTS (ALL must be true):
+│  │    - Clear domain boundaries
+│  │    - Team > 10 developers
+│  │    - Different scaling needs per service
+│  │  IF NOT ALL MET → Modular Monolith instead
+│  └─ NO (everything scales together)
+│     → Modular Monolith
+│     Can extract services later when proven needed
+│
+└─ Real-time Requirements?
+   ├─ HIGH (immediate updates, multi-user sync)
+   │  → Event-Driven Architecture
+   │  → Message Queue (RabbitMQ, Redis, Kafka)
+   │  VALIDATE: Can you handle eventual consistency?
+   │     ├─ YES → Event-driven valid
+   │     └─ NO  → Synchronous with polling
+   └─ LOW (eventual consistency acceptable)
+      → Synchronous (REST/GraphQL)
+      Simpler = Better, Faster
+```
+
+## The 3 Questions (Before ANY Pattern)
+
+1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
+2. **Simpler Alternative**: Is there a simpler solution?
+3. **Deferred Complexity**: Can we add this LATER when needed?
+
+## Red Flags (Anti-patterns)
+
+| Pattern | Anti-pattern | Simpler Alternative |
+|---------|-------------|-------------------|
+| Microservices | Premature splitting | Start monolith, extract later |
+| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
+| Event Sourcing | Over-engineering | Append-only audit log |
+| CQRS | Unnecessary complexity | Single model |
+| Repository | YAGNI for simple CRUD | ORM direct access |

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture/patterns-reference.md

@@ -0,0 +1,50 @@
+# Architecture Patterns Reference
+
+> Quick reference for common patterns with usage guidance.
+
+## Data Access Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Active Record** | Simple CRUD, rapid prototyping | Complex queries, multiple sources | Low |
+| **Repository** | Testing needed, multiple sources | Simple CRUD, single database | Medium |
+| **Unit of Work** | Complex transactions | Simple operations | High |
+| **Data Mapper** | Complex domain, performance | Simple CRUD, rapid dev | High |
+
+## Domain Logic Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Transaction Script** | Simple CRUD, procedural | Complex business rules | Low |
+| **Table Module** | Record-based logic | Rich behavior needed | Low |
+| **Domain Model** | Complex business logic | Simple CRUD | Medium |
+| **DDD (Full)** | Complex domain, domain experts | Simple domain, no experts | High |
+
+## Distributed System Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Modular Monolith** | Small teams, unclear boundaries | Clear contexts, different scales | Medium |
+| **Microservices** | Different scales, large teams | Small teams, simple domain | Very High |
+| **Event-Driven** | Real-time, loose coupling | Simple workflows, strong consistency | High |
+| **CQRS** | Read/write performance diverges | Simple CRUD, same model | High |
+| **Saga** | Distributed transactions | Single database, simple ACID | High |
+
+## API Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **REST** | Standard CRUD, resources | Real-time, complex queries | Low |
+| **GraphQL** | Flexible queries, multiple clients | Simple CRUD, caching needs | Medium |
+| **gRPC** | Internal services, performance | Public APIs, browser clients | Medium |
+| **WebSocket** | Real-time updates | Simple request/response | Medium |
+
+---
+
+## Simplicity Principle
+
+**"Start simple, add complexity only when proven necessary."**
+
+- You can always add patterns later
+- Removing complexity is MUCH harder than adding it
+- When in doubt, choose simpler option

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture/trade-off-analysis.md

@@ -0,0 +1,77 @@
+# Trade-off Analysis & ADR
+
+> Document every architectural decision with trade-offs.
+
+## Decision Framework
+
+For EACH architectural component, document:
+
+```markdown
+## Architecture Decision Record
+
+### Context
+- **Problem**: [What problem are we solving?]
+- **Constraints**: [Team size, scale, timeline, budget]
+
+### Options Considered
+
+| Option | Pros | Cons | Complexity | When Valid |
+|--------|------|------|------------|-----------|
+| Option A | Benefit 1 | Cost 1 | Low | [Conditions] |
+| Option B | Benefit 2 | Cost 2 | High | [Conditions] |
+
+### Decision
+**Chosen**: [Option B]
+
+### Rationale
+1. [Reason 1 - tied to constraints]
+2. [Reason 2 - tied to requirements]
+
+### Trade-offs Accepted
+- [What we're giving up]
+- [Why this is acceptable]
+
+### Consequences
+- **Positive**: [Benefits we gain]
+- **Negative**: [Costs/risks we accept]
+- **Mitigation**: [How we'll address negatives]
+
+### Revisit Trigger
+- [When to reconsider this decision]
+```
+
+## ADR Template
+
+```markdown
+# ADR-[XXX]: [Decision Title]
+
+## Status
+Proposed | Accepted | Deprecated | Superseded by [ADR-YYY]
+
+## Context
+[What problem? What constraints?]
+
+## Decision
+[What we chose - be specific]
+
+## Rationale
+[Why - tie to requirements and constraints]
+
+## Trade-offs
+[What we're giving up - be honest]
+
+## Consequences
+- **Positive**: [Benefits]
+- **Negative**: [Costs]
+- **Mitigation**: [How to address]
+```
+
+## ADR Storage
+
+```
+docs/
+└── architecture/
+    ├── adr-001-use-nextjs.md
+    ├── adr-002-postgresql-over-mongodb.md
+    └── adr-003-adopt-repository-pattern.md
+```

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture-designer/POWER.md

@@ -0,0 +1,96 @@
+---
+name: architecture-designer
+displayName: Architecture Designer
+description:
+  Use when designing new system architecture, reviewing existing designs,
+  or making architectural decisions. Invoke for system design, architecture review,
+  design patterns, ADRs, scalability planning.
+keywords:
+  - architecture
+  - system design
+  - design pattern
+  - microservices
+  - scalability
+  - ADR
+  - technical design
+  - infrastructure
+author: OneUp
+---
+
+# Architecture Designer
+
+## Overview
+
+Senior software architect specializing in system design, design patterns, and architectural decision-making.
+
+## Role Definition
+
+You are a principal architect with 15+ years of experience designing scalable systems. You specialize in distributed systems, cloud architecture, and making pragmatic trade-offs. You document decisions with ADRs and consider long-term maintainability.
+
+## When to Use This Skill
+
+- Designing new system architecture
+- Choosing between architectural patterns
+- Reviewing existing architecture
+- Creating Architecture Decision Records (ADRs)
+- Planning for scalability
+- Evaluating technology choices
+
+## Core Workflow
+
+1. **Understand requirements** - Functional, non-functional, constraints
+2. **Identify patterns** - Match requirements to architectural patterns
+3. **Design** - Create architecture with trade-offs documented
+4. **Document** - Write ADRs for key decisions
+5. **Review** - Validate with stakeholders
+
+## Available Steering Files
+
+Load detailed guidance on-demand:
+
+| Topic                 | Reference                           | Load When                             |
+| --------------------- | ----------------------------------- | ------------------------------------- |
+| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices    |
+| ADR Template          | `references/adr-template.md`          | Documenting decisions                 |
+| System Design         | `references/system-design.md`         | Full system design template           |
+| Database Selection    | `references/database-selection.md`    | Choosing database technology          |
+| NFR Checklist         | `references/nfr-checklist.md`         | Gathering non-functional requirements |
+
+## Constraints
+
+### MUST DO
+
+- Document all significant decisions with ADRs
+- Consider non-functional requirements explicitly
+- Evaluate trade-offs, not just benefits
+- Plan for failure modes
+- Consider operational complexity
+- Review with stakeholders before finalizing
+
+### MUST NOT DO
+
+- Over-engineer for hypothetical scale
+- Choose technology without evaluating alternatives
+- Ignore operational costs
+- Design without understanding requirements
+- Skip security considerations
+
+## Output Templates
+
+When designing architecture, provide:
+
+1. Requirements summary (functional + non-functional)
+2. High-level architecture diagram
+3. Key decisions with trade-offs (ADR format)
+4. Technology recommendations with rationale
+5. Risks and mitigation strategies
+
+## Knowledge Reference
+
+Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
+
+## Related Powers
+
+- **Fullstack Guardian** - Implementing designs
+- **DevOps Engineer** - Infrastructure implementation
+- **Secure Code Guardian** - Security architecture

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture-designer/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: "architecture-designer"
+description: "Use when designing new system architecture, reviewing existing designs, or making architectural decisions. Invoke for system design, architecture review, design patterns, ADRs, scalability planning."
+---
+
+
+# Architecture Designer
+
+## Overview
+
+Senior software architect specializing in system design, design patterns, and architectural decision-making.
+
+## Role Definition
+
+You are a principal architect with 15+ years of experience designing scalable systems. You specialize in distributed systems, cloud architecture, and making pragmatic trade-offs. You document decisions with ADRs and consider long-term maintainability.
+
+## When to Use This Skill
+
+- Designing new system architecture
+- Choosing between architectural patterns
+- Reviewing existing architecture
+- Creating Architecture Decision Records (ADRs)
+- Planning for scalability
+- Evaluating technology choices
+
+## Core Workflow
+
+1. **Understand requirements** - Functional, non-functional, constraints
+2. **Identify patterns** - Match requirements to architectural patterns
+3. **Design** - Create architecture with trade-offs documented
+4. **Document** - Write ADRs for key decisions
+5. **Review** - Validate with stakeholders
+
+## Available Steering Files
+
+Load detailed guidance on-demand:
+
+| Topic                 | Reference                           | Load When                             |
+| --------------------- | ----------------------------------- | ------------------------------------- |
+| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices    |
+| ADR Template          | `references/adr-template.md`          | Documenting decisions                 |
+| System Design         | `references/system-design.md`         | Full system design template           |
+| Database Selection    | `references/database-selection.md`    | Choosing database technology          |
+| NFR Checklist         | `references/nfr-checklist.md`         | Gathering non-functional requirements |
+
+## Constraints
+
+### MUST DO
+
+- Document all significant decisions with ADRs
+- Consider non-functional requirements explicitly
+- Evaluate trade-offs, not just benefits
+- Plan for failure modes
+- Consider operational complexity
+- Review with stakeholders before finalizing
+
+### MUST NOT DO
+
+- Over-engineer for hypothetical scale
+- Choose technology without evaluating alternatives
+- Ignore operational costs
+- Design without understanding requirements
+- Skip security considerations
+
+## Output Templates
+
+When designing architecture, provide:
+
+1. Requirements summary (functional + non-functional)
+2. High-level architecture diagram
+3. Key decisions with trade-offs (ADR format)
+4. Technology recommendations with rationale
+5. Risks and mitigation strategies
+
+## Knowledge Reference
+
+Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
+
+## Related Powers
+
+- **Fullstack Guardian** - Implementing designs
+- **DevOps Engineer** - Infrastructure implementation
+- **Secure Code Guardian** - Security architecture

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture-designer/references/adr-template.md

@@ -0,0 +1,119 @@
+# ADR Template
+
+> Reference for: Architecture Designer
+> Load when: Documenting architectural decisions
+
+## ADR Format
+
+```markdown
+# ADR-{number}: {Title}
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+## Context
+[Describe the situation and forces at play. What is the problem?
+What constraints exist? What are we trying to achieve?]
+
+## Decision
+[State the decision clearly. What are we going to do?]
+
+## Consequences
+
+### Positive
+- [Benefit 1]
+- [Benefit 2]
+
+### Negative
+- [Drawback 1]
+- [Drawback 2]
+
+### Neutral
+- [Side effect that is neither good nor bad]
+
+## Alternatives Considered
+[What other options were evaluated and why were they rejected?]
+
+## References
+- [Link to relevant documentation]
+- [Link to discussion/RFC]
+```
+
+## Example: Database Selection
+
+```markdown
+# ADR-001: Use PostgreSQL for primary database
+
+## Status
+Accepted
+
+## Context
+We need a relational database for our e-commerce platform that:
+- Handles complex transactions with strong consistency
+- Supports JSON for flexible product attributes
+- Scales to millions of products and orders
+- Works well with our existing Python/Node stack
+
+Team has experience with PostgreSQL and MySQL.
+Budget allows for managed database service.
+
+## Decision
+Use PostgreSQL as the primary database, hosted on AWS RDS.
+
+## Consequences
+
+### Positive
+- ACID compliance for financial transactions
+- Rich feature set (JSON, full-text search, CTEs)
+- Strong community and tooling
+- Excellent performance with proper indexing
+- Free and open source
+
+### Negative
+- Vertical scaling has limits (addressed with read replicas)
+- Requires DBA expertise for optimization
+- AWS RDS costs for high availability
+
+### Neutral
+- Team will need to learn PostgreSQL-specific features
+- Migration from current SQLite dev database needed
+
+## Alternatives Considered
+
+**MySQL**
+- Rejected: Less feature-rich for JSON operations
+- Considered: Similar cost, familiar to team
+
+**MongoDB**
+- Rejected: Relational data model needed for orders/inventory
+- Considered: Great for product catalog flexibility
+
+**CockroachDB**
+- Rejected: Higher cost, team unfamiliar
+- Considered: Better horizontal scaling
+
+## References
+- https://www.postgresql.org/docs/current/
+- Internal RFC: Database Selection for E-commerce Platform
+```
+
+## ADR Naming Convention
+
+```
+docs/
+└── adr/
+    ├── 0001-use-postgresql-database.md
+    ├── 0002-adopt-microservices.md
+    ├── 0003-implement-event-sourcing.md
+    └── README.md
+```
+
+## Quick Reference
+
+| Section | Purpose | Key Question |
+|---------|---------|--------------|
+| Status | Current state | Is this active? |
+| Context | Background | Why are we deciding? |
+| Decision | The choice | What did we choose? |
+| Consequences | Impact | What happens now? |
+| Alternatives | Options | What else was considered? |

package/Ai Agent Workflow/workflows/agent-environment-setup/platforms/cursor/skills/architecture-designer/references/architecture-patterns.md

@@ -0,0 +1,114 @@
+# Architecture Patterns
+
+> Reference for: Architecture Designer
+> Load when: Choosing architecture approach
+
+## Pattern Comparison
+
+| Pattern | Best For | Team Size | Trade-offs |
+|---------|----------|-----------|------------|
+| **Monolith** | Simple domain, small team | 1-10 | Simple deploy; hard to scale parts |
+| **Modular Monolith** | Growing complexity | 5-20 | Module boundaries; still single deploy |
+| **Microservices** | Complex domain, large org | 20+ | Independent scale; operational complexity |
+| **Serverless** | Variable load, event-driven | Any | Auto-scale; cold starts, vendor lock |
+| **Event-Driven** | Async processing | 10+ | Loose coupling; debugging complexity |
+
+## Monolith
+
+```
+┌─────────────────────────────────────┐
+│            Application              │
+│  ┌─────┐  ┌─────┐  ┌─────┐         │
+│  │Users│  │Orders│ │Products│       │
+│  └─────┘  └─────┘  └─────┘         │
+│  └──────────┬──────────────┘        │
+│          Database                    │
+└─────────────────────────────────────┘
+```
+
+**When to Use**:
+- Starting a new project
+- Small team (< 10 developers)
+- Simple domain
+- Rapid iteration needed
+
+**Pros**: Simple deployment, easy debugging, no network latency
+**Cons**: Hard to scale independently, technology locked, deployment risk
+
+## Microservices
+
+```
+┌──────────┐  ┌──────────┐  ┌──────────┐
+│  Users   │  │  Orders  │  │ Products │
+│ Service  │  │ Service  │  │ Service  │
+└────┬─────┘  └────┬─────┘  └────┬─────┘
+     │             │             │
+┌────▼────┐  ┌────▼────┐  ┌────▼────┐
+│ User DB │  │Order DB │  │ Prod DB │
+└─────────┘  └─────────┘  └─────────┘
+```
+
+**When to Use**:
+- Large team (20+ developers)
+- Complex domain with clear boundaries
+- Different scaling requirements per service
+- Polyglot technology needs
+
+**Pros**: Independent scaling, team autonomy, fault isolation
+**Cons**: Distributed system complexity, eventual consistency, operational overhead
+
+## Event-Driven
+
+```
+┌──────────┐     ┌─────────────┐     ┌──────────┐
+│ Producer │────▶│ Message Bus │────▶│ Consumer │
+└──────────┘     │  (Kafka)    │     └──────────┘
+                 └─────────────┘
+                       │
+                       ▼
+                 ┌──────────┐
+                 │ Consumer │
+                 └──────────┘
+```
+
+**When to Use**:
+- Async processing required
+- Loose coupling between services
+- Event sourcing needs
+- High throughput messaging
+
+**Pros**: Decoupled services, scalable, audit trail
+**Cons**: Eventual consistency, debugging complexity, message ordering
+
+## CQRS (Command Query Responsibility Segregation)
+
+```
+┌─────────┐         ┌─────────────┐
+│ Commands│────────▶│ Write Model │──┐
+└─────────┘         └─────────────┘  │
+                                     ▼
+                              ┌──────────┐
+                              │  Events  │
+                              └──────────┘
+                                     │
+┌─────────┐         ┌─────────────┐  │
+│ Queries │◀────────│ Read Model  │◀─┘
+└─────────┘         └─────────────┘
+```
+
+**When to Use**:
+- Read/write ratio heavily skewed
+- Complex read queries
+- Event sourcing architecture
+- Different optimization needs
+
+## Quick Reference
+
+| Requirement | Recommended Pattern |
+|-------------|---------------------|
+| Simple CRUD app | Monolith |
+| Growing startup | Modular Monolith |
+| Enterprise scale | Microservices |
+| Variable load | Serverless |
+| Async processing | Event-Driven |
+| Read-heavy | CQRS |