Handle scientific FOM values in results

docs/ci.md

@@ -252,7 +252,7 @@ app support matrix、partial support、app entrypoint不足、`list.csv` 内の
 | Root Markdown or `docs/**/*` only / root Markdownまたは`docs/**/*`のみ | No benchmark-specific GitHub workflow / ベンチマーク用GitHub workflowなし | Skipped by `.gitlab-ci.yml` rules / `.gitlab-ci.yml` rulesでskip | Keep docs-only changes separate from benchmark logic changes / docsのみの変更はbenchmark logic変更と分ける |
 | `result_server/**/*` / `result_server/**/*` | `Result Server Tests` | Skipped by `.gitlab-ci.yml` rules / `.gitlab-ci.yml` rulesでskip | Portal regressions should be caught by lightweight Python tests / portal回帰はlightweight Python testで捕捉する |
 | Public site config or portal metadata `config/system.csv`, `config/queue.csv`, `config/system_info.csv` / 公開site configまたはportal表示メタデータ`config/system.csv`、`config/queue.csv`、`config/system_info.csv` | `Result Server Tests`, including site config preflight / site config preflightを含む`Result Server Tests` | `config/system.csv` and `config/queue.csv` run by `.gitlab-ci.yml`; `config/system_info.csv` is skipped / `config/system.csv`と`config/queue.csv`は`.gitlab-ci.yml`で実行、`config/system_info.csv`はskip | Public systems listed in `system_info.csv` must also exist in `system.csv` and reference a queue defined in `queue.csv` / `system_info.csv`に載せる公開systemは`system.csv`にも存在し、`queue.csv`定義済みqueueを参照する必要がある |
-| Portal upload or profile-data helper `scripts/bk_functions.sh`, `scripts/result.sh`, `scripts/result_server/**` / portal uploadまたはprofile-data helper `scripts/bk_functions.sh`、`scripts/result.sh`、`scripts/result_server/**` | `Result Server Tests` when covered by its path filter / path filter対象なら`Result Server Tests` | Not automatic for pull requests; runs only if a maintainer starts `GitLab Manual CI` / pull requestでは自動起動せず、maintainerが`GitLab Manual CI`を起動した場合のみ実行 | These helpers shape result JSON / upload behavior without requiring a full benchmark by default / これらのhelperはfull benchmarkを既定で要求せずにResult JSONやupload挙動へ影響する |
+| Portal upload or profile-data helper `scripts/bk_functions.sh`, `scripts/result.sh`, `scripts/result_server/**` / portal uploadまたはprofile-data helper `scripts/bk_functions.sh`、`scripts/result.sh`、`scripts/result_server/**` | `Result Server Tests` when covered by its path filter / path filter対象なら`Result Server Tests` | GitHub pull requests do not start GitLab by default; if a direct/manual GitLab pipeline is started, `scripts/**/*` is treated as benchmark-affecting and runs / GitHub pull requestでは既定でGitLabは起動しない。直接/手動GitLab pipelineを起動した場合、`scripts/**/*` はbenchmark影響ありとして実行される | These helpers shape result JSON / upload behavior. Use lightweight tests first, then start `GitLab Manual CI` when benchmark-side behavior needs validation / これらのhelperはResult JSONやupload挙動へ影響する。まずlightweight testで確認し、benchmark側挙動の検証が必要な場合は`GitLab Manual CI`を起動する |
 | Benchmark app code or other shared scripts / benchmark appコードまたはその他の共通script | Normal GitHub review checks only / 通常のGitHub review checkのみ | Run through `GitLab Manual CI` when maintainer starts it / maintainerが`GitLab Manual CI`を起動した場合に実行 | Use `code` and `system` filters when broad validation is unnecessary / 広範な検証が不要なら`code`と`system`を指定する |
 | GitHub workflow/action `.github/**/*` / GitHub workflow/action `.github/**/*` | Workflow-specific checks when paths match / path一致時にworkflowごとのcheck | Skipped by `.gitlab-ci.yml` rules / `.gitlab-ci.yml` rulesでskip | GitHub workflow/action changes affect API-calling or sync control logic. Validate them on the GitHub side; they are pushed to GitLab with `ci.skip` during protected-branch sync / GitHub workflow/action変更はAPI呼び出しやsync制御に影響する。GitHub側で確認する。protected-branch syncでは`ci.skip`付きでGitLabへpushされる |
 | `.gitlab-ci.yml` / `.gitlab-ci.yml` | Normal GitHub review checks only / 通常のGitHub review checkのみ | Run through `GitLab Manual CI` when a maintainer needs to validate GitLab pipeline behavior / GitLab pipeline挙動の検証が必要な場合にmaintainerが`GitLab Manual CI`で実行 | This file defines GitLab benchmark pipeline behavior / このファイルはGitLab benchmark pipeline挙動を定義する |
