compact-agent 1.10.1 → 1.11.0

package/resources/ecc/skills/tdd-workflow/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: tdd-workflow
 description: Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
+origin: ECC
 ---
 
 # Test-Driven Development Workflow
@@ -46,6 +47,19 @@ ALWAYS write tests first, then implement code to make tests pass.
 - Browser automation
 - UI interactions
 
+### 4. Git Checkpoints
+- If the repository is under Git, create a checkpoint commit after each TDD stage
+- Do not squash or rewrite these checkpoint commits until the workflow is complete
+- Each checkpoint commit message must describe the stage and the exact evidence captured
+- Count only commits created on the current active branch for the current task
+- Do not treat commits from other branches, earlier unrelated work, or distant branch history as valid checkpoint evidence
+- Before treating a checkpoint as satisfied, verify that the commit is reachable from the current `HEAD` on the active branch and belongs to the current task sequence
+- The preferred compact workflow is:
+  - one commit for failing test added and RED validated
+  - one commit for minimal fix applied and GREEN validated
+  - one optional commit for refactor complete
+- Separate evidence-only commits are not required if the test commit clearly corresponds to RED and the fix commit clearly corresponds to GREEN
+
 ## TDD Workflow Steps
 
 ### Step 1: Write User Journeys
@@ -86,6 +100,29 @@ npm test
 # Tests should fail - we haven't implemented yet
 ```
 
+This step is mandatory and is the RED gate for all production changes.
+
+Before modifying business logic or other production code, you must verify a valid RED state via one of these paths:
+- Runtime RED:
+  - The relevant test target compiles successfully
+  - The new or changed test is actually executed
+  - The result is RED
+- Compile-time RED:
+  - The new test newly instantiates, references, or exercises the buggy code path
+  - The compile failure is itself the intended RED signal
+- In either case, the failure is caused by the intended business-logic bug, undefined behavior, or missing implementation
+- The failure is not caused only by unrelated syntax errors, broken test setup, missing dependencies, or unrelated regressions
+
+A test that was only written but not compiled and executed does not count as RED.
+
+Do not edit production code until this RED state is confirmed.
+
+If the repository is under Git, create a checkpoint commit immediately after this stage is validated.
+Recommended commit message format:
+- `test: add reproducer for <feature or bug>`
+- This commit may also serve as the RED validation checkpoint if the reproducer was compiled and executed and failed for the intended reason
+- Verify that this checkpoint commit is on the current active branch before continuing
+
 ### Step 4: Implement Code
 Write minimal code to make tests pass:
 
@@ -96,12 +133,24 @@ export async function searchMarkets(query: string) {
 }
 ```
 
+If the repository is under Git, stage the minimal fix now but defer the checkpoint commit until GREEN is validated in Step 5.
+
 ### Step 5: Run Tests Again
 ```bash
 npm test
 # Tests should now pass
 ```
 
+Rerun the same relevant test target after the fix and confirm the previously failing test is now GREEN.
+
+Only after a valid GREEN result may you proceed to refactor.
+
+If the repository is under Git, create a checkpoint commit immediately after GREEN is validated.
+Recommended commit message format:
+- `fix: <feature or bug>`
+- The fix commit may also serve as the GREEN validation checkpoint if the same relevant test target was rerun and passed
+- Verify that this checkpoint commit is on the current active branch before continuing
+
 ### Step 6: Refactor
 Improve code quality while keeping tests green:
 - Remove duplication
@@ -109,6 +158,11 @@ Improve code quality while keeping tests green:
 - Optimize performance
 - Enhance readability
 
