Bb Qa Gate

Mode 3: Learning Loop (post-incident)

After every significant bug, update this skill so the class of bug never escapes again. Read references/learning-loop.md for the update protocol.

The golden rule: An incident cannot be closed until either the QA skill is updated, or the chamber explicitly states why no reusable QA update is warranted.

INPUT ROUTING

Output format: Every run produces one or both of:

1. QA verdict — prioritized test cases, risk matrix, missing edge cases, likely regressions, release recommendation
2. Debug verdict + QA skill improvement delta — root cause, patch plan, verification steps, plus what the deck should learn

CHAMBER ROLES

The debugging chamber uses three models with distinct responsibilities:

Claude (orchestrator)

• Builds and patches the app
• Owns the QA skill deck
• Updates the QA skill when repeated gaps are discovered
• Makes final decisions on root cause, fix, and skill updates

GPT (diagnostician)

• Diagnoses the bug from the incident packet
• Identifies missing QA coverage that allowed the bug through
• Returns structured diagnosis + qa_skill_delta

Gemini (challenger)

• Challenges GPT's diagnosis from a different angle
• Identifies process and test blind spots
• Returns structured rebuttal + qa_skill_delta

When a production bug arrives, Claude runs scripts/chamber.py which handles all 5 phases automatically — calling GPT and Gemini APIs, collecting diagnoses, running rebuttals, and producing the converged verdict. See references/chamber-process.md for the full protocol details.

Quick start: Just tell Claude about the bug. Claude assembles the incident JSON and runs the chamber script. Keys are in .env.chamber.local.

DEBUGGING CHAMBER OUTPUT CONTRACT

Every debugging run produces two artifacts:

Artifact 1: Debug Verdict

{
  "root_cause": "string — what actually broke and why",
  "affected_subsystem": "auth|permissions|api_contract|realtime|react_state|ssr_boundary|graph|ai_pipeline|env_config|regression",
  "severity": "P0|P1|P2|P3",
  "patch_plan": ["step 1", "step 2"],
  "verification_steps": ["how to confirm the fix works"],
  "rollback_needed": false
}

Artifact 2: QA Skill Improvement Delta

{
  "qa_skill_delta": {
    "gap_type": "missing_test|missing_heuristic|missing_regression_rule|missing_architecture_check|unclear_guidance",
    "why_missed": "string — why the current QA deck did not catch this",
    "new_rule": "string — concrete QA guidance to add, written so future runs catch this",
    "new_test_cases": ["string — specific test scenarios to add"],
    "target_section": "§1-§12 or new subsystem bucket",
    "update_priority": "high|medium|low",
    "reusable_for_future": true
  }
}

BUILD PHASE → PLUGIN MAPPING

Each build phase loads ONLY the plugins relevant to its domain. This prevents context pollution and ensures integrators get targeted coverage.

Phase 1: DB/Schema (Migrations, RLS, Triggers, Indexes)

Risk profile: Data integrity, tenant isolation, financial precision Plugins:

• finance:journal-entry-prep — validates double-entry GL patterns in migrations
• finance:reconciliation — checks balance constraints and FK integrity
• finance:audit-support — SOX control testing on financial tables
• data:data-validation — methodology checks on schema design
• data:sql-queries — validates PostgreSQL syntax, index strategy, query performance
• engineering:architecture — ADR review for schema decisions
• legal:compliance-check — NJ DCA, Fair Housing, PCI compliance on data model

FINTECH_ABSOLUTES enforced: ABS-001 (NUMERIC(14,2)), ABS-005 (SERIALIZABLE), ABS-011 (balanced GL), ABS-015 (RLS), ABS-021 (TIMESTAMPTZ), ABS-030 (updated_at trigger), ABS-032 (no hard DELETE)

Phase 2: API/Backend (Route Handlers, RPC Functions, Auth Middleware)

Risk profile: Security, ACID compliance, input validation, error handling Plugins:

• engineering:code-review — security, performance, correctness on route handlers
• engineering:testing-strategy — test plan for API contracts
• data:sql-queries — validates Supabase RPC function SQL
• data:data-validation — verifies API response data accuracy

FINTECH_ABSOLUTES enforced: ABS-004 (RPC procedures), ABS-008 (idempotency), ABS-010 (optimistic locking), ABS-013 (no card data), ABS-016 (SECURITY INVOKER), ABS-018 (PostgREST filters), ABS-027 (no service_role in client), ABS-031 (no SELECT *)

Phase 3: UI/UX (Components, Pages, State Management, Styling)

Risk profile: Accessibility, state bugs, SSR boundary errors, UX quality Plugins:

• design:design-critique — usability, visual hierarchy, consistency review
• design:accessibility-review — WCAG 2.1 AA compliance audit
• design:ux-writing — microcopy, error messages, empty states, CTAs
• design:design-system-management — component consistency, design token compliance
• design:user-research — test plan for user flows
• engineering:code-review — React patterns, hook usage, state management

FINTECH_ABSOLUTES enforced: ABS-002 (no JS financial math), ABS-031 (explicit column selection in stores)

Phase 4: Integration (Graph API, Stripe, ILS, Email/SMS)

Risk profile: OAuth, webhook reliability, partial outage handling Plugins:

• engineering:system-design — integration architecture review
• engineering:incident-response — failure mode analysis for external services
• engineering:testing-strategy — mock provider test strategy
• legal:compliance-check — OAuth scope review, PCI compliance for payment integrations

FINTECH_ABSOLUTES enforced: ABS-013 (PCI tokenization), ABS-014 (payment state machine), ABS-019 (MIME validation on inbound), ABS-027 (key management)

Phase 5: QA/Release (Testing, Regression, Deployment)

Risk profile: Escaped defects, deployment failures, rollback safety Plugins:

• engineering:deploy-checklist — pre-deployment verification
• engineering:testing-strategy — regression test coverage
• engineering:code-review — final PR review
• data:data-validation — production data integrity verification
• finance:audit-support — SOX control verification before financial features ship

FINTECH_ABSOLUTES enforced: ALL 34 rules verified via bb-qa-gate.sh

How Integrators Use This

When an integrator is assigned to a wave, their task prompt specifies their phase:

## PHASE: DB/Schema
Load plugins: finance:journal-entry-prep, data:sql-queries, engineering:architecture
FINTECH checks: ABS-001, ABS-005, ABS-011, ABS-015, ABS-021, ABS-030, ABS-032

The orchestrator includes this in the integrator task package. The integrator reads it in PRE-FLIGHT and loads only the specified plugins.

SUBSYSTEM BUCKETS

Every bug and every QA rule maps into one of these 10 subsystem buckets. This gives the deck a stable structure instead of random growth.

When adding a new rule from a bug, tag it to the correct bucket. If a bug spans multiple buckets, add the rule to the primary bucket and cross-reference the secondary.

SKILL UPDATE POLICY

The learning loop uses tiered auto-updates based on priority:

Convergence filter for skill improvement — do not blindly merge all suggestions from the chamber. Apply these filters:

• Add to the QA skill only if the lesson is reusable (not a one-off)
• Prefer rules tied to architecture BlueBeast actually has
• Avoid adding narrow one-off checks unless the bug class is costly (P0/P1)
• Update the skill in the smallest way that would have caught the issue
• Never add duplicate rules — check existing coverage first

QA PHASE WEIGHTING

The deck covers all three phases, weighted by where bugs most commonly escape:

Pre-merge PR review (weight: 50%)

This is the primary defense. Most bugs should be caught here.

• Automated checks via bb-qa-gate.sh (23+ checks)
• Guide modules §1-§9 applied to PR diffs
• Regression Review §11 on every PR

Staging QA (weight: 30%)

Integration-level issues that only surface in a full environment.

• Feature Test Plan §2 executed manually
• Realtime QA §4 tested with live Supabase
• Graph Integration §9 tested with real OAuth tokens
• Cross-role permission walkthrough

