「たぶん受けるだろう」を許さない最小器官――CHECKER（PW90受領検査）を監査する

320　第八標本　CHECKER、PW90 STORY PACK RECEIVER CHECKER

最後に開くのは、少し変わった個体です。

名前はありません。

少なくとも、設計さん、執筆さん、修正刃さま、野良ちゃん、ヌル、ナル、エーアのような人格名は持っていません。

監査上の名前は、

CHECKER。

正式には、

PW90 STORY PACK RECEIVER CHECKER v001

です。

全身裸監査では、これも他runtimeと同じく独立audit subjectとして一体分保存されています。

全体では、

9 audit subjects / 8 runtime shelves。

PW90だけPREとPOSTの二標本があるため、監査対象数が一つ多くなっています。CHECKERもその九つの一つです。

その仕事は一つ。

話パックを、執筆さんが本当に受け取れるか調べる。

それだけです。

321　八ファイルしかない

CHECKERの身体は、

8ファイル。

1,148行。

今回開いた個体の中で、かなり小さい方です。

ZIP内entryは12。

明示directoryが4。

実ファイルが8。

JavaScript 5。

JSON 2。

Markdown 1。

CRC PASS。

unsafe path 0。

JSON parse issue 0。

JavaScript syntax issue 0。

runtime testは、

3/3 PASS。

物理treeも、ほとんどそのまま仕事の説明になっています。

README.md
manifest.json
package.json

src/
  check-story-pack.js

  pw90/
    full-power-write-lock.js
    projectlocked-pack-gate.js
    writable-story-pack-gate.js

test/
  receiver-checker.test.js

これだけです。

322　なぜ、わざわざ独立させたのか

一見すると、このCHECKERは不要に見えます。

執筆さん自身に、

「この話パック書ける？」

と聞けばいい。

実際、執筆さん本体にはstory packを検査する器官があります。

PRE監査でも、

projectlocked-pack-gate.js

はcanonical projectlocked folderを検査するinspector、

writable-story-pack-gate.js

はwritable ZIP story packを検査してprewrite acceptanceを判断する器官として確認されています。

では、なぜ外へ小さなCHECKERを切り出したのか。

理由は、

「執筆さんなら受けるだろう」を、外から推測したくないからです。

323　執筆さんの受領条件を、似せて作らない

話パックを作った。

次に知りたいのは、

「これは執筆さんへ渡せるか」

です。

ここで最悪なのは、

執筆さんの仕様を読んだ別runtimeが、

執筆さんっぽい受領判定

を自作することです。

たとえば、

9ファイルある。

ZIPも開く。

話カードもある。

だからWRITE_READYだろう。

それでは駄目です。

本当に知りたいのは、

PW90の実際の受領器官へ通した時、何と判定されるか。

CHECKERはそのために、

執筆さん側のreceiver gateを持ってきています。

コピーした思想から別判定を発明するのではなく、

実際のPW90受領線を使う。

324　これは「品質評価AI」ではない

CHECKERという名前だけを見ると、

小説の品質を採点しそうです。

しません。

面白いか。

文章が上手いか。

15,000字書けそうか。

設定が魅力的か。

そういう評価をする個体ではありません。

判断するのは、

この入力は、PW90が執筆開始可能なstory packとして受領できるか。

ここだけです。

この狭さが、この個体の価値です。

325　最初のSKILL　ZIP_EXTRACT_SUPPORT

裸監査で確認された最初の部位が、

ZIP_EXTRACT_SUPPORT

です。

場所は、

src/check-story-pack.js の extractZip()。

分類は、

SKILL_SUPPORT / CONFIRMED。

ZIPを安全に展開し、

CRCやunsafe pathを拒否します。

ここは受領判断そのものではありません。

その前に、

そもそも検査対象を安全に読める形へする。

そのためのsupport skillです。

326　ZIPを開けなければ、中身以前の問題

これはナルやヌルでも出てきました。

話パックの意味が正しいかを見る前に、

ZIPとして壊れていないか。

pathが危険でないか。

展開できるか。

そこを見る。

創作的には何も面白くありません。

でも、この一段がなければ、

中身を読むための入口そのものが信用できない。

CHECKERは小さいので、この境界が非常に分かりやすいです。

327　二つ目　PROJECTLOCKED_PACK_INSPECTION

次が、

PROJECTLOCKED_PACK_INSPECTION。

分類は、

SKILL / CONFIRMED。

実体は、

