CoreRasurae
007af498b8
Renamed all 11 task-type confidence threshold fields in AutomationProfile from phase-transition semantics to spec-defined task-type semantics. Updated all 8 built-in profiles, CLI formatting, YAML schema, services, and all Behave/Robot tests referencing the old field names. Post-review fixes: - Fixed 24 stale old field names in M6 fixture files (automation_profiles.json, autonomy_guardrails.json) - Added model_validator(mode='before') to detect legacy field names and raise actionable ValueError with rename mapping - Added semantic bridge comments in PlanLifecycleService mapping task-type thresholds to phase-transition gates - Added threshold_field to structured log messages for observability - Restored categorised CLI automation-profile show output to match spec (Phase Transitions / Decision Automation / Self-Repair / Execution Controls) instead of flat list - Added missing access_network field to spec show output examples (Rich, Plain, JSON, YAML variants) - Aligned ADR-017 profile fields table to all 11 fields with descriptions matching spec Automatable Tasks table - Aligned automation_profiles.md threshold descriptions with spec - Added spec section references in phase_reversion.md, error_recovery.md, and plan_execute.md for field naming context - Extended repository roundtrip test to assert all 11 threshold fields - Fixed benchmark _make_profile() passing safety fields as top-level kwargs instead of via SafetyProfile sub-model (incompatible with extra="forbid") - Aligned CLI JSON/YAML output structure for automation-profile show with the specification grouped format (phase_transitions, decision_automation, self_repair, execution_controls) - Moved safety boolean fields into the Execution Controls section of Rich output per spec examples - Reverted auto profile description to "Fully automatic except apply" per specification (line 16703, line 28406) - Improved bridge comments in test steps with semantic context for threshold-to-gate mappings ISSUES CLOSED: #902
3.8 KiB
AutomationProfileService Reference
Overview
The AutomationProfileService resolves the effective automation profile
for plan execution using a four-level precedence hierarchy.
Profile Precedence
Profiles are resolved in order (first non-null wins):
| Priority | Source | Description |
|---|---|---|
| 1 | Plan-level | Explicitly set via --automation-profile |
| 2 | Action-level | Default profile set on the action template |
| 3 | Project-level | Set via project configuration |
| 4 | Global-level | Config key or CLEVERAGENTS_AUTOMATION_PROFILE env var |
If no profile is set at any level, the global default is manual.
Configuration
Config Key
core:
automation_profile: "supervised"
This sets the global default profile name. The Settings field is
default_automation_profile.
Environment Variable Override
export CLEVERAGENTS_AUTOMATION_PROFILE=auto
The environment variable takes precedence over the config file value when the config field is empty.
Legacy Mapping
The automation_level setting is retained for backward compatibility.
It is mapped to built-in profiles as follows:
automation_level Value |
Built-in Profile |
|---|---|
manual |
manual |
supervised |
supervised |
auto |
auto |
full_auto |
full-auto |
When default_automation_profile is set, it takes precedence over
default_automation_level.
Auto-Progress Behavior
The PlanLifecycleService uses profile thresholds to decide whether
to auto-progress plans:
- Strategize → Execute: auto-progresses when
profile.create_tool < 1.0 - Execute → Apply: auto-progresses when
profile.select_tool < 1.0
A threshold of 0.0 means fully automatic (no human gate required).
A threshold of 1.0 means human approval is always required.
Built-in Profiles
Eight built-in profiles ship with every installation:
| Profile | create_tool | select_tool | Behavior |
|---|---|---|---|
manual |
1.0 | 1.0 | Human approves all |
review |
0.0 | 1.0 | Human reviews before apply |
supervised |
1.0 | 1.0 | Human reviews strategy + execution |
cautious |
0.7 | 1.0 | Probabilistic gates |
trusted |
0.0 | 1.0 | Auto most, human apply |
auto |
0.0 | 1.0 | Fully auto except revert |
ci |
0.0 | 0.0 | CI pipeline mode |
full-auto |
0.0 | 0.0 | No gates at all |
Persistence
Custom profiles are stored in the automation_profiles table with
the namespaced name as the primary key. The repository supports
list, show (get_by_name), upsert, and delete operations with a
schema_version guard for optimistic concurrency.
API
resolve_profile(plan_profile, action_profile, project_profile)
Resolves the effective profile using the four-level precedence.
get_profile(name)
Looks up a profile by name (built-in first, then repository).
map_legacy_level(level)
Maps a legacy automation_level string to a profile name.
resolve_legacy_level(level)
Resolves a legacy automation_level to a full AutomationProfile.
list_profiles()
Returns all built-in and custom profiles.
create_profile(config)
Creates and persists a custom profile.
update_profile(name, config)
Updates a persisted custom profile.
delete_profile(name)
Deletes a persisted custom profile.