claudecode-omc 5.6.4 → 5.6.6

package/bundled/upstream/ecc/skills/search-first/SKILL.md

@@ -20,6 +20,10 @@ Use this skill when:
 
 ```
 ┌─────────────────────────────────────────────┐
+│  0. TOOL AVAILABILITY PREFLIGHT             │
+│     Check search channels before relying on │
+│     them; report skipped channels honestly   │
+├─────────────────────────────────────────────┤
 │  1. NEED ANALYSIS                           │
 │     Define what functionality is needed      │
 │     Identify language/framework constraints  │
@@ -57,6 +61,19 @@ Use this skill when:
 
 ## How to Use
 
+### Step 0: Tool Availability Preflight
+
+This is agent guidance, not an executable setup script. Check only the channels
+that are relevant to the task and project in front of you.
+
+| Channel | Check | If missing |
+|---------|-------|------------|
+| Repository search | `rg --files` and targeted `rg` queries | State that only visible files were inspected |
+| Package registry | `npm --version`, `python -m pip --version`, or project package manager | Use web/docs search and avoid claiming registry coverage |
+| GitHub CLI | `gh auth status` | Use public web or local git history only |
+| MCP/docs tools | Available tool list or local MCP config | Fall back to official docs/web search |
+| Skills directory | `ls ~/.claude/skills ~/.codex/skills` where applicable | Say no local skill catalog was available |
+
 ### Quick Mode (inline)
 
 Before writing a utility or adding functionality, mentally run through:
@@ -72,7 +89,7 @@ Before writing a utility or adding functionality, mentally run through:
 For non-trivial functionality, launch the researcher agent:
 
 ```
