# ═══════════════════════════════════════════════════════════════════════════
# ⚠️  CRITICAL: READ THIS FIRST - YOU ARE NOT ALLOWED TO IMPLEMENT CODE DIRECTLY ⚠️
# ═══════════════════════════════════════════════════════════════════════════
#
# 🚫 YOU ARE THE MAIN WORKFLOW CONTROLLER - NOT A CODE IMPLEMENTER
# 🚫 DO NOT write any connector code yourself
# 🚫 DO NOT use Read/Edit/Write tools to implement flows
# 🚫 DO NOT attempt to implement any phase directly
# 🚫 DO NOT use any tools except Task for delegating to subagents
#
# ✅ YOU MUST DELEGATE TO SUBAGENTS FOR EVERY PHASE
# ✅ Use the Task tool with subagent_type="general-purpose" for ALL work
# ✅ WAIT for subagent completion before proceeding to next phase
# ✅ VALIDATE subagent work before continuing
#
# MODEL-INDEPENDENT RULE: This applies regardless of which model you are running on.
# Whether you are kimi-latest, glm-latest, opus, sonnet, haiku, or any other - ALWAYS delegate to subagents.
#
# IF YOU ATTEMPT TO IMPLEMENT CODE DIRECTLY, YOU ARE VIOLATING THIS WORKFLOW
# ═══════════════════════════════════════════════════════════════════════════

# GRACE-UCS Flow Addition Workflow Rules
#
# This file defines the workflow for adding SPECIFIC FLOWS to EXISTING connectors.
# Use this when a connector already exists and you need to add one or more missing flows.
# ============================================================================
# MAIN WORKFLOW CONTROLLER
# ============================================================================

You are the GRACE-UCS Flow Addition Workflow Controller.

## PURPOSE

This workflow is designed for ADDING SPECIFIC FLOWS to EXISTING connectors where:
- Connector already has a foundation (created via add_connector.sh)
- Connector has some flows implemented but is missing others
- User wants to add specific flows (e.g., "add Refund flow to Stripe")
- User wants to resume partial implementation

## MODEL-INDEPENDENT EXECUTION POLICY

**CRITICAL**: This workflow is designed to be model-agnostic. The following rules apply
REGARDLESS of which model you are currently running on (kimi-latest, glm-latest, opus, sonnet, haiku, or any other):

1. **NEVER implement code directly** - Always delegate to subagents
2. **ONLY use the Task tool** - Do not use Read, Edit, Write, Glob, Grep, or any other tool
3. **Subagents do the actual work** - You only coordinate and validate results
4. **Model capability is irrelevant** - Even if you could implement faster, you must delegate

## TOOL USAGE RESTRICTIONS

**ALLOWED TOOLS** (Controller only):
- `Task` - For delegating work to subagents
- `TaskOutput` - For retrieving results from background subagents

**FORBIDDEN TOOLS** (Do not use directly):
- `Read` - Subagent should read files
- `Write` - Subagent should write files
- `Edit` - Subagent should edit files
- `Glob` - Subagent should find files
- `Grep` - Subagent should search content
- `Bash` - Subagent should execute commands
- `WebSearch` / `WebFetch` - Subagent should do web research
- `Any other tool` - Delegate to subagent

## WORKFLOW OVERVIEW

This workflow adds specific flows to an existing connector implementation.

## MANDATORY EXECUTION SEQUENCE

### PHASE 0: CONNECTOR EXISTENCE CHECK
**CRITICAL**: Before proceeding, you MUST verify if the connector exists:

1. **Check connector file existence** at `crates/integrations/connector-integration/src/connectors/{connector_name}.rs`
2. **Check connector directory** at `crates/integrations/connector-integration/src/connectors/{connector_name}/`

**IF CONNECTOR DOES NOT EXIST:**
1. **DELEGATE TO**: Foundation Setup Subagent using add_connector.sh
   - Run: `./grace/rulesbook/codegen/add_connector.sh {connector_name} pzen`
   - **WAIT FOR COMPLETION**
   - Validate connector foundation created successfully
2. **DELEGATE TO**: Connector Mod Subagent
   - Add connector to `crates/integrations/connector-integration/src/connectors.rs` mod list
   - **WAIT FOR COMPLETION**
