@cubis/foundry 0.3.63 → 0.3.65

package/workflows/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/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/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/skills/flutter-security-reviewer/POWER.md

@@ -1,204 +0,0 @@
----
-name: "flutter-security-reviewer"
-displayName: "Flutter/Dart Security Reviewer"
-description: "Review Flutter/Dart code for security vulnerabilities: secure storage, network hardening, log redaction, and data protection"
-keywords:
-  [
-    "security",
-    "flutter security",
-    "dart security",
-    "secure storage",
-    "encryption",
-    "log redaction",
-    "network security",
-    "data protection",
-    "pii",
-    "sensitive data",
-    "authentication",
-    "authorization",
-  ]
----
-
-# Flutter/Dart Security Reviewer
-
-## Overview
-
-This power helps you identify and fix security vulnerabilities in mobile and web applications, focusing on secure storage, network hardening, log redaction, and sensitive data handling.
-
-## When to Use
-
-- Reviewing code that handles authentication tokens
-- Implementing secure storage for sensitive data
-- Adding logging/analytics that might expose PII
-- Reviewing network requests for security issues
-- Implementing biometric authentication
-- Handling user passwords or credentials
-- Processing payment information
-- Storing user preferences that contain sensitive data
-- Implementing session management
-- Any code that touches user data
-
-## Review Output Format
-
-When reviewing, output exactly:
-
-1. **Threat summary** (what could go wrong; 3-6 bullets)
-2. **Findings** grouped by severity (CRITICAL/HIGH/MED/LOW)
-3. **Concrete mitigations** (specific code-level steps)
-4. **Security regression tests/checks** (what to verify)
-5. **Logging & privacy audit** (PII, tokens, crash reports)
-
-## Severity Definitions
-
-- **CRITICAL**: Token/session compromise, auth bypass, remote code/data exposure, storing secrets insecurely, PII leakage
-- **HIGH**: Weak access control, insecure defaults, sensitive data in logs, missing TLS assumptions
-- **MED**: Hardening gaps (timeouts, retry abuse, overly broad permissions)
-- **LOW**: Best-practice improvements
-
----
-
-## 1) Authentication & Session Security
-
-### Tokens
-
-**CRITICAL:**
-- Tokens in logs, analytics events, crash reports
-- Tokens stored in plain SharedPreferences without justification
-
-**Recommendations:**
-- Prefer secure storage for tokens (platform-backed) where possible
-- If SharedPreferences must be used, ensure:
-  - Short-lived access tokens + refresh tokens handled carefully
-  - Minimal token surface; never log
-
-### Route Guards
-- Ensure router guards cannot be bypassed by deep links
-- Guard decisions must use authoritative session provider state
-- Avoid redirect loops (secure + usability)
-
----
-
-## 2) Network Security
-
-### Checklist
-- [ ] Use HTTPS in UAT/Prod baseUrl
-- [ ] Reasonable timeouts (connect/receive)
-- [ ] Avoid disabling cert validation
-- [ ] Do not accept all certs in production
-- [ ] Interceptors must not log sensitive headers or body fields
-
-### Retry Policy
-- Avoid retrying non-idempotent requests unless safe
-- Backoff + max attempts
-
-### Device ↔ Gateway Security
-- Prefer server-side validation and proper auth
-- Never "security-by-obscurity" headers
-
----
-
-## 3) Local Data Protection
-
-**CRITICAL:**
-- Storing PII or tokens unencrypted without threat model
-
-**Guidance:**
-- Store only what's needed offline
-- Encrypt sensitive cached blobs if possible, or avoid caching them
-- Apply TTL to cached session/profile data
-- Clear data on logout
-
----
-
-## 4) Input Validation & Injection Safety
-
-- [ ] Validate all user inputs before sending to API
-- [ ] Avoid string interpolation for SQL queries: use parameters
-- [ ] Avoid trusting client-only checks (roles, orgId); server must enforce
-
----
-
-## 5) Privacy, Logging, Analytics
-
-**CRITICAL:**
-- PII in logs (`name`, `phone`, `location`, identifiers)
-- Tokens/headers in logs
-- Crashlytics sending PII
-
-**Guidance:**
-- Redact: Authorization headers, cookies, IDs if sensitive
-- Provide `toSafeLog()` helpers
-- Ensure debug logging is disabled/limited in release builds
-
----
-
-## 6) Dependency & Supply Chain Hygiene
-
-- [ ] Check new packages are reputable and maintained
-- [ ] Avoid adding packages that request broad permissions without need
-- [ ] Pin versions as appropriate; review changelogs for security fixes
-
----
-
-## 7) Security Review Checklist for PRs
-
-### Always Search For
-- `print(`, `debugPrint(`, logging interceptors
-- `Authorization`, `token`, `refresh`, `secret`, `apiKey`
-- `badCertificateCallback`, `HttpClient` overrides
-- Persistent storage of user/session data
-
-### Enforce
-- [ ] No secrets in repo
-- [ ] No insecure network overrides in production
-- [ ] Logout clears sensitive local data
-- [ ] Access control enforced server-side (don't trust client role/org headers alone)
-
----
-
-## Quick Reference
-
-### Secure Storage (DO)
-
-```dart
-// ✅ Use flutter_secure_storage for tokens
-final storage = FlutterSecureStorage();
-await storage.write(key: 'auth_token', value: token);
-```
-
-### Secure Storage (DON'T)
-
-```dart
-// ❌ Never store tokens in SharedPreferences
-final prefs = await SharedPreferences.getInstance();
-prefs.setString('auth_token', token); // INSECURE!
-
-// ❌ Never hardcode secrets
-const apiKey = 'sk_live_abc123'; // NEVER DO THIS
-```
-
-### Log Redaction
-
-```dart
-// ❌ Bad - logs sensitive data
-logger.info('User login: ${user.email}, password: ${password}');
-
-// ✅ Good - no sensitive data in logs
-logger.info('User login successful: userId=${user.id}');
-```
-
----
-
-## Steering Files
-
-| File                        | Load When                              |
-| --------------------------- | -------------------------------------- |
-| `secure_storage_policy.md`  | What to store where                    |
-| `network_hardening.md`      | Network security best practices        |
-| `log_redaction.md`          | How to redact sensitive data from logs |
-| `vulnerability-patterns.md` | SQL injection, XSS, IDOR patterns      |
-| `secret-scanning.md`        | Finding hardcoded secrets              |
-
-## Templates
-
-- `security_review_response.md` - Security review report template