src/pw90/projectlocked-pack-gate.js。

projectlocked形式のstory packを独立して検査します。

これはPW90本体側の裸監査でも、

canonical projectlocked folder structureを検査する独立inspectorとして確認されていた器官です。

つまりCHECKERは、

「projectlockedっぽいか」

を独自判断しているのではありません。

PW90側のその検査線を使っています。

328　三つ目　WRITABLE_MINIMUM_INSPECTION

もう一つ、

WRITABLE_MINIMUM_INSPECTION

があります。

これも、

SKILL / CONFIRMED。

場所は、

src/pw90/writable-story-pack-gate.js。

こちらは、

PW90が最低限書けるstory packとして受領できるか

を見る線です。

PW90本体の監査でも、この器官は、

WRITABLE_PACK_INSPECTOR

として、writable ZIP story packを検査し、prewrite acceptanceを評価するものと確認されています。

ここで、CHECKERの少し面白い構造が見えてきます。

受領線が二つあります。

329　完全形だけを受けるわけではない

第一の線は、

PROJECTLOCKED。

より完全なprojectlocked story-pack形状として通るかを見る。

しかし、それが通らなかったら即全拒否、

ではありません。

次に、

WRITABLE MINIMUM

を見る。

つまり、

理想的なprojectlocked形状ではない。

でもPW90の実際の最低受領条件には入る。

そういうbundleを、

「完全形ではないが書ける」

として区別できます。

330　この二段階が、かなり実務的

形式検査を厳しくすると、

一つの問題が起きます。

形式が少し違う。

だから中身が十分でも全部STOP。

逆に緩くすると、

「たぶん書ける」

が増えて受領境界が崩れます。

CHECKERは、

一つの判定へ丸めません。

完全形として通るか。

通らなければ、

最低受領線では通るか。

それも駄目なら、

拒否。

三段階です。

331　でも、二つのSKILLがあるからROUTERではない

ここでまた、ROUTER問題が出ます。

候補は二つあります。

PROJECTLOCKED inspection。

WRITABLE MINIMUM inspection。

なら、

ROUTERで選んでいるのでは？

裸監査の判定は、

いいえ。

RECEIVER_FALLBACK_SELECTION

は、

ROUTER_CANDIDATE

ではあります。

しかしstatusは、

MIXED_WITH_RUNNER。

純粋なROUTERとしては成立していません。

332　なぜなら「先に選んでいない」

純粋なROUTERなら、

入力を見て、

PROJECTLOCKEDへ行く。

あるいはWRITABLE MINIMUMへ行く。

と、

処理開始前に行き先を選ぶ

はずです。

CHECKERは違います。

まずPROJECTLOCKED inspectionを実行する。

そこで受け入れられなかった時だけ、

WRITABLE MINIMUM inspectionを実行する。

つまり、

これは単なるroute selectionではありません。

fallback orchestrationです。

333　第一検査の結果が、第二検査の入力になるわけでもない

ここで、

「じゃあSKILL_CHAINでは？」

という話も出ます。

それも違います。

PROJECTLOCKED inspectionのoutputを、

WRITABLE MINIMUM inspectionがrequired inputとして受け取って処理する、

という構造ではありません。

第一検査の失敗は、

第二検査を試すかどうか

を決めているだけです。

第二検査自体は、

同じstory packを自分の条件で検査します。

したがって、

SKILL_CHAIN = NOT_GATED。

334　fallbackとCHAINは違う

これはかなり分かりやすい例です。

Aを試す。

駄目ならBを試す。

これは順番があります。

でも、

Aの成果物をBが加工するわけではありません。

だから、

A → Bという矢印が描けても、SKILL_CHAINとは限らない。

今まで何度も出てきた原則が、8ファイルのCHECKERで一番分かりやすい形になります。

335　FULL_POWER_WRITE_LOCK

CHECKERには、

FULL_POWER_WRITE_LOCK

もあります。

分類は、

GUARD / CONFIRMED。

場所は、

src/pw90/full-power-write-lock.js。

これもPW90から持ってきたwriter-side constraintです。

受領checkerだからといって、

「ZIPが読める」

だけを見ているわけではありません。

執筆さんがその後に要求する書く側の境界

も、受領線の一部として保持しています。

336　ただし、CHECKER自身は書かない

ここは非常に重要です。

FULL_POWER_WRITE_LOCKを持っている。

PW90のgateも持っている。

だからといって、