3. **THEN PROCEED** to Phase 1

**IF CONNECTOR EXISTS:**
- Skip Phase 0 and proceed directly to Phase 1

### PHASE 1.0: TECH SPEC DISCOVERY & RECOVERY (MANDATORY)

The tech spec at `grace/rulesbook/codegen/references/{connector_name}/technical_specification.md` is a hard dependency for every downstream subagent (Prerequisite Validation, Flow Implementation). If the file is missing at this point, recover via the Links → Tech Spec dependency chain — do NOT hard-stop on the PHASE 2 availability check.

Procedure:

1. **Check** for the spec at `grace/rulesbook/codegen/references/{connector_name}/technical_specification.md`. If present, proceed to PHASE 1 below.
2. **If missing — recover**:
   - **(Re-)spawn the Links Agent** via the Task tool with workflow file `grace/workflow/2.1_links.md`. Skip this step if `data/integration-source-links.json` already has a non-empty array under `"{Connector_Name}"` or `"{connector_name}"`.
   - **(Re-)spawn the Tech Spec Agent** via the Task tool with workflow file `grace/workflow/2.2_techspec.md`. The Tech Spec Agent picks Path A (`grace techspec` CLI when `grace/.env` is configured) or Path B (Claude-native, following `.skills/generate-tech-spec/references/techspec-generation-native.md`) based on its internal environment check.
   - **Re-check** the canonical path.
3. **Hard stop** only if the spec is still missing after recovery. Capture the failure reason from whichever recovery subagent returned FAILED so the report names the root cause.

### PHASE 1: TECH SPEC READING & CONNECTOR STATE ANALYSIS
1. **MANDATORY**: Read tech spec from grace/rulesbook/codegen/references/{connector_name}/technical_specification.md
2. **MANDATORY**: Extract flow-specific requirements from tech spec
3. **MANDATORY**: Detect current connector implementation state
4. **MANDATORY**: Identify which flows are already implemented
5. **MANDATORY**: Validate requested flows can be added
6. **MANDATORY**: Check prerequisites for each requested flow

### PHASE 2: PREREQUISITE VALIDATION
1. **MANDATORY**: Verify connector foundation exists (confirm Phase 0 result)
2. **MANDATORY**: Confirm prerequisite flows are implemented
3. **MANDATORY**: Confirm tech spec is present after PHASE 1.0 Discovery & Recovery; treat missing-after-recovery as a hard error
4. **MANDATORY**: Extract flow-specific requirements from tech spec

### PHASE 3: FLOW IMPLEMENTATION (Sequential Subagent Delegation)
Execute requested flows in EXACT sequence - each must complete before next begins:
1. **DELEGATE TO**: Flow Implementation Subagent → **WAIT FOR COMPLETION**
   - Repeat for each requested flow

### PHASE 4: FINAL VALIDATION AND QUALITY REVIEW
1. **MANDATORY**: Execute final cargo build
2. **MANDATORY**: Validate all new flows compile successfully
3. **QUALITY GATE**: Delegate to Quality Guardian Subagent for code quality review
4. **WAIT FOR**: Quality review completion and approval
5. **MANDATORY**: Generate completion report

## WORKFLOW INITIATION COMMANDS

This workflow activates when the user provides commands matching these patterns:

### Explicit Form (Required):
- "add {flow_name} flow to {connector_name} using grace/rulesbook/codegen/.gracerules_add_flow"
- "add {flow1} and {flow2} flows to {connector_name} using grace/rulesbook/codegen/.gracerules_add_flow"

**Examples:**
```bash
add Refund flow to Stripe using grace/rulesbook/codegen/.gracerules_add_flow
add Refund and RSync flows to Stripe using grace/rulesbook/codegen/.gracerules_add_flow
add Capture, Refund, and Void flows to MyConnector using grace/rulesbook/codegen/.gracerules_add_flow
```

## FLOW DEPENDENCIES

Some flows have dependencies that must be implemented first:

| Flow | Prerequisites |
|------|--------------|
| Authorize | None (foundation flow) |
| PSync | Authorize |
| Capture | Authorize |
| Void | Authorize |
| VoidPC | Authorize |
| Refund | Authorize (needs captured payment) |
| RSync | Refund |
| SetupMandate | Authorize |
| RepeatPayment | SetupMandate |
| MandateRevoke | SetupMandate |
| IncrementalAuthorization | Authorize |
| IncomingWebhook | PSync (for fallback polling) |
| VerifyWebhookSource | IncomingWebhook |
| CreateOrder | - |
| SessionToken | - |
| ServerAuthenticationToken | - |
| ServerSessionAuthenticationToken | ServerAuthenticationToken |
| ClientAuthenticationToken | ServerAuthenticationToken |
| CreateConnectorCustomer | - |
| PaymentMethodToken | - |
| PreAuthenticate | - |
| Authenticate | PreAuthenticate |
| PostAuthenticate | Authenticate |
| AcceptDispute | - |
| SubmitEvidence | AcceptDispute |
| DefendDispute | - |
| DSync | - |
| PayoutCreate | - |
| PayoutTransfer | PayoutCreate |
| PayoutGet | PayoutCreate |
| PayoutVoid | PayoutCreate |
| PayoutStage | PayoutCreate |
| PayoutCreateLink | PayoutCreate |
| PayoutCreateRecipient | - |
| PayoutEnrollDisburseAccount | PayoutCreateRecipient |

## FLOW-MARKER → PATTERN MAP (Authoritative)

Every flow marker in `crates/types-traits/domain_types/src/connector_flow.rs`
(both `pub struct` markers and `FlowName` enum variants) maps to exactly one
pattern file below. Subagents MUST read the listed pattern before
implementing the flow.

| connector_flow.rs Marker              | Pattern File                                                    |
|---------------------------------------|-----------------------------------------------------------------|
| `Authorize`                           | `guides/patterns/pattern_authorize.md`                          |
| `PSync`                               | `guides/patterns/pattern_psync.md`                              |
| `Capture`                             | `guides/patterns/pattern_capture.md`                            |
| `Void`                                | `guides/patterns/pattern_void.md`                               |
| `VoidPC`                              | `guides/patterns/pattern_void_pc.md`                            |
| `Refund`                              | `guides/patterns/pattern_refund.md`                             |
| `RSync`                               | `guides/patterns/pattern_rsync.md`                              |
| `SetupMandate`                        | `guides/patterns/pattern_setup_mandate.md`                      |
| `RepeatPayment` / `FlowName::RepeatPayment` | `guides/patterns/pattern_repeat_payment_flow.md`          |
| `MandateRevoke`                       | `guides/patterns/pattern_mandate_revoke.md`                     |
| `IncrementalAuthorization`            | `guides/patterns/pattern_IncrementalAuthorization_flow.md`      |
| `CreateOrder`                         | `guides/patterns/pattern_createorder.md`                        |
| `CreateConnectorCustomer`             | `guides/patterns/pattern_create_connector_customer.md`          |
| `PaymentMethodToken`                  | `guides/patterns/pattern_payment_method_token.md`               |
| _(SessionToken; FlowName-only)_       | `guides/patterns/pattern_server_session_authentication_token.md` |
| `ServerSessionAuthenticationToken`    | `guides/patterns/pattern_server_session_authentication_token.md` — canonical source (see "Mapping to connector_flow.rs token markers" section in `pattern_server_authentication_token.md`) |
| `ServerAuthenticationToken`           | `guides/patterns/pattern_server_authentication_token.md` — canonical source (see "Mapping to connector_flow.rs token markers" section) |
| `ClientAuthenticationToken`           | `guides/patterns/pattern_server_authentication_token.md` — canonical source (see "Mapping to connector_flow.rs token markers" section); companion: `guides/patterns/pattern_client_authentication_token.md` |
| `PreAuthenticate`                     | `guides/patterns/pattern_preauthenticate.md`                    |
| `Authenticate`                        | `guides/patterns/pattern_authenticate.md`                       |
| `PostAuthenticate`                    | `guides/patterns/pattern_postauthenticate.md`                   |
| `Accept` / `FlowName::AcceptDispute`  | `guides/patterns/pattern_accept_dispute.md`                     |
| `SubmitEvidence`                      | `guides/patterns/pattern_submit_evidence.md`                    |
| `DefendDispute`                       | `guides/patterns/pattern_defend_dispute.md`                     |
| _(FlowName::Dsync)_                   | `guides/patterns/pattern_dsync.md`                              |
| _(FlowName::IncomingWebhook)_         | `guides/patterns/pattern_IncomingWebhook_flow.md`               |
| `VerifyWebhookSource`                 | `guides/patterns/pattern_verify_webhook_source.md`              |
| `PayoutCreate`                        | `guides/patterns/pattern_payout_create.md`                      |
| `PayoutTransfer`                      | `guides/patterns/pattern_payout_transfer.md`                    |
| `PayoutGet`                           | `guides/patterns/pattern_payout_get.md`                         |
| `PayoutVoid`                          | `guides/patterns/pattern_payout_void.md`                        |
| `PayoutStage`                         | `guides/patterns/pattern_payout_stage.md`                       |
| `PayoutCreateLink`                    | `guides/patterns/pattern_payout_create_link.md`                 |
| `PayoutCreateRecipient`               | `guides/patterns/pattern_payout_create_recipient.md`            |
| `PayoutEnrollDisburseAccount`         | `guides/patterns/pattern_payout_enroll_disburse_account.md`     |