+If the repository is under Git, create a checkpoint commit immediately after refactoring is complete and tests remain green.
+Recommended commit message format:
+- `refactor: clean up after <feature or bug> implementation`
+- Verify that this checkpoint commit is on the current active branch before considering the TDD cycle complete
+
 ### Step 7: Verify Coverage
 ```bash
 npm run test:coverage

package/resources/ecc/skills/team-builder/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: team-builder
+description: Interactive agent picker for composing and dispatching parallel teams
+origin: community
+---
+
+# Team Builder
+
+Interactive menu for browsing and composing agent teams on demand. Works with flat or domain-subdirectory agent collections.
+
+## When to Use
+
+- You have multiple agent personas (markdown files) and want to pick which ones to use for a task
+- You want to compose an ad-hoc team from different domains (e.g., Security + SEO + Architecture)
+- You want to browse what agents are available before deciding
+
+## Prerequisites
+
+Agent files must be markdown files containing a persona prompt (identity, rules, workflow, deliverables). The first `# Heading` is used as the agent name and the first paragraph as the description.
+
+Both flat and subdirectory layouts are supported:
+
+**Subdirectory layout** — domain is inferred from the folder name:
+
+```
+agents/
+├── engineering/
+│   ├── security-engineer.md
+│   └── software-architect.md
+├── marketing/
+│   └── seo-specialist.md
+└── sales/
+    └── discovery-coach.md
+```
+
+**Flat layout** — domain inferred from shared filename prefixes. A prefix counts as a domain when 2+ files share it. Files with unique prefixes go to "General". Note: the algorithm splits at the first `-`, so multi-word domains (e.g., `product-management`) should use the subdirectory layout instead:
+
+```
+agents/
+├── engineering-security-engineer.md
+├── engineering-software-architect.md
+├── marketing-seo-specialist.md
+├── marketing-content-strategist.md
+├── sales-discovery-coach.md
+└── sales-outbound-strategist.md
+```
+
+## Configuration
+
+Agents are discovered via two methods, merged and deduplicated by agent name:
+
+1. **`claude agents` command** (primary) — run `claude agents` to get all agents known to the CLI, including user agents, plugin agents (e.g. `everything-claude-code:architect`), and built-in agents. This automatically covers ECC marketplace installs without any path configuration.
+2. **File glob** (fallback, for reading agent content) — agent markdown files are read from:
+   - `./agents/**/*.md` + `./agents/*.md` — project-local agents
+   - `~/.claude/agents/**/*.md` + `~/.claude/agents/*.md` — global user agents
+
+Earlier sources take precedence when names collide: user agents > plugin agents > built-in agents. A custom path can be used instead if the user specifies one.
+
+## How It Works
+
+### Step 1: Discover Available Agents
+
+Run `claude agents` to get the full agent list. Parse each line:
+- **Plugin agents** are prefixed with `plugin-name:` (e.g., `everything-claude-code:security-reviewer`). Use the part after `:` as the agent name and the plugin name as the domain.
+- **User agents** have no prefix. Read the corresponding markdown file from `~/.claude/agents/` or `./agents/` to extract the name and description.
+- **Built-in agents** (e.g., `Explore`, `Plan`) are skipped unless the user explicitly asks to include them.
+
+For user agents loaded from markdown files:
+- **Subdirectory layout:** extract the domain from the parent folder name
+- **Flat layout:** collect all filename prefixes (text before the first `-`). A prefix qualifies as a domain only if it appears in 2 or more filenames (e.g., `engineering-security-engineer.md` and `engineering-software-architect.md` both start with `engineering` → Engineering domain). Files with unique prefixes (e.g., `code-reviewer.md`, `tdd-guide.md`) are grouped under "General"
+- Extract the agent name from the first `# Heading`. If no heading is found, derive the name from the filename (strip `.md`, replace hyphens with spaces, title-case)
+- Extract a one-line summary from the first paragraph after the heading
+
+If no agents are found after running `claude agents` and probing file locations, inform the user: "No agents found. Run `claude agents` to verify your setup." Then stop.
+
+### Step 2: Present Domain Menu
+
+```
+Available agent domains:
+1. Engineering — Software Architect, Security Engineer
+2. Marketing — SEO Specialist
+3. Sales — Discovery Coach, Outbound Strategist
+
+Pick domains or name specific agents (e.g., "1,3" or "security + seo"):
+```
+
+- Skip domains with zero agents (empty directories)
+- Show agent count per domain
+
+### Step 3: Handle Selection
+
+Accept flexible input:
+- Numbers: "1,3" selects all agents from Engineering and Sales
+- Names: "security + seo" fuzzy-matches against discovered agents
+- "all from engineering" selects every agent in that domain
+
+If more than 5 agents are selected, list them alphabetically and ask the user to narrow down: "You selected N agents (max 5). Pick which to keep, or say 'first 5' to use the first five alphabetically."
+
+Confirm selection:
+```
+Selected: Security Engineer + SEO Specialist
+What should they work on? (describe the task):
+```
+
+### Step 4: Spawn Agents in Parallel
+
+1. Read each selected agent's markdown file
+2. Prompt for the task description if not already provided
+3. Spawn all agents in parallel using the Agent tool:
+   - `subagent_type: "general-purpose"`
+   - `prompt: "{agent file content}\n\nTask: {task description}"`
+   - Each agent runs independently — no inter-agent communication needed
+4. If an agent fails (error, timeout, or empty output), note the failure inline (e.g., "Security Engineer: failed — [reason]") and continue with results from agents that succeeded
+
+### Step 5: Synthesize Results
+
+Collect all outputs and present a unified report:
+- Results grouped by agent
+- Synthesis section highlighting:
+  - Agreements across agents
+  - Conflicts or tensions between recommendations
+  - Recommended next steps
+
+If only 1 agent was selected, skip synthesis and present the output directly.
+
+## Rules
+
+- **Dynamic discovery only.** Never hardcode agent lists. New files in the directory auto-appear in the menu.
+- **Max 5 agents per team.** More than 5 produces diminishing returns and excessive token usage. Enforce at selection time.
+- **Parallel dispatch.** All agents run simultaneously — use the Agent tool's parallel invocation pattern.
+- **Parallel Agent calls, not TeamCreate.** This skill uses parallel Agent tool calls for independent work. TeamCreate (a Claude Code tool for multi-agent dialogue) is only needed when agents must debate or respond to each other.
+
+## Examples
+
+```
+User: team builder
+
+Claude:
+Available agent domains:
+1. Engineering (2) — Software Architect, Security Engineer
+2. Marketing (1) — SEO Specialist
+3. Sales (4) — Discovery Coach, Outbound Strategist, Proposal Strategist, Sales Engineer
+4. Support (1) — Executive Summary
+
+Pick domains or name specific agents:
+
+User: security + seo
+
+Claude:
+Selected: Security Engineer + SEO Specialist
+What should they work on?
+
+User: Review my Next.js e-commerce site before launch
+
+[Both agents spawn in parallel, each applying their specialty to the codebase]
+
+Claude:
+## Security Engineer Findings
+- [findings...]
+
+## SEO Specialist Findings
+- [findings...]
+
+## Synthesis
+Both agents agree on: [...]
+Tension: Security recommends CSP that blocks inline styles, SEO needs inline schema markup. Resolution: [...]
+Next steps: [...]
+```