-Task(subagent_type="general-purpose", prompt="
+Agent(subagent_type="general-purpose", prompt="
   Research existing tools for: [DESCRIPTION]
   Language/framework: [LANG]
   Constraints: [ANY]
@@ -82,6 +99,9 @@ Task(subagent_type="general-purpose", prompt="
 ")
 ```
 
+Older Claude Code docs may call this `Task(...)`; use the current agent/subagent
+tool name exposed by the active harness.
+
 ## Search Shortcuts by Category
 
 ### Development Tooling
@@ -96,7 +116,7 @@ Task(subagent_type="general-purpose", prompt="
 - Document processing → `unstructured`, `pdfplumber`, `mammoth`
 
 ### Data & APIs
-- HTTP clients → `httpx` (Python), `ky`/`got` (Node)
+- HTTP clients → `httpx` (Python), `ky`/`undici` (Node)
 - Validation → `zod` (TS), `pydantic` (Python)
 - Database → Check for MCP servers first
 
@@ -157,5 +177,6 @@ Result: 1 package + 1 schema file, no custom validation logic
 
 - **Jumping to code**: Writing a utility without checking if one exists
 - **Ignoring MCP**: Not checking if an MCP server already provides the capability
+- **Silent skipping**: Reporting "nothing found" when a search channel was unavailable
 - **Over-customizing**: Wrapping a library so heavily it loses its benefits
 - **Dependency bloat**: Installing a massive package for one small feature

package/bundled/upstream/ecc/skills/security-review/SKILL.md

@@ -208,6 +208,11 @@ function renderUserContent(html: string) {
 ```
 
 #### Content Security Policy
+
+Start strict and loosen only with a documented removal plan. Do not default to
+`'unsafe-inline'` or `'unsafe-eval'`; they neutralize much of CSP's protection
+and should be treated as temporary compatibility debt.
+
 ```typescript
 // next.config.js
 const securityHeaders = [
@@ -215,8 +220,11 @@ const securityHeaders = [
     key: 'Content-Security-Policy',
     value: `
       default-src 'self';
-      script-src 'self' 'unsafe-eval' 'unsafe-inline';
-      style-src 'self' 'unsafe-inline';
+      base-uri 'self';
+      object-src 'none';
+      frame-ancestors 'none';
+      script-src 'self';
+      style-src 'self';
       img-src 'self' data: https:;
       font-src 'self';
       connect-src 'self' https://api.example.com;

package/bundled/upstream/ecc/skills/skill-comply/scripts/runner.py

@@ -15,6 +15,10 @@ from scripts.scenario_generator import Scenario
 
 SANDBOX_BASE = Path("/tmp/skill-comply-sandbox")
 ALLOWED_MODELS = frozenset({"haiku", "sonnet", "opus"})
+# Shell builtins cannot be invoked via subprocess.run; cwd is already
+# controlled by the cwd= keyword. Scenarios that include these in
+# setup_commands (a common shell-style convention) must be tolerated.
+SHELL_BUILTINS = frozenset({"cd", "pushd", "popd"})
 
 
 @dataclass(frozen=True)
@@ -53,9 +57,22 @@ def run_scenario(
         cwd=sandbox_dir,
     )
 
-    if result.returncode != 0:
+    # claude -p returns rc=1 when --max-turns is reached, but the stream-json
+    # output is still complete and parseable. Treat this graceful termination
+    # as non-fatal so scenarios that hit the turn cap still produce usable
+    # observations.
+    nonfatal_max_turns = (
+        result.returncode == 1
+        and '"terminal_reason":"max_turns"' in result.stdout
+    )
+    if result.returncode != 0 and not nonfatal_max_turns:
+        # Include both stderr and stdout tails. claude -p often surfaces the
+        # actual failure context (model error JSON, partial stream-json) on
+        # stdout, while stderr carries generic transport / auth messages.
+        # Showing both dramatically reduces "rc=N: <empty>" debugging dead-ends.
         raise RuntimeError(
-            f"claude -p failed (rc={result.returncode}): {result.stderr[:500]}"
+            f"claude -p failed (rc={result.returncode}): "
+            f"stderr={result.stderr[:500]!r} stdout_tail={result.stdout[-500:]!r}"
         )
 
     observations = _parse_stream_json(result.stdout)
@@ -86,7 +103,15 @@ def _setup_sandbox(sandbox_dir: Path, scenario: Scenario) -> None:
 
     for cmd in scenario.setup_commands:
         parts = shlex.split(cmd)
-        subprocess.run(parts, cwd=sandbox_dir, capture_output=True)
+        if not parts or parts[0] in SHELL_BUILTINS:
+            # Shell builtins (cd/pushd/popd) cannot run as subprocess; skip.
+            continue
+        try:
+            subprocess.run(parts, cwd=sandbox_dir, capture_output=True)
+        except FileNotFoundError:
+            # Setup tool not installed in this environment; skip rather than
+            # crash the whole scenario. The compliance run continues.
+            continue
 
 
 def _parse_stream_json(stdout: str) -> list[ObservationEvent]:

package/bundled/upstream/ecc/skills/skill-comply/tests/test_runner.py

@@ -0,0 +1,172 @@
+"""Tests for runner module — scenario execution + subprocess error handling."""
+
+from __future__ import annotations
+
+import subprocess
+from dataclasses import dataclass
+from unittest.mock import MagicMock, patch
+
+import pytest
+
+from scripts.runner import _setup_sandbox, run_scenario
+
+
+@dataclass(frozen=True)
+class _FakeScenario:
+    """Minimal Scenario-like object for runner tests (avoids generator deps)."""
+
+    id: str
+    prompt: str = "do nothing"
+    setup_commands: tuple[str, ...] = ()
+
+
+class TestSetupSandboxSkipsShellBuiltins:
+    """Setup commands containing shell builtins (cd/pushd/popd) must be skipped.
+
+    Regression: subprocess.run(["cd", ...]) raises FileNotFoundError because
+    cd is a shell builtin, not an external binary. Real-world scenarios often
+    include "cd subdir" in setup_commands assuming shell semantics, so the
+    runner must tolerate this rather than crashing the whole scenario.
+    """
+
+    def test_skips_cd(self, tmp_path):
+        scenario = _FakeScenario(
+            id="t1",
+            setup_commands=("cd subdir",),
+        )
+        called_args: list[list[str]] = []
+
+        def fake_run(args, **kwargs):
+            called_args.append(args)
+            return subprocess.CompletedProcess(args=args, returncode=0)
+
+        with patch("scripts.runner.subprocess.run", side_effect=fake_run):
+            _setup_sandbox(tmp_path, scenario)
+
+        # git init runs once; "cd subdir" must NOT be passed to subprocess
+        assert ["git", "init"] in called_args
+        assert ["cd", "subdir"] not in called_args
+
+    def test_skips_pushd_popd(self, tmp_path):
+        scenario = _FakeScenario(
+            id="t2",
+            setup_commands=("pushd dir", "popd"),
+        )
+        called_args: list[list[str]] = []
+
+        def fake_run(args, **kwargs):
+            called_args.append(args)
+            return subprocess.CompletedProcess(args=args, returncode=0)
+
+        with patch("scripts.runner.subprocess.run", side_effect=fake_run):
+            _setup_sandbox(tmp_path, scenario)
+
+        assert ["pushd", "dir"] not in called_args
+        assert ["popd"] not in called_args
+
+    def test_tolerates_missing_executable(self, tmp_path):
+        """A scenario referencing an unavailable tool must not crash setup."""
+        scenario = _FakeScenario(
+            id="t3",
+            setup_commands=("nonexistent-tool-xyz arg",),
+        )
+
+        def fake_run(args, **kwargs):
+            if args[0] == "nonexistent-tool-xyz":
+                raise FileNotFoundError(2, "No such file or directory")
+            return subprocess.CompletedProcess(args=args, returncode=0)
+
+        with patch("scripts.runner.subprocess.run", side_effect=fake_run):
+            # Must NOT raise — missing tools are skipped, not fatal
+            _setup_sandbox(tmp_path, scenario)
+
+    def test_real_commands_still_run(self, tmp_path):
+        """Skip logic must not break legitimate setup commands."""
+        scenario = _FakeScenario(
+            id="t4",
+            setup_commands=("touch file.txt", "cd ignored", "echo hi"),
+        )
+        called_args: list[list[str]] = []
+
+        def fake_run(args, **kwargs):
+            called_args.append(args)
+            return subprocess.CompletedProcess(args=args, returncode=0)
+
+        with patch("scripts.runner.subprocess.run", side_effect=fake_run):
+            _setup_sandbox(tmp_path, scenario)
+
+        # Real commands present, cd absent
+        assert ["touch", "file.txt"] in called_args
+        assert ["echo", "hi"] in called_args
+        assert ["cd", "ignored"] not in called_args
+
+
+class TestRunScenarioMaxTurnsTermination:
+    """rc=1 with terminal_reason=max_turns is graceful termination, not failure.
+
+    claude -p returns rc=1 when --max-turns is reached, but the stream-json
+    output is still valid. Treating this as RuntimeError aborts scenarios
+    that would have produced useful observations. Detect the marker in stdout
+    and downgrade rc=1 + max_turns to non-fatal.
+    """
+
+    def test_rc1_with_max_turns_marker_returns_normally(self, tmp_path, monkeypatch):
+        scenario = _FakeScenario(id="mt1", prompt="long task", setup_commands=())
+
+        # Skip sandbox setup side effects
+        monkeypatch.setattr("scripts.runner._setup_sandbox", lambda *a, **kw: None)
+
+        max_turns_stdout = (
+            '{"type":"system","subtype":"init","session_id":"s1"}\n'
+            '{"type":"result","terminal_reason":"max_turns"}\n'
+        )
+
+        fake_result = subprocess.CompletedProcess(
+            args=["claude"], returncode=1, stdout=max_turns_stdout, stderr=""
+        )
+
+        with patch("scripts.runner.subprocess.run", return_value=fake_result):
+            # Must NOT raise — max_turns is graceful termination
+            run_scenario(scenario, model="haiku")
+
+    def test_rc1_without_max_turns_marker_still_raises(self, tmp_path, monkeypatch):
+        """Real failures (rc≠0 with no max_turns marker) must still raise."""
+        scenario = _FakeScenario(id="mt2", prompt="oops", setup_commands=())
+        monkeypatch.setattr("scripts.runner._setup_sandbox", lambda *a, **kw: None)
+
+        fake_result = subprocess.CompletedProcess(
+            args=["claude"], returncode=1, stdout="", stderr="auth error"
+        )
+
+        with patch("scripts.runner.subprocess.run", return_value=fake_result):
+            with pytest.raises(RuntimeError, match="claude -p failed"):
+                run_scenario(scenario, model="haiku")
+
+
+class TestRunScenarioErrorIncludesStdoutTail:
+    """Error messages must include stdout tail, not only stderr.
+
+    When claude -p fails inside an LLM call, useful diagnostic context often
+    appears in stdout (partial stream-json events, model error JSON), not
+    stderr. Including stdout tail in the RuntimeError message dramatically
+    improves debug-ability without adding any new dependency.
+    """
+
+    def test_error_message_contains_stdout_tail(self, tmp_path, monkeypatch):
+        scenario = _FakeScenario(id="e1", prompt="x", setup_commands=())
+        monkeypatch.setattr("scripts.runner._setup_sandbox", lambda *a, **kw: None)
+
+        diagnostic_marker = "DIAG_STDOUT_MARKER_xyz123"
+        fake_result = subprocess.CompletedProcess(
+            args=["claude"],
+            returncode=2,
+            stdout=f"some context {diagnostic_marker} more text",
+            stderr="generic error",
+        )
+
+        with patch("scripts.runner.subprocess.run", return_value=fake_result):
+            with pytest.raises(RuntimeError) as excinfo:
+                run_scenario(scenario, model="haiku")
+
+        # Stdout marker MUST appear in the error message
+        assert diagnostic_marker in str(excinfo.value)

package/bundled/upstream/ecc/skills/skill-scout/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: skill-scout
+description: Search existing local, marketplace, GitHub, and web skill sources before creating a new skill. Use when the user wants to create, build, fork, or find a skill for a workflow.
+origin: community
+---
+
+# Skill Scout
+
+Use this skill before creating a new skill. The goal is to avoid duplicating
+existing community or marketplace work, while still vetting anything external
+before adoption.
+
+Source: salvaged from stale community PR #1232 by `redminwang`.
+
+## When to Use
+
+- The user says "create a skill", "build a skill", "make a skill", or "new
+  skill".
+- The user asks "is there a skill for X?" or "does a skill exist that does Y?"
+- The user describes a workflow and you are about to suggest creating a new
+  skill.
+- The user wants to fork or extend an existing skill.
+
+If the user explicitly says to skip search or create from scratch, acknowledge
+that and proceed with the requested creation workflow.
+
+## How It Works
+
+### Step 1 - Capture Intent
+
+Extract:
+
+- The task the skill should perform.
+- The trigger conditions for using it.
+- The domain, tools, frameworks, or data sources involved.
+- Three to five search keywords plus useful synonyms.
+
+### Step 2 - Search Local Sources
+
+Search installed and marketplace skill names first. Local sources are preferred
+because they are already part of the user's environment.
+
+```bash
+find ~/.claude/skills -maxdepth 2 -name SKILL.md 2>/dev/null | grep -iE "keyword|synonym"
+find ~/.claude/plugins/marketplaces -path '*/skills/*/SKILL.md' 2>/dev/null | grep -iE "keyword|synonym"
+```
+
+Then search frontmatter descriptions:
+
+```bash
+grep -RilE "keyword|synonym" ~/.claude/skills ~/.claude/plugins/marketplaces 2>/dev/null
+```
+
+### Step 3 - Search Remote Sources
+
+Use available GitHub and web search tools. Prefer concise queries:
+
+```bash
+gh search repos "claude code skill keyword" --limit 10 --sort stars
+gh search code "name: keyword" --filename SKILL.md --limit 10
+```
+
+For web search, use at most three targeted queries such as:
+
+```text
+"claude code skill" keyword
+"SKILL.md" keyword
+"everything-claude-code" keyword
+```
+
+### Step 4 - Vet External Matches
+
+Before recommending any external skill for adoption or forking:
+
+- Read the `SKILL.md` frontmatter and instructions.
+- Look for unexpected shell commands, file writes, network calls, credential
+  handling, or package installs.
+- Check whether the repository appears maintained.
+- Prefer copying into a fresh local branch and reviewing the diff over editing
+  marketplace originals.
+
+### Step 5 - Rank Results
+
+Rank candidates by:
+
+1. Exact keyword match in the skill name.
+2. Keyword or synonym match in description.
+3. Local installed or marketplace source.
+4. Maintained GitHub source with recent activity.
+5. Web-only mention.
+
+Cap the final list at 10 results.
+
+### Step 6 - Present Decision Options
+
+Give the user a short table:
+
+| Option | Meaning |
+| --- | --- |
+| Use existing | Invoke or install a matching skill as-is. |
+| Fork or extend | Copy the closest skill and modify it. |
+| Create fresh | Build a new skill after confirming no close match exists. |
+
+Only create a new skill after the user chooses that path or after the search
+finds no close match.
+
+## Examples
+
+### Result Table
+
+```markdown
+| # | Skill | Source | Why it matches | Gap |
+| --- | --- | --- | --- | --- |
+| 1 | article-writing | Local ECC | Drafts articles and guides | Not focused on release notes |
+| 2 | content-engine | Local ECC | Multi-format content workflow | Heavier than needed |
+| 3 | blog-writer | GitHub | Blog writing skill with recent commits | Needs security review |
+```
+
+### User-Facing Summary
+
+```markdown
+I found two close local matches and one external candidate. The closest fit is
+`article-writing`; it covers drafting and revision, but it does not include the
+release-note checklist you asked for. I can either use it as-is, fork it into a
+release-note variant, or create a fresh skill.
+```
+
+## Anti-Patterns
+
+- Do not jump directly to new skill creation when a search is reasonable.
+- Do not install external skills without reading them first.
+- Do not present a long unranked list of weak matches.
+- Do not treat web-only mentions as trusted sources.
+- Do not edit installed marketplace originals in place.
+
+## Related
+
+- `search-first` - General search-before-building workflow.
+- `skill-stocktake` - Audit installed skills for health, duplicates, and gaps.
+- `agent-sort` - Categorize and organize existing agents and skills.

package/bundled/upstream/ecc/skills/skill-stocktake/SKILL.md

@@ -1,4 +1,5 @@
 ---
+name: skill-stocktake
 description: "Use when auditing Claude skills and commands for quality. Supports Quick Scan (changed skills only) and Full Stocktake modes with sequential subagent batch evaluation."
 origin: ECC
 ---

package/bundled/upstream/ecc/skills/strategic-compact/SKILL.md

@@ -46,11 +46,11 @@ Add to your `~/.claude/settings.json`:
     "PreToolUse": [
       {
         "matcher": "Edit",
-        "hooks": [{ "type": "command", "command": "node ~/.claude/skills/strategic-compact/suggest-compact.js" }]
+        "hooks": [{ "type": "command", "command": "node ~/.claude/scripts/hooks/suggest-compact.js" }]
       },
       {
         "matcher": "Write",
-        "hooks": [{ "type": "command", "command": "node ~/.claude/skills/strategic-compact/suggest-compact.js" }]
+        "hooks": [{ "type": "command", "command": "node ~/.claude/scripts/hooks/suggest-compact.js" }]
       }
     ]
   }

package/bundled/upstream/ecc/skills/tinystruct-patterns/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: tinystruct-patterns
+description: Expert guidance for developing with the tinystruct Java framework. Use when working on the tinystruct codebase or any project built on tinystruct — including creating Application classes, @Action-mapped routes, unit tests, ActionRegistry, HTTP/CLI dual-mode handling, the built-in HTTP server, the event system, JSON with Builder/Builders, database persistence with AbstractData, POJO generation, Server-Sent Events (SSE), file uploads, and outbound HTTP networking.
+origin: ECC
+---
+
+# tinystruct Development Patterns
+
+Architecture and implementation patterns for building modules with the **tinystruct** Java framework – a lightweight, high-performance framework that treats CLI and HTTP as equal citizens, requiring no `main()` method and minimal configuration.
+
+## Core Principle
+
+**CLI and HTTP are equal citizens.** Every method annotated with `@Action` should ideally be runnable from both a terminal and a web browser without modification. This "dual-mode" capability is the core design philosophy of tinystruct.
+
+## When to Activate
+
+### 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` and `Builders` components.
+- Working with database persistence via `AbstractData` POJOs.
+- Generating POJOs from database tables using the `generate` command.
+- Implementing Server-Sent Events (SSE) for real-time push.
+- Handling file uploads via multipart data.
+- Making outbound HTTP requests with `URLRequest` and `HTTPHandler`.
+- Configuring database connections or system settings in `application.properties`.
+- 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` and `Builders` components should be used for JSON serialization to maintain a zero-dependency footprint. The database layer uses `AbstractData` POJOs paired with XML mapping files for CRUD operations without external ORM libraries.
+
+## 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!";
+    }
+
+    // Path parameter: GET /?q=greet/James  OR  bin/dispatcher greet/James
+    @Action("greet")
+    public String greet(String name) {
+        return "Hello, " + name + "!";
+    }
+}
+```
+
+### HTTP Mode Disambiguation (login)
+```java
+@Action(value = "login", mode = Mode.HTTP_POST)
+public String doLogin(Request<?, ?> request) throws ApplicationException {
+    request.getSession().setAttribute("userId", "42");
+    return "Logged in";
+}
+```
+
+### Native JSON Data Handling (Builder + Builders)
+```java
+import org.tinystruct.data.component.Builder;
+import org.tinystruct.data.component.Builders;
+
+@Action("api/data")
+public String getData() throws ApplicationException {
+    Builders dataList = new Builders();
+    Builder item = new Builder();
+    item.put("id", 1);
+    item.put("name", "James");
+    dataList.add(item);
+
+    Builder response = new Builder();
+    response.put("status", "success");
+    response.put("data", dataList);
+    return response.toString(); // {"status":"success","data":[{"id":1,"name":"James"}]}
+}
+```
+
+### SSE (Server-Sent Events)
+```java
+import org.tinystruct.http.SSEPushManager;
+
+@Action("sse/connect")
+public String connect() {
+    return "{\"type\":\"connect\",\"message\":\"Connected to SSE\"}";
+}
+
+// Push to a specific client
+String sessionId = getContext().getId();
+Builder msg = new Builder();
+msg.put("text", "Hello, user!");
+SSEPushManager.getInstance().push(sessionId, msg);
+
+// Broadcast to all
+// Broadcast to all
+SSEPushManager.getInstance().broadcast(msg);
+```
+
+### File Upload
+```java
+import org.tinystruct.data.FileEntity;
+
+@Action(value = "upload", mode = Mode.HTTP_POST)
+public String upload(Request<?, ?> request) throws ApplicationException {
+    List<FileEntity> files = request.getAttachments();
+    if (files != null) {
+        for (FileEntity file : files) {
+            System.out.println("Uploaded: " + file.getFilename());
+        }
+    }
+    return "Upload OK";
+}
+```
+
+## Configuration
+
+Settings are managed in `src/main/resources/application.properties`.
+
+```properties
+# Database
+driver=org.h2.Driver
+database.url=jdbc:h2:~/mydb
+database.user=sa
+database.password=
+
+# Server
+default.home.page=hello
+server.port=8080
+
+# Locale
+default.language=en_US
+
+# Session (Redis for clustered environments)
+# default.session.repository=org.tinystruct.http.RedisSessionRepository
+# redis.host=127.0.0.1
+# redis.port=6379
+```
+
+Access config values in your application:
+```java
+String port = this.getConfiguration("server.port");
+```
+
+## Red Flags & Anti-patterns
+
+| Symptom | Correct Pattern |
+|---|---|
+| Importing `com.google.gson` or `com.fasterxml.jackson` | Use `org.tinystruct.data.component.Builder` / `Builders`. |
+| Using `List<Builder>` for JSON arrays | Use `Builders` to avoid generic type erasure issues. |
+| `ApplicationRuntimeException: template not found` | 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. |
+| Action not found at runtime | Ensure class is imported via `--import` or listed in `application.properties`. |
+| CLI arg not visible | Pass with `--key value`; access via `getContext().getAttribute("--key")`. |
+| Two methods same path, wrong one fires | Set explicit `mode` (e.g., `HTTP_GET` vs `HTTP_POST`) to disambiguate. |
+
+## Best Practices
+
+1. **Granular Applications**: Break logic into smaller, focused applications rather than one monolithic class.
+2. **Setup in `init()`**: Leverage `init()` for setup (config, DB) rather than the constructor. Do NOT call `setAction()` — use `@Action` annotation.
+3. **Mode Awareness**: Use the `Mode` parameter in `@Action` to restrict sensitive operations to `CLI` only or specific HTTP methods.
+4. **Context over Params**: For optional CLI flags, use `getContext().getAttribute("--flag")` rather than adding parameters to the method signature.
+5. **Asynchronous Events**: For heavy tasks triggered by events, use `CompletableFuture.runAsync()` inside the event handler.
+
+## 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) — Builder, Builders, JSON serialization & parsing
+- [Database Persistence](references/database.md) — AbstractData POJOs, CRUD, mapping XML, POJO generation
+- [System & Usage](references/system-usage.md) — Context, Sessions, SSE, File Uploads, Events, Networking
+- [Testing Patterns](references/testing.md) — JUnit 5 unit and HTTP integration testing
+
+## Reference Source Files (Internal)
+
+- `src/main/java/org/tinystruct/AbstractApplication.java` — Core base class with lifecycle hooks
+- `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 object serializer
+- `src/main/java/org/tinystruct/data/component/Builders.java` — JSON array serializer
+- `src/main/java/org/tinystruct/data/component/AbstractData.java` — Base POJO class with CRUD
+- `src/main/java/org/tinystruct/data/Mapping.java` — Mapping XML parser
+- `src/main/java/org/tinystruct/data/tools/MySQLGenerator.java` — POJO generator reference
+- `src/main/java/org/tinystruct/data/component/FieldType.java` — SQL-to-Java type mappings
+- `src/main/java/org/tinystruct/data/component/Condition.java` — Fluent SQL query builder
+- `src/main/java/org/tinystruct/http/SSEPushManager.java` — SSE connection management
+- `src/test/java/org/tinystruct/application/ActionRegistryTest.java` — Registry test examples
+- `src/test/java/org/tinystruct/system/HttpServerHttpModeTest.java` — HTTP integration test patterns