@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/laravel/references/security.md

@@ -1,245 +0,0 @@
-# Security Reference
-
-## Authentication
-
-### Sanctum (API Token Authentication)
-
-Sanctum is the default Laravel API authentication package. Use it for SPA
-authentication (cookie-based) and mobile API tokens.
-
-```php
-// Install and configure
-// bootstrap/app.php already includes Sanctum in Laravel 11
-
-// Protecting routes
-Route::middleware('auth:sanctum')->group(function () {
-    Route::apiResource('orders', OrderController::class);
-});
-
-// Issuing tokens
-$token = $user->createToken('api-access', ['orders:read', 'orders:write']);
-return ['token' => $token->plainTextToken];
-
-// Checking abilities
-if ($user->tokenCan('orders:write')) {
-    // proceed
-}
-
-// Revoking tokens
-$user->currentAccessToken()->delete();   // Current token
-$user->tokens()->delete();               // All tokens
-```
-
-### Rate Limiting Authentication Endpoints
-
-Always rate limit login and registration to prevent credential stuffing.
-
-```php
-RateLimiter::for('login', function (Request $request) {
-    $key = Str::lower($request->input('email')) . '|' . $request->ip();
-    return Limit::perMinute(5)->by($key);
-});
-
-Route::post('login', LoginController::class)
-    ->middleware('throttle:login');
-```
-
-## Authorization
-
-### Policies
-
-Define one Policy per model. Register policies via auto-discovery (Laravel 11
-auto-discovers policies in `app/Policies` matching model names).
-
-```php
-<?php
-
-declare(strict_types=1);
-
-namespace App\Policies;
-
-use App\Models\Order;
-use App\Models\User;
-
-class OrderPolicy
-{
-    public function viewAny(User $user): bool
-    {
-        return true; // Authenticated users can list their orders
-    }
-
-    public function view(User $user, Order $order): bool
-    {
-        return $user->id === $order->customer->user_id;
-    }
-
-    public function create(User $user): bool
-    {
-        return $user->hasVerifiedEmail();
-    }
-
-    public function update(User $user, Order $order): bool
-    {
-        return $user->id === $order->customer->user_id
-            && $order->status === 'pending';
-    }
-
-    public function delete(User $user, Order $order): bool
-    {
-        return $user->id === $order->customer->user_id
-            && $order->status === 'pending';
-    }
-}
-```
-
-### Using Policies in Controllers
-
-```php
-public function show(Order $order): OrderResource
-{
-    $this->authorize('view', $order);
-    return new OrderResource($order->load('items.product'));
-}
-
-// Or in Form Requests
-public function authorize(): bool
-{
-    $order = $this->route('order');
-    return $this->user()->can('update', $order);
-}
-```
-
-## Input Sanitization
-
-### Mass Assignment Protection
-
-Always use `$fillable` (allow-list) instead of `$guarded` (deny-list).
-
-```php
-// GOOD: explicit allow-list
-protected $fillable = ['name', 'email', 'phone'];
-
-// BAD: easy to forget new sensitive columns
-protected $guarded = ['id', 'is_admin'];
-```
-
-### Validation Rules for Security
-
-```php
-public function rules(): array
-{
-    return [
-        'email'    => ['required', 'email:rfc,dns', 'max:255'],
-        'password' => ['required', Password::min(12)->mixedCase()->numbers()->symbols()],
-        'url'      => ['required', 'url:https'],         // HTTPS only
-        'file'     => ['required', 'file', 'mimes:pdf,docx', 'max:10240'],
-        'html'     => ['required', 'string', new NoScriptTags],  // Custom rule
-    ];
-}
-```
-
-## CSRF Protection
-
-CSRF protection is enabled by default for web routes. For API routes using
-token authentication (Sanctum tokens, not cookies), CSRF is not needed.
-
-For SPA authentication with Sanctum cookies, CSRF is required:
-
-```php
-// Frontend must fetch the CSRF cookie first
-// GET /sanctum/csrf-cookie
-
-// Then include the X-XSRF-TOKEN header on subsequent requests
-```
-
-## Encryption
-
-### Encrypting Data at Rest
-
-```php
-// Using the Crypt facade
-use Illuminate\Support\Facades\Crypt;
-
-$encrypted = Crypt::encryptString($ssn);
-$decrypted = Crypt::decryptString($encrypted);
-
-// Using cast on Eloquent models
-protected function casts(): array
-{
-    return [
-        'ssn'     => 'encrypted',
-        'api_key' => 'encrypted',
-    ];
-}
-```
-
-### Hashing Passwords
-
-Laravel hashes passwords automatically with `bcrypt` by default. Use `argon2id`
-for higher security when hardware supports it.
-
-```php
-// config/hashing.php
-'driver' => 'argon2id',
-
-// Manual hashing
-use Illuminate\Support\Facades\Hash;
-
-$hashed = Hash::make($password);
-$valid = Hash::check($password, $hashed);
-```
-
-## Security Headers
-
-Apply security headers via middleware.
-
-```php
-class SecurityHeaders
-{
-    public function handle(Request $request, Closure $next): Response
-    {
-        $response = $next($request);
-
-        $response->headers->set('X-Content-Type-Options', 'nosniff');
-        $response->headers->set('X-Frame-Options', 'DENY');
-        $response->headers->set('X-XSS-Protection', '0');
-        $response->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');
-        $response->headers->set('Permissions-Policy', 'camera=(), microphone=()');
-        $response->headers->set(
-            'Strict-Transport-Security',
-            'max-age=63072000; includeSubDomains; preload'
-        );
-
-        return $response;
-    }
-}
-```
-
-## Environment and Secrets
-
-- Store secrets in `.env` and never commit `.env` to version control.
-- Use `config()` helper to access env values. Never call `env()` outside config files.
-- Use Laravel's encrypted environment files for production secrets.
-- Rotate `APP_KEY` periodically and re-encrypt stored data.
-
-```bash
-# Encrypt .env for production
-php artisan env:encrypt --env=production
-
-# Decrypt at deploy time
-php artisan env:decrypt --env=production --key=base64:...
-```
-
-## SQL Injection Prevention
-
-Always use Eloquent or the query builder with parameter binding. Never
-concatenate user input into raw SQL.
-
-```php
-// SAFE: parameter binding
-DB::select('SELECT * FROM users WHERE email = ?', [$email]);
-User::where('email', $email)->first();
-
-// DANGEROUS: string concatenation
-DB::select("SELECT * FROM users WHERE email = '$email'"); // NEVER
-```

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/laravel/references/testing.md

