@hybridlabor-api/aos 4.2.0 → 4.4.0

package/mcps/RhinoMCP/docs/content/_index.md

@@ -1,88 +0,0 @@
----
-title: Rhino MCP Platform
-toc: false
-author: Callum
-editor: SteveF
-keywords:
-  - Rhino MCP
-  - AI assistant
-  - Grasshopper
-  - McNeel
----
-
-<p style="text-align: center; font-size: 1.25rem; margin: 0 0 2.5rem; opacity: 0.8; font-family: 'Lato', sans-serif; font-weight: 400; font-style: italic;">Talk to Rhino &amp; Grasshopper in plain language</p>
-
-<style>
-  .rh-logo-dark { display: none; } html.dark .rh-logo-light { display: none; } html.dark .rh-logo-dark { display: inline; }
-</style>
-
-<h1 style="display: flex; align-items: center; justify-content: center; gap: 0.75rem; margin: 2.5rem 0 0.5rem;">
-  <img class="rh-logo-light" src="images/landing.png" alt="" width="600" />
-  <img class="rh-logo-dark" src="images/landing-dark.png" alt="" width="600" />
-</h1>
-
-<section class="page-story-scene">
-<p class="scene-line scene-line-1">For most of <strong>Rhino & Grasshopper</strong>'s history, modeling meant <em><strong>a lot</strong> of typing &amp; clicking.</em></p>
-<p class="scene-line scene-line-2">Every command, layer, selection... with <em>your fingers</em> driving the geometry. <em>Now, <span class="rhino-mcp">Rhino MCP</span> can also listen.</em></p>
-<p class="scene-line scene-line-3">Describe what you want in <em>plain language,</em> and an AI assistant translates your intent into <strong>Rhino &amp; Grasshopper</strong> <em>actions.</em></p>
-<p class="scene-line scene-line-4">What's the significance? <em>Creativity is becoming <strong>a partnership.</strong></em></p>
-<p class="scene-line scene-line-5">The tedious parts of modeling &amp; drafting <em>are now <strong>assisted</strong>:</em> cleanup, layer-renaming, twenty variations.</p>
-<p class="scene-line scene-line-6">The other parts <em>stays yours:</em> the choices, the taste, the judgment behind what <strong>you're making.</strong></p>
-<p class="scene-line scene-line-7">Once the friction drops, <em>new work becomes <strong>possible.</strong></em></p>
-<p class="scene-line scene-line-8">Studies you've never attempted become <em>quick projects or <strong>deeper explorations.</strong></em></p>
-<p class="scene-line scene-line-9">Thirty columns of options, a folder of .3dm files <em>processed <strong>overnight...</strong></em></p>
-<p class="scene-line scene-line-10">A hand sketch turned into <em>a first-pass <strong>parametric build.</strong></em></p>
-<p class="scene-line scene-line-11 scene-finale"><em>With <span class="rhino-mcp">Rhino MCP</span>, digital design culture has shifted... <strong>again.</strong></em></p>
-</section>
-
-## ✨ What is the **Rhino MCP** Platform?
-
-<div class="lead">
-
-The **Rhino MCP Platform** is a free MCP from McNeel, the makers of Rhino & Grasshopper, that connects our software to AI assistants like {{< icon "claude" >}} **Claude**, {{< icon "github" >}} **GitHub Copilot**, {{< icon "chatgpt" >}} **Codex**, {{< icon "gemini" >}} **Gemini**, and {{< icon "lmstudio" >}} **Local LLMs**. Once **Rhino MCP** is installed, your assistant can see what's in your Rhino & Grasshopper files, create geometry, run commands, write & edit scripts, and build Grasshopper definitions.
-
-</div>
-
-<div class="hero-button-wrap" style="display: flex; justify-content: center; margin: 2rem 0 3rem;">
-{{< hextra/hero-button text="Get Started!" link="docs/getting-started" >}}
-</div>
-
-## 🙋 What kind of designer are you?
-
-{{< cards >}}
-
-  {{< card link="docs/getting-started" title="I'm new. Show me how :)" subtitle="GETTING STARTED: Install the plugin, pick an AI assistant, and try your first prompt" >}}
-
-  {{< card link="docs/try-it-out/examples" title="Just give me prompts to try..." subtitle="EXAMPLES: A growing library of prompts you can use, grouped by what you want to do" >}}
-
-  {{< card link="docs/advanced" title="I know what I'm doing!" subtitle="ADVANCED: I know Rhino & Grasshopper. Show me how to supercharge them!" >}}
-
-  {{< card link="docs/developers" title="I'm a Rhino developer." subtitle="DEVELOPER: How the Rhino MCP can assist you in plugin development" >}}
-
-{{< /cards >}}
-
-## 💡 What can I do with **Rhino MCP**?
-
-{{< cards >}}
-
-  {{< card link="docs/try-it-out/examples/model-from-image" title="Model from an image" subtitle="\"Create a 3d model from an image\"" >}}
-
-<!-- draft
-  {{< card link="docs/try-it-out/examples/generate-variations" title="Generate variations" subtitle="\"Create 30 columns in a grid, randomize their heights, and color them by height.\"" >}}
-
-  {{< card link="docs/try-it-out/examples/inspect-and-report" title="Inspect and report" subtitle="\"What's in this document? Group it by layer and tell me which objects are off-layer.\"" >}}
--->
-
-  {{< card link="docs/try-it-out/examples/build-grasshopper" title="Build Grasshopper definitions" subtitle="\"Make a Grasshopper definition that lofts a curve through these points.\"" >}}
-
-  {{< card link="docs/try-it-out/examples/layers" title="Automate layering" subtitle="\"Take a model and place all of its parts on layers.\"" >}}
-
-{{< /cards >}}
-
-<!-- TODO
-
-<blockquote class="page-note">
-See the <a href="docs/try-it-out/recipes">Recipes</a> for more ready-to-paste prompts.
-</blockquote>
-
--->