@@ -269,7 +269,7 @@ Use these examples when deciding whether to split a pull request or start GitLab
 | `result_server/routes/results_usage_routes.py` and `result_server/templates/*.html` / `result_server/routes/results_usage_routes.py`と`result_server/templates/*.html` | `Result Server Tests` should run / `Result Server Tests`が動く | No benchmark run unless a maintainer intentionally starts one / maintainerが意図して起動しない限りbenchmark不要 |
 | `config/system_info.csv` only / `config/system_info.csv`のみ | `Result Server Tests` should verify public site config consistency / 公開site config整合性を`Result Server Tests`で確認 | No benchmark run because this file is portal display metadata / portal表示metadataなのでbenchmark不要 |
 | `config/system.csv` or `config/queue.csv` for a public system / 公開system向けの`config/system.csv`または`config/queue.csv` | `Result Server Tests` should run the site config preflight / `Result Server Tests`でsite config preflightを実行 | Start `GitLab Manual CI` too when benchmark execution behavior needs validation / benchmark実行挙動の検証が必要なら`GitLab Manual CI`も起動 |
-| `scripts/bk_functions.sh`, `scripts/result.sh`, or `scripts/result_server/**` only / `scripts/bk_functions.sh`、`scripts/result.sh`、または`scripts/result_server/**`のみ | `Result Server Tests` should run when the path filter matches / path filter対象なら`Result Server Tests`が動く | Manual GitLab CI is optional and only needed if upload behavior affects benchmark operation / upload挙動がbenchmark運用に影響する場合だけ手動GitLab CIを検討 |
+| `scripts/bk_functions.sh`, `scripts/result.sh`, or `scripts/result_server/**` only / `scripts/bk_functions.sh`、`scripts/result.sh`、または`scripts/result_server/**`のみ | `Result Server Tests` should run when the path filter matches / path filter対象なら`Result Server Tests`が動く | Protected-branch sync uses `ci.skip`; direct/manual GitLab pipelines run because `.gitlab-ci.yml` treats `scripts/**/*` as benchmark-affecting / protected branch syncは`ci.skip`を使う。直接/手動GitLab pipelineでは`.gitlab-ci.yml`が`scripts/**/*`をbenchmark影響ありとして扱うため実行される |
 | `programs/qws/**/*` or `scripts/job/**/*` / `programs/qws/**/*`または`scripts/job/**/*` | Normal GitHub review checks / 通常のGitHub review check | Start `GitLab Manual CI` when benchmark validation is needed, preferably with explicit `code` and `system` filters / benchmark検証が必要なら`code`と`system`を明示して`GitLab Manual CI`を起動 |
 | `.github/workflows/sync-to-gitlab.yml` or `.github/actions/prepare-gitlab-repo/action.yml` / `.github/workflows/sync-to-gitlab.yml`または`.github/actions/prepare-gitlab-repo/action.yml` | Validate on the GitHub Actions side / GitHub Actions側で確認 | Skipped by `.gitlab-ci.yml` rules when changed alone; protected-branch sync pushes it with `ci.skip` / 単独変更なら`.gitlab-ci.yml` rulesでskip。protected-branch syncでは`ci.skip`付きでpushされる |
 | `.gitlab-ci.yml` / `.gitlab-ci.yml` | Review the GitLab rule diff carefully / GitLab rule差分を慎重にreview | Start `GitLab Manual CI` if rule behavior itself needs validation / rule挙動そのものの検証が必要なら`GitLab Manual CI`を起動 |

