Skip to content

feat: Code execution waits for reload recovery by default#1142

Merged
hatayama merged 2 commits into
v3-betafrom
feature/hatayama/update-domain-reload-default
May 16, 2026
Merged

feat: Code execution waits for reload recovery by default#1142
hatayama merged 2 commits into
v3-betafrom
feature/hatayama/update-domain-reload-default

Conversation

@hatayama
Copy link
Copy Markdown
Owner

@hatayama hatayama commented May 16, 2026

Summary

  • Dynamic code execution now waits for Unity domain reload recovery before returning by default.
  • The public execute-dynamic-code option surface now stays focused on normal execution controls; the diagnostic compile-only path remains internal.

User Impact

  • Follow-up CLI commands are less likely to race Unity while the Editor is still recovering after dynamic code triggers a reload.
  • Users and AI agents now see a simpler execute-dynamic-code surface: --no-wait-for-domain-reload is documented as the explicit fast path, while compile-only diagnostics are no longer advertised in help, skills, or examples.

Changes

  • Added default-on reload waiting for execute-dynamic-code, including a Unity-side reload signal and recovery wait after dispatched transport disconnects.
  • Bumped the native CLI contract and Unity package minimum required CLI version to 3.0.0-beta.9, with a separate cli-v release tag constant for installer flows.
  • Hid the internal compile-only option from CLI option listing and generated skill docs while preserving internal parser support.

Verification

  • scripts/check-go-cli.sh
  • go test ./...
  • Packages/src/Cli~/dist/darwin-arm64/uloop compile --project-path /Users/a12115/ghq/hatayama/unity-cli-loop
  • Focused EditMode tests for execute-dynamic-code reload signaling and CLI release tag behavior
  • Packages/src/Cli~/dist/darwin-arm64/uloop --list-options execute-dynamic-code
  • Packages/src/Cli~/dist/darwin-arm64/uloop execute-dynamic-code --compile-only --code 'return 1;' --project-path /Users/a12115/ghq/hatayama/unity-cli-loop

Overview

This PR makes the Unity CLI Loop's execute-dynamic-code command wait for Editor domain-reload recovery by default after executing dynamic code. This reduces race conditions where follow-up CLI commands run before the Editor is fully ready. Opting out is possible via a negated flag.

Key Changes

Version Bumping

  • CLI contract bumped to 3.0.0-beta.9 in Packages/src/Cli~/contract.json.
  • CliConstants.MINIMUM_REQUIRED_CLI_VERSION updated to 3.0.0-beta.9 and MINIMUM_REQUIRED_CLI_RELEASE_TAG updated to the GitHub-style tag (cli-v3.0.0-beta.9).

Schema & Tool Definition

  • ExecuteDynamicCodeSchema: added public bool WaitForDomainReload { get; set; } with default true.
  • default-tools.json: execute-dynamic-code inputSchema includes WaitForDomainReload (default: true).
  • Documentation and skill files updated to document the opt-out flag --no-wait-for-domain-reload and to remove/adjust the previously surfaced --compile-only usage where appropriate.

CLI Implementation (Go)

  • New dynamic_code_wait.go: encapsulates logic to decide when to wait, reads WaitForDomainReload (defaults to true), respects CompileOnly, interprets DomainReloadWaitRequired from the native response, handles disconnect-wait behavior, and strips control fields from the returned result.
  • run.go: when shouldWaitForExecuteDynamicCodeDomainReload(...) is true, execute-dynamic-code is handled by runExecuteDynamicCodeWithDomainReloadWait(...) which runs the request, updates spinner state, waits for domain-reload readiness on signal or dispatched disconnects, strips control signals from output, and returns appropriate exit codes.
  • compile_wait.go: uses domainReloadWaitParam and defers decision to domainReloadWaitEnabled.
  • tool_readiness.go: readiness probe params for execute-dynamic-code include domainReloadWaitParam: false for warmup.
  • completion.go: special-cases execute-dynamic-code to load default tools for option printing so completion exposes only the negated --no-wait-for-domain-reload flag and hides the positive flag.

CLI tooling & Types

  • Added ToolProperty.Hidden field to support hiding internal options.
  • Added visibleOptionNamesForTool helper to build sorted, visible option lists.

