bug(dashboard): Autonomous operations toggle ignores nested pipelineV2.autonomous.enabled and renders off at runtime #1963

Preflight

• I searched existing issues for duplicates or related work.
• I reproduced this on current main or the latest release, or explained why I cannot.
• I removed secrets and personal data from logs and examples.

Bug description

The Settings → Advanced toggle "Autonomous operations" always renders off, even when autonomous operations are enabled and active. The dashboard reads the flat config key memory.pipelineV2.autonomousEnabled, but the canonical runtime resolver accepts the nested form memory.pipelineV2.autonomous.enabled (and the packaged setup template writes the nested form). A workspace configured through setup or the resolver therefore shows the toggle off in the UI while the daemon genuinely runs autonomous operations — GET /api/status reports pipelineV2.autonomous.enabled: true while the switch renders unchecked.

The same mismatch affects the "Freeze autonomous writes" toggle: the UI reads pipelineV2.autonomousFrozen while the resolver also accepts pipelineV2.autonomous.frozen.

User impact: settings look silently reset/disabled after setup or template-based configuration, and a user who toggles the switch on writes a redundant flat key rather than corrupting anything — but the display lies about runtime state, and a user who toggles "off" believes they disabled something that stays enabled at runtime via the nested key.

Steps to reproduce

1. Configure a workspace with agent.yaml containing:

memory:
  pipelineV2:
    autonomous:
      enabled: true
      maintenanceMode: execute

2. Open the dashboard → Settings → Advanced → "Autonomy & maintenance".
3. Observe "Autonomous operations" renders off.
4. GET /api/status reports pipelineV2.autonomous.enabled: true and maintenanceMode: "execute".

Expected behavior

The toggle reflects the resolved runtime state: it should read the nested autonomous.enabled form (or any accepted alias) the same way the daemon resolver does.

Actual behavior

The toggle reads only the flat autonomousEnabled key and renders off whenever only the nested form is set.

Environment

• Signet version/commit: reproduced on 0.228.0; the same read path exists in 0.227.1 (pre-dates feat: establish workspace v2 ownership #1945, not a regression from it)
• OS: Arch Linux
• Runtime: compiled native binary, dashboard served from the daemon bundle
• Source: surfaces/dashboard/src/views/settings.tsx — AdvancedSection binds AdvToggle to ["memory", "pipelineV2", "autonomousEnabled"] (and autonomousFrozen); the resolver in platform/daemon/src/memory-config.ts accepts both autonomous.enabled and the flat alias.

Logs, trace, or reproduction artifact

Live capture of the rendered toggles against a config using the nested form:

Knowledge graph          => checked   (flat key set in file)
Autonomous operations    => unchecked (nested autonomous.enabled: true)
Allow update/delete      => checked   (flat key set in file)
GET /api/status → pipelineV2.autonomous = { enabled: true, frozen: false, maintenanceMode: "execute" }

Root-cause hypothesis or proposed fix

Fix in the dashboard settings layer: derive the autonomous toggles from both accepted forms, mirroring the resolver's alias behavior (e.g. read autonomous.enabled ?? autonomousEnabled, read autonomous.frozen ?? autonomousFrozen), and write back to the form the resolver treats as canonical. The nested object is what the shipped setup template writes, so that should be the display's source of truth. A small test asserting the toggle state from a nested-form config would lock it.