package/mcps/RhinoMCP/docs/content/docs/_index.md

@@ -1,35 +0,0 @@
----
-title: Documentation
-linkTitle: Docs
-next: docs/getting-started
-weight: 1
-author: Callum
-editor: SteveF
-keywords:
-  - Rhino MCP
-  - documentation
-  - getting started
-  - AI assistant
----
-
-Welcome! These docs walk you from your first prompt to power-user workflows in no time. Pick a starting point below, or jump straight into the sidebar menu.
-
-## Start here
-
-{{< cards >}}
-  {{< card link="getting-started" title="Getting Started" subtitle="Install the plugin and wire up an AI assistant: Claude Desktop, Claude Code, GitHub Copilot, OpenAI Codex, Gemini CLI, or a local model." >}}
-  {{< card link="try-it-out" title="Try It Out" subtitle="Confirm everything works with a first prompt, then browse the recipes and examples." >}}
-{{< /cards >}}
-
-## Go further
-
-{{< cards >}}
-  {{< card link="advanced" title="Advanced" subtitle="Power-user workflows: GH1 to GH2 upgrades, headless render farms, parametric rebuilds, sketch-to-model, and bulk .3dm processing." >}}
-  {{< card link="developers" title="Developers" subtitle="Using the Rhino MCP for plugin development: .NET Core upgrades, Rhino version upgrades, cross-platform ports, and Grasshopper component conversions." >}}
-{{< /cards >}}
-
-## When things go wrong
-
-{{< cards >}}
-  {{< card link="troubleshooting" title="Troubleshooting" subtitle="Plain-language answers to common gotchas." >}}
-{{< /cards >}}

package/mcps/RhinoMCP/docs/content/docs/advanced/_index.md

