Skip to content

fix(skills): repair butler cron and doc drift (2026-07-22 audit)#664

Open
IceyLiu wants to merge 2 commits into
mainfrom
fix/aionui-butler-drift-2026-07-22
Open

fix(skills): repair butler cron and doc drift (2026-07-22 audit)#664
IceyLiu wants to merge 2 commits into
mainfrom
fix/aionui-butler-drift-2026-07-22

Conversation

@IceyLiu

@IceyLiu IceyLiu commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Summary

Daily drift audit (2026-07-22) found two breaking issues and two doc
problems in the butler's built-in skills. This PR fixes all four.
Changes are asset-only — no .rs changes — and ship to users via
include_dir! on the next binary build.

Fixes

B1 — aionui-config: cron jobs update schedule field type (BREAKING)

The update example used "schedule": "0 10 * * MON" (flat string). The
backend UpdateCronJobRequest.schedule is Option<CronScheduleDto>
(crates/aionui-api-types/src/cron.rs:203-204) — the same internally-tagged
object as create. A plain string fails to deserialize and the request
errors out. Fixed the example to { "kind": "cron", "expr": "0 10 * * MON" }
and added a note distinguishing the two cron families (cron jobs uses
tagged object; cron current uses flat string).

B2 — aionui-troubleshooting: cron field names/paths (BREAKING → misdiagnosis)

The skill told the reading agent to look at top-level last_status,
next_run_at, last_run_at etc. These don't exist there. All run-state
fields are nested under state in CronJobResponse
(crates/aionui-api-types/src/cron.rs:113-140), and the timestamp fields
carry _ms suffixes. The agent would silently find nothing and misreport
cron state. Corrected to state.last_status, state.last_error,
state.next_run_at_ms, state.last_run_at_ms, etc.
Also added a fallback hint for the cron.failing overview field being
empty (see backend bug report linked below).

D1 — aionui-config: default_mcp_idsdefaults.mcps

Prose at line 149 named default_mcp_ids as a settable field on assistant
update. No such field exists on UpdateAssistantRequest; MCP defaults are
set via defaults.mcps (assistant.rs:164). Without deny_unknown_fields,
the old name was silently ignored. Corrected the prose.

D2 — aionui-config: agents custom testtry-connect

The prose said "test a custom agent" but the actual subcommand is
try-connect (cmd_config.rs:800-808). Renamed and added a minimal
example.

How verified

Every fix was verified against file:line in the freshly-pulled main
(10cdd579) before editing:

  • UpdateCronJobRequest: cron.rs:203-204
  • CronJobStateDto nesting: cron.rs:113-140
  • AssistantDefaultsRequest.mcps: assistant.rs:164
  • try-connect dispatch: cmd_config.rs:800-808

Related

Backend bug (not in this PR): diagnose cron summary / overview read
last_status at the wrong depth (cmd_diagnose.rs:764, 783), so
cron.failing is always empty. A separate issue is filed for that .rs
fix.

Deploy path

Asset-only change. Ships via include_dir! in aionui-app when the
binary is rebuilt. No migration, no schema change.

IceyLiu added 2 commits July 22, 2026 21:09
- cron jobs update example used a flat string for `schedule`; backend
  expects the tagged CronScheduleDto object (same as create). A flat
  string fails to deserialize and the update errors out.
- Added inline note distinguishing the tagged-object schedule used by
  `cron jobs` from the flat-string schedule used by `cron current`.
- Replaced `default_mcp_ids` prose (silently ignored by backend) with
  `defaults.mcps` — the actual AssistantDefaultsRequest field.
- Renamed "test" to `try-connect` for custom agents and added a minimal
  example showing the `command` field.
Cron run-state fields are nested under `state` in CronJobResponse, not
top-level. Timestamps use _ms suffix (epoch ms). The old field names
(`next_run_at`, `last_run_at` at top level) do not exist — the agent
would silently find nothing.

Also adds a fallback hint for `cron.failing` being empty: a known
backend bug in the diagnose CLI reads `last_status` at the wrong depth,
so the overview `cron.failing` list is always empty. Direct inspection
of `all[].state.last_status` in `diagnose cron summary` is the
workaround.
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