boss strategy は、player が何を見て、どの movement で安全に答え、いつ punish し、失敗したらどう reset するかを答える必要があります。公式 listing は六章の tower と十を超える boss の広い scope を示しますが、current encounter manual は公開していません。roster や phase order を発明せず、encounter note を作る方法として使います。
optimize 前に observe する
最初は damage を追わず、attack 前の screen、音、movement の変化を探します。signal を一つの短い言葉にし、どの距離と space で見えたかを書きます。Boss Guideへその observation を渡します。
opening を試す
signal の後に短い action だけを試し、exit を使わずに戻れるか確認します。長い combo や追加の Artifact は後に回し、同じ chapter と version で response を比べます。opening がない場面も重要な結果です。
phase を慎重に扱う
phase 名を先に決めず、敵の movement、range、arena の変化を記録します。区切りが再現できたら、どの signal が境界になったかを説明します。Chaptersの route とCo-op Bossesの結果は context を分けます。
solo、co-op、source
solo で作った response と、仲間が focus や space を作った response は同じではありません。party size、role、mode、platform、version を添え、公式の広い scope と player の lead を分離します。もう一度Chaptersを見て route の差を確認します。
strategy report template
boss、入口、weapon、signal、response、opening、失敗時の position、reset、confidence、次の試験を一行ずつ記録します。長い説明より、別の player が同じ問いを試せる条件を優先します。
pressure 下で response を試す
安全な練習でできた response を、敵が増えた場面で小さく試します。失敗したら全てを変えず、距離、input、退路のどれが原因かを分けます。Co-op Bossesの shared space で得た結果も同じように限定します。
update 後に retest する
balance change の後は、変更に近い signal から再試験します。過去の note を current として上書きせず、version と日付を分けて保存します。確定できない recommendation は pending のままにします。
strategy を公開するなら、成功した punish だけでなく、その前に守った space と、miss した場合の回復も示します。短い response が安定した後で長い action を追加し、どの条件で安全性が失われるかを説明します。これにより、速い player の一度の clear を全員の標準にせずに済みます。
複数の boss や chapter で似た cue が見えても、同じ mechanic だとは決めません。signal、response、version、platform が一致した範囲だけを共通の観察とし、違いは別の strategy note にします。