# Deployment / Architecture Findings

## 1. P0: 本流ノード定義が欠損パス参照で評価不能

- `flake.nix` の `nixosConfigurations.node01/02/03` は、`./docs/por/T036-vm-cluster-deployment/...` を参照している。
  - `flake.nix:486`
  - `flake.nix:498`
  - `flake.nix:510`
- しかし実ワークツリーに `docs/` が存在しない。
  - `ls docs` -> `No such file or directory`
- 参照先も実在しない。
  - `docs/por/T036-vm-cluster-deployment/node01/configuration.nix` (missing)
  - `.../node02/configuration.nix` (missing)
  - `.../node03/configuration.nix` (missing)

実証:

- `nix eval --show-trace .#nixosConfigurations.node01.config.system.build.toplevel.drvPath`
  - `path .../docs/por/T036-vm-cluster-deployment/node01/configuration.nix does not exist`

影響:

- 本流 `flake` から node01/02/03 を評価・ビルドできない。
- インフラ定義の単一正本が壊れており、デプロイ作業を自動化できない。

---

## 2. P0: ISO 自動インストールが欠損 `disko.nix` に依存

- ISO の自動インストールサービスは、リポジトリ同梱ソース内の以下を実行:
  - `nix/iso/plasmacloud-iso.nix:236`
  - `nix run github:nix-community/disko -- --mode disko /opt/plasmacloud-src/docs/por/T036-vm-cluster-deployment/$NODE_ID/disko.nix`
- しかし当該 `disko.nix` 群も存在しない（node01/02/03 すべて missing）。

影響:

- PXE/ISO ブート後の自動インストールが停止し、継続不能。

---

## 3. P0: ブートストラップの鶏卵問題（Deployer依存の経路未接続）

- ISO は `DEPLOYER_URL` を既定で `http://deployer.local:8080` とする。
  - `nix/iso/plasmacloud-iso.nix:48`
- Phone Home は `POST $DEPLOYER_URL/api/v1/phone-home` 固定。
  - `nix/iso/plasmacloud-iso.nix:90`
- 一方で flake 出力/モジュール配線に deployer がない:
  - `rg "deployer" flake.nix` -> no matches
  - `rg "deployer" nix/modules` -> no matches
  - `nix flake show . --all-systems | rg deployer` -> no matches
- CI 側は deployer ワークスペースを対象にしており、存在自体は前提化されている。
  - `.github/workflows/nix.yml:49`
  - `.github/workflows/nix.yml:61`
  - `.github/workflows/nix.yml:79`

影響:

- 「まず何をどこに立てるか」が定義されておらず、ゼロからの起動手順が閉じない。
- 外部手動依存（DNS/Deployer 先行配置）を暗黙要求するため、再現性が低い。

---

## 4. P1: first-boot automation の join 設計が実装と不整合

### 4-1. `leader_url` スキーム/ポート不整合

- `first-boot-automation` の既定 `leader_url` は `https://localhost:2379`。
  - `nix/modules/first-boot-automation.nix:37`
  - `nix/modules/first-boot-automation.nix:46`
  - `nix/modules/first-boot-automation.nix:83`
- `plasmacloud-cluster` / `nix-nos topology` が生成する `leader_url` も `https://<ip>:<apiPort>`。
  - `nix/modules/plasmacloud-cluster.nix:63`
  - `nix/modules/nix-nos/topology.nix:110`
- しかし Chainfire の join 互換エンドポイントは HTTP REST 側 (`/admin/member/add`)。
  - `chainfire/crates/chainfire-server/src/rest.rs:143`
  - `chainfire/crates/chainfire-server/src/rest.rs:404`
- Chainfire HTTP は plain `axum::serve`。
  - `chainfire/crates/chainfire-server/src/server.rs:175`
  - `chainfire/crates/chainfire-server/src/server.rs:178`

### 4-2. FlareDB join エンドポイント不在

- first-boot は FlareDB にも `/admin/member/add` を叩く設計。
  - `nix/modules/first-boot-automation.nix:266`
  - `nix/modules/first-boot-automation.nix:270`
- しかし FlareDB REST ルータには当該エンドポイントがない（`/health` 等のみ）。
  - `flaredb/crates/flaredb-server/src/rest.rs:149`
  - `flaredb/crates/flaredb-server/src/rest.rs:156`

### 4-3. 実 join リクエストで TLS 緩和なし

- join の curl は `-k` を付けず `"$LEADER_URL$leaderUrlPath"` を叩く。
  - `nix/modules/first-boot-automation.nix:147`
  - `nix/modules/first-boot-automation.nix:148`

影響:

- first-boot を有効化した場合、Chainfire/FlareDB join が高確率で失敗。

---

## 5. P1: テストクラスタ定義の評価失敗（複数ノード）

- `node02` / `node03` は `services.chainfire.joinAddr` を設定するが、option 未定義。
  - `nix/test-cluster/node02.nix:33`
  - `nix/test-cluster/node03.nix:33`
  - `nix/modules/chainfire.nix` option 定義に `joinAddr` なし（`7-76` 範囲）
- 実証:
  - `nix eval ./nix/test-cluster#nixosConfigurations.node02...`
  - `The option services.chainfire.joinAddr does not exist`
  - `node03` でも同一エラー

追加で `node06` も評価失敗:

- `creditservice` module が `config.services.flaredb` を直接参照:
  - `nix/modules/creditservice.nix:5`
- `node06` は `flaredb` module を import していない:
  - `nix/test-cluster/node06.nix:8-13`
- 実証:
  - `nix eval ./nix/test-cluster#nixosConfigurations.node06...`
  - `error: attribute 'flaredb' missing`

影響:

- テストクラスタ全体を評価・起動する前提が崩れている。

---

## 6. P2: トポロジ生成ロジックの二重実装

- `cluster-config` 生成ロジックが以下2箇所に重複:
  - `nix/modules/plasmacloud-cluster.nix:49-91`
  - `nix/modules/nix-nos/topology.nix:91-136`

影響:

- 将来変更時に片側だけ更新され、挙動が分岐するリスク。

---

## 7. P2: CI/品質ゲート観点で `doCheck = false` が多い

- 複数主要サービスで `doCheck = false` が残留。
  - `flake.nix:206`
  - `flake.nix:240`
  - `flake.nix:263`
  - `flake.nix:276`
  - `flake.nix:290`
  - `flake.nix:306`
  - `flake.nix:329`
  - `flake.nix:345`

影響:

- 回帰の早期検出能力が低く、設定不整合を CI で検知しにくい。