What changed in each simulator release, newest first.

Slack

v0.0.19 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

4. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

5. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.18 — 2026-10-11

1. The verified UI installs and starts with rystic ui slack. The Slack client built against Slack’s own client is a Pro and Enterprise deliverable: it ships as the image registry.rystic.ai/slack-twin-ui:<ver> beside the twin’s, pulled with the same docker login, and rystic ui runs it against a running instance (or, without Docker, the UI’s archive on your Node 22+). A Free key is refused with feature_not_in_plan, naming the verified_ui entitlement; the Web API and the embedded state UI stay on every plan. (RYS-2403)

2. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.17 — 2026-10-10

1. Scheduled messages post when the twin’s clock reaches them. A chat.scheduleMessage posts once, as its author and in its thread, when simulator time reaches post_at, and then leaves chat.scheduledMessages.list; a cancelled message never posts. (RYS-1572)

2. Ephemeral posts reach the activity stream, and stream starts keep their chunks. A successful chat.postEphemeral emits one slack.message.ephemeral event on /_rystic/events naming its recipient, and never enters history. A chat.startStream with chunks and no markdown_text stores the chunks’ text as the message text. (RYS-1575)

3. Closing a DM closes it only for you. conversations.close closes the DM for the caller alone and leaves the other participants’ view untouched; conversations.open on it reopens it for the caller with their read position kept. (RYS-1570)

4. Deleting a message removes its pin and its reactions, as Slack does. After chat.delete, pins.list on the channel no longer lists the message, and reactions.get on it answers message_not_found. A thread parent kept as a tombstone, because it still has replies, keeps both; that case is not yet measured. The pin behavior was measured against a live workspace. (RYS-1858)

5. Conversation answers name your workspace’s team, and list and info agree. conversations.create, invite, join, rename, setTopic and setPurpose answer shared_team_ids with your workspace’s team and leave out the latest and unread counts Slack omits there; conversations.list and conversations.info give one conversation the same creator and updated, whoever asks, and a new group DM is named mpdm-… from its members’ handles. setPurpose, rename and join leave their system message in channel history, and a streamed message carries your bot’s bot_id, app_id and bot_profile, reads back as in_progress with the text sent so far until chat.stopStream, and finishes as completed. (RYS-885)

6. A deleted file leaves a tombstone on its share, and a file names its uploader’s team. After files.delete, a message that shared the file keeps it as {"id": …, "mode": "tombstone"}, as Slack does, and files.info answers the uploader’s team in user_team instead of a placeholder. (RYS-891)

7. Refusals carry Slack’s diagnostics, and a published view names your app. Every invalid_arguments refusal carries response_metadata.messages, conversations.invite refusals carry the per-user errors array, and views.publish answers your app’s app_id and bot_id rather than fixed placeholders. A post_at that is not a timestamp on chat.scheduleMessage, a presence other than auto or away on users.setPresence, and markdown_text beside chunks on chat.stopStream answer invalid_arguments, as Slack does. conversations.invite with force=true passes over an unknown user only while another named user can still be added, so beside members alone it answers user_not_found. (RYS-889)

8. Answers carry what Slack’s documented responses fix. Where a handler leaves a field absent or null, the twin answers with the constant, the documented default or the ok tag the method’s documented response fixes for that status, error envelopes included; a value the handler wrote is never replaced. (RYS-1905)

9. Tokens are read and refused the way Slack reads them. A token that is not a Slack token (Bearer x, Bearer token) now answers invalid_auth instead of being accepted. A malformed Authorization header — Bearer alone, or a second one — answers not_authed, as live Slack answers Bearer alone on every method but api.test, which it answers ok, though live Slack refuses a second header with invalid_auth; a header under another scheme, such as Basic, presents no token and answers not_authed too. A form-encoded token now wins over the header, and of two form tokens the last, as live Slack answers; api.test still answers without a token but refuses an invalid one. Rotated xoxe.xoxb-/xoxe.xoxp-, app-level xapp- and workflow xwfp- tokens are recognised kinds, so an app-level token on users.identity answers not_allowed_token_type. (RYS-865)

10. A write moves the records it relates to, as Slack does. A stream started in a thread (chat.startStream with thread_ts), or a file shared into one (files.completeUploadExternal with thread_ts, naming its one conversation in channel_id or channels), moves its parent’s reply_count, reply_users, reply_users_count and latest_reply, as a posted reply does, and the file’s share message is a reply in that thread. pins.remove takes the channel off the message’s pinned_to, so conversations.history counts one pin fewer. conversations.info answers your last_read, which conversations.mark moves. (RYS-1909)

11. An empty workspace holds the bot every token acts as. A twin started without a scenario, and the workspace POST /_rystic/reset wipes to, now hold one bot user, tb-member-user-id of team tb-member-team-id, and every token acts as it. A method that names it now finds it: users.list lists it, and users.info and users.profile.get, among others, answer it instead of user_not_found. A user token’s users.identity answers it instead of invalid_auth, and what you create is authored by it: a channel’s creator, and a message’s user, team, bot_id and app_id, where a minted U00000001 of team T00000002 authored them before. The workspace still holds no team record, so auth.test answers invalid_auth as before. A seed that keys its own caller under member replaces this bot; one that keys every user by its id keeps it beside them, and every token still acts as it. (RYS-1911)

12. HOWTO.md counts every route the twin answers. Its coverage sentence reads 274 routes where it read 73: each of the 67 modelled methods counts at GET and POST on both /<method> and /api/<method>, as GET /_rystic/routes lists them. The twin answers what it did before. (RYS-1918)

13. A file is shared only once its bytes are uploaded, and a /me message reads back as Slack’s. files.completeUploadExternal on a file whose bytes never reached its upload_url still answers ok, but leaves the file untyped and unshared, posts no message and moves no thread parent, as Slack does: upload the bytes first to share a file. A chat.meMessage message reads back with your app’s app_id, a rich_text block and no team, and reactions.get answers a message’s pinned_to while it is pinned. (RYS-1909)

14. A first close answers its flags, an in-flight stream reads back empty, a thread parent carries its thread_ts, a broadcast reply and a /me edit answer no bot_profile, and an IM carries is_archived. conversations.close answers the first close of an open DM with no_op: false and already_closed: false beside ok. reactions.get on a stream still in flight answers an empty text with streaming_state: in_progress, the bot’s bot_id and app_id, and parent_user_id on a reply. A thread’s parent answers thread_ts equal to its own ts once any reply joins it, a streamed reply included. conversations.history lists a broadcast reply (reply_broadcast) with no bot_profile or team, and chat.update of a /me message answers neither. An IM’s conversations.info carries is_archived, and its latest bot message’s bot_profile carries a name. (RYS-885)

v0.0.16 — 2026-10-02

1. Socket Mode envelope ids come from their own range. The first envelope the twin sends carries envelope_id cdf8b689-d7dc-46e6-8000-000000000001 rather than 00000001-0000-4000-8001-000000000001, and later ones count up in their last digits. A client that acknowledges the id it receives sees no difference; a test that pinned an envelope id needs the new one. (RYS-1593)

2. Post as a person with X-Rystic-Surface: client. A chat.postMessage made as a seeded non-bot user with the header X-Rystic-Surface: client stores and emits the message that user would type in the Slack client: user, team, text, blocks and a client_msg_id, with no bot_id, app_id or bot_profile, so an app that ignores bot messages starts a turn on its message and app_mention events. Posts without the header keep their app attribution, as on Slack. (RYS-1663)

v0.0.15 — 2026-10-01

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. Your bot receives Events API events, over Socket Mode or at a request URL. Run the twin with SLACK_TWIN_SOCKET_MODE=1 and point Bolt at it with any xapp- token, or set SLACK_TWIN_EVENTS_URL and SLACK_TWIN_SIGNING_SECRET to have each event POSTed signed. Messages, edits, deletes, mentions, reactions, pins, file shares and channel joins, leaves, creates, renames and archives emit the events Slack sends for them. (RYS-1605)

v0.0.14 — 2026-09-30

1. Inspect offers an identity view, and an injected 429 can carry Retry-After. /_rystic/inspect?view=identities folds identical actor-label aliases for display; the default export retains all records so a reset followed by seeding restores caller identity. A network profile’s reject takes validated headers, so an injected 429 can send the Retry-After a client’s backoff reads. The docs now say what file downloads answer, how state_reaction is keyed, and that a deleted file’s share message keeps its full file. (RYS-1262)

2. File URLs serve the bytes. A GET of a file’s url_private or url_private_download with a Bearer token returns the bytes you uploaded, under the file’s mimetype (the download form as an attachment); without a token it answers 401, and a file whose bytes never reached the twin answers 404. files.completeUploadExternal now returns the file’s mimetype, mode, pretty_type, is_public and url_private_download, as Slack does. (RYS-1265)

3. Thread identities and query errors. Thread replies preserve an existing bot ID from the caller. Missing-argument errors from permalink, file-info, and email-lookup reads, and invalid-limit errors from reactions-list and user-conversations reads, include populated response diagnostics; replies and file-info reads reject non-integer limit values. (RYS-1263, RYS-1264)

4. The state UI shows the workspace as a Slack client. On Pro and Enterprise, /_rystic/ui opens a live Slack-style view of the twin — channels, threads, DMs, Block Kit, App Home and modals — where you can view as any seeded user and post, reply, react, pin, edit or join as them through the Web API, beside Your Bot, Scheduled messages and Views cards. (RYS-1327)

5. The state UI takes the rystic.ai look. /_rystic/ui and its Your Bot, Scheduled messages and Views cards now read in the site’s paper, ink and Space Grotesk instead of the dark theme; the workspace card keeps Slack’s own look. (RYS-1332)

6. Unmodified clients reach the twin at Slack’s hostnames. rystic run slack-twin --intercept boots the twin behind the rystic CLI’s HTTPS gateway, and rystic exec -- <command> routes that command’s calls to slack.com and slack-files.com to it, for supported SDKs using their default transports. (RYS-1398)

7. Missing and invalid arguments answer Slack’s errors. A call missing a required argument answers invalid_arguments with Slack’s response_metadata.messages ([ERROR] missing required field: channel), except users.info without user, which answers user_not_found as Slack does. chat.postMessage with no text, blocks or attachments answers no_text, reactions.add with an emoji name the workspace doesn’t know answers invalid_name, and users.getPresence without user reports the caller’s own presence. (RYS-1267)

8. Thread and message reads reflect earlier writes. A reply_broadcast reply appears in channel history as a thread_broadcast carrying its parent as root. Deleting a reply updates its parent’s reply_count, reply_users and latest_reply; deleting a parent that has replies leaves a tombstone (“This message was deleted.”, from USLACKBOT) that keeps its thread, and deleting it again answers message_not_found. An updated message carries no parse or link_names, and a post answers no username unless you sent one. (RYS-1264, RYS-1266, RYS-1268, RYS-900)

9. Pins list newest first, and Slackbot is a listed user. pins.list lists the most recently pinned item first, pins made in the same second included, and each pinned message carries pinned_info. users.list lists the built-in Slackbot first, as the same object users.info returns for USLACKBOT (is_bot false, Slack’s avatars). Lists the twin doesn’t otherwise order come back in the order their records were created, the same on every run. (RYS-1266, RYS-1268)

10. History windows and reply reads follow Slack. conversations.history with oldest returns the messages just after it, not the channel’s newest, and its cursor pages forward from there, so a bot that catches up from a checkpoint sees every message once. conversations.replies with a reply’s ts returns that reply alone, not its whole thread. (RYS-1266)

11. Long messages are truncated at 4,000 characters. A message longer than 4,000 characters is stored, and read back from history, as its first 4,000 characters; the post’s own answer still echoes the full text, as Slack’s does. (RYS-1267)

v0.0.13 — 2026-09-27

1. Several agents can share one workspace, each under its own token. POST /_rystic/credentials binds a token to a user, and every call with that token acts as that user, with no Rystic header. GET /_rystic/calls lists every request since reset with the identity that made it, for grading. See Identities in the Slack docs. (RYS-1202)

2. Conversation access follows each identity. Private conversation reads respect current membership, including after leaving; human user tokens can read public history without joining. Opening a human–bot DM from either identity reuses the same conversation, including an existing seeded DM. (RYS-1215)

3. Private conversations stay hidden from non-members everywhere. conversations.list shows a private channel, DM or group DM only to its members, as on Slack, and a non-member posting into one gets channel_not_found, the same answer reads give. A refused post no longer writes bot ids onto the caller. (RYS-1236)

v0.0.12 — 2026-09-26

1. HOWTO.md and check.sh start from an API key. HOWTO.md leads with rystic login rys_…, says which control-plane routes Free, Pro and Enterprise reach and what POST /_rystic/reset does on each, documents seeding (twelve registers, state_trigger included, and an inspect dump posted back as it is) and the token rules as served (xoxb-/xoxp- kinds, not_allowed_token_type, the form-body token= fallback), and states that the bundled MCP package, rebound to design_studio, is not yet re-qualified. SCENARIOS.md names design_studio as the world Free boots. check.sh runs the Free and Pro build on your API key (RYSTIC_TOKEN, or the key rystic login stored) as well as the Enterprise build on its license file, looked up in the CLI’s order. (RYS-1204)

v0.0.11 — 2026-09-26

1. Only design_studio ships as a named scenario. The older scenarios are now test-only fixtures and are no longer accepted by --scenario, RYSTIC_SCENARIO, or POST /_rystic/scenario. Tests and evaluations can load their unchanged register maps and clocks from sim/testdata/scenarios/ through the control plane. (RYS-1177)

v0.0.10 — 2026-09-25

1. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

2. design_studio is the same studio on every twin. Its people, clients and project dates now come from one shared world, so the clients, invoice numbers and dates #finance names match what the Stripe, PayPal, Resend and Lob twins hold for Website Design Contractors. The archived project channels were regenerated with each job’s real page count: the workspace now carries 2,951 messages (was 2,959). (RYS-1171)

v0.0.9 — 2026-09-22

1. No change to the twin’s behaviour. Same control plane, scenario pack, seeds, worlds and license gate as v0.0.8, and the free edition’s design_studio world is unchanged. The bundled MCP package pins the same korotovsky/slack-mcp-server v1.3.0 and the same thirteen cases; each receipt its workflow checker writes now carries a schema_version.

v0.0.8 — 2026-09-22

1. A fourth world, design_studio: somebody else’s whole Slack. ./slack-twin --scenario design_studio boots into a web design studio a year in — its own team (TWDC0000001), its own cast of forty-three people and bots, and its own bot token, studiobot. Sixty conversations: five company channels, five craft channels, ten live client projects, two Slack Connect channels shared with clients, four private channels, five DMs, a group DM and twenty-eight archived projects, carrying 2,959 messages with the pins, bookmarks, files, threads, reactions and queued messages a year leaves behind. Six questions are waiting in it that only a reader of this workspace can answer — who is on call, when a client launches, how a site is rolled back — and every one is answered by a record inside the binary. The three Rystic Shop worlds are unchanged, message for message, so a suite pinned to their ts values keeps passing. SCENARIOS.md has the workspace’s channels, people and the six questions.

v0.0.7 — 2026-09-21

1. No change to the licensed twin’s behaviour. Same control plane, scenario pack, seeds, worlds and license gate as v0.0.6. /_rystic/version gains an edition: line — empty on a licensed build — so a caller can tell a licensed twin from the free edition without inspecting anything else.

v0.0.6 — 2026-09-21

1. A pinned native MCP integration. The release includes the korotovsky/slack-mcp-server v1.3.0 bot-token profile, native caller, bounded local gateway, workflow checker and exact thirteen-case pack. The declared tools discover channels, read history and threads, and post replies. Package manifests pin the binaries, tool manifest, model and shipped fixture files. See the bundled MCP README for configuration and explicit exclusions, including hosted Slack MCP and search.

2. Protected runtime contract 9. A trusted harness can require a private gateway credential on all twin requests and preserve service URL identities while routing the native caller locally. Service credentials supplied in accepted form bodies follow the same modelled authentication rules.

3. Measured thread and message fixes. Posting updates stored parent thread registers; history and replies preserve those values. Repeated-parent cursor pages, public block metadata and the single-section Markdown fallback used by the pinned caller follow the controlled workflow evidence. The API test response no longer echoes the bearer token.

Measured scope. The native local workflow passes 13/13 cases, a fresh read-only comparison passes 8/8, and the Linux caller cell passes seven containment checks. The original controlled live comparison and exact local replay retain their separate model pins. These are scoped MCP results, not a new full-surface Slack fidelity score. Released Harbor reset/isolation and a real-agent rollout remain separate qualification gates; packaging alone does not certify them.

Qualification addendum, 2026-09-21. The published 0.0.6 package now passes 13/13 shipped cases without a compiler in the offline Linux amd64 Harbor image. Two-episode isolation, three repeated resets, in-flight cancellation, native crash, gateway timeout and cleanup pass. The unchanged held-out task’s MCP reference earns 1.0; null, wrong-thread, duplicate-reply and forbidden-edit controls fail their intended checks. The support card and dated receipts  identify exact artifacts and limitations. One real held-out Opus rollout earns 1.0 with 17 MCP replies under the original grader. The source workflow ended red because its checker compared a short row ID with Harbor’s qualified name; the retained original trace passes the corrected exact-name check. Both receipts and source hashes are retained. No learning/generalization claim is made, and the release archives remain unchanged.

v0.0.3 — 2026-09-19

1. A third world, refund_desk_xl. ./slack-twin --scenario refund_desk_xl boots into the same #refund-desk (CRYSOPS0003) over a busier week: twelve users, 45 top-level messages and five threads across five days, and seventeen open requests naming fourteen objects in stripe-twin’s busy_account — the nine refund_desk names plus the paused v1 webhook endpoint, a completed and an expired checkout session, an unpaid cart and the production endpoint. The shapes an ops bot has to leave alone are all on the record: a status question already answered in its thread, the bot’s own earlier summary naming a charge, a refund word with no payment id behind it, the same customer asked about twice, and two objects in one message. refund_desk and ops_channel are unchanged, message for message, so a suite pinned to their ts values keeps passing. SCENARIOS.md lists the new world’s requests and what each resolves to on the Stripe twin.

v0.0.2 — 2026-09-18

1. Two named worlds, baked in. ./slack-twin --scenario refund_desk boots into #refund-desk: one workspace, nine users, and a channel where eight people have left 19 messages — chatter, Stripe status questions and five refund requests, every payment id a real record in stripe-twin’s busy_account world — with the refund handbook pinned and one request already answered in its thread. ops_channel is #ops: the same people, 14 messages of chatter and status questions and not one refund request, several of the questions answerable only from another twin. Your xoxb- token is the workspace’s ops bot (auth.test → UBOTOPS0001) and already a member, so conversations.history answers without a join. Slack has no seed API and a bot cannot post as somebody else, so a channel with a history other people wrote is exactly the state a bot token cannot reach on its own. --list-scenarios names them; RYSTIC_SCENARIO=<name> does the same in a container.

2. SCENARIOS.md. One page in the archive naming each world, its channel and cast, what every request points at on the Stripe twin, and how to re-pin the handbook with a different refund window.

3. conversations.history lists top-level messages only. Thread replies no longer appear in a channel’s history; they live under conversations.replies, as on Slack, with thread_broadcast replies the one exception. A bot’s own posts now carry the bot_id and app_id that auth.test reports for its token, and each user’s tz_label / tz_offset follow their tz.

v0.0.1 — 2026-09-17

The first release of the Slack twin — an early cut, shipped so integrations can start against it while fidelity work continues. Read the measurement paragraph below before relying on a method’s exact response shape.

1. A local Slack Web API for your bot’s integration tests. 67 methods in the bot dialect across 11 resources: conversations.* (create, join, invite, kick, leave, archive, rename, topic and purpose, history, replies, members, mark, open, close, info, list), chat.* (postMessage, update, delete, postEphemeral, meMessage, getPermalink, scheduled messages, and the startStream/appendStream/stopStream trio), users.*, reactions.*, pins.*, bookmarks.*, the external file upload pair with files.info/list/delete, views.open/publish/update, auth.test, api.test, team.info, team.profile.get, dnd.info and dnd.teamInfo. Point your Slack SDK’s base URL at the twin and your existing suite runs against it unchanged — form-encoded and JSON bodies both work, as they do live.

2. Slack’s error envelope, faithfully. Slack answers failures as HTTP 200 with {"ok": false, "error": "channel_not_found"}, so a client branches on the error string and never the status code. The twin does the same for every modelled method — a missing channel, a missing token (not_authed), a user-token-only method called with a bot token — so your error handling is exercised against the shape it will meet live.

3. It never reaches the network, and it needs no app. Any well-formed bot token (xoxb-…) is accepted and the twin dials nothing — which is the point: a suite that hits slack.com/api fails when a channel it created last week cannot be deleted (Slack has no channel delete), and one that posts to a shared test workspace fails when a colleague’s run posts first.

4. Seed the workspace your test needs. POST /_rystic/seed takes a register map — channels, memberships, messages, users, the team, reactions, pins, bookmarks, files, scheduled messages, views — and lands it directly. GET /_rystic/registers lists what this twin accepts a seed for; a register the model does not carry is refused with a status rather than silently dropped.

5. The same seed twice is the same workspace twice. POST /_rystic/reset empties the twin, POST /_rystic/seed-rng pins the generator so channel ids repeat run to run, and POST /_rystic/clock fixes the twin’s notion of now — which matters more here than elsewhere, because a message’s ts is both its id and its clock reading. Two identical seed flows leave byte-identical /_rystic/inspect dumps.

What is measured, and what is not. Fidelity is scored differentially against real slack.com/api on a throwaway workspace, per response field, not by eyeball: the last full-suite round was 161 of 221 probes on 2026-09-17. That is an early number and this release ships it as-is. The misses cluster where the model is known to be thin: response fields the Slack SDK samples list but a live response omits, cursor and ts values that are volatile by design, and the reads whose live evidence came from a newly seeded workspace. HOWTO.md lists the known shortfalls under Limitations. Rounds are re-run as the model is repaired and each release states its own number.

Not in this release. The Events API and Socket Mode, admin.* (Enterprise Grid), Slack Connect and shared channels, user tokens (xoxp-) and the methods only they can succeed at — users.profile.set, users.setPhoto, users.deletePhoto, users.identity — which answer their documented ok:false branch, as they do live under a bot token.

GitHub

v0.0.12 — 2026-10-12

1. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

2. bots/test_bot.py boots your installed Kalshi twin. With neither KALSHI_BASE_URL nor KALSHI_TWIN_BIN set, it runs the kalshi-twin version rystic pull kalshi-twin installed, with the API key or license check.sh would find, instead of trying to build the twin from source. When that twin fails to start, the test prints its log.

3. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

4. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

5. github-pulls_open_queue plays a timeline. Over the hour after the pinned clock, tb-reviewer-login approves #41, tb-contributor thanks the reviewer on it, tb-maintainer requests changes on #42, retitles the draft #43 and squash-merges #41 into tb-base-branch, each through the REST API under a token the world binds to that login; advance the clock to watch the queue move. (RYS-2459)

6. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

7. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

8. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

9. A read-only collaborator cannot remove review requests. DELETE /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers refuses a caller who can only read the repository with 403 Must have write access to repository., as requesting reviewers already did. (RYS-2133)

