Improve profile management

[AFKFelix]

Make the following improvements to profile management:

• Include profiles from OrcaSlicer
• Handle uploaded profiles more securely
• Add a check for profile types to ensure that only the correct profiles can be uploaded and shown

[AFKFelix]

In order to use the profiles from OrcaSlicer resources folder´, they need to be merged with the profile it inherits from. This needs to be investigated further.

[AFKFelix]

The inheritance should also be tried to resolve using the profiles bundled in the Orca Slicer AppImage.

See #54

[maziggy]

Hi — context first: I'm working with @maziggy on the Bambuddy side and we've been corresponding on #54 about the slicer integration. We already have a working profile resolver on a bambuddy/profile-resolver branch on our fork (maziggy/orca-slicer-api), and I want to align here before opening a PR so we don't double-build with what you mentioned having drafted.

Shape of our approach, briefly:

• Resolver lives in the sidecar (TS), not in the client. Client sends a minimal stub: {name, inherits: <system_preset_name>, from: "system", type: <machine|process|filament>} per slot.
• Resolver walks inherits against BUNDLED_PROFILES_PATH/<category>/<name>.json, recurses on chained inheritance, merges parent-then-child.
• from: "system" flag short-circuits the User/system compatibility check that otherwise rejects bundled presets when they're injected via --load-settings.
• type is required by the CLI's --load-settings parser; without it the CLI logs unknown config type to result.json with return_code
  -5 and exits 0, which Node's child_process treats as silent success with no output (that one cost us a session of debugging silently- embedded fallbacks before we tracked it down).
• Multi-filament: client sends one stub per slot; resolver materializes each independently; CLI receives them as the semicolon-separated '--load-filaments` list.

Tested matrix on our side: X1C / P1S / H2D / X1E / A1 single-color and multi-color (up to 13 slots on H2D), with both Cloud-fetched and locally-imported user presets that reference the bundled system parents. All resolve.

Two questions before I prep the PR:

1. Does this shape conflict with what you drafted at the weekend? If you went a different route I'd rather rebase onto your shape than send a competing PR.
2. Resolver location — we put it in src/services/profile-resolver.ts alongside the existing slicing service. Happy to move it if you'd prefer a different layout.

I can have the PR up within a session once you confirm direction.

Thanks for being open to this.

[AFKFelix]

Hey, thanks for taking a look at it!

My approach was slightly different. Since I need it for all printers, my workflow was like this:
At the start, I load all the vendor files from the profiles directory e.g. /resources/profiles/BBL.json or /resources/profiles/BIQU.json. There I checked the process_list, filament_list and machine_list values. This is where I can find all the profiles and the paths for that vendor. From there I would load all the profiles from the category list, resolve the inheritance and save it as a new JSON file inside a new system profiles folder if the profile was an instantiation ("instantiation": "true"). This is because, as far as I can tell, user profiles only inherit from instantiation profiles. I also cache the profile name and path for faster access and resolving later. When a user submits a profile for slicing, I go to the cache and retrieve the required profile by name. Since this has already been resolved, I only need to merge the user profile with this profile.

From what I have seen in your branch, the resolution matches my idea, but the process and when to trigger it are slightly different. If you are fine with that, I will use your resolving as a base and just adapt it to fir more what I had in mind.

[maziggy]

Thanks @AFKFelix — happy to align on this and glad the resolver shape works as a base.

Quick note on your pre-compute-and-cache approach: that makes sense, especially for repeated slice calls against the same system presets. The cache lifecycle (when to invalidate on bundled-profile changes — slicer upgrade, vendor JSON edit) is the only piece worth thinking through; the on-demand version sidesteps that by re-resolving every request, which is cheap enough at typical slice cadence. Either shape is fine on our side — we're consuming the resolver, not maintaining its cache strategy.

Two updates from the Bambuddy side since the Apr 29 thread:

1. Resolver is production-ready. Tested matrix as before (X1C / P1S / H2D / X1E / A1, single + multi-color up to 13 slots on H2D), plus four resolver fixes you'll find on the bambuddy/profile-resolver branch: full inherits: chain walking, from: "User" → from: "system" rewrite, # -clone-prefix strip, and sentinel-value strip ("-1" and "" that the GUI treats as auto but the CLI's range check rejects). Happy to send as a PR now and let you adapt the trigger/caching layer on top.
2. Bundle import landed downstream. We added a .bbscfg (Bambu Studio Printer Preset Bundle) import endpoint on top of the resolver — a single zip containing one printer + N processes + M filaments that materializes the JSON triplet on dispatch. New routes: POST /profiles/bundle, GET /bundles, GET/DELETE /bundles/:id, and slice dispatch via bundle_id + printerName + processName + filamentNames. This is a bigger surface than what we discussed in April and I don't want to surprise you with it, so flagging it separately — happy to send as PR Add multi-plate slicing support #2 if you're interested, or keep it downstream-only if it's outside your scope here.

Let me know:

• Want the resolver PR now, or would you prefer a different shape (e.g. patches for you to apply, or wait until your cache layer is in)?
• Bundle import — interested, or out of scope for upstream?

No rush — we run our own image off the resolver branch in production already, so we're not blocked.

[AFKFelix]

@maziggy

The cache lifecycle is actually a good point, but I think it is fine to regenerate it with each Slicer update, since the profiles only change at this time anyway, as far as I know.

1. Thanks again. I have already done some work locally on the resolving. I think I will just pull your changes locally and see how they fit with my existing implementation.
2. It sounds interesting, but I am not 100% familiar with what the .bbscfg files are, when they are used or whether they are needed. Feel free to open a PR. If you do so, please include a description of what it is and why it is useful. But only do it if you have the time. If not, I will check it at some point and if I feel it's needed, I'll pull it back.