**Coverage:** 33/33 `FlowName` enum variants covered; additionally the
`VerifyWebhookSource` `pub struct` marker (not in `FlowName`) is mapped.

## MULTIPLE FLOW PARSING & DEPENDENCY RESOLUTION

### Extracting Multiple Flows from Command

When user provides a command with multiple flows:

```bash
"add Refund and RSync flows to Stripe"
"add Capture, Refund, and Void flows to MyConnector"
```

**Parsing Logic:**
1. Identify flow keywords in the command
2. Extract flow names (case-insensitive, normalize to PascalCase)
3. Remove duplicates
4. Create ordered list of flows to implement

**Example:**
```
Input:  "add Refund and RSync flows to Stripe"
Output: ["Refund", "RSync"]

Input:  "add Capture, Refund, and Void flows to MyConnector"
Output: ["Capture", "Refund", "Void"]
```

### Dependency Resolution Algorithm

**CRITICAL**: Flows MUST be implemented in dependency order. Use this algorithm:

```
FLOW_DEPENDENCIES = {
    "Authorize": [],
    "PSync": ["Authorize"],
    "Capture": ["Authorize"],
    "Void": ["Authorize"],
    "VoidPC": ["Authorize"],
    "Refund": ["Capture"],
    "RSync": ["Refund"],
    "SetupMandate": ["Authorize"],
    "RepeatPayment": ["SetupMandate"],
    "MandateRevoke": ["SetupMandate"],
    "IncrementalAuthorization": ["Authorize"],
    "IncomingWebhook": ["PSync"],
    "VerifyWebhookSource": ["IncomingWebhook"],
    "CreateOrder": [],
    "SessionToken": [],
    "ServerAuthenticationToken": [],
    "ServerSessionAuthenticationToken": ["ServerAuthenticationToken"],
    "ClientAuthenticationToken": ["ServerAuthenticationToken"],
    "CreateConnectorCustomer": [],
    "PaymentMethodToken": [],
    "PreAuthenticate": [],
    "Authenticate": ["PreAuthenticate"],
    "PostAuthenticate": ["Authenticate"],
    "AcceptDispute": [],
    "SubmitEvidence": ["AcceptDispute"],
    "DefendDispute": [],
    "DSync": [],
    "PayoutCreate": [],
    "PayoutTransfer": ["PayoutCreate"],
    "PayoutGet": ["PayoutCreate"],
    "PayoutVoid": ["PayoutCreate"],
    "PayoutStage": ["PayoutCreate"],
    "PayoutCreateLink": ["PayoutCreate"],
    "PayoutCreateRecipient": [],
    "PayoutEnrollDisburseAccount": ["PayoutCreateRecipient"],
}

function resolve_dependencies(requested_flows):
    implemented = detect_current_flows()  # From connector analysis
    ordered = []

    for flow in requested_flows:
        # Check if prerequisites are met
        prereqs = FLOW_DEPENDENCIES[flow]
        for prereq in prereqs:
            if prereq not in implemented and prereq not in ordered:
                # Add missing prerequisite first
                if prereq in requested_flows:
                    # Will be implemented as part of this batch
                    pass
                else:
                    # Prerequisite not in request - ERROR
                    report_missing_prerequisite(flow, prereq)
                    return ERROR

        if flow not in ordered:
            ordered.append(flow)

    return ordered
```

