feat(ja-JP): add skill sub-reference translations (angular, remotion, etc.)

Translated 85 skill sub-reference files to achieve full parity with
the English source:

- skills/angular-developer/references/ — 35 files (all references)
- skills/remotion-video-creation/rules/ — 28 files (all rules)
- skills/tinystruct-patterns/references/ — 5 files
- skills/openclaw-persona-forge/references/ — 6 files
- skills/skill-comply/prompts/ — 3 files
- skills/lead-intelligence/agents/ — 4 files
- skills/brand-voice/references/ — 1 file
- skills/frontend-slides/ — 2 files
- hooks/memory-persistence/README.md — 1 file

English source parity: 0 missing files (excluding rules/zh/, internal
docs, and experimental examples absent from zh-CN)
This commit is contained in:
Claude
2026-05-18 06:15:16 +09:00
parent 63624426c8
commit 174e31b3fc
85 changed files with 8409 additions and 0 deletions

View File

@@ -0,0 +1,77 @@
# tinystruct アーキテクチャと設定
## 使用場面
CLIとHTTPを同等に扱う軽量で高性能なJavaフレームワークが必要な場合に**tinystruct**を選択します。マイクロサービス、コマンドラインユーティリティ、フットプリントが小さく依存関係のないJSONハンドリングが必要なデータ駆動アプリケーションの構築に理想的です。変更なしにターミナルとWebサーバーの両方でロジックを一度だけ書いて公開したい場合に使用します。
## 動作の仕組み
### コアアーキテクチャ
フレームワークはURLパターンまたはコマンド文字列`Action` オブジェクトにマッピングするシングルトン `ActionRegistry` で動作します。リクエストが到着すると、システムはパスを解決して対応するメソッドハンドルを呼び出します。
#### 主要な抽象化
| クラス/インターフェース | 役割 |
|---|---|
| `AbstractApplication` | すべてのtinystruct アプリケーションの基底クラス。これを拡張します。 |
| `@Action` アノテーション | メソッドをURIパスWebまたはコマンド名CLIにマッピングします。単一のルーティングプリミティブ。 |
| `ActionRegistry` | URLパターンを `Action` オブジェクトにregexでマッピングするシングルトン。直接インスタンス化しない。 |
| `Action` | ディスパッチ用の `MethodHandle` + regexパターン + 優先度 + `Mode` をラップします。 |
| `Context` | リクエストごとの状態ストア。`getContext()` でアクセス。CLIの引数とHTTPのリクエスト/レスポンスを保持。 |
| `Dispatcher` | CLIエントリポイント`bin/dispatcher`)。アプリケーションを読み込むには `--import` を読み取ります。 |
| `HttpServer` | 組み込みのNettyベースHTTPサーバー。`bin/dispatcher start --import org.tinystruct.system.HttpServer` で起動。 |
### パッケージマップ
```
org.tinystruct/
├── AbstractApplication.java ← これを拡張する
├── Application.java ← インターフェース
├── ApplicationException.java ← チェック済み例外
├── ApplicationRuntimeException.java ← 非チェック例外
├── application/
│ ├── Action.java ← ランタイムアクションラッパー
│ ├── ActionRegistry.java ← シングルトンルートレジストリ
│ └── Context.java ← リクエストコンテキスト
├── system/
│ ├── annotation/Action.java ← @Actionアテーション + Mode列挙型
│ ├── Dispatcher.java ← CLIディスパッチャー
│ ├── HttpServer.java ← 組み込みHTTPサーバー
│ ├── EventDispatcher.java ← イベントバス
│ └── Settings.java ← application.propertiesを読み取る
├── data/component/Builder.java ← JSONシリアライゼーションGson/Jacksonの代わりに使用
└── http/ ← Request、Response、Constants
```
### テンプレートの動作とディスパッチフロー
デフォルトでは、フレームワークはビューテンプレートが必要だと仮定します。`templateRequired``true` の場合、`toString()``src/main/resources/themes/<ClassName>.view` 内の `.view` ファイルを探します。`getContext()` を使って状態を管理し、`setVariable("name", value)` でテンプレートにデータを渡します。テンプレートは補間に `[%name%]` を使用します。
## 例
### 最小アプリケーションの初期化
```java
@Override
public void init() {
this.setTemplateRequired(false); // データのみのアプリでは.viewテンプレートのルックアップをスキップ
}
```
### アクション定義とCLI呼び出し
```java
@Action("hello")
public String hello() {
return "Hello, tinystruct!";
}
```
**ディスパッチャー経由での実行:**
```bash
bin/dispatcher hello
```
### 設定へのアクセス
`src/main/resources/application.properties` に配置:
```java
String port = this.getConfiguration("server.port");
```

