stack-chan

# Visual Programming評価手順

## 評価対象

評価対象は、ローカルSDKを使ったことがない参加者です。

参加者ごとに新しいブラウザプロファイルを用意します。

評価者は操作方法を説明せず、チュートリアルの場所だけを伝えます。

## 計測する時点

- エディタを開いた時点
- 最初のビルドに成功した時点
- 最初のシミュレーター実行に成功した時点
- 最初の実機書き込みに成功した時点
- ビルド、USB接続、互換性確認に失敗した時点

エディタはこれらの時点をブラウザ内へ記録します。

評価終了後にヘッダーの評価ログ保存ボタンからJSONを保存します。

## 合格条件

- 15分以内にサンプルの表情か発話を変更し、シミュレーターで再実行できる。
- 対象機種にない能力を配置した場合、実機書き込みより前に理由を確認できる。
- 実行時エラーが発生した場合、対応するブロックへ戻れる。
- 実機書き込み前にチップ、パーティション、サイズ、使用能力を確認できる。
- 書き込み済みMODをバックアップから復元できる。

## 記録

評価ログにはブラウザ識別文字列が含まれます。

公開レポートへ転記する場合は、個人を識別できる拡張機能名や管理情報が含まれていないことを確認します。

複数参加者のログは、最初のシミュレーター実行までの中央値と失敗種別ごとの件数を集計します。

ログを同じディレクトリへ集め、次のコマンドで集計します。

```sh
cd web
npm run metrics:aggregate -- participant-1.json participant-2.json
```

集計結果には、参加者数、15分以内のシミュレーター成功数、最初のシミュレーター実行までの中央値、ビルド失敗数、実機失敗数が含まれます。

## 自動検証の実施記録

2026年7月14日から15日に、実機を使用しない範囲を次の条件で検証しました。

- Webの22テストファイル、163件の試験がすべて成功した。
- 5サンプルを実際にXSAへコンパイルした。
- XSA、プロジェクト、評価ログ、破損データ退避の各ダウンロードについて、ファイル名と内容をブラウザ内で検証した。
- 5 MiBを超えるプロジェクトをIndexedDBへ保存し、ページ再読込後に復元した。
- 破損したIndexedDB状態を退避し、復旧用JSONとして保存できることを確認した。
- 統合シミュレーターでXSAの起動、再起動、停止を行い、2回目の起動まで確認した。
- 統合シミュレーターは、ファームウェアが`[main] app behaviors ready`を出力した後に起動成功を通知することを確認した。
- 統合シミュレーターのAボタンからWASM入力ブリッジを通してMODの入力ハンドラーを起動し、実行時エラーのログ表示と実際に失敗したループブロックの選択を確認した。
- Shape顔エディターでFace領域、左右の目、まぶた、口を編集し、プレビュー上で左目をドラッグした。バージョン1のJSONとして保存して再読込した後、ブロックエディターへ渡し、`FaceBase.template`を含むXSAをビルドして統合シミュレーター上のFaceが置き換わることを確認した。
- 外部ESモジュールを改ざんした場合、完全性検査によってシミュレーター起動が拒否されることを確認した。
- エディター、チュートリアル、顔エディター、シミュレーターをデスクトップ幅と390 px幅で確認し、エディターは600 px幅でもプロジェクトメニューへ到達できることを確認した。
- シミュレーターの320×240画面出力を直接保存し、Wi-Fi設定、ネットワーク一覧、パスワード入力、通常顔、ドロワー、顔選択、犬顔、カメラ、カメラ終了後の各画面に欠けや重なりがないことを確認した。
- 実ブラウザのスクリプト操作で初回ビルドと初回シミュレーター成功が評価ログへ記録され、初回シミュレーター成功が15分基準内であることを確認した。
- 複数の評価ログファイルを集計CLIへ渡し、参加者数、15分以内の成功数、中央値、失敗数をJSONとして出力できることを確認した。
- 390 px幅ではプロジェクトメニューから新規、複製、対象変更、最近使ったプロジェクト、サンプル、評価ログ、復旧、チュートリアル、全消去へ到達できることを確認した。
- 全Webツールで左上のハンバーガーボタンから共通ツールドロワーを開き、現在ページを識別できることと、従来の右上ツールナビゲーションが残っていないことを確認した。
- ワークスペース消去では確認ダイアログに現在のプロジェクト名を表示し、キャンセル時は生成コードを維持し、確定時だけ空ワークスペースを自動保存することを確認した。
- キーボードによるタブ移動とダイアログのEscキー終了を確認し、全主要ページの表示中の操作要素にアクセシブルネームがあることを検査した。
- 模擬ローダーで、読戻し照合が失敗した場合に成功を返さず、再起動も行わないことを確認した。
- ファームウェア単体試験34ファイルとアーキテクチャ試験11ファイルが成功した。
- 6ターゲットのmanifest検査、22件のModdableテストmanifest、416ファイルのlintが成功した。
- Linuxシミュレーターを10秒間動作させ、`[main] app behaviors ready`まで到達し、異常終了しないことを確認した。
- 同梱サンプルMODをModdable SDK 8.3.1のrelease構成、XS 17.8.0、名前付き`onContextCreated`契約で再生成し、統合シミュレーターへのアップロード後に「適用済み」へ遷移することを確認した。
- 同梱サンプルMODを異なるソースパスから再生成してもSHA-256 `75471d397bbc118aeba18c83baea72ce664dbeb27ee90a1541a6b9309584367c`で一致し、`/home/`、`/Users/`、`/tmp/`を含まないことを確認した。
- 同梱サンプルMODによって顔がピンク、目と口がシアンへ変わり、`sample .xsa OK`の吹き出しが表示されることを画面画像で確認した。
- Moddable SDK 8.3.1とEmscripten 5.0.1から、WASM入力ブリッジを含むシミュレーターファームウェアを再生成した。
- Moddable SDK 8.3.1とEmscripten 5.0.1からブラウザ用ビルドツールを再生成し、追跡済み成果物と一致することを確認した。
- 配信ワークフローでもブラウザ用ビルドツールを再生成し、完全性検査と追跡済み成果物との差分検査に合格した場合だけ公開処理へ進むようにした。
- ブラウザ用ビルドツールをEmscripten 5.0.1で2回再生成し、`tools.js`のSHA-256が`f24188a0ef7ac675a52724e028e1a8d18436b1b57436702c2797d7aa1d810157`、`tools.wasm`が`491eda86686136659670bd5428ec68cdd1c6d8dee4ef2a641d7d606bf3d0e21a`で再現することを確認した。
- `m5stack_cores3`、`m5stackchan_cores3`、`stackchan_rt`、`takao_core2_sg90`のターゲットビルドが成功した。
- Moddable SDK 8.3.1でCoreS3 WebRadioを追加した`develop`へ追従した後も`m5stackchan_cores3`のビルドが成功し、app partitionは74%空いていることを確認した。
- Web依存関係の監査結果は脆弱性0件だった。
- ファームウェアの実行依存を対象にした監査結果は脆弱性0件だった。