package/resources/ecc/skills/terminal-ops/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: terminal-ops
+description: Evidence-first repo execution workflow for ECC. Use when the user wants a command run, a repo checked, a CI failure debugged, or a narrow fix pushed with exact proof of what was executed and verified.
+origin: ECC
+---
+
+# Terminal Ops
+
+Use this when the user wants real repo execution: run commands, inspect git state, debug CI or builds, make a narrow fix, and report exactly what changed and what was verified.
+
+This skill is intentionally narrower than general coding guidance. It is an operator workflow for evidence-first terminal execution.
+
+## Skill Stack
+
+Pull these ECC-native skills into the workflow when relevant:
+
+- `verification-loop` for exact proving steps after changes
+- `tdd-workflow` when the right fix needs regression coverage
+- `security-review` when secrets, auth, or external inputs are involved
+- `github-ops` when the task depends on CI runs, PR state, or release status
+- `knowledge-ops` when the verified outcome needs to be captured into durable project context
+
+## When to Use
+
+- user says "fix", "debug", "run this", "check the repo", or "push it"
+- the task depends on command output, git state, test results, or a verified local fix
+- the answer must distinguish changed locally, verified locally, committed, and pushed
+
+## Guardrails
+
+- inspect before editing
+- stay read-only if the user asked for audit/review only
+- prefer repo-local scripts and helpers over improvised ad hoc wrappers
+- do not claim fixed until the proving command was rerun
+- do not claim pushed unless the branch actually moved upstream
+
+## Workflow
+
+### 1. Resolve the working surface
+
+Settle:
+
+- exact repo path
+- branch
+- local diff state
+- requested mode:
+  - inspect
+  - fix
+  - verify
+  - push
+
+### 2. Read the failing surface first
+
+Before changing anything:
+
+- inspect the error
+- inspect the file or test
+- inspect git state
+- use any already-supplied logs or context before re-reading blindly
+
+### 3. Keep the fix narrow
+
+Solve one dominant failure at a time:
+
+- use the smallest useful proving command first
+- only escalate to a bigger build/test pass after the local failure is addressed
+- if a command keeps failing with the same signature, stop broad retries and narrow scope
+
+### 4. Report exact execution state
+
+Use exact status words:
+
+- inspected
+- changed locally
+- verified locally
+- committed
+- pushed
+- blocked
+
+## Output Format
+
+```text
+SURFACE
+- repo
+- branch
+- requested mode
+
+EVIDENCE
+- failing command / diff / test
+
+ACTION
+- what changed
+
+STATUS
+- inspected / changed locally / verified locally / committed / pushed / blocked
+```
+
+## Pitfalls
+
+- do not work from stale memory when the live repo state can be read
+- do not widen a narrow fix into repo-wide churn
+- do not use destructive git commands
+- do not ignore unrelated local work
+
+## Verification
+
+- the response names the proving command or test
+- git-related work names the repo path and branch
+- any push claim includes the target branch and exact result

