Run Resolver Tutorial#

This tutorial covers the scafctl run resolver command — a debugging and inspection tool for executing resolvers without running actions. You’ll learn how to run all resolvers, target specific resolvers, inspect execution metadata, skip phases, and visualize dependencies.

Prerequisites#

scafctl installed and available in your PATH
Familiarity with resolvers
A solution file with defined resolvers

A note on __execution metadata: When using JSON or YAML output, run resolver automatically includes an __execution key containing execution metadata (timing, dependency graph, provider stats). Throughout this tutorial, examples use --hide-execution to keep output focused on resolver values. See Execution Metadata for details on this feature.

Run All Resolvers#

The simplest usage runs all resolvers in a solution file.

Step 1: Create a Solution File#

Create a file called demo.yaml:

apiVersion: scafctl.io/v1
kind: Solution
metadata:
  name: resolver-demo
  version: 1.0.0
spec:
  resolvers:
    environment:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value: production
    region:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value: us-west-2
    app_name:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value: my-app

Step 2: Run All Resolvers#

Bash

scafctl run resolver -f demo.yaml --hide-execution

PowerShell

scafctl run resolver -f demo.yaml --hide-execution

Output:

KEY          VALUE
───────────────────────
app_name     my-app
environment  production
region       us-west-2

Step 3: Get JSON Output#

Bash

scafctl run resolver -f demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver -f demo.yaml -o json --hide-execution

Output:

{
  "app_name": "my-app",
  "environment": "production",
  "region": "us-west-2"
}

Tip: Unlike run solution, this command never executes actions — it’s safe for inspection.

Run Specific Resolvers#

Pass resolver names as positional arguments to execute only those resolvers (plus their transitive dependencies).

Step 1: Run a Single Resolver#

Bash

scafctl run resolver environment -f demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver environment -f demo.yaml -o json --hide-execution

Output:

{
  "environment": "production"
}

Step 2: Run Multiple Resolvers#

Bash

scafctl run resolver environment region -f demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver environment region -f demo.yaml -o json --hide-execution

Output:

{
  "environment": "production",
  "region": "us-west-2"
}

Step 3: Dependencies Are Included Automatically#

Create a file called dep-demo.yaml with a solution that has dependencies:

apiVersion: scafctl.io/v1
kind: Solution
metadata:
  name: dep-demo
  version: 1.0.0
spec:
  resolvers:
    base_url:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value: https://api.example.com
    endpoint:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value:
                rslvr: base_url
      transform:
        with:
          - provider: cel
            inputs:
              expression: "__self + '/v2/data'"
    unrelated:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value: not-needed

Running just endpoint automatically includes base_url (its dependency):

Bash

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

Output:

{
  "base_url": "https://api.example.com",
  "endpoint": "https://api.example.com/v2/data"
}

Note that base_url is included (it’s a dependency of endpoint) but unrelated is not.

Step 4: Handle Unknown Resolver Names#

If you request a resolver that doesn’t exist, you get a clear error:

Bash

scafctl run resolver nonexistent -f demo.yaml

PowerShell

scafctl run resolver nonexistent -f demo.yaml

Output:

 ❌ unknown resolver(s): nonexistent (available: app_name, environment, region)

Execution Metadata#

By default, run resolver includes a __execution key in the output alongside the resolver values. The __execution key is a structured object with named sections, designed to be extensible for future additions (e.g. timeline). Use --hide-execution to suppress it when you only need the resolved values.

Bash

scafctl run resolver -f dep-demo.yaml -o json

PowerShell

scafctl run resolver -f dep-demo.yaml -o json

Current sections:

resolvers: Per-resolver metadata including phase, duration, status, provider, dependencies, and phase metrics (resolve/transform/validate breakdown)
summary: Aggregate stats — total duration, resolver count, phase count
dependencyGraph: Full dependency graph with nodes, edges, phases, stats, and pre-rendered diagrams (ASCII, DOT, Mermaid)
providerSummary: Per-provider usage statistics (resolver count, total duration, call count, success/failure counts, average duration)

Example JSON output:

{
  "base_url": "https://api.example.com",
  "endpoint": "https://api.example.com/v2/data",
  "unrelated": "not-needed",
  "__execution": {
    "resolvers": {
      "base_url": {
        "phase": 1,
        "duration": "2ms",
        "status": "success",
        "provider": "static",
        "dependencies": [],
        "providerCallCount": 1,
        "valueSizeBytes": 26,
        "dependencyCount": 0
      },
      "endpoint": {
        "phase": 2,
        "duration": "3ms",
        "status": "success",
        "provider": "static",
        "dependencies": ["base_url"],
        "providerCallCount": 1,
        "valueSizeBytes": 38,
        "dependencyCount": 1,
        "phaseMetrics": [
          { "phase": "resolve", "duration": "2ms" },
          { "phase": "validate", "duration": "1ms" }
        ]
      }
    },
    "summary": {
      "totalDuration": "5ms",
      "resolverCount": 3,
      "phaseCount": 2
    }
  }
}

Combine with Named Resolvers#

Bash

scafctl run resolver endpoint -f dep-demo.yaml -o json

PowerShell

scafctl run resolver endpoint -f dep-demo.yaml -o json

The __execution section only includes metadata for the requested resolvers and their dependencies.

Tip: Use --hide-execution to suppress __execution when you only need the resolved values. For run solution, execution metadata is opt-in via --show-execution.

Skipping Phases#

Resolvers execute through three ordered phases: resolve → transform → validate. You can skip phases to inspect intermediate values — particularly useful when validation blocks output and you need to see what was actually resolved.

Create a file called phases-demo.yaml. This example resolves a port number, transforms it by adding 8000, then validates the result is within the valid port range. The input value of 60000 is intentionally too high — after the transform, the result (68000) exceeds the valid range:

apiVersion: scafctl.io/v1
kind: Solution
metadata:
  name: phases-demo
  version: 1.0.0
spec:
  resolvers:
    port:
      type: int
      resolve:
        with:
          - provider: static
            inputs:
              value: 60000
      transform:
        with:
          - provider: cel
            inputs:
              expression: "__self + 8000"
      validate:
        with:
          - provider: validation
            inputs:
              expression: "__self >= 1024 && __self <= 65535"
              message: "Port must be between 1024 and 65535"

Running the resolver fails because the transformed value (68000) exceeds the valid port range:

Bash

scafctl run resolver -f phases-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver -f phases-demo.yaml -o json --hide-execution

Output:

❌ resolver execution failed: ... validation: Port must be between 1024 and 65535

The validation error blocks the output entirely — you can’t see the resolved value.

Skip Validation#

Use --skip-validation to bypass the validation phase and see the actual value:

Bash

scafctl run resolver --skip-validation -f phases-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver --skip-validation -f phases-demo.yaml -o json --hide-execution

Output:

{
  "port": 68000
}

Now you can see the problem: the transform added 8000 to 60000, producing 68000 which exceeds the valid port range. Without --skip-validation, this value would be hidden behind the error.

Skip Transform (and Validation)#

Use --skip-transform to see the raw resolved value before any transformations:

Bash

scafctl run resolver --skip-transform -f phases-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver --skip-transform -f phases-demo.yaml -o json --hide-execution

Output:

{
  "port": 60000
}

This reveals the provider returned 60000 — confirming the root cause is the input value, not the transform logic.

Note: --skip-transform implies --skip-validation because validating a pre-transform value is misleading — validation rules are written against the expected final shape.

Dependency Graph#

The --graph flag renders the resolver dependency graph without executing any providers. This is useful for understanding the structure and execution order of your resolvers.

ASCII Graph (default)#

Bash

scafctl run resolver --graph -f dep-demo.yaml

PowerShell

scafctl run resolver --graph -f dep-demo.yaml

Output:

Resolver Dependency Graph:

Phase 1:
  - unrelated
  - base_url

Phase 2:
  - endpoint
    depends on:
      * base_url

Statistics:
  Total Resolvers: 3
  Total Phases: 2
  Max Parallelism: 2
  Avg Dependencies: 0.33

Graphviz DOT Format#

Prerequisite: Requires Graphviz (dot command) to be installed.

Generate DOT output and pipe it to Graphviz for a visual diagram:

Bash

scafctl run resolver --graph --graph-format=dot -f dep-demo.yaml | dot -Tpng > graph.png

