@ebitex/content-mcp 0.5.113 → 0.5.114

package/dist/resources/helpCorpus.generated.js

@@ -36,7 +36,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-environments",
         "title": "Content environments",
-        "body": "# Content environments\n\nBy default, your organization has one authoring space and one place published content goes live —\nyou'll never need this page if that's all you use. If you want separate spaces to draft in (a\nStaging environment you can experiment in before anything reaches Production, say), this is where\nthat's configured.\n\n## What's an environment?\n\nThere are two kinds:\n\n- **Authoring environments** are separate drafting spaces. Contracts, Templates, folders,\n  Components, the Experience tree, and Audiences are all specific to whichever authoring\n  environment you're currently working in — content in one is completely invisible from another,\n  as if they were separate organizations.\n- **Delivery environments** are separate published targets — what the Content Delivery API actually\n  serves to the outside world, and what a delivery key reads from.\n\nEvery organization starts with one of each, marked **Default**. The default is where publishing,\nnew delivery keys, and the environment switcher land when nothing more specific is chosen — you can\nchange which environment holds that role at any time (see **Managing environments** below).\n\n## Switching environments\n\nIf more than one authoring environment exists, a switcher appears in the header next to your\naccount. Pick one to start working there — every page reloads to show that environment's own\ncontent. Your choice is remembered per-organization, so it's still selected next time you sign in.\n\n## Managing environments\n\nOpen **Environments** under **Settings** in the app navigation (requires the \"Manage Environments\"\npermission — ask an Owner or administrator if it's not available to you).\n\n- **Create** a new authoring or delivery environment, give it a name. Your plan may limit how many\n  environments you can have in total. A newly created environment is added to the end of its\n  list.\n- **Reorder** the authoring or delivery list to whatever arrangement makes sense to your team —\n  drag a row to where you want it, or use the ▲/▼ buttons on each row. While dragging, the row\n  shows as a placeholder that moves to preview exactly where it'll land if you release. This sets\n  the order these lists and the environment switcher use, and where a not-yet-arranged box is\n  placed on the topology canvas below; once you've dragged a box on the canvas, the canvas keeps\n  where you put it. (A list with only one environment has nothing to reorder against, so dragging\n  is unavailable there.)\n- **Rename** any environment at any time — nothing else changes.\n- **Set as default**: on any non-default environment's row, this moves the Default badge to it and\n  clears it from wherever it was. Publishing, new delivery keys, and the environment switcher's own\n  default all follow immediately.\n- **Delete** any environment except the last remaining one of its kind. This is permanent and\n  immediate: everything authored (or, for a delivery environment, everything published) there is\n  gone, with no recovery. You'll be asked to type the environment's name to confirm. If the\n  environment currently publishes to a delivery target, promotes into another environment, or is\n  itself a promotion target, the confirmation names those connections — deleting still removes them\n  along with everything else. The current default can't be deleted directly while another\n  environment of its kind exists — set a different one as default first, then delete it.\n- **Refresh from…**: replace this environment's content wholesale from another authoring\n  environment — the routine \"copy Production down into Staging\" move. See\n  [environment-refresh.md](environment-refresh.md) for the full workflow, including how to rescue\n  work that would otherwise be lost.\n\n### The topology canvas\n\nOne canvas shows every way your environments connect to each other. Each environment is a box with\nfour small circles — **connectors** — one on each side. Each connection is a labelled line drawn\nbetween two boxes, and every line points the same way: **content can move along the arrow**.\n\nThere are three kinds, and the legend under the canvas names all three:\n\n- **publishes to** — an authoring environment publishes to a delivery environment.\n- **promotes into** — an authoring environment can promote content into another authoring\n  environment.\n- **inherited by** — an authoring environment's library is available, read-only, in another one.\n  The arrow runs from the parent to the child, the same direction the content travels.\n\nAll three are routing, not content. Changing one redirects where the next publish, promote or sync\nlands; it does not move anything by itself.\n\n**Drawing a connection.** Select a connector on the environment you want to connect *from*, then a\nconnector on the one you want to connect *to*. It works the same with a mouse (click one then the\nother, or drag between them) and with the keyboard alone (<kbd>Tab</kbd> to a connector,\n<kbd>Enter</kbd>, <kbd>Tab</kbd> to another, <kbd>Enter</kbd>). <kbd>Escape</kbd> cancels at any\npoint.\n\n**The connectors you choose are the ones the line uses**, and they stay that way — moving a box\nre-routes the line between the same two connectors rather than picking different ones. Pick whichever\nsides make your topology read best; if you want a line to come in from below, connect to the bottom\nconnector and that is where it will arrive, for everyone, after every reload.\n\nConnecting two *authoring* environments is the one case the canvas can't work out on its own, since\nthere are two relationships it could mean, so it asks: **Promote {A} into {B}** or **{B} inherits\nfrom {A}**. Everything else is decided by what you connected.\n\n**A delivery environment only receives.** Its box is marked *Receives only*, and its connectors\ncan't start a connection at all — there's nothing to click or drag from. That's not a rule you'll\ndiscover by being told off after the fact; the canvas simply can't draw the line.\n\n**When something isn't allowed**, a short message appears where you dropped the connection and\nnothing is saved:\n\n- *That would create a cycle in the promotion pipeline* / *…an inheritance cycle* — content can't\n  flow in a circle, directly or through a chain of other environments.\n- *Already connected* — that exact connection is already there.\n\n**A delivery environment can be published from only one authoring environment at a time.** Connect\none that's already claimed and you'll be asked to confirm reassigning it, naming the environment\nthat holds it now; confirming removes the other mapping. An authoring environment can promote into\nany number of others, and any number can promote into the same target — promotion has no such\nexclusivity. Each environment has at most one parent, so drawing an inheritance line into one that\nalready has a parent asks you to confirm replacing it — naming the parent it has **right now**,\nwhich is not always the one your page was showing if a colleague changed it while you had this open.\n\n**Removing a connection.** Select the **×** on the line's label, or **Remove** on the matching row\nin the Connections list below. Publishing and promotion lines go immediately — they're routing, and\nremoving one destroys nothing.\n\n**Removing a publishing line does not take your live site down.** Anything already published stays\npublished and keeps being served exactly as before: a published page is a finished copy held by the\ndelivery environment, not a view onto the authoring one. What stops is publishing itself — until you\ndraw the line again, you can't publish anything new to that environment or unpublish anything from\nit, and you'll be told so if you try. A delivery box in that state says *Still serving content\npublished from …* so it's clear the site is up even though nothing is connected to it.\n\nRemoving an inheritance line asks first, and explains that the content already inherited simply\nbecomes ordinary local content the child can edit: nothing is deleted.\n\n**Arranging the canvas.** Drag any box to where you want it. The arrangement is saved for your whole\norganization, so everyone sees the topology laid out the way you left it. Pan by dragging the\nbackground, zoom with the scroll wheel or the +/− buttons, and use the ⤢ button to fill the screen\n(<kbd>Escape</kbd> leaves full screen). An environment nobody has arranged yet is placed\nautomatically — authoring on the left, delivery on the right, in list order.\n\n**The Connections list** below the canvas says the same thing in words — *Live publishes to\nProduction* — grouped by the environment each connection starts from, with its own Remove on every\nrow. Use whichever you prefer; they're the same connections and the same actions.\n\nWithout the \"Manage Environments\" permission the canvas is read-only: you can pan, zoom, go full\nscreen and read the Connections list, but nothing offers to change anything.\n\n## Limiting who can use an environment\n\nBy default every member of your organization can open every authoring environment, with the role\nthey hold in the organization. That's usually what you want. When it isn't — an agency working on\none client's site, a contractor who should only see a Staging environment — you can limit a member\nto specific environments, and give them a different role in each.\n\nOpen **Environment access** at the bottom of the Environments page. Pick an environment, then choose\na member and the role they should have *in that environment*, and select **Bind member**. You can\nchange a bound member's role there at any time, or **Remove** them.\n\nThis needs the \"Assign member roles\" permission — the same one Hub uses to change a member's role —\nbecause giving someone a role in an environment is giving them that role. You also need \"View roles\",\nso the section can list the roles to choose from; if you have only one of the two, the section says\nwhich is missing.\n\n**What changes for a bound member:**\n\n- They can open **only** the environments they're bound to. The environment switcher shows just\n  those, and anything that names another environment is refused.\n- In each one they have the role you chose there, not their organization role — so someone can be\n  an editor in one environment and read-only in another.\n- The topology canvas is hidden from them, because it would show connections to environments they\n  can't see.\n\n**Owners are never limited.** They always reach every environment with full access, so they don't\nappear in the member list and the Owner role can't be chosen.\n\n**Removing a member's last binding gives them back access to every environment** with their\norganization role — it doesn't lock them out. Having no bindings at all is the normal, unrestricted\nstate. To take someone out of Content entirely, change their role in Hub instead.\n\n**Uploaded files follow the same boundary.** Someone limited to certain environments can open an\nimage or file that's used by content in one of those environments, or that they uploaded there\nthemselves. Anything else reports as not found, exactly as a file that doesn't exist would — so they\ncan't tell what exists elsewhere. Nobody unrestricted, and no Owner, is affected.\n\n**Setting up an outside collaborator.** Give them a minimal organization role in Hub, then bind their\nreal role per environment here — **Content Author** is usually the one you want. Their organization\nrole is what applies everywhere outside Content, and the bound role is what applies inside it. See\n**Working with someone outside your team** in the Hub organizations guide for the Hub half, and\n**What roles can do in an environment** below if they should write content but not publish it.\n\n## What roles can do in an environment\n\nBeing able to open an environment isn't the same as being able to do everything in it. **What roles\ncan do here**, below Environment access on the Environments page, sets what each role may do\nthroughout one authoring environment.\n\nTick a role for **Edit**, **Delete** or **Publish**. Viewing is included automatically with any of\nthem, so there's no separate tick for it.\n\nThe part that reads backwards, so it's worth saying plainly: **an action with no ticks at all is\nunrestricted.** Anyone who can open the environment can do it. Ticking roles is what restricts an\naction to those roles, and removing the last tick for an action makes it unrestricted again — so\nclearing ticks *widens* access rather than removing it. An environment where you've never set\nanything up behaves exactly as it always has.\n\nThis is the only place that can restrict content filed outside any folder. Rules you set on a\nfolder or a page still win for that branch, so the usual shape is: restrict publishing across the\nenvironment here, then grant it back on the one section a team owns.\n\nA typical setup for a writer who shouldn't publish:\n\n1. Tick **Edit** for Content Author, so editing is restricted to roles you name — including them.\n2. Leave **Publish** ticked only for the roles that should publish. Content Author isn't one.\n3. They can now write and change content anywhere in the environment, and publish nothing.\n\nAnyone holding the \"Manage access\" permission is unaffected by these rules, so an environment can\nnever be configured into a state nobody can fix.\n\n## Promoting content\n\nPromoting copies a Component or Experience node — and everything it needs (its Contract, Template,\nany Audiences its variants reference, referenced Components, ancestor folders) — from the\nenvironment you're in into another one, ready to be worked on or published there. This is different\nfrom publishing: promoting moves *draft* content between authoring spaces; publishing takes draft\ncontent live to visitors.\n\nSelect **Promote…** on a Component or Experience node — a target is already picked for you (the\nfirst one configured, changeable from the dropdown if more than one exists), so you'll usually go\nstraight to reviewing the plan below rather than choosing first. If your current environment has no\npromotion target configured at all, **Promote…** is disabled with an explanation — set one up under\n[Managing environments](#managing-environments) first. Once a target is resolved, you'll see\neverything about to move, each marked:\n\n- **New** — doesn't exist in the target yet.\n- **Update** — already exists there, unchanged since it was last promoted; safe to overwrite.\n- **Diverged** — already exists there, but has been edited directly in the target (or promoted from\n  somewhere else) since the last time this same source promoted it. You'll need to explicitly\n  confirm overwriting it — nothing diverged is ever silently replaced. Whatever was there before\n  stays recoverable in its own version history.\n\nContracts, Templates, Audiences, and ancestor folders/nodes always move along with the item you're\npromoting — there's no separate choice for those. Referenced Components can be unchecked\nindividually if you don't want them to move yet; a skipped reference is simply left as-is in the\ntarget, pointing at whatever (if anything) is already there. If the item you're skipping doesn't\nexist in the target at all yet, a note appears explaining that this leaves a dangling reference\nthere until it's promoted — see [Unresolved references](#unresolved-references-component-sync)\nbelow for how to find and fix one later.\n\nPromoting requires the same **Publish** permission the item's own branch requires; promoting a\nContract, Template, or Audience along with it additionally requires the permission to manage that\nkind of thing directly.\n\n### Promoting a Contract, Template, or Audience on its own\n\nA schema-only change — a field added to a Contract, an adjusted Template, a fixed Audience\ncondition — can be promoted by itself, without touching any Component that happens to use it.\nSelect **Promote…** directly from the Contract builder, the Template builder, or next to an\nAudience on the Audiences settings page. The same **New**/**Update**/**Diverged** states and\noverwrite confirmation apply; a Template's own settings Contract and a provider-contributed\nContract can't be promoted this way (promote the Template instead, or refresh/manage the provider\nregistration). This needs the permission to manage that kind of thing directly — there's no\n**Publish** branch involved, since Contracts/Templates/Audiences aren't organized into branches.\n\n## Unresolved references (Component Sync)\n\nSkipping a referenced Component during promotion (above) — or publishing a Component whose\nreference was already skipped in an earlier promotion — leaves that reference pointing at\nsomething that doesn't exist in this environment. This is allowed on purpose: it never blocks a\npromotion or a publish, and delivery itself handles it gracefully (the missing reference is simply\nomitted from what's served). But nothing else ever tells you it happened unless you go looking, so\n**Component Sync**, under **Settings** in the app navigation, lists every one currently in your\nenvironment: which Component or Experience node has the broken reference, which field it's in, and\n— where this environment has a direct upstream promotion source that still has the missing item —\nwhich environment that is.\n\nYou'll also see it called out in two other places, right where it matters: opening a Component\nwhose reference is broken shows an **Unresolved** badge in place of the usual resolved name, with a\nlink straight to its Component Sync entry; and publishing a closure that contains one shows a\nnon-blocking banner naming the affected item (publishing still proceeds — this is a heads-up, not a\nnew restriction).\n\n**To fix one:** promote the missing item forward from the environment Component Sync names — but\nthat step alone isn't enough on its own, because promoting the missing item doesn't touch the\nComponent that references it. Once the missing item exists here, **re-promote the referencing\nComponent too** (from wherever you originally promoted it), so its reference is re-checked against\nwhat's now available. After that second promotion, the entry disappears from Component Sync, the\nbadge on the Component resolves back to a normal name, and any publish banner clears.\n\n## Sharing content across environments (inheritance)\n\nPromoting is a deliberate, one-time push — good for moving a specific change from Staging to\nProduction. If instead you have content a *whole family* of environments should all draw from —\nshared design-system blocks, legal boilerplate, a common set of media Contracts — set up\ninheritance instead: link a \"Shared\" environment as the **parent** of each sibling that should\nreceive its content, and every relevant item in Shared shows up as a read-only copy in each child,\nkept up to date with a button press rather than a promotion per environment per change.\n\n**To link a parent:** draw an inheritance line on the topology canvas, from the parent to the\nchild, and choose **{child} inherits from {parent}** when the canvas asks which relationship you\nmeant. Removing that line unlinks them. The child's row also shows its current parent, as text —\nthe canvas is where you change it, so the two can never disagree. An environment can have at most\none parent, and a chain is fine (Shared → Region → Brand), but a loop is rejected.\n\n**To bring the parent's content in:** select **Sync now** on the child's row. This copies the\nparent's Contracts, Templates, Audiences, taxonomy, folders, and Components into the child,\nmarked as inherited. Running it again later picks up anything the parent has changed since —\nnew items appear, changed ones update, and anything the parent no longer has disappears from the\nchild too (unless something local in the child still depends on it, in which case the sync stops\nand tells you what's blocking it, so you can resolve that first). Nothing is ever half-applied — a\nsync either finishes completely or leaves the child exactly as it was.\n\n**Inherited items are read-only** in the child — you'll see an \"Inherited\" label on them, and any\nattempt to edit, rename, move, or delete one is refused with an explanation pointing you back to\nthe parent (or the Environments page, to unlink). You can still **publish** or **promote** an\ninherited Component from the child normally — it publishes as the child's own copy, just like\nanything else there.\n\n**Unlinking** a parent (or switching to a different one) doesn't delete anything — the child's\ncopies simply become ordinary local content you can edit freely from then on. If you relink the\nsame parent later and it now has a different version of something the child already has, syncing\nwill flag it and ask you to confirm before overwriting — your child's edit is version-recorded\nfirst, so nothing is lost even then.\n\nDeleting a parent environment automatically unlinks every child that pointed to it, the same way —\ntheir copies stay in place and become editable, nothing is deleted along with the parent.\n\n## How this affects everything else\n\nIf you never create a second environment, nothing here changes anything: the switcher never\nappears, publishing and delivery keys keep using your one delivery environment automatically, and\nthere's no promotion to do. See [publishing.md](publishing.md) for the publish lifecycle,\n[content-personalization.md](content-personalization.md) for Audiences (which, like everything else\nyou author, belong to one environment), and [content-providers.md](content-providers.md) for\ncopying a registered content provider between environments.\n"
+        "body": "# Content environments\n\nBy default, your organization has one authoring space and one place published content goes live —\nyou'll never need this page if that's all you use. If you want separate spaces to draft in (a\nStaging environment you can experiment in before anything reaches Production, say), this is where\nthat's configured.\n\n## What's an environment?\n\nThere are two kinds:\n\n- **Authoring environments** are separate drafting spaces. Contracts, Templates, folders,\n  Components, the Experience tree, and Audiences are all specific to whichever authoring\n  environment you're currently working in — content in one is completely invisible from another,\n  as if they were separate organizations.\n- **Delivery environments** are separate published targets — what the Content Delivery API actually\n  serves to the outside world, and what a delivery key reads from.\n\nEvery organization starts with one of each, marked **Default**. The default is where publishing,\nnew delivery keys, and the environment switcher land when nothing more specific is chosen — you can\nchange which environment holds that role at any time (see **Managing environments** below).\n\n## Switching environments\n\nIf more than one authoring environment exists, a switcher appears in the header next to your\naccount. Pick one to start working there — every page reloads to show that environment's own\ncontent. Your choice is remembered per-organization, so it's still selected next time you sign in.\n\n## Managing environments\n\nOpen **Environments** under **Settings** in the app navigation (requires the \"Manage Environments\"\npermission — ask an Owner or administrator if it's not available to you).\n\n- **Create** a new authoring or delivery environment, give it a name. Your plan limits authoring\n  and delivery environments **separately**, not as one combined total — Subscriptions & Billing\n  shows both, with how many you're using. A newly created environment is added to the end of its\n  list.\n- **Reorder** the authoring or delivery list to whatever arrangement makes sense to your team —\n  drag a row to where you want it, or use the ▲/▼ buttons on each row. While dragging, the row\n  shows as a placeholder that moves to preview exactly where it'll land if you release. This sets\n  the order these lists and the environment switcher use, and where a not-yet-arranged box is\n  placed on the topology canvas below; once you've dragged a box on the canvas, the canvas keeps\n  where you put it. (A list with only one environment has nothing to reorder against, so dragging\n  is unavailable there.)\n- **Rename** any environment at any time — nothing else changes.\n- **Set as default**: on any non-default environment's row, this moves the Default badge to it and\n  clears it from wherever it was. Publishing, new delivery keys, and the environment switcher's own\n  default all follow immediately.\n- **Delete** any environment except the last remaining one of its kind. This is permanent and\n  immediate: everything authored (or, for a delivery environment, everything published) there is\n  gone, with no recovery. You'll be asked to type the environment's name to confirm. If the\n  environment currently publishes to a delivery target, promotes into another environment, or is\n  itself a promotion target, the confirmation names those connections — deleting still removes them\n  along with everything else. The current default can't be deleted directly while another\n  environment of its kind exists — set a different one as default first, then delete it.\n- **Refresh from…**: replace this environment's content wholesale from another authoring\n  environment — the routine \"copy Production down into Staging\" move. See\n  [environment-refresh.md](environment-refresh.md) for the full workflow, including how to rescue\n  work that would otherwise be lost.\n\n### The topology canvas\n\nOne canvas shows every way your environments connect to each other. Each environment is a box with\nfour small circles — **connectors** — one on each side. Each connection is a labelled line drawn\nbetween two boxes, and every line points the same way: **content can move along the arrow**.\n\nThere are three kinds, and the legend under the canvas names all three:\n\n- **publishes to** — an authoring environment publishes to a delivery environment.\n- **promotes into** — an authoring environment can promote content into another authoring\n  environment.\n- **inherited by** — an authoring environment's library is available, read-only, in another one.\n  The arrow runs from the parent to the child, the same direction the content travels.\n\nAll three are routing, not content. Changing one redirects where the next publish, promote or sync\nlands; it does not move anything by itself.\n\n**Drawing a connection.** Select a connector on the environment you want to connect *from*, then a\nconnector on the one you want to connect *to*. It works the same with a mouse (click one then the\nother, or drag between them) and with the keyboard alone (<kbd>Tab</kbd> to a connector,\n<kbd>Enter</kbd>, <kbd>Tab</kbd> to another, <kbd>Enter</kbd>). <kbd>Escape</kbd> cancels at any\npoint.\n\n**The connectors you choose are the ones the line uses**, and they stay that way — moving a box\nre-routes the line between the same two connectors rather than picking different ones. Pick whichever\nsides make your topology read best; if you want a line to come in from below, connect to the bottom\nconnector and that is where it will arrive, for everyone, after every reload.\n\nConnecting two *authoring* environments is the one case the canvas can't work out on its own, since\nthere are two relationships it could mean, so it asks: **Promote {A} into {B}** or **{B} inherits\nfrom {A}**. Everything else is decided by what you connected.\n\n**A delivery environment only receives.** Its box is marked *Receives only*, and its connectors\ncan't start a connection at all — there's nothing to click or drag from. That's not a rule you'll\ndiscover by being told off after the fact; the canvas simply can't draw the line.\n\n**When something isn't allowed**, a short message appears where you dropped the connection and\nnothing is saved:\n\n- *That would create a cycle in the promotion pipeline* / *…an inheritance cycle* — content can't\n  flow in a circle, directly or through a chain of other environments.\n- *Already connected* — that exact connection is already there.\n\n**A delivery environment can be published from only one authoring environment at a time.** Connect\none that's already claimed and you'll be asked to confirm reassigning it, naming the environment\nthat holds it now; confirming removes the other mapping. An authoring environment can promote into\nany number of others, and any number can promote into the same target — promotion has no such\nexclusivity. Each environment has at most one parent, so drawing an inheritance line into one that\nalready has a parent asks you to confirm replacing it — naming the parent it has **right now**,\nwhich is not always the one your page was showing if a colleague changed it while you had this open.\n\n**Removing a connection.** Select the **×** on the line's label, or **Remove** on the matching row\nin the Connections list below. Publishing and promotion lines go immediately — they're routing, and\nremoving one destroys nothing.\n\n**Removing a publishing line does not take your live site down.** Anything already published stays\npublished and keeps being served exactly as before: a published page is a finished copy held by the\ndelivery environment, not a view onto the authoring one. What stops is publishing itself — until you\ndraw the line again, you can't publish anything new to that environment or unpublish anything from\nit, and you'll be told so if you try. A delivery box in that state says *Still serving content\npublished from …* so it's clear the site is up even though nothing is connected to it.\n\nRemoving an inheritance line asks first, and explains that the content already inherited simply\nbecomes ordinary local content the child can edit: nothing is deleted.\n\n**Arranging the canvas.** Drag any box to where you want it. The arrangement is saved for your whole\norganization, so everyone sees the topology laid out the way you left it. Pan by dragging the\nbackground, zoom with the scroll wheel or the +/− buttons, and use the ⤢ button to fill the screen\n(<kbd>Escape</kbd> leaves full screen). An environment nobody has arranged yet is placed\nautomatically — authoring on the left, delivery on the right, in list order.\n\n**The Connections list** below the canvas says the same thing in words — *Live publishes to\nProduction* — grouped by the environment each connection starts from, with its own Remove on every\nrow. Use whichever you prefer; they're the same connections and the same actions.\n\nWithout the \"Manage Environments\" permission the canvas is read-only: you can pan, zoom, go full\nscreen and read the Connections list, but nothing offers to change anything.\n\n## Limiting who can use an environment\n\nBy default every member of your organization can open every authoring environment, with the role\nthey hold in the organization. That's usually what you want. When it isn't — an agency working on\none client's site, a contractor who should only see a Staging environment — you can limit a member\nto specific environments, and give them a different role in each.\n\nOpen **Environment access** at the bottom of the Environments page. Pick an environment, then choose\na member and the role they should have *in that environment*, and select **Bind member**. You can\nchange a bound member's role there at any time, or **Remove** them.\n\nThis needs the \"Assign member roles\" permission — the same one Hub uses to change a member's role —\nbecause giving someone a role in an environment is giving them that role. You also need \"View roles\",\nso the section can list the roles to choose from; if you have only one of the two, the section says\nwhich is missing.\n\n**What changes for a bound member:**\n\n- They can open **only** the environments they're bound to. The environment switcher shows just\n  those, and anything that names another environment is refused.\n- In each one they have the role you chose there, not their organization role — so someone can be\n  an editor in one environment and read-only in another.\n- The topology canvas is hidden from them, because it would show connections to environments they\n  can't see.\n\n**Owners are never limited.** They always reach every environment with full access, so they don't\nappear in the member list and the Owner role can't be chosen.\n\n**Removing a member's last binding gives them back access to every environment** with their\norganization role — it doesn't lock them out. Having no bindings at all is the normal, unrestricted\nstate. To take someone out of Content entirely, change their role in Hub instead.\n\n**Uploaded files follow the same boundary.** Someone limited to certain environments can open an\nimage or file that's used by content in one of those environments, or that they uploaded there\nthemselves. Anything else reports as not found, exactly as a file that doesn't exist would — so they\ncan't tell what exists elsewhere. Nobody unrestricted, and no Owner, is affected.\n\n**Setting up an outside collaborator.** Give them a minimal organization role in Hub, then bind their\nreal role per environment here — **Content Author** is usually the one you want. Their organization\nrole is what applies everywhere outside Content, and the bound role is what applies inside it. See\n**Working with someone outside your team** in the Hub organizations guide for the Hub half, and\n**What roles can do in an environment** below if they should write content but not publish it.\n\n## What roles can do in an environment\n\nBeing able to open an environment isn't the same as being able to do everything in it. **What roles\ncan do here**, below Environment access on the Environments page, sets what each role may do\nthroughout one authoring environment.\n\nTick a role for **Edit**, **Delete** or **Publish**. Viewing is included automatically with any of\nthem, so there's no separate tick for it.\n\nThe part that reads backwards, so it's worth saying plainly: **an action with no ticks at all is\nunrestricted.** Anyone who can open the environment can do it. Ticking roles is what restricts an\naction to those roles, and removing the last tick for an action makes it unrestricted again — so\nclearing ticks *widens* access rather than removing it. An environment where you've never set\nanything up behaves exactly as it always has.\n\nThis is the only place that can restrict content filed outside any folder. Rules you set on a\nfolder or a page still win for that branch, so the usual shape is: restrict publishing across the\nenvironment here, then grant it back on the one section a team owns.\n\nA typical setup for a writer who shouldn't publish:\n\n1. Tick **Edit** for Content Author, so editing is restricted to roles you name — including them.\n2. Leave **Publish** ticked only for the roles that should publish. Content Author isn't one.\n3. They can now write and change content anywhere in the environment, and publish nothing.\n\nAnyone holding the \"Manage access\" permission is unaffected by these rules, so an environment can\nnever be configured into a state nobody can fix.\n\n## Promoting content\n\nPromoting copies a Component or Experience node — and everything it needs (its Contract, Template,\nany Audiences its variants reference, referenced Components, ancestor folders) — from the\nenvironment you're in into another one, ready to be worked on or published there. This is different\nfrom publishing: promoting moves *draft* content between authoring spaces; publishing takes draft\ncontent live to visitors.\n\nSelect **Promote…** on a Component or Experience node — a target is already picked for you (the\nfirst one configured, changeable from the dropdown if more than one exists), so you'll usually go\nstraight to reviewing the plan below rather than choosing first. If your current environment has no\npromotion target configured at all, **Promote…** is disabled with an explanation — set one up under\n[Managing environments](#managing-environments) first. Once a target is resolved, you'll see\neverything about to move, each marked:\n\n- **New** — doesn't exist in the target yet.\n- **Update** — already exists there, unchanged since it was last promoted; safe to overwrite.\n- **Diverged** — already exists there, but has been edited directly in the target (or promoted from\n  somewhere else) since the last time this same source promoted it. You'll need to explicitly\n  confirm overwriting it — nothing diverged is ever silently replaced. Whatever was there before\n  stays recoverable in its own version history.\n\nContracts, Templates, Audiences, and ancestor folders/nodes always move along with the item you're\npromoting — there's no separate choice for those. Referenced Components can be unchecked\nindividually if you don't want them to move yet; a skipped reference is simply left as-is in the\ntarget, pointing at whatever (if anything) is already there. If the item you're skipping doesn't\nexist in the target at all yet, a note appears explaining that this leaves a dangling reference\nthere until it's promoted — see [Unresolved references](#unresolved-references-component-sync)\nbelow for how to find and fix one later.\n\nPromoting requires the same **Publish** permission the item's own branch requires; promoting a\nContract, Template, or Audience along with it additionally requires the permission to manage that\nkind of thing directly.\n\n### Promoting a Contract, Template, or Audience on its own\n\nA schema-only change — a field added to a Contract, an adjusted Template, a fixed Audience\ncondition — can be promoted by itself, without touching any Component that happens to use it.\nSelect **Promote…** directly from the Contract builder, the Template builder, or next to an\nAudience on the Audiences settings page. The same **New**/**Update**/**Diverged** states and\noverwrite confirmation apply; a Template's own settings Contract and a provider-contributed\nContract can't be promoted this way (promote the Template instead, or refresh/manage the provider\nregistration). This needs the permission to manage that kind of thing directly — there's no\n**Publish** branch involved, since Contracts/Templates/Audiences aren't organized into branches.\n\n## Unresolved references (Component Sync)\n\nSkipping a referenced Component during promotion (above) — or publishing a Component whose\nreference was already skipped in an earlier promotion — leaves that reference pointing at\nsomething that doesn't exist in this environment. This is allowed on purpose: it never blocks a\npromotion or a publish, and delivery itself handles it gracefully (the missing reference is simply\nomitted from what's served). But nothing else ever tells you it happened unless you go looking, so\n**Component Sync**, under **Settings** in the app navigation, lists every one currently in your\nenvironment: which Component or Experience node has the broken reference, which field it's in, and\n— where this environment has a direct upstream promotion source that still has the missing item —\nwhich environment that is.\n\nYou'll also see it called out in two other places, right where it matters: opening a Component\nwhose reference is broken shows an **Unresolved** badge in place of the usual resolved name, with a\nlink straight to its Component Sync entry; and publishing a closure that contains one shows a\nnon-blocking banner naming the affected item (publishing still proceeds — this is a heads-up, not a\nnew restriction).\n\n**To fix one:** promote the missing item forward from the environment Component Sync names — but\nthat step alone isn't enough on its own, because promoting the missing item doesn't touch the\nComponent that references it. Once the missing item exists here, **re-promote the referencing\nComponent too** (from wherever you originally promoted it), so its reference is re-checked against\nwhat's now available. After that second promotion, the entry disappears from Component Sync, the\nbadge on the Component resolves back to a normal name, and any publish banner clears.\n\n## Sharing content across environments (inheritance)\n\nPromoting is a deliberate, one-time push — good for moving a specific change from Staging to\nProduction. If instead you have content a *whole family* of environments should all draw from —\nshared design-system blocks, legal boilerplate, a common set of media Contracts — set up\ninheritance instead: link a \"Shared\" environment as the **parent** of each sibling that should\nreceive its content, and every relevant item in Shared shows up as a read-only copy in each child,\nkept up to date with a button press rather than a promotion per environment per change.\n\n**To link a parent:** draw an inheritance line on the topology canvas, from the parent to the\nchild, and choose **{child} inherits from {parent}** when the canvas asks which relationship you\nmeant. Removing that line unlinks them. The child's row also shows its current parent, as text —\nthe canvas is where you change it, so the two can never disagree. An environment can have at most\none parent, and a chain is fine (Shared → Region → Brand), but a loop is rejected.\n\n**To bring the parent's content in:** select **Sync now** on the child's row. This copies the\nparent's Contracts, Templates, Audiences, taxonomy, folders, and Components into the child,\nmarked as inherited. Running it again later picks up anything the parent has changed since —\nnew items appear, changed ones update, and anything the parent no longer has disappears from the\nchild too (unless something local in the child still depends on it, in which case the sync stops\nand tells you what's blocking it, so you can resolve that first). Nothing is ever half-applied — a\nsync either finishes completely or leaves the child exactly as it was.\n\n**Inherited items are read-only** in the child — you'll see an \"Inherited\" label on them, and any\nattempt to edit, rename, move, or delete one is refused with an explanation pointing you back to\nthe parent (or the Environments page, to unlink). You can still **publish** or **promote** an\ninherited Component from the child normally — it publishes as the child's own copy, just like\nanything else there.\n\n**Unlinking** a parent (or switching to a different one) doesn't delete anything — the child's\ncopies simply become ordinary local content you can edit freely from then on. If you relink the\nsame parent later and it now has a different version of something the child already has, syncing\nwill flag it and ask you to confirm before overwriting — your child's edit is version-recorded\nfirst, so nothing is lost even then.\n\nDeleting a parent environment automatically unlinks every child that pointed to it, the same way —\ntheir copies stay in place and become editable, nothing is deleted along with the parent.\n\n## How this affects everything else\n\nIf you never create a second environment, nothing here changes anything: the switcher never\nappears, publishing and delivery keys keep using your one delivery environment automatically, and\nthere's no promotion to do. See [publishing.md](publishing.md) for the publish lifecycle,\n[content-personalization.md](content-personalization.md) for Audiences (which, like everything else\nyou author, belong to one environment), and [content-providers.md](content-providers.md) for\ncopying a registered content provider between environments.\n"
     },
     {
         "slug": "content-links",
@@ -66,7 +66,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-workflow",
         "title": "Editorial workflow",
-        "body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n  where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n  into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n  review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n  another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n  for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n  the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n  (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n  editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n  review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n  sides — click one, then click a connector on the state you want to connect it to (or drag from\n  one to the other). Click the new transition's label to name it and, optionally, restrict who may\n  fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n  organization member fire it. A state without any wiring simply never occurs — there's no way to\n  reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n  **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n  transition: there's nothing to drag or click to start one from it, since it can never be the\n  source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n  can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n  people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — pick a channel (email or in-app) and one or more recipients. **This doesn't send\n  anything yet** — no notification channel is configured for this organization. The attempt is still\n  recorded (see Activity Log below), so you can see exactly when it *would* have fired once sending\n  is available.\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n  details to that URL. A URL that resolves to a private or internal address is rejected when you try\n  to save it.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n\"Enters that state\" means however it got there, including when nobody was involved. A review that\nstarts on its own — a translation job finishing, or a proposal arriving from a form or another\nsystem — fires whatever is attached to the state it starts in, and anything attached to a step the\nworkflow takes automatically after that. That is usually the point of attaching one: nobody is\nwatching when a proposal arrives, which is exactly why you want to be told. A Webhook fired this way\nsays so in its payload (`\"runStarted\": true`), since there was no transition and no previous state\nto name.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n  none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n  branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n  of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n  the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component (under its **Settings** tab) or an Experience node under a governed branch and\nyou'll see a workflow panel showing its current state. If it's still in a non-publishable state,\nthe **Publish** button — always visible in the Component editor's header, regardless of which tab\nyou're on — is disabled and explains why.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify always shows \"not delivered (no\nnotification channel configured)\" — the reminder that it's recorded, not sent, until this\norganization has a notification channel set up.\n"
+        "body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n  where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n  into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n  review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n  another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n  for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n  the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n  (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n  editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n  review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n  sides — click one, then click a connector on the state you want to connect it to (or drag from\n  one to the other). Click the new transition's label to name it and, optionally, restrict who may\n  fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n  organization member fire it. A state without any wiring simply never occurs — there's no way to\n  reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n  **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n  transition: there's nothing to drag or click to start one from it, since it can never be the\n  source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n  can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n  people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — pick a channel (email or in-app) and one or more recipients. **This doesn't send\n  anything yet** — no notification channel is configured for this organization. The attempt is still\n  recorded (see Activity Log below), so you can see exactly when it *would* have fired once sending\n  is available.\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n  details to that URL. A URL that resolves to a private or internal address is rejected when you try\n  to save it. You can also set a **signing secret**, so the system receiving the request can prove it\n  came from us — see **Making sure a webhook really came from us**, below.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n\"Enters that state\" means however it got there, including when nobody was involved. A review that\nstarts on its own — a translation job finishing, or a proposal arriving from a form or another\nsystem — fires whatever is attached to the state it starts in, and anything attached to a step the\nworkflow takes automatically after that. That is usually the point of attaching one: nobody is\nwatching when a proposal arrives, which is exactly why you want to be told. A Webhook fired this way\nsays so in two places: its event type is `content.workflow.runStarted` rather than\n`content.workflow.transitioned`, and `\"runStarted\": true` appears in the payload — because there was\nno transition and no previous state to name.\n\n## Making sure a webhook really came from us\n\nA webhook is an ordinary `POST` to a URL you chose, so anyone who learns that URL could send one.\nSetting a **signing secret** on the Webhook node closes that: we sign every request with it, and your\nsystem can check the signature before trusting anything in the body.\n\nLeave the secret blank and requests are sent unsigned, exactly as before — nothing you have already\nset up changes.\n\nThe secret is write-only. Once saved, the node shows **Configured** rather than the value, and we\nnever send it back to your browser. To change it, select **Replace** and enter a new one; to stop\nsigning, select **Replace** and save with the field empty. Editing anything else about the workflow\nleaves the secret alone.\n\nChanging the destination URL does **not** carry the secret over, deliberately — a different URL is a\ndifferent system, and it should get its own secret rather than inheriting one silently.\n\nEvery request carries two headers:\n\n```\nX-Ebitex-Signature: v1,t=1790000591,s=<signature>\nX-Ebitex-Delivery: whd_0123456789abcdef0123456789abcdef\n```\n\nYour system should recompute the signature over the exact bytes it received and compare. The full\nrecipe, with worked examples in several languages, is on our developer site — see\n[developers.ebitex.io](https://developers.ebitex.io). Two things that catch people out: sign the raw\nbody you received rather than re-encoding it first, and compare using a constant-time comparison\nrather than `==`.\n\n`X-Ebitex-Delivery` identifies one delivery. If we retry after a failure, the retry carries the same\nid, so your system can recognise it as a repeat rather than a second event. Use it to ignore\nduplicates.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n  none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n  branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n  of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n  the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component (under its **Settings** tab) or an Experience node under a governed branch and\nyou'll see a workflow panel showing its current state. If it's still in a non-publishable state,\nthe **Publish** button — always visible in the Component editor's header, regardless of which tab\nyou're on — is disabled and explains why.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify always shows \"not delivered (no\nnotification channel configured)\" — the reminder that it's recorded, not sent, until this\norganization has a notification channel set up.\n"
     },
     {
         "slug": "contracts",
@@ -81,7 +81,7 @@ export const HELP_TOPICS = [
     {
         "slug": "export-import",
         "title": "Export and import",
-        "body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n  back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n  a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n  same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n  back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n  anything. Required when importing into a different organization than the one the bundle came\n  from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n  confirming you want the bundle's version to replace what's here. (The version being replaced is\n  saved first, so it isn't lost — see the item's own version history afterward if you need it\n  back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\nA large bundle can take a while, and the button counts items off as they're applied. The import runs\non the server rather than in this browser tab, so it keeps going if you close the dialog or reload\nthe page — reopening it picks the same import back up and carries on showing progress. If something\ndoes go wrong, nothing is left half-applied: the whole import is undone, and the reason appears next\nto the **Import** button.\n\n### Plan limits\n\nYour plan limits how many components, pages and categories your organization can have, counted\nacross all of its authoring environments. An import that would take you past one of those limits is\nrefused before anything is written, and the message says which limit and by how much. The import\nplan warns you about this before you click **Import**.\n\nOnly the items an import *creates* count. Importing a bundle that only updates content you already\nhave is never refused for this, even if you are over a limit.\n\nPromoting content, syncing an environment from its parent, and refreshing an environment are never\nrefused for this reason either. They copy content your organization already has, and being unable to\npromote to production would be worse than going over. If one of them takes you over a limit, you can\nkeep editing, but you can't create more of that kind of item until you upgrade or remove some.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
+        "body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n  back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n  a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n  same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n  back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n  anything. Required when importing into a different organization than the one the bundle came\n  from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n  confirming you want the bundle's version to replace what's here. (The version being replaced is\n  saved first, so it isn't lost — see the item's own version history afterward if you need it\n  back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\nA large bundle can take a while, and the button counts items off as they're applied. The import runs\non the server rather than in this browser tab, so it keeps going if you close the dialog or reload\nthe page — reopening it picks the same import back up and carries on showing progress. If something\ndoes go wrong, nothing is left half-applied: the whole import is undone, and the reason appears next\nto the **Import** button.\n\n### Plan limits\n\nYour plan limits how many components, pages and categories your organization can have, counted\nacross all of its authoring environments. **Organizations > Subscriptions & Billing** shows each\nlimit and how much of it you're using. An import that would take you past one of those limits is\nrefused before anything is written, and the message says which limit and by how much. The import\nplan warns you about this before you click **Import**.\n\nOnly the items an import *creates* count. Importing a bundle that only updates content you already\nhave is never refused for this, even if you are over a limit.\n\nPromoting content, syncing an environment from its parent, and refreshing an environment are never\nrefused for this reason either. They copy content your organization already has, and being unable to\npromote to production would be worse than going over. If one of them takes you over a limit, you can\nkeep editing, but you can't create more of that kind of item until you upgrade or remove some.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
     },
     {
         "slug": "locale-addressing",

package/dist/resources/helpCorpus.generated.js.map

@@ -1 +1 @@
-{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,qyfAAqyf;KAC9yf;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,mxqBAAmxqB;KAC5xqB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,wvJAAwvJ;KACjwJ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,85SAA85S;KACv6S;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,s2XAAs2X;KAC/2X;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,w5JAAw5J;KACj6J;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,qmMAAqmM;KAC9mM;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,m7KAAm7K;KAC57K;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}
+{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,qyfAAqyf;KAC9yf;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,s3qBAAs3qB;KAC/3qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,wvJAAwvJ;KACjwJ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,k4WAAk4W;KAC34W;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,s2XAAs2X;KAC/2X;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u/JAAu/J;KAChgK;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,qmMAAqmM;KAC9mM;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,m7KAAm7K;KAC57K;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ebitex/content-mcp",
-  "version": "0.5.113",
+  "version": "0.5.114",
   "description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
   "license": "Apache-2.0",
   "homepage": "https://developers.ebitex.io/getting-started/content-as-code/",