@@ -1,302 +0,0 @@
-# Testing Reference
-
-## Test Organization
-
-### Directory Structure
-
-```
-tests/
-  Feature/
-    Api/
-      OrderControllerTest.php
-      PaymentControllerTest.php
-    Jobs/
-      ProcessPaymentTest.php
-  Unit/
-    Models/
-      OrderTest.php
-    Services/
-      PricingServiceTest.php
-```
-
-Feature tests hit real routes through the HTTP kernel with middleware active.
-Unit tests isolate a single class with mocked dependencies.
-
-## Feature Tests
-
-### Basic API Test
-
-```php
-<?php
-
-declare(strict_types=1);
-
-namespace Tests\Feature\Api;
-
-use App\Models\Order;
-use App\Models\User;
-use Illuminate\Foundation\Testing\RefreshDatabase;
-use Tests\TestCase;
-
-class OrderControllerTest extends TestCase
-{
-    use RefreshDatabase;
-
-    public function test_index_returns_paginated_orders(): void
-    {
-        $user = User::factory()->create();
-        Order::factory()->count(30)->for($user->customer)->create();
-
-        $response = $this->actingAs($user)
-            ->getJson('/api/v1/orders');
-
-        $response
-            ->assertOk()
-            ->assertJsonCount(25, 'data')  // default pagination
-            ->assertJsonStructure([
-                'data' => [['id', 'status', 'total', 'customer', 'items']],
-                'links',
-                'meta',
-            ]);
-    }
-
-    public function test_show_returns_single_order_with_relations(): void
-    {
-        $order = Order::factory()->withItems(3)->create();
-        $user = $order->customer->user;
-
-        $response = $this->actingAs($user)
-            ->getJson("/api/v1/orders/{$order->id}");
-
-        $response
-            ->assertOk()
-            ->assertJsonPath('data.id', $order->id)
-            ->assertJsonCount(3, 'data.items');
-    }
-
-    public function test_unauthenticated_user_gets_401(): void
-    {
-        $this->getJson('/api/v1/orders')
-            ->assertUnauthorized();
-    }
-
-    public function test_user_cannot_see_other_users_orders(): void
-    {
-        $order = Order::factory()->create();
-        $otherUser = User::factory()->create();
-
-        $this->actingAs($otherUser)
-            ->getJson("/api/v1/orders/{$order->id}")
-            ->assertForbidden();
-    }
-}
-```
-
-### Testing JSON Structure
-
-Use `assertJsonStructure` for shape, `assertJsonPath` for specific values,
-and `assertJsonFragment` for partial matches.
-
-```php
-$response->assertJsonStructure([
-    'data' => [
-        'id',
-        'customer' => ['id', 'name'],
-        'items' => [
-            '*' => ['id', 'product_name', 'quantity'],
-        ],
-    ],
-]);
-
-$response->assertJsonPath('data.customer.name', 'Alice');
-```
-
-## Testing Queue Jobs
-
-### Faking the Queue
-
-```php
-use Illuminate\Support\Facades\Queue;
-
-public function test_store_dispatches_payment_job(): void
-{
-    Queue::fake();
-
-    $order = Order::factory()->create();
-    $user = $order->customer->user;
-
-    $this->actingAs($user)
-        ->postJson("/api/v1/orders/{$order->id}/pay")
-        ->assertAccepted();
-
-    Queue::assertPushed(ProcessPayment::class, function ($job) use ($order) {
-        return $job->order->id === $order->id;
-    });
-
-    Queue::assertPushedOn('payments', ProcessPayment::class);
-}
-```
-
-### Testing Job Execution
-
-Test the job's `handle` method directly, mocking external dependencies.
-
-```php
-public function test_process_payment_charges_customer(): void
-{
-    $order = Order::factory()->create(['status' => 'processing']);
-
-    $gateway = $this->mock(PaymentGateway::class);
-    $gateway->shouldReceive('charge')
-        ->once()
-        ->with(
-            Mockery::on(fn ($args) => $args['amount'] === $order->total_cents),
-        )
-        ->andReturn(new PaymentResult(transactionId: 'txn_123'));
-
-    (new ProcessPayment($order))->handle($gateway);
-
-    $order->refresh();
-    $this->assertEquals('paid', $order->status);
-    $this->assertEquals('txn_123', $order->payment_reference);
-}
-```
-
-## Testing Events
-
-```php
-use Illuminate\Support\Facades\Event;
-
-public function test_payment_fires_completed_event(): void
-{
-    Event::fake([PaymentCompleted::class]);
-
-    // ... trigger payment ...
-
-    Event::assertDispatched(PaymentCompleted::class, function ($event) use ($order) {
-        return $event->order->id === $order->id;
-    });
-}
-
-public function test_listener_sends_receipt(): void
-{
-    Notification::fake();
-
-    $event = new PaymentCompleted(Order::factory()->paid()->create());
-    (new SendPaymentReceipt())->handle($event);
-
-    Notification::assertSentTo(
-        $event->order->customer,
-        PaymentReceiptNotification::class,
-    );
-}
-```
-
-## Factories
-
-### Relationship Factories
-
-```php
-// Create an order with a specific customer
-$customer = Customer::factory()->create(['name' => 'Alice']);
-$order = Order::factory()->for($customer)->create();
-
-// Create with nested relationships
-$order = Order::factory()
-    ->has(OrderItem::factory()->count(3), 'items')
-    ->create();
-
-// Shorthand using magic methods
-$order = Order::factory()
-    ->hasItems(3)
-    ->create();
-```
-
-### State Methods
-
-```php
-class OrderFactory extends Factory
-{
-    public function paid(): static
-    {
-        return $this->state([
-            'status' => 'paid',
-            'paid_at' => now(),
-        ]);
-    }
-
-    public function cancelled(): static
-    {
-        return $this->state([
-            'status' => 'cancelled',
-            'cancelled_at' => now(),
-        ]);
-    }
-}
-```
-
-## Mocking External Services
-
-### Using Mock Facades
-
-```php
-Http::fake([
-    'api.stripe.com/*' => Http::response(['id' => 'ch_123'], 200),
-    '*' => Http::response('Not Found', 404),
-]);
-```
-
-### Using Dependency Injection
-
-Prefer binding a mock in the container for services injected via constructor.
-
-```php
-$mock = $this->mock(PaymentGateway::class);
-$mock->shouldReceive('charge')->once()->andReturn($result);
-
-// The controller/job will receive the mock automatically
-```
-
-## Database Testing Strategies
-
-- **`RefreshDatabase`**: Wraps each test in a transaction and rolls back. Fast.
-- **`DatabaseMigrations`**: Runs full migrate/rollback cycle. Slow but accurate.
-- **`LazilyRefreshDatabase`**: Only migrates if the database is dirty. Good for
-  parallel test suites.
-
-### Asserting Database State
-
-```php
-$this->assertDatabaseHas('orders', [
-    'id'     => $order->id,
-    'status' => 'paid',
-]);
-
-$this->assertDatabaseMissing('orders', [
-    'status' => 'pending',
-]);
-
-$this->assertDatabaseCount('order_items', 3);
-
-$this->assertSoftDeleted('orders', ['id' => $order->id]);
-```
-
-## Pest Integration
-
-Laravel supports Pest as an alternative to PHPUnit.
-
-```php
-// tests/Feature/Api/OrderTest.php
-use App\Models\Order;
-use App\Models\User;
-
-test('index returns paginated orders', function () {
-    $user = User::factory()->create();
-    Order::factory()->count(30)->for($user->customer)->create();
-
-    $this->actingAs($user)
-        ->getJson('/api/v1/orders')
-        ->assertOk()
-        ->assertJsonCount(25, 'data');
-});
-```

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/llm-eval/SKILL.md

@@ -1,79 +0,0 @@
----
-name: llm-eval
-description: "Use when designing LLM evaluation suites, writing assertions, building benchmarks, running human evals, implementing automated scoring, or detecting regressions across model or prompt versions."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: Claude Code, Codex, GitHub Copilot
----
-# LLM Eval
-
-## Purpose
-
-Guide the design and execution of rigorous LLM evaluation pipelines. Every instruction ensures that evaluation results are reproducible, assertions are meaningful, scoring is defensible, and regressions are caught before they reach production.
-
-## When to Use
-
-- Designing an evaluation suite for a new LLM-powered feature or chatbot.
-- Writing assertion sets that test functional correctness, safety, and style.
-- Building automated scoring pipelines with LLM-as-judge or deterministic checks.
-- Running human evaluation campaigns with calibrated annotators.
-- Detecting performance regressions after prompt changes, model upgrades, or fine-tuning.
-- Comparing model variants on cost, latency, and quality trade-offs.
-
-## Instructions
-
-1. **Define the evaluation objective before choosing metrics** because a chatbot eval measures different things than a code-generation eval. Misaligned metrics produce misleading pass rates that mask real quality problems.
-
-2. **Separate deterministic assertions from judgmental assertions** because string-match and schema-validation checks are cheap and reproducible, while LLM-as-judge or human ratings introduce variance that must be tracked separately.
-
-3. **Write at least five assertions per eval case** because single-assertion tests create a false sense of confidence. Multiple orthogonal assertions catch partial successes that a single check would miss.
-
-4. **Include negative test cases that should be refused or handled gracefully** because models that pass every positive case may still fail on adversarial, ambiguous, or out-of-scope inputs. Negative cases test guardrails.
-
-5. **Pin the model version, temperature, and system prompt in every eval run** because uncontrolled variables make results non-reproducible. A passing eval that cannot be repeated is evidence of nothing.
-
-6. **Use stratified sampling when building eval datasets** because biased distributions (e.g., 90% easy cases) inflate accuracy. Strata should cover difficulty levels, input lengths, edge cases, and domain segments.
-
-7. **Design LLM-as-judge prompts with explicit rubrics and scoring anchors** because vague judge instructions produce high inter-run variance. Anchored rubrics (score 1 = wrong, 3 = partial, 5 = perfect with reasoning) reduce drift.
-
-8. **Calibrate human evaluators with a shared golden set before production annotation** because uncalibrated raters disagree on subjective dimensions. Golden-set calibration aligns raters and reveals dimension ambiguity early.
-
-9. **Compute inter-annotator agreement (Cohen's kappa or Krippendorff's alpha) for every human eval** because raw average scores hide disagreement. Low agreement signals that the rubric or task definition needs revision, not that evaluators are wrong.
-
-10. **Automate regression detection by comparing current run scores against a baseline snapshot** because manual eyeballing of score tables misses slow degradation. Automated thresholds (e.g., >2% drop triggers alert) enforce discipline.
-
-11. **Store every eval run as an immutable artifact with inputs, outputs, scores, and metadata** because post-hoc debugging requires the exact conditions of the run. Overwriting previous results destroys regression evidence.
-
-12. **Report confidence intervals, not just point estimates** because a 92% pass rate from 25 samples has a wide confidence interval that could include 80%. Sample size determines how much the result can be trusted.
-
-13. **Test latency and cost alongside quality** because a prompt change that improves quality by 3% but doubles latency may be a net negative in production. Eval suites must capture operational metrics.
-
-14. **Version-control eval datasets and assertion definitions alongside code** because eval drift (silent changes to test cases) makes historical comparisons meaningless. Eval code is production code.
-
-15. **Run evals in CI on every prompt or model change** because manual eval runs get skipped under deadline pressure. Automated gates prevent regressions from reaching deployment.
-
-16. **Review eval coverage quarterly and retire stale cases** because product features evolve and old test cases may no longer exercise relevant behavior. Stale evals waste compute and create false confidence.
-
-## Output Format
-
-Provide eval suite designs as structured JSON or YAML with assertion definitions, scoring rubrics as numbered tables, regression reports as before/after comparisons with statistical significance, and implementation code for scoring pipelines.
-
-## References
-
-| File | Load when |
-| --- | --- |
-| `references/eval-frameworks.md` | Choosing or configuring an eval framework (OpenAI Evals, Braintrust, Promptfoo, custom). |
-| `references/assertion-patterns.md` | Writing deterministic and judgmental assertions for LLM outputs. |
-| `references/scoring-methods.md` | Implementing LLM-as-judge, rubric-based scoring, or composite metrics. |
-| `references/regression-detection.md` | Setting up automated regression detection, baselines, and alerting. |
-| `references/human-eval.md` | Designing human evaluation campaigns, calibration, and agreement metrics. |
-
-## Copilot Platform Notes
-
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
-- User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
-- Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/llm-eval/agents/benchmark-runner.md