package/resources/ecc/skills/tinystruct-patterns/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: tinystruct-patterns
+description: Use when developing application modules or microservices with the tinystruct Java framework. Covers routing, context management, JSON handling with Builder, and CLI/HTTP dual-mode patterns.
+origin: ECC
+---
+
+# tinystruct Development Patterns
+
+Architecture and implementation patterns for building modules with the **tinystruct** Java framework – a lightweight system where CLI and HTTP are equal citizens.
+
+## When to Use
+
+- Creating new `Application` modules by extending `AbstractApplication`.
+- Defining routes and command-line actions using `@Action`.
+- Handling per-request state via `Context`.
+- Performing JSON serialization using the native `Builder` component.
+- Configuring database connections or system settings in `application.properties`.
+- Generating or re-generating the standard `bin/dispatcher` entry point via `ApplicationManager.init()`.
+- Debugging routing conflicts (Actions) or CLI argument parsing.
+
+## How It Works
+
+The tinystruct framework treats any method annotated with `@Action` as a routable endpoint for both terminal and web environments. Applications are created by extending `AbstractApplication`, which provides core lifecycle hooks like `init()` and access to the request `Context`.
+
+Routing is handled by the `ActionRegistry`, which automatically maps path segments to method arguments and injects dependencies. For data-only services, the native `Builder` component should be used for JSON serialization to maintain a zero-dependency footprint. The framework also includes a utility in `ApplicationManager` to bootstrap the project's execution environment by generating the `bin/dispatcher` script.
+
+## Examples
+
+### Basic Application (MyService)
+```java
+public class MyService extends AbstractApplication {
+    @Override
+    public void init() {
+        this.setTemplateRequired(false); // Disable .view lookup for data/API apps
+    }
+
+    @Override public String version() { return "1.0.0"; }
+
+    @Action("greet")
+    public String greet() {
+        return "Hello from tinystruct!";
+    }
+}
+```
+
+### Parameterized Routing (getUser)
+```java
+// Handles /api/user/123 (Web) or "bin/dispatcher api/user/123" (CLI)
+@Action("api/user/(\\d+)")
+public String getUser(int userId) {
+    return "User ID: " + userId;
+}
+```
+
+### HTTP Mode Disambiguation (login)
+```java
+@Action(value = "login", mode = Mode.HTTP_POST)
+public boolean doLogin() {
+    // Process login logic
+    return true;
+}
+```
+
+### Native JSON Data Handling (getData)
+```java
+@Action("api/data")
+public Builder getData() throws ApplicationException {
+    Builder builder = new Builder();
+    builder.put("status", "success");
+    Builder nested = new Builder();
+    nested.put("id", 1);
+    nested.put("name", "James");
+    builder.put("data", nested);
+    return builder;
+}
+```
+
+## Configuration
+
+Settings are managed in `src/main/resources/application.properties`.
+
+```properties
+# Database
+driver=org.h2.Driver
+database.url=jdbc:h2:~/mydb
+
+# App specific
+my.service.endpoint=https://api.example.com
+```
+
+## Testing Patterns
+
+Use JUnit 5 to test actions by verifying they are registered in the `ActionRegistry`.
+
+```java
+@Test
+void testActionRegistration() {
+    Application app = new MyService();
+    app.init();
+    
+    ActionRegistry registry = ActionRegistry.getInstance();
+    assertNotNull(registry.get("greet"));
+}
+```
+
+## Red Flags & Anti-patterns
+
+| Symptom | Correct Pattern |
+|---|---|
+| Importing `com.google.gson` or `com.fasterxml.jackson` | Use `org.tinystruct.data.component.Builder`. |
+| `FileNotFoundException` for `.view` files | Call `setTemplateRequired(false)` in `init()` for API-only apps. |
+| Annotating `private` methods with `@Action` | Actions must be `public` to be registered by the framework. |
+| Hardcoding `main(String[] args)` in apps | Use `bin/dispatcher` as the entry point for all modules. |
+| Manual `ActionRegistry` registration | Prefer the `@Action` annotation for automatic discovery. |
+
+## Technical Reference
+
+Detailed guides are available in the `references/` directory:
+
+- [Architecture & Config](references/architecture.md) — Abstractions, Package Map, Properties
+- [Routing & @Action](references/routing.md) — Annotation details, Modes, Parameters
+- [Data Handling](references/data-handling.md) — Using the native `Builder` for JSON
+- [System & Usage](references/system-usage.md) — Context, Sessions, Events, CLI usage
+- [Testing Patterns](references/testing.md) — JUnit 5 integration and ActionRegistry testing
+
+## Reference Source Files (Internal)
+
+- `src/main/java/org/tinystruct/AbstractApplication.java` — Core base class
+- `src/main/java/org/tinystruct/system/annotation/Action.java` — Annotation & Modes
+- `src/main/java/org/tinystruct/application/ActionRegistry.java` — Routing Engine
+- `src/main/java/org/tinystruct/data/component/Builder.java` — JSON/Data Serializer

