@cubis/foundry 0.3.64 → 0.3.65

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/react-expert/references/testing-react.md

@@ -0,0 +1,174 @@
+# Testing React
+
+## Basic Component Test
+
+```tsx
+import { render, screen } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+
+test('renders greeting', () => {
+  render(<Greeting name="World" />);
+  expect(screen.getByText('Hello, World!')).toBeInTheDocument();
+});
+
+test('increments counter on click', async () => {
+  const user = userEvent.setup();
+  render(<Counter />);
+
+  await user.click(screen.getByRole('button', { name: /increment/i }));
+
+  expect(screen.getByText('1')).toBeInTheDocument();
+});
+```
+
+## Query Priority
+
+```tsx
+// Preferred: Accessible queries (how users find elements)
+screen.getByRole('button', { name: /submit/i });
+screen.getByLabelText('Email');
+screen.getByPlaceholderText('Search...');
+screen.getByText('Welcome');
+
+// Fallback: Test IDs (when no accessible name)
+screen.getByTestId('custom-element');
+
+// Async queries (wait for element)
+await screen.findByText('Loading complete');
+```
+
+## Testing Forms
+
+```tsx
+test('submits form with user data', async () => {
+  const handleSubmit = vi.fn();
+  const user = userEvent.setup();
+
+  render(<ContactForm onSubmit={handleSubmit} />);
+
+  await user.type(screen.getByLabelText('Name'), 'John Doe');
+  await user.type(screen.getByLabelText('Email'), 'john@example.com');
+  await user.selectOptions(screen.getByLabelText('Topic'), 'support');
+  await user.click(screen.getByRole('button', { name: /submit/i }));
+
+  expect(handleSubmit).toHaveBeenCalledWith({
+    name: 'John Doe',
+    email: 'john@example.com',
+    topic: 'support',
+  });
+});
+```
+
+## Testing with Providers
+
+```tsx
+function renderWithProviders(
+  ui: React.ReactElement,
+  { initialState = {}, ...options } = {}
+) {
+  function Wrapper({ children }: { children: React.ReactNode }) {
+    return (
+      <QueryClientProvider client={queryClient}>
+        <ThemeProvider>
+          {children}
+        </ThemeProvider>
+      </QueryClientProvider>
+    );
+  }
+
+  return render(ui, { wrapper: Wrapper, ...options });
+}
+
+test('displays user data', async () => {
+  renderWithProviders(<UserProfile userId="123" />);
+
+  await screen.findByText('John Doe');
+});
+```
+
+## Mocking API Calls
+
+```tsx
+import { http, HttpResponse } from 'msw';
+import { setupServer } from 'msw/node';
+
+const server = setupServer(
+  http.get('/api/users/:id', ({ params }) => {
+    return HttpResponse.json({ id: params.id, name: 'John' });
+  })
+);
+
+beforeAll(() => server.listen());
+afterEach(() => server.resetHandlers());
+afterAll(() => server.close());
+
+test('fetches and displays user', async () => {
+  render(<UserProfile userId="123" />);
+
+  await screen.findByText('John');
+});
+
+test('handles error', async () => {
+  server.use(
+    http.get('/api/users/:id', () => {
+      return new HttpResponse(null, { status: 500 });
+    })
+  );
+
+  render(<UserProfile userId="123" />);
+
+  await screen.findByText('Error loading user');
+});
+```
+
+## Testing Hooks
+
+```tsx
+import { renderHook, act } from '@testing-library/react';
+
+test('useCounter increments', () => {
+  const { result } = renderHook(() => useCounter());
+
+  act(() => {
+    result.current.increment();
+  });
+
+  expect(result.current.count).toBe(1);
+});
+
+test('useDebounce delays value', async () => {
+  vi.useFakeTimers();
+
+  const { result, rerender } = renderHook(
+    ({ value }) => useDebounce(value, 500),
+    { initialProps: { value: 'initial' } }
+  );
+
+  rerender({ value: 'updated' });
+  expect(result.current).toBe('initial');
+
+  await act(async () => {
+    vi.advanceTimersByTime(500);
+  });
+
+  expect(result.current).toBe('updated');
+  vi.useRealTimers();
+});
+```
+
+## Quick Reference
+
+| Query | Use When |
+|-------|----------|
+| `getByRole` | Buttons, links, headings |
+| `getByLabelText` | Form inputs |
+| `getByText` | Non-interactive text |
+| `findByX` | Async/loading content |
+| `queryByX` | Assert NOT present |
+
+| Pattern | Use Case |
+|---------|----------|
+| `userEvent.setup()` | User interactions |
+| `renderHook()` | Testing custom hooks |
+| `msw` | Mocking API calls |
+| Custom render | Wrap with providers |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/red-team-tactics/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: red-team-tactics
+description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
+allowed-tools: Read, Glob, Grep
+---
+
+# Red Team Tactics
+
+> Adversary simulation principles based on MITRE ATT&CK framework.
+
+---
+
+## 1. MITRE ATT&CK Phases
+
+### Attack Lifecycle
+
+```
+RECONNAISSANCE → INITIAL ACCESS → EXECUTION → PERSISTENCE
+       ↓              ↓              ↓            ↓
+   PRIVILEGE ESC → DEFENSE EVASION → CRED ACCESS → DISCOVERY
+       ↓              ↓              ↓            ↓
+LATERAL MOVEMENT → COLLECTION → C2 → EXFILTRATION → IMPACT
+```
+
+### Phase Objectives
+
+| Phase | Objective |
+|-------|-----------|
+| **Recon** | Map attack surface |
+| **Initial Access** | Get first foothold |
+| **Execution** | Run code on target |
+| **Persistence** | Survive reboots |
+| **Privilege Escalation** | Get admin/root |
+| **Defense Evasion** | Avoid detection |
+| **Credential Access** | Harvest credentials |
+| **Discovery** | Map internal network |
+| **Lateral Movement** | Spread to other systems |
+| **Collection** | Gather target data |
+| **C2** | Maintain command channel |
+| **Exfiltration** | Extract data |
+
+---
+
+## 2. Reconnaissance Principles
+
+### Passive vs Active
+
+| Type | Trade-off |
+|------|-----------|
+| **Passive** | No target contact, limited info |
+| **Active** | Direct contact, more detection risk |
+
+### Information Targets
+
+| Category | Value |
+|----------|-------|
+| Technology stack | Attack vector selection |
+| Employee info | Social engineering |
+| Network ranges | Scanning scope |
+| Third parties | Supply chain attack |
+
+---
+
+## 3. Initial Access Vectors
+
+### Selection Criteria
+
+| Vector | When to Use |
+|--------|-------------|
+| **Phishing** | Human target, email access |
+| **Public exploits** | Vulnerable services exposed |
+| **Valid credentials** | Leaked or cracked |
+| **Supply chain** | Third-party access |
+
+---
+
+## 4. Privilege Escalation Principles
+
+### Windows Targets
+
+| Check | Opportunity |
+|-------|-------------|
+| Unquoted service paths | Write to path |
+| Weak service permissions | Modify service |
+| Token privileges | Abuse SeDebug, etc. |
+| Stored credentials | Harvest |
+
+### Linux Targets
+
+| Check | Opportunity |
+|-------|-------------|
+| SUID binaries | Execute as owner |
+| Sudo misconfiguration | Command execution |
+| Kernel vulnerabilities | Kernel exploits |
+| Cron jobs | Writable scripts |
+
+---
+
+## 5. Defense Evasion Principles
+
+### Key Techniques
+
+| Technique | Purpose |
+|-----------|---------|
+| LOLBins | Use legitimate tools |
+| Obfuscation | Hide malicious code |
+| Timestomping | Hide file modifications |
+| Log clearing | Remove evidence |
+
+### Operational Security
+
+- Work during business hours
+- Mimic legitimate traffic patterns
+- Use encrypted channels
+- Blend with normal behavior
+
+---
+
+## 6. Lateral Movement Principles
+
+### Credential Types
+
+| Type | Use |
+|------|-----|
+| Password | Standard auth |
+| Hash | Pass-the-hash |
+| Ticket | Pass-the-ticket |
+| Certificate | Certificate auth |
+
+### Movement Paths
+
+- Admin shares
+- Remote services (RDP, SSH, WinRM)
+- Exploitation of internal services
+
+---
+
+## 7. Active Directory Attacks
+
+### Attack Categories
+
+| Attack | Target |
+|--------|--------|
+| Kerberoasting | Service account passwords |
+| AS-REP Roasting | Accounts without pre-auth |
+| DCSync | Domain credentials |
+| Golden Ticket | Persistent domain access |
+
+---
+
+## 8. Reporting Principles
+
+### Attack Narrative
+
+Document the full attack chain:
+1. How initial access was gained
+2. What techniques were used
+3. What objectives were achieved
+4. Where detection failed
+
+### Detection Gaps
+
+For each successful technique:
+- What should have detected it?
+- Why didn't detection work?
+- How to improve detection
+
+---
+
+## 9. Ethical Boundaries
+
+### Always
+
+- Stay within scope
+- Minimize impact
+- Report immediately if real threat found
+- Document all actions
+
+### Never
+
+- Destroy production data
+- Cause denial of service (unless scoped)
+- Access beyond proof of concept
+- Retain sensitive data
+
+---
+
+## 10. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Rush to exploitation | Follow methodology |
+| Cause damage | Minimize impact |
+| Skip reporting | Document everything |
+| Ignore scope | Stay within boundaries |
+
+---
+
+> **Remember:** Red team simulates attackers to improve defenses, not to cause harm.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/refactor/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: "refactor"
+displayName: "Refactor - OneUp HR"
+description: "Migrate legacy code to new architecture while maintaining behavior"
+keywords: ["refactor", "migrate", "clean", "improve", "legacy", "architecture"]
+---
+
+# Refactor - OneUp HR
+
+## Migration Patterns
+
+### State: Legacy → Riverpod
+
+```dart
+// FROM
+class _MyScreenState extends State<MyScreen> {
+  bool _isLoading = false;
+}
+
+// TO
+@riverpod
+class MyNotifier extends _$MyNotifier {
+  @override
+  FutureOr<State> build() => State.initial();
+}
+```
+
+### Models: Class → Freezed
+
+```dart
+// FROM
+class User {
+  final String id;
+  User({required this.id});
+}
+
+// TO
+@freezed
+class User with _$User {
+  const factory User({required String id}) = _User;
+  factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
+}
+```
+
+### Colors: Hardcoded → Tokens
+
+```dart
+// FROM
+Color(0xFF123456)
+Colors.white
+
+// TO
+context.colors.primary
+OneColor.white
+```
+
+## Checklist
+
+- [ ] Replace hardcoded values with design tokens
+- [ ] Convert to Riverpod providers
+- [ ] Add freezed for models
+- [ ] Remove dead code
+- [ ] Verify behavior unchanged

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/riverpod-3/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: "riverpod-3"
+displayName: "Riverpod 3 Expert"
+description: "Riverpod 3 best practices for codegen, UI interaction boundaries, caching, paging, lifecycle, and testing"
+keywords:
+  [
+    "riverpod",
+    "riverpod 3",
+    "flutter",
+    "state management",
+    "asyncnotifier",
+    "codegen",
+    "keepalive",
+    "testing",
+  ]
+---
+
+# Riverpod 3 Expert
+
+## Overview
+
+Use this skill for production-grade Riverpod 3 usage in Flutter apps.
+Focus: correct provider lifecycles, predictable UI interaction, rebuild control, side effects, and testability.
+
+## When to Use
+
+- Creating or refactoring providers/notifiers
+- Solving rebuild storms or dependency loops
+- Designing refresh/paging/cache behavior
+- Defining provider lifecycles (`autoDispose` vs `keepAlive`)
+- Writing Riverpod unit/widget tests
+
+## Quick Reference
+
+### AsyncNotifier Pattern
+
+```dart
+@riverpod
+class OrdersController extends _$OrdersController {
+  @override
+  FutureOr<OrdersState> build() async {
+    final repo = ref.watch(ordersRepositoryProvider);
+    final items = await repo.fetchOrders();
+    return OrdersState(items: items);
+  }
+
+  Future<void> refresh() async {
+    ref.invalidateSelf();
+    await future;
+  }
+
+  Future<void> createOrder(CreateOrderInput input) async {
+    final repo = ref.read(ordersRepositoryProvider);
+    state = const AsyncLoading();
+    state = await AsyncValue.guard(() async {
+      await repo.createOrder(input);
+      if (!ref.mounted) return const OrdersState(items: []);
+      final items = await repo.fetchOrders();
+      return OrdersState(items: items);
+    });
+  }
+}
+```
+
+### watch/read/listen/listenManual
+
+```dart
+// Build/render: watch
+final state = ref.watch(ordersControllerProvider);
+
+// User callbacks: read
+onPressed: () => ref.read(ordersControllerProvider.notifier).refresh();
+
+// UI side effects in build-capable context
+ref.listen(ordersControllerProvider, (prev, next) {
+  next.whenOrNull(error: (e, st) => showErrorSnackBar(context, e));
+});
+
+// Lifecycle side effects (initState/dispose flows)
+late final remove = ref.listenManual(authStateProvider, (prev, next) {
+  if (next.isLoggedOut) context.go('/login');
+});
+```
+
+### keepAlive Rule
+
+```dart
+// Use only for app-wide long-lived state
+@Riverpod(keepAlive: true)
+SessionState sessionState(Ref ref) => const SessionState.unknown();
+```
+
+Default to auto-dispose for route/screen-scoped and family providers.
+
+## Core Rules (Do/Don't)
+
+1. Do use `ref.watch` only in widget/provider build paths.
+2. Do use `ref.read` for callbacks and imperative actions.
+3. Do use `ref.listen`/`ref.listenManual` for side effects (navigation/snackbar/dialog).
+4. Don't trigger side effects from render branches (`watch + if + navigate`).
+5. Don't call notifier mutation methods from widget `build`.
+6. Don't mutate collections in-place; always emit new immutable values.
+7. Do keep provider parameters stable and immutable (correct `==/hashCode`).
+8. Do keep business state in providers and ephemeral UI state in widgets.
+
+## KeepAlive Decision Matrix
+
+Use `keepAlive: true` only when all are true:
+- state should survive route changes,
+- recomputation is expensive,
+- cardinality is low (not unbounded families).
+
+Avoid keepAlive for:
+- search/filter family providers,
+- row/detail item families,
+- short-lived forms.
+
+## Loop Avoidance Checklist
+
+- No notifier writes inside provider `build()` unless conditional and bounded.
+- No unconditional `invalidateSelf()` in `build()`.
+- No provider cycles (A watches B and B watches A).
+- No `ref.watch` in callbacks.
+- Audit repeated rebuilds with narrowed `select` usage.
+
+## Steering Files
+
+| File | Load when |
+| --- | --- |
+| `references/loop-avoidance.md` | Diagnosing provider loops, invalidation storms, or notifier recursion. |
+| `references/minimal-rebuild.md` | Reducing rebuilds with `select`, widget splitting, or item-level providers. |
+| `references/provider-layout.md` | Organizing provider boundaries, layers, and ownership. |
+| `references/refresh-cache-paging.md` | Designing refresh, cache TTL, paging, or stale-while-revalidate flows. |
+| `references/testing.md` | Writing `ProviderContainer` or widget tests for Riverpod behavior. |
+
+## Examples
+
+| File | Load when |
+| --- | --- |
+| `examples/attendance_paging.md` | You need a concrete paginated list example. |
+| `examples/profile_edit.md` | You need a form/editing workflow example. |
+
+## Templates
+
+| File | Load when |
+| --- | --- |
+| `templates/cache_policy.dart.md` | Creating a TTL helper for repository caching. |
+| `templates/paged_controller.dart.md` | Bootstrapping a cursor/page-based controller. |
+| `templates/riverpod_controller_test.md` | Starting a provider/controller test template. |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/riverpod-3/examples/attendance_paging.md

