FE-1489: Optimizations accept an ad-hoc scenario defined inline

[kube]

🌟 What is the purpose of this PR?

The third consumer of the ad-hoc scenario form (FE-778), and the one Optimize was built for: the create-optimization drawer offers "Ad-hoc (define inline)" in its scenario picker. Every Optimize selection in the form becomes a generated scenario parameter with a deterministic adhoc.* name, and the optimization manifest binds those parameters to their optimize domains — submitted exactly like a named scenario's manifest. The generated scenario is never persisted into the net file. Top of stack #9286, above FE-1488 (#9288).

Hold merging until the experiment-backend PRs #9178 and #9179 land (same hold as FE-1488).

🔗 Related links

• FE-1489 (internal): this PR
• FE-778 (internal): the umbrella ticket

🔍 What does this change?

All in create-optimization-drawer.tsx:

• The scenario Select gains an "Ad-hoc (define inline)" entry. Selecting it renders AdHocScenarioForm with optimizable: true in place of the scenario-parameters section; the Optimization and Objective sections are unchanged. An optimization no longer requires a saved scenario.
• On submit, synthesizeAdHocOptimization produces the generated scenario plus one optimized field per selection (name, attribution label, target, domain); adHocOptimizationBindings transforms the fields into manifest parameterBindings, and a new buildAdHocPetrinautOptimizationInput parses the result through the same petrinautOptimizationInputSchema as the named path — the manifest schema itself is untouched. Generated parameter names (adhoc.<place>.r<row>.<field>, adhoc.count.<place>, adhoc.var.net.<name>, ...) are the wire contract for result attribution.
• Validation: getConfigurationError accepts the ad-hoc state and requires at least one Optimize selection ("Enable Optimize on at least one value"); bounds and domain rules are enforced by the FE-1485 synthesis and surface in the drawer footer.

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• modifies an npm-publishable library and I have added a changeset file(s) (patch).

📜 Does this require a change to the docs?

The changes in this PR:

• add a user-visible surface. The user-guide pages for the whole ad-hoc feature ship as the next stack layer, now that all three consumers exist.

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph.

🛡 What tests cover this?

Two new drawer tests: selecting the ad-hoc option renders the inline form and blocks Run with "Enable Optimize on at least one value"; a real synthesizeAdHocOptimization outcome round-trips through buildAdHocPetrinautOptimizationInput and the manifest schema, binding adhoc.count.Queue to its integer domain with the generated scenario embedded. The FE-1485 tests cover the synthesis and naming rules.

❓ How to test this?

1. turbo run test:unit --filter @hashintel/petrinaut
2. turbo run dev --filter @apps/petrinaut → Simulate → Optimizations → Create → pick "Ad-hoc (define inline)", enable Optimize on a value with a domain, choose an objective, Run.
3. The submitted manifest binds adhoc.* parameters; the net file gains no scenario.

🐾 Next steps

The user-guide pages for the ad-hoc feature (all three consumers) follow as the next stack layer.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hash	Ready	Preview	Aug 23, 2026 2:48pm
petrinaut	Ready	Preview	Aug 23, 2026 2:48pm
petrinaut-docs	Ready	Preview	Aug 23, 2026 2:48pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hashdotdesign-tokens	Ignored	Preview	Aug 23, 2026 2:48pm