@@ -1,63 +0,0 @@
-# Benchmark Runner Agent
-
-## Role
-
-You are a benchmark execution specialist. Your job is to take a designed eval suite, execute it against one or more model configurations, collect results, compute metrics, and produce a regression-aware report.
-
-## When to Invoke
-
-- An eval suite is ready and needs to be executed against a model endpoint.
-- A prompt or model change requires a before/after comparison.
-- A scheduled regression run needs execution and reporting.
-- A model migration needs a side-by-side benchmark across providers.
-
-## Operating Procedure
-
-1. **Validate the eval suite before execution.** Check that every test case has a name, input, and at least 3 assertions. Reject malformed suites with specific error messages rather than running partial evals.
-
-2. **Lock the execution environment.** Record the model ID, API version, temperature, max tokens, system prompt hash, and timestamp. Store these in the run metadata so the result is reproducible.
-
-3. **Execute test cases with controlled concurrency.** Run cases in parallel where the API allows, but respect rate limits. Log each request/response pair with latency and token counts.
-
-4. **Evaluate deterministic assertions first.** Run contains, regex, JSON schema, and not-contains checks before invoking any LLM-as-judge. Deterministic failures are cheaper to detect and often indicate fundamental breakage.
-
-5. **Evaluate judgmental assertions with the judge model.** Use the configured judge model and rubric. Run each judgmental assertion 3 times and take the median to reduce variance.
-
-6. **Compute per-case and aggregate metrics.** For each test case: pass/fail on deterministic checks, mean judge score, latency p50/p95/p99, token count. For the suite: overall pass rate, mean quality score, cost estimate.
-
-7. **Compare against baseline if available.** Load the previous run's snapshot and compute deltas. Flag any metric that degrades beyond the configured threshold (default: 2% for pass rate, 0.3 for mean judge score).
-
-8. **Generate the regression report.** Produce a structured report with: summary verdict (PASS/REGRESS/IMPROVE), per-case breakdown, flagged regressions with before/after values, and recommended actions.
-
-9. **Archive the run artifact.** Store the complete run (inputs, outputs, scores, metadata) as an immutable JSON artifact. Never overwrite previous runs.
-
-## Output Format
-
-```
-## Benchmark Report
-
-**Run ID:** <uuid>
-**Model:** <model-id> | **Temperature:** <temp> | **Date:** <iso-date>
-**Verdict:** PASS | REGRESS | IMPROVE
-
-### Summary
-| Metric | Current | Baseline | Delta |
-|--------|---------|----------|-------|
-| Pass Rate | 94% | 96% | -2% |
-| Mean Judge Score | 4.2 | 4.1 | +0.1 |
-| Latency p95 | 1.8s | 1.6s | +0.2s |
-| Est. Cost/run | $0.42 | $0.38 | +$0.04 |
-
-### Flagged Regressions
-- Case "edge-case-refusal": deterministic assertion #3 failed (was passing).
-
-### Per-Case Breakdown
-[detailed table]
-```
-
-## Constraints
-
-- Never execute an eval suite without locked environment metadata.
-- Never report point estimates without sample size context.
-- Never overwrite or mutate a previous run's archived artifact.
-- Always flag regressions explicitly even if the overall pass rate is acceptable.