10. Refusals and issue search answer as GitHub does. A self-approval answers errors ["Review Can not approve your own pull request"], a review comment on a path outside the diff ["Path could not be resolved"], an invalid event on review create Unprocessable Entity and on submit Validation Failed with GitHub’s errors — each measured against GitHub. Issue search applies reason:completed, reason:"not planned" and owner:, which it used to read as text. A search qualifier the twin does not evaluate still answers 501, now in GitHub’s error envelope with a message. (RYS-2134)

11. GET /user/codespaces lists your codespaces. It answers {total_count, codespaces} with every codespace the caller created from a pull request, newest first, paged by per_page and page and narrowed by repository_id; without a credential it answers 401 Requires authentication. (RYS-2135)

12. Other search types are refused, and what is out of scope is listed. GraphQL search with a type other than ISSUE or ISSUE_ADVANCED is refused with an error naming g_search_type_served, where it used to answer issues. Code browsing, code and commit search and issue subscriptions are recorded as out of scope under Limitations. (RYS-2136)

v0.0.11 — 2026-10-10

1. Seeded worlds read like GitHub’s own records. Every URL a seeded user, organization, membership, repository, commit, file, review, team or check run carries sits on GitHub’s hosts — the API ones rewritten to the twin’s origin, as created records already were — so a client that completes a record lazily (PyGithub’s pull.user.name) comes back to the twin instead of failing on example.invalid. A pull request’s head.repo and base.repo are the whole repository object (fork, clone_url, ssh_url, pushed_at and the rest), its user and every owner the whole simple-user, and comments and review_comments count exactly the rows the comment routes list. The imported github-pulls_garrytan_gbrain world keeps its example.invalid URLs. (RYS-1248)

2. A body that is not JSON is refused, not applied as an empty edit. PATCH /repos/{owner}/{repo}/issues/{issue_number} and PATCH /repos/{owner}/{repo}/pulls/{pull_number} answer bytes their JSON decoder rejects with GitHub’s 400 {"message":"Problems parsing JSON"} before looking anything up, and write nothing — both used to answer 200 and bump updated_at. A truncated object is not that case: GitHub reads a body missing its closing brace as the object and a dangling value as a value its schema check refuses, and the sealed probe sends what no JSON grammar accepts. A PATCH on a seeded pull request answers the projection GET renders, with all eight _links and its derived merge_commit_sha, not the record as seeded. (RYS-1251)

3. A pull request serves its diff and patch. GET /repos/{owner}/{repo}/pulls/{pull_number} with Accept: application/vnd.github.diff (or .v3.diff) answers the unified diff as text under Content-Type: application/vnd.github.diff; charset=utf-8, .patch the format-patch mbox of its commits, and application/vnd.github.full+json the JSON body with body_html and body_text — including calls made by Octokit’s pulls.get({mediaType:{format:"diff"}}). (RYS-1247)

4. The Limitations say what the twin serves. The docs page and the HOWTO state where a seeded URL leads (to the twin, where GET /users/{login} and every other route outside its coverage answers 404), the headers it sends unlike GitHub (no ETag or 304, no X-GitHub-Request-Id, X-RateLimit-* only on GET /rate_limit, no charset on JSON), the past-the-last-page Link, the list query values and the requested-reviewers readback no round has measured, the truncated JSON bodies GitHub reads leniently, the Date: of a commit made through the API, and what body_html renders from. (RYS-1246)

5. The diff and patch representations read as GitHub writes them. GET /repos/{owner}/{repo}/pulls/{pull_number} under Accept: application/vnd.github.diff names each index line’s blobs by their first seven characters, and under .patch numbers a lone commit [PATCH], carries the create mode line in the stat block and ends after the diff with no version trailer — measured byte for byte against the real service — so a tool that parses GitHub’s format-patch output parses the twin’s. The one remaining difference is the Date: header of a commit created through the API: the twin stamps it in UTC, GitHub in the committing account’s time zone. (RYS-1247)

6. A seeded draft pull request is mergeable. In github-pulls_open_queue, the draft #43 answers mergeable: true, mergeable_state: "clean" — the settled values GitHub computes for a draft, measured against the real service on a full-suite round — where it answered mergeable: null, mergeable_state: "unknown" on every read, so a merge bot that polls until mergeable resolves now stops. A draft opened through the API already answered the settled values. (RYS-1252)

7. The pull-request list falls back to GitHub’s defaults. page=0, per_page=0, a non-numeric page and an unknown state or sort on GET /repos/{owner}/{repo}/pulls answer 200 with the defaults, as GitHub does, where the twin answered 422 Validation Failed; and a head value without user: or organization: is ignored rather than matched against the branch name, so head=<ref> lists every open pull request as it does on GitHub. Each value is a sealed probe confirmed against the real service. An unknown state on the issues list stays 422, which is what GitHub answers there. (RYS-1249)

8. A review comment’s review exists. A top-level comment through POST /repos/{owner}/{repo}/pulls/{pull_number}/comments creates the COMMENTED review its pull_request_review_id names, so GET …/pulls/{pull_number}/reviews/{review_id} answers that review and the reviews list includes it, as GitHub does. (RYS-1250)

9. A submitted review clears its author from the review request. Once a requested reviewer submits a review through POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews, GET …/pulls/{pull_number}/requested_reviewers and the pull request’s requested_reviewers no longer list them, as GitHub documents, so gh pr view drops their “(Requested)” mark and a bot waiting on the request sees it clear. A pending review leaves the request standing until it is submitted. (RYS-1250)

10. What a pull request’s conversation page reads now answers. GET .../issues/{n}/events and GET .../issues/{n}/timeline list a pull request’s or issue’s events and its derived timeline (comments, reviews, review comments, commits); Accept: application/vnd.github.html+json, .text+json and .full+json answer body_html and body_text; GET /repos/{owner}/{repo} answers permissions for the caller; and every avatar_url leads to an image the twin serves itself. github-pulls_garrytan_gbrain now carries every pull request’s conversation comments and issue events, and its collaborators are the logins GitHub marks as holding push, so other users read. (RYS-1827)

11. Organization access is consistent. Membership and repository routes match the caller’s login and membership state without case sensitivity, ignore memberships without a user, and keep organization affiliation when the caller is also a collaborator. Organization admins receive admin permissions on their repositories; billing managers and pending invitations grant no repository access. /user/orgs, /user/memberships/orgs, and /user/repos error responses include status. (RYS-1717)

12. Answers carry what GitHub’s response schemas fix. Where a handler leaves a field absent or null, the twin answers with the required constant, the required field’s documented default, or the variant tag that GitHub’s response schema fixes for that route and status, error envelopes included; a value the handler wrote is never replaced. (RYS-1905)

13. A body’s media type renders the same under its v3 spelling. Accept: application/vnd.github.v3.full+json, .v3.html+json, .v3.text+json and .v3.raw+json answer an issue’s, pull request’s, comment’s or review’s body exactly as the unversioned media types do: body_html and body_text are one GitHub-flavored Markdown rendering of body, so a client that names the API version in its media type gets the rendered fields. (RYS-1247)

14. Page links name the page size you asked for. On the page-numbered reads (GET /search/issues, GET /user/repos, GET /user/orgs, GET /user/memberships/orgs, and an issue’s events and timeline), each Link target carries the per_page the request sent, as GitHub does, even above the 100 items a page holds. A per_page that is not a positive integer names the size served. (RYS-1253)

15. Pull request mutations answer the pull request’s reviews. mergePullRequest, convertPullRequestToDraft, markPullRequestReadyForReview and createPullRequest answer reviews, latestReviews, latestOpinionatedReviews and reviewDecision from the reviews submitted on the pull request, as repository.pullRequest does, instead of always empty. (RYS-1304)

16. X-GitHub-Api-Version is checked on every route, as GitHub does. 2022-11-28 (the default when the header is absent) and 2026-03-10 are accepted; any other value answers 400 with GitHub’s error body before the operation runs. (RYS-1914)

17. A read answers If-None-Match with 304. A GET carries a weak ETag where GitHub’s does; send it back in If-None-Match and an unchanged read answers 304 Not Modified with no body, so a client’s cache revalidates against the twin as it does against GitHub. GET /search/issues and GET /rate_limit carry no ETag, as on GitHub, so a conditional request there reads the answer again. If-Modified-Since is not answered. (RYS-1253)

18. Web URLs lead back to the twin. html_url, _links.html, clone_url and every other URL on github.com or one of its subdomains (docs.github.com, codeload.github.com) now names the twin’s origin, as api.github.com URLs already did; RYSTIC_PRESERVE_SERVICE_URLS=1 keeps GitHub’s hosts. Through rystic run --intercept, github.com and its subdomains route to the twin. (RYS-1910)

19. Past the last page, Link points back at it. On the page-numbered reads (GET /search/issues, GET /user/repos, GET /user/orgs, GET /user/memberships/orgs, and an issue’s events and timeline), a page past the end names the last page as both prev and last, and page 1 as first, as GitHub does. (RYS-1249)

20. Repositories and commit authors read as GitHub embeds them. GET /user/repos lists each repository as GitHub’s full repository object with the caller’s permissions; a pull request’s base.repo and head.repo, on its reads and on PATCH …/pulls/{pull_number}, carry neither permissions nor collaborators; and GET …/pulls/{pull_number}/commits names each commit’s author and committer by GitHub’s 19-field user. (RYS-1248)

21. A pull request’s 404 carries only GitHub’s keys. A 404 on a pull request, or on its commits, files, comments, reviews, review comments, reactions or check-run annotations, answers exactly message, documentation_url and status, as GitHub does, without the url the twin added. GET …/issues/{issue_number}/events answers its 404 with the same three keys. (RYS-1253)

22. GET /user and GET /rate_limit answer what GitHub does. The authenticated caller reads its private-user view, with plan, disk_usage, collaborators, the private repository and gist counts, two_factor_authentication and notification_email, and GET /rate_limit lists every resource category GitHub answers, audit_log, audit_log_streaming and enterprise_token_inventory included. (RYS-1905)

23. The Limitations name the codespace timestamps. The docs page and the HOWTO say that a codespace’s created_at, updated_at and last_used_at are written in UTC, where GitHub writes them at the account’s UTC offset, so a client compares them as times rather than strings. (RYS-1253)

24. A path ending in a slash answers 404, as on GitHub. GET /repos/{owner}/{repo}/pulls/, or any route with a trailing slash, answers GitHub’s 404 Not Found (message, documentation_url and status) where the twin served the route without the slash; drop the slash to reach it. (RYS-1253)

25. GET /repos/{owner}/{repo} answers GitHub’s full repository object. The repository read carries all 96 of its fields, the merge-commit settings and the *_url templates among them, and names its owner by GitHub’s 19-field user. Its URLs on GitHub’s hosts lead back to the twin, except git_url and ssh_url, which keep GitHub’s git:// and SSH addresses. (RYS-1253)

26. A push runs the repository’s CI checks. A push, and a pull request that opens, moves or reopens, now starts the repository’s own .github/workflows: one check run per job as github-actions, named as GitHub names it, completed from the twin’s evaluation engine — a verdict the world already recorded for the same tree replays, a surrogate you register (POST /_rystic/eval/evaluators, run by rystic evaluator) evaluates, and anything else shows neutral. A push also renders GitHub’s push event into GET /_rystic/egress. (RYS-2061)

27. CI evidence stays tied to the current submission. Agent-created check runs and results from older submissions no longer count as trusted RL reward evidence; rerequests retain their prerequisites, workflow conditions retain their context, and executable files keep their permissions. Evaluation documents now require schema version 2 and a task scope; import reference history before starting an episode, and pin command evaluators to a container image digest and platform. Local execution requires explicit trusted opt-in, while calibration requirements can specify sample counts, coverage and applicability.

v0.0.10 — 2026-10-05

1. Search applies the rest of GitHub’s grammar, and refuses what it cannot evaluate. GET /search/issues and gh pr list --search now apply negation (-author:, -label:, -is:draft), repeated qualifiers as GitHub combines them, the advanced AND / OR / parentheses syntax gh sends, free text with in:title|body|comments, head:, base:, comments:, no:label, review:, involves:, mentions:, commenter: and in-query sort:, each measured against api.github.com; an unknown login or repository answers GitHub’s 422 over REST and matches nothing over GraphQL. A qualifier the twin cannot evaluate answers 501 with an X-Rystic-Marker instead of quietly broadening the result, REST search pages with GitHub’s Link header, so a client that follows it gets every page, and a pull request found by search or read through the Issues routes carries draft and its own node_id. (RYS-1620)

2. A codespace’s environment_id comes from its own range. The first codespace you create gets 81cebaf1-e762-4d0c-8000-000000000001 rather than 00000001-0000-4000-8001-000000000001. Ids still count up in their last digits and restart on reset; a test that pinned an old id needs the new one. (RYS-1593)

3. Seeded teams report type: "organization". The teams github-pulls_org_teams seeds, which GET /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers returns, carried type: "Team", a value GitHub never sends. They now carry "organization", GitHub’s ownership type for an organization’s team and the one the twin gives a team it was not seeded with, so a client typed on that field’s enum accepts them. (RYS-1600)

4. The authenticated user’s repositories and organizations answer. GET /user/repos lists the repositories the caller owns or collaborates on, with GitHub’s visibility, affiliation, type, sort, direction, since, before and paging parameters, and GET /user/orgs lists the caller’s organizations. Both answer 401 without a credential, as GitHub does, so gh api user/repos and gh api user/orgs no longer 404. (RYS-1654)

5. Organizations have members. GET /user/orgs lists the organizations the caller holds an active membership in, GET /user/memberships/orgs answers those memberships with their role and state, and GET /user/repos?affiliation=organization_member reads the same membership. github-pulls_org_teams seeds the organization its teams belong to, tb-org, with tb-owner, tb-reviewer-login and tb-maintainer as members, and its teams’ URLs name it; every other world seeds none, so those lists stay empty there. (RYS-1664)

v0.0.9 — 2026-10-01

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. The repository, the rate limit, the API root and the authenticated user answer. GET /repos/{owner}/{repo}, GET /rate_limit, GET / and GET /user are served as GitHub serves them, so an agent’s first probes no longer 404 and gh auth status reports a login instead of an invalid token. The rate limit reports a full budget that resets at the next hour of the twin’s clock, and URL templates in responses keep their braces, as GitHub writes them. (RYS-1530)

3. gh pr list and gh issue list run with their filter flags. With --author, --assignee, --label, --draft or --search, gh first asks for SearchType’s values, and the twin answered Field 'enumValues' doesn't exist on type '__Type'. It now answers with GitHub’s values, so the list runs through the twin’s search. HOWTO.md lists the qualifiers that search applies. (RYS-1532)

4. Issue search over REST, and both searches apply date qualifiers. GET /search/issues answers the world’s issues and pull requests with total_count, paging and sort. It and the GraphQL search that gh pr list --search sends now apply created:, updated:, closed: and merged: ranges, draft: and is:unmerged, so counting pull requests in a date window matches the world instead of ignoring the range. (RYS-1531)

v0.0.8 — 2026-09-30

1. The state UI shows the repository as GitHub. On Pro and Enterprise, /_rystic/ui opens GitHub-style Pull requests and Issues pages for the twin — a pull request’s conversation and merge box, commits, checks and diff with review threads and check annotations — where you can act as any seeded user: comment, review, comment on a line, react, request reviewers, merge, close, lock and set a check run’s status through the twin’s own API, beside Actors & calls and Webhook events cards. (RYS-1331)

2. Unmodified clients reach the twin at GitHub’s hostnames. rystic run github-pulls-twin --intercept boots the twin behind the rystic CLI’s HTTPS gateway, and rystic exec -- <command> routes that command’s calls to api.github.com and github.com to it: gh, git clone https://github.com/..., curl and SDKs with their default base URL, when their transport honors the proxy and CA settings. (RYS-1398)

3. Free boots the imported garrytan/gbrain repository. --scenario github-pulls_garrytan_gbrain (or RYSTIC_SCENARIO) now boots it on Free, and POST /_rystic/reset puts back whichever world the twin booted — issues, comments, pull requests, reviews, check runs, pushed branches and git objects included, with the next issue and pull request numbers where the boot left them. (RYS-1393)

v0.0.7 — 2026-09-26

1. HOWTO.md and check.sh start from an API key. HOWTO.md leads with rystic login rys_…, says which worlds and control-plane routes Free, Pro and Enterprise reach, and corrects the auth rules: Codespaces need a Bearer or token header, and a login the world does not seed is refused authored writes, merges, dismissals and review requests but not a PATCH, a check run or a reaction. SCENARIOS.md marks github-pulls_open_queue as the one Free world and keys a pull request file <number>#<path>, and both give the id bands new records get. check.sh runs the Free and Pro build on your API key (RYSTIC_TOKEN, or the key rystic login stored) as well as the Enterprise build on its license file, looked up in the CLI’s order. (RYS-1204)

v0.0.6 — 2026-09-25

1. More complete pull-request responses and token authentication. Pull-request and review responses include missing user and repository fields. GraphQL pull-request creation errors retain the nullable payload alongside errors, and merge and review-dismissal refusals match observed response envelopes. Codespaces can be deleted by name. Clients can authenticate with either GitHub’s Bearer or token authorization label. (RYS-1068)

2. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

v0.0.5 — 2026-09-24

1. gh repo clone works with gh 2.101.0 and later. That release’s clone query selects Repository.sshUrl on the repository and its parent and stops at the schema when the field is missing, so against 0.0.4 the clone failed before it started. The twin now answers sshUrl as GitHub spells it, git@<host>:<owner>/<repo>.git, on every repository.

v0.0.4 — 2026-09-23

1. A request GitHub’s schema refuses gets GitHub’s answer. In 0.0.3, eight routes answered a required field left out, a value of the wrong type, or one outside its enum with 422 {"message": "Validation Failed", "errors": [...]}. GitHub refuses those before the resource sees them, with 422 {"message": "Invalid request.\n\n<lines>"} and no errors key: "title" wasn't supplied., For 'properties/body', 5 is not a string., For 'properties/side', "UP" is not a member of ["LEFT", "RIGHT"]. The twin now answers the same way when you create or edit an issue, create or edit an issue comment, lock an issue, open a pull request, create a review comment, or react to one. Validation Failed with errors[] stays where GitHub sends it, for a value the schema admits and the resource refuses: a blank title, an unknown branch, a duplicate. Editing an issue with an unknown state_reason answers GitHub’s own 422 {"message": "Please specify a valid state reason."}.

v0.0.3 — 2026-09-22

1. Every world is a real git repository. Each scenario’s repository is served at /{owner}/{repo}.git/ on the twin’s port: git clone http://localhost:8080/tb-owner/tb-repo.git and git fetch origin refs/pull/{n}/head walk git’s dumb HTTP protocol, git push speaks the smart one, and every sha the API reports is a commit you can check out. Pushing to an open pull request’s head branch moves the pull request — head sha, commits, files, a synchronize notification — exactly as GitHub does; pushing to a protected branch is refused. A pull request’s files[].patch and its commits’ diffs now come from the same commits, so the two never disagree.

2. The gh CLI works against the twin. POST /graphql answers the queries and mutations the gh porcelain sends, so gh pr list, gh pr view, gh pr checkout, gh pr checks, gh pr comment, gh pr review, gh pr merge, gh repo clone, gh issue create, gh issue list and gh issue comment run unchanged, and every mutation writes through the same handler its REST route uses, so what gh did shows on the REST surface. Point it at the twin with environment alone — gh speaks plain HTTP to github.localhost and honours a proxy, and git honours the lowercase spelling:

   export GH_HOST=github.localhost GH_TOKEN=ghp_anything \
          HTTP_PROXY=http://localhost:8080 http_proxy=http://localhost:8080
   gh pr list -R tb-owner/tb-repo
   

   The GraphQL surface is the subset gh speaks, not GitHub’s schema; a field outside it answers GitHub’s undefinedField error. gh issue view --comments lists the comments the store holds.

3. The API’s writes land in the repository you clone. Creating a pull request, retargeting its base, merging it and updating its branch all move the served git repository now, so a git fetch after any of them finds what the API described: a merge is a commit on origin/<base> carrying the head’s changes — with merge_method merge the base and the head are its two parents, while squash and rebase land single-parent commits — and a pull request opened on a branch you pushed carries that branch’s commits and files. gh pr merge followed by git pull behaves as it does against GitHub. Fetching still changes nothing — refs/pull/{n}/merge is derived when a client asks for it and never written — so a clone leaves the world exactly as it found it.

4. Issues and their comments over REST. /repos/{owner}/{repo}/issues lists and creates them, /issues/{n} gets and updates one — state closes and reopens it, with a state_reason — and /issues/{n}/lock locks and unlocks its conversation. Comments are /issues/{n}/comments to list and create, /issues/comments for a whole repository’s, and /issues/comments/{id} to get, edit or delete one. Pull requests are issues here as they are on GitHub: they come back in the list and by number, each carrying a pull_request key, and /issues/{n}/comments is where a pull request’s conversation comments live — the route gh pr comment writes to, distinct from the diff-anchored review comments. Issues and pull requests draw their numbers from one sequence per repository, and a repository with issues disabled answers 410 on the issue routes; pull-request numbers and their comments are unaffected. The eighth world, github-pulls_issue_tracker, seeds five issues and a commented pull request around that shared sequence.

5. A real repository to review: github-pulls_garrytan_gbrain. The first imported world — the 300 most recently updated pull requests of garrytan/gbrain as GitHub served them (121 open, 15 merged), their 5,693 changed files with GitHub’s own diffs, 6,266 check runs, 140 real users, and the repository itself as a packfile: git clone http://localhost:8080/garrytan/gbrain.git downloads one 85 MB pack in about two seconds, git fetch origin refs/pull/N/head reaches any imported pull request, and gh pr checkout lands on the API’s head sha. Ids, logins and shas are GitHub’s. import_repo.py --git --gzip is how another repository becomes a world.

6. Who may write is one rule, answered as GitHub answers it. A caller’s standing on a repository — the owner is admin, a collaborator holds its declared permission, everyone else the world knows holds read, a login the world does not seed has none — is consulted by every guarded write. Merging, dismissing a review and requesting reviewers refuse a credential naming nobody with 401 Bad credentials and a caller without write access with 403, where before they accepted both; the writes that record an author no longer create issues, pulls, reviews or comments with user: null. Standing is asked of the resolved user, never the X-Rystic-Actor label, so a review can no longer be requested from the pull request’s own author. Every world seeds all four documented logins, and tb-contributor is a user without write access, as the name says. From the same review round: an issue’s and a pull request’s ids are one rule, and created rows mint into their own bands; error bodies are GitHub’s three families, and an unknown path answers in the service’s voice; a pull request’s mergeability, its reviews and its check runs report what the world actually holds.

v0.0.2 — 2026-09-18

