R3

Every R3 document this server can give you, IN READING ORDER, with what each one covers and how big it is. R3's documentation begins here: no model has R3 in its pretraining, and code written from tool descriptions alone saves cleanly and then silently does nothing. r3_docs_read returns one.

无需输入参数。

Return one R3 document in full, or one API symbol. Paths come from r3_docs_list: r3_docs_read("CODE_PATTERNS.md") how a Code component is written (reading order 1) r3_docs_read("PHYSICS_USAGE.md") colliders, rigid bodies, joints r3_docs_read("HOWTO_PHYSICS.md") one task step by step (how-tos: r3_docs_list) r3_docs_read("api") index of every component, system and event r3_docs_read("api/component/Mesh") one component r3_docs_read("api/system/PhysicsRapier") one system r3_docs_read("api/event/KEY_DOWN") one event, and the data it delivers The API reference is only ever read one symbol at a time — the whole file is too large to serve.

Report the R3 account you act for, how you are connected (an agent key, or an app connection made with Sign in with R3), what you are allowed to do, the account's plan (its name and how many live projects it allows and uses: going live needs one), and whether the R3 platform is reachable. It verifies the credential end to end and names the capabilities it carries, so it is the call that confirms the account before any other tool. For an account with no project yet it gives the first step: starters to build, and projects it can remix. Tool schemas version: 2bba2fd0e943 (the tool list you were given; r3_whoami returns the one served now).

无需输入参数。

Create a new R3 project and save it to the user's account. Produces a complete, openable project — scene, world, camera, renderer, lighting, audio listener, music transport and OrbitControls (anyone who opens it can turn and zoom the view) — ready for components to be added. Pass `template` for a phone project (mobile-portrait / mobile-landscape) that fills the screen when published. Returns the project id, which every other project tool takes. r3_whoami confirms which account it is created in.

List the projects this R3 account can work on — its own and its teams' — last updated first, with the projectId every other project tool takes. It is how a project the user names ("my slot machine") rather than giving an id is found: search for it; its projectId is what r3_project_load takes. Search by name rather than paging: search: "slot" is matched (case-insensitively, anywhere in the name) against EVERY project by the server, not against the page you are holding. Names are not unique: when more than one project matches, the candidates' name, team and last save tell them apart, and which one is meant is the user's answer. Each row says whose space it is in (personal, or a team by name), the account's role on it (a viewer cannot save changes), whether it is in the R3 Community, and whether you (this agent key or app connection) created it.

List the components in an existing R3 project — what it contains and, for each one, its entityRef: the name code addresses it by (`this['mesh_cube_1']`). Read this before writing any code for a project, and after any tool call whose outcome was reported as unknown, to see what actually landed. Value components (Vector3, Color, Scalar) are not listed individually — reach them through their owner, e.g. `mesh.position.x`. Each object says which entity it belongs to (entity: {entityRef, id}, or null; r3_component_set {"entity": …} changes it), and an entityRef several components share (the same name in different entities) is listed with their ids: tools refuse that name, use the id.

Create a shareable preview link for a saved R3 project, so a person can open it in a browser and see it running. The link is valid for 7 days and does NOT make the project public; making a new one is free. It is how the user sees what you built. Takes the projectId returned by r3_project_create. When an R3 tab has the project open, the project's picture (its card and the link's image) is refreshed from that tab; when none has, the picture refreshes the next time the project is opened in R3.

