Contents — 6 sections
RicochetTanksを2アカウントで同じ部屋へ入れて確認した。
片側で戦車を動かす。
砲塔も動かす。
もう片側を見る。
戦車も砲塔も初期姿勢のまま。
同期していなかった。
それでも、この時点では「M0のRegression」とは数えなかった。
なぜならM0の範囲外だったから
当時のM0は、
- 一人用試作
- 固定Target
- 一回反射で当てる
- 操作や射撃経路を確認する
ための段階。
1対1同期は次のM1側の仕事だった。
だから2アカウントで同期しないのは、観測上は事実。
でも、
実装済み機能が壊れたわけではない。
未実装だった。
「見つけた問題」を全部BugにするとScopeが崩れる
試験を増やすほど、未完成箇所はたくさん見える。
同期しない。
音がない。
PCVR未確認。
Seat swap未確認。
それらを全部Bugへ入れると、
「今のMilestoneで何が完成条件なのか」
が分からなくなる。
そこで、
- Regression
- Known limitation
- Future scope
- NOT_RUN
- NOT_CONFIRMED
を分けた。
ただし見なかったことにはしない
範囲外だから無視、でもない。
2アカウントで見た結果として、
相手側では初期姿勢のまま
という事実は残した。
M1へ進んだときには、この項目がそのままRequirementになる。
Scope外と記録なしは別。
Acceptance Criteriaが先
重要なのは、Testを実行した後に都合よくScopeを変えないこと。
先に、
「M0では何を確認するか」
を決める。
その外側で見つかったものは、Future workとして残す。
もしM0のAcceptanceに同期が入っていたなら、これは普通にFAIL。
今回はそうではなかった。
Agentic developmentほど境界が必要
Agentは問題を見つけると直したくなる。
同期していないなら同期実装へ進める。
UIが足りなければ追加する。
でもそれを繰り返すと、M0が終わらない。
だから、
見つかった問題と、今直す問題を分ける。
これはAgentへ長時間作業を任せるときにかなり重要だった。
いまの結論
2クライアントで同期しなかった。
これは事実。
でもM0のBugではなかった。
未実装とRegressionを分ける。
当たり前に見えるけど、試験項目が増えるほどこの区別が効いてくる。
Signal / 観測記録
この記録への観測を送る
反証、