OpenTouryoProject · daisukenishino2 · Jul 31, 2026 · Jul 31, 2026 · Jul 31, 2026 · Jul 31, 2026
diff --git a/.gitignore b/.gitignore
@@ -285,4 +285,19 @@ __pycache__/
 *.btp.cs
 *.btm.cs
 *.odx.cs
-*.xsd.cs
+*.xsd.cs
+
+# --------------------------------------------------
+# Open棟梁 build outputs
+#   ビルド bat / csproj の OutputPath が出力するディレクトリ。
+#   ※ 既存の "!**/packages/build/" と衝突しないよう、
+#      あえて汎用の "Build/" ではなくパスを固定している
+#      (core.ignoreCase=true の環境では Build/ が build/ にも一致するため)。
+# --------------------------------------------------
+/root/programs/*/Frameworks/Infrastructure/Build/
+/root/programs/*/Frameworks/Infrastructure/Build_net48/
+/root/programs/*/Frameworks/Infrastructure/Build_netcore100/
+/root/programs/*/Frameworks/Infrastructure/*/RichClient/Build_net48/
+/root/programs/*/Frameworks/Infrastructure/ServiceInterface/*/dll/
+/root/programs/*/Samples/WS_sample/Build/
+/root/programs/*/Samples4NetCore/Legacy/WS_sample/Build/
diff --git a/AGENTS.md b/AGENTS.md
@@ -0,0 +1,142 @@
+# プロジェクト ポリシー
+アプリケーション・フレームワーク
+
+https://github.com/OpenTouryoProject/OpenTouryo/
+
+と、ソレを使用したサンプル・アプリケーションの開発エージェント用。
+
+環境のセットアップとビルド手順は [root/Readme.ja.md](root/Readme.ja.md) を参照。
+本書は、その上で**エージェントが守るべきこと**と、**どの文書を見るか**を示す。
+
+### Git 操作は行わない（状態を変える操作をしない）
+
+**成果物の検収は人が行う。** エージェントは作業結果をワーキング ツリーに残すところまでを担当し、
+Git 操作は人が手動で行う。
+
+したがって、指示がない限り次を実行してはならない。
+
+- `git add` / `commit` / `push`（検収前・未レビューの変更を確定・送信しない）
+- `git checkout` / `switch` / `branch` / `reset` / `restore` / `stash`（人の作業状態や未保存の作業を壊す）
+
+**参照系は制限しない。** 何を変更したかを正確に報告するために必要なため、次は自由に実行してよい。
+
+- `git status` / `diff`（`--cached` 含む）/ `log` / `show` / `ls-files` / `check-ignore` / `blame`
+
+作業が完了したら**何を変更したかを報告するに留める**。コミットの要否とタイミングは人が判断する。
+
+<!--
+  補足（執筆者向け）:
+  インストラクションは「文脈」であって強制力を持たない。上記は遵守されやすい書き方に
+  しているが、確実に阻止したい場合は仕組み側で塞ぐ必要がある。
+    - Claude Code : PreToolUse フックで Bash(git commit:*) 等を deny する
+    - 各プロダクト: 同等の機構があればそれを使う
+  必要になったら install.ps1 に設定の配布を追加することを検討する。
+-->
+
+### GitHub 操作は gh で行う
+
+Issue の調査・起票・コメントは、**`gh` コマンドで実行してよい**（ブラウザ操作を人に依頼しない）。
+上記の「Git 操作は行わない」はワーキング ツリーとコミット履歴に対する制約であり、
+GitHub 側のやり取りは対象外。
+
+```
+gh issue view <番号> --repo OpenTouryoProject/OpenTouryo
+gh issue list --repo OpenTouryoProject/OpenTouryo
+gh issue comment <番号> --repo OpenTouryoProject/OpenTouryo --body-file <path>
+gh issue create --repo OpenTouryoProject/OpenTouryo --title <title> --body-file <path>
+```
+
+ただし**公開リポジトリへの投稿は取り消しにくい**ため、次を守ること。
+
+- **投稿前に文面を提示し、承認を得てから実行する。** 承認なしに投稿しない
+- 本文は一時ファイルに書き、`--body-file` で渡す（改行・記号の欠落を避ける）
+- 投稿後は URL を報告する
+
+**このリポジトリでは `OsscJpDevInfra` アカウントを使用する。**
+`gh auth status` に複数のアカウントが登録されていることがあるため、
+投稿前にアクティブなアカウントを確認すること。異なる場合は `gh auth switch` で切り替える。
+
+```
+gh auth status                        # アクティブなアカウントの確認
+gh auth switch --user OsscJpDevInfra  # 異なる場合は切り替え
+```
+
+**Issue のクローズ・ラベル変更・アサイン、PR の作成やマージは人が行う。**
+これらは成果物の検収と同じ扱いとし、エージェントは提案に留める。
+
+### コーディング規約は、領域ごとの ANALYSIS.md に従う
+
+`root/programs/CS/` 配下は領域ごとに基準が異なる。
+**コードを変更する前に、作業対象を所管する `ANALYSIS.md` を読むこと。**
+
+| 作業対象 | 読む文書 |
+|---|---|
+| `root/programs/CS/Frameworks/` | [`Frameworks/ANALYSIS.md`](root/programs/CS/Frameworks/ANALYSIS.md) |
+| `root/programs/CS/Samples/` | [`Samples/ANALYSIS.md`](root/programs/CS/Samples/ANALYSIS.md) |
+| `root/programs/CS/Samples4NetCore/` | [`Samples4NetCore/ANALYSIS.md`](root/programs/CS/Samples4NetCore/ANALYSIS.md) |
+
+各 `ANALYSIS.md` が、その領域におけるアーキテクチャ・ビルド手順・条件コンパイル・
+コーディング規約・既知の落とし穴の**一次情報**である。末尾の
+「エージェント向け作業チェックリスト」には着手前に目を通すこと。
+
+ファイル ヘッダの書式と**更新者名**、新規ファイルにおける Copyright ブロックの扱い、
+`.bat` の文字コードなど、**エージェントが見落としやすい指定**が含まれる。
+
+規約の実体はこのファイル（AGENTS.md）には書かない。領域ごとに基準が分かれるため、
+二重管理になり、どちらが正なのか分からなくなる。
+
+### ビルド・テスト・リリースの検証は、専用の文書に従う
+
+変更を加えたあとの**検証**は、次の文書が一次情報である。
+
+| 目的 | 読む文書 |
+|---|---|
+| リリース時の作業全体 | [`RELEASE.md`](root/programs/RELEASE.md) |
+| 全ビルドの実行と判定 | [`BUILDING.md`](root/programs/BUILDING.md) |
+| 単体テストの実行と判定 | [`TESTING.md`](root/programs/TESTING.md) |
+| サンプルの疎通確認 | [`SMOKETEST.md`](root/programs/SMOKETEST.md) |
+
+検証は次の 3 本で、いずれも終了コードで合否が分かる。**この順で実行すること。**
+
+```powershell
+cd root\programs
+.\1_BuildAll.ps1                 # 全ビルド
+.\2_RunAllTests.ps1              # 単体テスト
+.\3_SmokeTest.ps1                # サンプルの疎通
+```
+
+`2_RunAllTests.ps1` はワーキング ツリーの `Result*.txt` を書き換える（従来のバッチ運用と同じ）。
+**コミットの要否は人が判断する**ため、エージェントは差分を報告するに留める。
+
+**`.ps1` は Windows PowerShell 5.1 と PowerShell 7 の両方で動くこと。**
+エージェントの実行環境は 7 だが、利用者は 5.1（`powershell.exe`）で実行する。
+7 だけで確認すると 5.1 で落ちる。要点は
+[`SMOKETEST.md`](root/programs/SMOKETEST.md) 「PowerShell 5.1 と 7 の両対応」を参照。
+
+- `.ps1` は **UTF-8 BOM 付き**で保存する（5.1 は BOM 無しを Shift_JIS と誤認する）
+- `Get-Content` には **`-Encoding UTF8`** を明示する（既定が 5.1 と 7 で違う）
+- 7 専用の引数（`-SkipHttpErrorCheck` など）はバージョンを見て付け外しする
+- **変更したら 5.1 でも実行して確かめる**
+
+```powershell
+powershell.exe -NoProfile -Command "Set-Location 'root\programs'; .\3_SmokeTest.ps1"
+```
+
+前提となるサービスや DB の状態が足りない場合は、**勝手に変えず、対処方法とともに報告する。**
+
+### 付属ツールを CLI で使うときは、各ツールの README に従う
+
+エージェントから実行できる（非対話の）ツールには README を置く。
+
+| ツール | 読む文書 |
+|---|---|
+| `DaoGen_Tool`（Ｄ層自動生成ツール／墨壺） | [`README.md`](root/programs/CS/Frameworks/Tools/DaoGen_Tool/README.md) |
+
+**引数の一覧は README に書かない。** ツールの `/HELP` が一次情報であり、
+書き写すと二重管理になる。README には README にしか書けないこと
+（実行ファイルの場所、ヘルプの出し方、踏みやすい罠、前提）を置く。
+
+- **引数を組み立てる前に、まず `/HELP` を実行する**
+- 終了コードだけで判断せず、**生成物の存在も確認する**
+  （パス区切りを誤ると、成功（`0`）を返しつつ別の場所に出力される）
+
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -0,0 +1 @@
+@AGENTS.md
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,86 +1,92 @@
 # How to contribute
 
-Click [here](Contributing.ja.md) for Japanese version of this file.
+Click [here](Contributing.ja.md) for the Japanese version of this file.
 
 ## Programming Rules and Conventions
 
 ### Comment
- - The amount of comments aim about 1/3(33%) of the amount of code.  
-   It has set a higher ratio comment in consideration of the maintenance.  
-   Redundant comment is unnecessary. Amount of redundant comment at the present time was about 43%.
+ - Aim at about 1/3 (33%) of the amount of code for the amount of comments.  
+   - A higher comment ratio is set in consideration of the maintenance.  
+   - Redundant comments are unnecessary. The amount of (redundant) comments at the present time was about 43%.  
 
- - Change history will continue only history of the header.  
-   Descriptions such as start and end point of the fixes are not required.
+ - Change history will continue only as the history of the header, even after the introduction of Git. Descriptions such as the start and end point of the fixes are not required.  
 
 ### Coding
- - Writing of duplicate code and information has been prohibited in this project.  
-   This is "Once and Only Once" or "Don't repeat yourself".
+ - Writing duplicate code and information is prohibited in this project.  
+   This is "Once and Only Once" or "Don't repeat yourself".  
 
- - Please keep in mind that it is limited to the statement  
-   that can be used in run-time which was specified in the project file.  
+ - This project is cross-compiled for C#, VB, .NET Framework (net48) and .NET Core (net10.0).  
+   However, the VB version is provided only for .NET Framework (net48).
 
-   For example, Contained the support of VS 2010 and .NET 3.5 previously  
-   (The current support is from VS 2015 and .NET 4.6 to latest version).  
-   e.g. , such as async/await keyword that can not be used in VS 2010 and .NET 3.5 has not been used in this project.
+ - Backward compatibility is highly maintained, and breaking changes are kept to a minimum.
+   - When supporting both a new and an old runtime, the implementation is aligned with the old one (e.g. async/await was not used while the support of VS 2010 and .NET 3.5 was included).
+   - Because .NET Framework (net48) and .NET Core (net10.0) are different lines, they are cross-compiled by using conditional compilation (preprocessor).
+   - Breaking changes are basically for the cases of discontinuation on the runtime side, and a sufficient "obsolete" period is provided before the change.
+
+### Coding agent
+The policy for making use of it is described in [AGENTS.md](AGENTS.md).
 
 ## C#, VB
- Provision of VB version is not required.  
- If necessary, we will converte to VB by using the Sharpdeveloper.
+ Provision of the VB version is not required. If necessary, we will convert it to VB by using tools (Sharpdeveloper, generative AI).  
 
 ## Flow
 
 ### GitHub Flow
- GitHubFlow is not adopted because there is no culture of the shipment  
- that test and push constantly and deploy the product every day.  
+ "Push the product every day, test it constantly and deploy it."  
+ GitHub Flow is not adopted because there is no such culture of shipment in this project.  
 
- - GitHub Flow - Scott Chacon（原文）  
-   http://scottchacon.com/2011/08/31/github-flow.html  
- - 上記記事の日本語訳  
-   https://gist.github.com/Gab-km/3705015
+ - GitHub Flow - Scott Chacon (original)  
+   https://scottchacon.com/2011/08/31/github-flow/  
+ - Japanese translation of the above article  
+   https://gist.github.com/Gab-km/3705015  
 
 ### git-flow
- This repository is based on the branch model of the the following URL.  
- - develop branch and master branch has been permanent.  
- - Create other branches as needed.
+ This repository is based on the git-flow branching model in "Reference" below.
+
+ - The master and develop branches are permanent.  
+ - Other branches are created as needed.  
 
 #### Reference
  - A successful Git branching model » nvie.com  
-   http://nvie.com/posts/a-successful-git-branching-model/  
+   https://nvie.com/posts/a-successful-git-branching-model/  
  - 見えないチカラ A successful Git branching model を翻訳しました  
-   http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html  
+   http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html  
+
+ Note that a note by the author (Note of reflection, 2020/03/05) has been added to the original article above,  
+ which states that git-flow is not recommended for web applications with continuous delivery and so on.  
+ As described above, this project is not operated to ship every day, so git-flow is adopted.  
 
 ### About the "pull request"
 
 #### Size of the "pull request"
- - Reduce the size of "commit" and "pull request" for review of "pull request".
+ - Reduce the size of the "commit" and the "pull request" for the review of the "pull request".  
 
- - If multiple tasks of bug or enhance are present in the one "pull request", one delay affects the other.
+ - If multiple tasks of bugs or enhancements are present in one "pull request", one delay affects the others.
 
- - For this reason, you must create a feature branch for each task of bug or enhance.  
-   After that, ask the review to me by sending each time "pull request" from the feature branch.
+ - For this reason, you need to create a feature branch for each task of a bug or an enhancement.  
+   After that, ask me for a review by sending a "pull request" from the feature branch each time.  
 
- - Also, please do not commit unnecessary changes that indentation is changed by the IDE or editor.
+ - Also, please do not commit unnecessary changes such as indentation changed by the IDE or the editor.  
 
 #### Send a "pull request"
- - Fork to the repository by each user from OpenTouryo repository.  
-   After having done fork, create a feature branch from the develop branch.  
+ - Fork from the OpenTouryo repository to the repository of each user.  
+   After that, create a feature branch from the develop branch and work on it.  
+
+ - Send the "pull request" from your feature branch to the develop branch of the fork source.  
 
- - Send "pull request" to the "develop branch of fork source" from your feature branch.
+ - If the develop branch of the fork source has been changed, do "pull" or "fetch & merge" to the feature branch.  
 
- - If "develop branch of fork source" was changed,  
-   then you should do the "pull" or "fetch & merge" operation to the feature branch.
+#### Notes for the "pull request"
+ - Keep the develop / feature branches up to date with the following steps.  
 
-#### Notes for "pull request"
- - You keep the develop / feature branch up to date as follows.  
+   1. "pull" or "fetch & merge" the develop branch of OpenTouryo into your develop / feature branch.  
+   2. Recreate the feature branch from your develop branch.  
+   3. Reflect the changes to the feature branch.  
+   4. Test and push, and then send the "pull request".  
 
-   - "pull" or "fetch & merge" OpenTouryo develop branch from your develop / feature branch.  
-     and you recreate the feature branch from your develop branch and you reflect changes to the feature branch.  
-     After that, test and push, and finally send "pull request".
+ - These steps serve the following two purposes.  
 
-   - There is also a way to fork again instead of pull or fetch & marge,  
-     but comments and changes that are not merged original fork source are lost.
+   - Keeping up with the changes of the develop branch of the fork source.  
+   - Preventing the commit log from being contaminated by rolling back the program after an incorrect change.  
 
- - To prevent contaminating the commit log by rolling back program after the incorrect change, follow these steps.  
-   - You recreate the feature branch from your develop branch.  
-   - And you reflect changes again to the feature branch.  
-   - After that, test and push, and finally send "pull request".
+ - There is also a way to fork again instead of "pull" or "fetch & merge", but the comments and the changes that are not merged into the fork source are lost.