View File

@@ -0,0 +1,35 @@
# tinystruct データハンドリングJSON
## 使用場面
**外部依存関係がゼロ**の軽量かつ高性能なJSONソリューションが必要なシナリオでは `org.tinystruct.data.component.Builder` を優先します。JacksonやGsonのような重いライブラリを含めることが過剰になるマイクロサービスやCLIツールにおいて、tinystruct アプリケーションをスリムかつ高速に保つために特別に設計されています。
## 動作の仕組み
`Builder` クラスはJSON構造の作成と読み取りの両方にシンプルなキーバリューインターフェースを提供します。`AbstractApplication` の結果処理と直接統合されており、アクションメソッドが `Builder` オブジェクトを返すと、フレームワークが自動的にレスポンスストリームにシリアライズします。これにより手動での文字列変換が不要になり、アプリケーションモジュール全体で一貫したデータフォーマットが保証されます。
## 例
### シリアライゼーション
```java
import org.tinystruct.data.component.Builder;
// 作成して値を設定
Builder response = new Builder();
response.put("status", "success");
response.put("count", 42);
response.put("data", someList);
return response; // {"status":"success","count":42,...}
```
### パース
```java
import org.tinystruct.data.component.Builder;
// JSON文字列をパース
Builder parsed = new Builder();
parsed.parse(jsonString);
String status = parsed.get("status").toString();
```

View File

@@ -0,0 +1,57 @@
# tinystruct @Action ルーティングリファレンス
## 使用場面
アプリケーションで `@Action`テーションを使用して、CLIコマンドとHTTPエンドポイントの両方にルートを定義します。特定のパスにロジックをマッピングする必要がある場合、パラメータ化されたリクエストを処理する場合IDによるリソースの取得、または特定のHTTPメソッドGET、POSTなどに実行を制限しながら、環境をまたいで一貫したコマンド構造を維持したい場合に適しています。
## 動作の仕組み
`ActionRegistry``@Action`テーションをパースしてルーティングテーブルを構築します。パラメータ化されたメソッドに対して、フレームワークはJavaパラメータ型int、Stringなどを対応するregexセグメントに自動的にマッピングして内部マッチングパターンを生成します。例えば、`getUser(int id)` は数字をターゲットとするregexを生成し、`search(String query)` は汎用のパスセグメントをターゲットとします。
リクエストがディスパッチされると、`ActionRegistry``Request``Response` のような依存関係が指定されている場合、現在のリクエストの `Context` から直接取り出してアクションメソッドに自動的にインジェクトします。実行はさらに `Mode` の値によってフィルタリングされ、単一のパスがターミナルコマンドか特定タイプのHTTPリクエストかによって異なるロジックを呼び出せます。
### Mode値
| Mode | トリガーされるタイミング |
|---|---|
| `DEFAULT` | CLIとHTTPの両方GET、POSTなど |
| `CLI` | CLIディスパッチャーのみ |
| `HTTP_GET` | HTTP GETのみ |
| `HTTP_POST` | HTTP POSTのみ |
| `HTTP_PUT` | HTTP PUTのみ |
| `HTTP_DELETE` | HTTP DELETEのみ |
| `HTTP_PATCH` | HTTP PATCHのみ |
## 例
### 基本的なアクション宣言
```java
@Action(
value = "path/subpath", // 必須URIセグメントまたはCLIコマンド
description = "何をするか", // --helpの出力に表示される
mode = Mode.HTTP_POST, // デフォルトMode.DEFAULTCLIとHTTPの両方
options = {}, // CLIオプションフラグ
example = "curl -X POST http://localhost:8080/path/subpath/42"
)
public String myAction(int id) { ... }
```
### パラメータ化されたパスRegex生成
```java
@Action("user/{id}")
public String getUser(int id) { ... }
// → パターン:^/?user/(-?\d+)$
@Action("search")
public String search(String query) { ... }
// → パターン:^/?search/([^/]+)$
```
### RequestとResponseのインジェクション
```java
@Action(value = "upload", mode = Mode.HTTP_POST)
public String upload(Request<?, ?> req, Response<?, ?> res) throws ApplicationException {
// req.getParameter("file"), res.setHeader(...), など
return "ok";
}
```