package/resources/ecc/skills/tinystruct-patterns/references/architecture.md

@@ -0,0 +1,77 @@
+# tinystruct Architecture and Configuration
+
+## When to Use
+
+Choose **tinystruct** when you need a lightweight, high-performance Java framework that treats CLI and HTTP as equal citizens. It is ideal for building microservices, command-line utilities, and data-driven applications where a small footprint and zero-dependency JSON handling are required. Use it when you want to write logic once and expose it via both a terminal and a web server without modification.
+
+## How It Works
+
+### Core Architecture
+
+The framework operates on a singleton `ActionRegistry` that maps URL patterns (or command strings) to `Action` objects. When a request arrives, the system resolves the path and invokes the corresponding method handle.
+
+#### Key Abstractions
+
+| Class/Interface | Role |
+|---|---|
+| `AbstractApplication` | Base class for all tinystruct applications. Extend this. |
+| `@Action` annotation | Maps a method to a URI path (web) or command name (CLI). The single routing primitive. |
+| `ActionRegistry` | Singleton that maps URL patterns to `Action` objects via regex. Never instantiate directly. |
+| `Action` | Wraps a `MethodHandle` + regex pattern + priority + `Mode` for dispatch. |
+| `Context` | Per-request state store. Access via `getContext()`. Holds CLI args and HTTP request/response. |
+| `Dispatcher` | CLI entry point (`bin/dispatcher`). Reads `--import` to load applications. |
+| `HttpServer` | Built-in Netty-based HTTP server. Start with `bin/dispatcher start --import org.tinystruct.system.HttpServer`. |
+
+### Package Map
+
+```
+org.tinystruct/
+├── AbstractApplication.java      ← extend this
+├── Application.java              ← interface
+├── ApplicationException.java     ← checked exception
+├── ApplicationRuntimeException.java ← unchecked exception
+├── application/
+│   ├── Action.java               ← runtime action wrapper
+│   ├── ActionRegistry.java       ← singleton route registry
+│   └── Context.java              ← request context
+├── system/
+│   ├── annotation/Action.java    ← @Action annotation + Mode enum
+│   ├── Dispatcher.java           ← CLI dispatcher
+│   ├── HttpServer.java           ← built-in HTTP server
+│   ├── EventDispatcher.java      ← event bus
+│   └── Settings.java             ← reads application.properties
+├── data/component/Builder.java   ← JSON serialization (use instead of Gson/Jackson)
+└── http/                         ← Request, Response, Constants
+```
+
+### Template Behavior and Dispatch Flow
+
+By default, the framework assumes a view template is required. If `templateRequired` is `true`, `toString()` looks for a `.view` file in `src/main/resources/themes/<ClassName>.view`. Use `getContext()` to manage state and `setVariable("name", value)` to pass data to templates, which use `[%name%]` for interpolation.
+
+## Examples
+
+### Minimal Application Initialization
+```java
+@Override
+public void init() {
+    this.setTemplateRequired(false); // Skip .view template lookup for data-only apps
+}
+```
+
+### Action Definition and CLI Invocation
+```java
+@Action("hello")
+public String hello() {
+    return "Hello, tinystruct!";
+}
+```
+**Execution via Dispatcher:**
+```bash
+bin/dispatcher hello
+```
+
+### Configuration Access
+Located at `src/main/resources/application.properties`:
+```java
+String port = this.getConfiguration("server.port");
+```