docs/cx/BENCHKIT_GAP_ANALYSIS.md

@@ -58,7 +58,7 @@ Continuous estimation has now moved beyond a mere entry point: a common estimati
 However, estimation is still not yet broadly deployed across multiple applications, and AI-driven optimization integration remains mostly at the integration-point stage.
 
 As of the current repository survey, BenchKit has six benchmark applications with `build.sh`/`run.sh`, but only `qws` has an `estimate.sh`.
-The result portal also already has a meaningful test base (`result_server/tests`: 34 `test_*.py` modules), and the repository now has a repo-local Python dependency manifest, a standard portal test entrypoint under `result_server/tests`, and a lightweight GitHub Actions verification path for portal-oriented changes.
+The result portal also already has a meaningful test base (`result_server/tests`: 36 `test_*.py` modules), and the repository now has a repo-local Python dependency manifest, a standard portal test entrypoint under `result_server/tests`, and a lightweight GitHub Actions verification path for portal-oriented changes.
 The main GitLab pipeline still intentionally skips heavy benchmark execution when a direct or manually triggered GitLab pipeline sees changes limited to `result_server/**/*` or portal display metadata such as `config/system_info.csv`. Protected-branch synchronization itself uses `ci.skip`, so the dedicated lightweight GitHub Actions path should continue to be kept in sync as portal-side files evolve.
 
 ## 2.1 現時点で明示しておく設計負債 / Explicit Design Debts to Keep Visible
@@ -296,7 +296,7 @@ Once the estimation specification is clarified, many other design decisions beco
 
 今回のコードベース調査では、性能推定に次ぐ実務上の詰まりどころとして、`result_server` の検証導線が見えた。
 
-- `result_server/tests` には 34 個の `test_*.py` モジュールがあり、portal 側はすでに「検証すべき対象」になっている
+- `result_server/tests` には 36 個の `test_*.py` モジュールがあり、portal 側はすでに「検証すべき対象」になっている
 - repo-local な依存関係定義として `requirements-result-server.txt` があり、`result_server/tests/run_result_server_tests.py` が標準 test entrypoint として使える
 - portal-oriented 変更向けの lightweight GitHub Actions として `.github/workflows/result-server-tests.yml` が用意されている
 - `.gitlab-ci.yml` は直接または手動起動されたGitLab pipelineで `result_server/**/*` や `config/system_info.csv` 変更時に重い benchmark pipeline を skip する。保護ブランチ同期自体は `ci.skip` を使うため、GitHub Actions 側の path filter を portal 周辺の実ファイルに追従させ続ける必要がある
@@ -315,15 +315,15 @@ CI 関連の残 GAP は、「仕組みを新規に置く」段階から「対象
 短期的な実装・確認は次の状態まで進んでいる。
 
 1. `result-server-tests.yml` の path filter は、`result_server/**/*`、`scripts/bk_functions.sh`、`scripts/result.sh`、`scripts/result_server/**`、profile-data shell tests、`config/system.csv`、`config/queue.csv`、`config/system_info.csv`、`requirements-result-server.txt` を対象にする形へ更新済みである。
-2. `.gitlab-ci.yml` の heavy benchmark skip rules と `docs/ci.md` の説明は、root Markdown、`docs/**/*`、`result_server/**/*`、public site config / profile-data helper 周辺の lightweight verification 経路の扱いが一致するよう同期済みである。
+2. `.gitlab-ci.yml` の heavy benchmark skip rules と `docs/ci.md` の説明は、root Markdown、`docs/**/*`、`result_server/**/*`、`requirements-result-server.txt`、`config/system_info.csv` の skip 対象について同期済みである。一方、`scripts/bk_functions.sh`、`scripts/result.sh`、`scripts/result_server/**` は GitHub Actions の lightweight verification 対象でもあるが、直接または手動で GitLab pipeline を起動した場合は `.gitlab-ci.yml` の `scripts/**/*` rule により benchmark-affecting として実行される。
 3. 手動 GitLab CI は、`qws` / `MiyabiG` の最小実行で GitLab pipeline 起動から推定まで確認済みである。Pipeline API variables は JSON payload で渡す。
 4. protected branch sync は、`ci.skip` により GitLab mirror 更新時に GitLab CI が自動起動しないことを運用上確認済みである。
 
 docs-only / portal-only / benchmark-code / CI-config の代表的な変更セットは、`docs/ci.md` の examples として整理済みである。
 公開 `system_info.csv` に載せた system が `system.csv` と `queue.csv` に到達できることは、`result_server/tests/check_site_config.py` による CI preflight として整理済みである。逆に、開発用・非公開用の `system.csv` / `queue.csv` 定義が `system_info.csv` に載っていないことは許容する。
 app support matrix、partial support、app entrypoint 欠落、`list.csv` の未知 system などは、アプリごとの準備状況や導入段階に依存するため、現時点では CI failure ではなく `/results/usage` の visibility として扱う。
 
