cloudapper は何をしますか？
CloudApperはノーコードプラットフォームです。アプリはフォーム（データモデル）、メニュー（ナビゲーション）、ロール、UIワークフロー（クライアントサイド）、バックエンドワークフロー（自動化）、およびDevExpressレポートで構成され、これらはすべてApp Studio（フォームとメニューは/design/...、ワークフローは/studio/...）で編集され、ランタイムアプリ（/<clientId>/app/<appId>/...）で使用されます。
このファイルには、すべてのタスクに適用されるルールが記載されています。作業を開始する前に、タスクに一致するリファレンスを読んでください。
| タスク | 読むもの |
|---|---|
| プラットフォームの仕組みを理解する（フォーム、フィールド、ワークフロー、レポート、キャッシュ） | references/platform-model.md |
| APIを呼び出す（レコード、ワークフロー、フォーム、メニュー、ロール、UIワークフロー、レポート） | references/api-reference.md |
| ワークフローを構築または変更する；「動作しない」または遅いワークフローをデバッグする | references/workflow-patterns.md |
| Playwright MCPでブラウザを操作する | references/playwright-efficiency.md |
| 機能またはアプリ全体を別のアプリ/アカウントにコピーする | references/copy-between-apps.md |
| デザイナーで新しいアプリまたはフォームを構築する | references/building-apps.md |
| 何かを設計、命名、またはレビューする（CloudApperでのSOLID原則、命名規則、ワークフロー/設定/レポートの規則） | references/conventions.md |
| ソリューションまたは統合アーキテクチャを設計する（UKG、REST、webhooks、SFTP、ミドルウェア；スケーリングと効率性） | references/architecture.md |
| アプリをドキュメント化する（技術ガイド/トラブルシューティングガイド、またはPM引継ぎガイド） | references/documentation.md |
| アプリをレビューし、その所見/推奨事項を作成する | references/app-review-checklist.md |
| UKG（Pro、WFM、Recruiting、HRSD）コネクタを操作する | references/integrations-ukg.md |
| ユーザーがCloudApperでの作業方法や、このスキルに含まれる内容について質問する | references/learning-and-prompting.md |
環境：変更する前に確認する
ほとんどのCloudApper顧客は本番アプリとUAT（テスト）アプリを持っており、多くの場合異なるアカウント下にあります。変更（フォームの保存、ワークフローの編集または有効/無効の切り替え、レコードの編集、レポートのインポート、メニューの変更）を行う前には、ユーザーがこの会話ですでに指定していない限り、どの環境に対する変更かを確認してください。
- 質問：「これは本番用ですか、それともUAT用ですか？」と、ログインしているアカウント/アプリ名を伝え、ユーザーが不一致に気付けるようにします。
- デフォルトはUAT。本番環境は読み取り専用として扱います。ユーザーが明示的に特定のアクションを要求しない限り、変更、ワークフロー実行、ログイン、または読み取りは行いません。本番環境からのコピーは読み取りです。へのコピーは変更です。
- 書き込みの前に、URLのクライアントIDを確認します（
/<clientId>/app/<appId>）。書き込みを行うスクリプトは、ページが間違ったクライアントにある場合は実行を拒否する必要があります。 - プロジェクトの事実（アカウント、クライアント/アプリID、どのアプリが本番か）はこのスキルには保存されません。プロジェクト独自のメモやドキュメント、メモリから探してください。見つからない場合はユーザーに質問してください。
すべてのタスクに適用される安全ルール
- 自分自身でワークフローを実行、有効化、またはトリガーしないでください。 ユーザーが実行を開始します。定義の保存やオン/オフの切り替えは、依頼された場合のみ行い、切り替えがライブの動作を変更する場合は明確に伝えてください。
- 編集する前にバックアップを取ってください。 変更するすべてのワークフロー/フォームの現在の定義を、日付入りのローカルフォルダに保存し、ユーザーが結果を確認するまで保持してください。（以前、バックアップを早期に削除したためにロールバックが不可能になったことがあります。）
- シークレット。 ワークフローコネクタには認証情報（UKG、その他のベンダーAPI、キー）が含まれています。印刷、ログ記録、ドキュメントへの記載は絶対に行わないでください。ワークフローJSONを検査する際は、password/secret/apikey/token/clientIdなどのキーをマスクし、構造のみを出力してください。シークレットを含む生のダンプは完了後に削除し、どのローカルフォルダにまだ含まれているかをユーザーに伝えてください。
- ユーザーがサインインします。 パスワードは絶対に入力しないでください。ユーザーにPlaywrightブラウザでサインインするよう依頼し、完了したら知らせてもらってください。
- 個人データ。 保存または共有するスクリーンショットでは、名前、メールアドレス、IDをぼかしてください。
- 忠実に報告してください。 テストで何かが機能しなかった場合、次の修正を提案する前に、証拠（タイムスタンプ、ステータス、ログ行）とともにその旨を伝えてください。
最も驚きを引き起こす6つのプラットフォームの事実
苦労して学んだこと。詳細と証拠はreferences/workflow-patterns.mdにあります。
- ワークフローの順序が重要です（WP-001）。 ワークフローによって作成/更新されたレコードは、ワークフローリストの後ろ（Sequenceが大きい）にあるワークフローのみをトリガーします。ターゲットより前に配置されたワークフローは何もトリガーしません。環境間でリストの順序を同一に保ってください。
- デザイナーはAPIが行わない隠れたサイドワークを行います。 デザイナーでフォームを作成すると、管理者ロールのアクセス権（特権32655）も付与されます。APIを使用してフォーム本文を保存すると、フォームとそのデフォルトメニューは作成されますが、特権は作成されないため、メニューはランタイムで非表示のままになります。子フォームにも、独自の親子関係呼び出しが必要です。
- ステータストリガーには実際の変更が必要です（WP-002）。
Status _IsUpdatedでトリガーされるワークフローは、新しい値が古い値と同じ場合に開始しません（「Running」でスタックしたレコードは、再度「Running」を設定しても再実行できません）。 - 1つのワークフローのトリガーされた実行は一度に1つずつ行われ、ループはそれらを常に待機するとは限りません（WP-005）。 24のレコードを更新したループは数秒で終了しましたが、それによってトリガーされた24のワークフロー実行は次の1時間にわたって実行されました。その間に開始された2番目のバッチは、トリガーされた実行を失いました。一度に1つのバッチを実行してください。
- ランタイムはアプリをキャッシュします。 デザイン変更後は、アプリ名の横にある更新アイコンをクリックするか（または再サインイン）、ロールがアクセスできないフォームのメニューは非表示になるため、新しいフォームにはロール特権が必要です（コピーチェックリストを参照）。
- ルーターは、条件がtrueであるすべてのルートを実行します（WP-009）。 最初のルートだけではありません。1つの結果のみが必要な場合は、ルート条件を排他にしてください。
効率的に作業する方法
- APIをクリック操作よりも優先してください。APIは高速で正確でコストがかかりません。UIは、知っているAPIがない場合、およびユーザーが何を見るかを確認するためにのみ使用してください。
- Playwrightでは、ファイルからコードを実行し（
browser_run_code_unsafeをfilenameと共に使用）、大きなペイロードはlocalhostヘルパーから提供し、コンパクトなサマリー（カウント、名前、ステータス）を返し、JSON全体は返さないでください。references/playwright-efficiency.mdを参照してください。 - ワークフローを編集する前に、デザイナーを開く代わりに、APIからノードツリー（名前、アクションタイプ、フォーム）を読み取ってください。
- 変更のたびに、読み返して検証し（API）、ワークフローの場合は、ビルダーを一度開いてレンダリングされることを確認してください。
- 大規模または反復的なタスク：既存のノードからテンプレートを使用してJSONを生成する小さなビルダースクリプト（Python）を作成し、次にガード付きの適用スクリプトを作成します。変更を繰り返し可能でレビュー可能にするために、両方をプロジェクトに保存してください。
ドキュメントのデフォルト
Markdownのみ（PDFはリクエストがあった場合のみ）、内部向けのみ（顧客向けメールはなし）、ドキュメント内の未解決の質問は理由と目的を明確に、図は実行中のアプリとそのユーザー/外部システムのみを示します。完全な方法はreferences/documentation.mdを参照してください。アプリにすでにドキュメントやプロジェクトノートがある場合は、アプリを再度探索する前にそれらを読んでください。
このスキルに知識を追加する
ユーザーがこのスキルに何かを追加するよう依頼した場合（「これをcloudapperスキルに追加して」）：
- このスキルのフォルダにある
inbox/TEMPLATE.mdを読み、ドラフトをinbox/<yyyy-mm-dd>-<short-name>.mdにステータスHypothesisで書き込みます。汎用的に記述します。顧客名、アプリ名、フォーム名、ワークフロー名、人物名、ID、実際のホスト、認証情報は含めないでください。 references/を検索して、ドラフトが確認または矛盾するエントリを見つけ、ドラフトのレビューノートにリストします。- ユーザーがメンテナーでありレビュー済みの変更を適用していると明示しない限り、
SKILL.mdやreferences/を自分自身で編集しないでください。ユーザーにドラフトを使用してプルリクエストを開くように伝えてください（CONTRIBUTING.mdにフローが記載されています）。