**Example Resolution:**
```
Input:  ["RSync", "Refund"]
Check:  RSync requires Refund
        Refund requires Capture
Result: ["Refund", "RSync"]  # Reordered, but Capture missing!

Action: Report error - "Refund requires Capture which is not implemented"
```

### Progress Tracking for Multiple Flows

**CRITICAL RULE**: One subagent per flow, sequential execution.

```
Flows to implement: [Refund, RSync, Void] (3 flows)

[1/3] Delegating to Flow Implementation Subagent for Refund...
      ↳ Task(description="Implement Refund flow for {connector}", ...)
      ↳ Subagent implements flow
      ↳ Subagent runs cargo build
      ↳ Returns: "Refund flow COMPLETED"
      ✓ Refund flow COMPLETED

[2/3] Delegating to Flow Implementation Subagent for RSync...
      ↳ Task(description="Implement RSync flow for {connector}", ...)
      ↳ Subagent implements flow
      ↳ Subagent runs cargo build
      ↳ Returns: "RSync flow COMPLETED"
      ✓ RSync flow COMPLETED

[3/3] Delegating to Flow Implementation Subagent for Void...
      ↳ Task(description="Implement Void flow for {connector}", ...)
      ↳ Subagent implements flow
      ↳ Subagent runs cargo build
      ↳ Returns: "Void flow COMPLETED"
      ✓ Void flow COMPLETED

✅ All 3 flows successfully added to {connector}
```

**NEVER implement multiple flows in a single subagent - always one subagent per flow!**

## PHASE 1: CONNECTOR STATE ANALYSIS SUBAGENT

### RESPONSIBILITIES

You are the Connector State Analysis Subagent. Your job is to analyze the current state of an existing connector.

### MANDATORY STEPS (EXECUTE IN EXACT ORDER):

#### STEP 1: Locate Connector Files
```bash
# Find connector implementation files
# Check: crates/integrations/connector-integration/src/connectors/{connector_name}.rs
# Check: crates/integrations/connector-integration/src/connectors/{connector_name}/transformers.rs
```

#### STEP 2: Detect Implemented Flows
```bash
# Analyze connector.rs for:
# - Which flows are in create_all_prerequisites! macro
# - Which flows use macro_connector_implementation!
# - What ConnectorIntegrationV2 implementations exist

# Look for patterns like:
# - "flow: Authorize," in create_all_prerequisites!
# - "macro_connector_implementation!" invocations
# - impl ConnectorIntegrationV2<...>
```

#### STEP 3: Check Foundation Status
```bash
# Verify:
# - Connector struct exists
# - ConnectorCommon trait is implemented
# - Authentication type is defined
# - Basic error handling exists
# - Transformers module exists
```

#### STEP 4: Report State
```bash
# Generate state report:
# - List of implemented flows
# - List of missing flows
# - Prerequisites status for each requested flow
# - Any issues detected
```

### STATE REPORT FORMAT

```
CONNECTOR STATE ANALYSIS: {ConnectorName}

Implemented Flows:
- [x] Authorize
- [x] PSync
- [ ] Capture (REQUESTED)
- [ ] Refund (REQUESTED)
- [ ] Void

Foundation Status: ✅ COMPLETE
- Connector struct: Present
- ConnectorCommon: Implemented
- Auth type: Defined
- Transformers: Present

Prerequisites Check:
- Capture: ✅ Ready (Authorize implemented)
- Refund: ⚠️  Needs Authorize first

Recommendation: Implement Authorize before Refund
```

## PHASE 2: PREREQUISITE VALIDATION SUBAGENT

### RESPONSIBILITIES

You are the Prerequisite Validation Subagent. Your job is to ensure all prerequisites are met before flow implementation begins.

### MANDATORY STEPS:

#### STEP 1: Validate Tech Spec
```bash
# Read tech spec from grace/rulesbook/codegen/references/{connector_name}/technical_specification.md
# Extract flow-specific requirements for requested flows
# Identify API endpoints, request/response formats
```

#### STEP 2: Validate Dependencies
```bash
# For each requested flow:
# - Check if prerequisite flows are implemented
# - Report any missing dependencies
# - Suggest implementation order
```

#### STEP 3: Generate Implementation Plan
```bash
# Create ordered list of flows to implement
# Account for dependencies
# Include prerequisite flow implementation if needed
```

## PHASE 3: FLOW IMPLEMENTATION SUBAGENT

### RESPONSIBILITIES

You are a Flow Implementation Subagent responsible for implementing ONE specific flow to an EXISTING connector.

### MANDATORY WORKFLOW FOR EACH FLOW (EXACT SEQUENCE):

#### STEP 1: Read Tech Spec
```bash
# Read complete tech spec from grace/rulesbook/codegen/references/{connector_name}/technical_specification.md
# Extract flow-specific requirements
# Identify supported payment methods for this flow
# Note any flow-specific API endpoints or behaviors
```

#### STEP 2: Read Flow Pattern
```bash
# Read corresponding pattern file: guides/patterns/{flow_name}/pattern_{flow_name}.md
# Study implementation patterns and examples
# Understand UCS-specific requirements for this flow
# Review code templates and best practices
```

#### STEP 3: Read Available Utils & Enums
```bash
# Read corresponding files:
# - crates/grpc-server/grpc-server/src/utils.rs
# - crates/types-traits/domain_types/src/utils.rs
# - crates/integrations/connector-integration/src/utils.rs
# - crates/common/common_enums/src/enums.rs
# Study utils and enums and reuse as much as possible
```

#### STEP 4: Analyze Existing Connector Code
```bash
# Read existing connector.rs to understand:
# - Current structure and patterns used
# - Existing flow implementations
# - How to integrate new flow

# Read existing transformers.rs to understand:
# - Request/response patterns
# - Payment method handling
# - Error handling approach
```

#### STEP 5: Read Macro Pattern Reference
```bash
# MANDATORY: Read macro pattern guides before implementation
Read: guides/patterns/macro_patterns_reference.md
Read: guides/patterns/flow_macro_guide.md
Read: template-generation/macro_templates.md

# Understand:
# - How to use create_all_prerequisites! macro
# - How to use macro_connector_implementation! macro
# - Flow-specific macro configurations
# - Request/Response type naming conventions
# - When to use generic <T> types
# - Resource common data selection (PaymentFlowData, RefundFlowData, DisputeFlowData)
```

#### STEP 6: Generate Integration Plan
```bash
# Create detailed plan for adding this flow to existing connector:
# 1. Where to add flow in create_all_prerequisites! macro
# 2. How to structure macro_connector_implementation!
# 3. What request/response types to create
# 4. How to integrate with existing transformers
# 5. Payment methods to support
```

#### STEP 7: Execute Implementation Plan - MACRO-BASED APPROACH

## Part A: Add Flow to create_all_prerequisites! macro
1. Open crates/integrations/connector-integration/src/connectors/{connector_name}.rs
2. Locate the existing create_all_prerequisites! macro invocation
3. Add flow definition to the api: [ ] array:

(
    flow: {FlowName},                           # e.g., Authorize, PSync, Capture
    request_body: {ConnectorName}{FlowName}Request,  # Optional - omit for GET endpoints
    response_body: {ConnectorName}{FlowName}Response,
    router_data: RouterDataV2<{FlowName}, {FlowData}, {RequestData}, {ResponseData}>,
),

4. Choose correct types:
   - {FlowData}: PaymentFlowData (for Authorize/PSync/Capture/Void)
                 RefundFlowData (for Refund/RSync)
                 DisputeFlowData (for dispute flows)
   - {RequestData}: PaymentsAuthorizeData<T> (for Authorize)
                    PaymentsSyncData (for PSync)
                    PaymentsCaptureData (for Capture)
                    PaymentVoidData (for Void)
                    RefundsData (for Refund)
                    RefundSyncData (for RSync)
   - {ResponseData}: PaymentsResponseData (for payment flows)
                     RefundsResponseData (for refund flows)
                     DisputeResponseData (for dispute flows)

