fullseye

strict_mode() が経路の一部しか厳密にしていなかった(+ 0.2.1 再測定の 4 件)

症状

GenSpark 第 55 報(0.2.1 を入れ直しての再測定、2026-09-20)。修正確認 8 件のあと、残存 8 件・新規 4 件。

なぜ門が通したか

strict の門は test_guard_reraises_in_strict_mode(op 本体)と GPU の注入だけで、入力型の門は on_error="raise" で 試験していた。同じ言葉(strict)を使う経路を数えて 1 本にする([[feedback_count_wrapper_families_not_mechanisms]])。

直し

  1. api._policy: on_error=None で is_strict() なら "raise"。strict_mode / set_strict / FULLSEYE_STRICT が 入力型・非有限出力・op 本体・GPU・高速路の全部で同じ意味に。明示の on_error は文脈より強い(引数 > 文脈 > 環境変数 > 既定)。
  2. opassist.run: 先頭が文字列でなければ「the first argument is the op name … op_run(name, )」の TypeError、 台帳に無く registry に在る名前は「run it with fullseye.apply(img, name)」を添える。
  3. fullseye/__main__.py: python -m fullseye = CLI(imgevolve.main)。
  4. fullseye index: 書き先の既定は checkout では docs/OP_INDEX.json、docs/ の無い場所(wheel)では cwd。 出力に「this environment vs the shipped index: N missing here」と、欠けた op が要る backend と pip install の行。
  5. unified.Pipeline: 3 要素タプルの文に「knob stages (name, a, b) belong to run_pipeline / FullseyeEngine」。

同じ報で分けたもの: N148 op_names 既定に n-ary 無し = 設計(include_nary=True)/ N153 既定 fallback = 設計 / N155 set_strict / is_strict = backend_safe に在り facade は strict_mode + on_error(設計)/ N157-158・N154・ N175-176(os / sys)= 第 2 陣で修正 / fullseye.fixture / golden / jsonio / mdio はサブモジュール(属性 API、設計)。