@@ -0,0 +1,29 @@
+# Example: Attendance list with paging + refresh (realistic)
+
+This example shows how to implement:
+- initial load (today’s attendance)
+- pull-to-refresh
+- infinite scroll “load more” (older records)
+- cached-first UX
+
+## Files
+- `features/attendance/attendance_controller.dart`
+- `features/attendance/attendance_state.dart`
+- `features/attendance/views/attendance_view.dart`
+
+## State (simplified)
+Use `PagedState<AttendanceRecord>` from the template.
+
+## Controller
+Use `PagedItemsController` template but rename:
+- `PagedAttendanceController`
+- `AttendanceRepository.fetchAttendancePage(...)`
+
+## UI
+- The screen watches the controller provider.
+- A `ScrollController` triggers `loadNextPage` when close to bottom.
+- `RefreshIndicator` calls `refresh()`.
+
+Important minimal-rebuild tip:
+- The list widget should be a separate widget that receives `items` as plain values.
+- Only one place watches the provider.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/riverpod-3/examples/profile_edit.md

@@ -0,0 +1,15 @@
+# Example: Profile edit flow (load + edit + save, loop-free)
+
+Goal:
+- Load profile (AsyncNotifier build)
+- Edit in UI without triggering network calls per keystroke
+- Save -> invalidateSelf -> refresh
+
+Pattern:
+- Controller exposes AsyncValue<ProfileState>.
+- Text fields use local `TextEditingController` for draft edits.
+- On Save: call controller.save(draft) (ref.read(notifier))
+- After save success: controller invalidates itself so build reloads canonical data.
+
+This avoids the common anti-pattern:
+- writing draft state directly into provider on each keystroke (causes rebuild storms).

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/riverpod-3/references/loop-avoidance.md

