compact-agent 1.10.1 → 1.11.0

package/resources/ecc/skills/tinystruct-patterns/references/system-usage.md

@@ -0,0 +1,74 @@
+# tinystruct System and Usage Reference
+
+## When to Use
+
+Use the system and usage patterns described here when you need to handle stateful interactions across CLI and HTTP modes, manage user sessions in web applications, or implement loosely coupled communication between application modules using an event-driven architecture.
+
+## How It Works
+
+The framework's `Context` serves as the primary data store for request-specific state. In CLI mode, flags passed as `--key value` are automatically parsed and stored in the `Context` with the `--` prefix, allowing action methods to retrieve command parameters easily. For web applications, the system provides standard session management via the `Request` object, enabling the storage of user data across multiple HTTP requests.
+
+The internal `EventDispatcher` facilitates an asynchronous event bus. By defining custom `Event` classes and registering handlers (typically within an application's `init()` method), you can trigger background tasks—such as sending emails or logging audit trails—without blocking the main execution path.
+
+## Examples
+
+### Context and CLI Arguments
+```java
+@Action("echo")
+public String echo() {
+    // CLI: bin/dispatcher echo --words "Hello World"
+    Object words = getContext().getAttribute("--words");
+    if (words != null) return words.toString();
+    return "No words provided";
+}
+```
+
+### Session Management (Web Mode)
+```java
+@Action(value = "login", mode = Mode.HTTP_POST)
+public String login(Request request) {
+    request.getSession().setAttribute("userId", "42");
+    return "Logged in";
+}
+
+@Action("profile")
+public String profile(Request request) {
+    Object userId = request.getSession().getAttribute("userId");
+    if (userId == null) return "Not logged in";
+    return "User: " + userId;
+}
+```
+
+### Event System
+```java
+// 1. Define an event
+public class OrderCreatedEvent implements org.tinystruct.system.Event<Order> {
+    private final Order order;
+    public OrderCreatedEvent(Order order) { this.order = order; }
+
+    @Override public String getName() { return "order_created"; }
+    @Override public Order getPayload() { return order; }
+}
+
+// 2. Register a handler
+EventDispatcher.getInstance().registerHandler(OrderCreatedEvent.class, event -> {
+    CompletableFuture.runAsync(() -> sendConfirmationEmail(event.getPayload()));
+});
+
+// 3. Dispatch
+EventDispatcher.getInstance().dispatch(new OrderCreatedEvent(newOrder));
+```
+
+### Running the Application
+```bash
+# CLI mode
+bin/dispatcher hello
+bin/dispatcher echo --words "Hello" --import com.example.HelloApp
+
+# HTTP server (listens on :8080 by default)
+bin/dispatcher start --import org.tinystruct.system.HttpServer
+
+# Database utilities
+bin/dispatcher generate --table users
+bin/dispatcher sql-query "SELECT * FROM users"
+```

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

@@ -0,0 +1,59 @@
+# tinystruct Testing Patterns
+
+## When to Use
+
+Use the testing patterns described here when writing units tests for your tinystruct applications with **JUnit 5**. These patterns are essential for verifying that your `@Action` methods return the correct results and that your routing logic is properly registered within the singleton `ActionRegistry`.
+
+## How It Works
+
+Testing tinystruct applications requires a specific setup to ensure framework-level features like annotation processing and configuration management are active. By creating a new instance of your application and passing it a `Settings` object in the `setUp()` method, you trigger the `init()` lifecycle. This ensures all `@Action` methods are discovered and registered.
+
+Because the `ActionRegistry` is a singleton, it is critical to maintain isolation between tests by properly initializing your application state before each test execution, preventing side effects from leaking across the test suite.
+
+## Examples
+
+### Unit Testing an Application
+```java
+import org.junit.jupiter.api.*;
+import org.tinystruct.application.ActionRegistry;
+import org.tinystruct.system.Settings;
+
+class MyAppTest {
+
+    private MyApp app;
+
+    @BeforeEach
+    void setUp() {
+        app = new MyApp();
+        Settings config = new Settings();
+        app.setConfiguration(config);
+        app.init(); // triggers @Action annotation processing
+    }
+    void testHello() throws Exception {
+        // Direct invocation via the application object
+        Object result = app.invoke("hello");
+        Assertions.assertEquals("Hello, tinystruct!", result);
+    }
+
+    @Test
+    void testGreet() throws Exception {
+        // Invocation with arguments
+        Object result = app.invoke("greet", new Object[]{"James"});
+        Assertions.assertEquals("Hello, James!", result);
+    }
+}
+```
+
+### Testing via ActionRegistry
+If you need to test the routing logic itself, use the `ActionRegistry` singleton to verify path matching:
+
+```java
+@Test
+void testRouting() {
+    ActionRegistry registry = ActionRegistry.getInstance();
+    // Verify a path matches an action
+    Action action = registry.getAction("greet/James");
+    Assertions.assertNotNull(action);
+}
+```
+Reference: `src/test/java/org/tinystruct/application/ActionRegistryTest.java`

package/resources/ecc/skills/token-budget-advisor/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: token-budget-advisor
+description: >-
+  Offers the user an informed choice about how much response depth to
+  consume before answering. Use this skill when the user explicitly
+  wants to control response length, depth, or token budget.
+  TRIGGER when: "token budget", "token count", "token usage", "token limit",
+  "response length", "answer depth", "short version", "brief answer",
+  "detailed answer", "exhaustive answer", "respuesta corta vs larga",
+  "cuántos tokens", "ahorrar tokens", "responde al 50%", "dame la versión
+  corta", "quiero controlar cuánto usas", or clear variants where the
+  user is explicitly asking to control answer size or depth.
+  DO NOT TRIGGER when: user has already specified a level in the current
+  session (maintain it), the request is clearly a one-word answer, or
+  "token" refers to auth/session/payment tokens rather than response size.
+origin: community
+---
+
+# Token Budget Advisor (TBA)
+
+Intercept the response flow to offer the user a choice about response depth **before** Claude answers.
+
+## When to Use
+
+- User wants to control how long or detailed a response is
+- User mentions tokens, budget, depth, or response length
+- User says "short version", "tldr", "brief", "al 25%", "exhaustive", etc.
+- Any time the user wants to choose depth/detail level upfront
+
+**Do not trigger** when: user already set a level this session (maintain it silently), or the answer is trivially one line.
+
+## How It Works
+
+### Step 1 — Estimate input tokens
+
+Use the repository's canonical context-budget heuristics to estimate the prompt's token count mentally.
+
+Use the same calibration guidance as [context-budget](../context-budget/SKILL.md):
+
+- prose: `words × 1.3`
+- code-heavy or mixed/code blocks: `chars / 4`
+
+For mixed content, use the dominant content type and keep the estimate heuristic.
+
+### Step 2 — Estimate response size by complexity
+
+Classify the prompt, then apply the multiplier range to get the full response window:
+
+| Complexity   | Multiplier range | Example prompts                                      |
+|--------------|------------------|------------------------------------------------------|
+| Simple       | 3× – 8×          | "What is X?", yes/no, single fact                   |
+| Medium       | 8× – 20×         | "How does X work?"                                  |
+| Medium-High  | 10× – 25×        | Code request with context                           |
+| Complex      | 15× – 40×        | Multi-part analysis, comparisons, architecture      |
+| Creative     | 10× – 30×        | Stories, essays, narrative writing                  |
+
+Response window = `input_tokens × mult_min` to `input_tokens × mult_max` (but don’t exceed your model’s configured output-token limit).
+
+### Step 3 — Present depth options
+
+Present this block **before** answering, using the actual estimated numbers:
+
+```
+Analyzing your prompt...
+
+Input: ~[N] tokens  |  Type: [type]  |  Complexity: [level]  |  Language: [lang]
+
+Choose your depth level:
+
+[1] Essential   (25%)  ->  ~[tokens]   Direct answer only, no preamble
+[2] Moderate    (50%)  ->  ~[tokens]   Answer + context + 1 example
+[3] Detailed    (75%)  ->  ~[tokens]   Full answer with alternatives
+[4] Exhaustive (100%)  ->  ~[tokens]   Everything, no limits
+
+Which level? (1-4 or say "25% depth", "50% depth", "75% depth", "100% depth")
+
+Precision: heuristic estimate ~85-90% accuracy (±15%).
+```
+
+Level token estimates (within the response window):
+- 25%  → `min + (max - min) × 0.25`
+- 50%  → `min + (max - min) × 0.50`
+- 75%  → `min + (max - min) × 0.75`
+- 100% → `max`
+
+### Step 4 — Respond at the chosen level
+
+| Level            | Target length       | Include                                             | Omit                                              |
+|------------------|---------------------|-----------------------------------------------------|---------------------------------------------------|
+| 25% Essential    | 2-4 sentences max   | Direct answer, key conclusion                       | Context, examples, nuance, alternatives           |
+| 50% Moderate     | 1-3 paragraphs      | Answer + necessary context + 1 example              | Deep analysis, edge cases, references             |
+| 75% Detailed     | Structured response | Multiple examples, pros/cons, alternatives          | Extreme edge cases, exhaustive references         |
+| 100% Exhaustive  | No restriction      | Everything — full analysis, all code, all perspectives | Nothing                                        |
+
+## Shortcuts — skip the question
+
+If the user already signals a level, respond at that level immediately without asking:
+
+| What they say                                      | Level |
+|----------------------------------------------------|-------|
+| "1" / "25% depth" / "short version" / "brief answer" / "tldr"  | 25%   |
+| "2" / "50% depth" / "moderate depth" / "balanced answer"        | 50%   |
+| "3" / "75% depth" / "detailed answer" / "thorough answer"       | 75%   |
+| "4" / "100% depth" / "exhaustive answer" / "full deep dive"     | 100%  |
+
+If the user set a level earlier in the session, **maintain it silently** for subsequent responses unless they change it.
+
+## Precision note
+
+This skill uses heuristic estimation — no real tokenizer. Accuracy ~85-90%, variance ±15%. Always show the disclaimer.
+
+## Examples
+
+### Triggers
+
+- "Give me the short version first."
+- "How many tokens will your answer use?"
+- "Respond at 50% depth."
+- "I want the exhaustive answer, not the summary."
+- "Dame la version corta y luego la detallada."
+
+### Does Not Trigger
+
+- "What is a JWT token?"
+- "The checkout flow uses a payment token."
+- "Is this normal?"
+- "Complete the refactor."
+- Follow-up questions after the user already chose a depth for the session
+
+## Source
+
+Standalone skill from [TBA — Token Budget Advisor for Claude Code](https://github.com/Xabilimon1/Token-Budget-Advisor-Claude-Code-).
+Original project also ships a Python estimator script, but this repository keeps the skill self-contained and heuristic-only.