package/resources/ecc/skills/tinystruct-patterns/references/data-handling.md

@@ -0,0 +1,35 @@
+# tinystruct Data Handling (JSON)
+
+## When to Use
+
+Prefer `org.tinystruct.data.component.Builder` in scenarios where you need a lightweight, high-performance JSON solution with **zero external dependencies**. It is specifically designed to keep your tinystruct applications lean and fast, making it the ideal choice for microservices and CLI tools where including heavy libraries like Jackson or Gson would be overkill.
+
+## How It Works
+
+The `Builder` class provides a simple key-value interface for both creating and reading JSON structures. It integrates directly with `AbstractApplication` result handling; when an action method returns a `Builder` object, the framework automatically serializes it to the response stream. This prevents the need for manual string conversion and ensures consistent data formatting across your application modules.
+
+## Examples
+
+### Serialization
+```java
+import org.tinystruct.data.component.Builder;
+
+// Create and populate
+Builder response = new Builder();
+response.put("status", "success");
+response.put("count", 42);
+response.put("data", someList);
+
+return response; // {"status":"success","count":42,...}
+```
+
+### Parsing
+```java
+import org.tinystruct.data.component.Builder;
+
+// Parse a JSON string
+Builder parsed = new Builder();
+parsed.parse(jsonString);
+
+String status = parsed.get("status").toString();
+```

package/resources/ecc/skills/tinystruct-patterns/references/routing.md

@@ -0,0 +1,57 @@
+# tinystruct @Action Routing Reference
+
+## When to Use
+
+Use the `@Action` annotation in your applications to define routes for both CLI commands and HTTP endpoints. It is appropriate whenever you need to map logic to a specific path, handle parameterized requests (e.g., retrieving a resource by ID), or restrict execution to specific HTTP methods (GET, POST, etc.) while maintaining a consistent command structure across environments.
+
+## How It Works
+
+The `ActionRegistry` parses `@Action` annotations to build a routing table. For parameterized methods, the framework automatically maps Java parameter types (int, String, etc.) to corresponding regex segments to generate an internal matching pattern. For instance, `getUser(int id)` generates a regex targeting digits, while `search(String query)` targets generic path segments.
+
+When a request is dispatched, the `ActionRegistry` automatically injects dependencies like `Request` and `Response` into the action method if they are specified as parameters, drawing them directly from the current request's `Context`. Execution is further filtered by the `Mode` value, allowing a single path to invoke different logic depending on whether the trigger was a terminal command or a specific type of HTTP request.
+
+### Mode Values
+
+| Mode | When it triggers |
+|---|---|
+| `DEFAULT` | Both CLI and HTTP (GET, POST, etc.) |
+| `CLI` | CLI dispatcher only |
+| `HTTP_GET` | HTTP GET only |
+| `HTTP_POST` | HTTP POST only |
+| `HTTP_PUT` | HTTP PUT only |
+| `HTTP_DELETE` | HTTP DELETE only |
+| `HTTP_PATCH` | HTTP PATCH only |
+
+## Examples
+
+### Basic Action Declaration
+```java
+@Action(
+    value = "path/subpath",          // required: URI segment or CLI command
+    description = "What it does",    // shown in --help output
+    mode = Mode.HTTP_POST,           // default: Mode.DEFAULT (both CLI + HTTP)
+    options = {},                    // CLI option flags
+    example = "curl -X POST http://localhost:8080/path/subpath/42"
+)
+public String myAction(int id) { ... }
+```
+
+### Parameterized Paths (Regex Generation)
+```java
+@Action("user/{id}")
+public String getUser(int id) { ... }
+// → pattern: ^/?user/(-?\d+)$
+
+@Action("search")
+public String search(String query) { ... }
+// → pattern: ^/?search/([^/]+)$
+```
+
+### Request and Response Injection
+```java
+@Action(value = "upload", mode = Mode.HTTP_POST)
+public String upload(Request<?, ?> req, Response<?, ?> res) throws ApplicationException {
+    // req.getParameter("file"), res.setHeader(...), etc.
+    return "ok";
+}
+```