docs: archive 0.16.0 as Latest, add 0.17.x Next snapshot#1714
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📝 WalkthroughWalkthroughAdds a new “Next” (0.17.x) docs version: extensive MDX content across Understanding/Using/Creating sections, SDK references (Node/Python/Rust/Browser), engine protocol, changelogs and Motia migrations, tutorials/patterns/how-tos, plus navigation updates in docs.json. Changes0.17 docs content and navigation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
guibeira
force-pushed
the
docs/archive-0.16.0
branch
from
b199d03 to
562cbdb
Compare
Contributor
skill-check — docs48 verified, 349 skipped. 4 errors, 5 warnings across the verified workers.
Caution Rendered artifacts were out of date — sources had changed without re-rendering. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (7)
docs/0-17-0/how-to/build-a-realtime-todo-app.mdx (1)
8-54:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftThis how-to is still an outline, not an executable guide.
The page lacks concrete steps/code/expected outcomes, so users cannot complete the task. For a
type: "how-to"doc, this should be expanded before release (or hidden until ready).As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under
docs/."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/how-to/build-a-realtime-todo-app.mdx` around lines 8 - 54, The document is only an outline and missing concrete, executable steps, code samples, and expected outcomes required for a type: "how-to" page; expand the how-to by adding step-by-step instructions, runnable code snippets, configuration examples (e.g., config.yaml), expected outputs, and minimal end-to-end validation steps for each section (Engine configuration, Worker setup, Auth function (RBAC), Stream wrapper, Functions, Connection, Real-time hook) so readers can reproduce the tutorial; ensure the new content follows the Divio documentation system conventions (structure, admonitions, code blocks, and examples) and mark or hide the page until complete if you cannot supply full runnable guidance.docs/0-17-0/tutorials/build-an-agent/define-tools.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftTutorial page is effectively empty and should not ship as-is.
Line 1–7 defines metadata only; there are no tutorial steps/content, so this route will be non-actionable for readers. Please either add the minimum runnable tutorial flow or remove/hide this page from navigation until content is ready.
As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under
docs/."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/build-an-agent/define-tools.mdx` around lines 1 - 7, The tutorial page contains only frontmatter (title: "Define tools", description, owner, type) and no content; either add a minimal runnable tutorial flow under this frontmatter (intro, prerequisites, step-by-step example demonstrating how to define a tool with commands/examples and a "try it" snippet) or remove/hide the page from navigation until it's ready; update the file's content to replace the placeholder with real tutorial sections (Introduction, Prerequisites, Steps with concrete code examples, Expected outcome) or remove the page entry so it doesn't expose an empty route.docs/0-17-0/tutorials/build-an-agent/memory-and-state.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftTutorial page is effectively empty and should not ship as-is.
Line 1–7 contains only frontmatter and placeholder metadata, with no instructional content. Please add a concrete tutorial sequence or keep this page out of the published/nav set until it is ready.
As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under
docs/."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/build-an-agent/memory-and-state.mdx` around lines 1 - 7, The page "Memory and state" currently contains only frontmatter and placeholder metadata; either populate it with a concrete tutorial sequence following Divio documentation conventions (add an introduction, prerequisites, step-by-step walkthrough, examples, and a short summary) or remove/unpublish it from the navigation until ready; locate the MDX file with title "Memory and state" and replace the placeholder body with the full tutorial content (or update the frontmatter/published flag so it is not included in the site build) to comply with the docs guidelines.docs/0-17-0/tutorials/reactive-crud/model-and-store.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftComplete this tutorial page or keep it out of the published version set.
Line 3 uses
"Placeholder."and there is no tutorial content yet. This leaves a broken tutorial journey in the versioned docs.As per coding guidelines, docs in
docs/**should follow the Divio tutorial model, which requires concrete guided steps rather than placeholders.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/reactive-crud/model-and-store.mdx` around lines 1 - 7, The frontmatter for the "Model and store" tutorial uses a placeholder description ("Placeholder.") and contains no tutorial content, causing a broken tutorial; replace the placeholder by either adding a full Divio-style tutorial body (concrete guided steps, headings, code examples, and step-by-step instructions) under the file's content and update the description to a meaningful summary, or remove this file from the published version set; ensure the frontmatter fields title ("Model and store") and description are accurate and that the document follows the Divio tutorial model so it can be included in the versioned docs.docs/0-17-0/tutorials/reactive-crud/crud-endpoints.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftAvoid publishing empty tutorial stubs in reactive-crud.
Line 3 is still
"Placeholder."and the page has no instructional body. Please add the actual CRUD endpoint walkthrough before exposing this as a tutorial page.As per coding guidelines,
docs/**content should follow Divio tutorial expectations (task-oriented, stepwise execution), not placeholder-only pages.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/reactive-crud/crud-endpoints.mdx` around lines 1 - 7, The tutorial page with title "CRUD endpoints" currently has a frontmatter description set to "Placeholder." and contains no instructional content; replace the placeholder description with a concise summary and add a step-by-step Divio-style tutorial body that covers creating, reading, updating, and deleting endpoints (include prerequisites, code examples, expected outputs, and verification steps) so the page is a complete task-oriented walkthrough; update the frontmatter "description" and populate the Markdown body under the existing title in the same file to satisfy docs/** Divio tutorial expectations.docs/0-17-0/tutorials/incremental-adoption/wrap-existing-api.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftReplace placeholder tutorial with actual runnable steps (or hide it from navigation).
Line 3 still uses
"Placeholder.", and this tutorial has no body content. Shipping a visible tutorial stub creates a dead-end in docs flow.As per coding guidelines, docs under
docs/**must follow the Divio documentation system; a tutorial should contain concrete step-by-step execution content.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/incremental-adoption/wrap-existing-api.mdx` around lines 1 - 7, The frontmatter description for the "Wrap an existing API" tutorial still says "Placeholder." and the file has no tutorial body; update the frontmatter "description" to a real one-line summary and then replace the placeholder with a runnable, Divio-compliant tutorial body that includes prerequisites, step-by-step commands, copy-pasteable examples, expected outputs, and any config snippets (or alternatively remove it from navigation by marking the page as hidden/draft in frontmatter); ensure the page follows the Divio docs structure (title, short description, numbered steps, code blocks, and a concluding verification step) so the tutorial is not a dead-end.docs/0-17-0/tutorials/reactive-crud/realtime-subscriptions.mdx (1)
1-7:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace placeholder-only tutorial page with minimum actionable content.
Line 3 uses
"Placeholder.", and Lines 1-7 define a tutorial page with no body. This publishes an empty tutorial route and breaks task-oriented doc flow.Suggested fix
--- title: "Realtime subscriptions" -description: "Placeholder." +description: "Stream state changes from iii to connected clients in real time." owner: "devrel" type: "tutorial" --- + +This step wires realtime subscriptions so clients receive updates as CRUD operations mutate state. + +## What you'll add + +- A subscription endpoint for client connections +- Event emission on create/update/delete +- A client listener that applies incoming changes + +## Next + +Implement the subscription handler and broadcast state-change events from your CRUD functions.As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under
docs/."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/0-17-0/tutorials/reactive-crud/realtime-subscriptions.mdx` around lines 1 - 7, The frontmatter in the "Realtime subscriptions" tutorial currently uses a placeholder description and the page has no body, publishing an empty tutorial route; update the frontmatter (title: "Realtime subscriptions", description: replace "Placeholder." with a concise summary of the page purpose) and add minimal actionable content below the frontmatter such as a brief intro, a short list of prerequisites, and a one-step example of subscribing to realtime updates (so the page is non-empty and task-oriented); ensure the page follows Divio docs conventions and contains at least a paragraph and one code/example block to make the tutorial actionable.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/0-17-0/creating-workers/workers.mdx`:
- Around line 80-83: The example calls register_worker with
os.environ.get("III_URL") which can be None; update the snippet to read the env
var into a local (e.g., iii_url = os.environ.get("III_URL") or
os.getenv("III_URL")), guard it and fail fast if missing (raise a clear
RuntimeError/ValueError or assert) before calling register_worker with
InitOptions(worker_name="my-worker"), so register_worker always receives a
non-null URL.
- Around line 406-411: The Python tab should guard against a missing III_URL
before calling register_worker by checking the environment value and raising or
exiting with a clear error if it's None (e.g., verify III_URL and raise
ValueError or use os.environ[...]), because register_worker(address: str, ...)
and the connect logic expect a string; update the example around the Python
register_worker call to perform this explicit check; leave the Rust examples
using RegisterTriggerInput { ..., metadata: None } unchanged since metadata:
None matches the SDK type Option<Value>.
In `@docs/0-17-0/how-to/schedule-cron-task.mdx`:
- Line 8: The MDX currently contains only a TODO placeholder and must be
replaced with a complete how-to: open the schedule-cron-task.mdx document and
replace the TODO comment with concise, Divio-style step-by-step instructions
that cover installing/enabling the iii-cron plugin, registering a function (show
the function name you expect callers to use), binding it to a cron trigger with
a schedule expression (include examples of common cron strings), how to verify
the job fires, explicit notes on timezone behavior and overlap handling (skip vs
queue), and how to manually invoke the cron job for testing; if you cannot
produce the full guide now, remove the page from navigation/version until
content is ready. Ensure the final content follows the Divio documentation
system conventions.
In `@docs/0-17-0/how-to/use-trigger-conditions.mdx`:
- Line 8: Replace the placeholder TODO in the how-to with a concrete, navigable
how-to: include step-by-step instructions for (1) registering a condition
function that returns truthy/falsey for the same payload the handler receives
(describe the required signature and where to register it), (2) registering a
trigger and setting its condition_function_id to that condition, (3) how to
test/verify that the handler (the trigger’s handler) only runs when the
condition passes (describe sample test payloads or test harness), and (4) a
realistic, worked example (e.g., an HTTP trigger gated by an auth check) plus a
short note when to prefer a condition function versus branching inside the
handler; ensure the doc follows Divio docs conventions and remove the TODO
comment so the page is ready for navigation.
In `@docs/0-17-0/install.mdx`:
- Around line 27-30: The doc's "Engine and SDK versions" info block contains a
stale minor-version example (`0.11.x`); update that example to the current minor
line (e.g., replace `0.11.x` with `0.17.x`) so the text inside the <Info
title="Engine and SDK versions"> block reflects the 0-17-0 docs; ensure the
replacement occurs for the `0.11.x` literal in that paragraph.
In `@docs/0-17-0/sdk-reference/node-sdk.mdx`:
- Around line 124-127: The docs currently say `invocation_stopped` means an
engine timeout; update the description to state that `invocation_stopped`
indicates the worker disconnected mid-flight (worker lost connection) and not an
engine timeout, adjust any retry/diagnostic guidance accordingly, and review
other occurrences under the engine/ protocol references to align wording (search
for `invocation_stopped` and the engine timeout description in related docs and
correct them to the worker-disconnect meaning).
In `@docs/0-17-0/sdk-reference/rust-sdk.mdx`:
- Around line 104-110: The docs currently show a synchronous shutdown API
`shutdown(&self)` but the Rust SDK exposes an async lifecycle method to ensure
telemetry flush; update the documentation to reference and demonstrate
`shutdown_async` (e.g., `pub async fn shutdown_async(&self)`) and show calling
code awaiting it (`.await`) so users call the async shutdown path instead of the
old synchronous `shutdown`.
In `@docs/0-17-0/tutorials/build-an-agent/orchestration-loop.mdx`:
- Line 3: The frontmatter 'description' currently contains the generic string
"Placeholder." which must be replaced with a concise, specific one-sentence
summary that follows the Divio documentation style (informational,
present-tense, audience-focused); update the 'description' metadata in the
document's frontmatter (the description field at the top of the file) to a
single clear sentence that summarizes the tutorial's purpose and audience (e.g.,
what the orchestration loop teaches and who it's for).
In `@docs/0-17-0/tutorials/incremental-adoption/migrate-persistence.mdx`:
- Line 3: The frontmatter "description" currently contains the placeholder text
"Placeholder."; replace it with a concise, concrete tutorial summary in the file
migrate-persistence.mdx that follows the Divio docs style (one to two
sentences), e.g., state the tutorial goal, target audience, and main steps
covered (migrating persistence, incremental adoption strategy, and
prerequisites); ensure it reads like a discoverable summary rather than a
placeholder and update the description metadata value accordingly.
In `@docs/0-17-0/tutorials/incremental-adoption/offload-to-queue.mdx`:
- Line 3: Update the frontmatter metadata key "description" (currently
"Placeholder.") to a concise, meaningful one-line summary of the tutorial (e.g.,
what the reader will learn or achieve by following it) that follows the Divio
documentation style; locate the "description" field in the frontmatter of
offload-to-queue.mdx and replace the placeholder string with that descriptive
sentence.
In `@docs/0-17-0/understanding-iii/index.mdx`:
- Line 237: Remove or resolve the inline editor TODO comment "TODO: Confirm if
we still have restricted string prefixes" in the published docs page: either
confirm the status and replace the TODO with the resolved explanatory sentence
about restricted string prefixes, or delete the TODO line entirely so no
internal editing note remains in understanding-iii/index.mdx.
In `@docs/0-17-0/using-iii/cli.mdx`:
- Line 55: Remove the internal verification directive "// llm-only: Always
verify the claim about iii cloud..." from the user-facing docs source; locate
the HTML/JSX comment containing the "llm-only" token in the CLI docs (the
commented line shown in the diff) and either delete it or move it into an
internal-only notes file so published .mdx content contains no "llm-only"
directives.
- Line 43: The in-page anchor `[Updating iii itself](`#updating-iii-itself`)`
doesn't match the actual heading `## Updating iii`, so update the link to use
the correct slug (e.g., `[Updating iii itself](`#updating-iii`)`) or rename the
heading to `## Updating iii itself` so the anchor matches; ensure the anchor
text and the heading slug (the link `[Updating iii
itself](`#updating-iii-itself`)` or the heading `## Updating iii`) are made
identical to restore the link.
In `@docs/0-17-0/using-iii/console.mdx`:
- Around line 27-30: Remove the internal naming-review Note that mentions `iii
console` and `project-rules/cli.md` from the user-facing console documentation
(the Note block containing "Naming review: `iii console`...") and instead
relocate that remark to the internal guideline or PR/issue (e.g.,
project-rules/cli.md or an internal review comment); leave the console.mdx
content as purely user-facing guidance about the `iii console` command and its
behavior.
In `@docs/0-17-0/using-iii/deployment.mdx`:
- Line 18: Remove the internal LLM-only directive from the user-facing MDX
source: find and delete the inline comment containing "llm-only" (the string "/*
llm-only: Always verify the claim about iii cloud above, it could have changed
since when this document was written. */") so the documentation no longer
exposes internal verification notes; save and commit the cleaned deployment.mdx
change.
In `@docs/0-17-0/using-iii/workers.mdx.skill.md`:
- Line 1: Update the generated source-path hint on the first line so it points
to the versioned snapshot path rather than the unversioned doc: replace
"docs/using-iii/workers.mdx" with "docs/0-17-0/using-iii/workers.mdx" in the
header comment at the top of docs/0-17-0/using-iii/workers.mdx.skill.md (the
generated-file marker added by iii-skill-render) so contributors are directed to
the correct immutable snapshot.
In `@docs/docs.json`:
- Around line 155-235: The 0.17 navigation omits the newly added sections;
update docs.json (the "Docs" tab entry and/or its "groups" array) to include new
groups/pages for the 0-17-0/how-to/*, 0-17-0/patterns/* and 0-17-0/tutorials/*
routes so they appear in primary version navigation—add new group objects (e.g.,
{"group":"How-to","pages":["0-17-0/how-to/…"]},
{"group":"Patterns","pages":["0-17-0/patterns/…"]},
{"group":"Tutorials","pages":["0-17-0/tutorials/…"]}) or append the specific
page IDs into existing relevant groups in the "Docs" tab to make those pages
discoverable.
---
Outside diff comments:
In `@docs/0-17-0/how-to/build-a-realtime-todo-app.mdx`:
- Around line 8-54: The document is only an outline and missing concrete,
executable steps, code samples, and expected outcomes required for a type:
"how-to" page; expand the how-to by adding step-by-step instructions, runnable
code snippets, configuration examples (e.g., config.yaml), expected outputs, and
minimal end-to-end validation steps for each section (Engine configuration,
Worker setup, Auth function (RBAC), Stream wrapper, Functions, Connection,
Real-time hook) so readers can reproduce the tutorial; ensure the new content
follows the Divio documentation system conventions (structure, admonitions, code
blocks, and examples) and mark or hide the page until complete if you cannot
supply full runnable guidance.
In `@docs/0-17-0/tutorials/build-an-agent/define-tools.mdx`:
- Around line 1-7: The tutorial page contains only frontmatter (title: "Define
tools", description, owner, type) and no content; either add a minimal runnable
tutorial flow under this frontmatter (intro, prerequisites, step-by-step example
demonstrating how to define a tool with commands/examples and a "try it"
snippet) or remove/hide the page from navigation until it's ready; update the
file's content to replace the placeholder with real tutorial sections
(Introduction, Prerequisites, Steps with concrete code examples, Expected
outcome) or remove the page entry so it doesn't expose an empty route.
In `@docs/0-17-0/tutorials/build-an-agent/memory-and-state.mdx`:
- Around line 1-7: The page "Memory and state" currently contains only
frontmatter and placeholder metadata; either populate it with a concrete
tutorial sequence following Divio documentation conventions (add an
introduction, prerequisites, step-by-step walkthrough, examples, and a short
summary) or remove/unpublish it from the navigation until ready; locate the MDX
file with title "Memory and state" and replace the placeholder body with the
full tutorial content (or update the frontmatter/published flag so it is not
included in the site build) to comply with the docs guidelines.
In `@docs/0-17-0/tutorials/incremental-adoption/wrap-existing-api.mdx`:
- Around line 1-7: The frontmatter description for the "Wrap an existing API"
tutorial still says "Placeholder." and the file has no tutorial body; update the
frontmatter "description" to a real one-line summary and then replace the
placeholder with a runnable, Divio-compliant tutorial body that includes
prerequisites, step-by-step commands, copy-pasteable examples, expected outputs,
and any config snippets (or alternatively remove it from navigation by marking
the page as hidden/draft in frontmatter); ensure the page follows the Divio docs
structure (title, short description, numbered steps, code blocks, and a
concluding verification step) so the tutorial is not a dead-end.
In `@docs/0-17-0/tutorials/reactive-crud/crud-endpoints.mdx`:
- Around line 1-7: The tutorial page with title "CRUD endpoints" currently has a
frontmatter description set to "Placeholder." and contains no instructional
content; replace the placeholder description with a concise summary and add a
step-by-step Divio-style tutorial body that covers creating, reading, updating,
and deleting endpoints (include prerequisites, code examples, expected outputs,
and verification steps) so the page is a complete task-oriented walkthrough;
update the frontmatter "description" and populate the Markdown body under the
existing title in the same file to satisfy docs/** Divio tutorial expectations.
In `@docs/0-17-0/tutorials/reactive-crud/model-and-store.mdx`:
- Around line 1-7: The frontmatter for the "Model and store" tutorial uses a
placeholder description ("Placeholder.") and contains no tutorial content,
causing a broken tutorial; replace the placeholder by either adding a full
Divio-style tutorial body (concrete guided steps, headings, code examples, and
step-by-step instructions) under the file's content and update the description
to a meaningful summary, or remove this file from the published version set;
ensure the frontmatter fields title ("Model and store") and description are
accurate and that the document follows the Divio tutorial model so it can be
included in the versioned docs.
In `@docs/0-17-0/tutorials/reactive-crud/realtime-subscriptions.mdx`:
- Around line 1-7: The frontmatter in the "Realtime subscriptions" tutorial
currently uses a placeholder description and the page has no body, publishing an
empty tutorial route; update the frontmatter (title: "Realtime subscriptions",
description: replace "Placeholder." with a concise summary of the page purpose)
and add minimal actionable content below the frontmatter such as a brief intro,
a short list of prerequisites, and a one-step example of subscribing to realtime
updates (so the page is non-empty and task-oriented); ensure the page follows
Divio docs conventions and contains at least a paragraph and one code/example
block to make the tutorial actionable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: f0662ec3-12be-4c89-8263-7a9fb4817f97
⛔ Files ignored due to path filters (3)
docs/0-17-0/assets/favicon.svgis excluded by!**/*.svgdocs/0-17-0/assets/iii-black.svgis excluded by!**/*.svgdocs/0-17-0/assets/iii-white.svgis excluded by!**/*.svg
📒 Files selected for processing (91)
docs/0-17-0/changelog/0-11-0/everything-is-a-worker.mdxdocs/0-17-0/changelog/0-11-0/migrated-examples.mdxdocs/0-17-0/changelog/0-11-0/migrating-from-motia-js.mdxdocs/0-17-0/changelog/0-11-0/migrating-from-motia-py.mdxdocs/0-17-0/changelog/0-16-0/align-rust-register-function-with-signature.mdxdocs/0-17-0/changelog/index.mdxdocs/0-17-0/creating-workers/channels.mdxdocs/0-17-0/creating-workers/channels.mdx.skill.mddocs/0-17-0/creating-workers/functions.mdxdocs/0-17-0/creating-workers/functions.mdx.skill.mddocs/0-17-0/creating-workers/index.mdxdocs/0-17-0/creating-workers/index.mdx.skill.mddocs/0-17-0/creating-workers/triggers.mdxdocs/0-17-0/creating-workers/triggers.mdx.skill.mddocs/0-17-0/creating-workers/workers-registry.mdxdocs/0-17-0/creating-workers/workers-registry.mdx.skill.mddocs/0-17-0/creating-workers/workers.mdxdocs/0-17-0/creating-workers/workers.mdx.skill.mddocs/0-17-0/how-to/build-a-realtime-todo-app.mdxdocs/0-17-0/how-to/build-a-realtime-todo-app.mdx.skill.mddocs/0-17-0/how-to/schedule-cron-task.mdxdocs/0-17-0/how-to/schedule-cron-task.mdx.skill.mddocs/0-17-0/how-to/use-trigger-conditions.mdxdocs/0-17-0/how-to/use-trigger-conditions.mdx.skill.mddocs/0-17-0/index.mdxdocs/0-17-0/index.mdx.skill.mddocs/0-17-0/install.mdxdocs/0-17-0/install.mdx.skill.mddocs/0-17-0/patterns/adapter-pattern.mdxdocs/0-17-0/patterns/adapter-pattern.mdx.skill.mddocs/0-17-0/patterns/reactive-state-pattern.mdxdocs/0-17-0/patterns/reactive-state-pattern.mdx.skill.mddocs/0-17-0/quickstart.mdxdocs/0-17-0/quickstart.mdx.skill.mddocs/0-17-0/sdk-reference/browser-sdk.mdxdocs/0-17-0/sdk-reference/browser-sdk.mdx.skill.mddocs/0-17-0/sdk-reference/engine-sdk.mdxdocs/0-17-0/sdk-reference/engine-sdk.mdx.skill.mddocs/0-17-0/sdk-reference/node-sdk.mdxdocs/0-17-0/sdk-reference/node-sdk.mdx.skill.mddocs/0-17-0/sdk-reference/python-sdk.mdxdocs/0-17-0/sdk-reference/python-sdk.mdx.skill.mddocs/0-17-0/sdk-reference/rust-sdk.mdxdocs/0-17-0/sdk-reference/rust-sdk.mdx.skill.mddocs/0-17-0/tutorials/build-an-agent/define-tools.mdxdocs/0-17-0/tutorials/build-an-agent/define-tools.mdx.skill.mddocs/0-17-0/tutorials/build-an-agent/memory-and-state.mdxdocs/0-17-0/tutorials/build-an-agent/memory-and-state.mdx.skill.mddocs/0-17-0/tutorials/build-an-agent/orchestration-loop.mdxdocs/0-17-0/tutorials/build-an-agent/orchestration-loop.mdx.skill.mddocs/0-17-0/tutorials/build-an-agent/overview.mdxdocs/0-17-0/tutorials/build-an-agent/overview.mdx.skill.mddocs/0-17-0/tutorials/incremental-adoption/migrate-persistence.mdxdocs/0-17-0/tutorials/incremental-adoption/migrate-persistence.mdx.skill.mddocs/0-17-0/tutorials/incremental-adoption/offload-to-queue.mdxdocs/0-17-0/tutorials/incremental-adoption/offload-to-queue.mdx.skill.mddocs/0-17-0/tutorials/incremental-adoption/overview.mdxdocs/0-17-0/tutorials/incremental-adoption/overview.mdx.skill.mddocs/0-17-0/tutorials/incremental-adoption/wrap-existing-api.mdxdocs/0-17-0/tutorials/incremental-adoption/wrap-existing-api.mdx.skill.mddocs/0-17-0/tutorials/reactive-crud/crud-endpoints.mdxdocs/0-17-0/tutorials/reactive-crud/crud-endpoints.mdx.skill.mddocs/0-17-0/tutorials/reactive-crud/model-and-store.mdxdocs/0-17-0/tutorials/reactive-crud/model-and-store.mdx.skill.mddocs/0-17-0/tutorials/reactive-crud/overview.mdxdocs/0-17-0/tutorials/reactive-crud/overview.mdx.skill.mddocs/0-17-0/tutorials/reactive-crud/realtime-subscriptions.mdxdocs/0-17-0/tutorials/reactive-crud/realtime-subscriptions.mdx.skill.mddocs/0-17-0/understanding-iii/channels.mdxdocs/0-17-0/understanding-iii/channels.mdx.skill.mddocs/0-17-0/understanding-iii/engine.mdxdocs/0-17-0/understanding-iii/engine.mdx.skill.mddocs/0-17-0/understanding-iii/index.mdxdocs/0-17-0/understanding-iii/index.mdx.skill.mddocs/0-17-0/using-iii/cli.mdxdocs/0-17-0/using-iii/cli.mdx.skill.mddocs/0-17-0/using-iii/console.mdxdocs/0-17-0/using-iii/console.mdx.skill.mddocs/0-17-0/using-iii/deployment.mdxdocs/0-17-0/using-iii/deployment.mdx.skill.mddocs/0-17-0/using-iii/engine.mdxdocs/0-17-0/using-iii/engine.mdx.skill.mddocs/0-17-0/using-iii/functions.mdxdocs/0-17-0/using-iii/functions.mdx.skill.mddocs/0-17-0/using-iii/triggers.mdxdocs/0-17-0/using-iii/triggers.mdx.skill.mddocs/0-17-0/using-iii/workers-registry.mdxdocs/0-17-0/using-iii/workers-registry.mdx.skill.mddocs/0-17-0/using-iii/workers.mdxdocs/0-17-0/using-iii/workers.mdx.skill.mddocs/docs.json
Comment on lines
+80
to
+83
| worker = register_worker( | ||
| os.environ.get("III_URL"), | ||
| InitOptions(worker_name="my-worker"), | ||
| ) |
Contributor
There was a problem hiding this comment.
Make the Python connect example fail fast when III_URL is missing.
This currently passes a nullable value from os.environ.get("III_URL") directly; adding a guard keeps behavior consistent with the Node/Rust examples and prevents a misleading copy-paste runtime failure.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/creating-workers/workers.mdx` around lines 80 - 83, The example
calls register_worker with os.environ.get("III_URL") which can be None; update
the snippet to read the env var into a local (e.g., iii_url =
os.environ.get("III_URL") or os.getenv("III_URL")), guard it and fail fast if
missing (raise a clear RuntimeError/ValueError or assert) before calling
register_worker with InitOptions(worker_name="my-worker"), so register_worker
always receives a non-null URL.
Comment on lines
+406
to
+411
| worker.register_trigger(RegisterTriggerInput { | ||
| trigger_type: "engine::workers-available".into(), | ||
| function_id: "discovery::on-workers".into(), | ||
| config: json!({}), | ||
| metadata: None, | ||
| })?; |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify current in-repo convention for RegisterTriggerInput usage in docs.
rg -n -C2 'RegisterTriggerInput\s*\{' docs | head -n 200
rg -n -C2 'trigger_type:|function_id:|config:|metadata:' docs/0-17-0 docs | head -n 300Repository: iii-hq/iii
Length of output: 31021
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="docs/0-17-0/creating-workers/workers.mdx"
echo "=== workers.mdx:406-430 ==="
sed -n '395,440p' "$FILE" | nl -ba | sed 's/^/| /'
echo "=== Count RegisterTriggerInput blocks in docs/0-17-0/creating-workers ==="
rg -n "RegisterTriggerInput\s*\{" docs/0-17-0/creating-workers | wc -l
echo "=== Count metadata usage near RegisterTriggerInput in docs/0-17-0/creating-workers ==="
rg -n "RegisterTriggerInput\s*\{[\s\S]*?metadata:" docs/0-17-0/creating-workers -U | wc -l || true
echo "=== Count metadata: None in entire docs/0-17-0 ==="
rg -n "RegisterTriggerInput\s*\{" docs/0-17-0 | wc -l
rg -n "metadata:\s*None" docs/0-17-0 | wc -lRepository: iii-hq/iii
Length of output: 143
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="docs/0-17-0/creating-workers/workers.mdx"
echo "=== workers.mdx:395-440 (with line numbers) ==="
sed -n '395,440p' "$FILE" | cat -n
echo "=== Count RegisterTriggerInput blocks in docs/0-17-0/creating-workers ==="
rg -n "RegisterTriggerInput\s*\{" docs/0-17-0/creating-workers | wc -l
echo "=== metadata: occurrences in RegisterTriggerInput blocks under docs/0-17-0/creating-workers ==="
# Count lines containing metadata: None within the file(s) (fast/robust)
rg -n "metadata:\s*None" docs/0-17-0/creating-workers | wc -l
echo "=== metadata: occurrences within docs/0-17-0/creating-workers (any value) ==="
rg -n "metadata:" docs/0-17-0/creating-workers | wc -l
echo "=== metadata: occurrences within docs/**/RegisterTriggerInput blocks (approx by counting lines) ==="
rg -n "metadata:" docs/0-17-0 | wc -lRepository: iii-hq/iii
Length of output: 2503
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Locate the RegisterTriggerInput definition in the Rust code
rg -n "struct RegisterTriggerInput" -S . | head -n 50
# 2) If found, print a small surrounding region for the definition
# (Try common file patterns too, but don't assume paths.)
def_file="$(rg -n "struct RegisterTriggerInput" -S . | head -n 1 | cut -d: -f1 || true)"
if [ -n "${def_file:-}" ]; then
echo "=== Definition context: $def_file ==="
sed -n '1,200p' "$def_file" >/dev/null 2>&1 || true
# Print from the line where struct begins up to ~80 lines after
start_line="$(rg -n "struct RegisterTriggerInput" -S . | head -n 1 | cut -d: -f2)"
end_line=$((start_line+120))
sed -n "${start_line},${end_line}p" "$def_file" | cat -n
fi
# 3) Also look for any mentions of `metadata:` with RegisterTriggerInput (to see usage patterns)
rg -n "RegisterTriggerInput\s*\{[\s\S]*metadata" -S . | head -n 50
# 4) Check if docs mention a "required fields only" pattern anywhere (optional)
rg -n "required fields|trigger_type.*function_id.*config" docs .cursor | head -n 50Repository: iii-hq/iii
Length of output: 5539
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Look for any in-repo guidance mentioning "required fields" / RegisterTriggerInput field pattern.
rg -n "RegisterTriggerInput|required fields|trigger_type.*function_id.*config|metadata.*None" .cursor docs sdk | head -n 200
# 2) Inspect the Python snippet around the referenced lines (80-90 area) in the target doc.
FILE="docs/0-17-0/creating-workers/workers.mdx"
sed -n '60,120p' "$FILE" | cat -n
# 3) Inspect the Rust snippets around the referenced line ranges to ensure exact content.
sed -n '380,440p' "$FILE" | cat -nRepository: iii-hq/iii
Length of output: 24252
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "def register_worker" -S sdk/packages/python/iii/src/iii | head -n 50
python_file="$(rg -n "def register_worker" -S sdk/packages/python/iii/src/iii | head -n 1 | cut -d: -f1 || true)"
echo "FILE=$python_file"
if [ -n "${python_file:-}" ]; then
start_line="$(rg -n "def register_worker" -S "$python_file" | head -n 1 | cut -d: -f2)"
end_line=$((start_line+120))
sed -n "${start_line},${end_line}p" "$python_file" | cat -n
fi
rg -n "os\.environ\.get\(\"III_URL\"\)" -S docs/0-17-0/creating-workers/workers.mdxRepository: iii-hq/iii
Length of output: 380
🏁 Script executed:
#!/bin/bash
set -euo pipefail
PY_FILE="sdk/packages/python/iii/src/iii/iii.py"
# Print the signature + a bit of context around register_worker
rg -n "def register_worker\\(" "$PY_FILE" | head -n 20
line="$(rg -n "def register_worker\\(" "$PY_FILE" | head -n 1 | cut -d: -f1)"
start=$((line-30))
end=$((line+120))
sed -n "${start},${end}p" "$PY_FILE" | cat -n
# Also inspect how "address" is used (quick search within the function body)
rg -n "register_worker\\(address" "$PY_FILE" || true
rg -n "address" "$PY_FILE" | head -n 50
# Show the exact Python snippet from the docs around III_URL
DOC="docs/0-17-0/creating-workers/workers.mdx"
rg -n "os\\.environ\\.get\\(\"III_URL\"\\)" "$DOC" -n
docline="$(rg -n "os\\.environ\\.get\\(\"III_URL\"\\)" "$DOC" | head -n 1 | cut -d: -f1)"
sed -n "$((docline-10)),$((docline+15))p" "$DOC" | cat -nRepository: iii-hq/iii
Length of output: 4314
🏁 Script executed:
#!/bin/bash
set -euo pipefail
PY_FILE="sdk/packages/python/iii/src/iii/iii.py"
# Inspect III class __init__ around where address is stored/used
class_line="$(rg -n "^class III\\b" "$PY_FILE" | head -n 1 | cut -d: -f1)"
init_line="$(rg -n "def __init__\\(self, address: str" "$PY_FILE" | head -n 1 | cut -d: -f1 || true)"
echo "class_line=$class_line init_line=$init_line"
# Print around __init__
if [ -n "${init_line:-}" ]; then
sed -n "$((init_line-20)),$((init_line+80))p" "$PY_FILE" | cat -n
fi
# Find any immediate usage that would break if address is None (string ops, websocket URL checks)
rg -n "self\\._address|_address" "$PY_FILE" | head -n 80
# Find where ChannelWriter/Reader are constructed / used
rg -n "ChannelWriter\\(|ChannelReader\\(" "$PY_FILE" || trueRepository: iii-hq/iii
Length of output: 5797
🏁 Script executed:
#!/bin/bash
set -euo pipefail
PY_FILE="sdk/packages/python/iii/src/iii/iii.py"
# Show connect_async body around where it uses self._address
connect_start="$(rg -n "async def connect_async" "$PY_FILE" | head -n 1 | cut -d: -f1)"
connect_end=$((connect_start+220))
sed -n "${connect_start},${connect_end}p" "$PY_FILE" | cat -n
# Find the websocket connection call(s)
rg -n "websockets\\.connect|ClientConnection|connect\\(|ws://|wss://" "$PY_FILE" | head -n 80
# Show any explicit validation of address/url
rg -n "address.*None|None.*address|expect|raise.*address|III_URL must be set|str\\(address\\)" "$PY_FILE" || trueRepository: iii-hq/iii
Length of output: 11407
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "os\.environ\.get\(\"III_URL\"\)" docs | head -n 50
rg -n "III_URL must be set|os\.environ\[\"III_URL\"\]|os\.environ\.get\(\"III_URL\"\)\s*[^\\n]*expect|assert .*III_URL" docs | head -n 50
rg -n "register_worker\\(" docs/0-17-0/creating-workers/workers.mdx docs/0-17-0/creating-workers/workers.mdx.skill.md | head -n 50Repository: iii-hq/iii
Length of output: 9739
Fix Python III_URL handling in docs/0-17-0/creating-workers/workers.mdx; keep Rust metadata: None examples
- The Python tab uses
register_worker(os.environ.get("III_URL"), ...), which can passNoneeven though the SDK signature isregister_worker(address: str, ...)and the connect code uses it directly; add an explicit guard/raise whenIII_URLis unset (Node/Rust tabs already do this). - The Rust
RegisterTriggerInput { ..., metadata: None }snippets at lines 406-411 and 421-426 match the SDK type (metadata: Option<Value>), so no adjustment is needed there.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/creating-workers/workers.mdx` around lines 406 - 411, The Python
tab should guard against a missing III_URL before calling register_worker by
checking the environment value and raising or exiting with a clear error if it's
None (e.g., verify III_URL and raise ValueError or use os.environ[...]), because
register_worker(address: str, ...) and the connect logic expect a string; update
the example around the Python register_worker call to perform this explicit
check; leave the Rust examples using RegisterTriggerInput { ..., metadata: None
} unchanged since metadata: None matches the SDK type Option<Value>.
| type: "how-to" | ||
| --- | ||
|
|
||
| {/* TODO: write the how-to. Cover installing/enabling iii-cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */} |
Contributor
There was a problem hiding this comment.
Replace the TODO-only body with real how-to steps before shipping.
This currently publishes as an empty guide. Either complete it now or remove it from nav/version until content is ready.
As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under docs/."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/how-to/schedule-cron-task.mdx` at line 8, The MDX currently
contains only a TODO placeholder and must be replaced with a complete how-to:
open the schedule-cron-task.mdx document and replace the TODO comment with
concise, Divio-style step-by-step instructions that cover installing/enabling
the iii-cron plugin, registering a function (show the function name you expect
callers to use), binding it to a cron trigger with a schedule expression
(include examples of common cron strings), how to verify the job fires, explicit
notes on timezone behavior and overlap handling (skip vs queue), and how to
manually invoke the cron job for testing; if you cannot produce the full guide
now, remove the page from navigation/version until content is ready. Ensure the
final content follows the Divio documentation system conventions.
| type: "how-to" | ||
| --- | ||
|
|
||
| {/* TODO: write the how-to. Cover registering a condition function (returns truthy/falsey from the same payload the handler would see), registering the trigger with `condition_function_id` set, verifying the handler runs only when the condition passes. Show one realistic example (e.g. HTTP trigger gated by an auth check) and call out when to prefer this over branching inside the handler. */} |
Contributor
There was a problem hiding this comment.
This page is still a placeholder and should not ship as a how-to.
Please replace the TODO with concrete steps/examples (or keep it out of navigation until complete).
As per coding guidelines: "Use the Divio documentation system as the governing documentation approach for anything under docs/."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/how-to/use-trigger-conditions.mdx` at line 8, Replace the
placeholder TODO in the how-to with a concrete, navigable how-to: include
step-by-step instructions for (1) registering a condition function that returns
truthy/falsey for the same payload the handler receives (describe the required
signature and where to register it), (2) registering a trigger and setting its
condition_function_id to that condition, (3) how to test/verify that the handler
(the trigger’s handler) only runs when the condition passes (describe sample
test payloads or test harness), and (4) a realistic, worked example (e.g., an
HTTP trigger gated by an auth check) plus a short note when to prefer a
condition function versus branching inside the handler; ensure the doc follows
Divio docs conventions and remove the TODO comment so the page is ready for
navigation.
Comment on lines
+27
to
+30
| <Info title="Engine and SDK versions"> | ||
| The engine and SDK packages can have different patch versions within the same minor line. Keep the | ||
| engine and SDKs on the same minor version, for example `0.11.x`, unless a release note says | ||
| otherwise. |
Contributor
There was a problem hiding this comment.
Update the minor-version example to the current doc line.
Line 29 uses 0.11.x, which is stale in the 0-17-0 docs and can mislead version alignment guidance. Please update the example to the current minor line (e.g., 0.17.x).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/install.mdx` around lines 27 - 30, The doc's "Engine and SDK
versions" info block contains a stale minor-version example (`0.11.x`); update
that example to the current minor line (e.g., replace `0.11.x` with `0.17.x`) so
the text inside the <Info title="Engine and SDK versions"> block reflects the
0-17-0 docs; ensure the replacement occurs for the `0.11.x` literal in that
paragraph.
|
|
||
| <Note>iii's cloud will be available soon.</Note> | ||
|
|
||
| {/* llm-only: Always verify the claim about iii cloud above, it could have changed since when this document was written. */} |
Contributor
There was a problem hiding this comment.
Remove LLM-only directive from user-facing docs source.
This internal verification instruction should stay out of published documentation content files.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/using-iii/cli.mdx` at line 55, Remove the internal verification
directive "// llm-only: Always verify the claim about iii cloud..." from the
user-facing docs source; locate the HTML/JSX comment containing the "llm-only"
token in the CLI docs (the commented line shown in the diff) and either delete
it or move it into an internal-only notes file so published .mdx content
contains no "llm-only" directives.
Comment on lines
+27
to
+30
| <Note> | ||
| Naming review: `iii console` is verb-shaped (launches the console) but doesn't follow the `iii | ||
| noun verb` convention used elsewhere in the CLI. Flagged for naming review per | ||
| `project-rules/cli.md`. |
Contributor
There was a problem hiding this comment.
Move internal naming-review note out of end-user docs.
This is an internal process remark (project-rules/cli.md) and reads as implementation chatter for users.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/using-iii/console.mdx` around lines 27 - 30, Remove the internal
naming-review Note that mentions `iii console` and `project-rules/cli.md` from
the user-facing console documentation (the Note block containing "Naming review:
`iii console`...") and instead relocate that remark to the internal guideline or
PR/issue (e.g., project-rules/cli.md or an internal review comment); leave the
console.mdx content as purely user-facing guidance about the `iii console`
command and its behavior.
|
|
||
| <Note>iii's cloud will be available soon.</Note> | ||
|
|
||
| {/* llm-only: Always verify the claim about iii cloud above, it could have changed since when this document was written. */} |
Contributor
There was a problem hiding this comment.
Remove LLM-only verification note from documentation source.
This internal directive should not live in user-facing documentation files.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/using-iii/deployment.mdx` at line 18, Remove the internal
LLM-only directive from the user-facing MDX source: find and delete the inline
comment containing "llm-only" (the string "/* llm-only: Always verify the claim
about iii cloud above, it could have changed since when this document was
written. */") so the documentation no longer exposes internal verification
notes; save and commit the cleaned deployment.mdx change.
| @@ -0,0 +1,177 @@ | |||
| <!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/using-iii/workers.mdx. --> | |||
Contributor
There was a problem hiding this comment.
Fix the generated source-path hint for the versioned doc.
Line 1 points contributors to docs/using-iii/workers.mdx, but this file belongs to the 0-17-0 snapshot. That can cause edits to land in the wrong version.
Suggested fix
-<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/using-iii/workers.mdx. -->
+<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/0-17-0/using-iii/workers.mdx. -->📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/using-iii/workers.mdx. --> | |
| <!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/0-17-0/using-iii/workers.mdx. --> |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/0-17-0/using-iii/workers.mdx.skill.md` at line 1, Update the generated
source-path hint on the first line so it points to the versioned snapshot path
rather than the unversioned doc: replace "docs/using-iii/workers.mdx" with
"docs/0-17-0/using-iii/workers.mdx" in the header comment at the top of
docs/0-17-0/using-iii/workers.mdx.skill.md (the generated-file marker added by
iii-skill-render) so contributors are directed to the correct immutable
snapshot.
Comment on lines
+155
to
+235
| { | ||
| "tab": "Docs", | ||
| "groups": [ | ||
| { | ||
| "group": "Getting Started", | ||
| "pages": ["0-17-0/index", "0-17-0/install", "0-17-0/quickstart"] | ||
| }, | ||
| { | ||
| "group": "Using iii", | ||
| "pages": [ | ||
| "0-17-0/using-iii/workers", | ||
| "0-17-0/using-iii/workers-registry", | ||
| "0-17-0/using-iii/triggers", | ||
| "0-17-0/using-iii/functions", | ||
| "0-17-0/using-iii/engine", | ||
| "0-17-0/using-iii/console", | ||
| "0-17-0/using-iii/cli", | ||
| "0-17-0/using-iii/deployment" | ||
| ] | ||
| }, | ||
| { | ||
| "group": "Understanding iii", | ||
| "expanded": false, | ||
| "pages": [ | ||
| "0-17-0/understanding-iii/index", | ||
| "0-17-0/understanding-iii/engine", | ||
| "0-17-0/understanding-iii/channels" | ||
| ] | ||
| }, | ||
| { | ||
| "group": "Creating Workers", | ||
| "pages": [ | ||
| "0-17-0/creating-workers/index", | ||
| "0-17-0/creating-workers/workers", | ||
| "0-17-0/creating-workers/triggers", | ||
| "0-17-0/creating-workers/functions", | ||
| "0-17-0/creating-workers/channels" | ||
| ] | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "tab": "SDK & Engine Reference", | ||
| "groups": [ | ||
| { | ||
| "group": "Engine protocol", | ||
| "pages": ["0-17-0/sdk-reference/engine-sdk"] | ||
| }, | ||
| { | ||
| "group": "Language SDKs", | ||
| "pages": [ | ||
| "0-17-0/sdk-reference/node-sdk", | ||
| "0-17-0/sdk-reference/python-sdk", | ||
| "0-17-0/sdk-reference/rust-sdk", | ||
| "0-17-0/sdk-reference/browser-sdk" | ||
| ] | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "tab": "Changelog", | ||
| "groups": [ | ||
| { | ||
| "group": "Changelog", | ||
| "pages": ["0-17-0/changelog/index"] | ||
| }, | ||
| { | ||
| "group": "0.16.0", | ||
| "pages": ["0-17-0/changelog/0-16-0/align-rust-register-function-with-signature"] | ||
| }, | ||
| { | ||
| "group": "0.11.0", | ||
| "pages": [ | ||
| "0-17-0/changelog/0-11-0/everything-is-a-worker", | ||
| "0-17-0/changelog/0-11-0/migrating-from-motia-js", | ||
| "0-17-0/changelog/0-11-0/migrating-from-motia-py", | ||
| "0-17-0/changelog/0-11-0/migrated-examples" | ||
| ] | ||
| } | ||
| ] | ||
| } |
Contributor
There was a problem hiding this comment.
0.17 navigation omits large parts of the newly added docs set.
The new 0.17.x tabs don’t include the added 0-17-0/how-to/*, 0-17-0/patterns/*, and 0-17-0/tutorials/* pages from this PR cohort, so those pages are not discoverable from primary version navigation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/docs.json` around lines 155 - 235, The 0.17 navigation omits the newly
added sections; update docs.json (the "Docs" tab entry and/or its "groups"
array) to include new groups/pages for the 0-17-0/how-to/*, 0-17-0/patterns/*
and 0-17-0/tutorials/* routes so they appear in primary version navigation—add
new group objects (e.g., {"group":"How-to","pages":["0-17-0/how-to/…"]},
{"group":"Patterns","pages":["0-17-0/patterns/…"]},
{"group":"Tutorials","pages":["0-17-0/tutorials/…"]}) or append the specific
page IDs into existing relevant groups in the "Docs" tab to make those pages
discoverable.
Contributor
There was a problem hiding this comment.
this is fine they're not ready yet
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Resolve the review comment via GitHub CLI
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
/repos/iii-hq/iii/pulls/1714/comments \
2>/dev/null || true
# List my review comments to find the one to resolve
gh api \
-H "Accept: application/vnd.github+json" \
"/repos/iii-hq/iii/pulls/1714/comments" \
--jq '.[] | select(.user.login == "coderabbitai[bot]") | {id: .id, body: .body[0:80]}'Length of output: 2494
🏁 Script executed:
#!/bin/bash
# Get the thread node ID for comment 3327114671 via GraphQL
gh api graphql -f query='
{
repository(owner: "iii-hq", name: "iii") {
pullRequest(number: 1714) {
reviewThreads(first: 100) {
nodes {
id
isResolved
comments(first: 1) {
nodes {
databaseId
body
}
}
}
}
}
}
}' --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.comments.nodes[0].databaseId == 3327114671) | {threadId: .id, resolved: .isResolved}'Length of output: 663
@anthonyiscoding — the comment is already marked as resolved. No further action needed!
…t default - docs/next/: rolling snapshot for the 0.17.x (Next) line - docs.json: root (unprefixed) stays 0.16.x tagged Latest -> served at / by default; new 0.17.x Next version block points at next/ paths - Mintlify serves the unprefixed version at the site root, so Latest (0.16.x) is the default landing; 0.17.x Next is reachable via the version switcher
guibeira
force-pushed
the
docs/archive-0.16.0
branch
from
562cbdb to
aa898ac
Compare
anthonyiscoding
approved these changes
May 29, 2026
Comment on lines
+155
to
+235
| { | ||
| "tab": "Docs", | ||
| "groups": [ | ||
| { | ||
| "group": "Getting Started", | ||
| "pages": ["0-17-0/index", "0-17-0/install", "0-17-0/quickstart"] | ||
| }, | ||
| { | ||
| "group": "Using iii", | ||
| "pages": [ | ||
| "0-17-0/using-iii/workers", | ||
| "0-17-0/using-iii/workers-registry", | ||
| "0-17-0/using-iii/triggers", | ||
| "0-17-0/using-iii/functions", | ||
| "0-17-0/using-iii/engine", | ||
| "0-17-0/using-iii/console", | ||
| "0-17-0/using-iii/cli", | ||
| "0-17-0/using-iii/deployment" | ||
| ] | ||
| }, | ||
| { | ||
| "group": "Understanding iii", | ||
| "expanded": false, | ||
| "pages": [ | ||
| "0-17-0/understanding-iii/index", | ||
| "0-17-0/understanding-iii/engine", | ||
| "0-17-0/understanding-iii/channels" | ||
| ] | ||
| }, | ||
| { | ||
| "group": "Creating Workers", | ||
| "pages": [ | ||
| "0-17-0/creating-workers/index", | ||
| "0-17-0/creating-workers/workers", | ||
| "0-17-0/creating-workers/triggers", | ||
| "0-17-0/creating-workers/functions", | ||
| "0-17-0/creating-workers/channels" | ||
| ] | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "tab": "SDK & Engine Reference", | ||
| "groups": [ | ||
| { | ||
| "group": "Engine protocol", | ||
| "pages": ["0-17-0/sdk-reference/engine-sdk"] | ||
| }, | ||
| { | ||
| "group": "Language SDKs", | ||
| "pages": [ | ||
| "0-17-0/sdk-reference/node-sdk", | ||
| "0-17-0/sdk-reference/python-sdk", | ||
| "0-17-0/sdk-reference/rust-sdk", | ||
| "0-17-0/sdk-reference/browser-sdk" | ||
| ] | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "tab": "Changelog", | ||
| "groups": [ | ||
| { | ||
| "group": "Changelog", | ||
| "pages": ["0-17-0/changelog/index"] | ||
| }, | ||
| { | ||
| "group": "0.16.0", | ||
| "pages": ["0-17-0/changelog/0-16-0/align-rust-register-function-with-signature"] | ||
| }, | ||
| { | ||
| "group": "0.11.0", | ||
| "pages": [ | ||
| "0-17-0/changelog/0-11-0/everything-is-a-worker", | ||
| "0-17-0/changelog/0-11-0/migrating-from-motia-js", | ||
| "0-17-0/changelog/0-11-0/migrating-from-motia-py", | ||
| "0-17-0/changelog/0-11-0/migrated-examples" | ||
| ] | ||
| } | ||
| ] | ||
| } |
Contributor
There was a problem hiding this comment.
this is fine they're not ready yet
Contributor
There was a problem hiding this comment.
Actionable comments posted: 12
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/next/tutorials/build-an-agent/define-tools.mdx (1)
1-7:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAvoid shipping an empty tutorial placeholder page.
This page currently has metadata only; either add a minimal actionable tutorial stub or remove it from navigation until content is ready.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/tutorials/build-an-agent/define-tools.mdx` around lines 1 - 7, The page contains only frontmatter (the YAML block marked by --- with title/description/owner/type) and must not be shipped empty; either replace the placeholder by adding a minimal actionable tutorial stub under that frontmatter (e.g., a short intro, goals, one or two steps showing how to define a simple tool with code/commands and a “Next steps” section) or remove the page from site navigation/sidebars until ready; update the content under the frontmatter or remove the file reference so the empty metadata page is not published.
♻️ Duplicate comments (8)
docs/next/creating-workers/functions.mdx.skill.md (1)
1-342:⚠️ Potential issue | 🟠 MajorGenerated file will inherit Rust API inconsistencies.
This file is generated from
functions.mdx(see line 1). The same Rust API inconsistencies flagged infunctions.mdx(wrongRegisterFunction::newsignature, wrong error type, removed tuple form) appear here at lines 68-70, 165-171, and 251-264.Fix the source
functions.mdxfile and regenerate this skill file.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/creating-workers/functions.mdx.skill.md` around lines 1 - 342, The generated Rust examples in functions.mdx use an outdated/incorrect SDK surface (incorrect RegisterFunction::new signature, wrong error type, and tuple-style register_function usage); update the three Rust snippets to match the current SDK: replace RegisterFunction::new(...) and any tuple-form worker.register_function((..., HttpInvocationConfig)) with the current builder/factory (e.g., RegisterFunction::with_id(...) or the SDK's current constructor) and pass a single RegisterFunction value to worker.register_function, ensure handlers return the correct Result type (use anyhow::Result<T> or Result<T, Box<dyn std::error::Error>> as required by the SDK) and adjust HttpInvocationConfig/HttpAuth usage to the current structs/methods; then regenerate the skill file so the corrected Rust API appears in the generated functions.mdx.skill.md.docs/next/how-to/schedule-cron-task.mdx (1)
8-8:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace the TODO-only body with an actual how-to (or remove the page from nav for now).
This page currently publishes as an empty guide and should be completed before release.
As per coding guidelines: “Ensure the docs follow the Divio documentation system as defined in .cursor/rules and .cursor/skills.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/how-to/schedule-cron-task.mdx` at line 8, The page docs/next/how-to/schedule-cron-task.mdx currently contains only a TODO; replace that placeholder with a complete how-to that covers installing/enabling iii-cron, registering a function, binding it to a cron trigger using a schedule expression, verifying the trigger fires, common schedule strings, timezone behavior, overlap handling (skip vs queue), and how to manually invoke for testing, and ensure the content follows the Divio documentation system rules referenced in .cursor/rules and .cursor/skills; alternatively, if you cannot produce the guide now, remove the page from the navigation to avoid publishing an empty guide.docs/next/creating-workers/workers.mdx (1)
80-83:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winGuard
III_URLbefore callingregister_workerin the Python example.This snippet can pass
Nonetoregister_worker, unlike the Node/Rust tabs that fail fast. Add an explicit env check so all examples behave consistently.#!/bin/bash set -euo pipefail # Verify Python SDK signature/usage for register_worker and the current docs snippet. rg -n -C3 'def register_worker\(' sdk/packages/python/iii/src/iii/iii.py rg -n -C3 'os\.environ\.get\("III_URL"\)|register_worker\(' docs/next/creating-workers/workers.mdx🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/creating-workers/workers.mdx` around lines 80 - 83, The Python docs snippet can pass None into register_worker via os.environ.get("III_URL"); guard the env var before calling register_worker by reading III_URL into a local variable, validating it is non-empty, and failing fast (raise a RuntimeError or exit) if missing so register_worker and InitOptions(worker_name="my-worker") are never called with a None URL; update the example around register_worker/InitOptions to show this check.docs/next/sdk-reference/node-sdk.mdx (1)
126-128:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAlign
invocation_stoppedsemantics with the engine protocol.
invocation_stoppedis currently described as an engine timeout, but the engine protocol reference defines it as the worker disconnecting mid-flight. Please update this wording to avoid incorrect troubleshooting guidance.As per coding guidelines, "Check for related inconsistencies with the engine/".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/sdk-reference/node-sdk.mdx` around lines 126 - 128, The doc currently misstates the semantics of the `invocation_stopped` code as an engine timeout; update the phrasing where the common `code` values are listed so `invocation_stopped` is described as "worker disconnected mid-flight" (matching the engine protocol) rather than an engine timeout, and ensure surrounding entries (`invocation_failed`, `function_not_found`, `TIMEOUT`, `FORBIDDEN`) remain accurate; also scan nearby "engine/" references for any related inconsistent wording and align them to the engine protocol semantics.docs/next/sdk-reference/rust-sdk.mdx (1)
104-110:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUse async shutdown in the Rust SDK reference.
This still documents the synchronous shutdown path; the Rust docs should point users to
shutdown_async().awaitso shutdown waits for flush/cleanup.Suggested doc patch
-### `shutdown` +### `shutdown_async` -Disconnect from the engine and release resources. Returns immediately; in-flight tasks are aborted. +Disconnect from the engine and release resources. Await this before process exit so telemetry/export pipelines can flush. ```rust -pub fn shutdown(&self); +pub async fn shutdown_async(&self);Based on learnings: "In Rust SDK documentation, replace shutdown() with shutdown_async().await to ensure telemetry is flushed before process exit."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/sdk-reference/rust-sdk.mdx` around lines 104 - 110, Update the Rust SDK reference to document the asynchronous shutdown API: replace the synchronous signature and mentions of shutdown() with the async method shutdown_async and show it being awaited (shutdown_async().await). Ensure the documented signature reflects async (pub async fn shutdown_async(&self);) and that the text explains it waits for telemetry flush/cleanup before returning.docs/next/understanding-iii/index.mdx (1)
237-237:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove unresolved TODO from published docs.
This internal editing note should be resolved or deleted before merge.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/understanding-iii/index.mdx` at line 237, Remove the unresolved inline editor note by deleting or resolving the comment string "TODO: Confirm if we still have restricted string prefixes" in the documentation block so the published docs contain no internal TODOs; either replace it with the finalized statement about whether restricted string prefixes still apply or remove the line entirely from the MDX content.docs/next/using-iii/console.mdx (1)
27-31:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove internal naming-review note from end-user console docs.
This callout is process/internal guidance, not user guidance.
Suggested fix
-<Note> - Naming review: `iii console` is verb-shaped (launches the console) but doesn't follow the `iii - noun verb` convention used elsewhere in the CLI. Flagged for naming review per - `project-rules/cli.md`. -</Note>🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/using-iii/console.mdx` around lines 27 - 31, Remove the internal naming-review callout that begins with "<Note>" and mentions "`iii console` is verb-shaped" from the user-facing docs in console.mdx; delete the entire Note block so only end-user guidance remains and do not reference "project-rules/cli.md" or internal review notes in the published content, leaving the rest of the console documentation intact.docs/next/using-iii/deployment.mdx (1)
18-18:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDelete the LLM-only directive from user-facing docs.
This is internal process text and should not ship in public documentation.
Suggested fix
-{/* llm-only: Always verify the claim about iii cloud above, it could have changed since when this document was written. */}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/using-iii/deployment.mdx` at line 18, Remove the internal LLM-only directive from the public MDX content by deleting the JSX/MDX comment that starts with {/* llm-only: ... */} in the deployment document; search for any other occurrences of the "llm-only" marker and remove them from user-facing docs (e.g., the exact comment token "llm-only") so no internal process text is shipped, then run the docs build/preview to confirm nothing else depends on that comment.
🧹 Nitpick comments (1)
docs/next/using-iii/triggers.mdx (1)
163-168: ⚡ Quick winDrop redundant
metadata: NonefromRegisterTriggerInputexamples
RegisterTriggerInputincludespub metadata: Option<Value>withserde(skip_serializing_if = "Option::is_none"), so docs don’t need to spell outmetadata: None. Remove the redundant field from all occurrences indocs/next/using-iii/triggers.mdx(metadata at lines 167, 237, 244, 322, 368).Suggested doc-shape adjustment
worker.register_trigger(RegisterTriggerInput { trigger_type: "http".into(), function_id: "math::add".into(), config: json!({ "api_path": "/math/add", "http_method": "POST" }), - metadata: None, })?;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/next/using-iii/triggers.mdx` around lines 163 - 168, Examples that construct RegisterTriggerInput include an unnecessary metadata: None field (RegisterTriggerInput has pub metadata: Option<Value> with serde(skip_serializing_if = "Option::is_none")), so remove the redundant metadata: None entries from the example blocks that call worker.register_trigger(...) and construct RegisterTriggerInput (e.g., the snippet containing trigger_type, function_id, config) so the examples rely on the Option's skip-serializing behavior and are cleaner.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/next/creating-workers/functions.mdx`:
- Around line 63-75: Update the Rust example to match the new 0.16.0 API: call
worker.register_function with the function ID string first and pass
RegisterFunction::new only the handler closure (i.e., change the call that
currently uses RegisterFunction::new("math::add", |...|) to
worker.register_function("math::add", RegisterFunction::new(|...|)) so the ID is
passed to register_function and RegisterFunction::new accepts only the handler).
- Around line 239-266: The snippet uses the removed tuple form
register_function((RegisterFunctionMessage, HttpInvocationConfig)); replace it
with the new signature register_function("notifications::send",
RegisterFunction::http(http_config)) — construct an HttpInvocationConfig
instance (the same fields: url, method, timeout_ms, headers, auth) and pass it
via RegisterFunction::http; remove the RegisterFunctionMessage usage and instead
provide the function id string "notifications::send" and set the description
using the RegisterFunction API (e.g., the RegisterFunction builder/fields) if
available.
- Around line 148-173: The Rust example uses an outdated RegisterFunction
signature and error type: update the handler to use the new
RegisterFunction::new form that does not accept the function ID (register the ID
via the RegisterFunction builder or registration call) and change the handler
return type from Result<AddOutput, String> to Result<AddOutput, IIIError>;
specifically, adjust the closure passed to RegisterFunction::new (and any use of
register_worker/register_function registration) to accept AddInput and return
Result<AddOutput, IIIError>, and ensure the function ID is supplied via the
RegisterFunction builder/registration API rather than as the first argument to
RegisterFunction::new.
In `@docs/next/creating-workers/triggers.mdx`:
- Line 28: The page docs/next/creating-workers/triggers.mdx contains inline TODO
placeholders (e.g., the comment "{/* TODO: Review against real SDK/CLI surface
(now, and post-sdk rework, separately) */}" and similar TODOs at the mentioned
lines) which must be removed or replaced with finalized guidance before merge;
locate those TODO comments in the Triggers document and either provide the
final, user-facing guidance (or delete the unfinished claim) and ensure the
resulting text follows the Divio documentation rules by validating against
.cursor/rules and .cursor/skills.
In `@docs/next/creating-workers/workers-registry.mdx`:
- Line 8: This docs page contains internal TODO/editor placeholder comments
(e.g., the JSX comment "{/* Note: move this up */}" and other notes at the
referenced locations) that must be finalized or removed; edit
workers-registry.mdx to replace all internal planning notes and TODOs with
finalized copy that adheres to the Divio documentation rules (.cursor/rules and
.cursor/skills), removing any editor reminders and ensuring each placeholder at
the indicated spots (including the other occurrences noted) is converted into
complete, user-facing guidance or deleted.
In `@docs/next/creating-workers/workers.mdx`:
- Line 246: Replace the visible TODO placeholders in the Workers guide (e.g. the
comment "{/* TODO: Revisit and check code sample after SDK surface is reworked
*/}" and the other TODO instances) with final, user-facing content or remove
them entirely so no unfinished authoring tasks appear in published docs; update
the sample code and explanatory text to match the current SDK surface and ensure
the resulting content follows the Divio documentation rules referenced in
.cursor/rules and .cursor/skills and mirrors surrounding sections' style and
completeness (search for the TODO comment text to locate each occurrence).
In `@docs/next/quickstart.mdx.skill.md`:
- Around line 33-39: The three unlabeled fenced code blocks that show directory
listings (e.g., the block starting with "workers/ math-worker/ math_worker.py
caller-worker/ src/worker.ts") should be labeled with a language (use `text`)
in the source MDX (edit docs/quickstart.mdx, not the generated .skill.md) to
satisfy MD040; find the other unlabeled blocks with similar directory/listing
content (the other occurrences around the referenced ranges) and change their
opening fences from ``` to ```text so the generated docs remain lint-clean.
In `@docs/next/sdk-reference/rust-sdk.mdx`:
- Line 8: Remove the unresolved inline TODO comment "{/* TODO: Re-link worker
references to https://workers.iii.dev/workers/<name> once the Worker Docs
migration ships. */}" from the published docs page
docs/next/sdk-reference/rust-sdk.mdx; either resolve it by replacing the
placeholder with the final, working links to the Worker Docs or delete the TODO
entirely so no internal migration note is left in the published content.
In `@docs/next/understanding-iii/engine.mdx`:
- Around line 37-39: Update the two absolute Next-doc links in the content that
currently point to unprefixed Latest routes: replace
"/creating-workers/workers#handling-worker-disconnects" with
"/next/creating-workers/workers#handling-worker-disconnects" and replace
"/creating-workers/workers#inspecting-the-live-registry" with
"/next/creating-workers/workers#inspecting-the-live-registry"; make the same
replacements in the generated docs/next/understanding-iii/engine.mdx.skill.md so
both source (engine.mdx) and generated skill file use the /next/ prefix.
In `@docs/next/using-iii/cli.mdx.skill.md`:
- Line 10: Correct the typo in the generated CLI doc line by changing
"sucommand" to "subcommand" (the line that reads "iii subcommand --help") and
fix the broken local anchor by updating the link target "`#updating-iii-itself`"
to match the actual heading "`#updating-iii`" (or alternatively rename the heading
to "## Updating iii itself" so the fragment matches); update the source in
docs/using-iii/cli.mdx and re-render to verify the anchor resolves.
In `@docs/next/using-iii/triggers.mdx.skill.md`:
- Line 1: Update the generated source-path hint in the header comment of the
produced file so the "Edit …" link targets the versioned MDX source (e.g.,
docs/next/using-iii/triggers.mdx) instead of the unversioned path; modify the
template or iii-skill-render that writes the header comment (the <!-- generated
by iii-skill-render. DO NOT EDIT ... --> block) to interpolate the current
version segment ("next" in this case) into the Edit path so versioned skill
files point to their correct source MDX.
In `@docs/next/using-iii/workers-registry.mdx.skill.md`:
- Line 1: The generated header line "<!-- generated by iii-skill-render. DO NOT
EDIT (changes here are overwritten on the next render). Edit
docs/using-iii/workers-registry.mdx. -->" contains the wrong "Edit ..." hint;
update the generator/template that emits this header so the hint points to the
snapshot's versioned source (e.g., replace "Edit
docs/using-iii/workers-registry.mdx" with the appropriate versioned path such as
"Edit docs/next/using-iii/workers-registry.mdx" or inject the version variable
used by the renderer), ensuring the emitted header in the file produced by
iii-skill-render references the versioned source for workers-registry.mdx.
---
Outside diff comments:
In `@docs/next/tutorials/build-an-agent/define-tools.mdx`:
- Around line 1-7: The page contains only frontmatter (the YAML block marked by
--- with title/description/owner/type) and must not be shipped empty; either
replace the placeholder by adding a minimal actionable tutorial stub under that
frontmatter (e.g., a short intro, goals, one or two steps showing how to define
a simple tool with code/commands and a “Next steps” section) or remove the page
from site navigation/sidebars until ready; update the content under the
frontmatter or remove the file reference so the empty metadata page is not
published.
---
Duplicate comments:
In `@docs/next/creating-workers/functions.mdx.skill.md`:
- Around line 1-342: The generated Rust examples in functions.mdx use an
outdated/incorrect SDK surface (incorrect RegisterFunction::new signature, wrong
error type, and tuple-style register_function usage); update the three Rust
snippets to match the current SDK: replace RegisterFunction::new(...) and any
tuple-form worker.register_function((..., HttpInvocationConfig)) with the
current builder/factory (e.g., RegisterFunction::with_id(...) or the SDK's
current constructor) and pass a single RegisterFunction value to
worker.register_function, ensure handlers return the correct Result type (use
anyhow::Result<T> or Result<T, Box<dyn std::error::Error>> as required by the
SDK) and adjust HttpInvocationConfig/HttpAuth usage to the current
structs/methods; then regenerate the skill file so the corrected Rust API
appears in the generated functions.mdx.skill.md.
In `@docs/next/creating-workers/workers.mdx`:
- Around line 80-83: The Python docs snippet can pass None into register_worker
via os.environ.get("III_URL"); guard the env var before calling register_worker
by reading III_URL into a local variable, validating it is non-empty, and
failing fast (raise a RuntimeError or exit) if missing so register_worker and
InitOptions(worker_name="my-worker") are never called with a None URL; update
the example around register_worker/InitOptions to show this check.
In `@docs/next/how-to/schedule-cron-task.mdx`:
- Line 8: The page docs/next/how-to/schedule-cron-task.mdx currently contains
only a TODO; replace that placeholder with a complete how-to that covers
installing/enabling iii-cron, registering a function, binding it to a cron
trigger using a schedule expression, verifying the trigger fires, common
schedule strings, timezone behavior, overlap handling (skip vs queue), and how
to manually invoke for testing, and ensure the content follows the Divio
documentation system rules referenced in .cursor/rules and .cursor/skills;
alternatively, if you cannot produce the guide now, remove the page from the
navigation to avoid publishing an empty guide.
In `@docs/next/sdk-reference/node-sdk.mdx`:
- Around line 126-128: The doc currently misstates the semantics of the
`invocation_stopped` code as an engine timeout; update the phrasing where the
common `code` values are listed so `invocation_stopped` is described as "worker
disconnected mid-flight" (matching the engine protocol) rather than an engine
timeout, and ensure surrounding entries (`invocation_failed`,
`function_not_found`, `TIMEOUT`, `FORBIDDEN`) remain accurate; also scan nearby
"engine/" references for any related inconsistent wording and align them to the
engine protocol semantics.
In `@docs/next/sdk-reference/rust-sdk.mdx`:
- Around line 104-110: Update the Rust SDK reference to document the
asynchronous shutdown API: replace the synchronous signature and mentions of
shutdown() with the async method shutdown_async and show it being awaited
(shutdown_async().await). Ensure the documented signature reflects async (pub
async fn shutdown_async(&self);) and that the text explains it waits for
telemetry flush/cleanup before returning.
In `@docs/next/understanding-iii/index.mdx`:
- Line 237: Remove the unresolved inline editor note by deleting or resolving
the comment string "TODO: Confirm if we still have restricted string prefixes"
in the documentation block so the published docs contain no internal TODOs;
either replace it with the finalized statement about whether restricted string
prefixes still apply or remove the line entirely from the MDX content.
In `@docs/next/using-iii/console.mdx`:
- Around line 27-31: Remove the internal naming-review callout that begins with
"<Note>" and mentions "`iii console` is verb-shaped" from the user-facing docs
in console.mdx; delete the entire Note block so only end-user guidance remains
and do not reference "project-rules/cli.md" or internal review notes in the
published content, leaving the rest of the console documentation intact.
In `@docs/next/using-iii/deployment.mdx`:
- Line 18: Remove the internal LLM-only directive from the public MDX content by
deleting the JSX/MDX comment that starts with {/* llm-only: ... */} in the
deployment document; search for any other occurrences of the "llm-only" marker
and remove them from user-facing docs (e.g., the exact comment token "llm-only")
so no internal process text is shipped, then run the docs build/preview to
confirm nothing else depends on that comment.
---
Nitpick comments:
In `@docs/next/using-iii/triggers.mdx`:
- Around line 163-168: Examples that construct RegisterTriggerInput include an
unnecessary metadata: None field (RegisterTriggerInput has pub metadata:
Option<Value> with serde(skip_serializing_if = "Option::is_none")), so remove
the redundant metadata: None entries from the example blocks that call
worker.register_trigger(...) and construct RegisterTriggerInput (e.g., the
snippet containing trigger_type, function_id, config) so the examples rely on
the Option's skip-serializing behavior and are cleaner.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: ab272001-7b4c-4546-a1c6-9927c3a096b5
⛔ Files ignored due to path filters (3)
docs/next/assets/favicon.svgis excluded by!**/*.svgdocs/next/assets/iii-black.svgis excluded by!**/*.svgdocs/next/assets/iii-white.svgis excluded by!**/*.svg
📒 Files selected for processing (91)
docs/docs.jsondocs/next/changelog/0-11-0/everything-is-a-worker.mdxdocs/next/changelog/0-11-0/migrated-examples.mdxdocs/next/changelog/0-11-0/migrating-from-motia-js.mdxdocs/next/changelog/0-11-0/migrating-from-motia-py.mdxdocs/next/changelog/0-16-0/align-rust-register-function-with-signature.mdxdocs/next/changelog/index.mdxdocs/next/creating-workers/channels.mdxdocs/next/creating-workers/channels.mdx.skill.mddocs/next/creating-workers/functions.mdxdocs/next/creating-workers/functions.mdx.skill.mddocs/next/creating-workers/index.mdxdocs/next/creating-workers/index.mdx.skill.mddocs/next/creating-workers/triggers.mdxdocs/next/creating-workers/triggers.mdx.skill.mddocs/next/creating-workers/workers-registry.mdxdocs/next/creating-workers/workers-registry.mdx.skill.mddocs/next/creating-workers/workers.mdxdocs/next/creating-workers/workers.mdx.skill.mddocs/next/how-to/build-a-realtime-todo-app.mdxdocs/next/how-to/build-a-realtime-todo-app.mdx.skill.mddocs/next/how-to/schedule-cron-task.mdxdocs/next/how-to/schedule-cron-task.mdx.skill.mddocs/next/how-to/use-trigger-conditions.mdxdocs/next/how-to/use-trigger-conditions.mdx.skill.mddocs/next/index.mdxdocs/next/index.mdx.skill.mddocs/next/install.mdxdocs/next/install.mdx.skill.mddocs/next/patterns/adapter-pattern.mdxdocs/next/patterns/adapter-pattern.mdx.skill.mddocs/next/patterns/reactive-state-pattern.mdxdocs/next/patterns/reactive-state-pattern.mdx.skill.mddocs/next/quickstart.mdxdocs/next/quickstart.mdx.skill.mddocs/next/sdk-reference/browser-sdk.mdxdocs/next/sdk-reference/browser-sdk.mdx.skill.mddocs/next/sdk-reference/engine-sdk.mdxdocs/next/sdk-reference/engine-sdk.mdx.skill.mddocs/next/sdk-reference/node-sdk.mdxdocs/next/sdk-reference/node-sdk.mdx.skill.mddocs/next/sdk-reference/python-sdk.mdxdocs/next/sdk-reference/python-sdk.mdx.skill.mddocs/next/sdk-reference/rust-sdk.mdxdocs/next/sdk-reference/rust-sdk.mdx.skill.mddocs/next/tutorials/build-an-agent/define-tools.mdxdocs/next/tutorials/build-an-agent/define-tools.mdx.skill.mddocs/next/tutorials/build-an-agent/memory-and-state.mdxdocs/next/tutorials/build-an-agent/memory-and-state.mdx.skill.mddocs/next/tutorials/build-an-agent/orchestration-loop.mdxdocs/next/tutorials/build-an-agent/orchestration-loop.mdx.skill.mddocs/next/tutorials/build-an-agent/overview.mdxdocs/next/tutorials/build-an-agent/overview.mdx.skill.mddocs/next/tutorials/incremental-adoption/migrate-persistence.mdxdocs/next/tutorials/incremental-adoption/migrate-persistence.mdx.skill.mddocs/next/tutorials/incremental-adoption/offload-to-queue.mdxdocs/next/tutorials/incremental-adoption/offload-to-queue.mdx.skill.mddocs/next/tutorials/incremental-adoption/overview.mdxdocs/next/tutorials/incremental-adoption/overview.mdx.skill.mddocs/next/tutorials/incremental-adoption/wrap-existing-api.mdxdocs/next/tutorials/incremental-adoption/wrap-existing-api.mdx.skill.mddocs/next/tutorials/reactive-crud/crud-endpoints.mdxdocs/next/tutorials/reactive-crud/crud-endpoints.mdx.skill.mddocs/next/tutorials/reactive-crud/model-and-store.mdxdocs/next/tutorials/reactive-crud/model-and-store.mdx.skill.mddocs/next/tutorials/reactive-crud/overview.mdxdocs/next/tutorials/reactive-crud/overview.mdx.skill.mddocs/next/tutorials/reactive-crud/realtime-subscriptions.mdxdocs/next/tutorials/reactive-crud/realtime-subscriptions.mdx.skill.mddocs/next/understanding-iii/channels.mdxdocs/next/understanding-iii/channels.mdx.skill.mddocs/next/understanding-iii/engine.mdxdocs/next/understanding-iii/engine.mdx.skill.mddocs/next/understanding-iii/index.mdxdocs/next/understanding-iii/index.mdx.skill.mddocs/next/using-iii/cli.mdxdocs/next/using-iii/cli.mdx.skill.mddocs/next/using-iii/console.mdxdocs/next/using-iii/console.mdx.skill.mddocs/next/using-iii/deployment.mdxdocs/next/using-iii/deployment.mdx.skill.mddocs/next/using-iii/engine.mdxdocs/next/using-iii/engine.mdx.skill.mddocs/next/using-iii/functions.mdxdocs/next/using-iii/functions.mdx.skill.mddocs/next/using-iii/triggers.mdxdocs/next/using-iii/triggers.mdx.skill.mddocs/next/using-iii/workers-registry.mdxdocs/next/using-iii/workers-registry.mdx.skill.mddocs/next/using-iii/workers.mdxdocs/next/using-iii/workers.mdx.skill.md
✅ Files skipped from review due to trivial changes (37)
- docs/next/tutorials/incremental-adoption/offload-to-queue.mdx.skill.md
- docs/next/tutorials/build-an-agent/define-tools.mdx.skill.md
- docs/next/tutorials/reactive-crud/model-and-store.mdx.skill.md
- docs/next/tutorials/build-an-agent/orchestration-loop.mdx.skill.md
- docs/next/tutorials/build-an-agent/orchestration-loop.mdx
- docs/next/tutorials/reactive-crud/realtime-subscriptions.mdx.skill.md
- docs/next/understanding-iii/channels.mdx
- docs/next/tutorials/build-an-agent/overview.mdx
- docs/next/tutorials/incremental-adoption/overview.mdx.skill.md
- docs/next/how-to/build-a-realtime-todo-app.mdx
- docs/next/tutorials/reactive-crud/crud-endpoints.mdx
- docs/next/tutorials/reactive-crud/overview.mdx.skill.md
- docs/next/tutorials/incremental-adoption/wrap-existing-api.mdx
- docs/next/tutorials/incremental-adoption/migrate-persistence.mdx
- docs/next/tutorials/build-an-agent/memory-and-state.mdx
- docs/next/tutorials/incremental-adoption/offload-to-queue.mdx
- docs/next/tutorials/build-an-agent/overview.mdx.skill.md
- docs/next/tutorials/incremental-adoption/wrap-existing-api.mdx.skill.md
- docs/next/how-to/use-trigger-conditions.mdx
- docs/next/how-to/build-a-realtime-todo-app.mdx.skill.md
- docs/next/install.mdx
- docs/next/tutorials/reactive-crud/overview.mdx
- docs/next/tutorials/incremental-adoption/overview.mdx
- docs/next/changelog/0-11-0/migrated-examples.mdx
- docs/next/creating-workers/channels.mdx.skill.md
- docs/next/tutorials/incremental-adoption/migrate-persistence.mdx.skill.md
- docs/next/using-iii/engine.mdx
- docs/next/patterns/reactive-state-pattern.mdx
- docs/next/tutorials/reactive-crud/realtime-subscriptions.mdx
- docs/next/tutorials/reactive-crud/crud-endpoints.mdx.skill.md
- docs/next/tutorials/build-an-agent/memory-and-state.mdx.skill.md
- docs/next/index.mdx
- docs/next/tutorials/reactive-crud/model-and-store.mdx
- docs/next/using-iii/cli.mdx
- docs/next/sdk-reference/browser-sdk.mdx
- docs/next/using-iii/functions.mdx
- docs/next/creating-workers/channels.mdx
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/docs.json
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Sets up docs versioning for the 0.16.0 release line and the upcoming 0.17.x.
/as the default landing version.docs/0-17-0/(93 files), wired as a new version block with0-17-0/paths and theNexttag.Why
Mintlify serves the unprefixed version block at the site root. Latest (0.16.0) must therefore live at root to be the default landing; the Next line lives in a prefixed subfolder reachable via the version switcher.
Notes
docs/0-17-0/; root stays frozen at 0.16. On 0.17 release, promote0-17-0/→ root and archive 0.16 into0-16-0/.Verification
jq empty docs/docs.json→ valid0.16.x [Latest],0.17.x [Next], then archived/index(0.16.0 at root)Summary by CodeRabbit