@cubis/foundry 0.3.62 → 0.3.64

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/error-ux-observability/POWER.md

@@ -1,158 +0,0 @@
----
-name: "error-ux-observability"
-displayName: "Error UX & Observability"
-description: "Map backend failures to user-friendly messages, implement proper logging levels, and ensure observable error handling"
-keywords:
-  [
-    "error handling",
-    "error messages",
-    "logging",
-    "observability",
-    "user feedback",
-    "failure mapping",
-    "error ux",
-  ]
----
-
-# Error UX & Observability
-
-## Overview
-
-This power helps you translate technical errors into user-friendly messages, implement proper logging for debugging, and ensure errors are observable in production.
-
-## When to Use
-
-- Implementing error handling in repositories/use cases
-- Mapping API errors to UI messages
-- Adding logging to track issues
-- Reviewing error handling code
-- Debugging production issues
-
-## Quick Reference
-
-### Failure to UI Message Mapping
-
-```dart
-// ✅ Map technical errors to user-friendly messages
-String getErrorMessage(Failure failure) {
-  return failure.when(
-    network: () => 'No internet connection. Please check your network.',
-    server: (code, message) {
-      if (code == 401) return 'Session expired. Please login again.';
-      if (code == 403) return 'You don\'t have permission for this action.';
-      if (code == 404) return 'Resource not found.';
-      if (code >= 500) return 'Server error. Please try again later.';
-      return message ?? 'Something went wrong.';
-    },
-    validation: (errors) => errors.values.first,
-    unauthorized: () => 'Please login to continue.',
-    notFound: () => 'Item not found.',
-    unknown: (error) => 'An unexpected error occurred.',
-  );
-}
-```
-
-### Logging Levels
-
-```dart
-// ✅ Use appropriate log levels
-logger.debug('Cache hit for attendance data'); // Development only
-logger.info('User logged in: userId=${user.id}'); // Important events
-logger.warning('API rate limit approaching'); // Potential issues
-logger.error('Failed to sync attendance', error: e, stackTrace: st); // Errors
-logger.fatal('Database corruption detected'); // Critical failures
-```
-
-### Error Context
-
-```dart
-// ✅ Include context in errors
-try {
-  await repository.submitLeave(leaveRequest);
-} catch (e, st) {
-  logger.error(
-    'Failed to submit leave request',
-    error: e,
-    stackTrace: st,
-    context: {
-      'userId': user.id,
-      'leaveType': leaveRequest.type,
-      'startDate': leaveRequest.startDate,
-    },
-  );
-  rethrow;
-}
-```
-
-## Error Handling Patterns
-
-### Repository Layer
-
-```dart
-@override
-Future<Result<Attendance>> submitAttendance(AttendanceRequest request) async {
-  try {
-    final response = await _remoteDataSource.submit(request);
-    return Result.success(response);
-  } on DioException catch (e) {
-    logger.error('Submit attendance failed', error: e);
-    return Result.failure(_mapDioError(e));
-  } catch (e, st) {
-    logger.error('Unexpected error', error: e, stackTrace: st);
-    return Result.failure(Failure.unknown(e.toString()));
-  }
-}
-```
-
-### Controller Layer
-
-```dart
-Future<void> submit() async {
-  final prev = state;
-  state = const AsyncLoading();
-  
-  final result = await ref.read(featureRepositoryProvider).submit(request);
-  
-  result.when(
-    success: (data) => ref.invalidateSelf(),
-    failure: (failure) {
-      logger.warning('Submit failed', context: {'failure': failure});
-      state = prev;
-      throw Exception(failure.message);
-    },
-  );
-}
-```
-
-### UI Layer
-
-```dart
-ref.listen(controllerProvider, (prev, next) {
-  next.whenOrNull(
-    error: (error, _) {
-      final message = error is Failure 
-        ? getErrorMessage(error)
-        : 'An unexpected error occurred';
-      OneSnackbar.error(context, message);
-    },
-  );
-});
-```
-
-## Logging Best Practices
-
-1. **Never log sensitive data** (passwords, tokens, PII)
-2. **Include context** (userId, action, timestamp)
-3. **Use structured logging** (key-value pairs)
-4. **Log at appropriate levels** (debug/info/warning/error/fatal)
-5. **Include stack traces for errors**
-
-## Steering Files
-
-- `failure_to_ui.md` - Complete failure-to-message mapping guide
-- `logging_levels.md` - When to use each log level
-
-## Templates
-
-- `failure_message_mapper` - Failure to UI message mapper template
-

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/fastify-patterns/POWER.md

@@ -1,167 +0,0 @@
----
-name: fastify-patterns
-displayName: Fastify Patterns
-description: NestJS + Fastify integration patterns including secure sessions, cookie authentication, performance optimization, and plugin configuration. Use for high-performance API development.
-keywords:
-  - Fastify
-  - NestJS Fastify
-  - secure-session
-  - cookie authentication
-  - Fastify plugins
-  - performance
-  - rate limiting
-author: OneUp
----
-
-# Fastify Patterns
-
-## Overview
-
-Expert guidance for building high-performance NestJS applications with Fastify adapter. Covers secure session management, cookie-based authentication, plugin configuration, and performance optimization patterns.
-
-## Role Definition
-
-You are a backend performance specialist with deep expertise in Fastify and NestJS integration. You optimize for throughput, security, and maintainability while leveraging Fastify's plugin architecture.
-
-## When to Use This Power
-
-- Setting up NestJS with Fastify adapter
-- Implementing cookie-based session authentication
-- Configuring Fastify plugins (helmet, cors, rate-limit)
-- Optimizing API performance
-- Migrating from Express to Fastify
-- Implementing secure stateless sessions
-
-## Core Workflow
-
-1. **Bootstrap** - Configure Fastify adapter with NestJS
-2. **Security** - Register security plugins (helmet, cors, secure-session)
-3. **Performance** - Configure rate limiting and caching
-4. **Validation** - Set up global validation pipes
-5. **Test** - Benchmark and verify performance gains
-
-## Available Steering Files
-
-| Topic                | Reference                       | Load When                                     |
-| -------------------- | ------------------------------- | --------------------------------------------- |
-| Secure Sessions      | `references/secure-sessions.md`   | Cookie auth, session management, key rotation |
-| Plugin Configuration | `references/plugin-config.md`     | Helmet, CORS, rate limiting, compression      |
-| Performance Tuning   | `references/performance.md`       | Benchmarking, optimization, caching           |
-| Migration Guide      | `references/express-migration.md` | Converting Express middleware to Fastify      |
-
-## Quick Reference
-
-### Bootstrap with Fastify
-
-```typescript
-// main.ts
-import { NestFactory } from "@nestjs/core";
-import {
-  FastifyAdapter,
-  NestFastifyApplication,
-} from "@nestjs/platform-fastify";
-import { AppModule } from "./app.module";
-
-async function bootstrap() {
-  const app = await NestFactory.create<NestFastifyApplication>(
-    AppModule,
-    new FastifyAdapter({ logger: true }),
-  );
-
-  await app.listen(3000, "0.0.0.0");
-}
-bootstrap();
-```
-
-### Register Fastify Plugins
-
-```typescript
-// main.ts - Security plugins
-import helmet from "@fastify/helmet";
-import cors from "@fastify/cors";
-import rateLimit from "@fastify/rate-limit";
-
-async function bootstrap() {
-  const app = await NestFactory.create<NestFastifyApplication>(
-    AppModule,
-    new FastifyAdapter(),
-  );
-
-  // Security headers
-  await app.register(helmet, {
-    contentSecurityPolicy: {
-      directives: {
-        defaultSrc: ["'self'"],
-        styleSrc: ["'self'", "'unsafe-inline'"],
-      },
-    },
-  });
-
-  // CORS
-  await app.register(cors, {
-    origin: process.env.CORS_ORIGIN?.split(",") || [],
-    credentials: true,
-  });
-
-  // Rate limiting
-  await app.register(rateLimit, {
-    max: 100,
-    timeWindow: "1 minute",
-  });
-
-  await app.listen(3000, "0.0.0.0");
-}
-```
-
-### Secure Session Setup
-
-```typescript
-import cookie from "@fastify/cookie";
-import secureSession from "@fastify/secure-session";
-
-// Register cookie and session plugins
-await app.register(cookie);
-await app.register(secureSession, {
-  cookieName: process.env.SESSION_COOKIE_NAME || "session",
-  key: Buffer.from(process.env.SESSION_SECRET!, "hex"),
-  cookie: {
-    httpOnly: true,
-    secure: process.env.NODE_ENV === "production",
-    sameSite: "lax",
-    path: "/",
-  },
-});
-```
-
-## Constraints
-
-### MUST DO
-
-- Use `@nestjs/platform-fastify` adapter
-- Register security plugins before routes
-- Use `0.0.0.0` for Docker/container deployments
-- Generate session keys with `npx @fastify/secure-session`
-- Set `httpOnly: true` for session cookies
-- Enable `secure: true` in production
-
-### MUST NOT DO
-
-- Mix Express and Fastify middleware
-- Use Express-specific `req.ip` (use `request.ip` instead)
-- Hardcode session secrets
-- Skip rate limiting on auth endpoints
-- Use `localhost` in containerized environments
-
-## Performance Comparison
-
-| Metric        | Express | Fastify | Improvement |
-| ------------- | ------- | ------- | ----------- |
-| Requests/sec  | ~17,000 | ~30,000 | ~76% faster |
-| Latency (avg) | 5.8ms   | 3.3ms   | ~43% lower  |
-| Memory        | Higher  | Lower   | ~20% less   |
-
-## Related Powers
-
-- **NestJS Expert** - Core NestJS patterns
-- **Security Reviewer** - Security auditing
-- **DevOps Engineer** - Container deployment

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/flutter-code-reviewer/POWER.md

@@ -1,185 +0,0 @@
----
-name: "flutter-code-reviewer"
-displayName: "Flutter/Dart Code Reviewer"
-description: "Perform strict, actionable code reviews for Flutter/Dart projects enforcing architecture boundaries, Riverpod patterns, testing, and performance"
-keywords:
-  [
-    "code review",
-    "pr review",
-    "flutter review",
-    "dart review",
-    "riverpod review",
-    "architecture",
-    "clean code",
-    "testing",
-    "performance",
-  ]
----
-
-# Flutter/Dart Code Reviewer
-
-## Overview
-
-This power performs comprehensive code reviews enforcing Clean Architecture boundaries, state management patterns (Riverpod/GetX/Bloc), testing requirements, and performance standards. It adapts to your project's specific tech stack and design system.
-
-## Review Goals
-
-- Keep the codebase **consistent** with your architecture
-- Catch bugs early (loops, rebuild storms, race conditions)
-- Enforce **clean boundaries** (presentation ↔ domain ↔ data)
-- Ensure changes are **testable** and include the right tests
-- Prevent long-term maintenance pain (naming, duplication, tight coupling)
-
-## When to Use
-
-- Reviewing pull requests
-- Conducting code quality audits
-- Checking for architectural violations
-- Validating state management patterns
-- Ensuring test coverage
-
-## Review Severity Levels
-
-- **BLOCKER**: Must fix before merge (crashes, security, data loss, infinite loops, architectural violations)
-- **MAJOR**: Should fix before merge (performance issues, missing tests, incorrect patterns)
-- **MINOR**: Fix soon (style, small refactors)
-- **NIT**: Optional (readability, formatting)
-
-## Review Output Format
-
-When reviewing, output exactly:
-
-1. **Summary** (2-5 lines)
-2. **BLOCKERS** (bulleted, each with "Why" + "Fix")
-3. **MAJORS**
-4. **MINORS / NITS**
-5. **Suggested patch** (optional: small code snippets only)
-6. **Tests to add/update** (concrete list)
-7. **Architecture & performance notes** (select/watch boundaries, DI, caching)
-
----
-
-## Architecture Compliance (Pragmatic Clean Architecture)
-
-### Presentation Layer
-- Views contain **no business logic**, no repository calls
-- Controllers (AsyncNotifier) own all state + operations for a feature
-- One controller per feature — reads AND writes (no separate mutation unless 5+ write ops)
-- UI uses design system components and tokens
-
-### Data Layer
-- Repository is the "conductor" — coordinates API + cache, returns domain types
-- Repository handles error mapping (DioException → Failure)
-- No Riverpod imports in data layer
-- DI provider for repository lives inline in the repository file
-
-### Models
-- ONE Freezed class per entity (no separate entity + model)
-- Add mapper only when API response shape ≠ domain shape
-
-**BLOCKER if:**
-- UI calls repository/data source directly
-- Data layer imports Riverpod/Flutter
-- Controller imports data-layer classes (Dio, jsonEncode/Decode)
-- Duplicate entity + model classes when they're the same shape
-- Pass-through use cases that just call `repository.method()`
-
----
-
-## State Management Review
-
-### Riverpod Watch/Read Discipline
-- `ref.watch` only in widget build / provider build
-- `ref.read` in callbacks + controller methods
-- `ref.listen` for side effects (snackbar/nav/dialog)
-
-### Loop & Rebuild Storm Red Flags
-
-**BLOCKER:**
-- Calling controller methods inside widget `build()`
-- Updating providers during build in a way that affects watched dependencies
-- Mutating lists/maps in-place and re-emitting same object reference
-
-### Families / Parameters
-- Params must be stable and comparable (`==`/`hashCode`) if object-based
-- Avoid passing mutable lists/maps as family params
-
-### Async State Handling
-- For "load more", keep flags inside state (don't abuse AsyncLoading and lose data)
-- Guard parallel calls (`isLoadingMore`)
-
----
-
-## Naming & File Structure
-
-### File Naming
-- `lowercase_with_underscores.dart` for files and folders
-- 1 file = 1 main public type (or a tight group)
-
-### Type/Function Naming
-- Types: UpperCamelCase
-- Methods: lowerCamelCase; verb-first for commands (`refresh`, `submit`, `approve`)
-- Avoid `getX()` for remote calls; use `fetchX()`
-
-**BLOCKER if:**
-- Inconsistent naming causes confusion across features
-- Cross-feature imports instead of shared/core modules
-
----
-
-## Clean Code Principles (Pragmatic)
-
-Apply these *practically*:
-- **SRP**: one controller per screen/aggregate; repositories only data concerns
-- **DIP**: domain depends on abstractions; data provides implementations
-- **KISS**: avoid over-abstraction; prefer the simplest working design
-- **DRY**: avoid copy/paste, but do not create "god utils" or premature frameworks
-- **YAGNI**: don't add complexity "just in case"
-
-Use as review guidance, not dogma.
-
----
-
-## Performance Checklist
-
-**BLOCKER:**
-- Expensive computation in build (parsing, sorting large lists) without memoization
-- Whole-screen watching large provider states without `select`
-- Rebuilding entire lists for small changes
-
-**MAJOR:**
-- Missing `const` where easy
-- No stable keys on list items where state should persist
-
----
-
-## Testing Requirements
-
-Required when:
-- New controller/provider logic is added
-- Bug fixes for regressions
-- Paging/refresh/caching logic changes
-- Error mapping changes
-
-Minimum:
-- 1 unit/provider test for controller happy path
-- 1 unit test for failure path
-- Widget test for loading/error/data (or override repo)
-
-See: `steering/testing_expectations.md`
-
----
-
-## Steering Files
-
-| File                       | Load When                              |
-| -------------------------- | -------------------------------------- |
-| `review_checklist.md`      | Starting a review, categories          |
-| `testing_expectations.md`  | Checking test requirements             |
-| `common-issues.md`         | N+1 queries, magic numbers, patterns   |
-| `feedback-examples.md`     | Writing good feedback                  |
-| `strict-rules.md`          | Enforcing strict review standards      |
-
-## Templates
-
-- `review_response.md` - Code review response template

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/flutter-expert/POWER.md

@@ -1,68 +0,0 @@
----
-name: "flutter-expert"
-displayName: "Flutter Expert"
-description: "Flutter app architecture coordinator for Clean Architecture projects; delegates state, routing, persistence, testing, and security to specialized skills"
-keywords:
-  [
-    "flutter",
-    "clean architecture",
-    "modular",
-    "feature",
-    "coordination",
-    "riverpod",
-    "gorouter",
-    "drift",
-  ]
----
-
-# Flutter Expert
-
-## Overview
-
-Use this skill as the top-level coordinator for Flutter feature work and refactors.
-It defines architecture boundaries and routes implementation details to specialized Flutter skills.
-
-## Delegation Matrix
-
-- Riverpod state, codegen, lifecycles, caching -> `riverpod-3`
-- GoRouter guards, redirects, deep links, restoration -> `gorouter-restoration`
-- Drift schema, DAOs, migrations, transactions -> `drift-flutter`
-- Widget/unit/integration testing strategy -> `flutter-test-master`
-- Security review (storage, logs, transport) -> `flutter-security-reviewer`
-- Accessibility and semantics -> `accessibility`
-- UX consistency and screen states -> `ux-ui-consistency`
-- Error messaging and observability -> `error-ux-observability`
-
-## Core Boundaries
-
-1. Keep this skill focused on architecture and orchestration decisions.
-2. Do not duplicate provider lifecycle rules from `riverpod-3`.
-3. Do not duplicate guard/redirect rules from `gorouter-restoration`.
-4. Keep domain and use-case layers framework-agnostic.
-5. Keep data access behind repositories/adapters.
-
-## Delivery Workflow
-
-1. Define feature boundary and module ownership.
-2. Select specialized skills by concern (state, routing, persistence).
-3. Implement vertical slice end-to-end.
-4. Validate with tests and quality skills before merge.
-
-## Local References
-
-Use these only for high-level guidance in this skill:
-
-- `references/project-structure.md`
-- `references/widget-patterns.md`
-- `references/performance.md`
-- `references/engineering-principles.md`
-
-For Riverpod and GoRouter implementation details, use `riverpod-3` and `gorouter-restoration` directly.
-
-## Quick Commands
-
-```bash
-flutter --version
-flutter analyze
-flutter test
-```