CHECKERが小型PW90になったわけではありません。

本文を生成しません。

初稿も作りません。

FULLBURNもしません。

内部収束もしません。

二稿化もしません。

受領できるかを見るだけ。

執筆さんの器官を一部持っていても、

執筆さんのauthorityまでは持たない。

337　CHECK_STORY_PACK

全体を動かすのが、

CHECK_STORY_PACK。

場所は、

src/check-story-pack.js。

分類は、

RUNNER / CONFIRMED。

このrunnerが、

ZIP extraction、

PROJECTLOCKED inspection、

必要ならWRITABLE MINIMUM inspection、

を実行します。

そして結果を集めます。

338　小さい身体なので、runnerがよく見える

設計さんのengineは巨大でした。

執筆さんのorchestratorにも複数責務が入っていました。

CHECKERは8ファイルしかありません。

だからRUNNERというものが非常に分かりやすい。

検査器官を動かす。

それだけです。

どのstoryが面白いか決めない。

話パックを書き換えない。

不足を補わない。

新しい受領条件も作らない。

339　RECEIVER_DECISION

そして最後に、

RECEIVER_DECISION。

分類は、

TERMINAL_AUTHORITY / CONFIRMED。

CHECKERの最終受領権限です。

裸監査では、

receiver outcomeを一意に返すfinal authorityとして確認されています。

大きく分けると、

PROJECTLOCKEDとして受領。

WRITABLE MINIMUMとして受領。

受領拒否。

この三つです。

340　「受領できる」は一種類ではない

ここがこのCHECKERの肝です。

単純なbooleanなら、

true
false

だけで済みます。

でも、それでは情報を失います。

完全形で通った。

最低線でだけ通った。

完全に拒否された。

これらは、次工程の意味が違う。

だから、

acceptedだけでなく、どの線でacceptedなのか

を保持する。

341　最低線PASSを、完全形PASSに昇格させない

これはかなり重要です。

WRITABLE MINIMUMで通った。

なら、

「問題ありません」

とだけ言いたくなります。

でも、それではprojectlocked inspectionが落ちた事実が消えます。

正しくは、

完全形では通らなかった。
ただし、PW90の最低受領線では書ける。

です。

PASSの中にも、証明範囲があります。

342　逆に、完全形が落ちても即STOPにしない

これも同じくらい大事です。

理想形を要求するあまり、

実用可能なものまで拒否しない。

完全なprojectlocked形式ではない。

でも、PW90自身のwritable lineが受ける。

なら、

書けるという事実は書けるとして扱う。

形式美を、実働条件より上に置かない。

343　CHECKER自身が「理想の話パック」を定義しない

ここもかなり好きなところです。

CHECKERが独立した以上、

checker独自のルールを増やすこともできます。

このファイルも欲しい。

このmanifestも必須。

この命名も必須。

もっと安全に。

もっと厳密に。

でも、それをやると、

PW90よりCHECKERの方が厳しい

という奇妙な状態になります。

受領checkerの仕事は、

自分の理想を押し付けることではありません。

PW90の受領現実を答えること。

344　manifestがあるから受ける、でもない

CHECKERの目的は、

package completeness一般を評価することではありません。

たとえばmanifest metadataがあっても、

PW90の実際のwriter gateが通らなければ意味がない。

逆に、

package上の補助metadataが完全でなくても、

PW90の受領線としてwritableであるなら、

その事実は別に扱えます。

つまり、

package管理条件とwriter受領条件を混ぜない。

345　ARTIFACT_POLICYはない

CHECKERには、

独立したARTIFACT_POLICYはありません。

判定は、

NOT_REQUIRED_AS_SEPARATE_COMPONENT。

理由は単純です。

CHECKERはartifactを作るruntimeではありません。

話パックを作らない。

修正もしない。

移管containerも作らない。

存在するstory packを検査するだけ。

だからartifact managerを作る理由がありません。

346　「出力がある」と「artifactを作る」は違う

CHECKERは当然、結果を返します。

accepted。

rejected。

どのlineで受けたか。

warning。

そうしたoutputはあります。

でも、

それを理由に、

CHECKER_ARTIFACT_POLICY

を作る必要はない。

判定結果を返すことと、正式artifactを成立させることは別です。

これも、分類語を増やさないための重要な線です。

347　UPPER_ROUTERもない

UPPER_ROUTER = NOT_GATED。

純粋なlower routerすら成立していません。

fallback orchestrationが一つあるだけ。