Editor (C#) Behavior

  • ExecuteDynamicCodeUseCase: creates and awaits a DynamicCodeDomainReloadWaitSignal to set response.DomainReloadWaitRequired; signal is disposed in finally to cover success and failure.
  • New DynamicCodeDomainReloadWaitSignal: subscribes to compilation and assembly reload hooks when WaitForDomainReload is true and CompileOnly is false; exposes ShouldWaitAsync that waits briefly for signals to settle.
  • ExecuteDynamicCodeResponse: added DomainReloadWaitRequired flag and ShouldSerializeDomainReloadWaitRequired() to only include it when relevant.
  • CliSetupApplicationService.GetMinimumRequiredCliReleaseTag() simplified to return the prefixed constant.

Tests & Verification

  • C# tests:

    • FirstPartyToolSchemaMetadataTests: verifies ExecuteDynamicCodeSchema defaults WaitForDomainReload == true.
    • CliSetupApplicationServiceTests: updated to expect MINIMUM_REQUIRED_CLI_RELEASE_TAG (cli-v3.0.0-beta.9) and renamed/added tests to reflect the dynamic-code domain-reload wait requirement.
    • ExecuteDynamicCodeUseCaseTests: added tests asserting serialization and DynamicCodeDomainReloadWaitSignal behavior for reload/no-wait cases.
  • Go tests:

    • compile_wait_test.go: new tests cover default-on behavior for execute-dynamic-code, explicit false disabling, compile-only skipping, response-driven DomainReloadWaitRequired signaling, disconnect behavior for dispatched transport loss, and stripping control results.
    • completion_test.go: tests that --list-options shows only --no-wait-for-domain-reload and that embedded default tool schema is used for completions.
    • tools_test.go: tests converting --no-wait-for-domain-reload to the internal param and accepts hidden --compile-only for internal callers.
    • launch_test.go: asserts readiness probe disables domainReloadWaitParam for foreground warmup.
  • CI / verification commands referenced: go test ./internal/cli and go test ./..., scripts/check-go-cli-source.sh and scripts/check-go-cli.sh, Build/CLI smoke runs (darwin-arm64), and focused EditMode tests.

User-Facing Changes

  • Default: execute-dynamic-code waits for Editor domain reload recovery by default.
  • Opt-out: --no-wait-for-domain-reload disables waiting.
  • Setup: installer/tooling now requires matching cli-v3.0.0-beta.9 release.

Architecture Diagram (class-style flow)

execute-dynamic-code (User Command)
        |
        v
shouldWaitForExecuteDynamicCodeDomainReload()
        |
    +---+---+
    |       |
   YES     NO
    |       |
    v       v
runExecuteDynamicCodeWithDomainReloadWait()    runTool() (default)
    |                                               |
    +-->sendExecuteDynamicCodeRequest               v
        (Unity IPC)                         [Execute Command]
        |                                       |
        v                                       v
    [Wait for Domain Reload]                [Return Result]
    waitForPossibleDynamicCodeDomainReload()
        |
    +---+---+
    |       |
  Success  Failure
    |       |
    v       v
[Return Result] [Return Error]

Review Change Stack

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 16, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c6728b0b-daa0-4da8-90bd-83a911d3623a

📥 Commits

Reviewing files that changed from the base of the PR and between fbed937 and 7365c7d.

⛔ Files ignored due to path filters (4)
  • Packages/src/Cli~/dist/darwin-amd64/uloop is excluded by !**/dist/** and included by none
  • Packages/src/Cli~/dist/darwin-arm64/uloop is excluded by !**/dist/** and included by none
  • Packages/src/Cli~/dist/windows-amd64/uloop.exe is excluded by !**/dist/**, !**/*.exe and included by none
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/DynamicCodeDomainReloadWaitSignal.cs.meta is excluded by none and included by none
📒 Files selected for processing (26)
  • .agents/skills/uloop-execute-dynamic-code/SKILL.md
  • .claude/skills/uloop-execute-dynamic-code/SKILL.md
  • Assets/Tests/Editor/CliSetupApplicationServiceTests.cs
  • Assets/Tests/Editor/DynamicCodeToolTests/ExecuteDynamicCodeUseCaseTests.cs
  • Assets/Tests/Editor/DynamicCodeToolTests/FirstPartyToolSchemaMetadataTests.cs
  • Packages/src/Cli~/contract.json
  • Packages/src/Cli~/internal/cli/compile_wait.go
  • Packages/src/Cli~/internal/cli/compile_wait_test.go
  • Packages/src/Cli~/internal/cli/completion.go
  • Packages/src/Cli~/internal/cli/completion_test.go
  • Packages/src/Cli~/internal/cli/dynamic_code_wait.go
  • Packages/src/Cli~/internal/cli/launch_test.go
  • Packages/src/Cli~/internal/cli/run.go
  • Packages/src/Cli~/internal/cli/tool_readiness.go
  • Packages/src/Cli~/internal/cli/tools.go
  • Packages/src/Cli~/internal/cli/tools_test.go
  • Packages/src/Cli~/internal/tools/default-tools.json
  • Packages/src/Cli~/internal/tools/types.go
  • Packages/src/Editor/Application/CliSetupApplicationService.cs
  • Packages/src/Editor/Domain/CliConstants.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/DynamicCodeDomainReloadWaitSignal.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeResponse.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeSchema.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeUseCase.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Skill/SKILL.md
  • docs/execute-dynamic-code-examples.md
💤 Files with no reviewable changes (1)
  • docs/execute-dynamic-code-examples.md
✅ Files skipped from review due to trivial changes (3)
  • Packages/src/Cli~/contract.json
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Skill/SKILL.md
  • Packages/src/Cli~/internal/cli/tool_readiness.go
🚧 Files skipped from review as they are similar to previous changes (10)
  • Packages/src/Editor/Domain/CliConstants.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeSchema.cs
  • Packages/src/Editor/Application/CliSetupApplicationService.cs
  • Packages/src/Cli~/internal/tools/default-tools.json
  • Packages/src/Cli~/internal/cli/run.go
  • Packages/src/Cli~/internal/cli/launch_test.go
  • Packages/src/Cli~/internal/cli/compile_wait.go
  • Assets/Tests/Editor/DynamicCodeToolTests/FirstPartyToolSchemaMetadataTests.cs
  • Packages/src/Cli~/internal/cli/completion.go
  • Assets/Tests/Editor/CliSetupApplicationServiceTests.cs

📝 Walkthrough

Walkthrough

Adds parameter-driven domain-reload wait behavior for the execute-dynamic-code CLI command, bumps minimum CLI release to v3.0.0-beta.9, introduces WaitForDomainReload (default true) across schema/docs, implements wait and disconnect handling, integrates into execution/readiness flows, and updates tests/completion.

Changes

Domain-Reload Wait Feature

Layer / File(s) Summary
CLI version requirement and service update
Packages/src/Editor/Domain/CliConstants.cs, Packages/src/Cli~/contract.json, Packages/src/Editor/Application/CliSetupApplicationService.cs, Assets/Tests/Editor/CliSetupApplicationServiceTests.cs
Minimum required CLI version bumped to 3.0.0-beta.9; contract JSON and CliSetup tests updated; service returns precomputed release-tag constant.
Tool schema, defaults, docs, and examples
Packages/src/Cli~/internal/tools/default-tools.json, Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeSchema.cs, Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Skill/SKILL.md, docs/execute-dynamic-code-examples.md, .agents/..., .claude/..., Assets/Tests/Editor/DynamicCodeToolTests/FirstPartyToolSchemaMetadataTests.cs
Adds WaitForDomainReload: boolean (default true) to embedded tool schema and C# schema, updates skill docs and examples (adds --no-wait-for-domain-reload, removes --compile-only), and tests verify default schema behavior.
Core dynamic-code wait helpers
Packages/src/Cli~/internal/cli/dynamic_code_wait.go
New helpers implement wait enablement rules, response-signal parsing (DomainReloadWaitRequired), disconnect-wait decision, and sanitization of control result fields.
Editor signal, response shaping, and use-case integration
Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/DynamicCodeDomainReloadWaitSignal.cs, Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeResponse.cs, Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeUseCase.cs, Assets/Tests/Editor/DynamicCodeToolTests/*
Adds editor-side signal observer to detect compilation/reload events, sets DomainReloadWaitRequired on responses, disposes signal in finally, and updates tests/serialization to ensure control fields are emitted only when applicable.
Parameter wiring, types, and compile-wait tests
Packages/src/Cli~/internal/cli/compile_wait.go, Packages/src/Cli~/internal/tools/types.go, Packages/src/Cli~/internal/cli/compile_wait_test.go, Packages/src/Cli~/internal/cli/tools_test.go
Switches to domainReloadWaitParam key and shared enablement checks; adds Hidden to ToolProperty; adds tests asserting default-on behavior for execute-dynamic-code, explicit disable, compile-only skip, and control-field stripping.
Completion and option visibility
Packages/src/Cli~/internal/cli/completion.go, Packages/src/Cli~/internal/cli/completion_test.go, Packages/src/Cli~/internal/cli/tools.go
Special-cases printing options for execute-dynamic-code from embedded defaults, exposes --no-wait-for-domain-reload while hiding internal --compile-only; adds visible-option helper and tests.
Execution path and readiness integration
Packages/src/Cli~/internal/cli/run.go, Packages/src/Cli~/internal/cli/tool_readiness.go, Packages/src/Cli~/internal/cli/launch_test.go
Routes execute-dynamic-code through a domain-reload-aware execution routine that handles disconnects and optional post-success readiness waits; readiness probe includes domainReloadWaitParam: false for warmup; tests updated accordingly.

Sequence Diagram(s)

sequenceDiagram
  participant CLI
  participant UnityIPCClient
  participant Editor
  participant ReadinessProbe
  CLI->>UnityIPCClient: send execute-dynamic-code request (params include WaitForDomainReload / CompileOnly)
  UnityIPCClient->>CLI: return outcome (possibly contains DomainReloadWaitRequired flag)
  CLI->>Editor: if DomainReloadWaitRequired or dispatch-disconnect -> wait for domain reload readiness
  Editor->>ReadinessProbe: readiness checks (probe uses domainReloadWaitParam:false for warmup)
  ReadinessProbe->>Editor: readiness result
  Editor->>CLI: readiness signal (complete/failure)
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

  • hatayama/unity-cli-loop#1101: Both PRs update CliConstants and CliSetupApplicationServiceTests to align minimum required CLI version expectations as the CLI evolves.
  • hatayama/unity-cli-loop#1070: Directly related—this PR's domain-reload wait logic and executeDynamicCodeReadinessProbeParams integration builds on the readiness/warmup foundations from PR #1070.
  • hatayama/unity-cli-loop#1027: Both PRs modify domain-reload waiting behavior in the CLI—this PR adds the wait mechanism while PR #1027 fixes compile-wait reliability for the same domain-reload code path.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 22.03% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: code execution now waits for reload recovery by default, which aligns with the core PR objective and file modifications.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/hatayama/update-domain-reload-default

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
Packages/src/Cli~/internal/cli/completion.go (1)

249-254: ⚡ Quick win

Keep cache fallback if embedded execute-dynamic-code lookup misses.

The unconditional return suppresses the existing cache fallback path when embedded defaults don’t contain the tool. Return only on embedded-hit, otherwise fall through to the normal cache lookup.

Proposed patch
 if command == executeDynamicCodeCommandName {
 	if tool, ok := findTool(loadDefaultTools(), command); ok {
 		printOptionsForTool(tool, stdout)
+		return
 	}
-	return
 }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Packages/src/Cli`~/internal/cli/completion.go around lines 249 - 254, The
current block around executeDynamicCodeCommandName unconditionally returns,
which prevents the cache fallback when findTool(loadDefaultTools(), command)
misses; change the control flow so that you only return when the embedded lookup
succeeds (i.e., when findTool(...) yields ok and you call printOptionsForTool),
but when it does not find the tool do not return and let the function continue
to the normal cache lookup path; adjust the if/ok handling in the
executeDynamicCodeCommandName branch to only exit on embedded-hit and otherwise
fall through.
Assets/Tests/Editor/CliSetupApplicationServiceTests.cs (1)

41-42: ⚡ Quick win

Avoid hardcoded version/tag literals in assertions.

Use CliConstants here too, so future version bumps only touch one source of truth.

♻️ Suggested update
-            Assert.That(service.GetMinimumRequiredCliVersion(), Is.EqualTo("3.0.0-beta.9"));
+            Assert.That(
+                service.GetMinimumRequiredCliVersion(),
+                Is.EqualTo(CliConstants.MINIMUM_REQUIRED_CLI_VERSION));
@@
-            Assert.That(service.GetMinimumRequiredCliReleaseTag(), Is.EqualTo("cli-v3.0.0-beta.9"));
+            Assert.That(
+                service.GetMinimumRequiredCliReleaseTag(),
+                Is.EqualTo(CliConstants.MINIMUM_REQUIRED_CLI_RELEASE_TAG));

Also applies to: 52-53

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Assets/Tests/Editor/CliSetupApplicationServiceTests.cs` around lines 41 - 42,
The test is asserting a hardcoded CLI version string; update the assertions in
CliSetupApplicationServiceTests to use the centralized constant from
CliConstants instead of the literal "3.0.0-beta.9" (and the other literal at the
second assertion location), e.g. call CliConstants.MinimumRequiredCliVersion (or
the exact constant name defined for the required CLI version) when asserting
service.GetMinimumRequiredCliVersion() to ensure a single source of truth for
version bumps.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@Assets/Tests/Editor/CliSetupApplicationServiceTests.cs`:
- Around line 41-42: The test is asserting a hardcoded CLI version string;
update the assertions in CliSetupApplicationServiceTests to use the centralized
constant from CliConstants instead of the literal "3.0.0-beta.9" (and the other
literal at the second assertion location), e.g. call
CliConstants.MinimumRequiredCliVersion (or the exact constant name defined for
the required CLI version) when asserting service.GetMinimumRequiredCliVersion()
to ensure a single source of truth for version bumps.

In `@Packages/src/Cli`~/internal/cli/completion.go:
- Around line 249-254: The current block around executeDynamicCodeCommandName
unconditionally returns, which prevents the cache fallback when
findTool(loadDefaultTools(), command) misses; change the control flow so that
you only return when the embedded lookup succeeds (i.e., when findTool(...)
yields ok and you call printOptionsForTool), but when it does not find the tool
do not return and let the function continue to the normal cache lookup path;
adjust the if/ok handling in the executeDynamicCodeCommandName branch to only
exit on embedded-hit and otherwise fall through.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3de39f77-8224-4628-8552-761721cf4fc4

📥 Commits

Reviewing files that changed from the base of the PR and between 6dbe57b and fbed937.

⛔ Files ignored due to path filters (3)
  • Packages/src/Cli~/dist/darwin-amd64/uloop is excluded by !**/dist/** and included by none
  • Packages/src/Cli~/dist/darwin-arm64/uloop is excluded by !**/dist/** and included by none
  • Packages/src/Cli~/dist/windows-amd64/uloop.exe is excluded by !**/dist/**, !**/*.exe and included by none
📒 Files selected for processing (17)
  • Assets/Tests/Editor/CliSetupApplicationServiceTests.cs
  • Assets/Tests/Editor/DynamicCodeToolTests/FirstPartyToolSchemaMetadataTests.cs
  • Packages/src/Cli~/contract.json
  • Packages/src/Cli~/internal/cli/compile_wait.go
  • Packages/src/Cli~/internal/cli/compile_wait_test.go
  • Packages/src/Cli~/internal/cli/completion.go
  • Packages/src/Cli~/internal/cli/completion_test.go
  • Packages/src/Cli~/internal/cli/dynamic_code_wait.go
  • Packages/src/Cli~/internal/cli/launch_test.go
  • Packages/src/Cli~/internal/cli/run.go
  • Packages/src/Cli~/internal/cli/tool_readiness.go
  • Packages/src/Cli~/internal/cli/tools_test.go
  • Packages/src/Cli~/internal/tools/default-tools.json
  • Packages/src/Editor/Application/CliSetupApplicationService.cs
  • Packages/src/Editor/Domain/CliConstants.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/ExecuteDynamicCodeSchema.cs
  • Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Skill/SKILL.md

Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 20 files

Re-trigger cubic

hatayama added 2 commits May 17, 2026 00:20
execute-dynamic-code can mutate editor or asset state in ways that start a domain reload after the tool response is produced. Defaulting to a post-reload checkpoint keeps follow-up CLI calls from racing the recovering editor, while --no-wait-for-domain-reload preserves the explicit fast path for callers that opt out.

Use a Unity-side compile/reload signal in the dynamic-code response so the native CLI waits only after Unity has observed reload work, and wait through dispatched transport disconnects when a reload drops IPC before the response is serialized. Raise the native CLI contract and Unity package minimum CLI version together so older beta CLIs cannot satisfy the new package-side expectation. Keep the GitHub Release tag as a separate cli-v-prefixed constant so installer code reads like the release page.
Keep the compile-only execution path available for internal diagnostics, but stop advertising it through CLI option listings, execute-dynamic-code skill docs, and public examples so normal users see only the supported workflow surface.
@hatayama hatayama force-pushed the feature/hatayama/update-domain-reload-default branch from fbed937 to 7365c7d Compare May 16, 2026 15:47
@hatayama hatayama merged commit 15d3ad0 into v3-beta May 16, 2026
7 checks passed
@hatayama hatayama deleted the feature/hatayama/update-domain-reload-default branch May 16, 2026 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant