Skip to content

refactor(rust): move implementation to rust/clawcode workspace - #3289

Open
huagusam wants to merge 7 commits into
ultraworkers:mainfrom
huagusam:restructure/rust-clawcode-workspace
Open

refactor(rust): move implementation to rust/clawcode workspace#3289
huagusam wants to merge 7 commits into
ultraworkers:mainfrom
huagusam:restructure/rust-clawcode-workspace

Conversation

@huagusam

Copy link
Copy Markdown

Restructures the Rust codebase into a self-contained \clawcode\ workspace under
ust/clawcode, collocating claw config (agents, skills) with the Rust crates.

  • Move crates: agents, api, claw-cli, commands, compat-harness, migrate-patch-names, mock-anthropic-service, plugin-types, plugins, runtime, telemetry, tools
  • Drop the old flat
    ust/\ crates tree
  • Add
    ust/clawcode/claw/\ workspace config with agents and skills
  • Gitignore local .env\ secrets (\claw/.env, \claw/.env_deepseek)

Verified: \cargo build --release\ succeeds in the new workspace.

Restructures the Rust codebase into a self-contained clawcode workspace
under rust/clawcode, collocating claw config (agents, skills) with the
Rust crates. Follows the project convention of keeping source under rust/.

- Move crates: agents, api, claw-cli, commands, compat-harness,
  migrate-patch-names, mock-anthropic-service, plugin-types, plugins,
  runtime, telemetry, tools
- Drop the old flat rust crates tree
- Add claw/ workspace config with agents and skills
- Gitignore local .env secrets (claw/.env, claw/.env_deepseek)
@1716775457damn

Copy link
Copy Markdown

This restructure looks good — collocating the claw config (agents/skills) with the Rust crates under rust/clawcode keeps configuration in sync with the code, and gitignoring the local .env secrets is the right call. Since cargo build --release passes in the new workspace, the move seems safe. Thanks for cleaning up the old flat crates tree too.

…d settings/env/CLI precedence

- Introduce ReasoningEffort enum and per-provider level/wire registry
- Fail-fast validation in preflight rejects unsupported/unknown levels
- Wire translation: Anthropic thinking budgets, OpenAI reasoning_effort (off omits field)
- Propagate settings.json plugins.reasoningEffort with env/CLI precedence
- Document CLAW_REASONING_EFFORT in .env.example
@1716775457damn

Copy link
Copy Markdown

Looking at the reasoning-effort registry in 93ca225: the per-provider level/wire mapping plus fail-fast preflight validation is the right shape, and omitting reasoning_effort entirely for off (rather than sending "off") is correct — several OpenAI-compatible servers reject an explicit off value.

Two edge cases I don't see covered:

  1. Budget vs max_tokens: max maps to a 32000 thinking budget, but Anthropic rejects requests where the thinking budget is >= max_tokens. Preflight validates that the level is supported, but as far as I can tell it doesn't compare the resolved budget against the configured max_tokens, so a --reasoning-effort max run with a small --max-tokens would fail at request time instead of up front — which is exactly the class of failure the preflight check exists to prevent.

  2. Capability detection on self-hosted backends: fail-fast depends on knowing whether the endpoint supports reasoning at all. For a self-hosted Anthropic-compatible server (the scenario fix: harden the agent loop against a self-hosted Anthropic-compatible backend #3292 is hardening against), the capability table may be incomplete or the proxy may silently strip the field — then a valid-but-unsupported level either fails spuriously or gets dropped without any signal. Worth a way to mark a provider as reasoning-unknown and degrade to a warning rather than a hard failure.

Neither is a blocker for the restructure itself; the workspace move and the .env templating look good.

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.

2 participants