Command-line tools were designed for humans. When you run a configuration command, you typically get one of two experiences: an interactive wizard that walks you through prompts one at a time, or a strict non-interactive mode that fails with a cryptic error the moment a required option is missing.

Neither works well for AI agents.

Interactive mode traps the agent in a back-and-forth it can't navigate. Non-interactive mode gives it a binary pass/fail with no actionable context — the agent has to guess what went wrong, parse error messages, and retry blindly.

There's a better way.

Progressive Discovery

Progressive Discovery is a response pattern where a CLI tool, upon detecting an AI agent as its caller, returns structured, contextual feedback about what it already has, what it still needs, and how to get it. Instead of prompting or failing, the tool collaborates with the agent.

The key insight: an AI agent operates with partial context. It may already know some configuration values from the user's instructions or from the project it's working in. What it needs from the tool is not a prompt — it needs information to make decisions. The tool's job is to describe what's missing and provide enough context for the agent to either resolve it from what it knows or ask the user an intelligent question.

A Concrete Example: Payment Gateway Configuration

Consider a CLI tool that configures a payment gateway integration — something like setting up a Stripe or Bluefin connection for a merchant application.

The Human Experience

A human runs the setup command and gets a familiar interactive flow:

$ paytool configure
Welcome to PayTool configuration.
? Select environment: (Use arrow keys)
❯ sandbox
  production
? Enter your Merchant ID: ___
? Enter your API Key: ___
? Select default currency: (Use arrow keys)
❯ USD
  EUR
  GBP
? Enable webhook notifications? (Y/n): ___
? Webhook endpoint URL: ___
✓ Configuration saved to .paytool/config.json

This works for a human sitting at a terminal. But what happens when an AI agent needs to set this up?

The Agent Experience Today

Most tools offer a --no-interactive flag. The agent tries to supply everything upfront:

$ paytool configure --no-interactive --merchant-id "MCH_12345"

Error: Missing required option: --api-key

The agent retries, guessing at what else might be needed:

$ paytool configure --no-interactive --merchant-id "MCH_12345" --api-key "sk_test_xxx"

Error: Missing required option: --environment

And again. And again. Each round trip is a wasted call — no context, no guidance, just failure.

The Progressive Discovery Experience

With Progressive Discovery, the same tool detects the agent and shifts its behavior:

$ paytool configure --agent --merchant-id "MCH_12345"

# Configuration: incomplete
## Resolved
- **merchant_id**: `MCH_12345` (provided)
## Pending
### environment (required)
Deployment target. Use `sandbox` for testing, `production` for live transactions.
If this is a development or staging setup, use `sandbox`.

```json
{"field": "environment", "type": "enum", "options": ["sandbox", "production"]}
```

### api_key (required)
API authentication key for the selected environment.
Found in the merchant dashboard under **Settings → API Keys**.
Starts with `sk_test_` for sandbox or `sk_live_` for production.

```json
{"field": "api_key", "type": "string", "format": "sk_{environment}_[a-zA-Z0-9]{24}"}
```

### currency (optional, default: USD)
Default transaction currency.

```json
{"field": "currency", "type": "enum", "options": ["USD", "EUR", "GBP", "CAD", "AUD"], "default": "USD"}
```

### webhook_enabled (optional, default: false)
Enable webhook notifications for transaction events.
### webhook_url (optional, requires webhook_enabled: true)
HTTPS endpoint to receive webhook payloads.
Must be a publicly accessible HTTPS URL. For local development, consider using a tunneling service.

Now the agent has everything it needs to act intelligently. It reads the markdown and immediately understands the situation: environment and api_key are required, the rest have defaults. The prose explains where to find the API key and what format it takes. The JSON code blocks give the agent structured data it can map directly to command flags — valid enum options, format patterns, defaults. No parsing of a monolithic JSON object, no guessing at field semantics from key names alone.

The agent can now make a decision: Do I already have this information from the user's instructions or the project context? If the user said "set up the sandbox environment," the agent already knows the environment. If there's a .env file with an API key, the agent can use that. For anything truly unknown, the agent can ask the user a precise, informed question — not "what's your API key?" but "I need your sandbox API key. You can find it in the merchant dashboard under Settings → API Keys. It starts with sk_test_."

The agent fills in what it can and calls again:

$ paytool configure --agent \
  --merchant-id "MCH_12345" \
  --environment "sandbox" \
  --api-key "sk_test_a1b2c3d4e5f6g7h8i9j0k1l2"

# Configuration: complete
## Resolved
- **merchant_id**: `MCH_12345` (provided)
- **environment**: `sandbox` (provided)
- **api_key**: `sk_test_***` (provided)
- **currency**: `USD` (default)
- **webhook_enabled**: `false` (default)
Configuration saved to `.paytool/config.json`

Done in two calls, with full transparency about what was applied and how.

The Pattern

Progressive Discovery follows three principles:

1. Show the full picture, not one step at a time. Unlike interactive prompts that reveal requirements sequentially, Progressive Discovery returns the entire configuration surface in one response. The agent sees all required and optional fields, their types, constraints, defaults, and dependencies. This allows it to batch its decisions and minimize round trips.

2. Provide actionable context, not just validation errors. Each pending field includes its type, valid options, format constraints, human-readable descriptions, and hints about where to find the value. This transforms a missing field from a blocker into a solvable problem. The agent can reason about where to look — environment variables, project files, user instructions — or formulate a specific question for the user.

3. Acknowledge what's already resolved. The response always reflects back what the tool has already accepted. This gives the agent a clear picture of progress and prevents redundant work. It also surfaces the source of each value — whether it was explicitly provided, pulled from a default, or inferred from the environment.

Detecting the Agent

For Progressive Discovery to work, the tool needs to know when it's being called by an agent. There are two complementary approaches.

Environment-Based Detection

Most AI coding agents set identifiable environment variables. A tool can check for these:

export function detectAgentEnvironment(): null | string {
  // Claude Code (CLI or extension)
  if (process.env.CLAUDECODE === '1') return 'claude-code'
  // Cursor IDE
  if (process.env.CURSOR_TRACE_ID) return 'cursor'
  // GitHub Copilot CLI
  if (process.env.GITHUB_COPILOT_TOKEN
    || process.env.COPILOT_AGENT_ENABLED === '1') return 'github-copilot'
  // Aider AI coding assistant
  if (process.env.AIDER_MODEL
    || process.env.AIDER_CHAT_HISTORY_FILE) return 'aider'
  // OpenCode AI terminal agent
  if (process.env.OPENCODE === '1') return 'opencode'
  return null
}

This is useful for automatic detection — the tool can switch to Progressive Discovery mode without the caller needing to do anything special.

The --agent Flag

Environment detection is helpful, but it's inherently fragile. New agents appear regularly, environment variables change, and some agents might not set any identifiable markers at all.

The more robust solution is explicit: offer an --agent flag.

$ paytool configure --agent

This is the recommended approach for tool authors. It's simple, self-documenting, and puts control in the agent's hands. Any AI agent — current or future — can use it without the tool needing to know about that specific agent. It also serves as an escape hatch for advanced human users who prefer structured output over interactive prompts.

In practice, you should support both: auto-detect when possible, but always accept the flag.

export function isAgentMode(flags: ParsedFlags): boolean {
  // Explicit flag takes priority
  if (flags.agent) return true
  // Fall back to environment detection
  return detectAgentEnvironment() !== null
}

Implementation Guidelines

If you're building a CLI tool and want to support Progressive Discovery, here's what to keep in mind.

Use markdown as your primary response format, with JSON code blocks for structured datasets. LLMs are language models — they reason about prose and markdown natively. Rigid JSON-only responses waste tokens on syntax noise (brackets, quotes, escaping) that adds no semantic value for the agent. Write the response as readable markdown: describe what's resolved, what's pending, and provide context in natural language. When there's actual structured data the agent might need to iterate over or map to parameters — like a list of valid options, available resources, or enumerated values — wrap it in a JSON code block within the markdown. This gives the agent the best of both worlds: natural language for reasoning and structured data for programmatic use.

Include field metadata generously. Type, format, description, hint, default, dependencies — the more context you provide, the fewer round trips the agent needs. Think of each pending field as a self-contained brief for the agent.

Distinguish required from optional. Let the agent know what must be provided to proceed versus what has sensible defaults. This allows it to complete configuration without asking the user about every optional setting.

Express dependencies explicitly. If field B only matters when field A has a certain value (like webhook_url requiring webhook_enabled: true), say so in the schema. This prevents the agent from asking the user unnecessary questions.