View File

@@ -0,0 +1,74 @@
# tinystruct システムと使用リファレンス
## 使用場面
CLIとHTTPモード間でステートフルなインタラクションを処理する必要がある場合、Webアプリケーションでユーザーセッションを管理する場合、またはイベント駆動アーキテクチャを使用してアプリケーションモジュール間の疎結合な通信を実装する場合に、ここで説明するシステムと使用パターンを使用します。
## 動作の仕組み
フレームワークの `Context` はリクエスト固有の状態のプライマリデータストアとして機能します。CLIモードでは、`--key value` として渡されるフラグが `--` プレフィックス付きで自動的にパースされて `Context` に保存されるため、アクションメソッドがコマンドパラメータを簡単に取得できます。Webアプリケーションでは、システムは `Request` オブジェクト経由で標準セッション管理を提供し、複数のHTTPリクエストをまたいでユーザーデータを保存できます。
内部の `EventDispatcher` は非同期イベントバスを実現します。カスタム `Event` クラスを定義してハンドラーを登録(通常はアプリケーションの `init()` メソッド内)することで、メインの実行パスをブロックせずにバックグラウンドタスク(メールの送信や監査ログなど)をトリガーできます。
## 例
### コンテキストとCLI引数
```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";
}
```
### セッション管理Webモード
```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;
}
```
### イベントシステム
```java
// 1. イベントを定義する
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. ハンドラーを登録する
EventDispatcher.getInstance().registerHandler(OrderCreatedEvent.class, event -> {
CompletableFuture.runAsync(() -> sendConfirmationEmail(event.getPayload()));
});
// 3. ディスパッチする
EventDispatcher.getInstance().dispatch(new OrderCreatedEvent(newOrder));
```
### アプリケーションの実行
```bash
# CLIモード
bin/dispatcher hello
bin/dispatcher echo --words "Hello" --import com.example.HelloApp
# HTTPサーバーデフォルトで:8080でリッスン
bin/dispatcher start --import org.tinystruct.system.HttpServer
# データベースユーティリティ
bin/dispatcher generate --table users
bin/dispatcher sql-query "SELECT * FROM users"
```

View File

@@ -0,0 +1,59 @@
# tinystruct テストパターン
## 使用場面
**JUnit 5** でtinystruct アプリケーションのユニットテストを作成する場合に、ここで説明するテストパターンを使用します。これらのパターンは `@Action` メソッドが正しい結果を返し、ルーティングロジックがシングルトン `ActionRegistry` 内に適切に登録されていることを検証するために不可欠です。
## 動作の仕組み
tinystruct アプリケーションのテストには、アノテーション処理や設定管理などのフレームワークレベルの機能がアクティブであることを保証するための特定のセットアップが必要です。`setUp()` メソッドでアプリケーションの新しいインスタンスを作成して `Settings` オブジェクトを渡すことで、`init()` ライフサイクルをトリガーします。これにより、すべての `@Action` メソッドが検出されて登録されることが保証されます。
`ActionRegistry` はシングルトンであるため、テスト間で副作用が漏れるのを防ぐため、各テスト実行前にアプリケーションの状態を適切に初期化してテストの分離を維持することが重要です。
## 例
### アプリケーションのユニットテスト
```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(); // @Actionアテーション処理をトリガー
}
void testHello() throws Exception {
// アプリケーションオブジェクト経由の直接呼び出し
Object result = app.invoke("hello");
Assertions.assertEquals("Hello, tinystruct!", result);
}
@Test
void testGreet() throws Exception {
// 引数付きの呼び出し
Object result = app.invoke("greet", new Object[]{"James"});
Assertions.assertEquals("Hello, James!", result);
}
}
```
### ActionRegistry経由のテスト
ルーティングロジック自体をテストする必要がある場合は、`ActionRegistry` シングルトンを使用してパスマッチングを検証します:
```java
@Test
void testRouting() {
ActionRegistry registry = ActionRegistry.getInstance();
// パスがアクションにマッチするか検証
Action action = registry.getAction("greet/James");
Assertions.assertNotNull(action);
}
```
参照:`src/test/java/org/tinystruct/application/ActionRegistryTest.java`