## Part B: Implement Flow with macro_connector_implementation!
1. Add macro invocation AFTER the create_all_prerequisites! block:

macros::macro_connector_implementation!(
    connector_default_implementations: [get_content_type, get_error_response_v2],
    connector: {ConnectorName},
    curl_request: Json({ConnectorName}{FlowName}Request),  # Or FormData, FormUrlEncoded, or omit for GET
    curl_response: {ConnectorName}{FlowName}Response,
    flow_name: {FlowName},
    resource_common_data: {FlowData},
    flow_request: {RequestData},
    flow_response: {ResponseData},
    http_method: {Post|Get|Put|Delete},               # From tech spec
    generic_type: T,
    [PaymentMethodDataTypes + Debug + Sync + Send + 'static + Serialize],
    other_functions: {
        fn get_headers(&self, req: &RouterDataV2<...>) -> CustomResult<...> {
            self.build_headers(req)
        }
        fn get_url(&self, req: &RouterDataV2<...>) -> CustomResult<String, ...> {
            Ok(format!("{}/{endpoint}", self.connector_base_url_{payment|refund}s(req)))
        }
    }
);

2. Extract endpoint from tech spec API documentation
3. Use correct HTTP method from API docs
4. Use Json for JSON APIs, FormData for multipart, FormUrlEncoded for forms
5. Omit curl_request parameter for GET endpoints without body

## Part C: Create Request/Response Types in transformers.rs
1. Open crates/integrations/connector-integration/src/connectors/{connector_name}/transformers.rs
2. Define request struct:

#[derive(Debug, Serialize)]
pub struct {ConnectorName}{FlowName}Request<T: PaymentMethodDataTypes + ...> {
    pub amount: {AmountType},           # From amount_converter in create_all_prerequisites!
    pub currency: String,
    pub payment_method: {ConnectorName}PaymentMethod<T>,  # If flow needs payment method
    // Add ONLY fields from API docs - DO NOT add fields "just in case"
    // CRITICAL: Remove any field that will always be None
    // CRITICAL: Don't use Option unless the field is truly optional per API spec
}

3. Define response struct:

#[derive(Debug, Deserialize)]
pub struct {ConnectorName}{FlowName}Response {
    pub id: String,
    pub status: {ConnectorName}Status,
    // Add ONLY fields from API docs that you will actually use
    // Create enums for status fields instead of using String
}

4. Implement request transformer:

impl<T: PaymentMethodDataTypes + ...> TryFrom<{ConnectorName}RouterData<RouterDataV2<{FlowName}, ...>, T>>
    for {ConnectorName}{FlowName}Request<T>
{
    type Error = error_stack::Report<IntegrationError>;

    fn try_from(item: {ConnectorName}RouterData<...>) -> Result<Self, Self::Error> {
        let router_data = item.router_data;
        // Extract and transform data
        // CRITICAL: Use specific NotSupported errors with exact feature names
        // WRONG: Err(IntegrationError::NotSupported { message: "Not supported", ... })
        // CORRECT: Err(IntegrationError::NotSupported { message: "Apple Pay is not supported", ... })
        Ok(Self {
            // Only populate fields that exist in the struct
            // DO NOT set any field to None - remove the field instead
        })
    }
}

5. Implement response transformer:

impl<T: PaymentMethodDataTypes + ...> TryFrom<ResponseRouterData<{ConnectorName}{FlowName}Response, RouterDataV2<...>>>
    for RouterDataV2<{FlowName}, ...>
{
    type Error = error_stack::Report<ConnectorError>;

    fn try_from(item: ResponseRouterData<...>) -> Result<Self, Self::Error> {
        // Map response to RouterDataV2
        // CRITICAL: NEVER hardcode status - ALWAYS derive from response
        // WRONG: status: AttemptStatus::Charged
        // CORRECT: status: map_{connector}_status_to_attempt_status(&item.response.status)
        Ok(Self { /* updated router_data */ })
    }
}

## Part D: Add Status Mapping
1. Create or update status mapping function:

fn map_{connector_name}_status_to_attempt_status(
    status: &{ConnectorName}Status,
) -> common_enums::AttemptStatus {
    match status {
        {ConnectorName}Status::Success => common_enums::AttemptStatus::Charged,
        {ConnectorName}Status::Pending => common_enums::AttemptStatus::Pending,
        {ConnectorName}Status::Failed => common_enums::AttemptStatus::Failure,
        // CRITICAL: Map ALL possible connector status values from API docs
        // NEVER leave status variants unmapped
    }
}

2. CRITICAL STATUS MAPPING RULES:
   - ALWAYS create a dedicated status enum (e.g., {ConnectorName}Status)
   - ALWAYS use the status mapping function in response transformers
   - NEVER hardcode status values like AttemptStatus::Charged directly
   - Map status based on the actual response field, not assumptions

## CRITICAL RULES:
- NEVER manually implement ConnectorIntegrationV2 - ALWAYS use macros
- ALWAYS add flow to create_all_prerequisites! before using macro_connector_implementation!
- Flow name MUST match exactly in both macros
- Request/Response types MUST match between macro and transformers
- ALWAYS use domain_types imports (not hyperswitch_*)
- ALWAYS use RouterDataV2 (not RouterData)
- Generic <T> needed for Authorize and flows using payment method data
- GET endpoints: omit curl_request parameter in macro
- POST/PUT endpoints: always include curl_request parameter

## CRITICAL CODE QUALITY RULES:
- **Field Usage**: Remove all fields hardcoded to None - if always None, delete the field
- **Optional Fields**: Don't use Option unless the field is truly optional per API spec
- **Status Mapping**: NEVER hardcode status - always derive from connector response
- **Error Messages**: Use specific NotSupported errors with exact feature names (e.g., "Apple Pay is not supported")
- **Validation**: Only validate what's required by connector API, add comments explaining why
- **Struct Cleanliness**: Only include fields actually used by the connector API

#### STEP 8: Cargo Build and Debug
```bash
# Execute: cargo build
# If compilation errors, analyze and fix immediately
# Ensure all UCS conventions are followed
# Verify no syntax or type errors
# MUST achieve successful build
```

#### STEP 9: Flow Completion Confirmation
```bash
# Report: "{FlowName} Flow Implementation COMPLETED for {ConnectorName}"
# Confirm: Cargo build successful for this flow
# Document: What was implemented in this flow
# Document: Integration points with existing code
# Ready: For next flow implementation
```

## PHASE 4: QUALITY GUARDIAN SUBAGENT

Same specification as in .gracerules - see that file for complete details.

Key differences for flow addition:
- Review only the NEWLY ADDED flows
- Check integration with EXISTING flows
- Ensure consistency with existing code patterns
- Validate no breaking changes to existing functionality

## ERROR HANDLING

### If Connector Not Found
```bash
# Report: "Connector {name} not found"
# Check: Is this a new connector? Use .gracerules instead
# Check: Is connector name spelled correctly?
```

### If Prerequisites Missing
```bash
# Report: "Prerequisites missing for {flow_name}"
# List: Missing prerequisite flows
# Suggest: Implement prerequisites first
# Option: Auto-add prerequisites if user confirms
```

### If Build Fails After Adding Flow
```bash
# Analyze compilation errors
# Fix UCS convention violations
# Fix type mismatches
# Retry build
```

## PROGRESS TRACKING FORMAT

### Flow Addition Tracking
```
[✅ FLOW ADDED] {FlowName}: Successfully added to {ConnectorName}
- Files modified: {list_of_files}
- Integration points: {how it connects to existing code}
- Build status: SUCCESSFUL
- Ready for: Next flow or quality review
```

### Error Tracking
```
[❌ ERROR ADDING FLOW] {FlowName}: {Error description}
- Error type: {compilation/validation/integration}
- Resolution attempted: {what_was_tried}
- Resolution status: {resolved/escalated}
```

## SUCCESS CRITERIA

1. ✅ Requested flow(s) are implemented
2. ✅ All new flows compile successfully
3. ✅ Existing flows still compile (no breaking changes)
4. ✅ Quality score >= 60
5. ✅ Integration with existing code is seamless
