docs: URLs now mirror the sidebar — sections own their pages

Every page lives at a path matching its meta.json section, done now while none
of these URLs are publicly live (the last free window before merge):

- Workflows owns its accordions: /blocks/* -> /workflows/blocks/*,
  /triggers/{start,schedule,webhook,rss,table,sim} -> /workflows/triggers/*,
  /deployment/* -> /workflows/deployment/*
- Mothership owns Mailer: /mailer -> /mothership/mailer
- Workspaces & Access folds into Platform, sequenced concept-first with the
  reference tail last: /platform/{workspaces,organization,permissions,
  credentials,costs}, then platform/self-hosting/*, platform/enterprise/*
  (from /workspaces/fundamentals+organization, /permissions/roles-and-
  permissions, /credentials, /costs, /self-hosting/*, /enterprise/*)

All internal links swept (0 broken in a full-tree resolver sweep), root
meta.json repointed, and every previously-live URL 308s to its new home —
including retargeted destinations of existing redirects so chains stay
single-hop (verified: /execution/chat reaches /workflows/deployment/chat in
one hop), and the native-trigger rule ordered after the enumerated
integration-trigger redirects so /triggers/gmail still reaches
/integrations/gmail. Production build passes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: ouiliame

apps/docs/content/docs/en/agents/choosing.mdx

@@ -20,15 +20,15 @@ The running example is a workflow that scores inbound sales leads. It reads a ne
 
 A **block** is a single step that runs at a fixed point on the path, with no model deciding whether to. It always runs when the workflow reaches it. Use one when the action must happen every time: an API call, a data transform, a branch.
 
-In the lead scorer, a [Google Sheets](/integrations) block always appends the scored lead to a tracking sheet, and a [Function](/blocks/function) block always reshapes the enrichment response into the fields the next step expects. There is no judgment call. The work is guaranteed.
+In the lead scorer, a [Google Sheets](/integrations) block always appends the scored lead to a tracking sheet, and a [Function](/workflows/blocks/function) block always reshapes the enrichment response into the fields the next step expects. There is no judgment call. The work is guaranteed.
 
 <WorkflowPreview workflow={LEAD_SCORER_WORKFLOW} height={170} highlightBlock="log" />
 
 Most steps in a workflow are blocks. Reach for the kinds below only when you want a model to decide, or you want to reuse something.
 
 ## Agent tool
 
-An **agent tool** is an action you hand to an [Agent](/blocks/agent) block. The agent reads the task and decides whether and when to call it. The same catalog of [integrations](/integrations) that exist as standalone blocks can also be attached to an agent as tools.
+An **agent tool** is an action you hand to an [Agent](/workflows/blocks/agent) block. The agent reads the task and decides whether and when to call it. The same catalog of [integrations](/integrations) that exist as standalone blocks can also be attached to an agent as tools.
 
 In the lead scorer, the Agent has a Search tool and a Send Email tool. For a lead with a thin profile it runs Search to gather context; for a strong lead it calls Send Email. A thin, obvious lead might trigger neither. The agent chooses per run.
 
@@ -54,12 +54,12 @@ In the lead scorer, your CRM vendor ships an MCP server. After you connect it on
 
 ## Workflow-as-tool
 
-A **workflow-as-tool** is a whole workflow handed to an agent as one callable tool. You pick the workflow in the [Agent](/blocks/agent) block's tool list; the agent decides when to call it and supplies the inputs, which arrive at the child's [Start](/triggers/start) trigger, and the child's result comes back as the tool's output. Use it when a multi-step procedure should be at the agent's disposal, not on the path.
+A **workflow-as-tool** is a whole workflow handed to an agent as one callable tool. You pick the workflow in the [Agent](/workflows/blocks/agent) block's tool list; the agent decides when to call it and supplies the inputs, which arrive at the child's [Start](/workflows/triggers/start) trigger, and the child's result comes back as the tool's output. Use it when a multi-step procedure should be at the agent's disposal, not on the path.
 
 In the lead scorer, the agent has a `Deep Enrich` workflow as a tool — its own five-step procedure. For a thin lead, the agent calls it to fill out the profile before scoring; for a complete lead, it never runs. The agent weighs a whole procedure the same way it weighs a single action.
 
 <Callout type="info">
-A workflow can also run as a fixed step: the [Workflow](/blocks/workflow) block calls a child workflow because the path reached it. Same child workflow, same Start trigger — the difference, as with blocks and agent tools, is who decides. The Enrich step in the diagram is that deterministic case.
+A workflow can also run as a fixed step: the [Workflow](/workflows/blocks/workflow) block calls a child workflow because the path reached it. Same child workflow, same Start trigger — the difference, as with blocks and agent tools, is who decides. The Enrich step in the diagram is that deterministic case.
 </Callout>
 
 <WorkflowPreview workflow={LEAD_SCORER_WORKFLOW} height={170} highlightBlock="enrich" />
@@ -87,7 +87,7 @@ The lead scorer uses six kinds at once: blocks for the steps that must always ru
 
 <Cards>
   <Card title="Building agents" href="/agents" description="The features that let an agent act, follow instructions, and use your data." />
-  <Card title="Agent block reference" href="/blocks/agent" description="Every model, setting, and output field." />
+  <Card title="Agent block reference" href="/workflows/blocks/agent" description="Every model, setting, and output field." />
   <Card title="Using MCP tools" href="/agents/mcp" description="Connect an external MCP server to your agents." />
   <Card title="Skills" href="/agents/skills" description="Write reusable instructions agents can load." />
 </Cards>

apps/docs/content/docs/en/agents/index.mdx

@@ -8,7 +8,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Card, Cards } from 'fumadocs-ui/components/card'
 import { WorkflowPreview, BUILD_AGENT_WORKFLOW } from '@/components/workflow-preview'
 
-An **agent** is a [workflow](/workflows) that reasons and acts on its own. It reads an input, decides what to do, and carries it out, calling tools and using your data along the way. You build a custom agent in Sim by composing a workflow whose thinking runs through one or more [Agent blocks](/blocks/agent).
+An **agent** is a [workflow](/workflows) that reasons and acts on its own. It reads an input, decides what to do, and carries it out, calling tools and using your data along the way. You build a custom agent in Sim by composing a workflow whose thinking runs through one or more [Agent blocks](/workflows/blocks/agent).
 
 An **Agent block** is the reasoning step inside that workflow: a model reads the values available to it, decides, and returns a result that later blocks read by reference. A simple agent is a single Agent block; a larger one wires several together with other blocks. The Agent block is where the model thinks; the rest of the workflow is what it acts on and through.
 
@@ -20,7 +20,7 @@ The example throughout is an agent that scores inbound sales leads.
 
 You set up the reasoning step by giving the Agent block a **model** and a **prompt**. The model is the LLM that powers it; you pick one from the available providers, and the default is `claude-sonnet-4-6`. The prompt is a system message that defines who the agent is and how it should behave, plus a user message that carries the input, usually a reference like `<start.input>`.
 
-When it runs, the Agent block reasons, calls any tools it needs, and stores its result under its own name. By default that result is free text in `content`, read by a later block as `<agent.content>`, alongside run details like the model used, token counts, tool calls, and cost. Every setting and output field is in the [Agent block reference](/blocks/agent).
+When it runs, the Agent block reasons, calls any tools it needs, and stores its result under its own name. By default that result is free text in `content`, read by a later block as `<agent.content>`, alongside run details like the model used, token counts, tool calls, and cost. Every setting and output field is in the [Agent block reference](/workflows/blocks/agent).
 
 ## What you give an agent
 
@@ -55,7 +55,7 @@ To let an agent reuse information from one run to the next, give it [memory](/in
 
 ### Return a usable result: structured output
 
-To make an agent's result something later blocks can act on, give it a **structured output**: a typed object you define instead of free text. In the lead scorer, the agent returns `{ score, tier, reason }`, and a later [Condition](/blocks/condition) block reads `<agent.tier>` to branch. See [how blocks pass data](/workflows/data-flow) for reading fields.
+To make an agent's result something later blocks can act on, give it a **structured output**: a typed object you define instead of free text. In the lead scorer, the agent returns `{ score, tier, reason }`, and a later [Condition](/workflows/blocks/condition) block reads `<agent.tier>` to branch. See [how blocks pass data](/workflows/data-flow) for reading fields.
 
 ## Choosing what to use
 
@@ -66,7 +66,7 @@ Start with one Agent block and a prompt, then add only what the task needs: a to
 ## Next
 
 <Cards>
-  <Card title="Agent block reference" href="/blocks/agent" description="Every model, setting, and output field of the Agent block." />
+  <Card title="Agent block reference" href="/workflows/blocks/agent" description="Every model, setting, and output field of the Agent block." />
   <Card title="Choosing what to use" href="/agents/choosing" description="Pick the right feature for each task." />
   <Card title="Custom tools" href="/agents/custom-tools" description="Define a reusable tool with a schema and code." />
   <Card title="Using MCP tools" href="/agents/mcp" description="Connect an external MCP server to your agents." />

apps/docs/content/docs/en/credentials/meta.json

@@ -17,7 +17,7 @@ Like a build pipeline that produces artifacts and stores them in an artifact rep
 
 Most generated files start as the output of an earlier block. Two patterns are common.
 
-A block returns **text content** you want to keep. An [Agent](/blocks/agent) writes an analysis or summary; a [Function](/blocks/function) builds a CSV or formats a report. That text is part of the block's output, read by reference as `<agent.content>` or `<function.result>`. To make it a file, you pass that value into a File block set to Write.
+A block returns **text content** you want to keep. An [Agent](/workflows/blocks/agent) writes an analysis or summary; a [Function](/workflows/blocks/function) builds a CSV or formats a report. That text is part of the block's output, read by reference as `<agent.content>` or `<function.result>`. To make it a file, you pass that value into a File block set to Write.
 
 A block returns a **file object** directly. ElevenLabs text-to-speech returns an `audioFile`; an image generator returns a generated image; the File block's own Read operation returns parsed files. These are already [UserFile](/files/passing-files) objects (an object with `id`, `name`, `url`, `size`, and `type`), so they appear in the output panel as files with no Write step. You can hand one to a downstream block, or write its content to the Files store to persist it.
 
@@ -56,13 +56,13 @@ During a run, the file also appears in the output panel as the File block's outp
 
 ## Returning a generated file from a deployment
 
-When a workflow is deployed as an [API](/deployment/api), a generated file can be part of the response. Reference the file in a [Response](/blocks/response) block, or include its ID in the object you return. The caller uses the `url` or `id` to fetch the file from the workspace store. The file itself stays in the Files store, and the response carries a pointer to it, not the bytes.
+When a workflow is deployed as an [API](/workflows/deployment/api), a generated file can be part of the response. Reference the file in a [Response](/workflows/blocks/response) block, or include its ID in the object you return. The caller uses the `url` or `id` to fetch the file from the workspace store. The file itself stays in the Files store, and the response carries a pointer to it, not the bytes.
 
 ## Next
 
 <Cards>
   <Card title="Files overview" href="/files" description="The artifact layer of your workspace." />
   <Card title="Using files in workflows" href="/files/passing-files" description="Provide files to a workflow and receive files back." />
   <Card title="File block" href="/files" description="Read, Get, Write, and Append operations in full." />
-  <Card title="API deployment" href="/deployment/api" description="Expose a workflow as an API and return file references." />
+  <Card title="API deployment" href="/workflows/deployment/api" description="Expose a workflow as an API and return file references." />
 </Cards>

apps/docs/content/docs/en/files/generating.mdx

@@ -14,7 +14,7 @@ Any [workflow](/workflows) can read a file or produce one. You might upload a co
 
 - **[Workflows](/workflows)** read files, like a PDF to summarize, and produce them, like a rendered report. See [using files in workflows](/files/using-in-workflows).
 - **[Knowledge bases](/knowledgebase)** are built from files you upload, turning their contents into searchable memory.
-- **[Deployments](/deployment)** can take a file as input and return one as output.
+- **[Deployments](/workflows/deployment)** can take a file as input and return one as output.
 
 Use a file when the document or media itself is what matters. Use a [table](/tables) when you need structured rows and fields, and a [knowledge base](/knowledgebase) when an agent needs to search across many documents.
 

apps/docs/content/docs/en/files/index.mdx

@@ -62,15 +62,15 @@ Once a file is read, a processing block reads that output by name. Two blocks do
 
 ### Agent block
 
-An [Agent](/blocks/agent) block has a **Files** input. Reference the read file there, `<file1.files[0]>`, and write the instruction in the prompt: "Summarize this document." The agent receives the file object, not just its text, so a **vision-capable model** (such as Claude or GPT-4o) can analyze images and scanned pages directly. Other models work from the file's text content.
+An [Agent](/workflows/blocks/agent) block has a **Files** input. Reference the read file there, `<file1.files[0]>`, and write the instruction in the prompt: "Summarize this document." The agent receives the file object, not just its text, so a **vision-capable model** (such as Claude or GPT-4o) can analyze images and scanned pages directly. Other models work from the file's text content.
 
 In our example the Agent reads `<file1.files[0]>`, summarizes it, and keeps the summary under its own name as `<agent1.content>`.
 
 {/* VISUAL: Agent block config. Files input bound to <file1.files[0]>, prompt "Summarize this document" */}
 
 ### Function block
 