Release gate (weight: 20%)

Final go/no-go before production deploy.

• Release Readiness §1 full checklist
• FINTECH_ABSOLUTES verification
• Release Decision Matrix applied
• Smoke test on critical paths (login, payment, GL balance)

§1 RELEASE READINESS GUIDE

Before any deployment, verify against the full stack:

Next.js 16 Compatibility

• All dynamic route params use Promise<> typed params
• No Record<string, unknown> casts in TSX (use as any)
• No route group conflicts (parallel pages at same path)
• All hook-using pages have 'use client' in first 15 lines
• All JSX→TSX dynamic imports have const X: any = dynamic(... as any)
• middleware.ts warning acknowledged (Next.js 16 deprecation)
• No @ts-expect-error without explanation comment

Supabase

• All new tables have RLS enabled + 4 policies (SELECT/INSERT/UPDATE/DELETE)
• All new tables have audit trigger, soft deletes, metadata JSONB
• No SECURITY DEFINER functions (use SECURITY INVOKER)
• No service_role key in client-side code
• All .from() table names exist in schema
• All checkPermission() module values exist in Module type

Edge Functions

• Excluded from tsconfig.json (supabase/edge-functions in exclude array)
• Use Deno imports (https://esm.sh/, https://deno.land/)
• Environment variables accessed via Deno.env.get()

Graph Integrations

• OAuth tokens refreshed before Graph API calls
• Delegated permissions match required scopes
• Failure handling for 401/403 (token expired, consent revoked)
• Timezone handling on calendar events (UTC ↔ local conversion)

FINTECH_ABSOLUTES (34 rules)

• All money columns NUMERIC(14,2)
• No financial math in JavaScript
• All financial writes through RPC stored procedures
• Idempotency keys on all payment/GL APIs
• version_number on financial records
• GL entries append-only (no UPDATE/DELETE)
• No raw card data anywhere
• Payment state machine enforced at DB level

Release Decision Matrix

§2 FEATURE TEST PLAN GUIDE

Given a feature description, generate:

Happy Path Tests

For each user story, write the expected flow:

GIVEN [precondition]
WHEN [action]
THEN [expected result]
AND [side effects: DB writes, notifications, audit log]

Edge Cases

• Empty/null inputs on every field
• Maximum length strings (255 chars, 10KB text)
• Negative and zero amounts on financial fields
• Concurrent access (two users editing same record)
• Timezone boundary (11:59 PM EST payment = next day UTC?)
• Pagination boundary (page 1 of 1, page beyond last)

Failure Cases

• Network timeout mid-operation (partial write?)
• Auth token expired mid-session
• Supabase rate limit (429)
• Invalid FK reference (deleted parent record)
• RLS denying access (correct behavior — verify error message)

Regression Checks

• Did this feature change any shared component? List all consumers.
• Did this feature add a migration? Check all queries that touch affected tables.
• Did this feature modify a Zustand store? Check all components that subscribe.
• Did this feature touch middleware.ts? Check all protected routes.

Role/Permission Checks

• Staff (view-only) — can they see but not edit?
• Manager — can they edit but not delete?
• Admin — full access confirmed?
• Unauthenticated — redirected to login?
• Wrong org — RLS returns empty, not 403?

§3 DATABASE & AUTH QA GUIDE

Supabase RLS Checklist (per table)

-- Verify RLS is enabled
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';

-- Verify policies exist (need all 4: SELECT, INSERT, UPDATE, DELETE)
SELECT tablename, policyname, cmd FROM pg_policies WHERE schemaname = 'public';

-- Test cross-tenant isolation
-- As User A (org_id = 'aaa'): SELECT * FROM payments; → should only see org_aaa data
-- As User B (org_id = 'bbb'): SELECT * FROM payments; → should only see org_bbb data
-- As Anon (no auth): SELECT * FROM payments; → should return 0 rows

Session Handling

• Login creates valid Supabase session
• Session persists across page navigation
• Token refresh occurs before expiry (not after)
• Expired token → redirect to login (not 500 error)
• Multiple tabs share session state
• Logout invalidates session on all tabs

Azure AD Integration

• SSO login redirects to Azure AD consent screen
• Callback URL matches Supabase Auth config
• User profile + AD groups fetched after login
• Role mapping applies (domain → role, AD group → role)
• Token refresh on Graph API 401
• Revoked consent handled gracefully (not crash)

Tenant/Account Switching

• Switching org clears all cached data (Zustand reset)
• React Query cache invalidated on org switch
• RLS prevents data leakage during switch
• Navigation state resets to dashboard

270+ Table Permission Audit

• For every new table: Does it have RLS? Does it have all 4 policy types?
• For every new API route: Does it call checkPermission()?
• For every new store: Does it scope queries to org_id?

§4 REALTIME QA GUIDE

Subscription Verification

• supabase.channel().on('postgres_changes', ...) fires on INSERT/UPDATE/DELETE
• Subscription is scoped to user's org (not broadcasting all data)
• Unsubscribe on component unmount (no memory leaks)
• Multiple subscriptions on same table don't duplicate events

Duplicate Event Prevention

• Event dedup by ID (same record update doesn't render twice)
• Optimistic update + realtime update don't double-apply
• Race: local save + remote push arrive simultaneously → correct final state

Stale UI Resolution

• Tab backgrounded for 30 min → comes back → data refreshes
• WebSocket disconnects → reconnects → missed events are caught up
• Conflict: local edit + remote edit on same record → user notified

Reconnect Behavior

• Network drop → auto-reconnect within 5 seconds
• Reconnect re-subscribes to all active channels
• No duplicate subscriptions after reconnect

Optimistic Update Reconciliation

• Optimistic state rolls back on server error
• Loading spinner shown until server confirms
• Error toast if server rejects optimistic update

§5 API & CONTRACT QA GUIDE

Input Validation (per route)

• Required fields enforced (400 on missing)
• Type validation (UUID format, numeric ranges, date formats)
• Max length enforcement on text fields
• SQL injection prevention (parameterized queries via Supabase client)
• XSS prevention on user-generated content returned in responses

Auth Enforcement

• Route checks session via supabase.auth.getUser()
• Route calls checkPermission(module, action) for protected operations
• Service_role key used only in server-side code, never exposed to client
• 401 on missing/invalid session, 403 on insufficient permissions

Response Shape Stability

• Success response matches documented schema
• Error response always has { error: string } shape
• Pagination responses include { data, count, page, pageSize }
• No sensitive fields leaked (passwords, tokens, SSN fragments)

Error Handling

• try-catch wraps all async operations
• Database errors return 500 with generic message (not SQL details)
• Validation errors return 400 with field-level messages
• Rate limit returns 429 with retry-after header

Retry/Idempotency

• Financial APIs accept idempotency_key parameter
• Duplicate key returns cached response (not re-process)
• Non-financial APIs are safe to retry (GET is idempotent by design)

Graph API Failure Handling

• 401 → refresh token and retry once
• 403 → log consent issue, return user-friendly error
• 429 → respect retry-after header
• 500/503 → return degraded response, don't crash

§6 FRONTEND STATE QA GUIDE

Zustand + React Query Interactions

• Zustand stores hold UI state only (selected filters, modal state)
• React Query handles all server data (fetching, caching, mutations)
• No duplicate data in both Zustand and React Query
• Mutation success triggers query invalidation (stale data refreshes)

Cache Invalidation

• After mutation: related queries invalidated
• After navigation: stale queries refetched
• After org switch: ALL queries invalidated

Stale Data

• Query staleTime set appropriately (5 min for lists, 30 sec for detail views)
• Background refetch on window focus
• Loading/error states shown during refetch

Race Conditions

• Rapid navigation doesn't cause stale data from previous page
• Multiple concurrent mutations on same entity don't overwrite each other
• Search debounce prevents flood of API calls

Loading/Error States

• Every data-fetching component has loading skeleton
• Every data-fetching component has error state with retry button
• Empty state (no data) is distinct from loading state

Server/Client Boundary

• Server Components don't use hooks (useState, useEffect, etc.)
• Client Components have 'use client' directive
• Data fetched in Server Components passed as props to Client Components

§7 AI PIPELINE QA GUIDE

Prompt Consistency (Claude → ChatGPT → Mistral)

• System prompt is identical across all 3 models
• User prompt includes all required context (GL data, property info)
• Temperature/max_tokens settings are consistent
• Response format (JSON schema) is specified in prompt

Model Fallback Logic

• Primary (Claude) failure → fallback to ChatGPT
• ChatGPT failure → fallback to Mistral
• All models fail → return graceful degradation message
• Fallback logged in ai_pipeline_log table

Result Ranking

• Multiple model responses compared for consistency
• Confidence score calculated
• Disagreement flagged for human review
• Best response selected by defined criteria (not random)

Hallucination Checks

• Financial amounts in response match input data
• GL codes referenced actually exist in chart of accounts
• Date references are within the period being analyzed
• No fabricated vendor names or transaction descriptions

Schema Adherence

• AI response parses to expected JSON schema
• Missing fields have defaults (not null crash)
• Extra fields are ignored (not stored)

Cost/Latency

• Token usage logged per request
• Latency logged per request
• Cost per 1000 requests calculated and within budget
• Timeout set (30 sec) with graceful handling

§8 SECURITY & PRIVACY QA GUIDE

PII Exposure

• API responses don't include SSN, full card numbers, passwords
• Logs don't include PII (request bodies sanitized before logging)
• Error messages don't expose internal DB structure
• Supabase Storage files require signed URLs (no public access)

Prompt Injection Risk

• User input sanitized before inclusion in AI prompts
• AI responses not executed as code
• AI-generated SQL not run directly (always via parameterized Supabase client)

Secrets Leakage

• No secrets in client-side code (grep for SUPABASE_SERVICE_ROLE, API keys)
• .env.local in .gitignore
• No secrets in migration files
• No secrets in error messages or logs

OAuth Scope Misuse

• Only required Graph API scopes requested
• Scope changes require user re-consent
• Tokens stored securely (Supabase Auth, not localStorage)

Cross-User Data Exposure

• RLS prevents User A from seeing User B's data
• API routes scope all queries to user's org_id
• File uploads scoped to user's org storage bucket
• Audit log shows who accessed what data

AI Output Auditability

• Every AI-generated note stored with model, timestamp, prompt hash
• User edits to AI output tracked in ai_edit_history
• AI pipeline decisions logged in ai_pipeline_log

§9 INTEGRATION QA GUIDE (Microsoft Graph)

Delegated OAuth

• Access token refreshed before expiry
• Refresh token stored in Supabase Auth session
• Token exchange uses PKCE flow
• Scopes match: User.Read, Mail.Read, Calendars.Read, Files.Read

Calendar Sync

• Events created with correct timezone (not UTC offset errors)
• Recurring events handled (not duplicated per occurrence)
• Deleted events removed from local cache
• All-day events span correct calendar day

Teams/Email Permissions

• Mail.Send requires separate consent (not assumed)
• Teams channel messages require Group.ReadWrite.All
• Delegated permissions vs. application permissions correct

Revoked Consent

• User revokes consent → next Graph call returns 403
• App handles 403 gracefully (prompt to re-consent, not crash)
• Cached Graph data cleared on consent revocation

Partial API Outages

• Graph API down → app continues without Graph features
• Calendar sync fails → rest of app still works
• Email send fails → queued for retry, user notified

Timezone Mismatches

• User timezone stored in profile
• Calendar events displayed in user's timezone
• Financial timestamps always UTC in DB, local in UI

§10 BUG TRIAGE & REPRODUCTION GUIDE

Bug Report Rewrite Template

**Title:** [One-line description]
**Severity:** P0 (data loss) | P1 (broken feature) | P2 (degraded UX) | P3 (cosmetic)
**Subsystem:** [Auth | Finance | Leasing | Maintenance | AI | Graph | UI]
**Steps to Reproduce:**
1. [exact step]
2. [exact step]
3. [exact step]
**Expected:** [what should happen]
**Actual:** [what actually happens]
**Evidence:** [screenshot, error log, network trace]
**Environment:** [browser, OS, user role, property context]
**First Occurrence:** [date/time]
**Frequency:** [always | intermittent | once]

Evidence to Collect

• Browser console errors (screenshot + copy)
• Network tab (failed requests, response bodies)
• Supabase logs (auth errors, RLS denials)
• Git blame on affected file (recent changes)

Root Cause Isolation

1. Can it be reproduced in a different browser? (Browser-specific?)
2. Can it be reproduced as a different user role? (Permission issue?)
3. Can it be reproduced on a different property? (Data-specific?)
4. Can it be reproduced after clearing cache? (Stale state?)
5. Does the API return correct data? (Frontend vs. backend?)

Severity Assignment

After triage, if P0 or P1: Immediately launch the Debugging Chamber (references/chamber-process.md).

§11 REGRESSION REVIEW GUIDE

Given a PR diff, spec, or release note, generate a regression checklist:

Affected System Analysis

For each changed file, identify:

1. Direct consumers — what components/routes import this file?
2. Indirect consumers — what Zustand stores subscribe to data this file provides?
3. Database impact — does this change affect any migration, RLS policy, or table structure?
4. Auth impact — does this change touch middleware, checkPermission, or role definitions?

Regression Checklist Template

## Regression Checklist for [PR/Feature]

### Changed Files
- [ ] file1.ts — [what changed] — consumers: [list]
- [ ] file2.tsx — [what changed] — consumers: [list]

### Database
- [ ] Migration applied successfully in staging?
- [ ] Rollback tested?
- [ ] RLS policies still protect affected tables?
- [ ] Existing data not corrupted by ALTER TABLE?

### Auth
- [ ] All roles still have correct access?
- [ ] Login flow still works?
- [ ] Permission checks on affected routes verified?

### Financial
- [ ] GL balance integrity maintained?
- [ ] Payment flows still atomic?
- [ ] Idempotency keys still enforced?

### UI
- [ ] Affected pages still render?
- [ ] Loading/error states still work?
- [ ] Mobile responsive on affected pages?

### Integration
- [ ] Graph API calls still work?
- [ ] Realtime subscriptions still fire?
- [ ] AI pipeline still responds?

§12 PRODUCTION INCIDENT QA GUIDE

Incident Response Flow

1. REPRODUCE — Can you trigger the issue on demand?
2. SCOPE — How many users/properties/records affected?
3. BLAST RADIUS — What subsystems are impacted? (Auth? Finance? Realtime?)
4. CONTAIN — Can we stop the bleeding without a full rollback?
5. FIX — Root cause + patch (use Debugging Chamber for P0/P1)
6. VERIFY — Patch deployed, issue confirmed resolved
7. PREVENT — Run the Learning Loop to update this QA skill

Blast Radius Matrix

Post-Incident: Mandatory Skill Update

After resolving any P0/P1 incident, the incident cannot be closed until:

1. The Debugging Chamber has run (references/chamber-process.md)
2. The QA skill improvement delta has been produced
3. The skill has been updated (or a written justification exists for why not)
4. A regression test template has been added to the relevant subsystem bucket

§13 BUG-TO-COVERAGE LEARNING LOOP

This is the self-improvement engine that turns production bugs into QA training data. Read references/learning-loop.md for the full protocol.

Quick Reference

After every significant bug, Claude answers these five questions:

1. What failed in the app?
2. What failed in the QA process?
3. What new QA rule would have prevented this?
4. Where does that rule belong in the deck? (which §, which subsystem bucket)
5. What example test case should be added?

Rule Addition Protocol

• Identify the escaped defect class
• Identify the missing QA signal
• Add one reusable rule (written as a concrete checklist item)
• Add one regression test template (written as a GIVEN/WHEN/THEN)
• Tag the rule by subsystem bucket
• Check for duplicates — never add a rule that overlaps with existing coverage
• Prefer the smallest change that would have caught the issue

AUTOMATED CHECKS (scripts/bb-qa-gate.sh)

The bash script runs 29 automated checks (+ Check 29 in --deep mode). See the script for full implementation.

Standard mode: bash skills/bb-qa-gate/scripts/bb-qa-gate.sh (28 checks, no API calls) Deep mode: bash skills/bb-qa-gate/scripts/bb-qa-gate.sh --deep (28 checks + Anthropic self-simulation on diff)

Current checks:

1. Next.js 16 async route params
2. Record<string, unknown> type casts
3. Route group conflicts
4. Missing npm dependencies
5. FINTECH_ABSOLUTES violations (FLOAT, service_role, card data)
6. Migration RLS coverage
7. Shell script line endings
8. Jest config conflicts
9. Stray temp files
10. Package lock sync
11. ESLint config format
12. Banned npm packages
13. JSONB property access safety
14. Type union completeness
15. Duplicate exports
16. Missing 'use client' directives
17. Next.js 16 compatibility
18. SELECT * violations (ABS-031)
19. JSX→TSX dynamic import safety
20. JSONB .metadata access casting
21. Implicit-any in array callbacks
22. String literal type mismatches (Module, Action)
23. Zustand store type assertion safety
24. Await-inside-param-list syntax errors (from Chamber 2026-03-18)
25. filterForTable table name validation
26. Null vs undefined in optional parameters
27. Archive & changelog drift detection
28. Supabase GenericStringError — untyped .data access without as any[]
29. Deep self-simulation on staged diff (--deep mode only, uses Anthropic API)

Rule: Every CI failure becomes a new automated check. The skill learns from each failure.

Batch fix rule (from Chamber 2026-03-18): After any batch regex fix across multiple files, verify the output parses correctly by checking at least 3 sample files for syntax errors before committing. Never trust regex on function signatures without validating the output.

Build phase plugin loading: Each integrator loads ONLY the plugins relevant to their build phase (DB/Schema, API/Backend, UI/UX, Integration, QA/Release). See BUILD PHASE → PLUGIN MAPPING section above.

ESCAPED DEFECT LOG

This section tracks bugs that escaped to production and the QA rules added in response. It serves as a changelog for the learning loop and helps identify patterns over time.

2026-03-18 — Await inserted inside function parameter list (43 routes)

• Subsystem: ssr_boundary
• Severity: P1 (all 43 dynamic API routes broken — build fails)
• Root cause: Batch regex fix script inserted const params = await paramsPromise; between the last function parameter and the closing ) {, instead of inside the function body after {.
• QA gap: Check 1 verified the type signature was Promise<> but didn't verify the await was syntactically correct. No "verify output parses" step existed for batch fixes.
• Rule added: Check 24 (await-inside-param-list detection). Plus batch fix rule: "After any batch regex fix, verify 3+ sample files parse correctly before committing."
• Chamber run: Manual 5-phase (no API keys configured). Diagnosed by Claude, challenged internally. Convergence: the batch fix workflow needs a dry-run verification step.
• Reusable: yes — applies to any future batch regex modifications of function signatures

INTEGRATION

Referenced by:

1. reference/INTEGRATOR_SKILL.md — §7.1 Pre-flight checklist
2. reference/FINTECH_ABSOLUTES.md — ENFORCEMENT section
3. .github/workflows/ci.yml — architecture validation job
4. templates/ORCHESTRATOR_SKILL_TEMPLATE.md — §3.1a QA skill docs
5. templates/ORCHESTRATOR_DASHBOARD.html — Skills & Templates section

BlueBeast PMS — QA Gate Skill v4.2 29 automated checks + --deep self-simulation + 13 guide modules + debugging chamber (4-tier fallback) + learning loop + build phase→plugin mapping Every CI failure becomes a new check. Every production bug teaches the system.