@cubis/foundry 0.3.10

package/Ai Agent Workflow/powers/flutter-code-reviewer/steering/review_checklist.md

@@ -0,0 +1,68 @@
+# PR Review Checklist (copy/paste)
+
+## Architecture
+- [ ] Presentation does not call repository/data sources directly
+- [ ] Domain has no framework-specific imports (Flutter/Riverpod/Dio/Isar/GetX)
+- [ ] Data implements repository interface; errors mapped to Failure/Result
+- [ ] Dependency injection used correctly (no hardcoded dependencies)
+- [ ] Single responsibility principle followed
+
+## State Management
+
+### Riverpod Projects
+- [ ] No side effects in build
+- [ ] `ref.watch` in build, `ref.read` in callbacks, `ref.listen` for side effects
+- [ ] `build()` is pure, mutations in methods
+- [ ] Family params stable (==/hashCode)
+- [ ] No in-place mutation of emitted state
+- [ ] `ref.mounted` checked after async operations
+
+### GetX Projects
+- [ ] Controllers properly disposed
+- [ ] Observables used correctly (.obs, Rx types)
+- [ ] No memory leaks from subscriptions
+- [ ] GetBuilder/Obx used appropriately
+
+### Bloc/Cubit Projects
+- [ ] Events/states are immutable
+- [ ] No side effects in mapEventToState
+- [ ] Bloc properly closed
+- [ ] BlocProvider scope is correct
+
+## UI
+
+### Design System Compliance (if project has design system)
+- [ ] Uses project's design tokens (colors, spacing, typography)
+- [ ] Uses project's component library (not raw Flutter widgets)
+- [ ] No hardcoded colors (`Color(0xFF...)`, `Colors.white`)
+- [ ] No hardcoded spacing (`SizedBox(height: 16)`)
+- [ ] Theme-aware colors used where appropriate
+
+### General UI Best Practices
+- [ ] `select()` or equivalent used to minimize rebuilds
+- [ ] Large lists use `ListView.builder` or equivalent
+- [ ] List items have stable keys when needed
+- [ ] `const` widgets used where possible
+- [ ] No expensive computation in build methods
+
+## Networking/Errors
+- [ ] No secrets in logs
+- [ ] Errors mapped to typed Failure/Error classes
+- [ ] Timeouts configured appropriately
+- [ ] Cancellation behavior reasonable
+- [ ] Retry logic doesn't expose sensitive data
+
+## Tests
+- [ ] Controller/provider/bloc unit tests added
+- [ ] Failure/error paths tested
+- [ ] Widget test covers loading/error/data states
+- [ ] Mocks used appropriately (no real network calls)
+- [ ] Edge cases covered
+
+## Code Quality
+- [ ] Files use lowercase_with_underscores naming
+- [ ] Types use UpperCamelCase
+- [ ] Methods use verb-first naming (fetchUser, submitForm)
+- [ ] One main type per file
+- [ ] No commented-out code
+- [ ] No TODO without issue reference

package/Ai Agent Workflow/powers/flutter-code-reviewer/steering/strict-rules.md

@@ -0,0 +1,84 @@
+# Strict Code Review Rules
+
+> Reference for: Code Reviewer
+> Load when: Enforcing strict review standards
+
+## Core Standard (Non-Negotiable)
+
+- **Correctness first**: reject changes that introduce incorrect behavior, regressions, or incomplete edge cases
+- **Readability is a feature**: if code is hard to understand, request changes
+- **Consistency over preference**: match existing style and patterns within the codebase
+
+## Change Size & Scope
+
+- **Small, focused changes**: large or multi-purpose changes must be split
+- **No scope creep**: remove unrequested features and speculative abstractions
+- **Spec first**: if requirements are ambiguous, request clarification before approval
+
+## Naming & File Organization
+
+- **Intention-revealing names**: names must convey responsibility and behavior
+- **One primary concern per file**: avoid "utility dump" files
+- **Consistent file naming**: `lowercase_with_underscores.dart`
+- **Type naming**: `UpperCamelCase` for classes, enums, typedefs
+
+## Error Handling & Reliability
+
+- **No empty catch blocks**: handle or rethrow with context
+- **Avoid catch-all**: don't catch overly broad exceptions unless at top-level boundary
+- **Fail fast with clear errors**: avoid silent failures and partial updates
+- **Use Result/Either types**: prefer typed error handling over exceptions
+
+## Concurrency & Race Conditions
+
+- **Atomicity required**: read-modify-write must be transactional or atomic
+- **Shared state must be protected**: use proper state management patterns
+- **Idempotency for retries**: requests and jobs should be safe to retry
+- **Check ref.mounted**: always check after async operations in Riverpod
+
+## Design Principles (Strict)
+
+- **SRP**: split large classes/functions by responsibility
+- **KISS**: prefer the simplest solution that meets requirements
+- **DRY**: remove duplicated logic or clearly justify it
+- **YAGNI**: no speculative features or "just in case" hooks
+- **Composition over inheritance**: avoid deep inheritance chains
+
+## State Management (Riverpod)
+
+- **ref.watch in build**: never use ref.read in build methods
+- **ref.read in callbacks**: never use ref.watch in callbacks
+- **No side effects in build**: never call controller methods in build
+- **Immutable state updates**: never mutate state in-place
+- **Family params must be stable**: implement == and hashCode
+
+## Testing Requirements
+
+- **Critical paths covered**: happy path + failure path + edge cases
+- **Concurrency tests**: required when shared state or ordering is involved
+- **No flaky tests**: reject non-deterministic tests
+- **Mock external dependencies**: no real network calls in tests
+
+## Logging & Observability
+
+- **No sensitive data in logs**: redact secrets and PII
+- **Log sparingly**: avoid noisy logs and repeated errors
+- **Actionable logs**: include enough context to debug without leaking data
+
+## Security Baseline
+
+- **Input validation** everywhere input crosses trust boundaries
+- **Least privilege** for services, DB access, and API scopes
+- **No unsafe defaults**: defaults must be secure, explicit opt-in for risky behavior
+
+## Architecture Boundaries
+
+- **Presentation → Domain → Data**: never skip layers
+- **No Flutter in domain**: domain layer must be framework-agnostic
+- **Repository interfaces in domain**: implementations in data layer
+- **No Riverpod in data/domain**: only in presentation layer
+
+## References
+
+- Google Engineering Practices – Code Review: https://google.github.io/eng-practices/review/reviewer/
+- Effective Dart: https://dart.dev/effective-dart

package/Ai Agent Workflow/powers/flutter-code-reviewer/steering/testing_expectations.md

@@ -0,0 +1,21 @@
+# Testing expectations for reviews
+
+When a PR adds or modifies provider/controller logic, require tests:
+
+## Controllers (AsyncNotifier/Notifier)
+- Happy path returns expected state
+- Failure path maps to UI state (message/code)
+- refresh() re-runs build (invalidateSelf)
+- paging: loadMore merges immutably & stops when no more
+
+## Repositories
+- cache hit/miss behavior
+- TTL expiry (if implemented)
+- mapping errors into Failure types
+
+## Widgets
+- verifies loading/error/data renders
+- verifies actions call notifier methods (button taps)
+
+If tests are missing:
+- mark as MAJOR (or BLOCKER if change is risky: auth/session, payment, data deletion).

package/Ai Agent Workflow/powers/flutter-code-reviewer/templates/review_response.md

@@ -0,0 +1,28 @@
+# Code Review (OneUp HR)
+
+## Summary
+- ...
+
+## BLOCKERS
+- **[BLOCKER] ...**
+  - Why: ...
+  - Fix: ...
+
+## MAJORS
+- **[MAJOR] ...**
+  - Why: ...
+  - Fix: ...
+
+## MINORS / NITS
+- ...
+
+## Suggested patch (optional)
+```dart
+// minimal snippet
+```
+
+## Tests to add/update
+- [ ] ...
+
+## Architecture & performance notes
+- ...

package/Ai Agent Workflow/powers/flutter-expert/POWER.md

@@ -0,0 +1,68 @@
+---
+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:
+
+- `steering/project-structure.md`
+- `steering/widget-patterns.md`
+- `steering/performance.md`
+- `steering/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
+```

package/Ai Agent Workflow/powers/flutter-expert/SKILL.md

@@ -0,0 +1,68 @@
+---
+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:
+
+- `steering/project-structure.md`
+- `steering/widget-patterns.md`
+- `steering/performance.md`
+- `steering/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
+```