Remove the preview link of an R3 project: every preview link to it stops working at once (teammates' too). Only when the user asked for it, or when the preview link is what blocks an r3_project_delete the user asked for: a preview link is temporary, so it may then be removed without a separate request, and the user is told it was removed. A live project stays live; a project that was only previewed is no longer published. Deletes nothing: r3_preview_create makes a new link. A project with no open preview link is refused and left as it is. Needs the publish:preview right.

Publish an R3 project live: makes a RELEASE (a frozen copy) of the project as it is now and makes it the one its public live URL shows, for anyone. Only when the user asked for it. Changing the project does NOT change the live site; r3_publish_live does: on a project that is already live this is a publish update (a new release replaces the live one), and the answer names the release number and what changed since the previous live release. `note` (optional, up to 500 characters) is stored with the release. `slug` (optional, the first time a project goes live) is the project part of its public address (e.g. "my-game" for …/<handle>/my-game: letters, numbers and dashes); without it R3 uses a free address (the project's name when free) and the answer says which. Once a project has been live its address never changes. Going live the FIRST time uses one of the live-project slots of the project owner's plan (an update uses none); going live needs a plan. When there is no plan or no room, nothing is published and the answer says how many live projects the plan allows, how many are used and where the user picks a plan. It publishes every change kept so far (yours and the user's: there is nothing to save first). r3_release_list shows the releases, r3_release_rollback makes an older one live again. Needs the publish:live right.

Take a live R3 project offline: its public live URL stops working at once, and the live-project slot it used on the plan is free again. Only when the user asked for it. Other people open a live project, so one that blocks an r3_project_delete goes offline only once the user has been asked and agreed, never as a step of the delete. Deletes nothing: the project, and any preview link, stay; r3_publish_live makes it live again. A project that is not live is refused and left as it is. Needs the publish:live right.

List the releases of an R3 project, newest first: number, date, who made it, note, size, which one is LIVE (what the public URL shows), pinned, and releases in the trash (restorable for 7 days). Also says whether the project has saved changes that are not live yet: saving does NOT change the live site; r3_publish_live does. Read-only. Needs the project:read right.

Make an earlier release of a live R3 project the one its public URL shows again (rollback, or forward again). Only when the user asked for it. The project must be live; this never uses a plan slot. A release in the trash or one marked incomplete is refused. Nothing is deleted: the release that was live stays in the list. Take the number from r3_release_list. Needs the publish:live right.

Read the publish settings of one of the user's own R3 projects in this environment — what the app's Deploy → Settings shows: Works on (keyboard / touch / both / not tested), the SEO title and description that search engines and link previews show, how the live page starts (Start button, first click, on load), its controls and badge. Also answers a SUGGESTION for Works on, from a scan of the project's code for keyboard / touch / pointer handlers — only a suggestion. r3_publish_settings_set changes them. Needs the project:read right.

Change publish settings of one of the user's own R3 projects in this environment — the app's Deploy → Settings. Only the settings named change (the rest stay as they are). Only when the user asked for it, or approved the text: these settings shape the PUBLIC live page — its title and description in search results and link previews (seoTitle, seoDescription), Works on (keyboard puts a "made for a keyboard" note on phones and a "desktop" badge; touch a "mobile" badge; both, both; untested none — set it only after the user confirmed it or it was tested, never from the code scan alone), how it starts (with a Start button: what runs before the Start button, startButton.before {code, physics}, and whether the project's share picture shows until Start, startButton.poster shareImage), its controls. Invalid values are refused with every problem named, and nothing is saved. The answer names what changed; open live and preview pages are told (a preview reloads, a live page offers a reload). Takes effect without a new release. `address` changes the public address of a project that is or was live (only when the user asked for it): e.g. "my-game" for r3js.org/<handle>/my-game; the old address then redirects to the new one, so links already shared keep working. Refused by name when taken, invalid or not live yet (a first go-live chooses it: r3_publish_live `slug`). Needs the publish:live right. R3 admins only: `gallery` features, hides or sets the example prompt of a project in the landing gallery (any member's project; send it without `settings` for a project that is not yours).

Rename a project: the name shown in the user's project list, the editor's title and the live page. The same change as clicking the title in the R3 editor, kept at once in the project's live copy (every open R3 tab shows it). The public address does not change: a preview or live link keeps working. Scripts are not affected (they never address the project by name). Renaming a COMPONENT is not this tool: that is done in the R3 editor.

Remix a project: copy the published release of a project into a NEW private project in this account. The source is a Community or live project whose author allowed remixes (for now R3's own starters and showcase projects), or one of the account's own. The files it uses are copied into the account's own lists, the new project carries a credit line naming the original and its author, and its code starts held until Run is pressed in the R3 editor. The original is not changed. Limits: 20 remixes per account in 24 hours and 5 per agent key in an hour; one remix copies at most 50.0MB of files; a project with videos cannot be remixed yet. Returns the new project id, which every other project tool takes, the credit, and notes on anything that could not be copied. r3_editor_open opens it in the user's R3 tab and r3_preview_create makes a private link to show it.

Permanently delete an R3 project. With the project:delete:created right (on by default), only a project YOU created (this agent key or app connection) — use it to clean up your own abandoned attempts; the user's own projects and other agents' are refused. With project:delete:owned, any project the user owns, and only when the user asked for it: pass owned: true for a project you did not create (an app connection is then asked for that right). A published project (live, or with an open preview link) is refused: it must be taken offline first. If the refusal is for a preview link (temporary, 7 days), it may be removed without a separate request (r3_preview_remove) and the delete tried again; the user is then told it was removed. If the project is live, other people can open it: it goes offline only once the user has been asked and agreed, never as a step of the delete. This is irreversible: there is no trash and no undo.

List the R3 factories available to r3_factory_run, with each one's options, types and defaults. A factory builds a complete, correctly-wired object — a cube is a mesh plus geometry plus material plus colour, already connected. Call this before r3_factory_run if you are unsure of a factory name or its options.

Add an object to an existing R3 project — a cube, sphere, terrain, lighting, a physics body, and so on. Each factory builds a complete, correctly-wired object (mesh + geometry + material + colour, already connected), so you never assemble components by hand. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_create is the same tool). The answer says what was kept and its seq. "name" names what you make ("Leg front left" → entityRef leg_front_left): the primary component (a cube's Mesh, a light), unique in the project (a name already used gets _2); its geometry and material take it too (leg_front_left_geometry, leg_front_left_material). Name parts when you make them: renaming later is done in the R3 editor. "StudioLighting" lights a scene the way a photo studio does: one of R3's built-in HDR environments (studio, sunset, sky) as the scene's environment, so metal and glossy materials reflect, plus a key light. Use r3_factory_list to see the factories and their options.

Add or replace a Code component: JavaScript that makes a project DO something. It runs on ONE event you choose (`event`): RENDER_BEFORE (default) every frame, for movement (held keys: this.keysPressed); KEY_DOWN / KEY_UP once per press / release; MOUSE_CLICK, SWIPE, MUSIC_BEAT, PHYSICS_COLLISION once per click, swipe, beat, collision. A script per event: r3_docs_read("HOWTO_CODE_EVENTS.md"). Kept at once in the live copy every open R3 tab runs, nothing to save (r3_editor_code is the same tool); the answer gives its seq and codeVersion. r3_project_load names the entityRefs code uses; r3_docs_read("CODE_PATTERNS.md") is the API (a guessed one saves, then silently does nothing). The code: a function body that RETURNS its hooks: ```js this.start = function() { // once, at start }; this.update = function(data) { this['mesh_cube_1'].rotation.y += data.delta; }; return {start: this.start, update: this.update}; // REQUIRED — nothing runs without it ``` Reach a component as `this['<entityRef>']`, infrastructure with this.getProject() / getScene() / getCamera() / getRenderer() / getWorld() / getAudioListener() / getEntityInstance(). Anything else returned is an api other scripts call: `this['<entityRef>'].api.<name>(...)`. Code that creates things (scene objects, timers, listeners) frees them in a returned `dispose`: R3 calls it on re-save, Stop and delete. No getComponentByRef, this.state, this.getSibling or R3 global: code using them is REFUSED. EVENTS (by NAME; default RENDER_BEFORE): RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE, MUSIC_BEAT, MUSIC_BAR, PHYSICS_COLLISION. Their `data` (mouse: nested, -1..+1): the how-to's table. Pass entityRef + baseVersion (the codeVersion r3_code_read gave) to REPLACE a script (and its event); name (or neither) to create one. Never merged: a write on an older version is refused with the current code.

Read back what a Code component actually contains — its full JavaScript source and the event it runs on. r3_code_write reports what it wrote; this reports what is there. Use it before replacing a script, so an edit builds on the real source instead of overwriting it blind, and after a write whose reply you did not see, to confirm what landed. Call it with NO entityRefs to get every Code component in the project — that is how you find a script again when you never received the entityRef for it. Each script comes back with its codeVersion: pass it as r3_code_write's baseVersion. The event comes back as a NAME (RENDER_BEFORE, KEY_DOWN, …), which is the same form r3_code_write takes, so you can hand it straight back. r3_component_read reports the same field as a raw number and omits any source over 2000 characters; this is the tool for reading code. Name ONE entityRef to read it in pages (offset / length): every script comes back with totalChars, the sha256 of its WHOLE source, and truncated / nextOffset. When truncated is true you have only part of it: read on from nextOffset, join the pages and check the sha256 before writing it back. Reading several, a body longer than one page is left out WHOLE and named with its size — never cut silently, because a partial script written back would delete the rest of it. An entityRef that does not exist is named and the others are still read.

Set the instructions that ship WITH a project — controls, what to press, what it does. R3 renders them in a modal behind a floating "?" button and the H key, in the editor and in the live portal alike, so whoever opens your preview link can read them. This is the built-in surface for that, so a Code component needs no overlay of its own. The body is markdown — headings, bullets, `code`, links: the controls as a player needs them, e.g. "## Controls\n\n- `Space` — jump". A project has ONE help. Call this again and it replaces the text rather than adding a second. REPLACING needs baseVersion, the codeVersion r3_component_read gave for the Help: text is never merged, so a write on an older version is refused with the current text. The first Help needs none. The optional title is the modal's heading ("Controls", "How to play"); leave it out to keep "Help". Kept at once in the project's live copy: every R3 tab with the project open shows it now. The result gives you the component's entityRef — pass that to r3_component_set to change the trigger key, move or hide the button, or have the help open automatically on load.

Set one or more properties on a component that already exists in a project — a material's roughness, a mesh's position, which material a mesh uses. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_set is the same tool). The answer says what was kept and its seq. Components are addressed by entityRef (r3_project_load lists them); one several components share is refused with them: pass componentId (or the id as a reference). {"entity": "<an Entity's entityRef>"} puts it in that Entity (with its position, colours …); null takes it out. Properties come in four shapes and the value you pass differs: • plain value — {"roughness": 0.25}, {"visible": false} • value component (position / rotation / scale / color / size …) — pass an OBJECT of just the keys to change: {"position": {"y": 2}} leaves x and z alone. Vector3 has x/y/z, Color has r/g/b/a (0..1), Scalar has value. An EMPTY slot (a rigid body's centerOfMass is empty until set) is made from the fields given: {"centerOfMass": {"z": -0.3, "mass": 8}}; the fields not named keep their defaults. Rotations are in RADIANS, not degrees: a quarter turn is Math.PI/2 ≈ 1.5708 (the R3 Inspector shows rotations in degrees: 90°). • reference to another component — pass that component's entityRef as a string: {"material": "material_cube_1"}, or null to clear it. • list of references (a mesh's materials) — pass an ARRAY of entityRefs: {"materials": ["mat_a", "mat_b"]}. The array REPLACES the whole list, in the order given — it does NOT append, so name every component you want in it; [] empties the list. The result reports the list before and after, so check that against what you intended. Several properties in one call apply all-or-nothing. An unknown property is refused with the valid names (a typo never corrupts the project). Renaming (name / entityRef) is done in the R3 editor. Giving a VehicleWheel its mesh or vehicle measures the

Read back what components actually hold — a material's colour and roughness, a mesh's position, which material it uses. r3_project_load gives you the names; this gives you the values behind them. Pass SEVERAL entityRefs in one call — telling six similarly-named materials apart is the case this exists for, and it is one round trip rather than six. One component: entityRef: "mesh_cube_1" (r3_component_set's name for it) works too. What comes back is exactly what r3_component_set takes, so read → change → write needs no translation: value components are expanded inline ({"position": {"x": 0, "y": 2, "z": 0}}), references are the target's entityRef as a string (or null when empty), and lists of references are arrays of entityRefs. Use it before any relative change ("20% brighter", "move it up by one"), and after a write to confirm what landed. Bulk data — mesh vertex arrays and anything else megabyte-sized — is NOT returned. Every property left out is listed with the reason, so an omission is never silent. Each answer says which entity the component belongs to (entity: {entityRef, id}, or null). An id works in place of an entityRef; an entityRef several components hold (the same name in different entities) is not guessed: it is reported with each holder's id. An entityRef that does not exist is reported by name and the rest are still read. Value components (a Vector3, a Color) are not read on their own: ask for the component that owns them.

How high the ground of a heightfield terrain is at the world (x, z) positions you ask, exactly as physics and the drawn terrain have it, plus the terrain's lowest and highest point, centre, size and footprint. Use it to place something ON a terrain: an object stands on the ground at (x, z) when its lowest point is at the returned y (a vehicle: its wheels' bottom); the returned ground normal says how steep it is there. One call takes up to 100 points; with none it describes the terrain only. `terrain` is the terrain's Mesh, GeometryHeightfield or ColliderHeightfield (entityRef or id); leave it out when the project has one terrain. It reads the user's open R3 editor when it has the project (the terrain as on screen, a heightmap image included), else the saved project. A terrain shaped by a heightmap IMAGE needs the project open in R3 (r3_editor_open), because only a browser decodes the image. Read-only: nothing is changed.

The size and place of meshes and imported models, in R3 units (metres): the world-space box around each (min, max, size, centre), the mesh's scale, rotation and parents applied. Name a Mesh, or the root Empty of a Blender model (r3_blender_import makes one, named "<model>_root"), and the box covers it and every mesh under it, with each part listed. Use it before scaling or placing anything relative to its size: to stand a model on the ground, move it so its min.y is the ground height (r3_terrain_height on a terrain); to make it 2 m long, scale by 2 / size. Each answer also gives the project camera's position and lookAt that show it whole on any screen, a phone held upright included: use it to frame a model. Several in one call (up to 20). Works with no R3 tab open, from the project as it is kept; read-only.

Add one component of ANY registered type — a collider, a rigid body, a joint, a light, a material, a geometry … — to a saved R3 project, with its values and references set before it is created. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_add_component is the same tool). Use r3_factory_run for a ready-made object (a cube, a physics sphere …). `type` is the short type name, e.g. "ColliderCuboid" (an unknown type is refused with the list). `values` take r3_component_set's shapes: a plain value {"friction": 0.2}; a value component as the keys to set {"halfExtents": {"x": 2, "y": 0.5, "z": 1}}; a reference as the target's entityRef or id {"rigidBody": "rigidbody_dynamic_1"} — a component of THIS project, of a type the slot accepts; "name" names it (a name already used is kept as its label, and its entityRef gets a suffix, e.g. hull_2: the answer says so); "entity" puts it in an Entity (its value components join too). A type that cannot exist without an option (an Audio / AudioPositional / Texture's "url") takes it in values too, and is refused without it. A Code component's code is r3_code_write's. A VehicleWheel added with a mesh is measured from it (Configure from Mesh: radius, connectionPoint, axle), and a ColliderCuboid / Sphere / Cylinder / Capsule with a mesh (its own or its rigid body's) is fitted to it (Fit to Mesh: size, and position on the mesh's centre), only the values you did not pass; the answer says what (PHYSICS_USAGE.md → Vehicles).

Open a project in the R3 editor the user has open in their browser (their most recently used R3 tab) and focus it, so they see it. A project already open there is just focused (never reloaded). It is how the user gets to see the project you are working on, and how a tab gets the project r3_editor_inspect reads. The same access rules as opening it by hand: the user's own projects, their teams', and public ones. The editor holds up to 4 projects; at that limit it refuses. Nothing is saved or changed. When no editor is open, the answer says where the user can open one.

Read what components hold RIGHT NOW in an R3 tab that has the project open: runtime values included — a moving body's position while the project runs. Use it to debug live behaviour. It needs a tab with the project open (r3_editor_open opens one). r3_component_read reads the kept values without a tab. Select with any of: `ids` (component ids from r3_project_load), `type` ("Mesh", "RigidBodyDynamic", …) and `entityRef`; they combine. `fields` keeps only the properties you name (e.g. ["position", "rotation"]). At most 50 components per call; a larger answer is refused with how to narrow it. Values are in r3_component_read's shape (value components inline, references as entityRefs), so they can be handed to r3_component_set. The project must be open in the editor (r3_editor_open opens it). Read-only: nothing is changed.

The same tool as r3_component_set (this is its older name): change properties of a component, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Name the component with componentId or entityRef. `values` take r3_component_set's shapes: a plain value {"roughness": 0.25}; a value component as an object of the keys to change {"position": {"y": 2}} (an EMPTY slot, e.g. a rigid body's centerOfMass, is made from the fields given: {"centerOfMass": {"z": -0.3, "mass": 8}}); a reference as the target's entityRef {"material": "material_cube_1"} (null clears it); a list of references as an array of entityRefs (it REPLACES the list). All-or-nothing: an unknown name is refused with the valid ones. A Code component's code is r3_editor_code's. Rotations are in RADIANS, not degrees: a quarter turn is Math.PI/2 ≈ 1.5708 (the R3 Inspector shows rotations in degrees: 90°).

The same tool as r3_code_write (this is its older name): replace a Code component's code, kept at once in the project's live copy: every R3 tab with the project open runs the new code now, no editor needed and nothing to save. Name it with componentId or entityRef and pass baseVersion, the codeVersion r3_code_read answered: code is never merged, so on an older version it is refused with the current code and version (apply your change to that and call again). The code is a FUNCTION BODY (a top-level `return {start, update};`); read r3_docs_read("CODE_PATTERNS.md") for the R3 APIs. A syntax error or an R3 API that does not exist is refused before anything is kept.

The same tool as r3_factory_run (this is its older name): add an object — a cube, sphere, light, physics body … — kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. r3_factory_list lists the factories and their params.

The same tool as r3_component_add (this is its older name): add one component of ANY registered type — a collider, a rigid body, a joint, a light, a material, a geometry … — with its values and references set before it is created, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Use r3_editor_create for a ready-made object. `type` is the short type name, e.g. "ColliderCuboid" (an unknown type is refused with the list). `values` take r3_component_set's shapes: a plain value {"friction": 0.2}; a value component as the keys to set {"halfExtents": {"x": 2, "y": 0.5, "z": 1}}; a reference as the target's entityRef or id {"rigidBody": "rigidbody_dynamic_1"} — a component of THIS project, of a type the slot accepts. Example — swap a rigid body's collider: add a ColliderCuboid with {"rigidBody": …, "halfExtents": …}, then r3_editor_delete the old collider (mode "one").

Delete components from the project the user has OPEN in their R3 editor, exactly as the editor's delete dialog asks it — in TWO calls. First call WITHOUT `confirm`: it returns the plan and changes nothing — the selected components, what only they use (their geometry, material, colliders …), an Entity's members, the modes on offer and a planToken. Then call again with the same componentIds and confirm: {"mode": …, "planToken": …}: "one" deletes only the selection, "with_dependents" also what only it uses, "bundle" (one Entity) the entity with its members. The mode is the user's choice, unless they already said. If the project changes in between, the confirm is refused: plan again. Only when the user asked for it. The confirmed delete is kept at once in the project's live copy (every open R3 tab shows it; no editor is needed); R3 keeps what was deleted in the project's trash. The children of a deleted Empty or Mesh keep their place in the world, as the editor's delete does (their numbers become the scene's; the answer lists them). A project itself is never deleted here. Needs the editor:dispose capability.

Undo the last change YOU (this agent key or app connection) made to a project: everything one of your tool calls changed is undone together, and the user sees it at once in any R3 tab that has the project open. Use it when your own change was wrong or the user asks you to take it back. It never undoes the user's changes or another agent's: only yours. `count` undoes your last few changes, newest first. If someone else changed the same thing after you, that change of yours is SKIPPED: nothing is changed, the answer says who changed what, and that change of yours is dropped from your history (the next call takes the one before it). Their change stands: setting your old value back over theirs is the user's decision, not this tool's. `redo: true` puts back what you undid (until you make a new change). Needs project:write (and code:write to undo a change to code).

Put a project's working copy back the way one of its releases (saved versions) had it: components added since are removed, removed ones come back, values and scripts go back to that version (each script as a new version on top of the current one), and the name. The user sees it at once in any R3 tab that has the project open. Only when the user asked for it. Two steps: WITHOUT planToken it changes nothing and says what restoring would change, with a planToken; the same call WITH that planToken, once the user has seen the plan and agreed, restores. If the project changed in between, nothing is changed and the new plan comes back. The whole restore is ONE change of yours: r3_editor_undo takes it back. It never changes which release is LIVE (what the public URL shows): that is r3_release_rollback. The release number comes from r3_release_list. Needs project:write (and code:write when scripts change).

Press the Run buttons of the user's open R3 editor: start physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does — a paused simulation resumes. Use it to TEST what you built: run it, then look with r3_editor_capture and read live values with r3_editor_inspect. Changes nothing saved. It shows the named project first (focused, scrolled into view): the systems start for every project open in that tab, but only a project on screen moves. The scene only moves while that tab is in front: a browser pauses a background tab, and the answer then says the scene is NOT advancing. Needs the editor:run right.

Press the Stop buttons of the user's open R3 editor: stop physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does. Stopping physics puts every body back where it was placed. It stops every project open in that tab. Changes nothing saved. Needs the editor:run right.

Capture the canvas of a project open in the user's R3 editor — the scene as it looks NOW, running physics included — and LOOK at it: the answer is an image. Call it after a visual change (r3_editor_set, r3_editor_create, r3_editor_code …) to check what you built, and after r3_editor_run to see it move. By default (`camera: "editor"`) it is what the user sees: the editor's view camera, edit aids included. `camera: "project"` takes it through the project's own camera instead, with no edit aids, as a visitor sees it: use that to check a camera or a camera script. At most 1280 px each way (`width`, default 1024); a JPEG. Needs project:read.

Use what the project's camera shows NOW, in the user's open R3 editor, as the project's share image: the picture its live page, link previews (social cards) and the showcase show, used when the project is next published (r3_publish_live, or Publish update in the editor). The editor waits until the scene's textures have loaded and takes it without edit aids (no grid, gizmos or outlines), as a visitor sees it; the answer is the picture it set. It is for once the project looks right (r3_editor_capture shows it beforehand), or when the user asks for a new picture. A live page keeps the share image of its live release until that next publish. Needs a tab with the project open and project:write.

List this R3 account's entity templates: reusable bundles (a ship, a lamp post) saved from an Entity in a project, each with its current version and member count. community: true lists everyone's public templates instead. r3_entity_read shows one template's members and versions; r3_entity_import puts a copy into a project; r3_entity_save_template saves an Entity of a project as a template.

Read one entity template (this account's, or a public one): its current version, the members of the version read (type, name, entityRef; value components such as positions and colours are counted, they belong to their member), the shared code modules it imports, and its recent versions with their notes. version reads an older version. The current version is the baseVersion r3_entity_save_template needs to update the template.

Save an Entity of a project as an entity template version: its members (the components bound to it, with the positions, rotations and colours they hold). Without templateId it updates the template the Entity was imported from (or makes a new one, under the Entity's id); asNew: true always makes a new template. Updating an existing template needs baseVersion, the version read with r3_entity_read: if the template changed since, nothing is saved and the answer names the current version. The project itself is not changed.

Put a copy of an entity template (this account's, or a public one) into a project: every member with fresh ids, its positions and colours as saved, bound to a new Entity that starts DORMANT (started: false: its code, sounds and physics wait until r3_component_set sets started: true). The copy remembers the template and version it came from. version imports an older version. Answers the new Entity's entityRef and its members' entityRefs. r3_editor_undo takes it back.

Bring the copies of an entity template in this account's projects up to its newest version. Without reportId it only reports, per project: what the template changed that the project did not (taken), what the project changed itself (kept, e.g. a moved ship keeps its position), scripts changed on both sides (kept: code is never merged), parts the template added, and parts it removed (kept unless removeGone: true). With that reportId it applies the report to the projects, as undoable changes every open editor sees; if anything moved since, nothing is changed and the new report is returned. projectIds limits it to those projects (default: every project holding a copy). Published releases never change. Applying needs the template:update right.

List this R3 account's shared code modules: named pieces of script stored once (e.g. "ship-core") that any Code component in any project imports with `const core = this.import('ship-core')`. Each with its latest version. r3_module_read shows one's code; r3_module_write creates or changes one; r3_module_usage says where it is used. See the how-to "HOWTO_CODE_MODULES.md".

Read one shared code module: its code, its version (the baseVersion r3_module_write needs), the latest version, its notes, and how many of this account's projects use it. Your own module by name; someone else's PUBLIC module by moduleId. version reads an older version. A long module is read in PAGES (at most 60000 characters each): every answer gives totalChars, the sha256 of the WHOLE code, and truncated / nextOffset. When truncated is true you have only part of it: read on with the same name, the version answered and offset = nextOffset, join the pages, and check the sha256 before you write it back (half a module written back deletes the rest).

Create a shared code module (baseVersion 0) or write its next version (baseVersion = the version you read). The code is a FUNCTION BODY that returns the exports, e.g. `return { createShip(host, config) { … return {start, update, dispose, api}; } };`. It runs once per run with `this` undefined (it reaches no component: the importing script passes in what it needs) and the same globals as a script (Event, EntityManager, THREE, GraphicsThree). Variables at its top level are shared by every script that imports it; per-instance state goes in what its factory returns. A module cannot import another module. A write on an older version is refused with the current code, never merged. Projects that follow the latest version run the new one at once (open editors reload it); pinned projects and published releases keep their version. See "HOWTO_CODE_MODULES.md".

Which of this account's projects (and entity templates) import one of your code modules: per project the scripts that import it, the version it runs, and whether that version is pinned or follows the latest. Projects of other accounts that import a public module of yours are only counted.

Choose which version of a shared code module ONE project runs: version n pins it (the project keeps that version when the module changes), version null follows the latest again. moduleId names someone else's PUBLIC module (it is then the project's module of that name). The pin lives in the project's import map, not in the code: no script changes. Open editors of the project reload. A release (go-live) freezes the versions the project runs at that moment anyway. Not taken back by r3_editor_undo: pin again.

List the Blender models this R3 account has uploaded — one per .blend file name, the current version of each — with what it will produce: how many Blender objects land in the scene, how many meshes and materials, its screenshot, and any PENDING update (a re-upload that changes meshes the user's projects use, waiting for r3_blender_update). An upload with unapplied modifiers is applied in Blender by R3 itself; a model says what was applied, per object. community: true lists everyone's public models instead. Add one (or some of its meshes) to a project with r3_blender_import. A .blend gets here two ways: a person uploads it in the R3 app (Models -> Upload .blend), or you save one you built in Blender with r3_blender_upload (a one-time ticket and an upload endpoint: never a tool argument).

Add a Blender model the account has uploaded (its current version) to an existing R3 project — the whole model, or only the meshes you name. Every Blender mesh object becomes an R3 Mesh keeping its own position, rotation, scale and origin, with its geometry, materials and textures wired up; objects sharing one mesh share one geometry; a Blender Empty becomes an R3 Empty, the objects under it keeping their place relative to it. A whole model is one Entity whose parts hang from a `<model>_root` Empty: move that Empty to move the model. Reports each object's entityRef so you can reach it with r3_component_set or from code. Use r3_blender_list to choose a model. Pass reparse: true to re-read the .blend itself when the import warns that its meshes were placed at the origin; other projects keep the meshes they use (r3_blender_update moves them, if the user wants). Pass camera to frame the model in a NEW project (its first model: refused on a project that already holds a mesh).

A re-uploaded Blender model is always its latest version; the user's projects keep the meshes they have until asked. This tool asks and answers that one question: choice update_projects without reportId shows which projects and entity templates use an older version (or an earlier import of the same file) and what changed; with the reportId and the projectIds / entityTemplateIds the user chose, it moves just those to the current version. Which ones move is the user's choice; "not now" means no call. Parts are matched by Blender OBJECT name: each takes its new mesh and placement; when only its shape changed it keeps the project's materials and the edits made to them in R3, when its materials changed in Blender it takes Blender's materials, and edits made in R3 to its materials are replaced. Objects new in the model are added under the copy's root Empty, parts the model no longer has are kept (removeGone: true removes them). Published releases never change. The plan only reads; moving projects needs the blender:update right.

Does this project hold the same Blender model more than once (two whole imports side by side)? Answers "N copies of <model>: … Keep one?" with each copy (its Entity, entityRef, part count) and its delete plan. It changes nothing: which copy stays is the user's choice, and the other is removed with r3_editor_delete({projectId, componentIds, confirm: {mode: "bundle", planToken}}) once they have chosen.

Save a .blend you made or changed (in Blender, through a Blender MCP) as the newest version of one of the user's Blender models: the model is named by the file name, so "monster-truck.blend" adds a version to the user's monster-truck model, or makes the model. A tool argument cannot carry the file, so this answers a one-time upload ticket (5 minutes) and the upload endpoint: its URL, method, Authorization header and that the body is the file's raw bytes. Sending it needs file access where the .blend is (the R3 sandbox, or the user's own machine); without it, the user uploads on the Blender page. The endpoint's answer names the model, the version number and its sha256; R3 applies unapplied modifiers itself, and when the user's projects use an older version it asks one question (answer it with r3_blender_update). Then r3_blender_import puts the model in a project. Textures travel only when packed (bpy.ops.file.pack_all()). Up to 100 MB. Needs the blender:upload right.

Get a .blend of one of the user's OWN Blender models (from r3_blender_list) to open in Blender: the current version, or the version fileId names. Answers a one-time download ticket (5 minutes) and the download endpoint (URL, method, Authorization header); the response body is the file. When the current version is the copy R3 made by applying modifiers, the answer says so and names the original upload, with its modifiers intact, to download instead. Another user's model cannot be downloaded.

While you build a model in Blender for the user, push an APPLIED copy of your working .blend after each step (body done, wheels done, materials done): the user's Blender page shows it as a 3D preview they can orbit. A draft is not a saved version: one draft per user, the newest wins, kept 24 hours. Answers a one-time ticket (5 minutes) and the draft endpoint (URL, method, Authorization header; the body is the file's raw bytes); sending it needs file access where the .blend is. The draft is a copy with its modifiers applied and its textures packed; r3_blender_upload saves the real file once the user is happy. Up to 20 MB. Needs the blender:upload right.

List the images this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentTexture.url takes, so this is how you find the account's own artwork — a wood grain, a logo, a skybox — and then point a texture at it with r3_component_set. Search by name rather than paging: search: "wood" is matched against every image on the account by the server, not against the page you happen to be holding. Each row says whether it is a "texture" (an ordinary image for a material slot) or an "environment" map (.hdr / .exr). Those two are not interchangeable: an environment map belongs on Scene.environment, Scene.backgroundTexture or MaterialStandard.envMap, and renders as garbage in an ordinary map slot. You cannot upload an existing image file from here — a tool argument is JSON, this server cannot read your disk, and a real texture is megabytes. A person uploads those in the R3 app. r3_image_create is the one exception: it takes a small image you generated yourself, such as a checkerboard or a gradient.

List the audio files this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentAudio.url takes, so this is how you find a sound the account already has — a footstep, a drum hit, a music bed — and then point an Audio component at it with r3_component_set. Search by name rather than paging: search: "kick" is matched against every audio file on the account by the server, not against the page you happen to be holding. You cannot upload an audio file from here — a tool argument is JSON, this server cannot read your disk, and audio is megabytes. A person uploads those in the R3 app. r3_sound_create makes a new sound effect or seamless loop from a recipe (rendered by R3, listed here afterwards); R3's music components (Transport, Beat, Pattern, DrumGrid) synthesise music that stays editable and in tempo.

Store a small image YOU generated in this R3 account's image library and get back the URL for it — the value R3ComponentTexture.url takes. This is how you make a checkerboard, a gradient, a test grid or a noise tile and then actually put it on something with r3_component_set. Pass the image as a base64 data URL (data:image/png;base64,…), up to 1MB decoded. PNG, JPEG, GIF and WebP are stored; PNG is the right choice for a generated pattern. This is NOT a way to upload an image file you already have. You would have to emit every byte of it as base64, which for a real texture is far more output than a reply can hold — and this server cannot read your disk. A person uploads real artwork in the R3 app, and r3_image_list shows what they have already put there: the account's own artwork, where there is some, beats a generated substitute. Each call stores a NEW image, so calling it twice with the same bytes leaves two rows. The name you give is what appears in the owner's Images browser, prefixed with "agent-" so they can tell where it came from; a descriptive one says what it is. For a material's texture set (colour + normal + roughness that tile), use r3_texture_create instead: R3 renders it, so no bytes go through you.

Make a matching, seamlessly tiling texture SET for a material: a colour map, a normal map and a packed ambient-occlusion / roughness / metalness map, rendered by R3 from a procedural recipe (seeded noise, stones, bricks …). Nothing is uploaded and it is free. The maps are stored as images in the account (the owner sees them in the Images browser as "<name> · albedo.png" …). Start from a preset (gravel, sand, concrete, bricks, brushedMetal) with optional controls: seed (another variation), scale (an integer: finer pattern), colours (the ramp's "#rrggbb" stops, exactly as many colours as the preset has: gravel 3, sand 2, concrete 3, bricks 3, brushedMetal 3), contrast, bumpiness (normal strength), roughness {min, max} (from the smooth parts to the rough parts), metalness (0 = not metal, 1 = metal; metal looks dark without an environment map in the scene), size (256 / 512 / 1024 / 2048, default 1024), tileWorldSize (metres one tile covers, default 1), height (also store a 16-bit height map). Or pass a full `recipe` (r3_docs_read("TEXTURE_RECIPES.md") has the format and every preset's recipe). An invalid recipe is refused with the path of the problem. Pass `apply` {projectId, material, repeat | worldSize (a number, or {x, y} for a long strip)} to put it on a material in the same call (as r3_texture_apply). You cannot see the texture: the answer gives numbers (mean colour, brightness range, height spread, seam check) and the colour map's url; r3_editor_capture shows it in an open editor. Names are unique per account. Each call makes a NEW set; reuse a set with r3_texture_apply.

Read one texture set: its name, size, tile size, the three map urls, the numbers its render measured, the sets it was edited from, and the full RECIPE (the editable source). The account's own sets, or anyone's public one. To change a set, r3_texture_update makes a new version of it.

Change a texture set the account owns: its look (controls: seed, scale, colours, contrast, bumpiness, roughness {min, max}, metalness, size, tileWorldSize, height, applied to the set's own recipe; `scale` multiplies its pattern, so 2 is twice as fine as now) or a whole new `recipe` (read the current one with r3_texture_read, change it, pass it here). The set itself never changes: the change is saved as a new version under the same name (the user's lists show the latest), with new maps, and every project and release that uses an older version's maps keeps them. Give `name` only to make a separate copy under that name instead. The same recipe as the latest version saves nothing. The answer names the user's projects still on an older version; put the new set on a material with r3_texture_apply when the user wants it. An invalid change is refused with the path of the problem. Counts as one render toward your hourly texture budget.

Wire a texture set to a material in a project: the colour map to `map`, the normal map to `normalMap`, the ambient-occlusion / roughness / metalness map to `aoMap` + `roughnessMap` + `metalnessMap` (for a set without metal its blue channel is 0, so a metal map left by an earlier set is replaced and the material's own metalness is kept), the SAME repeat on every map, the material colour white, roughness 1 and metalness 1 for a metallic set (THREE multiplies the colour map by the colour and the roughness map by the roughness: a grey #808080 colour would show the texture at half brightness, the default roughness 0.5 would halve every roughness; the colour's alpha, the opacity, is kept). A Color the material shares with another component is left as it is, and the material gets its own new white Color; the answer says which. Creates one Texture per map, or reuses a Texture of the project already on that image. MaterialStandard / Physical get every map; Lambert / Phong / Toon get map, normalMap and aoMap; Basic is refused (unlit). `repeat` is how often the tile repeats across the surface (both axes); or give `worldSize` in metres: a number for a square surface (1000 for a 1 km terrain with 1 m gravel), or {x, y} for its two sides ({"x": 2, "y": 40} for a 2 m × 40 m path), giving repeatX = x / the set's tile size and repeatY = y / it, so a long strip does not stretch the texture. Give neither and the mesh using the material is measured (its own geometry size times its scale, as r3_component_bounds measures; the two largest sides). Kept at once in the project's live copy: every R3 tab with the project open shows it.

Make a sound (a 48 kHz WAV in the account's audio files) from a recipe that R3 renders: layers of synth / fm / noise / sample sources, each with an envelope and effects (filter, distortion, bitcrush, delay, reverb, compressor, tremolo), and a master stage that can make a seamless LOOP. Nothing is uploaded and it is free (60 sounds an hour for each agent key or app connection). Start from a preset (laser, coin, jump, explosion, click, whoosh, hit, power-up, helicopter-rotor, engine-hum) with optional overrides {seed, duration, channels}, or pass a full `recipe`: r3_docs_read("SOUND_RECIPES.md") has the format, every preset's recipe and worked examples. An invalid recipe is refused with the path of the problem. You cannot hear it: the answer gives numbers (peak / RMS dBFS, clipping, silent tail, the loop seam check, warnings), the url an Audio component takes and a listen link for the user. Pass `attachTo` {projectId} to also add an Audio component playing it in that project (a loop loops and plays when the project runs; a one-shot is played from code). Names are unique per account.

Read the RECIPE a sound was made from (the editable source), with its name, url, duration, whether it loops and the sound it was edited from. The account's own sounds, or anyone's public one; an uploaded file has no recipe. To change a sound, r3_sound_update makes a new version of it.

Change a sound the account owns: overrides {seed, duration, channels} applied to its own recipe, or a whole new `recipe` (read the current one with r3_sound_read, change it, pass it here; r3_docs_read("SOUND_RECIPES.md") has the format). The sound itself never changes: the change is saved as a new version under the same name (the user's audio list shows the latest), with a new url, and every project and release using an older version keeps it. Give `name` only to make a separate copy under that name instead. The same recipe as the latest version saves nothing. The answer names the user's projects still on an older version (r3_component_set moves an Audio component's url). An invalid change is refused with the path of the problem. Counts toward the 60 sounds an hour.

Read a project's Song: its tracks (each plays Patterns, DrumGrids, Beats or Audio files in clips placed in bars), automation lanes (keyframes on a track's or the master's gain, pan or effect settings), sections, master chain and length, with every source as its entityRef, plus a summary and the songVersion r3_song_update takes as baseVersion. Read it before a change ("move the drop", "a slower filter sweep"). The schema: SONGS.md; the how-to: HOWTO_SONG.md.

Change a project's Song with small typed changes, or make a new Song (create). The changes are applied in order and kept as ONE change (one undo step, every open R3 tab shows it): ops: setSong, setSections, setMaster, addTrack, setTrack, removeTrack, setClips, addClip, moveClip, removeClip, setLane, removeLane, addPoint, setPoint, removePoint, setChain, setEffect, addModulator, removeModulator, insertBars, splitClip, transposeClip, setClipGain. Tracks are named by their id ("kick"), sources by entityRef (a Pattern, DrumGrid, Beat, Audio or AudioPositional), clips and lane points by their index as r3_song_read lists them, positions in bars (bar 0 = the start). Examples: {"op": "moveClip", "track": "hats", "clip": 0, "start": 6}; {"op": "setLane", "track": "master", "target": "lp.frequency", "points": [{"bar": 0, "value": 350, "curve": "exp"}, {"bar": 12, "value": 1200}]}; {"op": "insertBars", "at": 64, "count": 8} (moves everything from bar 64 on 8 bars later); one eighth of a clip a few semitones higher, its length kept: {"op": "splitClip", "track": "bass", "clip": 0, "at": 65}, {"op": "splitClip", "track": "bass", "clip": 1, "at": 65.125}, {"op": "transposeClip", "track": "bass", "clip": 1, "semitones": 2} (whole semitones -24..24; a Sound Studio sound is rendered again from its public recipe, another file pitch-shifted, a Pattern's synth notes moved; 0 takes it off); that clip quieter (a clip's Volume in dB, -24..12, on top of its track's; 0 takes it off): {"op": "setClipGain", "track": "bass", "clip": 1, "gain": -4}. A song is version-checked, never merged: changing one needs baseVersion, the songVersion r3_song_read answered; if someone changed it since, the write is refused with the current version. A new Song (create) needs none. Every result is checked by lib-r3's song schema (SONGS.md) before anything is kept. How-to: HOWTO_SONG.md.

The account's images, models and audio files that nothing uses — no project, no entity template, no other user's project — with each one's size and date, biggest first, and the total. The same report as the R3 app's Settings → Storage, by the same rules the deletes use. A model lists the images only it uses, an HDR / EXR image its preview image: they go with it. A texture set nothing uses is one item (kind textureSet) with its maps under it; a map of a set is never listed on its own. Blender (.blend) files are not part of it: they are the user's to keep or delete, listed by r3_blender_list. Pass `kind` to see one kind, `limit` for more rows (the totals always cover everything). It only reads; r3_asset_delete deletes an item by its kind and id (a plan, then a confirm), for what the user asked to remove. The scan can take several seconds.

Delete one of the account's images, models, audio files, Blender models (kind blender: a whole uploaded .blend with every version; its meshes in use stay) or texture sets (kind textureSet: the set and its maps, r3_texture_create made it) — the same reference-guarded delete as the R3 app. With asset:delete:created, only an asset YOU created (this agent key or app connection; today: images made with r3_image_create); with asset:delete:owned, any of the user's assets, and only when the user asked for it: pass owned: true for one you did not create (an app connection is then asked for that right). Two calls, every time: without `confirm` nothing is deleted, and the answer says what would go and which of the user's projects use it; the same call with `confirm: true`, when that is what the user wants, deletes it. An asset another user's project uses can never be deleted. A model takes the images only it used with it, an HDR / EXR image its preview image. There is no trash and no undo. Ids come from r3_image_list, r3_audio_list and r3_blender_list.

Show one of the user's OWN images, audio files or texture sets in the R3 Community, or hide it again: the same switch as 'Show in Community' in the R3 app. public: true makes it visible to every R3 member, who can then find it in the Community lists and use it in their own projects; public: false hides it again (call this tool again with public: false to undo). A texture set is shown or hidden with all its maps; a map of a texture set is not switched on its own (switch the set). Use it only when the user asked to share or hide that asset. Ids come from r3_image_list, r3_audio_list and r3_texture_read / r3_texture_create. Needs asset:share. Videos, Blender models and projects are shared in the R3 app.

Send R3 a bug report about R3 ITSELF (the engine, the editor, these tools), in the user's name and naming you (your agent key or app connection). It becomes one of the user's support issues, which only the user and R3's team see. Use it when R3 does something its documentation says it should not, after checking the docs (r3_docs_read) — not for problems in the user's own project, and not for feature wishes (those are r3_roadmap_suggest). r3_bug_reports_mine lists what the user already reported, so a fault is not filed twice. A useful report says what was done (the tool calls), what was expected and what happened, with what was MEASURED in `measurements` — the values read back with r3_component_read or r3_editor_inspect, the exact error text. `projectId` (when it happens in a project) lets R3 open it. The answer carries the report's link for the user. Rate-limited per agent key or app connection (a few an hour). Needs the support:write right.

The user's own support issues — bug reports and questions they or their agents (agent keys and app connections) sent R3 — newest first, with status, date, the project and whether an agent filed it (and which), each with its link. It shows whether a fault is already reported, before r3_bug_report would file it twice. Needs the support:write right.

The public R3 roadmap: what is planned, in progress, proposed by the community and shipped, with each item's vote count and whether the user has voted for it — plus the user's OWN suggestions still awaiting R3's approval, marked pending, and the ones R3 declined, marked declined with R3's reason (only the user sees them; neither is votable); a declined item is not suggested again. It shows whether an item already covers an idea before r3_roadmap_suggest: r3_roadmap_upvote votes for that one instead of a duplicate. Narrow it with `search` (title and description, any case) and `status`.

Add the user's vote to a public roadmap item (its id from r3_roadmap_list), when the user wants it or it covers what you were about to suggest. One vote per user: an item the user already voted for stays voted, and this never removes a vote. Needs the roadmap:vote right.

Suggest a feature for R3's public roadmap, in the user's name and naming you (your agent key or app connection). It is HELD until R3's team approves it: not public, not votable, until then. r3_roadmap_list shows whether an item already covers it (r3_roadmap_upvote votes for that one instead). A good suggestion says what the feature lets a person do and why (what was being built when it was missed). Something broken rather than missing is r3_bug_report's. Rate-limited per agent key or app connection (a few a day). Needs the roadmap:suggest right.

What OTHER people changed in a project — the user in any R3 tab, their other agents — oldest first, grouped per author and per thing: properties set, code and help updated (with versions), components added, deleted or restored, the project renamed. Your own changes are never listed. Every answer about a project already ends with a short "Since your last call" line; this is its full list. Without `since`: from where you last looked (and moves that mark to now, unless advance: false). The mark belongs to your agent key or app connection, not to the conversation: two conversations on one share it. With `since` (a seq, e.g. the one the "+N more" line names, or 0 for everything still in the log): from there, without moving anything. Needs project:read.