Default new lightweight routines to tools-enabled

[henrypark133]

Summary

• default newly created lightweight routines to use_tools=true while keeping legacy stored routines backward compatible
• update routine discovery text to describe the owner live autonomous scope and the explicit use_tools=false opt-out
• add e2e coverage for both the new default-on path and the explicit no-tools path

Testing

• CARGO_TARGET_DIR=/tmp/ironclaw-lightweight-routines-default-tools-target cargo test parses_lightweight_create
• CARGO_TARGET_DIR=/tmp/ironclaw-lightweight-routines-default-tools-target cargo test test_action_lightweight_backward_compat_no_use_tools
• CARGO_TARGET_DIR=/tmp/ironclaw-lightweight-routines-default-tools-target cargo test routine_create
• CARGO_TARGET_DIR=/tmp/ironclaw-lightweight-routines-default-tools-target cargo test routine_manual_create

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request modifies the behavior of lightweight routines to default to tools-enabled, enhancing their capabilities by allowing them to use the owner's live autonomous tool scope. It also ensures backward compatibility for existing routines and provides clear documentation on how to opt-out of the new default behavior. Comprehensive end-to-end tests have been added to validate the changes.

Highlights

• Default Lightweight Routines to Tools-Enabled: New lightweight routines now default to use_tools=true, allowing them to leverage the owner's live autonomous tool scope.
• Backward Compatibility: Legacy stored routines remain backward compatible, ensuring existing functionality is not affected.
• Routine Discovery Text Update: Updated routine discovery text to clarify the owner's live autonomous scope and the explicit use_tools=false opt-out.
• E2E Coverage: Added end-to-end tests to cover both the new default-on path and the explicit no-tools path.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request changes the default behavior for new lightweight routines to have tools enabled. The implementation correctly introduces a default_use_tools parameter to parse_routine_execution and sets it to true for new routine creation, while maintaining backward compatibility for existing routines loaded from the database. The associated documentation, JSON schemas, and tool discovery summaries have been updated to reflect this new default and explain how to opt-out. The changes are well-tested with new unit and end-to-end tests covering both the new default and the explicit opt-out path. The code quality is high, and I have no issues to report.

[Copilot]

Pull request overview

Defaults newly created lightweight routines to use_tools=true so they can run with the owner’s autonomous tool scope by default, while keeping explicit opt-out and legacy behavior working.

Changes:

• Changed routine creation parsing so lightweight routines default to use_tools=true unless explicitly disabled.
• Updated routine tool discovery/schema text to describe the new default and the execution.use_tools=false opt-out.
• Added/updated unit + e2e tests and fixtures to cover default-on and explicit no-tools creation paths.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
tests/fixtures/llm_traces/tools/routine_manual_create_no_tools.json	Adds an e2e LLM trace fixture for creating a manual lightweight routine with tools explicitly disabled.
tests/e2e_builtin_tool_coverage.rs	Splits/expands the manual routine e2e test to assert the new default (use_tools=true) and the explicit opt-out path.
src/tools/builtin/routine.rs	Updates discovery text and changes lightweight execution parsing default to use_tools=true; adds unit coverage for default vs explicit disable.
src/agent/routine_engine.rs	Updates inline documentation to reflect autonomous tool-scope behavior for tool-enabled lightweight routines.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This trace uses the legacy top-level use_tools argument. Since the updated routine discovery text instructs callers to opt out via execution.use_tools=false, it would be better for this e2e fixture to use the canonical grouped field (e.g., execution: { use_tools: false }) so the trace matches current guidance and exercises the preferred parameter shape.

Suggested change

	"use_tools": false
	"execution": {
	"use_tools": false
	}

[henrypark133]

Fixed in f5062b6. I switched the fixture to the canonical grouped shape with execution.use_tools=false, and reran CARGO_TARGET_DIR=/tmp/ironclaw-lightweight-routines-default-tools-target cargo test routine_manual_create to confirm the opt-out e2e still passes.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Same as above: lightweight_execution_variant() documents use_tools defaulting to true, but the schema omits an explicit default: true. Setting the default in the schema would better match runtime parsing and improve discoverability.

Suggested change

	"type": "boolean",
	"type": "boolean",
	"default": true,

[henrypark133]

Fixed in 161f3e9. I added explicit "default": true metadata for the lightweight use_tools schema so discovery matches the runtime default.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zmanian]

Code Review: Default lightweight routines to tools-enabled

Verdict: APPROVE

Changes default for newly created lightweight routines from use_tools=false to use_tools=true (with max_tool_rounds=3).

Backward Compatibility: SAFE

Existing routines stored in the database are unaffected -- RoutineAction::from_db() defaults use_tools to false when the field is absent. Only new routine creation is affected.

Security

When use_tools=true, tools are filtered through autonomous_allowed_tool_names() respecting the owner's autonomous scope. Loop capped at min(max_tool_rounds, config.lightweight_max_iterations, 5). Reasonable guardrails.

Suggestions (non-blocking)

1. Unrelated cleanup: The codex_test_helpers.rs change (removing redundant #![cfg(test)]) doesn't belong in this PR. Harmless but worth noting.

2. max_tool_rounds=3 when use_tools=false: Storing max_tool_rounds=3 on a tools-disabled routine is slightly misleading. Consider defaulting to 0 when tools are disabled, or documenting that the value is ignored.

3. CLI test gating: cli_create_defaults_lightweight_routines_to_tools_enabled only runs under #[cfg(feature = "libsql")]. Ensure CI covers this.

Good test coverage at unit and e2e levels. Clean implementation.

[henrypark133]

Thanks for the review.

On the non-blocking notes:

• codex_test_helpers.rs: agreed this is unrelated to the routine behavior itself. I left it in this branch because full cargo clippy --all-targets --all-features -- -D warnings was failing on the duplicated #![cfg(test)], so the small cleanup was needed to keep the PR green.
• max_tool_rounds=3 when use_tools=false: I left that as-is intentionally. The schema and discovery text already describe max_tool_rounds as only applying when tools are enabled, so the value is ignored in the disabled case. I didn’t want to introduce a second sentinel convention (0 vs 3) in this PR.
• CLI test gating: confirmed CI covers this. The repo runs libsql-only matrices in both .github/workflows/test.yml and .github/workflows/code_style.yml, so the #[cfg(feature = "libsql")] CLI regression test is exercised in CI.