@volter/twin-tiktok 0.1.0

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,310 @@
+# @volter/twin-tiktok
+
+A local, stateful, vendor-faithful twin of **TikTok's Login Kit, Display API and Content Posting
+API** — the tiktok.com authorization page, the full OAuth round trip (token, refresh, revoke,
+client_credentials), `GET /v2/user/info/` + `POST /v2/video/list/` + `POST /v2/video/query/`
+with TikTok's real field selection, scope gating and error envelopes, and a creator's video posted
+the way TikTok takes it: `creator_info`, the Direct Post and inbox inits, the chunked `PUT` to a
+signed upload URL, and `status/fetch` walking the publish by World time.
+
+**First, register your app.** TikTok publishes no API that creates a developer app, so the twin
+cannot guess your `client_key`: a world must `POST /_twin/clients` with the key, secret and
+redirect URI its application uses *before* the authorize leg will answer anything but
+`invalid_client`. That one seeding call is the whole setup — after it, point an unmodified TikTok
+integration at the twin and complete a sign-in-with-TikTok flow offline.
+
+```bash
+curl -X POST "$TIKTOK_TWIN/_twin/clients" -H 'content-type: application/json' \
+  -d '{"client_key":"'"$TIKTOK_CLIENT_ID"'","client_secret":"'"$TIKTOK_CLIENT_SECRET"'",
+       "name":"My App","redirect_uris":["https://my.app/api/auth/callback/tiktok"]}'
+```
+
+```bash
+bun run packages/twin/tiktok/src/cli.ts mirror
+# tiktok twin (Login Kit OAuth + Display API) at http://127.0.0.1:54321
+# authorization page: http://127.0.0.1:54321/v2/auth/authorize?client_key=…
+```
+
+## Five things this vendor does that its OAuth siblings do not
+
+This pack exists next to `googleoauth` and `xidentity` because TikTok's protocol differs from both
+in ways that break code copied from either:
+
+1. **Scopes are COMMA-separated** (`scope=user.info.basic,user.info.profile`), not space-separated.
+   A space-separated string is one unknown scope here, and the twin refuses it as `invalid_scope`.
+2. **Consent is GRANULAR.** The documented callback carries a `scopes` parameter — "the
+   authorization scope(s) which the user has granted" — so the granted set may be a SUBSET of what
+   was requested. The authorization page this twin serves offers a checkbox per requested scope,
+   and unchecking one narrows the token and makes the Display API refuse the field that scope gated.
+3. **PKCE is OPTIONAL, and its challenge is HEX SHA-256.** TikTok requires PKCE for desktop apps
+   only (web apps, Dub included, send none), and when it is used the `code_challenge` is the
+   64-character hex digest — *not* RFC 7636's base64url. A helper copied from an X or Google
+   integration produces a challenge the real vendor rejects, and so does this twin.
+4. **The client authenticates in the BODY.** `client_key` + `client_secret` form fields; TikTok
+   documents no HTTP Basic alternative, so an `Authorization` header on the token endpoint is
+   ignored rather than honoured. (Dub sends one — its callback route is shared with a Basic-auth
+   provider — and the exchange must still succeed.)
+5. **`open_id` is PER APP, `union_id` is per human.** The same account authorizing two apps yields
+   two different `open_id`s and one `union_id`, and re-authorizing the same app yields the SAME
+   `open_id`. An app that keys its user records on `open_id` must not see a new person each login.
+
+There are **two error envelopes**, not one: the OAuth endpoints answer the flat
+`{error, error_description, log_id}` body and the v2 API answers the nested
+`{data, error:{code, message, log_id}}` one — which is present on SUCCESS too, with
+`code: "ok"`. The `log_id` is deterministic here (14 digits of UTC `yyyyMMddHHmmss` plus 20
+uppercase hex, the vendor's own shape), because a served byte may not carry a clock or entropy.
+
+It is a **browser-facing protocol pack** (the `googleoauth` class): the authorization page is
+served as HTML at the vendor's real path (`https://www.tiktok.com/v2/auth/authorize`),
+server-rendered from the twin's own kernel projection by the **same React components** the pack
+ships — one renderer, so API↔UI parity cannot drift. The whole decision is a plain `<form>` with a
+checkbox per scope and two submit buttons, so **no JavaScript is required to complete an OAuth
+round trip** against this twin: the pack ships no browser bundle, the stylesheet is inlined, and
+`curl`, redirect-following HTTP libraries and headless browsers all behave identically.
+
+## Posting a video
+
+The Content Posting API as its references describe it (developers.tiktok.com, fetched
+2026-09-27), driven with nothing but `curl`:
+
+```bash
+# a creator and a token that may post (the twin's own doors: TikTok has no API for either)
+curl -X POST "$TIKTOK_TWIN/_twin/accounts" -H 'content-type: application/json' \
+  -d '{"union_id":"11111111-2222-4333-8444-555555555555","username":"volter","display_name":"Volter"}'
+curl -X POST "$TIKTOK_TWIN/_twin/tokens" -H 'content-type: application/json' \
+  -d '{"union_id":"11111111-2222-4333-8444-555555555555","scopes":["user.info.basic","user.info.stats","video.list","video.publish"]}'
+
+curl -X POST "$TIKTOK_TWIN/v2/post/publish/creator_info/query/" -H "Authorization: Bearer $TOKEN"
+curl -X POST "$TIKTOK_TWIN/v2/post/publish/video/init/" -H "Authorization: Bearer $TOKEN" \
+  -H 'content-type: application/json; charset=UTF-8' \
+  -d '{"post_info":{"title":"Release #volter","privacy_level":"PUBLIC_TO_EVERYONE"},
+       "source_info":{"source":"FILE_UPLOAD","video_size":14904527,"chunk_size":5242880,"total_chunk_count":2}}'
+# → {"data":{"publish_id":"v_pub_file~v2-1.…","upload_url":"$TIKTOK_TWIN/video/?upload_id=…&upload_token=…"}, …}
+curl -X PUT "$UPLOAD_URL" -H 'Content-Type: video/mp4' -H 'Content-Range: bytes 0-5242879/14904527' --data-binary @chunk1  # 206
+curl -X PUT "$UPLOAD_URL" -H 'Content-Type: video/mp4' -H 'Content-Range: bytes 5242880-14904526/14904527' --data-binary @chunk2  # 201
+curl -X POST "$TIKTOK_TWIN/v2/post/publish/status/fetch/" -H "Authorization: Bearer $TOKEN" -d '{"publish_id":"…"}'
+# → PROCESSING_UPLOAD, then PUBLISH_COMPLETE with "publicaly_available_post_id":[7063961975802954486]
+```
+
+- **The chunk rules are TikTok's**: a video under 5 MB is one whole chunk; chunks are 5–64 MB;
+  `total_chunk_count` is `video_size / chunk_size` rounded down, the final chunk carrying the rest
+  (up to 128 MB); a video over 64 MB takes more than one chunk; at most 1000 chunks and 4 GB. Chunks
+  go in order: out of order is 416, a size that disagrees with the plan is 400, and each chunk answers
+  206 until the last answers 201. **The twin's own limit is lower, and says so**: it holds a video
+  whole when the last chunk lands (the kernel's blob seam stores bytes, not a stream), so an init
+  over 512 MiB is refused with `invalid_param` naming that limit.
+- **`privacy_level` is the creator's choice from creator_info**: missing, or not one of their
+  `privacy_level_options`, is `privacy_level_option_mismatch` (403).
+- **The upload URL is signed, not looked up.** Like TikTok's, it is a different address from the
+  API — `/video/` under the twin's public base, or `https://open-upload.tiktokapis.com/video/` when
+  the request came through a World's injector naming `open.tiktokapis.com` (the pack claims that
+  host, so the PUT routes back here) — and its `upload_token` is an HMAC over the upload and its
+  expiry, keyed by that upload's own secret drawn from entropy at init. The PUT carries no bearer; a
+  token altered by a character is 403, and so is the URL after its hour. Publish ids, upload ids and
+  post ids are drawn from entropy too, so a World cloned from another never reissues the origin's.
+- **The lifecycle is World time**: `PROCESSING_UPLOAD` while chunks arrive and for the twin's
+  processing interval after (2 s plus 1 s per 10 MiB — TikTok publishes none), then
+  `PUBLISH_COMPLETE` (or `SEND_TO_USER_INBOX` for an inbox upload, which posts nothing to the
+  profile). The Direct Post appears in `/v2/video/list/` from that instant. What TikTok's
+  processing checks and the file's own headers can show fails the publish (`FAILED`, nothing
+  posted): bytes that are no readable video (`file_format_check_failed`), longer than the creator's
+  maximum (`duration_check_failed`), outside 23–60 FPS (`frame_rate_check_failed`) or outside
+  360–4096 px (`picture_size_check_failed`). `publicaly_available_post_id`
+  is written as bare int64 JSON numbers, as TikTok writes them — so a client that `JSON.parse`s a
+  19-digit id into a double loses digits here, not in production.
+- **Each endpoint meters its own minute** at its reference's figure: creator_info 20, the inits 6,
+  status/fetch 30, per user token.
+- **The bytes are the bytes.** Chunks are staged one key each and joined once, when the last lands;
+  the video is stored content-addressed on the kernel's blob seam and read back through its
+  resource-blob helpers, so a branch plays its ancestors' posts. `GET /_twin/media/video/<post id>`
+  (under the twin's public base) serves it with Range — 206, 416 past the end, an open-ended range
+  capped at 8 MiB, an inverted range ignored as RFC 9110 says (200) — and a post that is not
+  `PUBLIC_TO_EVERYONE` plays only with its creator's `access_token`.
+- **No credential is kept in the clear.** Access, refresh and client tokens, authorization codes
+  and rate windows are the twin's `_`-prefixed bookkeeping (never deployed, never pushed), each keyed
+  by the SHA-256 of its credential; an app's client secret, a publish's token and an upload's token
+  are kept as hashes; an upload's signing secret is its own. An app registered through
+  `/_twin/clients` without a secret gets one drawn from entropy, answered once. A presented credential is hashed and
+  looked up.
+
+The one kernel write is the finalize: `video.publish` (the video on the profile, and its `publish`
+row) or `video.inbox_upload`. Staging is never a kernel action, so an abandoned upload leaves nothing
+for a deploy to trip on. **Deploying** that entry to a real TikTok root performs the same flow
+against the vendor (see *The three operations*).
+
+## The mirror: tiktok.com over the twin's state
+
+A creator posts and reads their profile on tiktok.com, so the pack ships tiktok.com's view of what
+was posted — a React app over the twin's own Display API, on the twin's origin:
+
+```bash
+bun run packages/twin/tiktok/src/cli.ts mirror
+# mirror (tiktok.com profile + player): http://127.0.0.1:54321/
+```
+
+- **Log in** as tiktok.com's form asks — the username, then, in place of the password, the access
+  token the twin issued for that creator (`POST /_twin/tokens`). A token for another account is
+  refused on the form; both stay in the tab's sessionStorage.
+- **The profile**: the avatar (the creator's initial — the twin holds no image), `@username` with the
+  verified tick, the nickname, Following / Followers / Likes **only as `/v2/user/info/` returns them**
+  (a token without `user.info.stats` or a persona seeded without counts draws none), the bio, and the
+  Videos tab's 9:16 grid of the creator's posts, newest first, each tile the post's own first frame
+  and its play count.
+- **The player**: a post opens full height and vertical, playing its bytes from
+  `/_twin/media/video/<id>` (Range, the creator's token on the URL) over a blurred copy of itself,
+  with the `@handle`, the caption and its hashtags, the sound line, the action rail carrying the
+  Video Object's own like/comment/share counts, and up/down to the neighbouring posts.
+
+Inside a World it is mounted at `/<org>/<world>/tiktok/mirror/`: the shell (`tiktokMirrorHtml`) has
+`<base href="/">` and relative `assets/`, the client (`buildTiktokMirrorClient`) routes on `#/`, and
+its reads go to the keyed wire with the browser's World session.
+
+## Coverage
+
+Partial and honest. The manifest (`src/tiktok-capabilities.ts`) is the **Login Kit + Display API +
+Content Posting** denominator — the surface a user access token reaches — and it also carries
+TikTok's other open-platform products (Research, Data Portability, Local Services, the mobile/QR
+login variants, the photo post) and the separate business-api.tiktok.com Ads API as honest `todo`s
+rather than silent omissions.
+
+It currently reads **142 done / 218 covered** (76 `todo`, across 25 areas) — and the percentage is
+flattering, so here is the magnitude of what discounts it, measured rather than hand-waved:
+
+- **The eleven endpoints this pack serves are enumerated per BEHAVIOUR** (a parameter honoured, an
+  error produced, a field gated) — the six Login Kit + Display endpoints at about 19 rows apiece,
+  Content Posting at 14 `done` plus 8 pinning/model `todo`s — **while the product families it does
+  not serve are enumerated per OPERATION FAMILY**, about 3 rows apiece. Modelling one of them would
+  add a `done` per behaviour where a few `todo`s sit today.
+- **16 of the 142 `done` rows never issue a request at the twin's wire at all**: three compare the
+  twin's copy of TikTok's published error/scope tables against a literal, twelve drive the
+  connector's pricing, mapping and budget over injected executors, and one checks the mirror
+  module's exports build. They are real claims, but they say nothing about what the served HTTP
+  surface does.
+- **25 of the 142 assert an HTTP status on the flat OAuth envelope that TikTok publishes no status
+  column for.** Its error reference lists the ten `error` values and their descriptions and stops
+  there; the twin answers RFC 6749 §5.2's 400/401, and `tiktok.token.error_http_status` is the
+  `todo` that pins the live ones. If the vendor turns out to answer 200 with an error body — as
+  some OAuth implementations do — those 25 rows are asserting the wrong half of the wire.
+
+The honest correction is to expand the unserved families as each is read from its own reference,
+and to close the pinning `todo`s against the live vendor — never to pad the denominator now with
+rows nobody has read the docs for.
+
+### No first-party spec — the denominator is hand-authored
+
+TikTok publishes **no** machine-readable specification for the open API: no OpenAPI, no SDL, no
+Discovery document. Its reference material is prose, curl examples and hand-written tables, and its
+one first-party generated SDK (`tiktok-business-api-sdk`) speaks the *Business/Ads* API on a
+different host. So the denominator was authored top-down from the published references, all fetched
+**2026-09-13**, and every capability cites the one that grounds it: Login Kit for Web and for
+Desktop; User Access Token Management and Client Access Token Management; the Scopes Overview; Get
+User Info; the Video Object / Video List / Video Query references; the OAuth and API-v2
+error-handling references; and the rate-limit reference. `census.json`'s `spec` slice records that
+trail in full.
+
+The `todo`s are real TikTok surface this twin does not model — most notably the **photo post** and
+**PULL_FROM_URL** (both need the developer portal's verified domains), the **webhook events page** (`authorization.removed`
+with its reason enum, `video.publish.completed`, `video.upload.failed`,
+`portability.download.ready`, and delivery/signature itself), the public unauthenticated
+**oEmbed** read, **Share Kit**, the **Research API**, **Data Portability**, the **Mini Games /
+Mini Dramas / TikTok GO** product families, and the **Business/Ads API** — plus a family of
+**wire-pinning todos**: behaviours
+the twin models from RFC 6749/7009 or from a widely-reported capture because no fetched official
+artefact states them (the HTTP status of an OAuth failure, the authorization-code format and
+lifetime, whether the live vendor always rotates a refresh token, the authorize error page, the
+live consent sheet's affordances, the dimension the 600/minute limit is enforced on). Each such
+`done` names its evidence boundary in the manifest and its pinning `todo`.
+
+### What is real here
+
+- **The complete round trip.** Authorize request → authorization page → 302 to `redirect_uri` with
+  exactly `code`, `scopes` and `state` (the documented callback parameters) → the code is
+  redeemable **exactly once** → `refresh_token` grant (rotating) → revoke kills the whole (app,
+  user) grant. One pack against one state root, so the code minted at the screen is honoured at the
+  token endpoint by construction.
+- **`disable_auto_auth`**, modelled: with `0` and an existing grant covering the request, the page
+  is skipped and a code bounces straight back; a first authorization or a widened scope set still
+  shows it. The default (parameter absent) shows the page — bypassing the human leg is the thing
+  this pack exists to make visible.
+- **Exact callback matching** — a trailing-slash variant is a different Redirect URI, so
+  `redirect_uri`-mismatch bugs reproduce, on the vendor's own error page, with the app never
+  reached.
+- **The Display API reads** — `fields` selection over the documented 14 user fields and 16 video
+  fields, per-scope field gating (`scope_not_authorized`, 401), `max_count` defaulting to 10 and
+  capped at 20, millisecond cursor pagination, the 20-id query limit, and a foreign video id
+  omitted rather than 404'd.
+- **The documented rate limit** — a one-minute sliding window at 600, enforced separately per
+  endpoint, answering HTTP 429 with `rate_limit_exceeded`. TikTok publishes no rate-limit response
+  headers, so the twin invents none.
+- **Vendor-shaped opaque credentials** — `act.` / `rft.` / `clt.` prefixes, and an authorization
+  code carrying the characters that make the documented "URL decoded" requirement observable: the
+  raw callback text does not redeem, the decoded one does.
+- **Fidelity over real transport** — `tiktok-sdk.integration.test.ts` drives the twin through a
+  socket with the exact calls Dub's unmodified source makes (TikTok publishes no official npm
+  client, so ADDING_A_TWIN.md §10's real-transport `fetch` alternative applies).
+
+### What is not
+
+The twin **authenticates nobody**: no password, no 2FA, no risk engine. The tiktok.com "signed in"
+session is a seeded persona row — `POST /_twin/session` switches it, which is the honest local
+equivalent of "the browser is already signed in". There is also no TikTok API that creates a
+developer app, so a world running a real integration registers its own `client_key` through
+`POST /_twin/clients`; the seeded `Twin Demo App` is a convenience, not a claim.
+
+### Twin-only scaffolding (not vendor surface, not counted)
+
+`GET /_twin/consent` (re-render a pending authorization page by request handle) and
+`POST /_twin/consent` (the Continue/Cancel form post — TikTok's real sheet posts to an undocumented
+internal endpoint), `POST /_twin/clients`, `POST /_twin/accounts` (also what creator_info answers:
+`is_private`, `privacy_level_options`, the comment/duet/stitch switches,
+`max_video_post_duration_sec`), `POST /_twin/videos` (a metadata-only video for a Display API
+fixture; a video with its media is posted through the Content Posting API), `POST /_twin/tokens`
+(a user access token with the named scopes — what a World issues in place of the consent leg),
+`POST /_twin/session`, `POST /_twin/rate_limit` (arm a deterministic 429) and
+`GET /_twin/media/video/<post id>` (a published video's bytes; TikTok's CDN is not Open API
+surface). This list is the audit trail the conformance
+census deliberately excludes — keep it in lockstep with `twinControl`'s branches in
+`tiktok-twin.ts`.
+
+## The three operations
+
+- **pull** — `syncTikTokFromReal(execute)` observes the real account behind the operator's own user
+  token (`GET /v2/user/info/`, every modelled field) over an **injected executor**, and their
+  videos when `videos: true` (the video reads need the separate `video.list` scope, so they are
+  opt-in rather than silently skipped). Live runs use `liveTikTokExecute(accessToken)`, the ONE
+  place a real TikTok request may be issued, guarded by the fail-closed rate budget
+  (`tiktok-budget.ts`: TikTok's own 600-per-minute scheme, live-fetched 2026-09-13). The app
+  registry and the token's scope set are **not observable** (no API reads TikTok apps; TikTok has
+  no token introspection) — reasoned gaps, not fakes. Accounts are keyed by `union_id`, so one
+  human is one twin account however many apps they authorize.
+- **write** — the default: local consent flows mint local credentials and local posts, no real calls.
+- **perform** — a World's post crosses when its root is TikTok: `performTikTokAction` sends a
+  `video.publish` entry through the vendor's own Direct Post flow (creator_info, whose
+  `privacy_level_options` must include the entry's privacy level; `video/init` with the chunk plan
+  TikTok's rules require; each chunk `PUT` to the returned `upload_url` **presigned** — without the
+  sealed credential, on the upload host; `status/fetch` until `PUBLISH_COMPLETE`), and a
+  `video.inbox_upload` through the inbox init to `SEND_TO_USER_INBOX`. The bytes come off the blob
+  seam a chunk at a time. The pack budget wraps the executor with one ledger per sealed credential
+  (its keyed fingerprint — every World posting as one account spends one allowance), per World root
+  only when none is sealed:
+  creator_info, the init and every status read are charged (at 600 over each reference's per-minute
+  figure), an answer that arrived is never dropped, and the chunk `PUT`s are not charged — once a
+  publish has started, the budget cannot stop it. The wait reads status every 3 s and stops at
+  120 s, failing retryably — as does a 429 or 5xx from TikTok, or a chunk TikTok does not take; the
+  publish it opened and its upload URL are kept in this World's byte annex (never an entry, never a
+  changeset), so the next deploy asks that publish where it stands and resumes its missing chunks
+  instead of posting twice. It opens a fresh publish only when TikTok says the old one is gone
+  (`invalid_publish_id`, or `FAILED`): `uploaded_bytes` is a count of what arrived, and no count
+  means TikTok will not still post it. Nothing else
+  crosses: apps, users, tokens and grants have no TikTok write API, and each entry says so.
+
+## Serving
+
+`world-tiktok serve` starts one server for the WHOLE surface; point `www.tiktok.com` (the
+authorization path only), `open.tiktokapis.com` (the Login Kit, Display and Content Posting paths
+only) and `open-upload.tiktokapis.com` (`/video/` only) at it — the pack descriptor's path-scoped
+`hosts` entries do exactly that, so an unmodelled TikTok call refuses loudly instead of landing in a
+twin that cannot serve it. `mirror` is the same twin with the tiktok.com mirror at `/`, and prints a
+ready-to-open authorization URL for the authorization page too; `conformance` runs the endpoint
+census (one real probe per claimed endpoint + the hand-enumerated router surface + a reachability
+witness per resource type).