@@ -1,37 +0,0 @@
----
-title: Advanced
-linkTitle: Advanced
-icon: sparkles
-weight: 20
-prev: docs
-next: docs/advanced/upgrade-gh1-to-gh2
-author: Callum
-editor: SteveF
-keywords:
-  - Rhino MCP
-  - advanced
-  - power user
-  - workflows
----
-
-For users who already know Rhino and Grasshopper and want to get more out of the MCP. These pages cover power-user workflows where the assistant does the heavy lifting and you stay in review.
-
-{{< cards >}}
-  
-  {{< card link="upgrade-gh1-to-gh2" title="Upgrade a GH1 script to GH2" subtitle="Port a `.gh` definition onto a GH2 canvas and verify the two solve to the same result." >}}
-  
-  <!-- draft
-  {{< card link="headless-render-farm" title="Headless render farm" subtitle="Spawn slots, point cameras, dump images, tear them down, without losing your active document." >}}
-  -->
-  
-  <!-- draft
-  {{< card link="make-this-parametric" title="Make this parametric" subtitle="Hand-modeled something? Have the assistant infer the recipe and rebuild it as a GH2 graph." >}}
-  -->
-  
-  {{< card link="sketch-to-model" title="Sketch to model" subtitle="Drop in a napkin sketch, agree an interpretation, get a first-pass parametric build." >}}
-
-  <!-- draft
-  {{< card link="bulk-file-processing" title="Bulk file processing" subtitle="Open, modify, and save a whole folder of `.3dm` files in slots, without the `RunScript` fragility." >}}
-  -->
-
-{{< /cards >}}

package/mcps/RhinoMCP/docs/content/docs/advanced/bulk-file-processing.md