@@ -0,0 +1,68 @@
+# Infinite loop & rebuild-storm avoidance (Riverpod 3)
+
+## Common loop sources
+
+### 1) Mutation calls in widget build
+Bad:
+```dart
+if (needsLoad) ref.read(itemsControllerProvider.notifier).load();
+```
+Every rebuild can re-trigger the write path.
+
+Fix:
+- Trigger in explicit user callbacks.
+- Trigger initial load in provider `build()`.
+- Use `ref.listenManual` in widget lifecycle when you need one-time imperative hooks.
+
+### 2) Self-invalidating provider build
+Bad:
+- `build()` unconditionally calls `ref.invalidateSelf()`.
+- `build()` performs persistent writes each run.
+
+Fix:
+- Keep `build()` declarative.
+- Mutations belong in methods.
+- Use dependency `watch` so recompute happens naturally when inputs change.
+
+### 3) Wrong watch/read boundaries
+Bad:
+```dart
+onPressed: () async {
+  final v = ref.watch(filtersProvider); // WRONG
+}
+```
+Fix:
+```dart
+onPressed: () async {
+  final v = ref.read(filtersProvider);
+}
+```
+
+### 4) In-place state mutation
+Bad:
+```dart
+state.value!.items.add(item);
+state = state;
+```
+Fix:
+```dart
+final current = state.valueOrNull ?? const ItemsState(items: []);
+state = AsyncData(current.copyWith(items: [...current.items, item]));
+```
+
+### 5) Circular provider graph
+Bad:
+- `aProvider` watches `bProvider`
+- `bProvider` watches `aProvider`
+
+Fix:
+- Extract shared dependency into `baseProvider`.
+- Keep read model and write model separated.
+
+## Quick debug flow
+
+1. Identify the smallest widget rebuilding repeatedly.
+2. Search for `invalidateSelf`, `state =`, and notifier calls in build paths.
+3. Confirm no `watch` usage in callbacks.
+4. Confirm immutable updates and stable family params.
+5. Add temporary logs to provider build/mutation methods to locate loop edge.