-A [Function](/blocks/function) block runs code, and it works with file **text**, not the file object. It doesn't reach into workspace storage on its own. Pass it the extracted text, `<file1.combinedContent>`, and it can parse, filter, or reshape that text and return the result as its own output. Use a Function when the file is structured text (a CSV or JSON dump) and you want exact, deterministic processing instead of a model's interpretation.
+A [Function](/workflows/blocks/function) block runs code, and it works with file **text**, not the file object. It doesn't reach into workspace storage on its own. Pass it the extracted text, `<file1.combinedContent>`, and it can parse, filter, or reshape that text and return the result as its own output. Use a Function when the file is structured text (a CSV or JSON dump) and you want exact, deterministic processing instead of a model's interpretation.
 
 <Callout type="info">
 The two blocks differ in what they take. An **Agent** takes the file object on its Files input, while a **Function** takes the file's text from `combinedContent`. Both store their result under their own name for the next block to read.
@@ -105,6 +105,6 @@ For the file-object schema in full, base64 access, and how files move across API
   <Card title="Passing files" href="/files/passing-files" description="The file object in full: properties, base64, and references across blocks." />
   <Card title="Generating & storing files" href="/files/generating" description="Produce files from a run and save them to your workspace." />
   <Card title="File block reference" href="/files" description="Every operation, input, and output in detail." />
-  <Card title="Agent block" href="/blocks/agent" description="Give an agent files to read, summarize, or analyze." />
+  <Card title="Agent block" href="/workflows/blocks/agent" description="Give an agent files to read, summarize, or analyze." />
   <Card title="Using tables in workflows" href="/tables/using-in-workflows" description="Read and write structured rows the same way you read and write files." />
 </Cards>

apps/docs/content/docs/en/files/using-in-workflows.mdx

@@ -85,13 +85,13 @@ Build a people research agent in 10 minutes. It takes a name through a chat inte
   <Card title="Workflows" href="/workflows">
     The full model: blocks, connections, triggers, and how runs execute.
   </Card>
-  <Card title="Agent block" href="/blocks/agent">
+  <Card title="Agent block" href="/workflows/blocks/agent">
     Everything the block you just used can do — tools, memory, skills, structured output.
   </Card>
   <Card title="Integrations" href="/integrations">
     1,000+ services your agents can act on, from Gmail to HubSpot.
   </Card>
-  <Card title="Deploy it" href="/deployment">
+  <Card title="Deploy it" href="/workflows/deployment">
     Ship the workflow as an API, a chat, or an MCP server.
   </Card>
 </Cards>

apps/docs/content/docs/en/getting-started/index.mdx

@@ -45,7 +45,7 @@ Welcome to Sim, the open-source AI workspace where teams build, deploy, and mana
 ## Advanced Features
 
 <Cards>