@@ -1,70 +0,0 @@
----
-title: Bulk file processing
-linkTitle: Bulk file processing
-weight: 5
-next: docs/developers
-author: Callum
-editor: SteveF
-draft: true
-keywords:
-  - bulk processing
-  - batch 3dm
-  - headless
-  - slots
----
-
-You've got a folder of `.3dm` files and a job to do on each of them: purge unused layers, re-export every file as STEP, replace a block definition across the set, fix unit settings, strip annotations, add a title block, re-save under a new naming scheme. The hand version is a click-fest. The traditional scripted version is a fragile pile of `RunScript` hacks that breaks the moment one file has a dialog you didn't expect.
-
-The MCP gives you a cleaner path: each file opens in its own **slot**, the assistant drives it through whatever sequence you describe, and the slot closes when it's done. Your main Rhino window keeps whatever you were actually working on.
-
-## What you need
-
-- An MCP-connected assistant ([Claude Code](../getting-started/cc-plugin), Claude Desktop, or similar).
-- **Rhino** running with Rhino MCP.
-- A folder of `.3dm` files you want to process, and write-access to wherever the output should land.
-- A clear description of the per-file operation. "Make it tidy" is not enough; "purge unused block definitions, set tolerance to 0.001, save as `<name>-clean.3dm`" is.
-
-## A prompt to start with
-
-{{< prompt >}}
-For every `.3dm` in `incoming/`, open it in a slot, purge unused
-layers and block definitions, set the absolute tolerance to 0.001,
-export the contents of layer `Deliverable` as a STEP file into
-`out/<name>.step`, then close the slot. Don't touch my current
-document. Do it four files at a time and stop on the first error so
-I can look at it.
-{{< /prompt >}}
-
-Variations worth trying:
-
-- **Format conversion**: "re-save every file as Rhino 7 format into `legacy/`, preserving the folder structure."
-- **Mass edit**: "in every file, find the block named `TitleBlock` and replace its definition with the one from `template.3dm`."
-- **Audit and report**: "open each file, collect layer counts, object counts, units, and tolerance, write the results to `audit.csv`. Don't modify anything."
-- **Rename and reorganize**: "for each file, read the project code from layer `Meta`, and re-save it as `<code>/<original-name>.3dm`."
-
-## What you should see
-
-The assistant calls `spawn_slot` per file (or per worker, if it's batching), `open_doc` into that slot, then a sequence of `run_command` / `run_python` / `run_csharp` calls to do the actual work, then `save_doc` (or an export command) and `close_slot`. Your main Rhino window doesn't flicker; the slot documents are headless siblings.
-
-For anything non-trivial, expect the assistant to run the first file end-to-end and show you the result before fanning out. If it doesn't offer, ask for it. Verifying one good output is much cheaper than auditing fifty bad ones.
-
-## What to review
-
-- **The first output.** Before the batch runs, demand one completed file you can open and inspect. Layer names, unit settings, and tolerances are easy to get subtly wrong in a way that only shows up downstream.
-- **Skipped files.** If a file errors, did the assistant skip it and carry on, or stop? Be explicit about which behavior you want. For destructive batches, "stop on first error" is usually safer.
-- **The save path.** Make the assistant echo the full output folder and a couple of example output filenames before it starts. Files landing in the wrong place is the most common way a batch wastes an afternoon.
-- **Originals.** If the operation overwrites in place, confirm there's a backup. The assistant won't make one unless you ask.
-
-## When the assistant gets stuck
-
-Common failure modes:
-
-- **`ActiveDoc` confusion.** Scripts that use `sc.doc` or `Rhino.RhinoDoc.ActiveDoc` inside a slot may not be talking to the slot you think. Tell the assistant to use the injected `__rhino_doc__` handle inside `run_python` / `run_csharp` calls. See the [doc-handle note](../try-it-out/recipes).
-- **Modal dialogs.** Some commands pop UI on certain files (missing fonts, missing linked blocks, unit mismatch on import). In a slot, these can hang the run. If it's stalling on one file, ask for the command to be replaced with a script-call equivalent that doesn't prompt, or for the file to be skipped with a logged reason.
-- **Slot leak.** If the batch errors halfway through, slots can stay open. Ask for a `list_slots` and have the assistant close anything stray before you start the next run.
-- **Memory pressure.** Big files plus many parallel slots will exhaust RAM faster than you expect. Cap the parallelism explicitly ("at most four slots at a time") rather than letting it fan out across the whole folder.
-- **`RunScript` reflex.** If the assistant reaches for `RunScript` with a long dash-prefixed command string, push back: it's the fragile path. The Rhino API has direct equivalents for most things, so ask for those instead. On Mac in particular, `_-Close` and `_-New` have quirks worth avoiding.
-
-## Related
-
-- [Headless render farm](../headless-render-farm): same slot-per-file shape, but the per-file job is "render", not "modify and save".

package/mcps/RhinoMCP/docs/content/docs/advanced/headless-render-farm.md

@@ -1,60 +0,0 @@
----
-title: Headless render farm
-linkTitle: Headless render farm
-weight: 2
-author: Callum
-editor: SteveF
-draft: true
-keywords:
-  - headless
-  - render farm
-  - slots
-  - viewport capture
----
-
-If you have a model you need to capture from many angles (a study model with twenty options, a presentation board, a turntable, a daylight sweep), the MCP can spin up headless Rhino documents in parallel, point cameras at them, dump viewport images, and tear them down again without you ever clicking "New Document".
-
-This is what the **slot** tools are for. Each slot is its own Rhino document; the assistant can open, drive, and close them programmatically while your main session keeps its window focused on whatever you were actually doing.
-
-## What you need
-
-- An MCP-connected assistant ([Claude Code](../getting-started/cc-plugin), Claude Desktop, or similar).
-- **Rhino** running with Rhino MCP.
-- A `.3dm` (or several) you want to capture, or a recipe the assistant can build from scratch.
-- A folder you're happy for the assistant to write images into.
-
-## A prompt to start with
-
-{{< prompt >}}
-Open `studies/option-*.3dm`, each in its own slot. For every file,
-set the camera to an isometric view framed on layer `Massing`, render
-the active viewport at 1920&times;1080, save it as
-`renders/<filename>.png`, and close the slot. Don't touch my current
-document.
-{{< /prompt >}}
-
-Variations worth trying:
-
-- **Turntable**: "spin the camera around the model in 15&deg; steps, save each frame numbered."
-- **Sun study**: "step the sun from 08:00 to 18:00 in 30-minute intervals, capture from the same camera each time."
-- **Option matrix**: "for every combination of these three GH sliders, solve, capture, label the filename with the slider values."
-
-## What you should see
-
-The assistant calls `spawn_slot` for each file or variation, `open_doc` into that slot, `set_camera` (or `run_command` for named views), `get_viewport_image` to capture, then `close_slot` when it's done. Your main Rhino window stays on whatever you had open; the slot documents are headless siblings, not takeovers.
-
-If it's working from a Grasshopper definition, expect to see `g2_*` solve calls between the camera move and the capture so the geometry updates before the shutter clicks.
-
-## What to review
-
-- **Camera framing.** Headless slots don't have a viewport you can eyeball, so the assistant is guessing at zoom and target. Ask it to do one capture first and show you the image before it loops over fifty.
-- **Render settings.** `get_viewport_image` captures the display mode, not a Rendered/Raytraced pass by default. If you need ray-traced output, say so explicitly and check the first frame matches what you expected.
-- **Output paths.** Make the assistant echo the full output folder before it starts. Cheaper than discovering forty PNGs landed in the wrong place.
-
-## When the assistant gets stuck
-
-Common failure modes:
-
-- **Slot leak.** If a run errors halfway through, slots may stay open. Ask for a `list_slots` and have it close anything stray.
-- **ActiveDoc confusion.** Remind it that each slot has its own document handle; `sc.doc` inside a `run_python` call may not be the slot you think. The [doc-handle note](../try-it-out/recipes) covers this.
-- **Memory pressure.** Spinning up many slots at once can chew RAM. Cap the parallelism ("do at most four at a time") rather than letting it fan out.

package/mcps/RhinoMCP/docs/content/docs/advanced/make-this-parametric.md

@@ -1,56 +0,0 @@
----
-title: Make this parametric
-linkTitle: Make this parametric
-weight: 3
-author: Callum
-editor: SteveF
-draft: true
-keywords:
-  - parametric
-  - Grasshopper
-  - reverse engineer
-  - GH2
----
-
-You've modeled something by hand (a stair, a panelized facade, a piece of furniture) and now you wish you'd built it in Grasshopper from the start, because the client just asked for "the same thing but 200mm taller and with seven of them instead of five."
-
-This workflow puts the assistant in the role of a Grasshopper author: it reads the geometry you already made, infers the recipe, and rebuilds it as a GH2 graph that drives the same result from sliders.
-
-## What you need
-
-- An MCP-connected assistant ([Claude Code](../getting-started/cc-plugin), Claude Desktop, or similar).
-- **Rhino 9** with Rhino MCP running, your hand-built model open, and a GH2 canvas available.
-- A rough mental model of what the parameters should be. The assistant can guess, but you'll get a better graph if you say so.
-
-## A prompt to start with
-
-{{< prompt >}}
-I've modeled this stair by hand. Look at the geometry on layer
-`Stair`, work out the construction recipe, and rebuild it as a GH2
-definition driven by sliders for tread depth, riser height, total
-rise, and number of treads. Reference my existing geometry in the
-Rhino doc only as a target to match; the GH definition should
-generate it from scratch. Solve and compare.
-{{< /prompt >}}
-
-## What you should see
-
-The assistant calls `list_objects` and reads attributes off your geometry (layer, dimensions, counts, bounding boxes) to reverse-engineer the rules. Then it builds the GH2 graph with `g2_place_component`, `g2_connect`, and `g2_place_slider`, solves it, and compares the output to your reference geometry, usually by checking key dimensions and counts rather than a literal Brep diff.
-
-Expect a back-and-forth: the assistant will often ask "is the spacing uniform, or does it follow a curve?" before committing to a topology.
-
-## What to review
-
-- **The parameter set.** You wanted four sliders: did you get four? The assistant sometimes adds extras for things you'd rather hard-code, or hard-codes something you wanted to expose. A quick prompt fixes it.
-- **Did it match, or did it cheat?** The cheapest way to "match" your geometry is to bake your existing Rhino objects into the GH output. That's not parametric. Have the assistant show you the graph and confirm it generates from primitives, not from referenced objects.
-- **Edge cases.** Push the sliders to extremes (1 tread, 100 treads, zero rise) and see whether the graph degrades gracefully or explodes. Real-world stairs don't have 100 treads, but the failure mode tells you whether the topology is right.
-
-## When the assistant gets stuck
-
-- **Ambiguous intent.** If your hand model has irregular spacing or one-off tweaks, the assistant can't tell whether those are intentional features or sloppy modeling. Tell it explicitly which variations are parametric and which were drift.
-- **Missing GH2 components.** If the recipe needs something GH2 doesn't have yet, ask for the gap to be called out rather than papered over with a `run_python` node that hides the logic.
-- **Over-fitting to one example.** A graph that exactly reproduces your reference but breaks for any other input isn't useful. If you only see it solve once, push it.
-
-## Related
-
-- [Upgrade a GH1 script to GH2](../upgrade-gh1-to-gh2): for when you already have a parametric definition, just in the old canvas.

package/mcps/RhinoMCP/docs/content/docs/advanced/sketch-to-model.md

@@ -1,58 +0,0 @@
----
-title: Sketch to model
-linkTitle: Sketch to model
-weight: 4
-author: Callum
-editor: SteveF
-draft: true
-keywords:
-  - sketch to model
-  - image to geometry
-  - parametric
-  - Grasshopper
----
-
-If you've got a hand sketch (a napkin drawing, a whiteboard photo, a marked-up plan) you can drop the image into the chat and ask the assistant to propose a parametric build. It reads the sketch, suggests an interpretation, and constructs a first-pass model or Grasshopper definition you can iterate on.
-
-This is a conversation, not a one-shot. The first model will be wrong in interesting ways; the value is in how quickly you can correct it.
-
-## What you need
-
-- An MCP-connected assistant that can accept images ([Claude Code](../getting-started/cc-plugin), Claude Desktop, or similar).
-- **Rhino** running with Rhino MCP, ideally on Rhino 9 if you want the result as GH2.
-- A reasonably legible image of the sketch. Phone photo is fine; shadows and skew are tolerable, illegible handwriting is not.
-
-## A prompt to start with
-
-{{< prompt >}}
-Here's a sketch of a shelving unit I want to build. Read the
-proportions and structure off the drawing, tell me what you think the
-key parameters are, and propose a parametric model. Don't build
-anything yet. Show me your interpretation first so I can
-correct it.
-{{< /prompt >}}
-
-That second sentence matters. Without it the assistant will dive straight to geometry and you'll spend longer correcting the result than you would have spent on a slower start.
-
-## What you should see
-
-1. **An interpretation.** The assistant lists what it thinks the sketch shows: overall dimensions, the parts, which proportions are load-bearing, which annotations are dimensions vs. labels.
-2. **A parameter proposal.** A short list of sliders it thinks you'll want.
-3. **Once you confirm:** a first build, either as Rhino geometry or a GH2 graph, depending on what you asked for.
-4. **A comparison.** Often a screenshot via `get_viewport_image` framed to roughly match the sketch's angle, so you can eyeball whether the massing matches.
-
-## What to review
-
-- **Dimensions.** Sketches rarely have every measurement. The assistant will infer the missing ones from proportion, which is almost always *almost right*. Spot-check by asking for a few overall dims and comparing to what you meant.
-- **Topology vs. style.** A sketch of "a chair" might be interpreted as *that specific chair* or as *a chair-shaped recipe*. Be explicit about which one you want.
-- **Hidden assumptions.** Material thicknesses, joinery, tolerances, fixings: none of these are in the sketch. The assistant will invent reasonable defaults; check them before you cut anything.
-
-## When the assistant gets stuck
-
-- **Illegible sketch.** If the response is vague ("a shelf-like object with some compartments"), the image isn't carrying enough information. Annotate the sketch with dimensions and labels, or describe the bits the drawing doesn't show.
-- **Wrong axis.** Plan vs. elevation vs. perspective confusion is common. State it: "this is the front elevation."
-- **Too literal.** If the model copies sketch artefacts (a wobbly line becomes a wobbly edge), tell the assistant to treat the sketch as intent, not as a digitised input.
-
-## Related
-
-- [Make this parametric](../make-this-parametric): once the first-pass model exists, this workflow takes it the rest of the way.

package/mcps/RhinoMCP/docs/content/docs/advanced/upgrade-gh1-to-gh2.md

@@ -1,51 +0,0 @@
----
-title: Upgrade a GH1 script to GH2
-linkTitle: Upgrade GH1 to GH2
-weight: 1
-prev: docs/advanced
-author: Callum
-editor: SteveF
-keywords:
-  - Grasshopper
-  - GH1 to GH2
-  - .gh definition
-  - upgrade
----
-
-> GH2 is very new and AI agents are not as familiar with it as GH1
-
-Rhino 9 ships Grasshopper 2 alongside Grasshopper 1. If you have a GH1 definition you'd like to upgrade, your AI Agent and the MCP can read your GH1 graph and rebuild it on a GH2 canvas, solving both side-by-side to confirm they match.
-
-This is different from [upgrading a plugin's compiled components](../developers/upgrade-gh1-to-gh2); here you're porting a `.gh` definition, not source code.
-
-## A prompt to start with
-
-{{< prompt >}}
-Using Rhino 9 WIP/BETA, open this GH1 script \<path> and rebuild the same definition on a GH2 canvas.
-{{< /prompt >}}
-
-## What you should see
-
-The assistant opens Rhino 9 WIP/BETA, Grasshopper 1 and 2. It will then remake your GH1 script in GH2. It should solve both canvases and compare the outputs. You can swap slider values on either side and check that they still agree.
-
-## What to review
-
-- **Component substitutions.** GH2 component names and parameter types don't always line up one-to-one. Have the assistant flag any case where it picked the closest match rather than an exact equivalent.
-- **Third-party components.** If your GH1 definition relies on a plugin that doesn't have a GH2 build yet, the assistant should surface that and skip those nodes rather than fake them.
-- **Parity vs Intent** some components work differently in GH1 and GH2, so the script may be technically identical, but output slightly differently.
-
-## When the assistant gets stuck
-
-If part of the definition can't be cleanly ported, ask for a short "these need human eyes" list at the end instead of stubbed nodes that silently solve to nothing. A flagged gap is more useful than a quiet mismatch.
-
-## A more advanced and accurate prompt
-
-Note : This is _much_ more thorough and will use more tokens.
-
-{{< prompt >}}
-Rebuild this GH1 script \<path> as a working GH2 definition
-
-1. Dump GH1's ground truth — every node's outputs and internal state (incl. Graph Mapper output domains). That's the answer key.
-2. Rebuild with closest-equivalent components; keep a deviation list for anything GH2 does differently. No clean equivalent → ask first.
-3. Validate each node against GH1's recorded values (not your own work). Don't say "matches" until the final output matches end-to-end, to 1e-4, confirmed by a side-by-side render.
-{{< /prompt >}}

package/mcps/RhinoMCP/docs/content/docs/developers/_index.md

@@ -1,39 +0,0 @@
----
-title: Developers
-linkTitle: Developers
-icon: code
-weight: 30
-prev: docs
-next: docs/developers/upgrade-to-netcore
-author: Callum
-editor: SteveF
-keywords:
-  - developers
-  - plugin development
-  - Claude Code
-  - AI assistant
----
-
-These pages are about incorporating the Rhino MCP and an AI assistant like Claude Code into your development cycle for rapid development.
-
-These pages are **not** tutorials on how to do the conversion by hand. The goal is to put an assistant in the driver's seat and review what it does.
-
-{{< cards >}}
-  
-  {{< card link="upgrade-to-netcore" title="Upgrade a plugin to .NET Core" subtitle="Move a `net48` plugin onto `net7.0` / `net8.0` using Claude Code + Rhino MCP." >}}
-  
-  {{< card link="upgrade-gh1-to-gh2" title="Upgrade GH1 components to GH2" subtitle="Scaffold GH2 equivalents and verify them side-by-side on a GH1 + GH2 canvas." >}}
-  
-  <!-- draft
-  {{< card link="plugin-prototyping" title="Prototype a plugin" subtitle="\"Make me a plugin that does X.\" Scaffold, build, load, exercise, all through the MCP loop." >}}
-  
-  {{< card link="windows-to-cross-platform" title="Make a Windows plugin cross-platform" subtitle="Replace P/Invokes, registry calls, and other Windows-isms so the plugin runs on Mac." >}}
-  
-  {{< card link="wpf-to-eto" title="Convert a WPF UI to Eto" subtitle="Port a Windows-only WPF UI to Eto.Forms so the plugin runs on Mac too." >}}
-  -->
-
-{{< /cards >}}
-
-<blockquote class="page-note">
-If you're here to hack on <strong>Rhino MCP itself</strong>, see the <a href="https://github.com/mcneel/RhinoMCP#building--debugging">contributing notes on GitHub</a>.
-</blockquote>

package/mcps/RhinoMCP/docs/content/docs/developers/dev-troubleshooting.md

@@ -1,15 +0,0 @@
----
-title: Developer Troubleshooting
-linkTitle: Dev Troubleshooting
-icon: question-mark-circle
-weight: 100
-author: Callum
-keywords:
-  - develop
-  - troubleshooting
-  - faq
----
-
-## AI Agent is stuck, looping for a long time.
-
-If your AI Agent is stuck, interrupt it and ask it why it is stuck. You can always instruct it to continue.

package/mcps/RhinoMCP/docs/content/docs/developers/plugin-prototyping.md

@@ -1,56 +0,0 @@
----
-title: Plugin prototyping
-linkTitle: Plugin prototyping
-weight: 4
-author: Callum
-editor: SteveF
-draft: true
-keywords:
-  - plugin prototyping
-  - scaffolding
-  - Claude Code
-  - rapid prototyping
----
-
-If you've ever wanted to try a plugin idea but didn't have the time to scaffold the project, write the manifest, wire up a command, build, load, debug, repeat: this is something that the Rhino MCP and an AI assistant can do. Describe what you want the plugin to do, and the assistant can scaffold it, build it, load it into a running Rhino, exercise commands, figure out crashes, and iterate until complete.
-
-This is closer to "rapid prototyping a plugin idea" than "ship a production plugin." The output is a starting point you can keep developing, or throw away once you've decided whether the idea was worth pursuing.
-
-## A prompt to start with
-
-{{< prompt >}}
-Scaffold a Rhino 8 plugin in this folder called `EdgeAudit`. It
-should add one command, `EdgeAuditReport`, that scans the active doc
-for Breps with naked edges, prints a per-object count to the command
-line, and selects the worst offender. Use the standard plugin
-template, target `net7.0`, and once it builds load it into Rhino and
-run the command on whatever's open so I can see it work.
-{{< /prompt >}}
-
-Adjust scope to taste: one command, three commands, a Grasshopper component, a display conduit. The pattern is the same.
-
-## What you should see
-
-The assistant runs `dotnet new rhinoplugin` (or equivalent), edits the generated command file to match your spec, builds the `.rhp`, loads it into the running Rhino via `run_command` (`_PluginManager` / `_-LoadPlugIn`), and then invokes the new command. It reads the command line output back through the MCP, so it can tell whether the command actually did what you asked, not just whether it compiled.
-
-If the first build fails or the command misbehaves, expect an iterate loop: edit, build, reload, re-run, observe. The whole point of doing this through Rhino MCP is that the assistant closes that loop itself.
-
-## What to review
-
-Even for a throwaway prototype, glance at:
-
-- **The plugin GUID and manifest.** If you might keep the plugin, make sure the GUID is the assistant's, not a placeholder from the template, and that the plugin name / version are what you want.
-- **Where it loads from.** The assistant will usually load the built `.rhp` from `bin/Debug/...`. That's fine for prototyping; for anything you want to keep, decide whether to ship via Yak or copy to the plugins folder.
-- **API choices.** Brand-new RhinoCommon code from an assistant is often *almost right*: the right namespace, a plausible method name, slightly wrong arguments. Read the diff with the [RhinoCommon docs](https://developer.rhino3d.com/api/rhinocommon/) open in the other window.
-- **Cleanup.** Prototyping leaves loaded plugins in your Rhino session. If you abandon the experiment, unload it before forgetting.
-
-## When the assistant gets stuck
-
-- **Template missing.** If `dotnet new rhinoplugin` isn't available, the assistant should install `Rhino.Templates` rather than hand-rolling a `.csproj`. The templates set up a lot of boring things correctly.
-- **Plugin won't load.** Usually a target-framework mismatch (plugin built for `net8.0`, Rhino running `net7.0`) or a missing reference. Ask the assistant to print the exact load error from Rhino's command line before guessing.
-- **"Works on the next reload."** Rhino caches loaded plugin assemblies; for tight iteration loops, use the plugin developer's reload flow (or just unload, rebuild, reload). The assistant should do this for you; if it skips the reload step, builds will land but behavior won't change.
-
-## Related
-
-- [Upgrade a plugin to .NET Core](../upgrade-to-netcore): once the prototype proves the idea, you'll want it on a modern target.
-- [Upgrade to a newer Rhino](../upgrade-rhino-version): same idea, different axis.