@kubohiroya/turbowarp-webrtc-qrcode-pairing 0.1.0

package/docs/integration-guide.md

@@ -0,0 +1,258 @@
+# Integration guide
+
+[日本語](integration-guide.ja.md)
+
+How to pair two machines with this extension from a TurboWarp project. For the block-by-block
+reference, see [Block reference](../README.md#block-reference).
+
+## 1. Before you start
+
+Load these extensions **before** this one, and run all of them unsandboxed:
+
+| Extension | Why |
+|---|---|
+| `turbowarp-webrtc` | Creates and accepts the offer and the answer, and owns the connection |
+| `turbowarp-jsqr` | Decodes QR codes from camera frames |
+| `turbowarp-camera-source` | Acquires the camera and exposes frames |
+
+`turbowarp-webrtc` must publish runtime capability **v3**, which version 0.4.0 and later do. Version
+0.3.0 and earlier publish v2, which has `createOffer` and `getOffer` but not `acceptOffer`,
+`getAnswer`, `acceptAnswer` or `connectionState`, so a round trip cannot complete. A version that is
+too old reports `webrtc-capability-missing`.
+
+Turn the pairing blocks on at startup, before the extension loads:
+
+```js
+globalThis.__TWQP_FEATURE_FLAGS__ = {qrCodePairing: true};
+```
+
+While the flag is off, no pairing blocks appear and `pairing phase of [SESSION]` reports `disabled`.
+
+The flag is read once while the bundle evaluates, so setting it afterwards has no effect. To get a
+single file that already has it set, run the repository's helper:
+
+```bash
+pnpm run build:flagged      # optionally: pnpm run build:flagged Q
+```
+
+It writes `local/webrtc-qrcode-pairing.flagged.js` and prints a `file://` URL to load as a custom
+extension. The optional argument fixes the error correction level. The file is local to the working
+copy and is not published; loading `dist/webrtc-qrcode-pairing.js` instead is how you check the
+blocks really are off by default.
+
+## 2. Roles and names
+
+One machine is the **hub**: it creates the offer, projects it, and reads the answer back. The other
+is the **camera machine**: it reads the offer and shows the answer.
+
+Each machine picks its own names. They do **not** have to match:
+
+- The hub calls itself `studio` and the camera machine `cam-A`.
+- The camera machine learns both names from the offer. It registers the connection under `studio`
+  and answers as `cam-A`.
+
+So the hub's `remote peer` is the camera machine's `local peer`, and vice versa. The names only need
+to be meaningful to the person reading the screen.
+
+Pass an empty `LOCAL_PEER` on the camera machine to accept whatever name the offer assigns. Pass a
+name to require it: an offer addressed to a different machine is then rejected with `peer-mismatch`,
+which catches an operator scanning the wrong projection.
+
+## 3. The hub script
+
+```
+when green flag clicked
+  start offer pairing [pairing-1] as [studio] to [cam-A]
+  set pairing timeout of [pairing-1] to (600) seconds
+  show pairing QR part (1) of [pairing-1] on this sprite
+```
+
+The timeout is set after the session exists: every block but the two `start`
+blocks needs an open session and reports `no-session` otherwise. The deadline is
+measured from the moment the session started, so setting it right afterwards
+loses nothing.
+
+`start offer pairing` returns once the offer exists and its QR parts are prepared; the phase becomes
+`offer-ready`. Creating the offer waits for ICE gathering to finish, so it can take a moment.
+
+Then project the parts and let the camera machine read them. When the operator brings the answer
+back:
+
+```
+scan pairing QR for [pairing-1] from camera [default]
+wait until pairing [pairing-1] is connected
+end pairing QR display of [pairing-1]
+```
+
+`scan pairing QR` returns when every part of the answer has arrived and passed its checks. At that
+point the phase is `answer-received`, then `connecting`. `wait until ... is connected` returns when
+WebRTC reports the connection, and fails if the session is cancelled, times out, or fails.
+
+## 4. The camera machine script
+
+```
+when green flag clicked
+  start answer pairing [pairing-1] as []
+  set pairing timeout of [pairing-1] to (600) seconds
+  scan pairing QR for [pairing-1] from camera [default]
+  show pairing QR part (1) of [pairing-1] on this sprite
+  wait until pairing [pairing-1] is connected
+  end pairing QR display of [pairing-1]
+```
+
+After the offer is complete the extension accepts it and prepares the answer on its own, so the
+phase moves `receiving` → `offer-received` → `creating-answer` → `answer-ready` without another
+block.
+
+## 5. Showing parts so they can be photographed
+
+A long connection code needs several QR codes. Show them one at a time and let the operator advance
+them, rather than cycling automatically: a person photographing a projection needs to see each part
+stay still.
+
+```
+show pairing QR part (1) of [pairing-1] on this sprite
+say (join (join (current pairing QR part of [pairing-1]) " / ") (pairing QR part count of [pairing-1]))
+
+when [space v] key pressed
+  show next pairing QR part of [pairing-1] on this sprite
+```
+
+Practical points:
+
+- Show the part number and the total ("2 / 3") so the operator knows what is left to photograph.
+- The sprite keeps its original costume: `end pairing QR display` puts it back, and so do cancelling,
+  a timeout, the stop button, and removing the sprite.
+- Keep the sprite large and square on the projection, and leave the white margin around the code
+  intact — it is part of the symbol.
+- Higher error correction survives worse optics but fits fewer characters per code, which means more
+  parts to carry. `M` is the default; set `Q` or `H` at startup if reading is unreliable:
+  `globalThis.__TWQP_QR_CONFIG__ = {errorCorrectionLevel: 'Q'};`
+- To draw the code yourself instead of using a sprite skin, read
+  `pairing QR part [INDEX] of [SESSION] as data URI` or `... as SVG`. This path works even without a
+  renderer.
+
+## 6. Reading parts
+
+`scan pairing QR for [SESSION] from camera [CAMERA_ID]` holds one camera lease for the whole session
+and keeps looking until every part has arrived. Reading the same part repeatedly is normal and
+costs nothing. Codes belonging to something else — a poster, another session, the previous attempt —
+are skipped silently.
+
+Show progress while it runs:
+
+```
+say (join (join (received parts of [pairing-1]) " / ") (required parts of [pairing-1]))
+say (join "still needed: " (missing parts of [pairing-1]))
+```
+
+`required parts` is 0 until the first part arrives, because the part count travels inside the parts.
+
+If your project obtains QR text some other way, feed it in directly with
+`receive pairing QR text [TEXT] for [SESSION]`. That is the primary entry point; camera scanning is
+built on top of it.
+
+## 7. Watching progress
+
+`pairing phase of [SESSION]` reports where the exchange is:
+
+| Phase | Meaning |
+|---|---|
+| `disabled` | The feature flag is off |
+| `idle` | No session with that name |
+| `creating-offer` | Hub: waiting for WebRTC to produce the offer |
+| `offer-ready` | Hub: offer QR parts are ready to project |
+| `awaiting-answer` | Hub: some answer parts have arrived |
+| `answer-received` | Hub: the answer passed its checks |
+| `awaiting-offer` | Camera: waiting for the first offer part |
+| `receiving` | Camera: some offer parts have arrived |
+| `offer-received` | Camera: the offer passed its checks |
+| `creating-answer` | Camera: waiting for WebRTC to produce the answer |
+| `answer-ready` | Camera: answer QR parts are ready to show |
+| `connecting` | The code reached WebRTC; the connection is not up yet |
+| `connected` | WebRTC reports an established connection |
+| `cancelled` / `expired` / `failed` | The exchange ended |
+
+**Carrying the code successfully is not the same as connecting.** `answer-received` and
+`offer-received` mean the optical transport worked. `connected` means the network path worked. A
+code can arrive perfectly and the connection still fail, because reachability depends on the network,
+not on the QR codes.
+
+## 8. Two or more camera machines
+
+Pair them one at a time, each with its own session name and its own remote peer name:
+
+```
+start offer pairing [pairing-A] as [studio] to [cam-A]
+...
+start offer pairing [pairing-B] as [studio] to [cam-B]
+```
+
+An answer from `cam-B` offered to session `pairing-A` is rejected: each answer carries the session
+and the offer it replies to, so the connections cannot be swapped. `pairing sessions` lists the open
+session names.
+
+## 9. Timeouts, cancelling, retrying
+
+- `set pairing timeout of [SESSION] to [SECONDS] seconds` — 1 to 3600, default 600. The deadline is
+  measured on this machine's own clock, so the two machines do not need synchronized time.
+  `remaining seconds of [SESSION]` counts down.
+- `cancel pairing [SESSION]` — restores the display, releases the camera and the receive buffer, and
+  closes the peer connection **if it never connected**. An established connection stays up.
+- `retry pairing [SESSION]` — cancels and starts a fresh exchange. The new exchange has a new id, so
+  a QR code photographed from the previous attempt is refused rather than applied.
+
+Pressing the stop button releases displays and cameras and cancels exchanges in progress. It does
+not disconnect an established connection.
+
+## 10. When something goes wrong
+
+`pairing error code of [SESSION]` gives a stable code; `pairing error message of [SESSION]` gives a
+sentence for the operator. Neither ever contains the connection code itself.
+
+| Code | What happened | What to do |
+|---|---|---|
+| `feature-disabled` | The startup flag is off | Set `__TWQP_FEATURE_FLAGS__` before loading |
+| `webrtc-capability-missing` | `turbowarp-webrtc` is absent or older than v3 | Load it first; it must publish capability v3 |
+| `qr-decoder-missing` / `camera-unavailable` | `turbowarp-jsqr` or `turbowarp-camera-source` is absent, or the camera failed | Load them first; check camera permission |
+| `renderer-unavailable` | The sprite cannot take a temporary skin | Use a normal sprite, not the stage or a clone; or display the SVG yourself |
+| `unsupported-protocol` | The code is not `twqr/1` | An old `twmp-qr/1` code or another product's QR |
+| `hash-mismatch` / `length-mismatch` | Parts assembled but the message is damaged | Re-read all parts; raise error correction |
+| `conflicting-part` | The same part number arrived with different content | Two different exchanges are being mixed; restart |
+| `missing-parts` | Not every part has been read | `missing parts of [SESSION]` says which |
+| `peer-mismatch` | The code names different machines | The wrong projection was scanned |
+| `reply-mismatch` / `stale-exchange` | The code answers a different offer or a previous attempt | Photograph the current codes again |
+| `already-accepted` | This exchange already handed its code to WebRTC | Nothing to do |
+| `timeout` | The deadline passed | `retry pairing` |
+| `webrtc-rejected` | WebRTC refused the code or the connection failed | A network problem, not a transport problem |
+| `session-exists` / `session-limit` / `no-session` | Session name already open, too many open, or not open | Cancel a session, or check the name |
+
+## 11. What this extension does not do
+
+- **It is not authentication.** The hash detects damage. Anyone who can photograph the codes can
+  recompute it, and anyone who can see the projection can read the connection information. Manage
+  the visibility of the projection as an operational matter.
+- **It does not guarantee reachability.** ICE, STUN and TURN belong to `turbowarp-webrtc`.
+- **It does not carry video.** Camera data travels over WebRTC after the connection is established.
+- **It does not lay out your screen.** Operator instructions, projection layout, and what happens
+  after the connection are the application's job.
+
+## 12. Recording a hardware test
+
+Optical conditions cannot be checked in CI. Record each run and do not treat an untested condition
+as verified:
+
+```
+Date:
+Hub machine: <model / OS / browser and version>
+Camera machine: <model / OS / browser and version>
+Carrier: <smartphone model / OS / camera app>
+ICE mode: lan | stun
+Network: same LAN / different segments / other
+Offer: parts =   / QR version =   / error correction =   / projector (size, distance, ambient light)
+Answer: parts =   / QR version =   / error correction =   / screen brightness
+Reading: camera machine took   s / hub took   s / re-photographs =
+Result: connected = yes|no / connection state =   / test message exchanged = yes|no
+Error: code =   / circumstances =
+Notes:
+```

package/docs/migration.ja.md

@@ -0,0 +1,110 @@
+# 移行と切戻し
+
+[English](migration.md)
+
+## 1. turbowarp-realtime-motion-capture からの移行
+
+`turbowarp-realtime-motion-capture`は`twmp-qr/1`形式でOfferをQR搬送する経路を、独自の
+`qrCourierPairing`フラグの内側に持っています。ブロックは`prepare offer QR`、
+`show offer QR part`、`show next offer QR part`、`end offer QR display`、`offer QR state`、
+`offer QR error`です。
+
+この経路はOffer側だけです。カメラ側がOfferを受理してAnswerを返す部分は別の手段が必要で、そこが
+本拡張の追加分です。
+
+### 形式
+
+`twqr/1`は`twmp-qr/1`と**互換ではなく**、読み取りもしません。`twmp-qr/1`はpeer名を1つしか持たず
+reply-toも無いため、次を表現できません。
+
+- 送信側が自分を呼ぶ名前と、相手を呼ぶ名前の区別
+- Answerがどの Offer への応答か
+
+本拡張では両方が必要です。前者は両端で同じ識別子を設定せずに済ませるため、後者はAnswerが誤った
+交換へ適用されないためです。必須フィールドの追加は後方互換にできないため、新しい名前空間と
+versionを与えました。
+
+`twmp-qr/1`のQRを本拡張へ渡すと`unsupported-protocol`で拒否されます。読み取り互換モードは
+設けていません。peerの対応付けを表現できないQRを受理することは、その対応を推測することであり、
+推測を誤れば誤った端末同士が接続されます。曖昧な受理より明示的な拒否のほうが安全です。
+
+同じ会場で両者を併用することはできます。相互にQRを読めませんが、失敗は黙って起きるのではなく
+報告されます。
+
+### ブロックの対応
+
+| motion-capture | 本拡張 |
+|---|---|
+| `prepare offer QR for peer [PEER]` | `start offer pairing [SESSION] as [LOCAL_PEER] to [REMOTE_PEER]` |
+| `show offer QR part [INDEX] on this sprite` | `show pairing QR part [INDEX] of [SESSION] on this sprite` |
+| `show next offer QR part on this sprite` | `show next pairing QR part of [SESSION] on this sprite` |
+| `offer QR part count` | `pairing QR part count of [SESSION]` |
+| `current offer QR part` | `current pairing QR part of [SESSION]` |
+| `end offer QR display` | `end pairing QR display of [SESSION]` |
+| `offer QR state` | `pairing phase of [SESSION]`（状態が増えています。利用ガイド参照） |
+| `offer QR error` | `pairing error code of [SESSION]`と`pairing error message of [SESSION]` |
+| — | Answer側の一式、読取り、取消、再試行、期限 |
+
+プロジェクトを移すときの差分です。
+
+- すべてのブロックがsession名を取ります。1つのプロジェクトで複数台とペアリングできます。
+- peerの引数が、自分の呼称と相手の呼称に分かれます。
+- `offer QR state`は`idle`、`generating-offer`、`rendering`、`displayed`、`error`を返していました。
+  `pairing phase`は往復の各段階に状態を持ち、QR読取り完了と接続成立を別々に報告します。
+- 起動時フラグは`__TWMP_FEATURE_FLAGS__.qrCourierPairing`ではなく
+  `__TWQP_FEATURE_FLAGS__.qrCodePairing`です。誤り訂正の設定も`__TWMP_QR_CONFIG__`から
+  `__TWQP_QR_CONFIG__`に変わります。
+
+### この移行に含まれないこと
+
+本拡張は`turbowarp-realtime-motion-capture`を変更も削除もしません。同リポジトリのQR経路と
+manual pairing経路はそのまま残ります。旧経路の廃止や`turbowarp-time-space-sync`側の責務調整は、
+それぞれのリポジトリの別Issueとして扱います。
+
+## 2. manual pairingへの切戻し
+
+ペアリング用ブロックは経路の1つであり、必須ではありません。使うのをやめるには次のようにします。
+
+1. `globalThis.__TWQP_FEATURE_FLAGS__ = {qrCodePairing: true};`の設定をやめる。
+2. `turbowarp-webrtc`のブロックで直接ペアリングする。
+   - hub: `create offer code for peer [PEER]`、続いて`offer code for peer [PEER]`
+   - カメラ側: `accept offer code [CODE] as peer [PEER]`、続いて`answer code for peer [PEER]`
+   - hub: `accept answer code [CODE] for peer [PEER]`
+
+   接続情報の運搬方法は会場の事情に合わせて選びます。
+3. 拡張自体は読み込んだままで構いません。フラグが無効ならブロックを公開せず、何もしません。
+
+フラグの無効化は経路の選択です。成立済みの接続を切断することはなく、既存のpeer接続を閉じることも
+ありません。
+
+フラグは起動時に一度だけ読むため、変更は次回の読込みから有効になります。プロジェクトの実行中に
+経路が変わると失敗の解釈が難しくなるため、意図的にそうしています。
+
+## 3. 変更後の回帰確認
+
+`pnpm run check`を実行します。型検査、lint、テスト、README生成検証、ビルド再現性、リポジトリ方針
+検査、npm梱包のdry-runが含まれます。
+
+これに加えて、搬送形式や状態機械に手を入れた場合は手動で確認してください。光学条件はCIで
+検証できません。
+
+- [ ] 単一partと複数partの交換が、どちらも完了する。
+- [ ] 順不同で読んだpartと、同じpartの重複読取りが、正しく再構成される。
+- [ ] 不足partが`missing parts of [SESSION]`に現れ、再構成されない。
+- [ ] 破損したpartが`hash-mismatch`で失敗し、WebRTCへ何も渡らない。
+- [ ] カメラ側2台を順に接続しても、Answerが入れ替わらない。
+- [ ] 取消・期限切れ・再試行のいずれでも表示とカメラが解放され、再試行前に撮影したQRが拒否される。
+- [ ] 表示終了、プロジェクト停止、スプライト削除のいずれでもスプライトが元のコスチュームに戻る。
+- [ ] 同じカメラを他が保持していれば、session終了後もカメラが止まらない。
+- [ ] フラグ無効でペアリング用ブロックが現れず、manual pairingが動く。
+
+実機の試行は[利用ガイドの記録テンプレート](integration-guide.ja.md#12-実機検証の記録)で記録します。
+
+## 4. 将来、搬送形式を変えるとき
+
+別のenvelopeが必要になった場合は次の方針です。
+
+- 受信側は`protocol`を完全一致で判定し、それ以外を拒否します。未知のversionは中途半端に読まれず
+  必ず拒否されます。
+- 必須フィールドの追加はversionの変更であり、拡張ではありません。
+- 旧形式の扱いと移行方法を、このページが`twmp-qr/1`について記しているのと同じ形で記載します。

package/docs/migration.md

@@ -0,0 +1,115 @@
+# Migration and rollback
+
+[日本語](migration.ja.md)
+
+## 1. Coming from turbowarp-realtime-motion-capture
+
+`turbowarp-realtime-motion-capture` carries an offer as QR codes with the `twmp-qr/1` format, behind
+its own `qrCourierPairing` flag. Its blocks are `prepare offer QR`, `show offer QR part`,
+`show next offer QR part`, `end offer QR display`, `offer QR state` and `offer QR error`.
+
+That path only covers the offer. The camera machine has to accept the offer and return an answer by
+some other means, which is what this extension adds.
+
+### Format
+
+`twqr/1` is **not compatible** with `twmp-qr/1` and does not read it. `twmp-qr/1` carries one peer
+name and no reply-to, so it cannot express:
+
+- which name the sender uses for itself versus for the receiver, and
+- which offer an answer is replying to.
+
+Both are required here: the first so the two machines never need matching identifiers, the second so
+an answer cannot be applied to the wrong exchange. Adding required fields is not a backward
+compatible change, so the format got a new namespace and version.
+
+A `twmp-qr/1` code presented to this extension is refused with `unsupported-protocol`. There is no
+read-compatibility mode: accepting a code that cannot express the peer mapping would mean guessing
+it, and a wrong guess pairs the wrong machines. An explicit refusal is safer than an ambiguous
+acceptance.
+
+The two can be used in the same venue. They will not read each other's codes, but the failure is
+reported rather than silent.
+
+### Block mapping
+
+| motion-capture | here |
+|---|---|
+| `prepare offer QR for peer [PEER]` | `start offer pairing [SESSION] as [LOCAL_PEER] to [REMOTE_PEER]` |
+| `show offer QR part [INDEX] on this sprite` | `show pairing QR part [INDEX] of [SESSION] on this sprite` |
+| `show next offer QR part on this sprite` | `show next pairing QR part of [SESSION] on this sprite` |
+| `offer QR part count` | `pairing QR part count of [SESSION]` |
+| `current offer QR part` | `current pairing QR part of [SESSION]` |
+| `end offer QR display` | `end pairing QR display of [SESSION]` |
+| `offer QR state` | `pairing phase of [SESSION]` (more states; see the integration guide) |
+| `offer QR error` | `pairing error code of [SESSION]` and `pairing error message of [SESSION]` |
+| — | everything on the answer side, scanning, cancel, retry, timeout |
+
+Differences to expect when porting a project:
+
+- Every block takes a session name, so one project can pair several machines.
+- The peer argument splits into a local name and a remote name.
+- `offer QR state` returned `idle`, `generating-offer`, `rendering`, `displayed` or `error`.
+  `pairing phase` has a state per step of the round trip, and reports QR completion and connection
+  separately.
+- The startup flag is `__TWQP_FEATURE_FLAGS__.qrCodePairing`, not
+  `__TWMP_FEATURE_FLAGS__.qrCourierPairing`. The error correction setting moves from
+  `__TWMP_QR_CONFIG__` to `__TWQP_QR_CONFIG__`.
+
+### What is not part of this migration
+
+This extension does not remove or change anything in `turbowarp-realtime-motion-capture`. Its QR
+path and its manual pairing path stay as they are. Retiring the old path there, and adjusting
+responsibilities in `turbowarp-time-space-sync`, are separate issues in those repositories.
+
+## 2. Rolling back to manual pairing
+
+The pairing blocks are a route, not a requirement. To stop using them:
+
+1. Stop setting `globalThis.__TWQP_FEATURE_FLAGS__ = {qrCodePairing: true};`.
+2. Pair with the `turbowarp-webrtc` blocks directly:
+   - hub: `create offer code for peer [PEER]`, then `offer code for peer [PEER]`;
+   - camera machine: `accept offer code [CODE] as peer [PEER]`, then `answer code for peer [PEER]`;
+   - hub: `accept answer code [CODE] for peer [PEER]`.
+   Move the codes by whatever means the venue allows.
+3. Leave the extension loaded if you like. With the flag off it publishes no blocks and does
+   nothing.
+
+Turning the flag off selects the other route. It never disconnects an established connection, and it
+does not close peer connections that already exist.
+
+Because the flag is read once at startup, changing it takes effect on the next load, not while a
+project is running. That is deliberate: a route that could change mid-session would make failures
+hard to interpret.
+
+## 3. Regression checks after a change
+
+Run `pnpm run check` — type checking, lint, the test suite, README generation, build reproducibility,
+the repository policy check, and an npm pack dry run.
+
+Beyond that, a change to the transport or the state machine should be re-verified by hand, because
+optical conditions are not testable in CI:
+
+- [ ] A single-part exchange and a multi-part exchange both complete.
+- [ ] Parts read out of order, and the same part read repeatedly, still assemble.
+- [ ] A missing part is reported by `missing parts of [SESSION]` and never assembles.
+- [ ] A damaged part fails with `hash-mismatch` and nothing reaches WebRTC.
+- [ ] Two camera machines pair one after another without their answers crossing.
+- [ ] Cancel, timeout and retry each release the display and the camera, and a code photographed
+      before a retry is refused.
+- [ ] The sprite returns to its original costume after ending the display, stopping the project, and
+      removing the sprite.
+- [ ] Another holder of the same camera keeps it running after the session ends.
+- [ ] With the flag off, no pairing blocks appear and manual pairing still works.
+
+Record hardware runs with the template in the [integration guide](integration-guide.md#12-recording-a-hardware-test).
+
+## 4. Changing the transport format later
+
+If a future change needs a different envelope:
+
+- Receivers match `protocol` exactly and refuse anything else, so an unknown version is always
+  rejected rather than half-read.
+- Adding a required field is a version change, not an extension.
+- Document the old format's treatment and the migration path here, as this page does for
+  `twmp-qr/1`.

package/package.json

@@ -0,0 +1,90 @@
+{
+  "name": "@kubohiroya/turbowarp-webrtc-qrcode-pairing",
+  "version": "0.1.0",
+  "description": "TurboWarp extension that pairs WebRTC peers by carrying offers and answers as QR codes.",
+  "author": "Hiroya Kubo <hiroya@cuc.ac.jp>",
+  "license": "MPL-2.0",
+  "homepage": "https://github.com/kubohiroya/turbowarp-webrtc-qrcode-pairing#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/kubohiroya/turbowarp-webrtc-qrcode-pairing.git"
+  },
+  "bugs": {
+    "url": "https://github.com/kubohiroya/turbowarp-webrtc-qrcode-pairing/issues"
+  },
+  "keywords": [
+    "turbowarp",
+    "scratch",
+    "extension",
+    "webrtc",
+    "qrcode",
+    "pairing",
+    "typescript"
+  ],
+  "type": "module",
+  "files": [
+    "dist/",
+    "docs/",
+    "schemas/",
+    "src/",
+    "templates/",
+    "README.md",
+    "README.ja.md",
+    "LICENSE"
+  ],
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/"
+  },
+  "packageManager": "pnpm@11.11.0",
+  "engines": {
+    "node": ">=22.18.0"
+  },
+  "scripts": {
+    "dev": "vite build --watch",
+    "typecheck": "tsc --noEmit",
+    "build": "vite build",
+    "build:flagged": "node scripts/build-flagged.ts",
+    "lint": "eslint src tests scripts vite.config.ts",
+    "test": "vitest run",
+    "docs": "node scripts/generate-readme.ts",
+    "docs:check": "node scripts/check-readme.ts",
+    "template:readme": "node scripts/apply-readme-template.ts",
+    "repo:check": "node scripts/check-repo.ts",
+    "pack:check": "npm pack --dry-run --ignore-scripts",
+    "check": "pnpm run typecheck && pnpm run lint && pnpm run test && pnpm run docs:check && pnpm run check:dist && pnpm run repo:check && pnpm run pack:check",
+    "check:dist": "pnpm run build && node scripts/check-dist.ts"
+  },
+  "devDependencies": {
+    "@eslint/js": "^9.39.5",
+    "@kubohiroya/turbowarp-jsqr": "0.3.0",
+    "@kubohiroya/vite-plugin-turbowarp-extension": "0.3.0",
+    "@types/node": "^24.13.3",
+    "@types/qrcode": "1.5.6",
+    "eslint": "^9.39.5",
+    "jsqr": "^1.4.0",
+    "typescript": "^5.9.3",
+    "typescript-eslint": "^8.66.0",
+    "vite": "^8.2.2",
+    "vitest": "^5.0.0"
+  },
+  "dependencies": {
+    "qrcode": "1.5.4"
+  },
+  "peerDependencies": {
+    "@kubohiroya/turbowarp-webrtc": ">=0.4.0",
+    "@kubohiroya/turbowarp-jsqr": "0.3.0",
+    "@kubohiroya/turbowarp-camera-source": "0.5.0"
+  },
+  "peerDependenciesMeta": {
+    "@kubohiroya/turbowarp-webrtc": {
+      "optional": true
+    },
+    "@kubohiroya/turbowarp-jsqr": {
+      "optional": true
+    },
+    "@kubohiroya/turbowarp-camera-source": {
+      "optional": true
+    }
+  }
+}

package/schemas/extension-manifest.schema.json

@@ -0,0 +1,49 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://raw.githubusercontent.com/kubohiroya/turbowarp-extension-template/main/schemas/extension-manifest.schema.json",
+  "title": "TurboWarp Extension API Manifest",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["formatVersion", "id", "blocks", "menus"],
+  "properties": {
+    "formatVersion": {"const": 1},
+    "id": {"type": "string", "pattern": "^[a-z0-9]+$"},
+    "blocks": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["opcode", "blockType", "arguments"],
+        "properties": {
+          "opcode": {"type": "string", "minLength": 1},
+          "blockType": {"type": "string", "minLength": 1},
+          "arguments": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "additionalProperties": false,
+              "required": ["id", "type"],
+              "properties": {
+                "id": {"type": "string", "minLength": 1},
+                "type": {"type": "string", "minLength": 1},
+                "menu": {"type": "string", "minLength": 1}
+              }
+            }
+          }
+        }
+      }
+    },
+    "menus": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["id", "acceptReporters"],
+        "properties": {
+          "id": {"type": "string", "minLength": 1},
+          "acceptReporters": {"type": "boolean"}
+        }
+      }
+    }
+  }
+}