## CoreS3実機検証記録

2026年7月15日に、`/dev/ttyACM0`へ接続したM5Stack-chan CoreS3を次の条件で検証しました。

- チップはESP32-S3 rev 0.2、フラッシュは16 MiB、接続はUSB-Serial/JTAGだった。
- factoryアプリは`xs_esp32 8.3.0-1-gacf3d5262-dirty`で、対応するMODのXS版は17.8.0だった。
- `xs`パーティションはoffset `0xfa0000`、size `0x40000`で、接続時の先頭4 KiBは全`0xFF`だった。
- 接続時の先頭4 KiBを退避し、SHA-256 `f47a8ec3e9aff2318d896942282ad4fe37d6391c82914f54a5da8a37de1300c6`を記録した。
- 2,491バイトのXS 17.8.0アーカイブを書き込み、アプリ起動前の読戻しが書き込み元のSHA-256 `1d6fd2e6be787276512b068cce48223843a5b16923897ee4bbe8a4da38d9c156`と一致した。
- 再起動後に通常アプリが`[main] app context created`、MODが`[vp-hardware] mod ready`、通常アプリが`[main] app behaviors ready`の順で出力し、10秒間に例外や再起動ループが発生しないことを確認した。
- 起動後に読み出したアーカイブでは、XSランタイムによる識別子マッピングで`IDEN`とバイトコードが更新されていた。
- 起動後のアーカイブをバックアップし、MOD削除後の先頭4 KiBが全`0xFF`であることと、通常アプリがMOD固有トレースなしで起動することを確認した。
- 起動後バックアップを復元し、読戻しがバックアップと一致することと、`[vp-hardware] mod ready`が再度出力されることを確認した。
- 最後に接続時の先頭4 KiBを復元し、接続時と最終状態のSHA-256が一致することと、`SPI_FAST_FLASH_BOOT`でMODなしの通常アプリが起動することを確認した。

実機検証では、esptool v5.3.dev2 CLIを使い、WebSerial実装と同じ順序でパーティションテーブル、factoryアプリ記述子、既存MODを読み、書き込み、起動前の読戻し照合、再起動、削除、復元を実施しました。

シリアル制御線の状態によって一度ダウンロードモードへ入ったため、DTRを解除したままRTSでENをパルスし、通常起動へ戻したことも確認しました。

## Moddable SDK 8.3.1による全デバイスバンドル問題の解消

Moddable SDK 8.3.0では、`com.m5stack`のfactory app partition超過と、`com.m5stack.fire`の`embedded:io/audio/in`解決失敗を検出しました。

Moddable SDK 8.3.1へ更新したCIで`npm run bundle`を再実行し、`mcbundle`、M5StackChan CoreS3の追加ビルド、4対象のバイナリ存在検査、factory app partition容量検査、ZIP生成がすべて成功しました。

- `com.m5stack`: 3,762,000 / 3,801,088バイト（39,088バイト空き）
- `com.m5stack.core2`: 3,828,144 / 16,384,000バイト
- `com.m5stack.cores3`: 3,933,888 / 16,318,464バイト
- `m5stackchan_cores3`: 4,018,224 / 16,318,464バイト

したがって、8.3.0で検出した全デバイスバンドル問題は8.3.1更新後のCIで再現せず、全デバイスバンドルを合格としました。

評価参加者による15分指標の測定も未実施です。

Webとファームウェアは、開発依存を含む`npm audit`で脆弱性0件です。