だから当然、その上もない。

8ファイルのcheckerへ、

二階建てrouter architectureを載せたら、

検査本体より交通整理の方が大きくなります。

348　RUNTIME_COMPONENT_LEDGERもない

これも、

ABSENT。

manifest.json

はあります。

でも、それはpackage metadataです。

v003でいう、

実在runtime componentを、

kind、status、introducedVersion、evidenceなどで記録するcomponent ledgerではありません。

だから、

manifestがある。

つまりledgerがある。

とは言いません。

似たファイルを、役割まで同じことにしない。

349　三本のtestしかない

CHECKERのregression testは、

3/3 PASS。

数だけ見ると、かなり少ない。

でも仕事も狭い。

確認しているのは、

projectlocked受領線。

writable minimum受領線。

ZIP inputを含むreceiver path。

そういう、CHECKER自身の責任範囲です。

テスト数を全runtimeで揃える必要はありません。

341ファイルの設計さんと、

8ファイルのCHECKERへ、

同じ大きさのtest suiteを要求する方が不自然です。

350　小さいruntimeは、薄いruntimeではない

8ファイル。

3 tests。

だから簡易版。

ではありません。

むしろCHECKERは、

責任が非常に狭く切れているから小さい。

projectlocked inspection。

writable minimum inspection。

fallback orchestration。

receiver decision。

それ以外を持たない。

ここまで責任が狭ければ、身体も小さくできます。

351　CHECKERは、執筆さんの代わりではない

ここを最後にもう一度。

CHECKERが、

「受領可能」

と返した。

それは、

執筆成功

ではありません。

本文が書けたわけではない。

FULLBURNしたわけでもない。

15K条件を満たした本文があるわけでもない。

内部収束したわけでもない。

PW90全体のSUCCESSでもない。

意味はただ一つ。

ここからPW90の仕事を開始できる。

352　入口判定を独立させる意味

私から見ると、この小さなCHECKERが存在する理由はかなり明快です。

専門runtimeを使う時、

外からその専門runtimeの判断を推測しない。

ナルが、

「執筆さんならたぶん受ける」

と言わない。

私も、

「writer-readyのつもりだから大丈夫」

と言わない。

実際の受領線へ聞く。

そして、

受けるかどうかだけ返してもらう。

これはかなり健全です。

353　専門家の判定を、外側で再実装しない

この原則は、他runtimeにも広げられます。

私は、

ヌルの移管完了を宣言しない。

ナルのPACK_CUTOUT完了を宣言しない。

修正刃さまの編集SUCCESSを宣言しない。

執筆さんの本文SUCCESSを宣言しない。

必要なら、

そのruntime自身の判定を使う。

CHECKERは、その考えを最小サイズで物理化した個体です。

354　八体すべてを開いた

これで、全身裸監査に入っていたruntime棚を一通り開きました。

DS90、設計さん。

PW90、執筆さん。

TS90、修正刃さま。

NW22、野良ちゃん。

MT00、ヌル。

SP00、ナル。

MT00_BOOTSTRAP_EA、エーア。

そして、

PW90 STORY PACK RECEIVER CHECKER。

PW90にはPRE / POST二標本があるため、監査上は9 subjects、runtime棚としては8です。全身監査束ではsource runtime byte identityも9/9 PASSとして固定されています。

ここまでで、

「誰が何をしているか」

は一通り見ました。

355　では、全員を横に並べます

ここからが、たぶんこの解体新書で一番面白いところです。

一体ずつ見ている間は、

それぞれ別のruntimeでした。

設計。

執筆。

編集。

試走。

移管。

話パック。

初回施工。

受領検査。

まったく違う仕事です。

でも、全部開いた状態で横に並べると、

妙に同じ形をした骨が何本もあります。

GUARDが多い。

STOPがある。

局所PASSと全体SUCCESSを分けたがる。

成果物が存在するだけでは成功にしない。

reportへ判定権限を持たせたがらない。

ROUTERを名乗っているのに、実競合がなくて降格する場所がある。

SKILL_CHAINを名乗りたくなる順序があるのに、出力依存がなくて成立しない。

逆に、本当に仕事が一つしかないruntimeは、

驚くほど小さくできる。

そして何より、

全員が「できること」より「やってよいこと」を細かく持っています。

次は、一体ずつではなく、

八体を一枚の解剖台へ並べます。

そこで初めて、

この八か月で何を作っていたのかを、

runtime横断で見ます。