Keep the final call idempotent. The agent might call the command multiple times as it gathers values. Each call should accept all previously resolved values plus new ones, and return the updated state without side effects until status: "complete".

Support partial progress. Don't require all fields in a single call. Accept what the agent has now and report back what's still missing. The tool should be comfortable with incremental resolution.

Why This Matters

AI agents are becoming a primary interface for developer tools. They read documentation, they execute commands, they configure environments. But they're working with tools that were designed for a different kind of user — one who can read a prompt, glance at a help page, and type a response.

Progressive Discovery bridges this gap without breaking the human experience. A tool can support all three modes — interactive for humans, non-interactive for scripts, and progressive for agents — with the same underlying configuration logic. The only thing that changes is how requirements are communicated.

The pattern is simple: instead of asking or failing, describe what you need and why. Let the agent — which sits between the tool and the user — do what it's good at: reasoning about context, making decisions, and asking smart questions when it has to.

That's Progressive Discovery. Not a new protocol. Not a framework. Just a better way for tools to talk to agents.

All changes have to be done directly in mdx file

Add langulage support

import php from 'react-syntax-highlighter/dist/esm/languages/prism/php';

Add SyntaxHighlighter component

import { SyntaxHighlighter } from "@storybook/components";

Register language

{SyntaxHighlighter.registerLanguage("php", php)}

I'm using YubiKey for my ssh keys with gpg-agent. After some updates with homebrew (including pinentry) something odd happens. My key was in place as usual, gpg --card-status returns all as supposed. But trying to pull my repo from gitlab Pinentry always poped with me same message:

Please insert the card with serial number XXXX XXXXXXXXX

And that was my card number. All was correct.

I fixed it with the following commands:

gpg-connect-agent killagent \bye
gpg-connect-agent "scd serialno" "learn --force" \bye

If you are not familiar with RE:DOM framework here you should look first. You should get to know especially how RE:DOM components updates their state. It's not the same as in bigger reactive frameworks. An update is done manually through update method of each component. There are also no partial updates. Each update starts in the root of the application and flows to the leaves unless you decide that some part of the view should not be updated adding special logic in update function.

redom-state component is not changing this approach. It does not extend the framework but builds on top of and what it provides is simple loop feedback between DOM event in RE:DOM component and root application update function call.

The state is updating mostly like reducer in react hooks. It's a simple function that gets payload and merges it with the whole state:

import { wire } from "redom-state"

export const addJob((state, jobPayload) => {
  return {
     ...state,
     jobs: [...state.jobs, jobPayload]
  }
})

Each update call returns a whole new state and each update calls the update function in the application's root.

That's why you can be sure that in the following RE:DOM component each button click will increment counter value:

import { el, text } from "redom"
import { wire } from "redom-state"

export const increment = wire((state) => ({ ...state, counter: state.counter + 1 }));

export default class Counter {
  constructor() {
    this.el = el('.counter',
      this.counter = text(),
      this.button = el('button', text('increment'))
    );
    this.button.onclick = increment;
  }
  
  update(state) {
    this.counter.textContent = state.counter;
  }
}

You can encapsulate view components and data manipulating functions in logic components what makes the code cleaner. For example, if the component above would be a part of a bigger app I would be able to include RE:DOM component and state functions as well.

import Counter, { increment } from "./Counter"

If you will want to try redom-state just install it using your favorite package manager:

yarn add redom-state
# or
npm i redom-state

You can feel free also to fork and update, just let me know if you figure out something nice.

GitHub - kobylinski/redom-state: State management for RE:DOM apps

State management for RE:DOM apps. Contribute to kobylinski/redom-state development by creating an account on GitHub.

GitHubkobylinski

I start with simple code:

class MyState{
  constructor( bootstrap = () => {} ) {
    this.state = bootstrap();
  }
}

The constructor calls the bootstrap function and the state is ready. But in the case of async calls, I'm forced to keep access to the final state object and update it directly when an async call ends.

const state = new MyState(() => {
	callAsyncService().then((asyncState) => {
    	state.state = asyncState
    })
	return "sync state";
});

It's easy on this example but if have don't keep access to state objects things are more complicated.

The simplest way to handle it is to return a promise or array of promises and resolve those using Promise.all and/or Promise.resolve and apply results to the state. This was my first step:

class MyState {
  constructor( bootstrap = () => {} ) {
    const state = bootstrap();
    this.state = {}
    if ( Array.isArray(state) ) {
    	Promise.all( state ).then( (stateParts) => this.state = { ...this.state, ...stateParts })    
    }else{
    	Promise.resolve(state).then( (state) => this.state = state )
    }
  }
}

That way handles one or more promises and in the case of an array, all results will be merged into the state object when the last promise will resolve. It's almost good but what I want is to make the first state without delay, and render the app with loader. The second thought I had was that progress also would be a nice thing.

I thought, what if I will not use Promise.all but iterate through an array and resolve each promise separately?

class MyState {
  constructor( bootstrap = () => {} ) {
    const state = bootstrap();
    if( Array.isArray(state) ) {
      for( let stage of state ) {
        Promise.resolve(stage).then( stage => this.state = {
        	...this.state,
            ...stage
        });
      }
    }else{
    	Promise.resolve(state).then( state => this.state = state );
    }
  }
}

Then I have tested this code with the following bootstrap function:

const sleep = (ms, result) =>
  new Promise((done) => setTimeout(() => done(result), ms));
  
const myBootstrap = () => {
	return [
    	{ state: "loading", progress: 0 },
        sleep(1000, { progress: 66 }),
        sleep(500, { progress: 100 }),
        { state: "ready" }
    ];
}

This code didn't keep proper functions call. It's good if there is no matter what result I got first. But the thing it's not I wanted to achieve.

To keep proper sequence I need to check if the first promise is resolved before I will check the second one.

class MyState {
  constructor( bootstrap = () => {} ) {
    const state = bootstrap();
    if( Array.isArray(state) ) {
      const step = (i) => {
        Promise.resolve(state[i]).then( stage => {
		  this.state = {
            ...this.state,
            ...stage
          });
          if( state.length > ++i  ){
            runNext(i);
          } 
        });
      };
      step(0)
    }else{
      Promise.resolve(state).then( state => this.state = state );
    }
  }
}

To simplify this code I will use async / await keywords.

const runBootstrap = async (state, merge) => {
	for await ( let stage of state ) {
    	merge(stage);
    }
}

class MyState {
  constructor( bootstrap = () => {} ) {
    const state = bootstrap();
    if( !Array.isArray(state) ) {
      	state = [state];
	}
    this.state = {};
    runBootstrap( state, (stage) => {
        this.state = {
            ...this.state,
            ...stage
        }
    });
  }
}

What when one async call in bootstrap depends on other? For example, the first call is for the user session and the next are based on if the user is logged in or not.

const bootstrapApp = async () => {
  const user = await api.getCurrentUser();
  const resources = await api.getUserResources(user);
  return { user, resources };
}

Let's try to use a function generator.

const bootstrapApp = async function* () {
  yield { state: "loading", progress: 0 };
  const user = await api.getCurrentUser();
  if( null !== user ) {
  	yield { progress: 50, user };
    const resources = await api.getUserResources(user);
    yield { progress: 100, resources }; 
  }
  yield { state: "done" }
}

And resolve it in state constructor.

const runBootstrap = async ( state, merge ) => {
	for await ( let stage of state ) {
    	merge(stage); 
    }
}

class MyState {
  constructor( bootstrap ) {
  	this.state = {};
    runBootstrap(bootstrap(), stage => this.state = {
      ...this.state,
      ...stage
    });
  }
}

I have all, but what if there will be no need to use generator function and simple function call will be enough? Let's try to test this code against those variations:

const bootstrap1 = () => ({
  state: "done"
});

const bootstrap2 = () => [
  {state: "loading", progress: 0},
  sleep(1000, { progress: 66 }),
  sleep(500, { progress: 100 }),
  {state: "done"}
];

In case of function:  bootstrap1 I need to be sure that only asyncIterator will be passed to loop code. bootstrap2 can be passed to loop code but it's not asyncIterator and I need to include also simple array type. The whole code will look like this:

const runBootstrap = async ( state, merge ) => {
	for await ( let stage of state ) {
    	merge(stage); 
    }
}

