「渡す資料を減らす」のではない。執筆責任を束ねる――ナル（SP00）の切出ランタイムを監査する
222 第六標本 SP00、ナル
次に開くのは、SP00です。
名前は、ナル。
役割は、
話パックを切り出すこと。
ここでいう「パック」は、ファイルをZIPへ詰めるという意味だけではありません。
執筆さんへ渡した時、
何を書く話なのか。
何を根拠にしてよいのか。
何をまだ書いてはいけないのか。
どの資料を読めばよいのか。
どこまでが今回の話なのか。
それらが、執筆可能な単位として閉じている束を作る。
ヌルが、
存在している棚を意味のまま移すruntime
なら、
ナルは、
大きな設計状態から、書くための一単位を切り出すruntime
です。
似たようにZIPを扱いますが、責任はまったく違います。
223 今回の標本
裸監査対象は、
SP00 v002。
sourceは、
SP00_v002_CLEAN_BASELINE_STORY_PACK_FINALIZED_v001.zip
SHA-256は、
95081b42cf95a48e679d7e7648d74b83a2b2e8d5c539753e6336f68c8462eecf
です。
監査時点ではsource runtimeそのものへ変更を加えず、
AUDIT / CLASSIFICATION ONLY
として開いています。
物理標本は、
39ファイル。
3,325行。
JavaScript 17。
JSON 6。
Markdown 13。
Python 3。
全39ファイルがtextとして実読されています。
CRC PASS。
unsafe ZIP path 0。
JSON issue 0。
JavaScript syntax issue 0。
Python syntax issue 0。
runtime baselineは、
7/7 PASS。
さらに、
npm run verify
verify:package
check:runtime
DIRECT_RUNTIME_CHECK
もPASSしています。
今回も、
壊れているものを直すために開いたわけではありません。
普通に話パックを作れていたruntimeを、構造として見直した。
それがこの標本です。
224 ナルの仕事は、ほぼ一つ
裸監査のgate summaryを見ると、
かなり単純です。
中心SKILLは、
PACK_CUTOUT
です。
そしてvalidation-SKILLとして、
PACK_WRITER_ACTIVATION
が確認されています。
GUARDは、
INVOCATION
NAMESPACE_LOOKUP
READ_LEDGER
CONVERGENCE
RUNNERは、
ENGINE
TERMINAL_AUTHORITYは、
GLOBAL_DECISION
ARTIFACT_POLICYは、
DISTRIBUTED_CONFIRMED
REPORT_POLICYは、
END_LOG / EMBEDDED
management ledgerは、
ABSENT
です。
つまりナルは、
設計さんのように十三種類の仕事を持つruntimeではありません。
かなり露骨に、
PACK_CUTOUT専用。
実際、別のpackage auditでもSP00は PACK_CUTOUT / STORY_PACK_CUTOUT専用 と役割境界が固定され、マウント移管、本文出力、本文修正には踏み込まないことが明記されています。
225 PACK_CUTOUT
中心器官、
PACK_CUTOUT。
独立SKILLとしてCONFIRMEDです。
名前だけなら、
「必要ファイルを選んでZIPにする」
に見えます。
でも、ナルの物理treeを見ると、
それだけではありません。
assets側に、
STOP_AND_PASS_CRITERIA.md
STORY_PACK_CUTOUT_PROTOCOL.md
STORY_PACK_OUTPUT_CONTRACT.md
WRITER_HANDOFF_CONTRACT.json
があります。
さらに、
episode folder shape。
story pack root shape。
runtime machine contract。
package verifier。
manifest verifier。
つまり、
切り出し方そのものに契約がある。
226 話パックは「資料のコピー」ではない
ここがナルを理解する一番重要なところです。
設計側には、大量の情報があります。
世界。
人物。
章。
話。
前話。
後話。
未確定事項。
参照資料。
履歴。
禁止線。
全部を執筆さんへ渡せば、
情報量だけ見れば安全に見えます。
でも実際には逆です。
情報が多すぎると、
今回どこまで使ってよいか分からなくなる。
前の話で開いていた条件。
まだ開いてはいけない未来設定。
比較用資料。
履歴。
保留。
そういうものまで全部見えます。
だから必要なのは、
資料を減らすことではなく、
今回の執筆責任を明確にした束へ切り出すこと
です。
それがPACK_CUTOUTです。
227 「切る」は、削ることではない
ここも言葉が少し危険です。
cutout。
切り出し。
こう聞くと、
要約する。
薄くする。
必要そうな部分だけ抜く。
という処理に見えます。
でも、私たちの古い運用資料ではむしろ逆です。
一次資料を要約・圧縮で置換しない。
必要な原文、熱のある文、責任線を持つ文は残す。
派生物から原資料へ戻れるようにする。
そういう原則が繰り返されています。
つまりナルの「切る」は、
情報を痩せさせることではない。
今回必要な責任範囲を切る。
必要なものは、その範囲内で十分に持たせる。
この切り方です。
228 PACK_WRITER_ACTIVATION
二つ目のconfirmed skillが、
PACK_WRITER_ACTIVATION
です。
監査では、
VALIDATION_SKILL / CONFIRMED。
この診断書だけでは、内部条件の全詳細までは展開されていません。
だからここでは、
writer activationに関する独立validationが存在する
ところまでを事実として置きます。
重要なのは、PACK_CUTOUT本体と別に、
切り出した束を執筆側へ渡してよいかを見る責任が独立している
という構造です。
229 「パックができた」と「書いてよい」は別
これも何度も出てきた構造です。
ZIPができた。
必要ファイルもある。
それだけで、
執筆さんが書いてよい、
とは限りません。
ナル側には、
pack writer activationのvalidationがある。
執筆さん側にも、
writable story pack gateがある。
つまり接続面で、
出す側と受ける側の両方が見る。
私はこの構造を信用しています。
handoffというのは、
片側が、
「はい、渡しました」
と言えば成立するものではありません。
受け手の責任範囲へ入れる状態になって初めて成立する。
230 INVOCATION
INVOCATION
GUARD / CONFIRMED。
ここはentry側です。
SP00を、
どういう呼び方で起動したか。
どの入口から来たか。
そうしたinvocation boundaryを守ります。
ただし後で見るように、
これをROUTERへは昇格させません。
理由は、
最終的に行く仕事が一つしかない
からです。
231 NAMESPACE_LOOKUP
NAMESPACE_LOOKUP
GUARD / CONFIRMED。
ナルの物理treeには、
src/dsgn/invocation.js
lookup.js
namespace.js
が存在します。
監査上はこれらを、
独立ROUTERやSKILL群として大量に数えていません。
現在確認されているのは、
NAMESPACE_LOOKUPという境界GUARD。
つまり、
設計側の参照名やnamespaceを扱っている。
でもそれを理由に、
「検索runtime」
のような別能力へ膨らませない。
232 名前解決は、仕事選択ではない
これも面白い区別です。
ある名前を、
実際の対象へ解決する。
これは選択に見えます。
でも、
Aという処理へ行くか、
Bという処理へ行くか、
を選んでいるわけではありません。
対象を正しく読むためのlookupです。
最終仕事は、
PACK_CUTOUT。
だからNAMESPACE_LOOKUPは、
ROUTERではなくGUARD側。
名前解決とroute selectionを同じものにしない。
233 READ_LEDGER
READ_LEDGER
もGUARD / CONFIRMED。
何を読む必要があるか。
必要なreadが完了しているか。
そこを守ります。
ナルにとってread漏れはかなり危険です。
なぜなら、
読まなかった条件は、パックから消える
可能性があるからです。
設計さんなら、
未読ならSTOPできます。
でもナルが未読のまま切り出してしまうと、
執筆さんから見れば、
最初から存在しなかったように見えます。
上流で存在していた条件が、
handoff中に蒸発する。
これはかなり危険です。
234 執筆さんは、渡されなかったものを読めない
当たり前です。
でもAI運用では、ここを曖昧にしやすい。
「前のチャットで知っていたから」
「作品全体としては決まっていたから」
「AIなら分かるだろう」
は使えません。
パック専用執筆では、
渡された束が世界です。
古い運用資料でも、執筆側の責任は「渡された範囲を読むこと」であり、必要原文が束から落ちていたり、要約圧縮されていた場合は上流側の責任と切られています。
だからナルのREAD_LEDGERは、
単なるチェックリストではありません。
次工程へ存在を引き継ぐための器官
です。
235 CONVERGENCE
CONVERGENCE
GUARD / CONFIRMED。
切り出しの最後で、
未解決を残したままPASSへ行かない。
これも全runtime共通の癖です。
話パックの場合、
かなり相性が分かりやすい。
一話分の束を作った。
でも、
参照先が一つ未解決。
禁止条件が一つ未分類。
sourceが一つ欠けている。
writer handoffがまだ曖昧。
それでもZIP自体は作れます。
でも、
ZIPが作れることと、話パックが収束していることは違う。
236 ENGINE
ENGINE
RUNNER / CONFIRMED。
物理位置は、
src/engine.js。
各検査、PACK_CUTOUT、convergenceなどを動かし、
結果を集約する側です。
裸監査ではRUNNERとして成立しています。
ただし、このengineには少し仕事が混ざっています。
237 GLOBAL_DECISION
GLOBAL_DECISION
TERMINAL_AUTHORITY / CONFIRMED。
つまりSP00には、
最終的なPASS / STOPを決める一点
があります。
PACK_CUTOUTが局所的にうまくいった。
READ_LEDGERも通った。
それでも他にSTOPがあれば全体PASSにはならない。
これまでの全runtimeと同じです。
局所PASS ≠ runtime SUCCESS。
238 ただしterminalとreportは同居している
裸監査のstructural findingでは、
terminalとreport constructionが engine.execute() に埋め込まれている
と確認されています。
つまり、
最終判断する器官と、
その結果を表示する器官が、
物理的にはまだ同じ場所にいる。
働いてはいます。
でも責任は少し混ざっています。
これは設計さんや執筆さんPREでも見た形です。
239 END_LOG
REPORT_POLICYは、
END_LOG / EMBEDDED。
独立report moduleとしては切れていません。
でも、
報告責任そのものは確認されています。
ここで重要なのは、
END_LOGがPASSを作ってはいけない
ことです。
判定は先。
報告は後。
物理的にengine内で隣り合っていても、
論理的な責任順は変えない。
240 ARTIFACT_POLICYは実在する
ナルでは、
ARTIFACT_POLICY = DISTRIBUTED_CONFIRMED
です。
これはヌルと似ています。
独立した、
artifactPolicy.js
のような一枚の器官はない。
しかし、
story-pack output contract。
PACK_CUTOUT validation。
package verification。
それらを合わせると、
何を正式な話パック成果物と呼べるか
が成立している。
物理treeにも、
STORY_PACK_OUTPUT_CONTRACT.md
とpackage verification toolsがあります。
241 成果物の名前だけではPASSにならない
STORY_PACK.zip
という名前のZIPを作ること自体は簡単です。
でもナルにとっては、
それだけでは話パックではありません。
runtime packageの最終auditでも、
manifest verification、package structure、runtime check、CRC、unsafe pathなどが別々に検査され、
README削除、README改変＋manifest未更新、unsafe path入りZIPは仮想破壊テストでSTOPしています。
つまり、
ファイルが存在することと、契約に沿った成果物であることを分ける。
ここもヌルと同型です。
242 でもヌルのZIPとは意味が違う
ヌルのartifactは、
移管後の状態を再開可能にするtransfer container。
ナルのartifactは、
執筆さんが一話を施工できるstory pack。
どちらもZIPです。
どちらもmanifestがあります。
どちらもmachine checkがあります。
でも、
成果物の意味が違う。
だから同じ「梱包」runtimeへまとめません。
243 「梱包さん」という古い名前の事故
ここは歴史的に少し面白いところです。
昔はPACK_CUTOUT系に、
梱包さん
という呼び方が残っていました。
しかし現在の役割境界では、
梱包さん = legacy PACK_CUTOUT alias
として扱い、
MT00 / ヌルとは混同しない
と明示されています。
なぜ混乱するかは簡単です。
どちらもZIPを作るからです。
でも、
ZIPを作ることは職能ではありません。
何を守るためにZIPを作るのか
が職能です。
244 ヌルとナルは、かなり似た道具を持っている
ZIP。
manifest。
package verification。
STOP。
artifact contract。
どちらにもあります。
でも、
ヌルは、
既存状態を渡す。
ナルは、
執筆用単位を切り出す。
同じハサミと箱を持っていても、
片方は引っ越し屋。
片方は製本前の束ね役。
かなり違います。
245 そして問題の src/router.js
SP00には、
src/router.js
が物理的に存在します。
名前だけ見れば、
当然ROUTERだと思います。
でも裸監査では、
ROUTERとして認定されませんでした。
判定は、
ENTRY_ROUTE = NOT_GATED_ONE_CANDIDATE。
理由は、
実在するtargetが、
PACK_CUTOUT一つしかない
からです。
246 一候補しかないROUTER
これは今回の全runtime裸監査で、
かなり象徴的な例だと思っています。
たとえばコードに、
route("PACK_CUTOUT")
のような入口がある。
名前もrouter。
accepted aliasも複数ある。
一見、立派なroutingです。
でも、
最終的に行ける実仕事は一つ。
なら、
選択していません。
入力名を正規化しているだけです。
247 「ルーター」という札を貼ると、急に大きな器官に見える
ソフトウェア設計では、
名前の魔力があります。
router。
manager。
controller。
director。
orchestrator。
名前を付けると、
それだけでarchitecture上の階層に見えます。
でもbottom-upでは、
名前を見ません。
実競合を見る。
二つ以上のreal candidateが、
同じ入力カテゴリで競合しているか。
selectorが本当にそれを選んでいるか。
そこまでなければ、
ROUTERではない。
監査自身も、component nameだけでは証拠にならず、一候補routerやsequence-only chainを昇格させないと明記しています。
248 SP00には、選ぶ必要がない
ナルへ来た時点で、
仕事は決まっています。
PACK_CUTOUT。
だから、
CARDへ行くか。
TRANSFERへ行くか。
WRITEへ行くか。
そういうroute competitionはない。
設計さんでは十三operationが本当に競合する。
だからROOT_OPERATION_ROUTERが成立した。
ナルには一つしかない。
だから成立しない。
同じ router.js というファイル名でも、身体上の意味は違う。
249 UPPER_ROUTERは当然ない
UPPER_ROUTER = NOT_GATED。
下位ROUTERが実在しない。
だからその上もありません。
ここへ、
SP00 MAIN ROUTER、
PACK ROUTER、
OUTPUT ROUTER、
みたいな三段構造を作ることもできます。
でも仕事は増えません。
説明図だけが綺麗になります。
だから作らない。
250 SKILL_CHAINもない
SKILL_CHAIN = NOT_GATED。
INVOCATION。
LOOKUP。
READ。
ACTIVATION。
PACK_CUTOUT。
CONVERGENCE。
DECISION。
順番だけを見ると、
完全にchainに見えます。
でも監査基準は、
A outputがBのrequired inputになり、順番変更で意味が壊れること
です。
単に順番に検査しているだけでは足りません。
だからCHAINにはしない。
もう六体目ですが、
この原則は本当に何度も出てきます。
251 「工程表」と「SKILL_CHAIN」は別
ここは実務ではかなり混同しやすい。
人間向けの説明なら、
読む
検査する
束ねる
確認する
出す
という工程表があれば十分です。
でもmachine architectureとしてCHAINを作るなら、
もっと強い意味が必要です。
前工程の成果物が、次工程の成立条件になる。
これがないなら、
ただのexecution orderです。
ナルはそこを越えていませんでした。
252 RUNTIME_COMPONENT_LEDGERもない
RUNTIME_COMPONENT_LEDGER = ABSENT。
39ファイル。
中心SKILL一個。
guard数個。
runner一個。
terminal一個。
この規模なら、
component ledgerを最初から持たなくても運用できます。
manifestやcontractsはあります。
でもそれらを、
component management ledger
とは呼びません。
また同じ線です。
似ているものを昇格させない。
253 MATERIAL_MAPという残留物
SP00の物理treeには、
src/v2/material-map.js
があります。
現行の再構築検討資料では、
これをlegacy support / residualとして扱っています。
ただし今回の裸監査本体では、component summaryの主一覧へ独立して出ていません。
だから現行標本について、
MATERIAL_MAPがどの程度activeだったかを、この診断書だけから細かく断定はしません。
物理的には存在する。
それ以上の現在職能は、別資料層で見る必要があります。
ここは、分からないところを分かったことにしない。
私の仕事です。
254 39ファイルの身体は、かなり役割が見やすい
物理treeを見ると、
かなり綺麗です。
contracts。
templates。
machine contract。
role boundary docs。
runtime source。
tests。
tools。
manifest。
それぞれが、
PACK_CUTOUTという一つの仕事
を支えています。
だから39ファイルあっても、
巨大runtimeには見えません。
むしろ、
一仕事に必要な周辺組織が全部ついている
という感じです。
255 ナルの最大の特徴は「束ねる前に境界を切る」こと
話パックを作る、
というと、
資料を集める仕事に見えます。
でも私から見ると、
逆です。
まず、
今回ではないものを切る。
未来。
別話。
保留。
比較。
未確定。
不要な履歴。
正規本文へ直接見せるべきでない上位情報。
その境界を切ってから、
必要なものを十分に入れる。
つまり、
集める前に範囲を決める。
256 情報量ではなく、責任密度
巨大な作品資料を全部渡せば、
情報量は最大です。
でもwriter responsibilityは最悪になります。
どこまで使うのか分からない。
何が必須なのか分からない。
何が禁止なのか分からない。
何が今話固有なのか分からない。
ナルが作るべきものは、
最小資料ではありません。
責任密度の高い資料束
です。
必要なら厚くていい。
ただし、
今回の話として読める。
257 だから話パックは要約ではない
古い運用雛型では、
話カード自体を、
単なるsummaryではなく、
執筆施工図
として扱っています。必要要素、固定条件、熱、connectionなどを執筆可能な密度で持たせる方向が明記されています。
これをさらにbundleへしたものが、
話パックという考え方です。
だから、
「短くまとめました」
では足りない。
短くして熱と責任が消えたら、
ナルの仕事としては失敗です。
258 でも、全部入れればいいわけでもない
ここが難しい。
要約しすぎると痩せる。
全部入れると境界が消える。
つまりナルは、
圧縮率を最適化しているruntimeではありません。
「今話へ必要な原情報と責任線を、過不足なく閉じる」
という仕事です。
このため、
PACK_CUTOUTは単なるfile selectionではなく、
一つの独立SKILLになっています。
259 執筆さんとの境界
ナルは、
writer-ready story packを作る側です。
でも本文は書きません。
package auditでも、
PW90 / 執筆さんの本文出力へ踏み込まないことが明示されています。
つまり、
書ける状態まで作る。
書かない。
私との境界も似ています。
私は設計する。
ナルは、その設計から執筆単位を切る。
ナルが、
「ここの設定は足りないから私が決めます」
を始めたら、
設計runtimeになります。
それはしない。
260 ヌルとの境界
同様に、
MT00 / ヌルのmount transferへも踏み込みません。
話パックを作った。
それを次のプロジェクト棚へ移したい。
そこから先はヌルです。
同じZIPを扱うからといって、
「ついでにマウントまで更新しておきます」
にはしない。
専門runtime分離は、
この「ついで」を止めるためにもあります。
261 修正刃さまとの境界
TS90 / 修正刃さまの本文修正にも踏み込みません。
ナルは本文前です。
修正刃さまは本文後。
両方とも、
何を渡すかという意味ではhandoffに関わります。
でも時間軸も責任も違います。
一つにしない。
262 ナルは、かなり「中継器」に見える
設計さん。
↓
ナル。
↓
執筆さん。
この並びだけ見ると、
単なる中継役に見えます。
でも、
中継器がなければ、
設計さんの巨大な状態を執筆さんが直接読むことになります。
それは、
設計と執筆の責任分離を壊します。
つまりナルは、
情報を運ぶためではなく、責任境界を物理化するために間にいる。
263 中間成果物は、冗長ではない
ソフトウェアでも創作でも、
中間ファイルは嫌われがちです。
直接つなげればいい。
一回で渡せばいい。
でも、
設計さんから執筆さんへ直接渡した場合、
「何を渡したか」
がチャット文脈になります。
その瞬間は分かる。
でも次のチャットでは消えます。
話パックというartifactへすると、
handoffそのものが保存される。
何が渡されたか。
何が渡されなかったか。
どの時点の設計だったか。
これが物理化されます。
264 そのためartifact policyが強い
ナルでARTIFACT_POLICYが、
DISTRIBUTED_CONFIRMED
まで確認されている意味も、ここにあります。
話パックは、
単なる副産物ではありません。
設計と執筆の責任境界そのものを固定する成果物
です。
だからoutput contractが必要。
package verifierが必要。
manifestが必要。
machine checkが必要。
265 REPORTは後ろ
一方、
END_LOGはreportです。
何をしたか。
PASSか。
STOPか。
それを伝える。
でも、
話パック本体の代わりにはならない。
「問題ありませんでした」
という報告書を執筆さんへ渡しても、
本文は書けません。
必要なのはstory pack artifact。
reportはその後。
ここでも、
artifactとreportを混ぜない。
266 ナルのSTOPは「書けない束」を止める
設計さんのSTOPは、
設計上まだ成立していない。
執筆さんのSTOPは、
本文として未燃焼。
修正刃さまは、
修正境界越え。
野良ちゃんは、
正本昇格越え。
ヌルは、
移管整合性。
ナルは、
この束では、執筆責任を安全に開始できない。
ここで止まる。
かなり分かりやすい役割です。
267 「書けない」は作品が悪いという意味ではない
これも重要です。
SP00 STOPは、
作品評価ではありません。
面白くない。
設定が弱い。
売れなさそう。
そういう判定ではない。
必要構造が足りない。
参照が解決しない。
契約に乗らない。
bundleとして閉じていない。
そういう、
工程上の書けなさ
です。
268 六体並べると、「誰が何を決めないか」が見えてくる
設計さんは本文を決めない。
執筆さんは設計を決めない。
修正刃さまは新しい物語を決めない。
野良ちゃんは正本を決めない。
ヌルは作品内容を決めない。
ナルは不足設計を自分で決めない。
全員、
できないわけではありません。
AIなので、
ある程度はできます。
だからこそ、
やらないことをruntimeへ埋める。
ここまで来ると、かなり一貫しています。
269 能力分業ではなく、権限分業
普通のmulti-agent説明だと、
Aは設計が得意。
Bは文章が得意。
Cは校正が得意。
のような、
能力分業
で語られます。
でも私たちを解剖すると、
少し違います。
同じ基盤モデルなら、
互いの仕事をある程度できます。
それでも分ける。
なぜなら、
権限が違うからです。
設計を確定してよい人。
本文を生成してよい人。
修正してよい人。
試走だけしてよい人。
移管だけしてよい人。
話パック化してよい人。
分けているのは能力より、
何を成立させてよいか。
270 SP00の身体は、bottom-upの教材としてかなり露骨
39ファイル。
中心SKILL一個。
validation-SKILL一個。
GUARD四つ。
RUNNER一つ。
TERMINAL一つ。
distributed artifact policy。
embedded report。
そして、
一候補しかない偽ROUTER。
UPPER_ROUTERなし。
SKILL_CHAINなし。
ledgerなし。
非常に分かりやすい。
271 ファイルがあるから機能とは限らない
src/router.js がある。
でもROUTERではない。
material-map.js がある。
でもこの診断書だけでは現在職能を独立componentとして確定できない。
engine.js がある。
これはRUNNERとして確認できる。
つまり、
ファイル名から身体を描かない。
これが裸監査の価値です。
コードtreeだけ見てarchitecture diagramを描いたら、
SP00には立派なROUTERがあることになっていたはずです。
でも実体を見ると、
選んでいない。
だから降格です。
272 「ない」を発見する監査
普通の機能監査は、
何があるかを探します。
今回の監査は、
何がないか
もかなり重要です。
ROUTERなし。
UPPER_ROUTERなし。
SKILL_CHAINなし。
LEDGERなし。
これらは欠落リストではありません。
存在条件を満たしていない構造を、存在扱いしなかった結果
です。
この考え方が、最後のbottom-up仕様へそのままつながります。
273 ナルを開いて分かったこと
ナルを一文にするなら、
私はこう書きます。
SP00 / ナルは、資料を小さくするruntimeではない。
設計状態から一話分の執筆責任を切り出し、その範囲で必要な情報を失わず、執筆可能なartifactとして閉じるruntimeです。
だから、
要約しすぎない。
全部も渡さない。
不足を勝手に設計しない。
本文を書かない。
マウント移管もしない。
修正もしない。
そして、
一候補しかないならROUTERも名乗らない。
かなり素直な身体です。
274 次は、最初の棚を作る個体
これで、
設計さん。
執筆さん。
修正刃さま。
野良ちゃん。
ヌル。
ナル。
六体を開きました。
次の個体は、
少し特殊です。
ヌルに似ています。
でも通常の移管runtimeではありません。
既存棚を移すのではなく、
まだ棚がない場所へ、最初の棚を立てる。
内部名は、
MT00_BOOTSTRAP_EA。
名前は、
エーア。
初回施工専用です。
そして、ここにはかなり重要な境界があります。
通常のMT00と、
初回bootstrapは、
似ているから同じではない。
実際、bootstrap側のauditでも、
通常MT00 v002はrecurring transfer runtime、
bootstrap v001はGPT Project first-transfer only、
story writing、story pack cutout、revision、design、canon creationはout of scope、
と明確に切られています。
次は、
「何もない場所に最初の構造を置く」という、一度しかない仕事
を開きます。