PowerShell

scafctl run resolver --graph --graph-format=dot -f dep-demo.yaml | dot -Tpng -o graph.png

Mermaid Format#

Generate a Mermaid diagram for embedding in Markdown or documentation:

Bash

scafctl run resolver --graph --graph-format=mermaid -f dep-demo.yaml

PowerShell

scafctl run resolver --graph --graph-format=mermaid -f dep-demo.yaml

JSON Format#

Get the graph as structured JSON for programmatic analysis:

Bash

scafctl run resolver --graph --graph-format=json -f dep-demo.yaml | jq .

PowerShell

scafctl run resolver --graph --graph-format=json -f dep-demo.yaml | ConvertFrom-Json

Bash users: The above command uses jq , a command-line JSON processor. Install it separately if not already available.

The JSON output includes:

nodes: List of resolvers with name, type, phase, provider, and conditional flag
edges: Dependency relationships (from → to with dependency type)
phases: Phase groups showing which resolvers execute together
stats: Graph metrics including total resolvers, phases, edges, max depth, and critical path

Critical Path#

The graph stats include a critical path — the longest chain of dependencies that determines the minimum sequential execution depth. This helps identify bottlenecks:

Bash

scafctl run resolver --graph --graph-format=json -f dep-demo.yaml -e '_.stats.criticalPath'

PowerShell

scafctl run resolver --graph --graph-format=json -f dep-demo.yaml -e '_.stats.criticalPath'

Graph in Execution Metadata#

When running resolvers normally, the dependency graph and a provider usage summary are automatically embedded in __execution:

Bash

scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph'
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.providerSummary'

PowerShell

scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph'
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.providerSummary'

The providerSummary shows per-provider statistics: resolver count, total duration, call count, success/failure counts, and average duration.

Extracting Diagrams from Execution Metadata#

The dependencyGraph in __execution includes a diagrams field with pre-rendered ASCII, DOT, and Mermaid representations. Use the -e flag (CEL expression) to extract a specific diagram:

Prerequisite: The DOT diagram commands below require Graphviz to be installed.

Bash

# Extract the Mermaid diagram
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.mermaid'

# Extract the DOT diagram and render with Graphviz
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.dot' | dot -Tpng > graph.png

# Extract the ASCII diagram
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.ascii'

PowerShell

# Extract the Mermaid diagram
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.mermaid'

# Extract the DOT diagram and render with Graphviz
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.dot' | dot -Tpng -o graph.png

# Extract the ASCII diagram
scafctl run resolver -f dep-demo.yaml -o json -e '_.__execution.dependencyGraph.diagrams.ascii'

You can also extract diagrams when running only specific resolvers:

Bash

# Get the Mermaid diagram for just endpoint and unrelated (and their deps)
scafctl run resolver endpoint unrelated -f dep-demo.yaml -o json \
  -e '_.__execution.dependencyGraph.diagrams.mermaid'

PowerShell