class MyState {
  constructor( bootstrap ) {
  	this.state = {};
	const state = bootstrap();
    if( 
      Array.isArray(state) || // handle bootstrap2
      typeof state[Symbol.asyncIterator] !== 'undefined' 
    ) {
      runBootstrap(state, stage => this.state = {
        ...this.state,
        ...stage
      });
    } else { // handle bootstrap1
      this.state = state;
    }
  }
}

Let's create closure:

class Example {
  function get($arg) {
    return function() use ($arg) {
      return $arg;
    }
  }
}

$closure = (new Example())->get("value"); 

Take a $this attribute:

$ref = new \ReflectionFunction($closure);
$refThis = $ref->getClosureThis();

Take scope variables from use statement:

$refUse = $ref->getStaticVariables();
assertEquals($closure(), $refUse['arg']);

<?php

namespace App\GraphQL\Directives;

use Closure;
use GraphQL\Type\Definition\ResolveInfo;
use Nuwave\Lighthouse\Schema\Directives\BaseDirective;
use Nuwave\Lighthouse\Schema\Values\FieldValue;
use Nuwave\Lighthouse\Support\Contracts\FieldMiddleware;
use Nuwave\Lighthouse\Support\Contracts\GraphQLContext;
use App\GraphQL\Grid\Types;

class MyDirective extends BaseDirective implements FieldMiddleware {

    public static function definition(): Directive
    {
        return new Types\Directive();
    }

    public function handleField(FieldValue $fieldValue, Closure $next)
    {
        $resolver = $fieldValue->getResolver();
        return $next(
            $fieldValue->setResolver(function (
                $root,
                array $args,
                GraphQLContext $context,
                ResolveInfo $resolveInfo
            ) use ($resolver) {
                info("Middleware");
                return $resolver($root, $args, $context, $resolveInfo);
            })
        );
    }
}

And defined my query:

extend type Query {
    myQuery( arg1: String! @fieldDirective1, arg2: String! @fieldDirective2 ): [MyType] @paginate @myDirective
}

I had two arguments with field directives and @paginate directive.

To each directive, I've added info a function with the class name. In case of a trace is added at the beginning and just before the end (when a query is resolved).

First, run:

MyDirective
Paginate Begin
FieldDirective1
FieldDirective2
Paginate End

Paginate directive Resolve field arguments in the middle. I need to add my middleware after FieldDirective2 and before Paginate End.

A little change in the code of MyDirective

$result = $resolver($root, $args, $context, $resolveInfo);
info("middleware");
return $result;

Result as expected:

Paginate Begin
FieldDirective1
FieldDirective2
Paginate End
MyDirective

Paginate directive runs field directives. I'm not able to catch the moment with FieldMiddleware. I need to be here:

// PaginateDirective.php
$query = $resolveInfo->argumentSet->enhanceBuilder($query, $this->directiveArgValue("scopes", []));

Add bogus argument

I've changed my directive resolver to inject additional arguments into arguments stored in $resolveInfo

class MyDirective extends BaseDirective implements
    FieldManipulator,
    DefinedDirective,
    FieldMiddleware,
    \Nuwave\Lighthouse\Support\Contracts\ArgBuilderDirective
{
    public function handleField(FieldValue $fieldValue, Closure $next)
    {
        $resolver = $fieldValue->getResolver();
        return $next(
            $fieldValue->setResolver(function (
                $root,
                array $args,
                GraphQLContext $context,
                ResolveInfo $resolveInfo
            ) use ($resolver) {
                $argument = new \Nuwave\Lighthouse\Execution\Arguments\Argument();
                $argument->value = true;
                $argument->type = \GraphQL\Type\Definition\Type::boolean();
                $argument->directives->push($this);
                $resolveInfo->argumentSet->arguments["my_directive_arg"] = $argument;
                info("MyDirective Begin");
                $result = $resolver($root, $args, $context, $resolveInfo);
                info("MyDirective End");
                return $result;
            })
        );
    }


    public function handleBuilder($builder, $filters)
    {
        info("MyDirective Bulder");
        return $builder;
    }
}

And result:

MyDirective Begin
Pagination Begin
FieldDirective1
FieldDirective2
MyDirective Bulder
Paginate End
MyDirective End

This gives me the ability to modify eloquent queries just before execute knowing all conditions made by argument directives.

... trying to login to docker.

Type:

security -v unlock-keychain ~/Library/Keychains/login.keychain-db