1. Two worlds whose diffs carry a real program. github-pulls_bot_pr_broken seeds a merged pull request (#7) whose single file is a working Kalshi market-maker bot — files[].patch is the whole ~150-line Python file — and an open pull request (#8) that changes one line so the buy and sell legs swap sides, with a red bot-smoke check run whose failure annotation points at that line. github-pulls_bot_pr_queue opens five such pull requests (#11–#15), one bug each: swapped sides, a syntax error, the wrong orders path, prices in cents, a required order field dropped. The twin has no contents API, so this is how code comes out of it: read the base, apply the change, run the result. Seven worlds now; --list-scenarios names them.

2. The bot ships as plain files too. bots/bot.py, the five bots/variants/*.py and bots/test_bot.py ride the archive beside the binary, and rystic features github-pulls-twin describes them under reference bot. The test runs the bot for 30 s against a kalshi-twin in its tight_book world and requires a bid and an ask resting at once, no crossed quote and nothing left resting; every variant is held to failing that.

3. SCENARIOS.md. One page naming every baked-in world and what it is for, with ids, the cast and the bot-world recipe — the cheat sheet the Kalshi and Stripe twins already carried.

4. Writes on a seeded pull request now land. In 0.0.1 every baked-in world keyed its pull requests and branches by bare number and name while the handlers look them up as <owner>/<repo>#<number> and <owner>/<repo>#<name>, so a GET on a seeded pull request resolved but PATCH, merge, review dismiss, reply and reviewer requests on it answered 404. The worlds are re-keyed the way the handlers read them, and GET /_rystic/registers states the key grammar. One consequence that matches GitHub: opening a second pull request on a head that already has an open one is 422; a head whose pull request is closed takes a new one.

v0.0.1 — 2026-09-17

The first release of the GitHub Pulls twin.

1. A local GitHub pull-request surface for your review automation. 37 routes across 13 resources under /repos/{owner}/{repo}: pull requests (list, create, get, update, files, commits, merge, update-branch), reviews and their submit and dismiss events, review comments with replies and reactions, requested reviewers, check runs with annotations and re-requests, and codespaces. Point your GitHub client’s base URL at the twin — PyGithub, octokit and gh all take one — and your existing suite runs against it unchanged. Nothing you send it counts against a rate limit, lands in a real repository, or needs a token.

2. Five worlds baked in. --list-scenarios names them: an open queue of four pull requests, a finished review thread with reactions, a head sha with four check runs standing, a merged-and-closed backlog, and org teams requested for review. --scenario <name> boots straight into one, so a test starts from the review state it needs with no seeding step.

3. Review as one user, approve as another. GitHub’s review rules depend on who is calling — an author cannot approve their own pull request, only a user with write access can dismiss a review. The twin reads the caller from the X-Rystic-Actor header and applies the seeded permissions, so the permission branches of your integration are testable without a second real account.

4. It never reaches the network, and it needs no token. Any Authorization header is accepted, and the twin dials nothing — which is the point: a suite that hits api.github.com fails when the hourly limit is spent, and one that creates throwaway repositories leaves them behind.

5. Seed the world your test needs. POST /_rystic/seed takes a register map — repositories, branches, commits, users, teams, pull requests, reviews, comments, reactions, check runs — and lands it directly. GET /_rystic/registers lists what this twin accepts a seed for; a register the model does not carry is refused with a status rather than silently dropped.

6. The same seed twice is the same world twice. POST /_rystic/reset empties the twin, POST /_rystic/seed-rng pins the generator so ids, node_ids and merge shas repeat run to run, and POST /_rystic/clock fixes the twin’s notion of now so created_at and updated_at are values your test chose. Two identical seed flows leave byte-identical /_rystic/inspect dumps.

What is measured, and what is not. Fidelity is scored differentially against real api.github.com on a per-run throwaway repository, per response field, not by eyeball: the last full-suite round was 136 of 138 probes on 2026-09-06, and the suite has since grown to 140 probes. Known shortfalls are listed in HOWTO.md under Limitations — there is no git behind the records, so diffs and file lists are seeded facts and merging does not rewrite branch history; no webhooks are delivered. Rounds are re-run daily and each release states its own number.

Not in this release. Issues, issue comments, labels as a resource, commit statuses, branch protection and repository or organization administration are not modelled.

Kalshi

v0.0.40 — 2026-10-12

1. Scheduled calls reach the Trade API, and a world can carry its own timeline. A call event in POST /_rystic/inject or --inject may name a Trade API route and act as the actor its as names, through the same handlers and WebSocket frames as your orders, and an event’s at may be +<duration>. A --seed file, or a whole one posted to POST /_rystic/seed, may carry its own credentials and events, and a top-level key of either name the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock in real time. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

4. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. A live feed batch that passes an event stops for it, so it fires between the frames either side. (RYS-2542)

5. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

6. GET /account/limits shows the advanced API usage level once you upgrade. After POST /account/api_usage_level/upgrade, the limits read answers usage_tier: "advanced", Kalshi’s advanced read and write buckets, and the advanced grant in grants, as Kalshi does. A client can now confirm its upgrade through the public API. (RYS-2249)

7. A triggered order group refuses new orders until it is reset. After PUT /portfolio/order_groups/{id}/trigger, an order naming that group in order_group_id is refused and does not rest, as Kalshi documents; PUT /portfolio/order_groups/{id}/reset admits orders again. A bot that relied on the twin accepting orders into a triggered group now sees the refusal. (RYS-2248)

v0.0.39 — 2026-10-11

1. The verified UI installs and starts with rystic ui kalshi. Kalshi Accurate, the client built against Kalshi’s own interface, is a Pro and Enterprise deliverable: it ships as the image registry.rystic.ai/kalshi-twin-ui:<ver> beside the twin’s, pulled with the same docker login, and rystic ui runs it against a running instance (or, without Docker, the UI’s archive with its public market snapshot on your Node 22.12+). A key whose plan lacks the verified_ui entitlement is refused with feature_not_in_plan. (RYS-2403)

2. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.38 — 2026-10-11

1. Kalshi is on Pro and Enterprise. A Free API key is refused product_not_in_plan for rystic pull kalshi-twin and a start. On Pro and Enterprise every world, control route and the verified Kalshi UI are open, and without --scenario the twin boots empty. (RYS-2400)

v0.0.37 — 2026-10-09

1. The live feeder separates the exchange’s delay from its own. The feeder’s [status] line now reports upstream_lag_ms (receive time minus the exchange stamp), the queue depth, how long the simulator takes per batch, reconnects, and every exchange error by code. The feeder also keeps reading the socket while it subscribes, so a reconnect no longer leaves the exchange buffering for it. A frame the exchange skipped resubscribes its socket for fresh snapshots instead of leaving the book behind. Needs a CLI and simulator from this release. (RYS-1782)

2. Replay keeps pace with the feed under order load. Placing, cancelling and listing orders no longer slows down as a session’s order history grows, and a replayed frame costs the same however many orders and positions are open in other markets. A large /_replay/feed batch no longer holds order requests until it finishes: they run between chunks of at most 1,000 frames. (RYS-1805)

3. The live feeder names a series or market listed as an event, and a carry it ignores. A series (KXBTCD) or an open market ticker in --live-events or RYSTIC_LIVE_EVENTS_FILE is now named in the feeder log with the flag that carries it, instead of being reported as an event not yet open. Setting --live-carry beside named markets or events logs that the carry is ignored. (RYS-1937)

4. A subaccount transfer is refused when its amount is not positive or exceeds the source balance. POST /portfolio/subaccounts/transfer answers 400 transfer_amount_must_be_positive for a negative amount and 400 insufficient_balance for more than from_subaccount holds, as Kalshi does; neither moves a balance. A bot that relied on the twin accepting those transfers now sees Kalshi’s refusal. (RYS-60)

5. Replay keeps pace with more markets per twin. The terminal event feed no longer wakes for every replayed market-data frame it does not print, so one twin applies up to a fifth more replayed events per second before it falls behind the recording. With the default event scope, a burst of market data can no longer push one of your fills out of the terminal feed. (RYS-2111)

6. Orders no longer wait behind replay catch-up. When playback or the live feed falls behind, an order request that arrives while events are applying runs after the event in flight, not after the whole batch: a cancel waited about 100 ms on average while replay caught up, and now waits about 4 ms. A pause or seek still takes effect between batches. The action log now stamps each request line with received, when the request arrived, and writes a fill line for each of your fills with its order_id, trade_id and the recorded time it happened. (RYS-2086)

7. Replay no longer scans the whole book per event to track your orders. Each replayed event checks only the orders you have resting, not every level of the book, so one twin applies about a fifth more replayed events per second on the busiest BTC market before it falls behind the recording. (RYS-2137)

8. An open state UI no longer slows replay. /_rystic/events sends what queued in one write at most every 5 ms instead of waking for every event, so with /_rystic/ui open a busy replay applies about 17% more events per second. Each event keeps its own frame and id, and resuming with Last-Event-ID or ?cursor= works as before. (RYS-2140)

9. Replayed trades no longer copy the whole book. A replayed trade renders its book changes from the levels it reached, so one twin applies about 40% more replayed events per second on the busiest BTC market before it falls behind the recording. WebSocket frames are byte-for-byte unchanged. (RYS-2138)

10. Replay refreshes market records once per step, not per event. A market’s record is rebuilt after its first event in a step, after each trade, and at step end, so one twin applies about 14% more replayed events per second on the busiest BTC market before it falls behind the recording. A market read between steps, and every WebSocket frame, is unchanged. (RYS-2139)

11. A pause or seek no longer waits out replay catch-up. When playback falls behind and catches up, a pause or seek takes effect at the end of the batch applying when it arrived; before, it could wait until the whole backlog had applied. (RYS-2163)

v0.0.36 — 2026-10-03

1. Query parsing errors match the demo on sixteen GET routes. Declared query fields return the measured flat 400 message for malformed integers and booleans, empty values, integer overflow, and duplicate values, preserving which field fails first. Coverage is limited to the documented field prefixes; application range checks and the positions endpoint’s separate integer narrowing remain known gaps.

2. Clearer market details and Economics browsing. The standalone coded frontend shows holdings with fee-inclusive average prices in outcome rows, uses series-based market URLs and labels, and adds fixed-scale charts with line/bar views. Economics gains subcategory filters and a featured-event pager, while the shared header shows open-event counts and compact balances with consistent page margins. (RYS-1695, RYS-1696, RYS-1697, RYS-1702)

3. Keyboard controls and shared trading state in the coded frontend. Use arrow keys across trading controls, inspect seeded YES and NO order intent, and keep UI interaction logs after closing the page. The coded frontend defaults to the recorded frontend’s ui-trader account; set RYSTIC_ACTOR to use another account. (RYS-1642)

4. A set of cut games can be stitched into one tape offline. tapecut stitch -dst <set> <cut>… writes the games already back to back on one session clock, with the replay sequence’s own rule, as one cut archive per game plus a session.json whose replay_start body plays them with every offset at 0. The set reads as one continuous tape without the twin. examples/kalshi-sidefeed builds its play-by-play feed: each line runs a lead ahead of the book’s reaction on the tape, either one value or drawn per line from a seeded range (the MLB sets draw from 100 ms behind to 1 s ahead), and the plain feed is one {ts_ms, event} line per play. (RYS-1708, RYS-1711)

5. Private account settings stay out of recorded UI fixtures. The original-frontend HAR importer and fixture loader replace captured API tiers, grants and limits with fixed synthetic display values, including when loading older fixtures. Unknown fields in those account responses are discarded. (RYS-1622)

6. MLB set builds refuse linked output directories. The set/game driver rejects symlinks at selected output paths, including dangling links, and stops if old output cannot be removed. Partial builds preserve sibling sets instead of writing through a link. (RYS-1708)

v0.0.35 — 2026-10-02

1. Replay stops at an exact tape time. POST /_replay/start takes checkpoints and POST /_replay/play takes until_ms, both in absolute tape milliseconds (the axis of status.start_ms). Playback applies every event through the stop, pauses there, and status.at_checkpoint_ms reports the stop, so the same actions at the same stops give the same fills and balances after a reset. (RYS-1628)

2. A windowed capture archive replays its whole window, quiet markets included. An archive cut to a [from, to) window carries a manifest.json that declares the window, an opening book per market and a SHA-256 per file, and holds no frame at or after to. Replaying it, alone or as a group, covers the declared window even when a market has no event near either end, so one quiet outcome no longer ends a grouped replay early. (RYS-1627)

3. A replayed window’s trade history and candlesticks follow the tape. Every recorded print is stamped at its own tape time, even when an accelerated replay applies many events in one batch, so GET /markets/trades and the candlestick reads bucket it into the minute it traded. Restarting a replay, or jumping the play head back, removes the recorded prints the head has not reached yet; your own fills stay. (RYS-1626)

4. Replay can use a zero-fee series seed. Before starting playback, seed the market’s series in state_series with its ticker, fee_type: "quadratic" and fee_multiplier: 0. Crossing fills and resting orders filled by recorded prints then charge zero fees; cash changes only by quantity times price. Event fee overrides and series fee changes still take precedence over that series setting. (RYS-1629)

5. Replay steps by a fixed amount of tape or to the next scheduled event. POST /_replay/play takes advance_ms to play that many tape milliseconds from the head and pause, or until: "next_event" to play to the next injected event and pause right after it. Every injected event inside the step fires at its own time first, and status.next_event_ms shows the next stop, so a harness can drive a session one step at a time with identical results on every run. (RYS-1669)

6. Independent local Kalshi interface for source checkouts. Run the standalone Kalshi Accurate app against a local twin: browse markets, open price history and the order book, buy and sell with an inline review, and manage positions, resting orders, amendments, cancellations and fill history as the member account. It reaches only the Trade API routes it uses; the existing state UI remains separate. (RYS-1632)

7. A market can settle on schedule. A scripted-event schedule now takes a call event that runs one of the twin’s own routes, such as POST /_settle, at its sim time, so a replayed game’s markets close and pay the real winner at the final out with no admin request. A windowed archive’s manifest.json records each market’s outcome, read from its market records, while its meta/ stays free of it, so nothing the agent reads shows the winner early. (RYS-1667)

8. Liquidity you take during replay stays taken. When your order lifts a replayed level, the next recorded update at that price no longer puts the contracts back: the level shows the recorded size minus what you took, and recorded decreases there pay that down until the book is back on the recording. The same holds for reconnect snapshots and for live-fed markets, and a restart, seek or reset starts clean. (RYS-1660)

9. The control plane can be locked away from an agent, and every action logged to disk. With RYSTIC_ADMIN_TOKEN set, /_rystic/*, /_replay/* and /_settle need that value in X-Rystic-Admin-Token (or the rystic_admin_token cookie). GET /_rystic/version stays open as the readiness probe, and so does GET /_feed. RYSTIC_ACTION_LOG=<path> appends one JSON line per state-changing request and control op, with the sim clock and the replay head on each line. (RYS-1639)

10. Replayed markets can share one cash pool. A replayed market keeps the exchange shard its own record names, so a seeded account needs presence and cash on that shard; the HOWTO’s “Seeding state” section now shows the seed. To fund every replayed market from one balance instead, start the twin with KALSHI_REPLAY_SHARD=0: each market minted from a tape or the live feed is placed on shard 0, at the cost of per-shard fidelity. (RYS-1679)

11. A grader can read a whole account, the action log and the run’s configuration over HTTP. GET /_account/snapshot returns one account’s cash per shard, positions with average entry price and a mark, portfolio value at those marks, open orders, every fill with its fee and the replay time it happened at, and settlements. It agrees with the Trade API’s own reads. GET /_rystic/actions?since=<seq> pages through this run’s action log, and GET /_rystic/config names the run: input digests, RNG seed, and the loaded replay session with its archive and cut manifest. All three need the admin token when one is set. (RYS-1680)

12. Replay can play games back to back in any order. POST /_replay/start takes a sequence of games, each a market or a list of markets, with gap_ms between them. Games recorded on different days play one after another on one session clock, each shifted whole (book, trades and market times), so a game plays the same wherever it sits in the order. KALSHI_CAPTURE_DIR can hold one cut archive per game. GET /_replay/status and GET /_rystic/config report each game’s recorded window, session window and offset, so a session time maps back to its recorded time. (RYS-1668)

13. The Enterprise image runs a replayed session with the network off. The HOWTO’s new “Running offline” section shows the docker create --network none recipe for a cut library: license, RYSTIC_REPLAY_METADATA=off, the admin token, the action log and a single cash pool. It also names GET /_rystic/version as the readiness probe. A nightly check runs a two-game session, its feed, an order and both settlements through the release image with no network. (RYS-1689)

v0.0.34 — 2026-10-02

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. Order ids from the matching engine come from their own range. An order the engine places gets an order_id such as a7cade2e-8c1a-43f4-8000-000000000001 rather than 00000001-0000-4000-8001-000000000001, the id other records minted first share. Ids still count up in their last digits and restart on reset; a test that pinned an old order id needs the new one. (RYS-1593)

3. market_unopened seeds its market as initialized. The market reports status: "initialized", Kalshi’s status for a market before its open time, where it reported "unopened", which is a GET /markets filter value and never a market’s status. Orders are still refused with 409 market_closed, and GET /markets?status=unopened still lists the market. (RYS-1600)

4. Scripted events fire on the sim clock. Load a schedule of timed messages and seeds with POST /_rystic/inject, or --inject <file> / RYSTIC_INJECT at boot. Each event fires once when the clock reaches its at, between the same two tape events at any replay speed. Fired messages are readable at GET /_feed?since=<seq>, and GET /_rystic/inject shows what fired and when. (RYS-1638)

v0.0.33 — 2026-09-30

1. The batched cancel is measured against live on the order it places. The sealed probe for DELETE /portfolio/events/orders/batched now cancels the resting order its own chain creates, so every round compares the simulator’s cancel with live Kalshi’s instead of stopping before the call, and the order no longer outlives the run. (RYS-1294)

2. The state UI takes the rystic.ai look. /_rystic/ui — the market list, order book, order entry and bot panels included — now reads in the site’s paper, ink and Space Grotesk instead of the dark theme. (RYS-1332)

v0.0.32 — 2026-09-27

1. Taker fees follow the fee schedule. A taker fill now pays ceil(0.07 × the series’ fee_multiplier × C × P × (1−P)) per fill, at the micro-dollar, as live Kalshi does; the simulator used the multiplier as the rate, so every taker fill on a series that carries one — the btc15m_tape world’s KXBTC15M among them — paid about 14 times the schedule. A backtest’s fees and P&L on the tape world are correct again, and two sealed probes hold the simulator to the schedule. (RYS-1255)

2. A replayed market keeps its ending to itself, and stays settled. While a tape market is active its record no longer shows the recorded expiration_value (look-ahead data in a backtest); its expected_expiration_time, latest_expiration_time, expiration_time and occurrence_datetime follow the market’s own geometry on the replayed clock (5 minutes and 7 days past close on a 15-minute market) instead of all reading close_time. After POST /_settle the market quotes bid 0.0000 / ask 1.0000 on an empty book, publishes the recorded settlement value, and the tape’s later frames leave it alone. (RYS-1256)

3. The V1 order writes answer 410, as live Kalshi has since June 2026. POST /portfolio/orders, POST /portfolio/orders/{id}/amend, DELETE /portfolio/orders/{id} and DELETE /portfolio/orders/batched now answer 410 deprecated_v1_order_endpoint with live’s envelope, so a bot that still calls them fails on the simulator the way it fails in production; trade through /portfolio/events/orders (V2). A v1-era bot you cannot change yet keeps its old wire by starting the simulator with RYSTIC_KALSHI_LEGACY_ORDERS=on. Four sealed probes hold the refusal. (RYS-1257)

4. The portfolio reads publish what live publishes. GET /portfolio/orders lists newest first by the full created_time instant, including fractional seconds, with order ID breaking ties so cursors resume deterministically; an order canceled through DELETE /portfolio/events/orders/batched keeps an RFC 3339 last_update_time instead of a unix integer; every resolved trade from a replayed tape reaches GET /markets/trades with the same ID, price and quantity as its WebSocket trade and any member fill; and balance, fills, positions and settlements no longer carry the simulator’s internal owner field. (RYS-1258)

5. Error envelopes match the exchange. A path the simulator does not route answers Go’s plain-text 404 page not found like live; GET /markets?status=<anything outside unopened|open|paused|closed|settled> is a 400 bad_request with details invalid status filter instead of an empty page; GET /markets?limit=1001 answers the parameter binder’s {"msg":"Parameter validation failed for GetMarkets: …"}; a routed 404 carries {"error":{"code","message"}} and no service key; and the rate_limited world’s 429 body is the documented {"error":"too many requests"}. (RYS-1261)

6. A repeated WebSocket subscribe merges its market scope into the same subscription. Subscribing again to a market-filterable channel answers {"type":"ok","sid":…,"seq":…,"msg":{"market_tickers":[…]}} on the same sid, followed by the requested markets’ snapshots. Subscribing to all markets keeps or expands the subscription to all markets; a later scoped subscribe cannot narrow it. Channels that require a market still require one, and keyed channels or channels configured to ignore market filters retain error 6 Already subscribed. (RYS-1259)

v0.0.31 — 2026-09-26

1. The login offer starts Kalshi in btc15m_tape, and HOWTO.md and the smoke scripts start from an API key. rystic login offers Kalshi booted into btc15m_tape, the world every plan can run, instead of tight_book. HOWTO.md leads with rystic login rys_…; HOWTO.md and SCENARIOS.md count all 47 named worlds and say which worlds, control-plane and /_replay/ routes Free, Pro and Enterprise reach. HOWTO.md gives Compose on RYSTIC_TOKEN with the Enterprise license second, sends /_settle with Content-Type: application/json, lists the lease check-in among outbound calls, and says the DELETE /portfolio/events/orders kill switch answers 404, as demo does. check.sh runs on your API key as well as a license and, on Free, waits for btc15m_tape’s market and reads it back instead of seeding; trade-check.sh says it needs Pro or Enterprise when the plan refuses its seed. (RYS-1204)

v0.0.30 — 2026-09-25

1. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

2. Live mode carries markets by event. --live-events E1,E2, RYSTIC_LIVE_EVENTS, or a shared --live-events-file / RYSTIC_LIVE_EVENTS_FILE (stack keys live_events / live_events_file) carry every open market of each named event, on top of any --live-markets. Each event is looked up again on every rescan, so a strike the exchange adds later is carried and a closed market drops. (RYS-1162)

v0.0.29 — 2026-09-23

1. Live market selections survive rollover. The feeder reapplies --live-markets and RYSTIC_LIVE_MARKETS_FILE on every discovery scan, removes closed selections, and picks up newly open named markets. When none of the selected markets is open, it waits instead of falling back to the busiest markets. This fixes gold-market rollover losing gold data while subscribing to hundreds of unrelated markets. A named market removed through the UI returns on the next scan.
2. WebSocket lifecycle and price-feed channels work. multivariate_market_lifecycle, pyth_value, cfbenchmarks_value, communications and order_group_updates now accept subscriptions. Markets minted by a tape or seed emit lifecycle creation events, and /_settle emits determined and settled events. Live mode forwards exchange-wide lifecycle and price-feed frames, even with no market selected. Price feeds remain silent on recorded tapes; accepting communications and order-group subscriptions does not generate events for those channels. Scheduled market close remains time-based and sends no lifecycle frame. Forwarded live settlement frames do not settle the twin’s own market; exchange-wide frames may be dropped under feeder backpressure to preserve order-book updates.

v0.0.28 — 2026-09-22

1. Orders on btc15m_tape now fill. In v0.0.27 every order placed on the recorded KXBTC15M market answered 404 user_not_found. The market trades on exchange shard 2, as it does on Kalshi, but the world put the $10,000 balance on shard 0 only. The balance now sits on shard 2: GET /portfolio/balance shows a balance_breakdown of $0.00 on shard 0 and $10,000.00 on shard 2, and an order on the market fills against the replayed book. The free edition, which boots this world, has the same fix.

v0.0.27 — 2026-09-22

1. A real recorded session as a named world: btc15m_tape. ./kalshi-twin --scenario btc15m_tape boots into the KXBTC15M market that closed 2026-09-03 10:30 UTC, exactly as the exchange streamed it. It replays all 62,629 WebSocket messages recorded live off the feed, including 2,818 prints, event for event on the exchange clock from the moment the world starts, with no /_replay call. Your bot fills against the real book, level for level, in a session that runs 0.52 → 0.95 and settles yes. The market is served active on a clock rebased to now, and the 14-minute session loops, so a bot left running never reaches the end. The world seeds the market’s own event and series and a $10,000 balance. It is the 47th named scenario (SCENARIOS.md lists it under Recorded) and the one world the free edition serves.
2. /_rystic/version reports more. The control-plane contract moves from 7 to 9. edition is always present: empty on a licensed build and free on the free edition, so a caller can tell them apart without probing. --version prints the same value as an edition: line. initial_clock is the epoch a reset returns the clock to. api_base_paths, service_hosts, preserve_service_urls and credential_required report settings other twins declare. Kalshi declares none, so they read empty, false and 0, present so one client reads every twin the same way.
3. The EULA in the archive gains a Free Edition section. LICENSE.txt now defines the Free Edition and sets out its terms as Section 13; General moves to Section 14. The terms of your license are unchanged, and a licensed build still sends nothing over the network.

v0.0.26 — 2026-09-17

1. Drop a WebSocket connection on demand. GET /_rystic/ws lists every open socket with its subscriptions; POST /_rystic/ws-drop cuts them by tickers (any socket whose subscription names one), by connections (ids from the listing), or all. The default is a bare close with no close frame, what a crashed server or a severed path looks like; graceful: true sends 1001 going away first. A reconnect bug in a one-to-many exchange client is fleet-wide, and sockets are split by ticker, so a test drops one stream and asserts the others survive. The drop is recorded on the event stream as a control op.
2. One tape as many markets. /_replay/prepare and /_replay/start take copies: N, playing one tape as N distinct markets on one clock, named <tape>-1 … <tape>-N, each on its own stream; {"tape", "as"} members in markets pick the names yourself, mixed freely with plain tapes. REST and WS agree on the new ticker, the real record (strike, title, grid) carries over from the tape’s own ticker, and status shows which tape each member plays. Each copy is folded separately, so memory scales with copies × tape size. rystic run kalshi-twin --tape <id> --copies N does the same from the CLI, and the copies survive a restart.
3. A load rig for the reconnect path. examples/kalshi-loadtest in the rystic-sim repo drives N streams against N copies with a drop on a timer and reports frames/s, pace (tape time advanced per wall second; 1.00 means the twin kept up) and reconnect latency. Its README records what one twin sustained; run it on your own hardware before trusting a number.
4. Every live setting from the environment. --live reads RYSTIC_LIVE=1 and every --live-x-y flag reads RYSTIC_LIVE_X_Y, flag over env over default, so a container starts fed with no argv. New --live-markets a,b (RYSTIC_LIVE_MARKETS) carries exactly those markets before the state UI picks; KALSHI_PRIVATE_KEY_B64 carries your own key inline beside KALSHI_PRIVATE_KEY_FILE (the id and one key form); a stack file’s live: true service takes live_env, live_series, live_max_markets, live_shards, live_carry and live_markets; and rystic run --live --runner docker runs the feeder on the host beside the container, ended first by stop.
5. A scenario swap under a running tape is one step. Moving the twin to another scenario while a tape played could carry the previous world’s records into the new one, because a frame already in flight landed after the reset. The swap now holds the tape off for its whole duration, so a retired tape cannot seed the new world.
6. A market always has its event. Seeding a state_market_catalog record (or replaying over one you seeded first, the strike-metadata workflow) now mints the state_event it names when none exists, so GET /events/{event_ticker} and GET /events?series_ticker= answer for every market the twin serves — on the exchange a market cannot exist without its event, and the twin used to 404 where Kalshi returns 200. A minted event carries its market’s exchange_index instead of a fixed 0, and no longer claims a collateral_return_type the exchange never serves. An event you seed yourself is left as you seeded it.

v0.0.25 — 2026-09-12

1. Pausing a replay inside a quiet stretch of tape no longer loses your place. Between two recorded events the play head paces the gap on the clock. POST /_replay/pause now keeps that paced position, play (and a speed change mid-flight) resumes from it instead of rewinding to the last applied event, and GET /_replay/status reports it while paused as well as while playing. Before this, chunked playback — pause, play a little, pause again, the shape an agent-driven clock takes — could never cross a gap longer than one chunk, and a status read taken while paused mid-gap jumped a whole gap forward. An uninterrupted play is unchanged.

v0.0.24 — 2026-09-06

1. The twin can be fed a live stream, not only a recorded tape. rystic run kalshi-twin --live starts the twin and a feeder together: the feeder holds the authenticated exchange socket and pushes every frame to the twin, so your bot trades against a book that is tracking the real market right now. rystic feed kalshi-twin --url <base> attaches a feeder to a twin that is already running — any runner, any machine, which is also how you feed a containerised twin. Pick the exchange with --live-env prod|demo, choose what is carried with --live-series and --live-carry, and spread the carried markets over more sockets with --live-shards. Keys come from KALSHI_KEY_ID and KALSHI_PRIVATE_KEY_FILE, checked before the twin starts so a missing key cannot leave a half-started instance.

   The twin still dials nothing. The socket lives in the CLI process, never in the twin — that is what keeps the twin’s offline licence and hermetic guarantees intact. Frames arrive at POST /_replay/feed and go through the same fold and the same seam a tape frame takes, so a fed twin ends on the same book a tape replay of the same bytes ends on.

   What is not claimed: paper-trading fidelity. Your orders fill against the fed book and prints but never move them, and queue position is exactly what apply-mode replay already claims. Delivery is best-effort — a slow twin costs frames (counted and reported), never the recorder a byte, and a dropped delta leaves the book behind until that market’s next snapshot.

2. The state UI carries a watch list. The Markets card lists what the feeder offers — hundreds of open markets, busiest first — and you add, remove and watch several at once; viewing a market implies carrying it. The Replay card reports the live session: frames applied, frames dropped, how many markets are carried, and lag, which is the age of the last frame that arrived. A climbing lag means nothing is feeding the twin.

3. The clock steps; it no longer runs. Simulated time used to advance in real time from wherever you pinned it, so two runs of the same request sequence rendered different timestamps, and an order with an expiration_time expired on wall time. The clock now moves one millisecond per request that reads it and stands still between requests: the same sequence from the same reset renders byte-identical stamps, created_time and ts included. What changes for a bot: nothing expires while the twin is idle — advance the clock past the deadline with POST /_rystic/clock {"advance_seconds": N} (or pin it with {"time": ...}) and the first request after that cancels the order. Two orders placed seconds apart now carry created_times one tick apart, not seconds apart, so assert on ordering, never on elapsed time. The HOWTO’s clock section is rewritten to match.

v0.0.23 — 2026-09-02

1. The boot banner prints a URL you can paste. 0.0.21 and 0.0.22 announced http://[::]:8080 on all four boot lines — the wildcard bind the listener reports, not a host — while the CLI’s own summary line said localhost:8080 for the same port. The banner now rewrites the unspecified address in all three forms ("", ::, 0.0.0.0) to localhost; an explicit host survives untouched. --health still answers 127.0.0.1, because a distroless image has no resolver.
2. Two order-entry rejections now come in live’s order and live’s words. A reused client_order_id answers 409 order_already_exists before the balance check, and a fill_or_kill the book cannot cover answers 409 fill_or_kill_insufficient_resting_volume before it too; the twin used to answer 400 insufficient_balance to both, and the duplicate’s envelope (duplicate_client_order_id) was one live has never sent. good_till_canceled and post_only keep answering insufficient_balance pre-match, as live does. One walk of the book per order; nothing is written on a rejection.
3. The backtest half of the API answers. /historical/* read registers no scenario ever seeded, so every world booted with a dead archive: cutoff at epoch, 404 on historical/markets/{ticker} and on candlesticks at all three intervals, empty fills, orders and trades. --scenario has_history now boots a world holding both halves — KXDEMO-26-A open and tradeable, KXDEMO-25-SETTLED in the archive behind a 2026-07-20 cutoff — each 404ing on the other’s half, which is the property historical/cutoff exists to express.
4. Four reads answer the question asked. A candlestick’s end_period_ts is the inclusive end of its window, so a trade landing exactly on the boundary files in the period it closes rather than one period late. ?event_ticker= on both positions reads narrows through the market’s catalog record instead of returning every event. forecast_percentile_history is one series per event, with the percentile taken across that event’s markets, not one duplicate-addressed item per market. total_cost_shares_fp counts seeded contracts once and traded fills as they land, instead of rolling traded shares up against the cost of both.

v0.0.22 — 2026-08-30

1. Every world in a batch gets its own arguments. The bot contract was four environment variables; the argv after -- was exec’d byte-identical in every slot, so rystic batch -j 4 -- ./bot --market KXBTC… ran four worlds against one ticker. The same values now substitute into your bot’s own argv as {{world}}, {{world_kind}}, {{market}}, {{addr}} and {{result}}, for a bot that takes them as flags rather than reading the environment. The environment variables are unchanged — this is additive. An unrecognised placeholder is refused before anything boots, -dry-run prints the resolved command per world, and {{market}} is refused on grid and batch -scenarios, where a world has no market and --market "" is an argument your bot cannot tell from a real one. {{market}} is the market ticker (KXBTC15M-26AUG202330-30); a bot that subscribes by event or series derives those from it — the derivation is in the HOWTO.
2. Correlated tapes play as one exchange. BTC, gold and silver over the same session used to mean three processes on three ports, each rebasing its own first event to now — which erased the offset between the markets, the one thing a correlated group exists to preserve. Pass markets: [...] to prepare and start and the group is merge-sorted into a single time-ordered stream: one twin, one port, N tickers, one play head, one rebase offset. The window is trimmed to the overlap; tapes that never overlap are refused with both spans named.
3. Fills and orders carry the side/action fields live still serves. The WebSocket fills channel serves action_side; REST serves book_side and outcome_side. The deprecated field was absent from the twin, so a bot reading it saw a key error — and stopping one bot and starting another on the same tape surfaced it as apparent state corruption.
4. 17 documented operations the twin never registered now route, and the read surface answers for what it is served beside: the catalog answers for its book, and the account answers for the trades that moved it. Order entry enforces the bounds it declares, and list endpoints page.
5. A miss answers as the exchange. The error contract returns Kalshi’s own shape rather than a generic one, and the parser no longer accepts infinities.
6. Smaller surface corrections. Block-trade accept requires the caller to be a named party. /exchange/status omits exchange_estimated_resume_time rather than sending it null. /events/{ticker}/milestones is served. expiration_time is enforced as a deadline rather than recorded as a note; an amend keeps what the order was created with; the mutation path sees only resting orders.
7. Replay accuracy. Tape removals are attributed to trades versus cancels and the queue advances behind-first; a play-head jump re-syncs the applier’s tally. The network profile is re-measured from us-east-2, the region production is served from.

v0.0.21 — 2026-08-27

1. The exchange is sharded, the way the real one is. Buying power, presence and routing are now per exchange shard: an order routes to its market’s shard and records it (exchange_index on the order record), the cash on that shard is what admits it, and the three portfolio/intra_exchange_instance_transfers routes move cash between shards. Cancels route too, and the default is shard 0: a DELETE .../events/orders/{id} with no ?exchange_index cannot reach an order resting on any other shard and answers the same 404 as an unknown id. Pass ?exchange_index=<n>, or ?exchange_index=-1&market_ticker=… to auto-route by market — wire it now, before your first non-zero-shard market teaches it to you as “my cancels stopped working”.
2. Post-only meets your own quotes the way live does. A post_only order under self_trade_prevention_type: maker whose crossing region — every opposite level at or through its price — holds only your resting orders is now accepted: those orders are canceled in full and the new order rests at its full count, exactly live’s behavior (pinned by an 8-case demo matrix, every order read back to its terminal state). Any other participant’s order in the region, whatever its price priority — or any crossing at all under taker_at_cross — still answers the exact 400 invalid order / post only cross, byte-identical, so a pull-all-quotes trigger keyed on that string keeps firing. An MM re-quoting ask-first over its own resting bid no longer takes a spurious reject.
3. One trade, one id, five surfaces. A match reports itself under a single id everywhere it appears — each party’s REST fill record, each party’s private WS fill frame, and the public WS trade print — live-verified with three subscriptions open across one crossing fill. Correlate the feeds by id; the heuristics can go.
4. Position money at live’s scale. GET /portfolio/positions renders its money fields at six decimal places (“0.114600”), the scale live uses — a client comparing them as strings no longer diverges on every read — and each fill leg is recorded under its own party.
5. A replay reseed no longer swallows WS frames in flight. On a replayed market, an orderbook delta rendered inside the reseed’s poll window could be dropped as “already reflected” — a resting order’s own delta sometimes never reached the subscriber. The gateway now drains pending frames before and inside the reseed, so the stream is complete across tape snapshots.
6. Batched creates are yours alone. The batched order path stamps every order it creates with the caller’s identity exactly as the single-order path does, held in place by its own regression test.
7. A fresh install has somewhere to go. The bundled random-walker and the “no markets” screen no longer point exclusively at replay — which needs a tape archive a fresh install does not have. Scenarios are compiled into the binary and --list-scenarios names them, so the quickstart works thirty seconds after the install, tape or no tape.

v0.0.20 — 2026-08-21

1. A replayed market knows what it is. Replayed markets now carry the exchange’s own record for that ticker — floor_strike, cap_strike, strike_type, custom_strike, occurrence_datetime, the real yes_sub_title/no_sub_title (“Target Price: $64,968.77” rather than “Yes”) and the market’s own declared price grid. On a threshold market the strike is what the market means, and a bot that read it off a replay used to find nothing there. The record comes from your capture’s meta/ log when it has one; otherwise the twin fetches it once per tape, unauthenticated, and caches it into the archive so it never fetches again.
2. That fetch is yours to refuse, and bounded when you keep it. RYSTIC_REPLAY_METADATA=off disables it outright — replay is unaffected either way, since a failed or disabled fetch never blocks playback. RYSTIC_REPLAY_METADATA_HOSTS=<host> pins the host it may dial. The twin only ever speaks https, never follows a redirect off the host it started on, and logs the host it used on the first fetch. Stated plainly because it matters to a trading desk: with the fetch enabled, replaying a tape tells the exchange which historical window you are studying.
3. The market is replayed as it was, not as it ended. The fetched record is the market at settlement — finalized, with a result. Status, result, settlement values and every time field stay derived from your tape, so you still get an active market with a book that moves.
4. The price grid is per market, not per series. Kalshi migrated KXGOLD15M from whole-cent to tapered deci-cent midway through 2026-08-20: the 06:45Z window and the 09:45Z window of the same series have different tick sizes. The twin serves each market’s own declared grid, and the per-series table is now only a fallback for a tape whose record is unknown. Read price_ranges per market rather than memorising which series is which.
5. A twin that dies says so at once. rystic run -d, up and check used to wait out the full readiness timeout when a twin refused to boot — against a bad license, say — and then blame the timeout. They now notice the exit and name it: the twin exited before serving: exit status 1.
6. The shipped scenario packs are complete against the current model. Every loadable pack is now checked field by field as it loads, and the packs that were short of the widened market and event records were completed (35_self_trade_prevention among them).

v0.0.19 — 2026-08-20

1. Backtest results you can read. rystic batch now ends in a per-market P&L table — mtm, net, fees, mark, traded, fills, position, balance — with exact totals, and each finished market’s line carries its mtm and fees. rystic report <out-dir> re-renders the table from a finished run any time, with -csv for spreadsheets, -sort <column>, and --json.
2. Honest mark-to-market. The twin values every open position at the market’s last traded price (shorts at the dual), updated on every trade — yours or the tape’s — and zeroed at settlement. Markets that were never settled are called out loudly: realized columns exclude their outcomes, the mark columns carry the last-price valuation, and the -settlements file realizes them exactly.
3. Live progress while tapes play. A heartbeat per slot — events played, percent, time left — and a run-wide estimate on every completion, so a 15-minute tape no longer looks like a hang.
4. rystic doctor and the replay screen speak the CLI. The tapes hint now says -tapes <dir> instead of naming an internal environment variable, and names where tapes come from.

v0.0.18 — 2026-08-20

1. Money folds in exact micro-dollars. Balances, positions and fees accumulate in an exact internal register instead of re-reading their own printed 4-dp values, so a long session’s balance is the exact figure rendered once — sub-cent fee debits no longer drift, and the register never leaks onto the wire.
2. A minted market declares the grid the exchange declares. Replayed markets now carry the complete live record — the declared price grid (price_level_structure + price_ranges), the full quote/volume block derived from the tape, and a complete parent event — so a bot that indexes the catalog before pricing no longer dies on a missing field.
3. An unbuilt fleet image names the build. rystic batch --runner docker --image with an image that was never built now says to build it (with the exact command) instead of surfacing Docker Hub’s “may require ‘docker login’” dead end.

v0.0.17 — 2026-08-19

Same simulator as v0.0.16. First release cut, published and verified end to end by the automated pipeline — every archive, checksum, image digest and download endpoint checked per licensee before publication.

v0.0.16 — 2026-08-19

1. Ctrl-C stops a docker fleet. Cancelling rystic batch --runner docker now kills the whole container process group instead of leaving workers running.
2. Fleet failures name their cause. A world whose twin never served reports the twin’s last log line in the ledger row; an image whose bundled rystic predates -tape says exactly that instead of “exited 2”.
3. Sharper docker errors. A missing image is “no such image” (exit 5), never mistaken for an auth failure; a container-name collision names the project holding the name.

v0.0.15 — 2026-08-19

1. Fleets from your own image. rystic batch --runner docker --image <yours> -- <bot> runs one container per tape or world from an image you build FROM registry.rystic.ai/kalshi-twin:<ver>, with a ledger row per world. -tape <id> names one tape exactly.
2. Stack files. Declare a hand-picked set of twins once in rystic.yaml; rystic up / down / ps --project manage them as a group.
3. Export. rystic export compose emits a digest-pinned compose file (license via .env, never in the file); rystic export antithesis scaffolds the config image and launch steps.
4. Secrets passed to bots ride -e NAME — values never appear in docker’s argv.

v0.0.14 — 2026-08-18

1. Images pull from registry.rystic.ai. --runner docker pulls the published per-licensee image through the registry front door — your license file is the docker credential, and rystic login runs the docker login for you.
2. The shipped Dockerfile is retired. The container path is the published image; the HOWTO opens with rystic login / rystic run.

v0.0.13 — 2026-08-18

1. Instances. rystic run -d --name --port, ps, stop, restart, rm, logs, status, a --json envelope on every command, and a stable exit-code contract (8 = runtime unavailable, 9 = conflict).
2. rystic list is the released catalog — latest, installed and running per product your license covers.
3. A twin says which build it is. --version, --health, and product/version/watermark on GET /_rystic/version.
4. rystic grid runs the bundled bots across named scenario worlds; the bots take a RYSTIC_TICKS budget and exit instead of running forever.
5. The quickstart’s check.sh resolves your license before booting the twin.

Cut for a subset of licensees and superseded the next day — rystic pull may resolve past it; nothing was lost by skipping it.

v0.0.12 — 2026-08-17

1. Shipped scenario packs carry complete market records, held by the same completeness gate as the built-in scenarios.
2. Order creation validates required parameters as the outermost gate, so a missing field 400s the way production Kalshi does.

v0.0.11 — 2026-08-17

1. Complete market records in scenarios. Every scenario market now carries the full Kalshi field set (close_time, price_level_structure, price_ranges, yes_sub_title, …), so clients that read the whole record no longer crash mid-stream. A seed-completeness gate keeps future scenarios honest.
2. Per-customer archives. Release assets are watermarked per licensee; rystic pull resolves the build your license names.

v0.0.7 — 2026-08-12

1. Named scenarios ship with the twin. rystic run kalshi-twin --scenario thin_book; --list-scenarios and SCENARIOS.md for the menu.
2. Evidence-backed fees and P&L. Taker fees micro-ceil per fill, maker fees only on series that declare them, offsetting fills net on the spot, positions settle at expiry.
3. Replay runs on the exchange clock, not capture-arrival time. Every tape starts from a flat portfolio.
4. State UI. Effective configuration in the header, an Avg cost tile per bot, a Network panel.
5. rystic check accepts 204 No Content from /_rystic/reset.

v0.0.6 — 2026-08-11

First build shipped alongside the rystic CLI. Feature set is v0.0.5’s; existing licenses work unchanged.

v0.0.5 — 2026-08-10

1. Replay is 9.4× faster, byte-for-byte identically — a 446k-event tape plays in 41s instead of 384s.
2. Member fills print to the public tape, sharing one trade_id sequence with private fills.
3. The egress log is bounded at 100k frames (RYSTIC_EGRESS_RETAIN to widen) and reports dropped.
4. Network shaping, inert by default — POST /_rystic/network.
5. Network panel in the state UI.

v0.0.4 — 2026-08-03

First licensed build: the license gate, LICENSE.txt in every archive, a rebased tape that survives restarts, and one actor identity across HTTP, WS, and replay.

v0.0.2 — first limited release

Trade API v2 (88 routes), the matching engine, the WS feed at /trade-api/ws/v2, captured-day replay, and the state UI at /_rystic/ui.

PayPal

v0.0.8 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. design_studio carries a timeline. As the clock moves past 2026-03-01T00:00:00Z, the world opens an order for Wildflower Daycare’s open invoice, charges Oakridge Bakery’s saved wallet for its hosting renewal, refunds 500.00 of Saltmarsh Brewing’s deposit, and authorizes then captures Quill and Ink Stationery’s March care plan, each a call on the twin’s own API under the world’s bound tokens. Those calls take the first order, capture and authorization ids, so a test that advances the clock before creating its own sees its ids minted later in the sequence. (RYS-2459)

4. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

5. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

6. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.7 — 2026-10-11

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. Every link the twin hands out leads back to the twin. An order’s, authorization’s, capture’s or refund’s links[].href and an error’s information_link now carry the origin you reached the twin on, with PayPal’s path kept, so a client that follows self, capture or refund calls the twin rather than PayPal with its token. A buyer approve link and a documentation link now answer 404 from the twin; a twin started with rystic run --intercept keeps PayPal’s hosts in its links, which rystic exec routes to the twin. (RYS-1910)

3. The order read accepts your client id and secret. GET /v2/checkout/orders/{id} now answers HTTP Basic client_id:secret as the sandbox does, beside a bearer token; the other payment routes still answer Basic with 401. (RYS-1920)

4. The guide lists what the twin serves and what it does not, from the model. HOWTO.md and the docs page now carry the served operations and the known gaps generated from the twin’s model and its open issues: the spec operations not served, the branches the fidelity suite does not measure, what the model leaves out, and the known differences from the sandbox. (RYS-1918)

5. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.6 — 2026-09-30

1. PayPal-Debug-Id keeps its spelling. A 404 on an authorization, capture or refund read now sends PayPal-Debug-Id instead of Paypal-Debug-Id; the value still repeats the body’s debug_id. (RYS-1336)

2. The state UI shows the account as PayPal Business. On Pro and Enterprise, /_rystic/ui opens a live PayPal Business-style view of the twin — Home with a derived balance, Activity with gross, fee and net, and each transaction’s details — where you can refund captures, capture or void authorizations and capture approved orders through the API, approve a waiting order as a chosen buyer, and watch your integration’s calls, the egress events, stored request ids and OAuth tokens. (RYS-1375)

v0.0.5 — 2026-09-26

1. The guide starts from an API key, says what each plan reaches, and documents the payment events. HOWTO.md now opens with rystic login rys_…, says what Free, Pro and Enterprise boot and which control-plane routes each answers, states which routes check a bearer token (and which seven refuse a minted token marked expired), and corrects the claim that the twin emits no webhook events: authorization capture and capture refund write PAYMENT.CAPTURE.COMPLETED and PAYMENT.CAPTURE.REFUNDED to GET /_rystic/egress, and authorization void writes the twin’s own authorization_voided record. SCENARIOS.md says what each plan boots. check.sh finds the API key rystic login stored as well as a license file, looked up in the CLI’s order, and rystic features marks the features and commands that need Pro or Enterprise. (RYS-1204)

v0.0.4 — 2026-09-26

1. Only design_studio ships as a named scenario. The older scenarios are now test-only fixtures and are no longer accepted by --scenario, RYSTIC_SCENARIO, or POST /_rystic/scenario. Tests and evaluations can load their unchanged register maps and clocks from sim/testdata/scenarios/ through the control plane. (RYS-1177)

v0.0.3 — 2026-09-25

1. A new world, design_studio, now the default. --scenario design_studio boots Website Design Contractors’ business account: 57 completed orders, one per invoice its eight PayPal clients paid, each with its capture, invoice_id the studio’s invoice number and custom_id the client, the same invoices the studio’s Slack, Resend and Stripe worlds name. A lease that grants no scenarios boots it. (RYS-1171)

2. The HOWTO now names what the twin does not do. Its scope section lists the six measured-refusal routes with their status codes, that there are no list routes, and that webhooks, bearer verification, asynchronous settlement and token expiry are not modeled; the worlds section documents GET /_rystic/scenarios and POST /_rystic/scenario for switching worlds without a restart. (RYS-1020)

v0.0.2 — 2026-09-24

1. More accurate authentication errors. Requests without credentials now return PayPal-compatible 401 responses before resource lookup across checkout and payment endpoints. OAuth token requests with a missing or unsupported grant type return the corresponding unsupported_grant_type error.

   Order validation and replay. Multiple purchase units require reference IDs. PATCH rejects removal of required amounts, empty purchase units, unsupported moves, invalid currencies, and missing reference selectors without changing state. Order reads reject XML-only response requests. Replayed order creation returns the current order after a successful PATCH.

2. Complete PATCH validation errors. Invalid order updates now report structural errors in request order, including repeated errors, before applying changes or validating amount values. Replacing the entire purchase-unit array is rejected. Failed compound updates preserve the original order and payment state.

3. USD refunds retain the original capture processing fee instead of returning a prorated amount. Ordinary USD refunds report zero PayPal fee and net equal to gross, including partial refunds and the final remainder. Replays preserve the stored refund and do not move money again.

   Direct-card creation and order capture use the existing synthetic USD capture policy already used by authorization capture and scenario seeds: 3.49% plus USD 0.49, rounded to cents. This is deterministic simulator pricing, not a claim about a merchant’s current PayPal rate. Non-USD capture pricing and platform-fee return rules are unchanged and are not newly validated.

v0.0.1 — 2026-09-24

1. Exercise PayPal checkout, authorizations, captures and refunds locally with twelve payment-history worlds, deterministic reset and clock control, validated retries and error contracts, and a packaged installation check. (RYS-1056)

Lob

v0.0.8 — 2026-10-12

1. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

2. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

3. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

4. design_studio carries a timeline. As the clock moves past 2026-03-01T00:00:00Z, the world saves Harborview Dental’s second office, sends a spring-checkin postcard to Redwood Realty under an idempotency key, schedules one to Atlas Moving and cancels it a day later, then lists the campaign, each a call on the twin’s own API under the world’s bound test key. A test that advances the clock past +1h now sees these records. (RYS-2459)

5. A world can move a postcard through the mail. POST /_tracking_event records a USPS scan (In Transit, Delivered, Returned to Sender and Lob’s other documented names) on a postcard’s tracking_events, so a world’s timeline can carry a piece from mailing to delivery. (RYS-2461)

6. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

7. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

8. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.7 — 2026-10-11

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. The test fixtures seed Lob’s render status on postcards. In lob_mailroom, lob_returned_mail and lob_campaign_blast under sim/testdata/scenarios/, a mailed postcard’s status was a mail state (delivered, in_transit, returned_to_sender, …) or canceled. It is now rendered, a value of Lob’s PDF render status; the mail’s progress stays in tracking_events, and the canceled card is still marked deleted: true. (RYS-1600)

3. Deleting an address marks the postcards sent with it, as Lob does. After DELETE /addresses/{adr_id}, a postcard sent from or to that address is still served, and its embedded from or to address answers deleted: true. Measured against Lob’s test environment. (RYS-1858)

4. A list’s next_url and previous_url lead back to the twin, and /v1 paths answer. Both list cursors name the host your client reached the twin on, under /v1, where they named api.lob.com, so a client that follows one stays on the twin. Every Lob path now answers with and without the /v1 prefix, so an SDK’s host override may keep Lob’s https://api.lob.com/v1 form with the twin’s host. A twin started with rystic run --intercept keeps api.lob.com in those URLs, which its gateway routes to the twin. (RYS-1910)

5. A request without credentials answers Lob’s Missing authentication. Every route answers a request that presents no Basic credential, with no Authorization header or one under another scheme such as Bearer, with Lob’s 401 {"error":{"message":"Missing authentication","status_code":401,"code":"unauthorized"}} before it reads anything else, so a refused create writes nothing; it answered “Your API key is not valid…” or “The request isn’t authorized.” before. A Basic header with an empty username, or with a payload that is not base64, still answers the route’s own 401. (RYS-1920)

6. A seeded postcard renders as a created one. In design_studio and any world you seed, a postcard’s to and from answer the address objects a created postcard embeds, where they answered bare address ids, and a record missing object (or a postcard missing carrier) takes Lob’s value. design_studio’s postcards also carry raw_url, print_speed, to_be_expunged_date, qr_code, completed_at, is_creative_proof, is_dashboard, usps_campaign_id and lob_credits_funding_status, and its addresses recipient_moved, as created ones do. (RYS-1911)

7. The guide’s Coverage and Limitations are generated from the twin. Coverage lists every route the twin serves at its /v1 path, and Limitations end with the twin’s open issues and the spec operations, unmeasured branches and unmodeled behaviors it leaves out, regenerated whenever the twin changes. The postcard list’s total count is requested as include[]=total_count, the form Lob takes. (RYS-1918)

8. lob-assets.com render URLs are declared Lob’s asset host. A postcard’s url, raw_url and thumbnail URLs on lob-assets.com, seeded or answered, are handed out as written and never rebased onto the twin, by declaration (pipeline_policy.json host_roles) rather than by omission, so a seed carrying Lob’s own render URLs passes RYSTIC_SEED_GATE=reject. The twin serves no render behind them. (RYS-1910)

v0.0.6 — 2026-09-30

1. Rate-limit headers keep their lowercase spelling. ratelimit-limit, ratelimit-remaining and ratelimit-reset on address and postcard creation now reach the wire lowercase instead of as Ratelimit-Limit and friends, so a client that keys on the received header name reads the names as written. (RYS-1336)

2. The state UI shows the account as the Lob dashboard. On Pro and Enterprise, /_rystic/ui opens a live Lob-style view of the twin — postcards with their proof, addresses and tracking, and the address book — where you can send and cancel postcards and add or delete addresses through the API, beside Mail stream and Calls cards. (RYS-1377)

v0.0.5 — 2026-09-26

1. The guide starts from an API key and says what each plan reaches. HOWTO.md now opens with rystic login rys_…, says what Free, Pro and Enterprise boot and which control-plane routes each answers, and states that DELETE /addresses/{adr_id} is the one route that checks no credential; SCENARIOS.md says what each plan boots. The rystic features example that filtered on a status no postcard carries now filters design_studio by client, the idempotent-send example mails between two of design_studio’s own addresses, and the features and commands that need Pro or Enterprise say so. check.sh finds the API key rystic login stored as well as a license file, looked up in the CLI’s order. (RYS-1204)

v0.0.4 — 2026-09-26

1. Only design_studio ships as a named scenario. The older scenarios are now test-only fixtures and are no longer accepted by --scenario, RYSTIC_SCENARIO, or POST /_rystic/scenario. Tests and evaluations can load their unchanged register maps and clocks from sim/testdata/scenarios/ through the control plane. (RYS-1177)

v0.0.3 — 2026-09-25

1. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

2. A new world, design_studio, now the default. --scenario design_studio boots Website Design Contractors’ account: the studio’s return address, 38 client addresses and 63 first-class postcards, a holiday campaign and a thank-you card after each site launch, each tagged metadata[campaign] and metadata[client], with one holiday card returned to sender. The clients are the same ones the studio’s Slack, Stripe and Resend worlds hold. A lease that grants no scenarios boots it instead of lob_mailroom. (RYS-1171)

3. Every probe matches live Lob. The last full-suite round scored 21 of 21 probes on 2026-09-24 against real api.lob.com, and the four differences the first release listed are repaired: a last page answers next_url: null, an inline to or from carries email and phone as null and a postcard read answers deleted: false, a canceled postcard reads back as the canceled piece with deleted: true, and the captured 210 King St address reads back with Lob’s ZIP+4. One known difference remains, disclosed under Limitations: a failed postcard can still be canceled inside its send window where Lob answers 422 not_deletable. (RYS-1090)

v0.0.2 — 2026-09-24

1. Postcard cancellation and response consistency. Canceled postcards remain retrievable with deleted: true and disappear from collection lists; created postcards retain front/back thumbnail links. Scheduled filtering compares send and creation dates, and omitted send dates use the documented default cancellation window. Address creation stores its standardized response, while reads preserve stored address values. Lob API keys resolve through the shared HTTP Basic authentication layer, including regenerated testbooks and shape checks. Collection probes isolate their seeded postcards with a fresh metadata filter and exercise pagination with two records. (RYS-1067)

2. Updated coverage guidance. The Lob guides now describe repaired cancellation, pagination, thumbnail and address responses, clarify HTTP Basic authentication, and distinguish seeded mail stages from unverified asynchronous rendering and failure transitions. (RYS-1085) The guides also disclose the failed-postcard cancellation mismatch, with repair tracked in RYS-1090. (RYS-1085)

v0.0.1 — 2026-09-24

1. A local Lob for your mail-sending code’s tests. The first release of the Lob twin: 8 routes over addresses (create, retrieve, delete, list) and postcards (create, retrieve, cancel, list), served from a model validated against real api.lob.com with a test key. Point your Lob SDK’s host at the twin — http://localhost:8080, no /v1 — and your existing calls run against it unchanged, with form-encoded or JSON bodies. (RYS-1023)

2. A retried send is the same postcard. POST /postcards honours an Idempotency-Key header, or an idempotency_key query parameter, as Lob does: a replay under the same key answers the original postcard instead of sending a second one, so the retry loop around your send is testable without mailing anything twice. (RYS-1023)

3. Four named worlds, baked in. --scenario lob_mailroom boots five postcards standing at every healthy stage from rendered through delivered, with their tracking histories; lob_returned_mail the returned, failed, re-routed and canceled pieces with their failure_reason; lob_campaign_blast six sends under one campaign_id for paging and filters; lob_quiet_desk one of everything. SCENARIOS.md says what each is for. (RYS-1023)

4. Seed the mailroom your test needs, and get the same one twice. POST /_rystic/seed lands addresses, postcards and idempotency keys directly; GET /_rystic/registers lists every field it accepts. POST /_rystic/reset rewinds the id sequence and the clock, so two identical runs give byte-identical postcards down to id, send_date and expected_delivery_date. (RYS-1023)

5. It never reaches the network, and it needs no key. Any key is accepted as the Basic username and the twin dials nothing: nothing you send renders a PDF, counts against a rate limit, or could ever print or mail a piece. Not in this release: letters, checks, self-mailers, templates, campaigns as a resource, address verification and webhooks; a postcard does not move through the mail stream on its own — boot a world or seed the stage you need. (RYS-1023)

6. What is measured, and what is not. Fidelity is scored differentially against real api.lob.com with a test key, per response field, not by eyeball: the last full-suite round was 13 of 21 probes on 2026-09-24. That is an early number and this release ships it as-is. The misses are four known differences, listed in HOWTO.md under Limitations: next_url is a link on the last page where Lob sends null; an inline to or from address omits email and phone, and a postcard read answers deleted: false, where Lob sends null; a canceled postcard reads back as 404 where Lob answers the canceled piece; and an address reads back with the ZIP you sent, not Lob’s ZIP+4. Rounds are re-run daily and each release states its own number. (RYS-1023)

Okta

v0.0.3 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. design_studio carries a timeline. As the clock moves past 2026-03-01T00:00:00Z, the admin Noor Haddad adds Hannah Kim to Content and retitles her, suspends the freelancer Ava Chen and removes her from Freelancers, then creates and activates Lena Okafor and adds her to Freelancers, each a call on the twin’s own API under Noor’s bound token. A test that advances the clock past +1h now sees these changes, and Lena takes the first user id the twin mints. (RYS-2459)

4. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

5. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

6. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.2 — 2026-10-11

1. A group lookup’s error id comes from its own range. An error from GET /api/v1/groups/{groupId} carries an errorId such as oae6f3c83c1-0474-49d0-8000-000000000001 rather than oae00000001-0000-4000-8001-000000000001. Ids still count up in their last digits and restart on reset; a test that pinned an old errorId needs the new one. (RYS-1593)

2. The test fixtures seed transitioningToStatus: null. The four okta_* fixtures under sim/testdata/scenarios/ seeded an empty string for a user with no transition in progress, which PUT /api/v1/users/{id} and GET /api/v1/groups/{groupId}/users echoed back. They now seed null, as the twin’s own lifecycle operations write it. (RYS-1600)

3. Offboarding a user removes their app access, as Okta does. Deactivating a user, by POST /api/v1/users/{id}/lifecycle/deactivate or a first DELETE, and purging one remove their app assignments, direct and group-derived: GET /api/v1/apps/{appId}/users/{userId} answers 404 E0000007 and the app’s user list leaves them out. A group assigned to an app afterwards gives a deactivated member no access, adding a deactivated user to a group is refused 403 E0000038, and activating the user again restores their group-derived access but not a direct assignment. Each was measured against a live Okta org. (RYS-1847)

4. Deleting a group, an app or a user removes what names it, as Okta does. After DELETE /api/v1/groups/{groupId}, GET /api/v1/apps/{appId}/groups/{groupId} answers 404 E0000007, and the app access members held only through that group goes with it. A direct assignment, or access held through another assigned group, stays. Deleting an app removes its user and group assignments, and purging a user removes their enrolled factors. The group behavior was measured against a live Okta org. (RYS-1857)

5. A JSON Patch on an app’s group assignment is applied. PATCH /api/v1/apps/{appId}/groups/{groupId} with an array such as [{"op":"replace","path":"/priority","value":9}] now changes the assignment: the answer and a later GET carry the replaced priority, profile or profile attribute, and an empty array changes nothing. Before, the twin answered 200 and left the assignment as it was. (RYS-1850)

6. A user write must carry the profile properties Okta requires. POST /api/v1/users and PUT /api/v1/users/{id} refuse a profile that omits, nulls or blanks login, firstName, lastName or email with 400 E0000001 and one "<property>: The field cannot be left blank" cause per such property, plus Okta’s "login: Username must be in the form of an email address" when a create has no login. POST /api/v1/users/{id} may still leave them out, but refuses nulling or blanking one. Before, the twin created a user without firstName, lastName or email, replaced one without firstName or lastName, and let a partial update null either name. (RYS-1850)

7. Every link in design_studio leads back to the twin. Seeded users’ and groups’ _links, on every route that answers them, are on the origin you reached the twin on, as the links the twin builds already were. They named a host on Okta’s own domain, so following one left the twin; a test that resolved a link’s path against its org URL can now follow the link as it is. The four okta_* test fixtures under sim/testdata/scenarios/ moved the same way. (RYS-1851)

8. Listed users no longer carry realmId. GET /api/v1/users answers each user without it, as Okta does and as GET /api/v1/users/{id} already did. Before, a user given a realmId by a write or a seed showed it in the list and not in its own read. Measured against Okta’s reference org, whose lists and reads carry no realmId. (RYS-1850)

9. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.1 — 2026-10-01

1. A local Okta Management API. okta-twin serves 49 routes of Okta’s Management API — users and their lifecycle, groups and memberships, bookmark applications with their user and group assignments, password operations and OKTA software-TOTP factors — plus the /_rystic/ control plane for reset, seeding and the clock. It accepts any non-empty Authorization header and never calls Okta, so no activation email is sent and no real directory changes. (RYS-1384)

2. Okta’s user lifecycle, two-step delete included. Users move through STAGED, ACTIVE, SUSPENDED and DEPROVISIONED by the lifecycle routes. A first DELETE deactivates a user and a second purges it; a plain GET /api/v1/users leaves DEPROVISIONED users out while search and filter include them; and a profile update on a DEPROVISIONED user answers 403 E0000038, as an org with deactivated-profile edits turned off does. (RYS-1065)

3. Password operations and software-TOTP factors. Reset, change and expire a password, reactivate a user and reset their factors; list a user’s factor catalog, and enroll, read, activate, verify and delete an OKTA token:software:totp factor with codes computed from its shared secret. Other factor types enroll but do not activate, and OAuth/OIDC and browser sign-in are not served. (RYS-1135)

4. One shipped world, design_studio. Website Design Contractors’ Okta org: 36 users (33 ACTIVE, three DEPROVISIONED ex-staff) in ten groups, Everyone included, each profile carrying title, department and manager. Free boots it and POST /_rystic/reset returns to it; Pro and Enterprise boot an empty org unless --scenario design_studio names it. (RYS-1177)

5. Measured against a live Okta org. The 2026-10-01 full-suite round matched 143 of 143 probes against an Okta Integrator Free Plan org. HOWTO.md states what the suite leaves out and the differences this release ships with. (RYS-1384)

Linear

v0.0.5 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. linear_sprint_board plays a timeline. Over the four hours after the pinned clock, Hana replies on ENG-103 and moves it to Done, Deploy Bot attaches a production deploy to it, Tomas starts ENG-102 and Yuki files a Backlog follow-up, each through POST /graphql under an API key the world binds to that person; advance the clock to watch the sprint move. (RYS-2459)

4. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

5. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

6. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.4 — 2026-10-11

1. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

2. The docs say what an empty workspace’s viewer answers. Booted without --scenario, the twin answers viewer with its placeholder user until you seed a person; the plans section said it was refused. (RYS-2401)

v0.0.3 — 2026-10-11

1. Free runs every control route but latency and fault injection. On Free, scenarios, seeding, the clock, inspect, the state UI and replay now work as on Pro, and the twin boots empty without --scenario. /_rystic/network and /_rystic/ws-drop answer 403 with "feature":"faults" and stay Pro and Enterprise. (RYS-2400)

v0.0.2 — 2026-10-11

1. An issue and a comment never share an id. Each kind of record the twin creates draws its ids from its own range: the first issue you file is 554dd3a1-3e25-42f1-8000-000000000001 and the first comment 925e28d1-dad3-4fd4-8000-000000000001, where both were 00000001-0000-4000-8001-000000000001. Ids still count up in their last digits and restart on reset; a test that pinned an old id needs the new one. (RYS-1593)

2. Introspection answers each argument’s type. __type’s fields { args } now carry type as the specification nests it (kind, name, ofType), so a client that reads argument signatures, such as args { name type { kind name ofType { kind name } } }, gets them instead of a validation error. (RYS-1604)

3. Nested lists answer the records that name them. An issue’s parent, children, cycle, project, labels, relations and inverseRelations, a cycle’s, label’s and project’s issues, a project’s teams, a team’s projects, a user’s assignedIssues, and the organization’s teams and users now list what the workspace holds, where they answered empty or null. An issue filed with a parentId or labelIds, or updated to one, shows up under its parent’s children and each label’s issues, and a new issue’s creator reads the caller. issueCreate takes the parent by UUID or by identifier such as ENG-102; issueUpdate still drops an identifier, so name the parent by its UUID there. (RYS-1909)

4. viewer answers in a world with no scenario, and a seed names its caller under member. A twin started without a scenario resolves its caller, a placeholder user with an empty name, so viewer answers a user instead of an error. A world or a seed names the person viewer answers by keying that state_user record member, its id its own; every shipped world does. A seed that keys none gets the placeholder, where viewer used to answer the user marked isMe. (RYS-1911)

5. The guide lists what the twin serves and what it does not, from the model. HOWTO.md and the docs page carry the served operations and the known gaps generated from the twin’s model and its open issues: the schema operations not served, the non-null fields the model does not declare, the branches the fidelity suite does not measure, what the model leaves out, and the known differences from Linear. They also say how to seed the person viewer answers: a state_user keyed member. (RYS-1918)

6. A JSON field or a small payload object the twin does not model no longer fails the response. reactionData, Team.securitySettings and searchIssues’ archivePayload answer an empty value where they answered Cannot return null for non-nullable field …, so @linear/sdk’s issues(), issue(id), createIssue, updateIssue, createComment and searchIssues return data. teams(), projects() and createProject still fail on Team.visibility and Project.status. (RYS-1873)

7. Malformed requests are refused before they run, as Linear refuses them. A missing required variable now answers 400 BAD_USER_INPUT, a variable whose type does not fit its argument ($id: ID! where String! is expected) 400 GRAPHQL_VALIDATION_FAILED, a document with several operations and no operationName 400 INPUT_ERROR, a subscription 400 with “Cannot query field … on type “Subscription"", and a JSON-array batch body 400 BAD_REQUEST “Operation batching disabled.”. Before, each one executed or answered a different error. (RYS-1881)

8. attachment(id:) answers Linear’s not-found error. Asking for an attachment that does not exist now answers INPUT_ERROR with statusCode 400, the message Entity not found: Attachment: could not find by url. and Could not find referenced attachment with this url., as Linear does, instead of an INVALID_INPUT “Argument Validation Error”. (RYS-1878)

9. A request without Authorization is refused before it runs. A GraphQL request with no Authorization header now answers 401 with Linear’s AUTHENTICATION_ERROR error before any field resolves, so a refused mutation writes nothing; it used to run as the world’s caller. An empty Authorization header gets the same refusal, which is the twin’s own: Linear’s answer to an empty header is not measured. Any non-empty value, a bare key or a Bearer token, is still accepted, so a test that sends no header now needs a placeholder key. (RYS-1920)

10. Introspection answers each field’s type and an input object’s fields. __type’s fields now carry type (kind, name, ofType), and __type(name: "IssueFilter") { inputFields { name type { kind name } } } lists an input object’s fields, instead of a validation error. (RYS-1882)

v0.0.1 — 2026-10-01

1. A local Linear for your agent’s tests. The first release of the Linear twin: 58 GraphQL operations on Linear’s one endpoint, POST /graphql — issues (create, update, archive, unarchive, delete, search), comments, labels, relations, projects with milestones and status updates, documents and attachments, and read-only teams, users, workflow states, cycles and the organization — served from a model validated against the real Linear API. Point your client’s API URL at http://localhost:8080/graphql (apiUrl in @linear/sdk) and your existing queries and mutations run against it unchanged. (RYS-1619)

2. Five named workspaces, and the one your test needs. --scenario linear_sprint_board boots an engineering team on the day cycle 7 closes — six people, six workflow states, three labels, eight issues with comments, relations and attachments — and is the world Free boots. linear_triage_inbox holds five untriaged support issues, linear_roadmap_quarter three projects with milestones and status updates, linear_solo_workspace one person and one team, and linear_archive_vault archived and trashed records; SCENARIOS.md says what each is for. On Pro and Enterprise, POST /_rystic/seed lands teams, people, workflow states, cycles and any issue, comment, label, project or document directly. POST /_rystic/reset rewinds the id sequence and the clock, so two identical runs give byte-identical issues down to id, identifier, number and createdAt. (RYS-1619)

3. It never reaches the network, and it needs no key. Any Authorization value is accepted, as a bare API key or a Bearer token, and the twin dials nothing: no test issue lands in a real workspace and no webhook fires. Not in this release, on purpose: workspace administration (creating teams, inviting users, workflow and cycle settings), integrations, OAuth applications, webhooks, billing and initiatives. A query for any of them answers GRAPHQL_VALIDATION_FAILED rather than empty data. (RYS-1619)

4. What is measured, and what is not. Fidelity is scored differentially against the real Linear API, per response field, not by eyeball: the last full-suite round matched 64 of 71 probes on 2026-10-01, with 2 more inconclusive, on a 73-probe suite. That is an early number and this release ships it as-is. An issue read resolves its team, workflow state, assignee and comments, but driving the twin as an agent would found differences the score does not show, listed in HOWTO.md under Limitations: some non-null fields (Issue.priorityLabel, Issue.branchName, Project.state) fail the whole response; issue.labels and issue.attachments answer empty; a new issue without a stateId has no state; a new issue in a world is numbered from 1; issues ignores filter; and __schema introspection is refused. Each release states its own number. (RYS-1619)

Stripe

v0.0.11 — 2026-10-12

1. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

2. Hosted Checkout completes subscription sessions. Subscribing on a subscription-mode session’s page creates the customer and a subscription with the session’s prices, quantities and subscription_data[metadata], completes the session and redirects to success_url, sending customer.created, customer.subscription.created and checkout.session.completed to your registered endpoints in that order. Payment and setup sessions still answer 501. (RYS-2545)

3. A subscription ends at its cancel_at. Once the twin’s clock reaches a subscription’s cancel_at (set through the API or the customer portal), the subscription reads canceled with ended_at set and customer.subscription.deleted goes to your registered endpoints, so a POST /_rystic/clock advance past it plays out the cancellation. (RYS-2545)

v0.0.10 — 2026-10-12

1. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

2. Webhook endpoints can receive their events. Boot with RYSTIC_WEBHOOK_DELIVERY=on and every event your requests trigger is POSTed to each enabled endpoint registered through POST /v1/webhook_endpoints whose enabled_events names it or *, signed with that endpoint’s secret in Stripe-Signature at wall-clock time so stripe.webhooks.constructEvent accepts it however the twin’s clock is pinned; without the variable nothing is POSTed. (RYS-2421, RYS-1463)

3. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

4. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

5. A Checkout Session’s url opens the twin’s hosted Checkout page. url now leads back to the twin instead of checkout.stripe.com, and the page shows the session’s line items, total and email with a link back to cancel_url. Submitting it is not simulated yet: it answers 501 and the session stays open. (RYS-1463)

6. GET /v1/events lists the events your requests trigger. Creating a customer, a charge or any other object that triggers an event now also writes that event to /v1/events, under the same id its webhook delivery carries, so GET /v1/events and GET /v1/events/{id} return it beside any seeded events. (RYS-2460)

7. A world can open a dispute. POST /_dispute opens a dispute on a captured charge, the way a cardholder’s bank does: the charge reads disputed, a refund is refused with charge_disputed, and charge.dispute.created reaches the egress log and every endpoint registered for it. A world’s timeline schedules it like any other call. (RYS-2461)

8. Products, prices, subscriptions, customer portal sessions and meter events. The twin serves 14 more Stripe routes: create and retrieve a product; create, retrieve and list prices; create, retrieve, update, cancel, list and search subscriptions; update a subscription item; create a customer portal session and a billing meter event. A subscription’s create, update and cancel emit customer.subscription.created, .updated and .deleted. A portal session’s url leads back to the twin, which serves no portal page yet. (RYS-1463)

9. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

10. Webhook signatures can follow a shifted receiver clock. POST /_rystic/clock {"wall_offset_seconds": N} signs every webhook delivery’s Stripe-Signature t= N seconds past the wall clock, so a receiver whose own clock you moved forward (as sandbox clock -advance does) still accepts it; 0 or /_rystic/reset puts it back. (RYS-2538)

11. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

12. A customer portal session’s url opens the twin’s customer portal. url leads back to the twin at /p/session?secret=…, which lists the customer’s subscriptions with their seats and renewal date. Changing seats, cancelling at the end of the billing period (cancel_at set, cancel_at_period_end left false, as Stripe’s portal does) and taking a cancellation back each update the subscription and send customer.subscription.updated to your registered webhook endpoints. (RYS-2544)

v0.0.9 — 2026-10-11

1. check.sh fails fast on a port that never answers. Its port check and boot wait give each /_rystic/version probe two seconds, so an address where something accepts connections but never replies fails the check with a message instead of hanging. (RYS-1444)

2. Answers carry the fields Stripe’s API reference fixes. Where a response would leave out, or send null for, a field the reference fixes for that route and status (a required constant such as object, a required field’s declared default, a variant’s tag), the twin now fills it in. (RYS-1905)

3. Line items are built from the request’s line_items. GET /v1/checkout/sessions/{session}/line_items and GET /v1/payment_links/{payment_link}/line_items list one line item per line_items element of the create, in request order, each with its own li_ id, the element’s quantity, the product name as its description, a Price (minted from price_data, inactive and one-time), and amount_subtotal equal to the unit amount times the quantity. On either list, a line naming an existing Price carries that Price with every field a Stripe Price requires. The twin holds no Prices, so the Price’s product and creation time come from its id alone, the same on every session and link that names it, and the rest are defaults: active, one-time, per-unit, in the session’s or link’s currency (usd when the create gives none). Its unit amount stays unknown, so the line’s amounts are 0. A session no longer collapses its lines into one, or answers a null currency when every line names a Price. A payment link no longer answers the id li_unknown or amounts of 0 on a line built from price_data, and neither list answers a Price that is only an id. (RYS-483)

4. check.sh gives each run its own twin log. The twin’s log is no longer the shared /tmp/stripe-twin.log: each run writes it to a path of its own, so two checks running at once on one host no longer overwrite each other’s log or report a failure from the other’s. When the check leaves the twin running, its last line prints the log’s path; when it stops the twin, it removes the log. (RYS-1951)

v0.0.8 — 2026-09-30

1. Charge lists include the full charge details. GET /v1/charges now includes the 24 fields previously available only when retrieving an individual charge, including billing details, payment-method details, outcome, and nullable references. Stored details are preserved, so callers can inspect charges directly from list results.

2. Retries reuse the original response. Repeating a POST with the same Idempotency-Key and parameters returns the original response without creating another object. Reusing the key with different parameters returns 400 idempotency_error. (RYS-1241)

3. Simulator limitations are easier to find. The HOWTO now explains unsupported behavior, incomplete object shapes, missing error fields, and scenario-clock differences, and the release notes point to it for current limitations. (RYS-1239)

4. Stripe-compatible errors and response headers. Unknown URLs and trailing slashes now return Stripe’s invalid-request envelope. Supported routes include Request-Id and Stripe-Version, and echo a pinned Stripe-Version request header. (RYS-1245)

5. Full list objects and successful-card seeds. PaymentIntent, refund and customer list items retain their full object fields. Seeded PaymentIntent reads include nullable fields present on created records, and customer list projections preserve explicit nulls. Successful card charges in the scenario pack include synthetic payment-method, outcome and balance-transaction details. PaymentIntent confirmation records card details and an authorized outcome on its charge. Oracle key-set probes check list items, member reads, and seeded records. (RYS-1242)

6. Expand related objects on reads. Charge and PaymentIntent retrieve/list routes and PaymentMethod retrieve accept expand[] for their modeled links. Nested paths, multiple paths and list expansions return canonical related objects. Invalid paths return 400 before the handler runs. Null references stay null. Expansion on other routes is not supported. (RYS-1240)

7. Reference

   Immediate test-card declines

   Charge creation and PaymentIntent creation/confirmation recognize the measured immediate-decline test inputs and return HTTP 402 card errors with the matching code, decline code, message, parameter, and input-specific advice/network codes. The error includes synthetic request/charge identifiers and the measured PaymentMethod shape where applicable. A failed intent retains its requires_payment_method status and last_payment_error for subsequent reads.

   The probe generator supports service-declared negative body values and request headers. It measures refusal responses separately from optional state readbacks and keeps cleanup for prerequisites. A valid confirmation retry verifies that the persisted error clears before successful state is stored. Conditional decline-after-attachment inputs, failed-charge projection, and retry-limit cancellation remain outside this closure. (RYS-1243)

8. Reference

   Parameter validation

   Invalid amount syntax, malformed customer email and webhook settings, oversized metadata, missing token/customer references, and conflicting payment settings return measured Stripe errors before successful writes. Charge currency is normalized to lowercase. Missing-source errors precede missing-amount errors, and missing parameters and error links use the measured response fields.

   Schema-derived probes independently exercise type, format, bounds, enum, map-key/value, unknown-parameter and missing-reference cases. Bounds that the oracle accepts remain success witnesses: list limits outside 1–100 are clamped, while non-integer limits and created-time bounds are rejected. Complete error key sets distinguish absent fields from null fields. These witnesses do not establish validation of every Stripe parameter or every currency’s minimum. Repeated scalar query values use the last supplied value consistently for validation, pagination and created-time filtering. A scoped live receipt and seeded timestamp regression tests cover both orderings of duplicate inputs. (RYS-1244)

9. The state UI shows the account as the Stripe Dashboard. On Pro and Enterprise, /_rystic/ui opens a live Dashboard view of the twin — Home charts, payments, refunds, customers, payment links, Checkout Sessions, webhooks and events — where you can refund, capture, cancel, edit customers, manage payment links and webhook endpoints and expire sessions through the twin’s own API, beside Your integration, Webhook egress and Clock cards. (RYS-1374)

v0.0.7 — 2026-09-26

1. The guide starts from an API key and says what each plan reaches. HOWTO.md now opens with rystic login rys_…, says what Free, Pro and Enterprise boot and which control-plane routes each answers, and lists PaymentIntent capture among the 50 routes. check.sh finds the API key rystic login stored as well as a license file, looked up in the CLI’s order, and rystic features marks the features and commands that need Pro or Enterprise. (RYS-1204)

v0.0.6 — 2026-09-25

1. A new world, design_studio, now the default. --scenario design_studio boots Website Design Contractors’ own account: 30 clients as customers, 269 charges since November 2024 each naming its invoice, a declined card paid on a replacement, a refund, a dispute, a bank debit still pending, and seven unpaid invoices as open intents, for the same clients, invoice numbers and dates the studio’s Slack, Resend, PayPal and Lob worlds hold. A lease that grants no scenarios boots it instead of customer_with_card. (RYS-1171)

2. Only design_studio ships as a named scenario. The older scenarios are now test-only fixtures and are no longer accepted by --scenario, RYSTIC_SCENARIO, or POST /_rystic/scenario. Tests and evaluations can load their unchanged register maps and clocks from sim/testdata/scenarios/ through the control plane. (RYS-1177)

3. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

v0.0.5 — 2026-09-23

1. A free edition. stripe-twin now has a free download: no license, one fixed world (customer_with_card) with reads and writes, and no control plane. Get it from https://www.rystic.ai/dl/free/stripe-twin ; the licensing docs’ free edition section says exactly what is in and out. (RYS-787)

v0.0.4 — 2026-09-21

1. Protected runtime contract 9. A trusted environment harness can require a private gateway credential on every request, including administrative routes. This lets the released Stripe HTTP twin serve as the protected auxiliary backend in MCP-backed Slack environments without exposing direct twin controls to the agent.

The sealed Stripe model and scenario pack are unchanged from v0.0.3. This release updates the shared runtime; it makes no new Stripe MCP compatibility or API-fidelity claim. Released multi-episode qualification is recorded separately from package availability.

v0.0.3 — 2026-09-14

1. A fourteenth named world, busy_account_xxl. busy_account_xl proves a client follows a cursor. This one asks the next question: whether an answer still comes out right when it has to be assembled from many pages and many objects at once. Same account shape at 2011 live customers — 2305 payment intents, 2274 charges, 361 refunds, 535 checkout sessions, 158 payment links, 123 setup intents, 505 saved cards, 14 endpoints — with four things the smaller worlds do not hold: 81 charged-back charges whose owners carry the refunded money on their other orders, so the account’s net refunded figure appears on no single page; six customers holding a run of declines, with a unique worst; 240 live subscribers across four plans, sold as completed mode=subscription Checkout Sessions, beside one-time sessions and expired subscription checkouts at the same prices as decoys; and billing addresses, so “every customer in country X” is a read of all 2011 customers, which no Stripe list route filters on. It boots in about 0.3 seconds and holds about 75 MiB. ./stripe-twin --scenario busy_account_xxl, or curl -X POST localhost:8080/_rystic/scenario -d '{"name":"busy_account_xxl"}'.

2. busy_account_xl is now big enough to need paging. Stripe serves at most 100 records per list request, and the world shipped in v0.0.2 held fewer than that in every collection but customers — so a client could read the whole account with one ?limit=100 call per collection and never touch has_more or starting_after. It is now 1011 live customers, 1083 payment intents, 1047 charges, 168 refunds, 158 checkout sessions, 134 payment links and 131 setup intents, so every one of those answers has_more: true at limit=100 and the rest of the account is only reachable by cursor. (Webhook endpoints stay at 14, because Stripe caps an account at 16.) Everything the smaller world was authored for survives at the new size, with the same ids: busy_account’s whole cast, saved cards whose last payment sits at 45, 20 or 7 days so an overdue report moves with its window, unpaid intents either side of 1-hour, 6-hour and 48-hour cutoffs, authorized holds that are cancelable but not unpaid, duplicate-shaped charge groups straddling 7-, 14- and 30-day reporting windows, open carts either side of 10, 20 and 60 minutes, and live payment links either side of 100, 400, 2000 and 5000 cents. Point a client at it when you want to find out whether your pagination, cursors and date windows are right: ./stripe-twin --scenario busy_account_xl.

3. A charged-back charge can no longer be refunded. POST /v1/refunds against a charge whose disputed is true minted a refund and returned 200, where Stripe answers 400 charge_disputed — “Charge <id> has been charged back; cannot issue a refund.” The twin now refuses it the same way, for a full refund, a partial one and a payment_intent-targeted one alike, and in the same order live does: an unknown parameter or a non-positive amount is still rejected first, and the refusal precedes the amount-exceeds-remaining check. busy_account’s ch_busy_disputed is the charge to try it on.

v0.0.2 — 2026-09-12

1. Separate authorization and capture works end to end. POST /v1/payment_intents/{intent}/capture is routed, and confirming an intent created with capture_method=manual now holds the authorization at requires_capture instead of settling it. Partial captures release the remainder, over-captures are refused with amount_too_large, and the charge goes from uncaptured to captured in place — the flow a capture-later integration actually tests.

2. confirm=true on create does what the docs show. Creating a PaymentIntent with a payment method and confirm=true — the one-call form the Stripe docs use for off-session charges — now succeeds and mints the charge, instead of answering requires_payment_method as though the card had been declined. Creating with a payment method and no confirm correctly rests at requires_confirmation.

3. A saved card belongs to its customer. Confirming a PaymentIntent with a PaymentMethod attached to a different customer is refused with Stripe’s own 400, rather than quietly charging one customer’s card against another’s intent.

4. disabled=true disables a webhook endpoint. POST /v1/webhook_endpoints/{id} with disabled=true flips status to disabled; it was accepted and ignored.

5. A thirteenth named world, busy_account_xl. busy_account is a month of traffic over eleven customers, and every question you can ask of it is answered by the first page of a list. busy_account_xl is the same account at 201 customers: the whole busy_account cast is still there, with the same ids, plus 190 more customers with mixed histories — 43 saved cards, payments spread over the last 45 days, repeat charges that straddle a 7-, 14- or 30-day reporting window, thirteen open checkout sessions and fourteen webhook endpoints over overlapping event sets. Every collection answers has_more: true on its default page, so it is the world to point a client at when you want to find out whether your pagination, your cursors and your date windows are right. Boot it like any other: ./stripe-twin --scenario busy_account_xl, or curl -X POST localhost:8080/_rystic/scenario -d '{"name":"busy_account_xl"}'.

v0.0.1 — 2026-09-11

The first release of the Stripe twin.

1. A local Stripe for your integration tests. 49 routes across 11 resources: customers, payment intents, setup intents, payment methods, charges, refunds, checkout sessions, payment links, webhook endpoints and events. Point your Stripe client’s api_base at the twin and your existing suite runs against it unchanged — the Stripe SDKs need no patching. Nothing you send it is billed, rate-limited, visible in a dashboard, or shared with whoever else on your team is using the same test-mode account.

2. It never reaches the network, and it needs no key. Any Authorization header is accepted, and the twin dials nothing — which is the point: a suite that hits api.stripe.com fails when Stripe is slow, and a suite on a shared test-mode account fails when a colleague clears it.

3. Seed the world your test needs. POST /_rystic/seed takes a register map and lands it directly, so a test starts from the records it needs instead of creating them through the API one call at a time. GET /_rystic/registers lists what this twin accepts a seed for; a register the model does not carry is refused with a status rather than silently dropped.

4. The same seed twice is the same world twice. POST /_rystic/reset empties the twin and POST /_rystic/seed-rng pins the generator, so ids repeat run to run; POST /_rystic/clock fixes the twin’s notion of now, so created on every record is a value your test chose. Two identical seed flows leave byte-identical /_rystic/inspect dumps — which is what makes a failing test reproducible rather than merely re-runnable.

5. Read back the webhooks you would have sent. Event and webhook egress is rendered into an ordered in-memory log (GET /_rystic/egress) rather than delivered, so you can assert on what would have been sent without standing up a receiver or running stripe listen.

6. See what the twin holds. /_rystic/ui serves a live view of the registers and the requests hitting them, so a test that fails on a missing record shows you the world it actually ran against.

What is measured, and what is not. Fidelity is scored differentially against real api.stripe.com in test mode, per response field, not by eyeball: the last full-suite round was 131 of 161 probes on 2026-09-04, and the suite has since grown to 175 probes. Shortfalls recorded for this release included missing doc_url and request_log_url error fields, customer deletion acknowledging without performing, and objects serializing differently across endpoints. Customer deletion has since been fixed; the other two remain. Current known limitations are listed in HOWTO.md under Limitations. Rounds are re-run daily and each release states its own number.

Not in this release. Subscriptions, products and prices are modelled in separate twins and are not part of this one; Connect, Tax and Billing are not modelled at all.

Resend

v0.0.8 — 2026-10-12

1. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

2. Webhook signatures can follow a shifted receiver clock. POST /_rystic/clock {"wall_offset_seconds": N} signs every webhook delivery N seconds past the wall clock, so a receiver whose own clock you moved forward (as sandbox clock -advance does) still accepts the svix-timestamp; 0 or /_rystic/reset puts it back. (RYS-2538)

3. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.7 — 2026-10-12

1. Registered webhooks can receive their events. Boot with RYSTIC_WEBHOOK_DELIVERY=on and each webhook event a send triggers is POSTed to every enabled webhook registered through POST /webhooks whose events names it, signed with its signing_secret in Svix headers at wall-clock time so svix’s Webhook.verify accepts it however the simulator clock is pinned; without the variable nothing is POSTed. (RYS-2421, RYS-1463)

2. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

3. Sandbox recipients bounce and complain. An immediate send whose first to recipient is bounced@resend.dev or complained@resend.dev, with or without a +label, now emits email.bounced, or email.delivered and email.complained, after email.sent, and the email reads last_event bounced or complained; under RYSTIC_WEBHOOK_DELIVERY=on each is delivered Svix-signed to the webhooks subscribed to it. A bounced email’s email.bounced and GET /emails/{email_id} carry the bounce object live Resend sends. (RYS-2419)

4. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

5. design_studio carries a timeline. As the clock moves past 2026-03-01T00:00:00Z, the world registers a billing webhook, sends Copperline Coffee’s March plan invoice, and schedules an overdue reminder to Pickford Law, moves it off a Sunday and cancels it, each a call on the twin’s own API under the world’s bound key. Those calls take the first email and webhook ids, so a test that advances the clock before sending sees its own email minted later in the sequence. (RYS-2459)

6. A world can bounce an email. POST /_bounce bounces an email that went out to any address: it reads bounced with its bounce, and email.bounced reaches the egress log and every webhook subscribed to it. A world’s timeline schedules it like any other call. (RYS-2461)

v0.0.6 — 2026-10-11

1. An email and a webhook never share an id. Each kind of record draws its ids from its own range: the first email you send is 28c9b732-cf71-466d-8000-000000000001, where it and the first webhook were both 00000001-0000-4000-8001-000000000001. Ids still count up in their last digits and restart on reset, and webhook signing secrets change the same way; a test that pinned an old id needs the new one. (RYS-1593)

2. Every route refuses a missing or malformed key the way Resend does. All ten routes check Authorization before anything else: no header answers 401 missing_api_key with “Missing API Key”, and an empty Bearer key or another scheme such as Basic abc answers 400 validation_error with “API key is invalid”, where the twin used to answer 401 with “Missing API key in the authorization header.”. GET /emails, POST /emails/{email_id}/cancel, POST /webhooks, GET /webhooks/{webhook_id} and DELETE /webhooks/{webhook_id} used to answer without a key, so a test that calls them without one now needs a placeholder key. (RYS-1285)

3. A scheduled send no longer shows an SMTP handoff. POST /emails with scheduled_at writes only its email.scheduled event to GET /_rystic/egress, since Resend hands the mail to SMTP only at the scheduled time; an immediate send still writes the handoff before email.sent. (RYS-1378)

4. A send or update with a form Content-Type is refused as Resend refuses it. POST /emails and PATCH /emails/{id} with a JSON body labelled application/x-www-form-urlencoded answer 422 with Resend’s message (Missing `to` field. and The `scheduled_at` field is required.), where the simulator answered 400 to a send and applied the update. Label JSON bodies application/json. (RYS-1190)

5. A scheduled email’s scheduled_at reads back as Resend renders it. GET /emails/{id} and GET /emails return scheduled_at in the same form as created_at, such as 2026-01-03 00:00:00.439000+00, where the simulator echoed an ISO 8601 string such as 2026-01-03T00:00:00.439Z. A test that compares the string should compare the instant. (RYS-1190)

6. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.5 — 2026-09-30

1. Scheduled email reads preserve null values. Text-only emails return html: null, and newly scheduled emails return message_id: null until their state indicates a completed send. Explicit HTML, including an empty string, and existing message identifiers are preserved. (RYS-1293)

2. Resend fidelity limitations are explicit. The HOWTO and website docs disclose missing throttling and sender-domain checks, distinguish local auth errors from measured Resend responses, and explain how to choose scheduled dates without treating initial_clock as the scenario clock. The dated fidelity result and absence of a standing daily converge round remain explicit. (RYS-1283)

3. Sent-email events include ISO timestamps, message IDs and tags. The email.sent events in GET /_rystic/egress use UTC ISO 8601 timestamps and include data.message_id and supplied tags as a name/value map, so tests can inspect these fields in the outbound event log. (RYS-1288)

4. Request admission shares a ten-per-second window across credentials, emits rate-limit headers on API responses, and returns 429 with retry-after when exhausted. The window uses real time; control-plane requests are exempt and reset restores the allowance. Daily/monthly quotas remain unmodeled. The full 39-probe live round matched and exercised 36/39, including the header and actual 429 burst probes; the three known POST/PATCH differences remain.

   Burst comparison requires an observed oracle 429 in both two-way and ThreeWay runs; an oracle that never refuses leaves the result inconclusive. Wire recording emits each burst request once, without duplicating the selected response as a synthetic exchange.

   The 36/39 rate-limit acceptance round predates the merge of RYS-1288 webhook fields. Both features and their separate live records are retained; the combined simulator is covered by local regression tests, without claiming a new combined live round.

5. Rate-limit headers arrive spelled as Resend spells them. ratelimit-limit, ratelimit-remaining, ratelimit-reset, ratelimit-policy and retry-after now reach the wire lowercase instead of as Ratelimit-Limit and friends, so a client that keys on the received header name sees the same keys it sees from Resend. (RYS-1336)

6. The state UI shows the outbox as Resend’s dashboard. On Pro and Enterprise, /_rystic/ui opens a live Resend-style view of the twin — emails with their status, events and rendered body, and webhooks with the events they would receive — where you can reschedule or cancel a scheduled email and add, edit, disable or delete webhooks through the API, beside Your program and Egress cards. (RYS-1376)

v0.0.4 — 2026-09-26

1. The guide starts from an API key, says what each plan reaches, and documents the outbound mail log. HOWTO.md now opens with rystic login rys_…, says what Free, Pro and Enterprise boot and which control-plane routes each answers, and names the five routes that answer 401 missing_api_key without a bearer key and the five that check none; SCENARIOS.md says what each plan boots. Each POST /emails writes the SMTP message and its email.sent or email.scheduled event to GET /_rystic/egress, and the guide now says so. check.sh finds the API key rystic login stored as well as a license file, looked up in the CLI’s order, and rystic features marks the features and commands that need Pro or Enterprise. (RYS-1204)

v0.0.3 — 2026-09-26

1. The fidelity number is current again. The first full-suite comparison on the 38-probe suite scored 35 of 38 against api.resend.com on 2026-09-25, and the HOWTO and site page name the three misses (content-type mismatch on sending and updating an email, and the non-object send body) with the repair that closes them. (RYS-1190)

2. Only design_studio ships as a named scenario. The older scenarios are now test-only fixtures and are no longer accepted by --scenario, RYSTIC_SCENARIO, or POST /_rystic/scenario. Tests and evaluations can load their unchanged register maps and clocks from sim/testdata/scenarios/ through the control plane. (RYS-1177)

v0.0.2 — 2026-09-25

1. The free edition is replaced by self-serve on the metered edition. A Rystic account’s token runs the metered build: rystic login rys_… once, then rystic run or docker run -e RYSTIC_TOKEN=…. It carries every scenario and control-plane route your plan includes, and bills active 30-second blocks against the plan’s allowance. The fixed-world free download and its usage report are gone. (RYS-1097)

2. A new world, design_studio, now the default. --scenario design_studio boots Website Design Contractors’ outbox: 595 emails since November 2024 (invoices, receipts, overdue reminders, a declined-card notice, a refund notice, welcome and launch notes, and one receipt bounced off a departed contact, then resent), for the same clients, invoice numbers and dates the studio’s Slack, Stripe, PayPal and Lob worlds hold. A lease that grants no scenarios boots it instead of busy_outbox. (RYS-1171)

3. The limitations now date the fidelity evidence. The HOWTO and the site page say which comparison rounds against api.resend.com stand behind the release: the 25/25 full-suite round of 2026-09-02 and the scoped rounds of 2026-09-24 that verified the 13 probes added since, with no full-suite round yet on the current 38-probe suite. The package manifest also describes the metered edition instead of the retired free edition. (RYS-1028)

v0.0.1 — 2026-09-24

1. First Resend simulator release: email lifecycle and webhook APIs, three deterministic scenarios, licensed and free archives, and customer quickstart. Includes measured validation and idempotency behavior; asynchronous delivery and documented fidelity limitations remain outside the release claim. (RYS-1028)

2. Resend email and webhook workflows, locally. The first package provides ten stateful API routes, three embedded scenarios, a smoke check, and a quickstart. Forward email paging now traverses all records. No email or webhook is delivered; scheduling, validation, collection and fixture limitations are documented explicitly. (RYS-1028)

Clerk

v0.0.2 — 2026-10-12

1. clerk_acme_tenant plays a timeline. Its backend, bound to sk_test_acme_backend, updates Sam’s metadata two hours after the pinned clock, creates Priya Raman a day in, promotes Yuki to admin, moves the organization to the scale plan on day three and removes Iris on day five, all through the Backend API; advance the clock to watch the tenant change. (RYS-2459)

2. A seeded user, organization or membership sends its created webhook. A record a world’s timeline seed event or a bare POST /_rystic/seed creates now sends user.created, organization.created or organizationMembership.created, as the create operation does, to the egress log and any configured webhook endpoint. A world’s starting snapshot sends none. (RYS-2508)

3. Session tokens and webhooks can follow a shifted app clock. POST /_rystic/clock {"wall_offset_seconds": N} stamps session JWT iat, nbf and exp and the webhook svix-timestamp N seconds past the wall clock, so an app whose own clock you moved forward (as sandbox clock -advance does) still accepts them; 0 or /_rystic/reset puts it back. (RYS-2538)

4. Every Backend API call without a secret key is refused as Clerk refuses it. A request with no Authorization header now answers 401 with errors[0].code = authorization_header_format_invalid on every operation, ahead of the operation’s own checks. DELETE /v1/organizations/{id} and PATCH /v1/organizations/{id}/memberships/{user_id} used to succeed without a key, and other operations answered with differing authentication_invalid bodies. (RYS-2532)

v0.0.1 — 2026-10-11

1. A local Clerk for your app’s users, organizations and sign-in. The first release of the Clerk twin: the 20 Backend API operations on users and their metadata, organizations with their metadata and memberships, at Clerk-API-Version: 2026-05-12, served from a model validated against a live Clerk development instance, and a browser companion that serves a lookalike clerk.js so a @clerk/nextjs app signs users in against the same state. It runs on Pro and Enterprise. Point @clerk/backend at it with any sk_ key (HOWTO.md shows how); no email is sent and no real instance changes. (RYS-1315, RYS-1234, RYS-2412)

2. Users and their metadata, as Clerk keeps them. POST /v1/users stores each email address in lowercase, GET /v1/users?email_address= finds a user by any letter case of their address, and an address that differs from a taken one only in case answers 422 form_identifier_exists; a malformed one answers 422 form_param_format_invalid. GET /v1/users refuses an order_by that names no sortable field with 422 form_param_value_invalid. PATCH and PUT /v1/users/{user_id}/metadata merge and replace metadata, and DELETE /v1/users/{user_id} removes the user’s organization memberships. Every image_url and profile_image_url leads to a PNG the twin serves under /preview/. (RYS-1858, RYS-1899, RYS-1900)

3. Organizations, their metadata and their members. An organization created with created_by lists its creator as an org:admin member right after the create, and include_members_count=true counts them. PATCH /v1/organizations/{organization_id}/metadata deep-merges public_metadata and private_metadata, removing a key set to null, and PUT replaces each field it names whole. Writes and lists answer with the keys Clerk’s answers carry. (RYS-1895, RYS-1899, RYS-1909)

4. Clerk-API-Version is checked on every route and echoed. 2021-02-05, 2024-10-01, 2025-04-10, 2025-11-10 and 2026-05-12 (the default) are accepted and echoed in clerk-api-version, and any other value answers 400 api_version_invalid. At 2026-05-12, metadata sent to PATCH /v1/users/{user_id} or PATCH /v1/organizations/{organization_id} answers 422 form_param_deprecated, as Clerk does: write it through the /metadata routes. (RYS-1914)

5. A browser sign-in for @clerk/nextjs. Point NEXT_PUBLIC_CLERK_JS_URL and NEXT_PUBLIC_CLERK_UI_URL at the twin’s /clerk.js and /clerk-ui.js and your app gets email sign-in and sign-up with consent, Continue with GitHub and Continue with Google buttons that sign in local test identities, organization creation and selection, and member invitation, role changes and removal; signing in as an invited address joins its organization with no email sent. Sessions are RS256 tokens stamped on the wall clock your site verifies them against, and the SDK middleware’s handshake is answered by the twin, so a sandboxed site never leaves it. Boot the twin with your own RSA key, your site’s origin and its own origin; GET /_twin/config gives the publishable key, the public PEM and the proxy URL. (RYS-1234, RYS-1475, RYS-2413, RYS-2414)

6. Webhooks Clerk would send, signed with Svix headers. Every user write, organization create, update and delete, and membership write, from the Backend API or the browser, records user.*, organization.* or organizationMembership.* in GET /_rystic/egress; the organization /metadata routes record none. Boot with CLERK_TWIN_WEBHOOK_URL and a whsec_ CLERK_TWIN_WEBHOOK_SECRET and each is also delivered, its svix-timestamp on the wall clock so your receiver’s five-minute window holds however long the twin sat idle. A failed delivery never undoes the write. Event shapes follow Clerk’s documentation and are not measured against live deliveries. (RYS-1317, RYS-2413)

7. Five shipped worlds. --scenario clerk_acme_tenant boots Acme Robotics: five users in one organization, two pending invitations and three live sessions. clerk_holdco_orgs holds one identity across three organizations, clerk_invite_backlog an organization at its ten-seat cap with eight invitations pending, clerk_session_sweep six sessions from lapsed to live, and clerk_solo_founder one user and her organization; SCENARIOS.md says what each is for. Without --scenario the twin boots an empty instance, POST /_rystic/seed lands users, organizations, memberships, sessions and invitations directly, and POST /_rystic/reset rewinds the id sequence, so two identical runs from a pinned clock give byte-identical users and organizations. (RYS-1315, RYS-2412)

8. Measured against a live Clerk development instance. The 2026-10-07 full-suite round matched 100 of 100 Backend API probes, with 0 inconclusive. HOWTO.md states what the suite leaves out and the differences this release ships with, each with its ticket: typed query parameters are not validated (RYS-1906), responses carry no x-clerk-trace-id header (RYS-1912), an unserved route answers a plain 404, not Clerk’s resource_not_found (RYS-1913), and deleting an organization or changing a membership’s role checks no secret key. (RYS-2412)

Notion

v0.0.8 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. notion_task_tracker plays a timeline. Over the three hours after the pinned clock, Rae ticks a to-do and moves a row to In review, Theo comments and files a new row, and Nour marks the retention policy Done, each through the API under a token the world binds to them; advance the clock to watch the sprint move. (RYS-2459)

4. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

5. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

6. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.7 — 2026-10-11

1. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

2. A file upload’s filename may be up to 900 characters. POST /v1/file_uploads counts a filename’s length in characters, as Notion measures it, so an accented name of 900 characters or fewer is accepted even when it runs past 900 bytes. (RYS-2099)

3. Requests Notion refuses are refused, in Notion’s order. The twin answers 400 validation_error where Notion does, before looking anything up: a malformed id in the path of GET /v1/blocks/{id}/children, GET /v1/data_sources/{id}/templates and PATCH /v1/pages/{id}/markdown; a non-numeric page_size; an unknown filter member, mixed timestamp and property filter, unknown operator or mistyped operand in a data source query; a malformed parent id, or a template_id template with no id, on POST /v1/pages; an executable file type, or a filename over the limit, on POST /v1/file_uploads; and a move to a destination the integration can’t reach (tool_error_code: destination_unavailable). GET /v1/data_sources/{id} accepts a dashless id, and its 404, like a database create’s, carries additional_data.integration_id and request_id. (RYS-2099)

v0.0.6 — 2026-10-11

1. A seeded app.notion.com page URL passes the seed gate. app.notion.com is declared Notion’s web host (pipeline_policy.json host_roles): the twin hands such a URL out as written, never rebased, and a seed carrying one lands under RYSTIC_SEED_GATE=reject where it was refused as an undeclared host of the service. Page, database and data-source url values the twin builds still sit on www.notion.so, which Notion no longer uses; that is RYS-2386. (RYS-1910)

v0.0.5 — 2026-10-10

1. A sent file upload drops its upload URL, and completing a single-part upload is refused. After a single_part send leaves an upload uploaded, the send’s answer and every read of the upload leave out upload_url and complete_url, as Notion’s do. Completing a single_part upload answers 400 validation_error, “One or more parts must be uploaded before completing the file upload”, where the twin answered 200. (RYS-2099)

2. Three more worlds for the Tier 2 surface. notion_page_tree boots a page tree with page and data source parents to move pages between. notion_template_board boots a Tickets data source with five templates, one of them the default, beside a data source with none. notion_attachments boots a page with image and file blocks and an asset library whose files property holds files, ready for an upload to attach. (RYS-2102)

3. A moved page leaves its old parent and joins the new one. After POST /v1/pages/{page_id}/move, the old parent’s GET /v1/blocks/{id}/children no longer lists the page, and its has_children updates. The new parent page lists the page as its child_page block. A page moved into a data source drops out of its page parent’s children and appears in the data source’s query. (RYS-2349)

4. Templates refuse what Notion refuses and apply their content. POST /v1/pages with a template beside children, content or markdown, or with {"type": "default"} under a data source that has no default template, now answers 400 validation_error with Notion’s message. A page created from a template, or given a template by PATCH /v1/pages/{page_id}, reads back the template’s content as its children. A PATCH adds that content after the page’s existing children. (RYS-2350, RYS-2355)

5. Attached file uploads read back as files the twin serves. An upload attached as a file, image, PDF, audio or video block, a page icon or cover, or a files property now reads back as {"type": "file", "file": {"url", "expiry_time"}}. The URL serves the uploaded bytes from the twin until expiry_time, one hour after each read. Attaching an upload clears its own expiry_time. GET /v1/file_uploads lists only the calling connection’s uploads, newest first. An upload never attached reads expired once its hour passes on the twin’s clock. (RYS-2351, RYS-2356, RYS-2360)

6. External imports and async tasks complete. An external_url file upload answers pending, as Notion’s does, and reads uploaded with a successful file_import_result on its first GET /v1/file_uploads/{id}. Its file is the twin’s placeholder; the twin never fetches the URL. A POST /v1/pages or PATCH /v1/pages/{page_id}/markdown sent with allow_async: true answers a queued task with poll_after_seconds: 2. Its first GET /v1/async_tasks/{task_id} reads succeeded with the result, where it used to answer 404. (RYS-2352, RYS-2347)

7. An import’s time reads as Notion writes it. A completed external_url file upload’s file_import_result.imported_time carries a +00:00 offset, as Notion’s does, where it used to end in Z. A client that compares or parses the stamp as text now sees Notion’s form. (RYS-2370)

8. A seeded comment reads back without attachments. A comment a shipped world seeds, such as notion_review_thread’s, now answers GET /v1/comments and GET /v1/comments/{comment_id} with no attachments key, as Notion’s comments and the ones POST /v1/comments creates do. It used to carry attachments: []. (RYS-2228)

9. A seeded comment’s user mention carries the user. The mention in notion_review_thread’s reply now reads back with the mentioned user’s name, avatar_url and type, as Notion answers a user mention in a comment, beside plain_text @Review Bot. It used to carry only the user’s object and id. (RYS-2286)

10. A shipped world’s pages carry Notion’s url. Every page a scenario seeds now reads back with a url on https://app.notion.com/p/, its title’s words and its bare id, as Notion writes it, and a seeded page mention’s href is the page’s bare https://app.notion.com/p/ url. They used to point at www.notion.so. (RYS-2294)

11. A user mentioned in a comment reads back as the user. A rich_text user mention written through POST /v1/comments or PATCH /v1/comments/{comment_id} answers and reads back with the mentioned user’s object, name, avatar_url and type (bot: {} or person), and plain_text @<name>, as Notion does. It used to echo the request’s {id} with empty plain_text. (RYS-2286)

12. A comment’s markdown turns a mention-user tag into a mention. <mention-user url="<user id>">…</mention-user> in a comment’s markdown, its url a bare id or user://<id>, becomes a user mention of that user, the tag’s text dropped: a person resolves to the user and @<name>, a bot to {object, id} and @Anonymous, as Notion answers them. It used to stay literal text. (RYS-2287)

13. Every comment 404 names the integration. POST /v1/comments with an unknown discussion_id, parent.page_id or parent.block_id, and GET /v1/comments with an unknown block_id, answer 404 object_not_found with additional_data.integration_id, the calling bot’s id, as Notion does; a comment on an unknown block is refused, where it used to be created. (RYS-2288)

14. Page markdown refuses a database or block id as Notion does. PATCH /v1/pages/{id}/markdown through a database’s id answers 400 validation_error “Provided ID is a database, not a page. Use the retrieve database API instead.”, and through a block that is not a page, 400 naming the page that contains it, both with additional_data.tool_error_code invalid_input. GET through a database’s id answers the same 400, while a block id still renders its subtree. They used to answer 404, or render the database. (RYS-2290)

15. A seeded child database renders like a created one in page markdown. GET /v1/pages/{page_id}/markdown renders every child database with inline and data-source-url read off the database, so notion_team_wiki’s Meeting Notes reads inline="true" data-source-url="collection://…" as one POST /v1/databases creates does. (RYS-2292)

16. Blocks carry every content field Notion returns. A block written as markdown or as children reads back with a heading’s is_toggleable, a paragraph’s icon, a code block’s caption (and no color), a markdown numbered item’s list_format and a markdown file block’s name, as Notion’s do. (RYS-2293)

17. A created page’s url is on app.notion.com. A page POST /v1/pages creates, or a markdown <page> tag adds, has its url on https://app.notion.com/p/, its title’s words then its bare id, as Notion’s are. It used to point at www.notion.so. (RYS-2294)

18. Moving a page under itself is refused. POST /v1/pages/{page_id}/move with the page itself as parent.page_id answers 400 validation_error, “Parent ID must be different from the child ID: ”, with additional_data.tool_error_code source_is_destination, as Notion does. It used to answer 200. (RYS-2345)

19. The template board’s templates hold content. In notion_template_board, each of the Tickets data source’s five templates holds a heading, a paragraph and a to-do or bulleted item of its own, from Bug Report’s steps to reproduce to Customer Call Notes’ attendees. A page created from the default template or from a template_id now reads back that template’s blocks as its children, where it used to read back none. (RYS-2385)

20. Eight more routes: page moves, data source templates, async tasks and file uploads. The twin now serves POST /v1/pages/{page_id}/move, GET /v1/data_sources/{data_source_id}/templates, GET /v1/async_tasks/{task_id} and the five file upload routes, 35 operations in all, so the official JavaScript SDK’s pages.move, dataSources.listTemplates, asyncTasks.retrieve and fileUploads methods run against it. (RYS-2103)

21. A multi_part upload’s parts and /complete are unmeasured. The measuring workspace is on Notion’s Free plan, which caps a file at 5 MiB and offers no multi-part upload, so creating a multi_part upload is measured but sending its parts and POST /v1/file_uploads/{file_upload_id}/complete are built from Notion’s published spec alone. (RYS-2103)

v0.0.4 — 2026-10-10

1. User and property-item reads carry request_id. GET /v1/users/{user_id} and the single-value answer of GET /v1/pages/{page_id}/properties/{property_id} now include Notion’s top-level request_id, as every other answer does. (RYS-2289)

2. Every property a data source is created or updated with gets its own id. POST /v1/data_sources, POST /v1/databases and PATCH /v1/data_sources/{data_source_id} mint a distinct 4-character id for each new property other than the title (whose id stays title), and for the synced property a dual_property relation adds to its target, so GET /v1/pages/{page_id}/properties/{property_id}, a properties update, filter_properties and a query’s filter or sort by id reach the property the id names. Before, POST /v1/data_sources gave every property it created the same id, and the other two minted uuids. The twin’s ids are letters only; Notion’s may also hold URL-encoded punctuation. (RYS-2296)

v0.0.3 — 2026-10-09

1. A markdown update_content keeps every block’s id. PATCH /v1/pages/{page_id}/markdown with update_content edits the page’s blocks in place: every block keeps its id at any depth, the edited block’s included, so an id read before the edit still names the same block after it. Before, every block of the page got a new id. (RYS-2255)

2. A markdown replace_content_range keeps every block’s id. PATCH /v1/pages/{page_id}/markdown with replace_content_range rewrites the matched range in place: every block keeps its id at any depth, the replaced block’s included, so an id read before the edit still names the same block after it. Before, every block but a child page or database got a new id. (RYS-2259)

3. A markdown edit that would delete a child page or database is refused in Notion’s words. PATCH /v1/pages/{page_id}/markdown without allow_deleting_content answers 400 validation_error with Notion’s message, which lists each child page or database the edit would delete by title and id and says how to proceed, and with Notion’s additional_data (tool_error_code invalid_input). Before, the refusal carried a generic message and no additional_data. (RYS-2270)

4. A markdown <page> tag with no url creates a subpage. <page>Title</page> in insert_content, in an update_content, replace_content_range or replace_content edit, or in POST /v1/pages markdown creates a child page with that title where the tag stands: the page lists its child_page block, and GET /v1/pages/{id} answers it. A child page whose <page url> tag an edit moves under another block now answers that block as its parent. Before, the tag was dropped, and a moved child page kept the page as its parent. (RYS-2271)

5. A connection updates or deletes only a comment it created. PATCH and DELETE /v1/comments/{comment_id} on a comment another user or another connection created answer 404 object_not_found, as Notion’s do, and leave the comment as it was. Before, the twin rewrote or deleted any comment, a person’s included. (RYS-2285)

6. A property item list with more pages links to the next one. GET /v1/pages/{page_id}/properties/{property_id} on a title, rich_text, people or relation property with more values than page_size now carries property_item.next_url: the same request with start_cursor set to the answer’s next_cursor, on the twin’s own host. The last page’s next_url stays null. Before, next_url was null on every page. (RYS-2281)

7. A two-way relation is kept in sync on both sides. Writing a dual_property relation on a row, through POST /v1/pages or PATCH /v1/pages/{page_id}, updates the synced property on every page the value names or no longer names, so the related pages, GET /v1/pages/{page_id}/properties/{property_id} and a data source query’s relation filter all agree with the write. Creating such a relation, through POST /v1/data_sources or PATCH /v1/data_sources/{data_source_id} with dual_property: {}, adds the matching relation property to the target data source and answers its synced_property_id and synced_property_name, as Notion does. (RYS-2282, RYS-2283)

8. A markdown edit with allow_deleting_content moves each child page or database it drops to the trash. After PATCH /v1/pages/{page_id}/markdown with allow_deleting_content: true drops a child page’s <page url> tag or a child database’s <database url> tag, through replace_content or update_content, GET /v1/pages/{id} and GET /v1/databases/{id} answer the child with in_trash: true under its parent, and POST /v1/search no longer lists it as live. Before, the child stayed live and its block was gone. (RYS-2291)

v0.0.2 — 2026-10-09

1. An empty workspace answers as the twin’s own bot. On Pro and Enterprise, a workspace booted without --scenario or cleared by POST /_rystic/reset still has a bot user: GET /v1/users/me answers it where it answered 401, and the pages and blocks you create name it in created_by. A world that seeds its own bot under state_user.member, as every shipped world does, replaces it. (RYS-1911)

2. Moving a data source stamps the database it leaves. A PATCH /v1/data_sources/{data_source_id} that moves the data source to another database now refreshes the previous database’s last_edited_time to the time of the move, as Notion does. The database it joins keeps its last_edited_time. (RYS-1909)

3. A page created under a database is a row of it. POST /v1/pages with a database_id parent now lands the page in that database’s data source: its parent reads {type: "data_source_id", data_source_id, database_id} as Notion answers it, and a query of the data source lists it. A page created under a trashed page is refused with 400 validation_error, as Notion refuses it. (RYS-1596)

4. A renamed page shows its new title on its block. After PATCH /v1/pages/{id} changes a page’s title, GET /v1/blocks/{id} and the parent’s GET /v1/blocks/{parent}/children answer child_page.title as the new title, as Notion does. (RYS-1980)

5. Rich text over 2000 characters is refused, as in Notion. A rich text item whose text.content is longer than 2000 characters is refused with 400 validation_error when you append children (PATCH /v1/blocks/{block_id}/children), update a block or a page title, or set a database or data source title, as POST /v1/pages already refused it in a page title. Measured against a live Notion workspace. (RYS-1983)

6. A page trashed through PATCH /v1/pages is trashed as a block too. After PATCH /v1/pages/{page_id} with "in_trash": true, GET /v1/blocks/{page_id} reads in_trash: true, as on Notion, where it read false before. (RYS-1981)

7. A data source query sorts by a property and refuses an unknown one, as in Notion. POST /v1/data_sources/{data_source_id}/query now orders rows by a sorts entry naming a property (a number numerically, a title or rich_text by its text), in array order with timestamp sorts. A filter or sort naming a property the data source does not have answers 400 validation_error “Could not find property with name or id: …”, and a condition of another type than its property answers 400 validation_error, as Notion answers both. Before, a property sort was ignored and both answered 200. (RYS-2058)

8. A row’s properties follow its data source’s schema. A page under a data source, created with a data_source_id or a database_id parent, now carries every property of the schema, an unset one with its type’s empty value (date: null, checkbox: false, number: null, select: null, title: []). A property can be named by its id, so title renames the Name title property. A select value reads {id, name, color} from its schema option, and naming an option the schema lacks adds it to the data source with color gray. A property name the schema does not have is refused with 400 validation_error “<name> is not a property that exists.”, as Notion refuses it, with the id spelled with or without dashes. filter_properties on retrieving or updating a page and on a data source query returns only the properties it names. (RYS-1885)

9. A child block of an unknown type is refused, as in Notion. Appending children (PATCH /v1/blocks/{block_id}/children) or creating a page with children refuses a block whose type is not one Notion creates through the API, such as "nonsense", with 400 validation_error, and stores nothing. Before, the twin answered 200 and stored the block. (RYS-1982)

10. Trashing a page leaves is_archived alone, as in Notion. PATCH /v1/pages/{page_id} with {"in_trash": true} now answers and reads back in_trash: true with is_archived: false; in_trash and is_archived are independent members. Before, trashing a page also set is_archived: true. (RYS-2013)

11. A page created with an over-long rich text block is refused, as in Notion. POST /v1/pages refuses a children or content block whose rich text item is over 2000 characters with 400 validation_error “body failed validation: body.children[0].paragraph.rich_text[0].text.content.length should be ≤ 2000, instead was 2001.”, and stores nothing. Before, the page was created. (RYS-2016)

12. A status property starts with Notion’s defaults, and a row shows its unset status and relation. A status property created without options gets Notion’s three options (Not started, In progress, Done) and groups (To-do, In progress, Complete); a row that doesn’t set it reads Not started. An unset relation reads {"relation": [], "has_more": false}, and a relation property’s schema carries database_id beside data_source_id. Before, the status schema was empty and both were left out of the row. (RYS-2108)

13. Comments, users, page markdown, property items and data source creation. The twin serves 11 more Notion routes, 27 in all. Agents can post, list, read, edit and delete comments; list the workspace’s users and read one; read a page as Notion’s enhanced markdown and replace or edit it; page through one property’s values; and create a data source in an existing database. Every route at Notion-Version: 2026-03-11 was measured against a live Notion workspace. @notionhq/notion-mcp-server now reaches 22 of its 24 tools. (RYS-2097)

14. Comment deletes are soft, and the user list is the workspace’s roster. Deleting a comment keeps it readable by id with original_content_deleted: true and empty rich_text, drops it from its page’s comment list, and refuses a further edit or delete with 404 object_not_found, as Notion does; a comment’s timestamps are at minute precision. GET /v1/users lists persons before bots, each user once. (RYS-2097)

15. Page markdown renders each block’s text. GET /v1/pages/{page_id}/markdown and the answer to PATCH /v1/pages/{page_id}/markdown render each block’s text, a to-do’s checked state and a code block’s language. Before, every block rendered empty ("# \n<empty-block/>"). As a result, update_content and replace_content_range matched nothing, and they wiped the text of every block outside the edit. A block written through markdown also reads back from the blocks API with plain_text and href on its rich text and color on its payload, as Notion’s blocks do. (RYS-2222)

16. A block’s comments list by its id. GET /v1/comments?block_id=… takes a block id as well as a page id, as Notion does: a comment created with parent.block_id is listed under that block, apart from its page’s comments, instead of answering 404 object_not_found. (RYS-2223)

17. A page created with markdown holds the blocks the markdown describes. POST /v1/pages with a markdown body now stores the blocks Notion’s enhanced markdown describes, converted by the same companion that reads and updates page markdown: a leading # heading is lifted off (it is the title when properties.title is omitted, and is never a block), every other element becomes a block in document order, and a tab-indented line nests under the block above it. GET /v1/blocks/{page_id}/children lists those blocks and GET /v1/pages/{page_id}/markdown renders them back, where before both answered empty. Two readback flows measure this against the live workspace. (RYS-2235)

18. Three more worlds for the Tier 1 surface. notion_review_thread boots a task page with two open comment discussions to read, reply in, edit and delete. notion_team_directory boots six people and two bots to page through with GET /v1/users. notion_linked_sources boots one database with two data sources, Projects and Tasks, and a project whose 30-task relation pages through property items. Every shipped world’s own bot now also answers users/me with its workspace id and workspace limits. (RYS-2098)

19. A page answer holds at most 25 relation references and says when there are more. GET /v1/pages/{page_id}, and the page POST /v1/pages and PATCH /v1/pages/{page_id} answer, now carry a relation property’s first 25 references with has_more: true when more exist, as Notion does, so a caller learns it must page through GET /v1/pages/{page_id}/properties/{property_id}, which still returns every reference. The same answer holds at most 25 people in a people value and at most 25 inline mentions in a title or rich_text value. Before, the answer carried every reference with has_more: false. (RYS-2161)

20. A markdown edit keeps the child pages and databases it leaves in place. PATCH /v1/pages/{page_id}/markdown with update_content, replace_content_range or replace_content keeps every child page and child database whose <page url> or <database url> tag the edited markdown still carries, under its id and with its own content, and answers 200 without allow_deleting_content. Before, any such edit on a page holding a child page or database answered 400 validation_error, and with allow_deleting_content: true it deleted the untouched children. An edit that removes a child’s tag still answers 400 unless allow_deleting_content is true. (RYS-2258)

v0.0.1 — 2026-10-07

1. A local Notion API for your integration and the agents that drive it. The first release of the Notion twin: 16 routes of the Notion API at Notion-Version: 2026-03-11 — pages, blocks, databases with their data sources, search and the connection’s own bot user — served from a model validated against a live Notion workspace. Point @notionhq/client, notion-client or @notionhq/notion-mcp-server at it with any bearer token and that version (HOWTO.md shows all three); no page lands in a real workspace. (RYS-1947)

2. Pages and block trees, written and read back. POST /v1/pages creates a page under a page or a data source, with children if you send them; GET and PATCH /v1/pages/{page_id} read and update it; GET, PATCH and DELETE /v1/blocks/{block_id} and GET and PATCH /v1/blocks/{block_id}/children read, edit and append nested blocks. DELETE trashes rather than deletes, as on Notion, and PATCH with "in_trash": false restores. A missing id answers Notion’s 404 object_not_found. (RYS-1597, RYS-1598, RYS-1884)

3. Databases, data sources and search. POST /v1/databases creates a database with its first data source; GET and PATCH read and update a database or a data source’s schema; POST /v1/data_sources/{data_source_id}/query returns its rows with property and timestamp filters applied and page_size paging; POST /v1/search finds pages and data sources by title. A property sort is ignored in this release. (RYS-1595, RYS-1596, RYS-1886, RYS-1892)

4. One API version, enforced on every route. The twin speaks Notion-Version: 2026-03-11: a request with no Notion-Version or any other version answers 400 missing_version, on every route, as Notion does. The official clients default to 2025-09-03, so set the version in the client. (RYS-1914)

5. Five shipped workspaces. --scenario notion_team_wiki boots a wiki with a root page, three child pages, a nested block tree and a Meeting Notes database, and is the world Free boots and POST /_rystic/reset returns to. notion_task_tracker holds a Sprint Tasks database with six rows across every status, notion_blank_slate one page and one empty database, notion_trash_bin a trashed page tree beside a live restore log, and notion_locked_vault locked pages beside an unlocked one; SCENARIOS.md says what each is for. On Pro and Enterprise, POST /_rystic/seed lands pages, blocks, databases, data sources and users directly, and POST /_rystic/reset rewinds the id sequence and the clock, so two identical runs give byte-identical pages and blocks. (RYS-1947)

6. Measured against a live Notion workspace. The 2026-10-07 full-suite round matched 79 of 79 probes against a live Notion workspace, with 0 inconclusive. HOWTO.md states the differences this release ships with, each with its ticket: unserved routes answer a plain 404, not Notion’s envelope (RYS-1913); a data source query ignores property sorts, has no page_size cap and misses a page created with a database_id parent (RYS-1596); and a page’s properties are not resolved against its data source’s schema (RYS-1885). (RYS-1947)

S3

v0.0.4 — 2026-10-12

1. A world can carry its own timeline. A --seed file, or a whole one posted to POST /_rystic/seed, may add credentials, binding presented credentials to actors, and events: calls the twin makes on its own API at set sim times as one of those actors, through the same handlers and egress as your requests. A top-level credentials or events key the twin used to ignore now takes effect. RYSTIC_PACE=<speed> plays the clock, and the timeline, in real time, and an event’s at may be +<duration>. /_rystic/inject, --inject and RYSTIC_INJECT now need state_set instead of scenarios. (RYS-2422)

2. A timeline call can hand what it minted to later events. A call event may add bind, {"<name>": "<JSON Pointer>"}, saving fields of its answer, such as an ID the twin minted; a later event uses one as ${name} in a call’s path, headers or body or in a seed event’s record keys and values (a register name cannot be bound). A schedule naming a ${name} no earlier call binds is refused at load, and an event whose binding call failed records an error instead of firing. (RYS-2505)

3. s3_static_site plays a timeline. Over the two hours after the pinned clock, the site’s deploy bot, bound to its own AWS4-HMAC-SHA256 authorization header, snapshots index.html into releases/2026-02-01/, puts a new assets/app.js, deletes the legacy.html redirect stub, rolls an access log and uploads the release bundle as a one-part multipart upload, all through the S3 API; advance the clock to watch the release land. (RYS-2459)

4. A clock jump fires each timeline event at its own time. When one POST /_rystic/clock or paced tick passes several events, each fires with the clock at its at, so the records it creates carry that time, and the clock then lands where the move asked. An event already due when the clock moves fires at the current time. (RYS-2520)

5. A clock jump stamps each timeline event at its exact instant. When a clock move passes timeline events, the records each one makes carry exactly its at, to the millisecond, whatever traffic came before it, so one jump leaves the same records as stepping the clock to each event in turn. (RYS-2542)

6. A timeline call can carry raw bytes, XML or a JSON array. A call event may send body_text or body_base64 instead of body; the twin sends it as written, under the route’s own content type (XML, bytes, JSON or a form), so a scheduled call can upload an object’s bytes or post an XML document, and ${name} fills in body_text. A body may be a JSON array where the route reads one. A call that answers XML binds from its elements by JSON Pointer, such as /InitiateMultipartUploadResult/UploadId. (RYS-2523)

v0.0.3 — 2026-10-11

1. DeleteObjects in quiet mode answers only the keys that failed. A <Quiet>true</Quiet> delete now answers S3’s quiet DeleteResult: no Deleted entries, only an Error per key that failed, so a fully successful quiet delete answers an empty result. (RYS-1836)

2. GetObjectAttributes answers every attribute you ask for. x-amz-object-attributes naming Checksum, ObjectParts or StorageClass now returns them beside ETag and ObjectSize: the stored checksum and its type, a completed multipart object’s parts, and STANDARD. The ETag element is unquoted, as S3 answers it. (RYS-1837)

3. A multipart upload keeps the checksum algorithm it was created with. CreateMultipartUpload with x-amz-checksum-algorithm (CRC32, CRC32C, SHA1, SHA256) now completes with S3’s composite checksum for it (<base64>-<part count>, type COMPOSITE) instead of the default CRC64NVME, and CompleteMultipartUpload answers x-amz-server-side-encryption. The completed object reads back through HeadObject and GetObject with that checksum and x-amz-server-side-encryption, as a single-PUT object does, and GetObjectAttributes lists its parts. (RYS-1838)

4. ListObjectVersions lists the objects you write. In a bucket without versioning every object is listed as a Version with VersionId null and IsLatest true, so emptying a bucket through the version listing (boto3’s bucket.object_versions.delete(), Terraform’s force_destroy) now removes your objects. (RYS-1839)

5. DeleteObject in a versioning-enabled bucket hides the object. A delete marker becomes the key’s current version and the object stays listed in ListObjectVersions as a noncurrent version, so a later GetObject or HeadObject answers 404 NoSuchKey as S3 does, where the twin used to keep serving the object. (RYS-1845)

6. ACL grantee group URIs are declared identifiers. http://acs.amazonaws.com/groups/global/AllUsers and its siblings in a bucket’s or an object’s ACL are handed out byte for byte and never rebased onto the twin, by declaration (pipeline_policy.json host_roles), so a seeded ACL naming them passes RYSTIC_SEED_GATE=reject and a client comparing a grantee URI against the AWS constant matches. (RYS-1910)

7. The scripts in this archive are MIT-licensed. check.sh and the archive’s other scripts are published under the MIT License at https://github.com/Rystic-Inc/rystic-scripts , so you can copy, change and share them. LICENSE.txt no longer covers them; it still governs the twin itself.

v0.0.2 — 2026-10-07

1. Streaming uploads in the aws-chunked coding. A body sent aws-chunked (Content-Encoding: aws-chunked or x-amz-content-sha256: STREAMING-…), as SDKs stream uploads with a trailing checksum, is decoded: the object stores the payload alone, a trailing x-amz-checksum-* is verified, stored and echoed like the header form, and framing that does not parse answers 400 IncompleteBody without storing anything. (RYS-1372)

2. Presigned URLs. A SigV4 or SigV2 presigned URL, as aws s3 presign and boto3’s generate_presigned_url make, stands in for the Authorization header. The twin checks its shape, and its expiry against the real clock, never its signature: a misshapen SigV4 URL answers 400 AuthorizationQueryParametersError, a misshapen SigV2 one 403 AccessDenied, an expired one 403 AccessDenied, and one sent beside a second credential 400 InvalidArgument, as S3 answers them. (RYS-1372)

3. Breaking: a request’s SigV4 signature must be well formed and fresh. The twin still holds no key and never verifies a signature, but it now checks the signing time against your machine’s real clock and then the Authorization header’s shape, in S3’s order: a signed request with no parseable X-Amz-Date or Date answers 403 AccessDenied (“AWS authentication requires a valid Date or x-amz-date header”), one signed more than 15 minutes from now, either way, answers 403 RequestTimeTooSkewed whatever its shape, one with a fresh date but without exactly one well-formed Credential, SignedHeaders and 64-hex Signature answers 400 AuthorizationHeaderMalformed, and one with no credential answers 403 AccessDenied. A static Authorization header, such as the placeholder v0.0.1’s HOWTO.md and check.sh sent, is refused: sign each request instead, as the AWS SDKs and CLI already do, or with curl --aws-sigv4 'aws:amz:us-east-1:s3' --user <access key>:<secret> (curl 7.75 or later; any key pair works). /_rystic/clock never makes a fresh signature stale. (RYS-1372)

4. Virtual-hosted addressing. A request to <bucket>.s3.us-east-1.amazonaws.com or <bucket>.s3.amazonaws.com is served as the path-style request with that bucket first in the path, so a client keeping S3’s own hostnames and default addressing reaches the twin through rystic run s3-twin --intercept and rystic exec, when it honors the gateway’s proxy and CA settings. Path-style on an endpoint override works as before. (RYS-1372)

v0.0.1 — 2026-10-07

1. A local Amazon S3 for your storage code and the agents that drive it. The first release of the S3 twin: 32 operations of S3’s REST API, path-style on /, /{Bucket} and /{Bucket}/{Key+} — buckets, objects under any key, listings, multipart uploads, copies, tagging, batch deletes, conditional and Range requests and request checksums — served from a model validated against S3 itself. Point boto3 or the AWS CLI at it with an endpoint override, path-style addressing and any access key pair (HOWTO.md shows both), and your code runs against it unchanged; nothing it stores reaches AWS. (RYS-1548)

2. Objects under any key, read back as S3 answers them. PutObject, GetObject, HeadObject and DeleteObject on /{Bucket}/{Key+}, where a key such as logs/2026/09/report.csv is one object and %2F in a path is the / it stands for; ListObjectsV2, ListObjects and ListObjectVersions list by prefix and delimiter; GetObjectTagging, PutObjectTagging, DeleteObjectTagging, GetObjectAttributes and GetObjectAcl read and write an object’s settings. Bodies run to 64 MiB; a larger one answers 400 EntityTooLarge. Every routed answer is S3’s own XML or headers and carries x-amz-request-id and x-amz-id-2, every error a routed S3 request gets is S3’s <Error> document (only a path no route matches answers the twin’s own JSON 404), and an operation on a modelled path that the twin does not model (ACL writes, legal hold, retention, restore, select, and every bucket setting but versioning and tags) answers 501 NotImplemented and changes nothing. (RYS-1368, RYS-1369, RYS-1370, RYS-1373)

3. Multipart uploads, copies and batch deletes. CreateMultipartUpload, UploadPart, ListParts, CompleteMultipartUpload, AbortMultipartUpload and ListMultipartUploads let an SDK’s upload manager — boto3’s upload_file, aws s3 cp — start an upload, send its parts and complete it with the multipart ETag S3 gives it, up to twelve parts at S3’s 5 MiB minimum; a part whose ETag matches none uploaded answers InvalidPart, an unknown upload id NoSuchUpload, and the completed object’s Location leads back to the twin. CopyObject and UploadPartCopy copy within a bucket or from another by x-amz-copy-source, and DeleteObjects deletes every key its <Delete> document names. (RYS-1369, RYS-1370, RYS-1910)

4. Request checksums, conditional writes and Range reads. A PutObject or UploadPart carrying x-amz-checksum-crc32, -crc32c, -crc64nvme, -sha1 or -sha256, as the AWS SDKs send by default, is checked against the body — a mismatch answers 400 BadDigest and stores nothing — and the stored checksum is echoed under x-amz-checksum-mode: ENABLED, so SDK integrity validation passes. If-None-Match: * or a stale If-Match on PutObject answers 412 PreconditionFailed and leaves the object alone; If-None-Match and If-Modified-Since on GetObject and HeadObject answer 304; If-Match naming another ETag answers 412; and a Range answers 206 Partial Content with its Content-Range. (RYS-1368, RYS-1369, RYS-1835, RYS-1840)

5. Buckets: create, list, read, configure and delete. CreateBucket makes a bucket by the name you choose, ListBuckets lists the account’s buckets with each one’s CreationDate (and BucketRegion when asked), HeadBucket, GetBucketLocation, GetBucketAcl, GetBucketVersioning and GetBucketTagging read one, PutBucketVersioning turns versioning on or suspends it, PutBucketTagging and DeleteBucketTagging write its tags, and DeleteBucket removes an empty one — a bucket still holding objects answers BucketNotEmpty. x-amz-expected-bucket-owner passes for the owning account’s 12-digit id (123456789012 unless a seed says otherwise) and answers 403 AccessDenied for any other. (RYS-1370, RYS-1856, RYS-1865)

6. Five shipped worlds, and the one your test needs. --scenario s3_static_site boots acme-demo-site, an unversioned website bucket with seven keys under real prefixes beside its access-log bucket, and is the world Free boots and POST /_rystic/reset returns to. s3_versioned_archive holds six version rows with a delete marker among them, s3_encrypted_vault four objects pinning different encryption, checksum and storage-class combinations, s3_bucket_farm six buckets over five regions and every versioning state, and s3_fresh_bucket one empty tagged bucket; SCENARIOS.md says what each is for. On Pro and Enterprise, POST /_rystic/seed lands buckets, objects, versions and multipart uploads directly, and POST /_rystic/reset rewinds the id sequence and the clock, so two identical runs give byte-identical objects and listings down to ETag, Last-Modified and UploadId. (RYS-1368, RYS-1548)

7. Measured against S3 itself. The 2026-10-06 full-suite round matched 117 of 117 probes against s3.us-east-1.amazonaws.com, with 0 inconclusive. HOWTO.md states what the suite leaves out and the differences this release ships with, each with its ticket: a versioning-enabled bucket keeps no versions of what you write (RYS-1845), ListObjectVersions lists no null version for an object you write (RYS-1839), DeleteObjects in quiet mode lists every deleted key (RYS-1836), GetObjectAttributes answers ETag and ObjectSize only (RYS-1837), and a multipart upload completes with CRC64NVME whatever algorithm it was created with and reads back without its checksum or encryption headers (RYS-1838). (RYS-1548)