---
name: fluent-rfl-assess
description: Run a Ready For Launch (RFL) assessment on a Fluent Commerce implementation. Analyzes workflows, rules, settings, and integrations for production readiness. Triggers on "rfl assessment", "ready for launch check", "go-live readiness", "production audit".
user-invocable: true
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
argument-hint: [--profile name] [--retailer ref]
cursor-tier: auto
---

# RFL Assessment

Comprehensive Ready For Launch assessment for Fluent Commerce implementations.

## When to Use

- Pre-go-live production readiness check
- Post-implementation quality review
- Periodic health check of running implementations
- New team member onboarding (understand current state)

## Assessment Workflow

### Step 1: Environment Discovery

```bash
# Verify connection
fluent profile active

# List workflows
fluent workflow list -p <profile> -r <retailer>

# List installed modules
fluent module list -p <profile>
```

### Step 2: Workflow Analysis

For each workflow:
- Download and parse workflow JSON
- Check naming conventions
- Detect duplicate rulesets
- Identify orphaned rulesets
- Verify state transitions are complete
- Check for cyclic dependencies

### Step 3: Custom Rules Review

- Locate plugin source code under `accounts/<PROFILE>/SOURCE/backend/`
- If source is unavailable:
  - Check for JARs or decompiled output at `accounts/<PROFILE>/SOURCE/backend/.decompiled/`
  - If neither exists, run `/fluent-custom-code <PROFILE>` to decompile available JARs
  - If no JARs are available, run `/fluent-connect` for full workspace preparation including JAR provision guidance
  - Fall back to `plugin.list` for description-level review (rule parameters, accepted entity types, produced events) — note reduced confidence in the report
- Analyze Java code quality (original source = high confidence; decompiled = medium confidence, note synthetic variable names)
- Check GraphQL usage patterns
- Verify error handling
- Assess test coverage (skip if only decompiled source available)

### Step 4: Configuration Audit

- Query settings via GraphQL
- Check user and role setup
- Verify catalogue configuration
- Validate network topology
- Confirm location setup

### Step 5: Generate Report

Output: `rfl-report-<retailer>-<timestamp>.md`

Includes:
- Overall score (0-100)
- Risk matrix
- Findings by category
- Prioritized recommendations
- Go/No-Go recommendation

## Scoring

| Score | Rating | Meaning |
|-------|--------|---------|
| 90-100 | Excellent | Ready for launch |
| 75-89 | Good | Minor issues, safe to launch |
| 60-74 | Fair | Address high-priority items first |
| 40-59 | Poor | Significant work needed |
| 0-39 | Critical | Not ready for launch |

## Common Findings

| Category | Finding | Severity |
|----------|---------|----------|
| Workflow | Orphaned rulesets | Medium |
| Workflow | Missing error handlers | High |
| Rules | No test coverage | High |
| Rules | Hardcoded values | Medium |
| Config | Missing settings | Critical |
| Integration | No retry on webhook failure | High |

## Event Health Assessment

As part of the RFL assessment, check event processing health:

Prerequisites:
- Metrics queries require a user/token with `METRICS_VIEW`.
- Interpret metrics as trend-level observability signals (Prometheus functions may extrapolate around scrape windows), not ledger-accurate financial totals.

### Automated Health Check (Preferred)
```
metrics.healthCheck({
  "window": "168h",
  "topN": 20,
  "thresholds": { "failureRate": 2, "pendingRate": 5 }
})
```
Single call covers failure rate, NO_MATCH, PENDING, and dominance checks. Use stricter thresholds (2% failure) for go-live readiness.

If Prometheus is unavailable, the tool automatically falls back to Event API aggregation.

### Manual Checks (Drill-Down)

Use these for targeted investigation when healthCheck reports findings:

### Failed Events Check
```
event.list({
  "eventStatus": "FAILED",
  "from": "<last_7_days>",
  "count": 50
})
```
Flag: >5% failure rate indicates systemic issues requiring investigation before launch.

### NO_MATCH Events Check
```
event.list({
  "eventStatus": "NO_MATCH",
  "from": "<last_7_days>",
  "count": 50
})
```
Flag: Any NO_MATCH events indicate missing workflow configuration (event name doesn't match any ruleset).

### Exception Events Check
```
event.list({
  "category": "exception",
  "from": "<last_7_days>",
  "count": 50
})
```
Flag: Recurring exceptions with the same `lastRule` or `lastRuleSet` indicate a code-level bug.

### Event Volume Analytics

**Prometheus (preferred):**
```
metrics.query({
  "query": "sum by (event_name, entity_type, status) (increase(rubix_event_runtime_seconds_count[24h]))",
  "type": "instant"
})
```

**Fallback (Event API aggregation):**
```
metrics.topEvents({
  "from": "<last_24h>",
  "topN": 20
})
```
Review top events for unexpected patterns: high failure rates, unusual entity type distribution, missing expected events.

For detailed event diagnostics → `/fluent-trace`.
For monitoring workflows and anomaly detection → `/fluent-system-monitoring`.