scafctl run resolver endpoint unrelated -f dep-demo.yaml -o json `
  -e '_.__execution.dependencyGraph.diagrams.mermaid'

This is useful for generating focused dependency visualizations of a resolver subset without rendering the full solution graph.

--graph is mutually exclusive with --snapshot.

Snapshots#

The --snapshot flag executes resolvers and saves the complete execution state to a JSON file. This mirrors the snapshot functionality in scafctl render solution --snapshot.

Basic Snapshot#

Bash

scafctl run resolver --snapshot --snapshot-file=snapshot.json -f demo.yaml

PowerShell

scafctl run resolver --snapshot --snapshot-file=snapshot.json -f demo.yaml

This creates a snapshot file containing:

metadata: Solution name, version, build version, timestamp, total duration, and execution status
resolvers: Complete execution state of each resolver including resolved values, durations, and provider information
parameters: Input parameters used during execution

Redacting Sensitive Values#

Use --redact to replace sensitive resolver values with <redacted>:

Bash

scafctl run resolver --snapshot --snapshot-file=snapshot.json --redact -f demo.yaml

PowerShell

scafctl run resolver --snapshot --snapshot-file=snapshot.json --redact -f demo.yaml

Resolvers marked with sensitive: true will have their values replaced in the snapshot.

Snapshot Use Cases#

Debugging: Capture a full execution trace for offline analysis
Auditing: Record resolver outputs for compliance
Testing: Compare snapshots between runs to detect regressions
Support: Redacted snapshots can be shared without exposing secrets

--snapshot requires --snapshot-file to be specified. It is mutually exclusive with --graph.

Output Formats#

The command supports all standard output formats:

Bash

# Table (default) — human-readable bordered table
scafctl run resolver -f demo.yaml --hide-execution

# JSON — for scripting and piping
scafctl run resolver -f demo.yaml -o json --hide-execution

# YAML — for configuration contexts
scafctl run resolver -f demo.yaml -o yaml --hide-execution

# Quiet — suppress output (useful for exit code checks)
scafctl run resolver -f demo.yaml -o quiet

# Interactive TUI — explore and search results
scafctl run resolver -f demo.yaml -i

# CEL expression filtering
scafctl run resolver -f demo.yaml -e '_.environment'

PowerShell

# Table (default) — human-readable bordered table
scafctl run resolver -f demo.yaml --hide-execution

# JSON — for scripting and piping
scafctl run resolver -f demo.yaml -o json --hide-execution

# YAML — for configuration contexts
scafctl run resolver -f demo.yaml -o yaml --hide-execution

# Quiet — suppress output (useful for exit code checks)
scafctl run resolver -f demo.yaml -o quiet

# Interactive TUI — explore and search results
scafctl run resolver -f demo.yaml -i

# CEL expression filtering
scafctl run resolver -f demo.yaml -e '_.environment'

Working Directory Override#

Use the --cwd (or -C) global flag to run commands as if you were in a different directory. This is useful when scripting or when your solution files live in a different location:

Bash

# Run resolvers from a solution in another directory
scafctl --cwd /path/to/project run resolver -f solution.yaml

# Short form (similar to git -C)
scafctl -C /path/to/project run resolver -f solution.yaml

# Combine with other flags
scafctl -C /path/to/project run resolver -f solution.yaml -o json

PowerShell

# Run resolvers from a solution in another directory
scafctl --cwd /path/to/project run resolver -f solution.yaml

# Short form (similar to git -C)
scafctl -C /path/to/project run resolver -f solution.yaml

# Combine with other flags
scafctl -C /path/to/project run resolver -f solution.yaml -o json

All relative paths (including -f, --output-dir, etc.) are resolved against the specified working directory instead of the current directory.

Debugging Dependencies#

A common debugging workflow is to inspect how resolver dependencies cascade.

Step 1: Visualize the Graph#

Bash

scafctl run resolver --graph -f dep-demo.yaml

PowerShell

scafctl run resolver --graph -f dep-demo.yaml

Step 2: Run Target Resolver#

Bash

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

Step 3: Inspect a Single Resolver’s Value#

Bash

scafctl run resolver base_url -f dep-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver base_url -f dep-demo.yaml -o json --hide-execution

This lets you progressively narrow down which resolver is producing unexpected output.

Working with Parameters#

Parameters can be passed in two equivalent ways:

Positional key=value (recommended) — after resolver names or on their own
Explicit -r flag — repeatable flag for each parameter

Both forms can be mixed freely.

Bash

# Positional key=value syntax (recommended)
scafctl run resolver -f parameterized.yaml env=staging

# Load parameters from file (positional)
scafctl run resolver -f parameterized.yaml @params.yaml

# Load parameters from stdin (pipe YAML or JSON)
echo '{"env": "prod"}' | scafctl run resolver -f parameterized.yaml @-

# Pipe parameters from another command
cat params.yaml | scafctl run resolver -f parameterized.yaml -r @-

# Pipe raw stdin into a single parameter
echo hello | scafctl run resolver -f parameterized.yaml message=@-

# Read a file's raw content into a parameter
scafctl run resolver -f parameterized.yaml body=@content.txt

# Multiple positional parameters
scafctl run resolver -f parameterized.yaml env=prod region=us-east1

# Mix resolver names and parameters — bare words are names, key=value are params
scafctl run resolver db auth -f parameterized.yaml env=prod

# Explicit -r flag (still supported)
scafctl run resolver -f parameterized.yaml -r env=staging

# Load parameters from file with -r
scafctl run resolver -f parameterized.yaml -r @params.yaml

# Mix both forms (-r values and positional values are combined)
scafctl run resolver -f parameterized.yaml -r env=prod region=us-east1

PowerShell

# Positional key=value syntax (recommended)
scafctl run resolver -f parameterized.yaml env=staging

# Load parameters from file — wrap @file in single quotes to avoid splatting operator
scafctl run resolver -f parameterized.yaml '@params.yaml'

# Load parameters from stdin (pipe YAML or JSON)
'{"env": "prod"}' | scafctl run resolver -f parameterized.yaml '@-'

# Pipe parameters from another command
Get-Content params.yaml | scafctl run resolver -f parameterized.yaml -r '@-'

# Pipe raw stdin into a single parameter
'hello' | scafctl run resolver -f parameterized.yaml 'message=@-'

# Read a file's raw content into a parameter
scafctl run resolver -f parameterized.yaml 'body=@content.txt'

# Multiple positional parameters
scafctl run resolver -f parameterized.yaml env=prod region=us-east1

# Mix resolver names and parameters
scafctl run resolver db auth -f parameterized.yaml env=prod

# Explicit -r flag (still supported)
scafctl run resolver -f parameterized.yaml -r env=staging

# Load parameters from file with -r
scafctl run resolver -f parameterized.yaml -r '@params.yaml'

# Mix both forms
scafctl run resolver -f parameterized.yaml -r env=prod region=us-east1

Dynamic Help Text#

When you specify a solution file with --help, the command shows the solution’s resolver parameters alongside the standard help text:

Bash

scafctl run resolver -f param-demo.yaml --help

PowerShell

scafctl run resolver -f param-demo.yaml --help

This appends a table showing which resolvers accept CLI parameters, their types, and descriptions — making it easy to discover what inputs a solution expects without reading the YAML file.

Example with Parameter Provider#

Create a file called param-demo.yaml:

apiVersion: scafctl.io/v1
kind: Solution
metadata:
  name: param-demo
  version: 1.0.0
spec:
  resolvers:
    env:
      type: string
      resolve:
        with:
          - provider: parameter
            inputs:
              key: environment
    config_url:
      type: string
      resolve:
        with:
          - provider: static
            inputs:
              value:
                rslvr: env
      transform:
        with:
          - provider: cel
            inputs:
              expression: "'https://config.' + __self + '.example.com'"

Bash

scafctl run resolver -f param-demo.yaml environment=staging -o json --hide-execution

PowerShell

scafctl run resolver -f param-demo.yaml environment=staging -o json --hide-execution

Output:

{
  "config_url": "https://config.staging.example.com",
  "env": "staging"
}

Parameter Key Validation#

Parameter keys are validated against the solution’s parameter-type resolver names. Unknown keys are rejected early with a helpful error message that suggests the closest valid key when a typo is detected:

Bash

# Typo: "envronment" instead of "environment"
scafctl run resolver -f param-demo.yaml envronment=staging
# Error: solution does not accept input "envronment" — did you mean "environment"?

# Completely unknown key
scafctl run resolver -f param-demo.yaml unknown=value
# Error: solution does not accept input "unknown" (valid inputs: environment)

PowerShell

# Typo: "envronment" instead of "environment"
scafctl run resolver -f param-demo.yaml envronment=staging
# Error: solution does not accept input "envronment" — did you mean "environment"?

# Completely unknown key
scafctl run resolver -f param-demo.yaml unknown=value
# Error: solution does not accept input "unknown" (valid inputs: environment)

Common Workflows#

CI/CD Validation#

Check that all resolvers succeed without running actions:

Bash

scafctl run resolver -f demo.yaml -o quiet
echo "Exit code: $?"

PowerShell

scafctl run resolver -f demo.yaml -o quiet
Write-Output "Exit code: $LASTEXITCODE"

Partial Execution for Debugging#

Isolate a failing resolver and its dependencies:

Bash

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver endpoint -f dep-demo.yaml -o json --hide-execution

Inspect Raw Resolved Values#

Skip transforms to see what providers actually return:

Bash

scafctl run resolver --skip-transform -f dep-demo.yaml -o json --hide-execution

PowerShell

scafctl run resolver --skip-transform -f dep-demo.yaml -o json --hide-execution

Preview Execution Plan#

Use --graph to see the resolver execution plan without running anything:

Bash

scafctl run resolver --graph -f dep-demo.yaml

PowerShell

scafctl run resolver --graph -f dep-demo.yaml

Comparing Resolver Outputs#

Bash

# Get current values
scafctl run resolver -f param-demo.yaml -r environment=production -o json --hide-execution > current.json

# Change parameters and compare
scafctl run resolver -f param-demo.yaml -r environment=staging -o json --hide-execution > staging.json
diff current.json staging.json

PowerShell

# Get current values
scafctl run resolver -f param-demo.yaml -r environment=production -o json --hide-execution > current.json

# Change parameters and compare
scafctl run resolver -f param-demo.yaml -r environment=staging -o json --hide-execution > staging.json
diff current.json staging.json

Show Execution Metrics#

Bash

scafctl run resolver -f demo.yaml --show-metrics -o json

PowerShell

scafctl run resolver -f demo.yaml --show-metrics -o json

Metrics are displayed on stderr after execution completes.

What’s Next?#

Resolver Tutorial — Learn resolver fundamentals
Actions Tutorial — Execute actions after resolvers
CEL Tutorial — Filter and transform resolver output
Snapshots Tutorial — Deeper dive into snapshot analysis

Quick Reference#

Bash

# All resolvers
scafctl run resolver -f solution.yaml --hide-execution

# Named resolvers (with dependencies)
scafctl run resolver db config -f solution.yaml --hide-execution

# JSON output (includes __execution metadata by default)
scafctl run resolver -f solution.yaml -o json

# JSON output without __execution metadata
scafctl run resolver -f solution.yaml -o json --hide-execution

# Skip transform and validation phases
scafctl run resolver --skip-transform -f solution.yaml

# Dependency graph (ASCII)
scafctl run resolver --graph -f solution.yaml

# Dependency graph (DOT/Mermaid/JSON)
scafctl run resolver --graph --graph-format=dot -f solution.yaml
scafctl run resolver --graph --graph-format=mermaid -f solution.yaml
scafctl run resolver --graph --graph-format=json -f solution.yaml

# Snapshot execution state
scafctl run resolver --snapshot --snapshot-file=out.json -f solution.yaml

# Snapshot with sensitive value redaction
scafctl run resolver --snapshot --snapshot-file=out.json --redact -f solution.yaml

# With parameters
scafctl run resolver -f solution.yaml -r key=value

# Interactive exploration
scafctl run resolver -f solution.yaml -i

# Aliases: res, resolvers
scafctl run res -f solution.yaml

PowerShell

# All resolvers
scafctl run resolver -f solution.yaml --hide-execution

# Named resolvers (with dependencies)
scafctl run resolver db config -f solution.yaml --hide-execution

# JSON output (includes __execution metadata by default)
scafctl run resolver -f solution.yaml -o json

# JSON output without __execution metadata
scafctl run resolver -f solution.yaml -o json --hide-execution

# Skip transform and validation phases
scafctl run resolver --skip-transform -f solution.yaml

# Dependency graph (ASCII)
scafctl run resolver --graph -f solution.yaml

# Dependency graph (DOT/Mermaid/JSON)
scafctl run resolver --graph --graph-format=dot -f solution.yaml
scafctl run resolver --graph --graph-format=mermaid -f solution.yaml
scafctl run resolver --graph --graph-format=json -f solution.yaml

# Snapshot execution state
scafctl run resolver --snapshot --snapshot-file=out.json -f solution.yaml

# Snapshot with sensitive value redaction
scafctl run resolver --snapshot --snapshot-file=out.json --redact -f solution.yaml

# With parameters
scafctl run resolver -f solution.yaml -r key=value

# Interactive exploration
scafctl run resolver -f solution.yaml -i

# Aliases: res, resolvers
scafctl run res -f solution.yaml

Next Steps#

Run Provider Tutorial — Test providers in isolation
Actions Tutorial — Learn about workflows
Resolver Tutorial — Deep dive into resolvers
Provider Reference — Complete provider documentation