Install moleculer app using cli command:

npm install -g moleculer-cli
moleculer init project <project-name>

Install vuepress:

cd <project-name>
npm install vuepress --save-dev

Create moleculer mixin

// mixins/vuepress.js

const { createApp } = require( 'vuepress' );
const enabled = process.env.npm_lifecycle_event === 'dev';

let app;
let logger;
let server;

module.exports = {
	settings: {
		middleware: enabled,
		...( enabled ? {} : {
			assets: {
				folder: './public/.vuepress/dist'
			}
		} )
	},
	async started(){
		logger = this.broker.getLogger('Vuepress', { svc: 'Vuepress', ver: null });
		if( enabled ){
			const service = this;
			app = createApp({ 
				sourceDir: 'public',
				port: this.settings.port,
				host: this.settings.ip,
				plugins: [[
					( pluginOptions, context ) => ({
						name: 'moleculer',
						beforeDevServer(express, server) {
							logger.info( `Connecting to vuepress dev server` );
							express.use( service.express() );
						}
					})
				]]
			});

			await app.process();
			await app.dev();
		}
	}
}

Add vuepress mixin to API service before ApiGateway mixin:

// services/api.js

const ApiGateway = require( 'moleculer-web' );
const Vuepress = require( '../mixins/vuepress' );

module.exports = {
	name: 'api',
	mixins: [ 
		Vuepress,
		ApiGateway
	],
	settings: {
		port: process.env.PORT || 3000,
		routes: [{
			path: "/api",
			whitelist: [ "**" ]
		}]
	}
};

Add build script to package.json

{
    "scripts": {
        "build": "vuepress build public"
    }
}

version: "3.2"
  app:
    build:
      context: .
    environment:
      PORT: 3000
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.app.loadbalancer.server.port=3000"
      - "traefik.http.middlewares.force-sec.redirectscheme.scheme=https"
      - "traefik.http.routers.app.rule=Host(`example.dev`)"
      - "traefik.http.routers.app.entrypoints=web"
      - "traefik.http.routers.app.middlewares=force-sec"
      - "traefik.http.routers.app-sec.rule=Host(`example.dev`)"
      - "traefik.http.routers.app-sec.entrypoints=web-sec"
      - "traefik.http.routers.app-sec.tls=true"
      - "traefik.http.routers.app-sec.tls.certresolver=le"
    networks:
      - default
      - internal
  gateway:
    image: traefik
    container_name: gateway
    restart: always
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web-sec.address=:443"
      - "--providers.docker.network=app_default"
      - "--certificatesResolvers.le.acme.tlsChallenge=true"
      - "--certificatesResolvers.le.acme.email=email@example.dev"
      - "--certificatesResolvers.le.acme.storage=/acme/storage.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - acme:/acme
    networks:
      - default
      
networks:
  internal:
  
volumes:
  acme:

2. As a standalone gateway.

version: "3.2"
services:
  gateway:
    image: traefik
    restart: always
    container_name: gateway
    command:
      - "--providers.docker=true"
      - "--providers.docker.network=gateway_gateway"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websec.address=:443"
      - "--providers.docker.exposedByDefault=false"
      - "--certificatesResolvers.le.acme.tlsChallenge=true"
      - "--certificatesResolvers.le.acme.email=email@example.dev"
      - "--certificatesResolvers.le.acme.storage=/acme/storage.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - acme:/acme
    networks:
      - gateway

networks:
  gateway:
    ipam:
      driver: default

volumes:
  acme:

version: "3.2"
  app:
    build:
      context: .
    environment:
      PORT: 3000
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.app.loadbalancer.server.port=3000"
      - "traefik.http.middlewares.force-sec.redirectscheme.scheme=https"
      - "traefik.http.routers.app.rule=Host(`example.dev`)"
      - "traefik.http.routers.app.entrypoints=web"
      - "traefik.http.routers.app.middlewares=force-sec"
      - "traefik.http.routers.app-sec.rule=Host(`example.dev`)"
      - "traefik.http.routers.app-sec.entrypoints=web-sec"
      - "traefik.http.routers.app-sec.tls=true"
      - "traefik.http.routers.app-sec.tls.certresolver=le"
    networks:
      - internal
      - gateway

networks:
  internal:
  gateway:
    external:
      name: gateway_gateway