-完了条件は、変更種別ごとの期待 CI 経路が文書化され、path filter と skip rules がその期待に一致し、portal 実装変更が heavy benchmark を起動せず lightweight verification で捕捉されることである。Result JSON quality は portal 内の内部管理として可視化し、通常 PR の blocking rule にはしない。
+完了条件は、変更種別ごとの期待 CI 経路が文書化され、path filter と skip rules がその期待に一致し、portal 実装変更が heavy benchmark を起動せず lightweight verification で捕捉されることである。Result JSON / upload helper の変更は lightweight verification でまず捕捉しつつ、GitLab pipeline を明示起動した場合は benchmark-affecting script として扱う。Result JSON quality は portal 内の内部管理として可視化し、通常 PR の blocking rule にはしない。
 
 ### 5.3 次点: AI 駆動最適化連携 / Next Priority: AI-Driven Optimization
 

scripts/bk_functions.sh

@@ -125,8 +125,8 @@ bk_emit_result() {
       ;;
   esac
 
-  # Normalize scientific notation (e.g. 3.64E+01 -> 36.415) to plain decimal
-  # result.sh parses with grep -Eo 'FOM:[ ]*[0-9.]*' which doesn't match E notation
+  # Canonicalize scientific notation where awk can do so without losing precision.
+  # Very small values may remain in scientific notation; result.sh accepts both.
   case "$_bk_fom" in
     *[eE]*)
       _bk_fom=$(awk "BEGIN {printf \"%.17g\", $_bk_fom}")

scripts/result.sh

@@ -294,8 +294,8 @@ while IFS= read -r line; do
     sections_json=""
     overlaps_json=""
 
-    # Parse FOM line (existing logic)
-    fom=$(echo $line | grep -Eo 'FOM:[ ]*[0-9.]*' | head -n1 | awk -F':' '{print $2}' | sed 's/^ *//')
+    # Parse FOM line. Values may be decimal or scientific notation.
+    fom=$(printf '%s\n' "$line" | grep -Eo 'FOM:[ ]*[-+]?([0-9]+([.][0-9]*)?|[.][0-9]+)([eE][-+]?[0-9]+)?' | head -n1 | awk -F':' '{print $2}' | sed 's/^ *//')
     if [ -z "$fom" ]; then
       fom=null
     fi

scripts/tests/test_result_profile_data.sh

@@ -15,7 +15,7 @@ if ! command -v jq >/dev/null 2>&1; then
 fi
 
 cat > "${TMP_DIR}/results/result" <<'EOF'
-FOM:1.234 FOM_version:test Exp:CASE0 node_count:1 numproc_node:1 nthreads:2
+FOM:9.9999999999999995e-07 FOM_version:test Exp:CASE0 node_count:1 numproc_node:1 nthreads:2
 EOF
 
 cat > "${TMP_DIR}/bk_profiler_artifact/meta.json" <<'EOF'
@@ -79,6 +79,7 @@ popd >/dev/null
 RESULT_JSON="${TMP_DIR}/results/result0.json"
 test -f "${RESULT_JSON}"
 jq -e '
+  .FOM == "9.9999999999999995e-07" and
   .profile_data.tool == "fapp" and
   .profile_data.level == "single" and
   .profile_data.report_format == "text" and