Limits and caps

Every limit worth planning around, taken from the product rather than from assumption.

Several of these are absences rather than numbers: things the assistant deliberately does not do.

#Limits

• Scope is site-wide, or one whole space, plus an optional search filter. There is no page picker and no page-count cap, and no confirmation dialog before a site-wide run, the only guard is the four acknowledgements on step 1.

• There is no "re-run failures only" action. The hints tell you which pages need re-running, but nothing narrows the next run to them for you.

• The entire run happens in the browser tab. Nothing is stored on a server, so there is no way to close the tab and come back to a run in progress, and no notification when it finishes.

• Pages are processed oldest-first by page ID, not by space or importance, so a partial run covers the oldest content first.

• Options are set two steps before the run buttons, and the wizard never returns you to them.

• Repair tools exist only for draw.io diagrams. A failed or unsupported macro from any other vendor app has no fix-forward path beyond re-running, rolling back, or sending a debug bundle to support.

• Repair tools never sweep the site. Every one of them only looks at pages you hand it, from a downloaded log or by page ID.

• Repair tools run as you, without the admin key option and without the rate-limit retry the migration itself uses, so their reach can be narrower than the run that created the problem and large batches behave differently under load.

• A repair rewrites the whole page, not just the macro, and the page body is normalised on the way through, so a repair can incidentally tidy unrelated formatting such as out-of-range heading levels or fractional table column widths.

• Cancel on a repair is cooperative rather than immediate: it stops the queue between pages, so pages already in flight will still complete and write.

• Debug bundles are capped at 25 pages regardless of how many pages hit the same problem.

• Drill-down from an issue group lists at most 2,000 pages, so on a very large run the group's count and its drill-down list will disagree. The counts are the accurate ones.

• Recognised-versus-unexpected failure classification is based on matching the wording of the error message, so it is a helpful heuristic rather than a guarantee. A genuinely new failure whose wording happens to resemble a known one will be shown as explained and will not offer the route to support.

• Several migrators are deliberately not offered and never appear in the wizard, no matter what is installed: Gliffy (held back because the converter still has fidelity gaps on real-world diagrams), Viadee BPMN Modeler and DMN Modeler, three Vectors layout macros (panels, tabs, expanders), the two MacroSuite Swagger converters, and the Just Add+ HTML converter. Documentation must not list any of these as supported, even though long-form notes for some of them exist in the product.

• Standalone-to-suite migrators are hidden outside the Capable Suite, and Search migrators are hidden outside Search and the Suite, with no on-screen explanation in either case.

• There is a second, separate macro catalogue inside the product that the migration wizard does not use. It feeds the Quality byline, the Quality macro rules page and the Search third-party macro filter, and it disagrees with the real migrator list in places. Do not build a "what Capable can migrate" list from it.

• A repair from the log-driven "Detected issues" scope cannot find the single-embed multi-tab case; those pages must be added by ID.

#A few things that catch people out

• A drill-down list caps at 2,000 pages while the count above it does not. The counts are the accurate ones.

• Debug bundles cap at 25 pages and sample the rest, so a bundle is a sample rather than a census.

• Repair tools never sweep the site. They only look at pages you hand them.

#Related

Numbers, and the deliberate gaps.