package/Ai Agent Workflow/powers/flutter-expert/steering/bloc-state.md

@@ -0,0 +1,259 @@
+# Bloc State Management
+
+## When to Use Bloc
+
+Use **Bloc/Cubit** when you need:
+
+* Explicit event → state transitions
+* Complex business logic
+* Predictable, testable flows
+* Clear separation between UI and logic
+
+| Use Case               | Recommended |
+| ---------------------- | ----------- |
+| Simple mutable state   | Riverpod    |
+| Event-driven workflows | Bloc        |
+| Forms, auth, wizards   | Bloc        |
+| Feature modules        | Bloc        |
+
+---
+
+## Core Concepts
+
+| Concept | Description            |
+| ------- | ---------------------- |
+| Event   | User/system input      |
+| State   | Immutable UI state     |
+| Bloc    | Event → State mapper   |
+| Cubit   | State-only (no events) |
+
+---
+
+## Basic Bloc Setup
+
+### Event
+
+```dart
+sealed class CounterEvent {}
+
+final class CounterIncremented extends CounterEvent {}
+
+final class CounterDecremented extends CounterEvent {}
+```
+
+### State
+
+```dart
+class CounterState {
+  final int value;
+
+  const CounterState({required this.value});
+
+  CounterState copyWith({int? value}) {
+    return CounterState(value: value ?? this.value);
+  }
+}
+```
+
+### Bloc
+
+```dart
+import 'package:flutter_bloc/flutter_bloc.dart';
+
+class CounterBloc extends Bloc<CounterEvent, CounterState> {
+  CounterBloc() : super(const CounterState(value: 0)) {
+    on<CounterIncremented>((event, emit) {
+      emit(state.copyWith(value: state.value + 1));
+    });
+
+    on<CounterDecremented>((event, emit) {
+      emit(state.copyWith(value: state.value - 1));
+    });
+  }
+}
+```
+
+---
+
+## Cubit (Recommended for Simpler Logic)
+
+```dart
+class CounterCubit extends Cubit<int> {
+  CounterCubit() : super(0);
+
+  void increment() => emit(state + 1);
+  void decrement() => emit(state - 1);
+}
+```
+
+---
+
+## Providing Bloc to the Widget Tree
+
+```dart
+BlocProvider(
+  create: (_) => CounterBloc(),
+  child: const CounterScreen(),
+);
+```
+
+Multiple blocs:
+
+```dart
+MultiBlocProvider(
+  providers: [
+    BlocProvider(create: (_) => AuthBloc()),
+    BlocProvider(create: (_) => ProfileBloc()),
+  ],
+  child: const AppRoot(),
+);
+```
+
+---
+
+## Using Bloc in Widgets
+
+### BlocBuilder (UI rebuilds)
+
+```dart
+class CounterScreen extends StatelessWidget {
+  const CounterScreen({super.key});
+
+  @override
+  Widget build(BuildContext context) {
+    return BlocBuilder<CounterBloc, CounterState>(
+      buildWhen: (prev, curr) => prev.value != curr.value,
+      builder: (context, state) {
+        return Text(
+          state.value.toString(),
+          style: Theme.of(context).textTheme.displayLarge,
+        );
+      },
+    );
+  }
+}
+```
+
+---
+
+### BlocListener (Side Effects)
+
+```dart
+BlocListener<AuthBloc, AuthState>(
+  listenWhen: (prev, curr) => curr is AuthFailure,
+  listener: (context, state) {
+    if (state is AuthFailure) {
+      ScaffoldMessenger.of(context)
+          .showSnackBar(SnackBar(content: Text(state.message)));
+    }
+  },
+  child: const LoginForm(),
+);
+```
+
+---
+
+### BlocConsumer (Builder + Listener)
+
+```dart
+BlocConsumer<FormBloc, FormState>(
+  listener: (context, state) {
+    if (state.status == FormStatus.success) {
+      context.pop();
+    }
+  },
+  builder: (context, state) {
+    return ElevatedButton(
+      onPressed: state.isValid
+          ? () => context.read<FormBloc>().add(FormSubmitted())
+          : null,
+      child: const Text('Submit'),
+    );
+  },
+);
+```
+
+---
+
+## Accessing Bloc Without Rebuilds
+
+```dart
+context.read<CounterBloc>().add(CounterIncremented());
+```
+
+⚠️ **Never use `watch` inside callbacks**
+
+---
+
+## Async Bloc Pattern (API Calls)
+
+```dart
+on<UserRequested>((event, emit) async {
+  emit(const UserState.loading());
+
+  try {
+    final user = await repository.fetchUser();
+    emit(UserState.success(user));
+  } catch (e) {
+    emit(UserState.failure(e.toString()));
+  }
+});
+```
+
+---
+
+## Bloc + GoRouter (Auth Guard Example)
+
+```dart
+redirect: (context, state) {
+  final authState = context.read<AuthBloc>().state;
+
+  if (authState is Unauthenticated) {
+    return '/login';
+  }
+  return null;
+}
+```
+
+---
+
+## Testing Bloc
+
+```dart
+blocTest<CounterBloc, CounterState>(
+  'emits incremented value',
+  build: () => CounterBloc(),
+  act: (bloc) => bloc.add(CounterIncremented()),
+  expect: () => [
+    const CounterState(value: 1),
+  ],
+);
+```
+
+---
+
+## Best Practices (MUST FOLLOW)
+
+✅ Immutable states
+✅ Small, focused blocs
+✅ One feature = one bloc
+✅ Use Cubit when possible
+✅ Test all blocs
+
+❌ No UI logic inside blocs
+❌ No context usage inside blocs
+❌ No mutable state
+❌ No massive “god blocs”
+
+---
+
+## Quick Reference
+
+| Widget            | Purpose              |
+| ----------------- | -------------------- |
+| BlocBuilder       | UI rebuild           |
+| BlocListener      | Side effects         |
+| BlocConsumer      | Both                 |
+| BlocProvider      | Dependency injection |
+| MultiBlocProvider | Multiple blocs       |
+

package/Ai Agent Workflow/powers/flutter-expert/steering/engineering-principles.md

@@ -0,0 +1,82 @@
+# Engineering Principles
+
+## Core Principles
+
+### SOLID
+
+- **S**ingle Responsibility: One reason to change per class/module
+- **O**pen/Closed: Open for extension, closed for modification
+- **L**iskov Substitution: Subtypes must be substitutable for base types
+- **I**nterface Segregation: Many specific interfaces > one general interface
+- **D**ependency Inversion: Depend on abstractions, not concretions
+
+### KISS — Keep It Simple
+
+- Prefer straightforward solutions over clever ones
+- If it's hard to explain, it's probably too complex
+- Complexity is the enemy of reliability
+
+### DRY — Don't Repeat Yourself
+
+- Extract shared logic into reusable functions/modules
+- Single source of truth for business rules
+- But: don't over-abstract prematurely (see YAGNI)
+
+### YAGNI — You Aren't Gonna Need It
+
+- Build only what's needed now
+- No speculative features or "just in case" code
+- Requirements change; premature abstraction wastes effort
+
+### Separation of Concerns
+
+- Each module handles one aspect of functionality
+- UI, business logic, data access in separate layers
+- Clear boundaries between packages
+
+### Dependency Inversion
+
+- High-level modules don't depend on low-level modules
+- Both depend on abstractions (interfaces)
+- Inject dependencies, don't instantiate them
+
+### Explicit > Implicit
+
+- Favor explicit configuration over magic
+- Clear naming over clever shortcuts
+- Readable code over terse code
+
+### Fail Fast
+
+- Validate inputs at boundaries
+- Throw early on invalid state
+- Don't silently swallow errors
+
+### Boring Architecture Wins
+
+- Proven patterns over trendy solutions
+- Standard libraries over custom implementations
+- Maintainability over cleverness
+
+---
+
+## Applying These Principles
+
+### When Writing Code
+
+1. Ask: "Does this class/function do one thing?"
+2. Ask: "Is this the simplest solution that works?"
+3. Ask: "Am I building something I actually need right now?"
+4. Ask: "Would a new team member understand this?"
+
+### When Reviewing Code
+
+- Flag violations of these principles
+- Suggest simpler alternatives
+- Question speculative features
+
+### When Designing
+
+- Start simple, add complexity only when proven necessary
+- Prefer composition over inheritance
+- Design for change, but don't over-engineer