docs: clarify example/ config counts to avoid misleading totals

CONTRIBUTING.md

@@ -46,7 +46,7 @@ schema/          JSON Schema generation and validation
 middleware/      HTTP middleware (validation, rate limiting)
 audit/           Structured audit logging
 ui/              React + ReactFlow visual builder
-example/         27 YAML configs and application examples
+example/         YAML configs and application examples
 mock/            Test helpers
 docs/            API docs, tutorials, ADRs
 ```

README.md

@@ -193,7 +193,7 @@ A 10+ module workflow demonstrating module composition with HTTP servers, router
 
 ### Example Configurations
 
-The [`example/`](example/) directory contains 27 YAML configurations covering:
+The [`example/`](example/) directory contains 27 top-level `example/*.yaml` configurations covering:
 
 - API gateways and reverse proxies
 - Event-driven and scheduled workflows
@@ -223,7 +223,7 @@ ai/                  AI integration layer
   service.go           Provider selection and orchestration
   deploy.go            Validation loop and deployment to dynamic components
 ui/                  React + ReactFlow + Zustand visual builder (Vite, TypeScript)
-example/             27 YAML configs and 2 full application examples
+example/             Top-level example YAML configs and full application examples
 mock/                Test helpers and mock implementations
 ```
 

docs/adr/001-yaml-driven-config.md

@@ -10,6 +10,6 @@ The workflow engine needs a way to define applications. The two main approaches
 We chose YAML as the primary configuration format. All module composition, workflow definitions, trigger configuration, and runtime behavior are specified in YAML files. One file per application (or per service in distributed mode).
 
 ## Consequences
-**Positive**: Non-developers can create applications; configs are validatable via JSON Schema; enables visual builder UI with YAML import/export; runtime reconfiguration without recompilation; 27 example configs as documentation; easy to version control and diff.
+**Positive**: Non-developers can create applications; configs are validatable via JSON Schema; enables visual builder UI with YAML import/export; runtime reconfiguration without recompilation; many example configs as documentation; easy to version control and diff.
 
 **Negative**: Complex logic requires dynamic components (Yaegi); YAML syntax errors can be cryptic; some configs are verbose vs code. Mitigated by JSON Schema validation, wfctl validate CLI, example configs, and visual builder UI.

docs/tutorials/getting-started.md

@@ -26,7 +26,7 @@ Visit http://localhost:8080 to see your server running.
 
 ### 3. Explore Example Configs
 
-The `example/` directory contains 27 YAML configurations:
+The `example/` directory contains 27 top-level `example/*.yaml` configurations, plus additional configs under application subdirectories:
 
 ```bash
 ls example/*.yaml | head -20