bizboost 6.6.2 → 6.6.8

package/README.md

@@ -16,6 +16,68 @@ bluelamp42    # slot #42
 # ...
 ```
 
+## 配布物が難読化されていることについて
+
+npm で配布している `bluelamp` の `dist/` は、**意図的に難読化してあります**。中身がそのまま読めないのはビルドの設計であって、隠しごとではありません。以下にその理由と、正規のビルドであることの確かめ方を記します。
+
+### なぜ難読化しているのか
+
+- **認証とトークンの取り扱いを守るため。** この CLI は利用者の資格情報とアクセストークンを端末上で扱います。その取り回しを読める形のまま配ると、なりすましやトークンの窃取を試みる側に手順を渡すことになります。
+- **当社の知的資産を守るため。** BlueLamp の価値は積み上げてきた設計そのものにあり、配布物はその一部を含みます。
+
+難読化が掛かるのは配布物 (`dist/`) だけです。**ソースは非公開です。** そのうえで、配布物が当社の CI が出した正規ビルドであることは、第三者の立場で検証できます (下の「正規のビルドであることの確かめ方」)。ビルドの段取りそのものは下の「ビルド出力」の節のとおりです。
+
+### 利用者にとって何が変わらないのか
+
+- **機能・挙動は変わりません。** 難読化は publish 用ビルドの最終工程で、実行される処理は tsc が出したものと同じです。
+- **通信先は増えません。** CLI が接続するのは当社ポータルの API と、起動する Claude Code だけです。送信先はコードに固定されており、設定で任意の URL に向け替えることはできません。
+- **第三者の解析サービスへの送信はありません。** テレメトリ / 解析 SDK を同梱していません。当社ポータルとの通信は認証と機能提供のためのものです。
+- **認証トークンは利用者の端末内 (`~/.musuhi/portal-token.enc`) にのみ保存されます。**
+
+### 正規のビルドであることの確かめ方
+
+公開されている tarball が当社の CI が出した正規ビルドであることは、**第三者の立場で検証できます**。署名は cosign の keyless 署名で行い、その記録は公開の透明性ログ (Rekor) に載ります。
+
+🔑 **下の手順 1・2 で参照するのは npm registry と公開 Rekor だけで、当社のサーバーは一切登場しません。** 当社を信用しなくても確かめられる、というのがこの手順の要点です。必要なのは `curl` / `openssl` / `node` だけで、**cosign のインストールは要りません**。
+
+**1. registry が配っている tarball を取得し、ハッシュを出す**
+
+```bash
+V=<インストールした版>          # npm ls -g bluelamp で確認できます
+curl -sSL "https://registry.npmjs.org/bluelamp/-/bluelamp-$V.tgz" -o "bluelamp-$V.tgz"
+shasum -a 256 "bluelamp-$V.tgz"
+```
+
+**2. そのハッシュで公開透明性ログ (Rekor) を引く**
+
+```bash
+SHA=<手順 1 で出た 64 桁>
+curl -s -X POST -H 'Content-Type: application/json' \
+  -d "{\"hash\":\"sha256:$SHA\"}" \
+  https://rekor.sigstore.dev/api/v1/index/retrieve
+```
+
+エントリが返れば、その tarball が当社の GitHub Actions によって署名され、公開ログに記録されていることを意味します。
+
+**3. さらに厳密に確かめる場合** — 証明書チェーンと署名者の固定まで検証するスクリプトをパッケージに同梱しています。グローバルインストールなら次の 1 行で実行できます (依存は上と同じ `curl` / `openssl` / `node` だけです)。
+
+```bash
+"$(npm root -g)/bluelamp/verify-release.sh" "$V"
+```
+
+⚠️ **信頼の起点は手順 1・2** — ご自身の手で公開ログを引き、目で読む記録 — の側にあります。検証を代行するスクリプトを配布物に同梱しても、それは信頼の起点にはなりません (改ざんされた tarball は、改ざんされた検証器を同梱することもできるためです)。
+
+📌 署名が付くのは、この README を同梱した版以降のリリースです。それより前の版では手順 2 でエントリが返りませんが、改ざんを意味するものではありません。
+
+### ウイルス対策ソフトが反応した場合
+
+難読化されたコードは、その形からヒューリスティックに検知されることがあります (誤検知)。お使いのウイルス対策製品が `bluelamp` を検知した場合は、下記の窓口から誤検知として報告できます。
+
+- **各ウイルス対策ベンダーの窓口一覧**: https://docs.virustotal.com/docs/false-positive-contacts
+  VirusTotal 自身は判定を出さず、誤検知は各エンジンのベンダーへ直接報告する形になっています。上記ページに 150 社以上の窓口がまとまっているので、検知した製品の窓口から報告してください。
+- **Microsoft Defender (Windows)**: https://www.microsoft.com/en-us/wdsi/filesubmission
+  サインイン不要でファイルを送信でき、誤検知として申告できます。
+
 ## 構成
 
 - `src/auth/` — Portal API auth client + token manager + interactive login
@@ -131,3 +193,16 @@ publish 対象は `dist/` + `README.md` のみ (`package.json files` で制限)
 2. 4.3.4〜6.4.1 が `playwright` / `gmail` 等をキー名だけで無条件 delete していた。利用者が自分で登録した同名 MCP を黙って消しうる。
 
 **ルール: 今後 `~/.mcp.json` に触る処理を足す場合は、我々が書いた entry だと確認できるものだけを対象にする** (キー名一致だけで削除しない。他人の設定を消さない)。
+
+## 開発時の注意: ソースツリーから直接動かさない
+
+`lib/mcp-server/` は **`dist/` レイアウト前提**です（`require('../../utils/logger')` は
+`dist/lib/mcp-server/` に置かれたときにだけ解決します）。ソースツリーの `lib/` を直接
+起動すると `MODULE_NOT_FOUND` になり、スロット設定の取得が既定へ degrade します。
+
+```bash
+pnpm run build   # dist/ を作ってから
+```
+
+⛔ require パスの二重化はしません（板 #442 ④）。ソースから動かしたときは、
+エラーメッセージが真因（＝ソースツリー直実行）を指します。