-  <Card title="Team Management" href="/permissions/roles-and-permissions">
+  <Card title="Team Management" href="/platform/permissions">
     Set up workspace roles and permissions
   </Card>
   <Card title="MCP Integration" href="/agents/mcp">

apps/docs/content/docs/en/index.mdx

@@ -11,7 +11,7 @@ Sim connects your HubSpot CRM to AI workflows. Once connected, your workflows ca
 
 - **Read and write CRM records** — create, look up, search, and update contacts, companies, deals, and tickets from any workflow.
 - **React to CRM changes** — start a workflow when a contact, company, deal, or ticket is created or updated in HubSpot.
-- **Combine HubSpot with AI steps** — enrich a new contact with an [Agent block](/blocks/agent), route deals with a [Condition](/blocks/condition), or sync records into [Tables](/tables).
+- **Combine HubSpot with AI steps** — enrich a new contact with an [Agent block](/workflows/blocks/agent), route deals with a [Condition](/workflows/blocks/condition), or sync records into [Tables](/tables).
 
 This guide covers installing the integration, connecting a HubSpot account, configuring it in a workflow, and disconnecting or uninstalling it.
 
@@ -88,7 +88,7 @@ The full list of operations, with every input and output, is on the [HubSpot int
 
 The HubSpot block can also act as a trigger. Toggle **Use as Trigger**, select the connection, and choose which events to watch — contacts, companies, deals, or tickets, created or updated. Sim polls HubSpot for changes and runs the workflow once per changed record, with the record's fields available to downstream blocks.
 
-Triggers run against your workflow's active [deployment](/deployment), so deploy the workflow to activate them.
+Triggers run against your workflow's active [deployment](/workflows/deployment), so deploy the workflow to activate them.
 
 ## Use the app
 

apps/docs/content/docs/en/integrations/hubspot-setup.mdx

@@ -45,7 +45,7 @@ A Sim system is not a single chat response. It is a set of resources that live i
 - **[Tables](/tables)** hold structured rows your workflows read, write, and process.
 - **[Knowledge bases](/knowledgebase)** are searchable memory. An agent retrieves relevant passages from your documents to ground its answers.
 - **[Files](/files)** are the documents and media your workflows store, read, and produce.
-- **[Deployments](/deployment)** expose a workflow to the outside world as an API, a chat, or an MCP server.
+- **[Deployments](/workflows/deployment)** expose a workflow to the outside world as an API, a chat, or an MCP server.
 - **[Logs](/logs-debugging)** record every run, block by block, so you can verify what happened.
 
 <div className="mx-auto w-full overflow-hidden rounded-lg my-6">