agents init --yes should not require user input. #783

Closed
opened 2026-03-12 20:41:01 +00:00 by brent.edwards · 6 comments
Member

The difference between agents init and agents init --yes is that agents init may ask the user whether steps should be taken; agents init --yes should assume the answers to all problems is "Yes".

Given:

Inside a docker container at commit log ec0b7631d06c9aea44264e281de0 , run the following steps:

cd ~ # Put the virtual environment outside of /app
uv venv
source .venv/bin/activate
uv pip install -e /app

When:

The user types agents init --yes

Expected

The system initializes without any user input.

This command should act as if

yes | agents init

were typed.

Actual

Here is the output; the ***HERE*** was added to show where user input was necessary.

(devuser) ➜  ~ agents init --yes
Database schema is not initialized. Apply migrations to create it.

Apply migrations now? It's recommended to back up the .cleveragents directory first. [y/N]: y ***HERE***
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> 001_initial_schema, Initial database schema with all core tables.
INFO  [alembic.runtime.migration] Running upgrade 001_initial_schema -> 4b518923afb2, add_debug_attempts_table
INFO  [alembic.runtime.migration] Running upgrade 4b518923afb2 -> c3d9b3d0cf3e, Add actors table for actor registry.
INFO  [alembic.runtime.migration] Running upgrade c3d9b3d0cf3e -> a5_001_actions_v3, Add actions_v3 table for v3 plan lifecycle.
INFO  [alembic.runtime.migration] Running upgrade a5_001_actions_v3 -> a5_002_lifecycle_plans, Add lifecycle_plans table for v3 plan lifecycle.
INFO  [alembic.runtime.migration] Running upgrade a5_002_lifecycle_plans -> a5_003_spec_aligned_actions, Replace actions_v3 with spec-aligned actions table.
INFO  [alembic.runtime.migration] Running upgrade a5_003_spec_aligned_actions -> a5_004_spec_aligned_plans, Create spec-aligned plans and related tables.
INFO  [alembic.runtime.migration] Running upgrade a5_004_spec_aligned_plans -> b1_001_resource_registry, Add resource registry tables (resource_types, resources, resource_edges).
INFO  [alembic.runtime.migration] Running upgrade b1_001_resource_registry -> b1_001_resource_links, Add resource_links table for validated DAG parent-child links.
INFO  [alembic.runtime.migration] Running upgrade b1_001_resource_registry -> a5_005_rebaseline_plan_phases, Rebaseline plan phase/state enums for Action + Apply terminal states.
INFO  [alembic.runtime.migration] Running upgrade a5_005_rebaseline_plan_phases -> b0_001_projects, Add ns_projects and project_resource_links tables.
INFO  [alembic.runtime.migration] Running upgrade b0_001_projects -> c1_001_tool_registry, Add tool registry tables (tools, tool_resource_bindings, validation_attachments).
INFO  [alembic.runtime.migration] Running upgrade c1_001_tool_registry -> a7_001_session_persistence, Add sessions and session_messages tables.
INFO  [alembic.runtime.migration] Running upgrade c1_001_tool_registry -> a6_001_automation_profiles, Add automation_profiles table.
INFO  [alembic.runtime.migration] Running upgrade a6_001_automation_profiles, b1_001_resource_links -> 71cd40eb661f, Merge resource_links and automation_profiles branches
INFO  [alembic.runtime.migration] Running upgrade 71cd40eb661f -> c0_001_skill_registry, Add skill registry tables (skills, skill_items).
INFO  [alembic.runtime.migration] Running upgrade 71cd40eb661f, a7_001_session_persistence -> a7_002_merge_heads, Merge session persistence and resource/automation heads.
INFO  [alembic.runtime.migration] Running upgrade a7_002_merge_heads -> c3_001_actor_registry, Add yaml_text, schema_version, compiled_metadata to actors table.
INFO  [alembic.runtime.migration] Running upgrade c3_001_actor_registry -> a6_002_drop_automation_level, Drop automation_level column from v3_plans.
INFO  [alembic.runtime.migration] Running upgrade a6_002_drop_automation_level, c0_001_skill_registry -> c0_002_merge_skill_registry, Merge skill registry and actor/automation heads.
INFO  [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> m4_001_concurrency_locks, Add concurrency locks table.
INFO  [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> d0_001_changeset_artifacts, Add changeset_entries and tool_invocations tables.
INFO  [alembic.runtime.migration] Running upgrade d0_001_changeset_artifacts, m4_001_concurrency_locks -> d0_002_merge_changeset_and_locks, Merge changeset artifacts and concurrency locks heads.
INFO  [alembic.runtime.migration] Running upgrade d0_002_merge_changeset_and_locks -> m4_001_decision_tables, Add decision tree tables.
INFO  [alembic.runtime.migration] Running upgrade m4_001_decision_tables -> m4_002_skill_flattened_tools, Add flattened tool persistence columns to skills table.
INFO  [alembic.runtime.migration] Running upgrade m4_002_skill_flattened_tools -> m6_001_checkpoint_metadata, Create checkpoint_metadata table.
INFO  [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> c4_001_safety_profile_column, Add safety_profile_json column to actions table.
INFO  [alembic.runtime.migration] Running upgrade c4_001_safety_profile_column, m6_001_checkpoint_metadata -> m6_002_merge_safety_and_checkpoint, Merge safety profile and checkpoint metadata heads.
INFO  [alembic.runtime.migration] Running upgrade m6_002_merge_safety_and_checkpoint -> m6_003_async_jobs_table, Add async_jobs table for background job execution.
INFO  [alembic.runtime.migration] Running upgrade m6_003_async_jobs_table -> m7_001_repo_indexing_tables, Add repo_indexes and indexed_files tables for repository indexing.
INFO  [alembic.runtime.migration] Running upgrade m7_001_repo_indexing_tables -> m6_004_resource_type_inherits, Add inherits column to resource_types for type inheritance (ADR-042).
INFO  [alembic.runtime.migration] Running upgrade m6_004_resource_type_inherits -> m6_004_container_metadata_column, Add container_metadata_json column to tool_invocations table.
2026-03-12 19:44:02 [debug    ] Starting attempt               attempt_number=1 outcome=None
╭────────────────── Initialized ──────────────────╮
│ Data Dir: /home/devuser/.cleveragents (created) │
│ Config: /home/devuser/.cleveragents/config.toml │
│ Database: initialized (schema v3)               │
│ Directories: logs, cache, sessions, contexts    │
╰─────────────────────────────────────────────────╯
✓ OK Initialized (non-interactive)
The difference between `agents init` and `agents init --yes` is that `agents init` may ask the user whether steps should be taken; `agents init --yes` should assume the answers to all problems is "Yes". ## Given: Inside a docker container at commit log `ec0b7631d06c9aea44264e281de0` , run the following steps: ``` cd ~ # Put the virtual environment outside of /app uv venv source .venv/bin/activate uv pip install -e /app ``` ## When: The user types `agents init --yes` ## Expected The system initializes without any user input. This command should act as if `yes | agents init` were typed. ## Actual Here is the output; the `***HERE***` was added to show where user input was necessary. ``` (devuser) ➜ ~ agents init --yes Database schema is not initialized. Apply migrations to create it. Apply migrations now? It's recommended to back up the .cleveragents directory first. [y/N]: y ***HERE*** INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. INFO [alembic.runtime.migration] Running upgrade -> 001_initial_schema, Initial database schema with all core tables. INFO [alembic.runtime.migration] Running upgrade 001_initial_schema -> 4b518923afb2, add_debug_attempts_table INFO [alembic.runtime.migration] Running upgrade 4b518923afb2 -> c3d9b3d0cf3e, Add actors table for actor registry. INFO [alembic.runtime.migration] Running upgrade c3d9b3d0cf3e -> a5_001_actions_v3, Add actions_v3 table for v3 plan lifecycle. INFO [alembic.runtime.migration] Running upgrade a5_001_actions_v3 -> a5_002_lifecycle_plans, Add lifecycle_plans table for v3 plan lifecycle. INFO [alembic.runtime.migration] Running upgrade a5_002_lifecycle_plans -> a5_003_spec_aligned_actions, Replace actions_v3 with spec-aligned actions table. INFO [alembic.runtime.migration] Running upgrade a5_003_spec_aligned_actions -> a5_004_spec_aligned_plans, Create spec-aligned plans and related tables. INFO [alembic.runtime.migration] Running upgrade a5_004_spec_aligned_plans -> b1_001_resource_registry, Add resource registry tables (resource_types, resources, resource_edges). INFO [alembic.runtime.migration] Running upgrade b1_001_resource_registry -> b1_001_resource_links, Add resource_links table for validated DAG parent-child links. INFO [alembic.runtime.migration] Running upgrade b1_001_resource_registry -> a5_005_rebaseline_plan_phases, Rebaseline plan phase/state enums for Action + Apply terminal states. INFO [alembic.runtime.migration] Running upgrade a5_005_rebaseline_plan_phases -> b0_001_projects, Add ns_projects and project_resource_links tables. INFO [alembic.runtime.migration] Running upgrade b0_001_projects -> c1_001_tool_registry, Add tool registry tables (tools, tool_resource_bindings, validation_attachments). INFO [alembic.runtime.migration] Running upgrade c1_001_tool_registry -> a7_001_session_persistence, Add sessions and session_messages tables. INFO [alembic.runtime.migration] Running upgrade c1_001_tool_registry -> a6_001_automation_profiles, Add automation_profiles table. INFO [alembic.runtime.migration] Running upgrade a6_001_automation_profiles, b1_001_resource_links -> 71cd40eb661f, Merge resource_links and automation_profiles branches INFO [alembic.runtime.migration] Running upgrade 71cd40eb661f -> c0_001_skill_registry, Add skill registry tables (skills, skill_items). INFO [alembic.runtime.migration] Running upgrade 71cd40eb661f, a7_001_session_persistence -> a7_002_merge_heads, Merge session persistence and resource/automation heads. INFO [alembic.runtime.migration] Running upgrade a7_002_merge_heads -> c3_001_actor_registry, Add yaml_text, schema_version, compiled_metadata to actors table. INFO [alembic.runtime.migration] Running upgrade c3_001_actor_registry -> a6_002_drop_automation_level, Drop automation_level column from v3_plans. INFO [alembic.runtime.migration] Running upgrade a6_002_drop_automation_level, c0_001_skill_registry -> c0_002_merge_skill_registry, Merge skill registry and actor/automation heads. INFO [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> m4_001_concurrency_locks, Add concurrency locks table. INFO [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> d0_001_changeset_artifacts, Add changeset_entries and tool_invocations tables. INFO [alembic.runtime.migration] Running upgrade d0_001_changeset_artifacts, m4_001_concurrency_locks -> d0_002_merge_changeset_and_locks, Merge changeset artifacts and concurrency locks heads. INFO [alembic.runtime.migration] Running upgrade d0_002_merge_changeset_and_locks -> m4_001_decision_tables, Add decision tree tables. INFO [alembic.runtime.migration] Running upgrade m4_001_decision_tables -> m4_002_skill_flattened_tools, Add flattened tool persistence columns to skills table. INFO [alembic.runtime.migration] Running upgrade m4_002_skill_flattened_tools -> m6_001_checkpoint_metadata, Create checkpoint_metadata table. INFO [alembic.runtime.migration] Running upgrade c0_002_merge_skill_registry -> c4_001_safety_profile_column, Add safety_profile_json column to actions table. INFO [alembic.runtime.migration] Running upgrade c4_001_safety_profile_column, m6_001_checkpoint_metadata -> m6_002_merge_safety_and_checkpoint, Merge safety profile and checkpoint metadata heads. INFO [alembic.runtime.migration] Running upgrade m6_002_merge_safety_and_checkpoint -> m6_003_async_jobs_table, Add async_jobs table for background job execution. INFO [alembic.runtime.migration] Running upgrade m6_003_async_jobs_table -> m7_001_repo_indexing_tables, Add repo_indexes and indexed_files tables for repository indexing. INFO [alembic.runtime.migration] Running upgrade m7_001_repo_indexing_tables -> m6_004_resource_type_inherits, Add inherits column to resource_types for type inheritance (ADR-042). INFO [alembic.runtime.migration] Running upgrade m6_004_resource_type_inherits -> m6_004_container_metadata_column, Add container_metadata_json column to tool_invocations table. 2026-03-12 19:44:02 [debug ] Starting attempt attempt_number=1 outcome=None ╭────────────────── Initialized ──────────────────╮ │ Data Dir: /home/devuser/.cleveragents (created) │ │ Config: /home/devuser/.cleveragents/config.toml │ │ Database: initialized (schema v3) │ │ Directories: logs, cache, sessions, contexts │ ╰─────────────────────────────────────────────────╯ ✓ OK Initialized (non-interactive) ```
freemo added this to the v3.2.0 milestone 2026-03-12 20:57:00 +00:00
Owner

Dependency (TDD workflow): This bug fix is blocked by TDD issue #842. Per CONTRIBUTING.md Bug Fix Workflow, the TDD test capturing the bug must be written and merged first (@tdd_expected_fail), then the fix PR removes the tag.

Blocked by: #842

**Dependency (TDD workflow):** This bug fix is blocked by TDD issue #842. Per `CONTRIBUTING.md` Bug Fix Workflow, the TDD test capturing the bug must be written and merged first (`@tdd_expected_fail`), then the fix PR removes the tag. **Blocked by:** #842
Owner

PM Triage — Day 34

State: Upgraded from State/Unverified to State/Verified. The bug is clearly reproducible per the report — agents init --yes should not prompt for input.

Priority exception: Per PM decision, this bug is kept at Priority/Low + MoSCoW/Could Have instead of the mandatory Priority/Critical for bugs. Justification: the workaround is trivial (type "y" when prompted), the --yes flag still initializes correctly after the prompt, and no data loss or test failure occurs. This is a UX convenience issue rather than a blocking defect.

TDD counterpart: #842 (assigned to @hurui200320, State/Verified).

Assignee: @aditya — confirmed.

Note: Removed the repo-level bug label — the org-level Type/Bug label is the correct label per CONTRIBUTING.md.


PM triage comment — Day 34

## PM Triage — Day 34 **State**: Upgraded from `State/Unverified` to `State/Verified`. The bug is clearly reproducible per the report — `agents init --yes` should not prompt for input. **Priority exception**: Per PM decision, this bug is kept at **Priority/Low + MoSCoW/Could Have** instead of the mandatory Priority/Critical for bugs. Justification: the workaround is trivial (type "y" when prompted), the `--yes` flag still initializes correctly after the prompt, and no data loss or test failure occurs. This is a UX convenience issue rather than a blocking defect. **TDD counterpart**: #842 (assigned to @hurui200320, State/Verified). **Assignee**: @aditya — confirmed. **Note**: Removed the repo-level `bug` label — the org-level `Type/Bug` label is the correct label per CONTRIBUTING.md. --- *PM triage comment — Day 34*
Owner

Priority exception documented.

Per project policy, all Type/Bug issues should carry Priority/Critical. The PM has justified keeping this at Priority/Low because:

  1. The bug is cosmetic — agents init --yes still prompts for input, but the workaround is trivial (respond to the prompt).
  2. No data loss or functional failure occurs.
  3. The bug does not block any M3 acceptance criteria.

Decision: This exception is accepted under the same conditions as #797. TDD counterpart #842 exists and must be completed before the fix. The exception is formally recorded for audit purposes.

**Priority exception documented.** Per project policy, all `Type/Bug` issues should carry `Priority/Critical`. The PM has justified keeping this at `Priority/Low` because: 1. The bug is cosmetic — `agents init --yes` still prompts for input, but the workaround is trivial (respond to the prompt). 2. No data loss or functional failure occurs. 3. The bug does not block any M3 acceptance criteria. **Decision:** This exception is accepted under the same conditions as #797. TDD counterpart #842 exists and must be completed before the fix. The exception is formally recorded for audit purposes.
Owner

Day 42 escalation: The TDD counterpart (#842) was completed and merged to master on 2026-03-19. However, no bugfix/ branch has been created yet. Per the TDD workflow (CONTRIBUTING.md > Bug Fix Workflow), @aditya should:

  1. Create the bugfix branch from master
  2. Implement the fix
  3. Remove the @tdd_expected_fail tag
  4. Open a PR to master

This is now 2 days overdue. Please start immediately.

**Day 42 escalation**: The TDD counterpart (#842) was completed and merged to master on 2026-03-19. However, no bugfix/ branch has been created yet. Per the TDD workflow (CONTRIBUTING.md > Bug Fix Workflow), @aditya should: 1. Create the bugfix branch from master 2. Implement the fix 3. Remove the @tdd_expected_fail tag 4. Open a PR to master This is now 2 days overdue. Please start immediately.
Owner

Priority escalated from Low to Critical.

Per CONTRIBUTING.md bug priority policy, all Type/Bug issues must have Priority/Critical and MoSCoW/Must Have. This is a bug in existing CLI functionality — agents init --yes should not require user input, but it does.

Labels updated: Priority/Critical, MoSCoW/Must Have added.

TDD pipeline status: TDD counterpart #842 is CLOSED (TDD test merged to master). This means the tagged test for this bug already exists on master. This is a STALLED TDD PIPELINE — the bugfix branch should have been created immediately after the TDD PR merged. @aditya: Please create branch bugfix/m3-init-yes-no-input from master and begin the fix. The fix must remove the @tdd_expected_fail tag from the test tagged @tdd_bug_783.

**Priority escalated from Low to Critical.** Per `CONTRIBUTING.md` bug priority policy, all `Type/Bug` issues must have `Priority/Critical` and `MoSCoW/Must Have`. This is a bug in existing CLI functionality — `agents init --yes` should not require user input, but it does. Labels updated: `Priority/Critical`, `MoSCoW/Must Have` added. **TDD pipeline status**: TDD counterpart #842 is CLOSED (TDD test merged to `master`). This means the tagged test for this bug already exists on `master`. **This is a STALLED TDD PIPELINE** — the bugfix branch should have been created immediately after the TDD PR merged. @aditya: Please create branch `bugfix/m3-init-yes-no-input` from `master` and begin the fix. The fix must remove the `@tdd_expected_fail` tag from the test tagged `@tdd_bug_783`.
Member

Implementation Notes — Bug Fix for #783

Background

The bug was partially addressed in commit 620adfee (issue #522, fix(cli): add --yes flag to agents init for non-interactive setup), which injected a prompt_for_migration=lambda _: True callback into the UnitOfWork factory when --yes was passed. This worked around the issue but left require_confirmation=True hardcoded in UnitOfWork._ensure_database_initialized(), meaning the migration prompt function was still called (it just auto-approved). This is semantically incorrect — when the user passes --yes, the confirmation prompt should be bypassed entirely, not silently auto-approved.

The TDD counterpart (#842, commit 747d8d3c) was merged to master with @tdd_expected_fail tags. These tags were subsequently removed in commit 051ee7c2 (mass coverage commit) as a side effect, not through the proper TDD workflow.

Root Cause

UnitOfWork._ensure_database_initialized() hardcoded require_confirmation=True when calling MigrationRunner.init_or_upgrade(). Even when --yes was passed at the CLI level, the migration runner would enter the require_user_approval path and invoke the prompt callback. With the existing workaround, this callback returned True (auto-approve), but the prompt path was still exercised unnecessarily.

Fix Applied

  1. UnitOfWork.__init__ (cleveragents.infrastructure.database.unit_of_work.UnitOfWork.__init__): Added a require_confirmation: bool = True constructor parameter, stored as self._require_confirmation. Default is True for backward compatibility.

  2. UnitOfWork._ensure_database_initialized (cleveragents.infrastructure.database.unit_of_work.UnitOfWork._ensure_database_initialized): Changed from hardcoded require_confirmation=True to require_confirmation=self._require_confirmation, making it configurable via the constructor.

  3. init_command (cleveragents.cli.commands.project.init_command): Updated the --yes path to pass require_confirmation=False in addition to the existing prompt_for_migration=lambda _: True (kept as belt-and-suspenders fallback). When --yes is passed, the migration runner now skips the prompt entirely.

Test Verification

  • Behave TDD tests (features/tdd_init_yes_no_input.feature): Both scenarios pass — @tdd_expected_fail tags were already removed on master.
  • Robot TDD tests (robot/tdd_init_yes_no_input.robot): Both test cases pass.
  • Related tests: cli_init_yes_flag.feature (5 scenarios) and db_migration_lifecycle.feature (8 scenarios) all pass.

Quality Gates

All nox stages pass:

  • nox -e lint — passed
  • nox -e typecheck — passed (0 errors, 1 pre-existing warning)
  • nox -e unit_tests — 12,230 scenarios passed, 0 failed
  • nox -e integration_tests — all tests passed
  • nox -e coverage_report — 98.38% coverage (threshold: >97%)

Design Decision

Chose to make require_confirmation a constructor parameter on UnitOfWork rather than modifying MigrationRunner.init_or_upgrade() defaults, because the decision of whether to prompt belongs to the caller (CLI layer), not the infrastructure layer. The existing prompt_for_migration callback is retained as a fallback safety measure.

## Implementation Notes — Bug Fix for #783 ### Background The bug was partially addressed in commit `620adfee` (issue #522, `fix(cli): add --yes flag to agents init for non-interactive setup`), which injected a `prompt_for_migration=lambda _: True` callback into the UnitOfWork factory when `--yes` was passed. This worked around the issue but left `require_confirmation=True` hardcoded in `UnitOfWork._ensure_database_initialized()`, meaning the migration prompt function was still *called* (it just auto-approved). This is semantically incorrect — when the user passes `--yes`, the confirmation prompt should be **bypassed entirely**, not silently auto-approved. The TDD counterpart (#842, commit `747d8d3c`) was merged to master with `@tdd_expected_fail` tags. These tags were subsequently removed in commit `051ee7c2` (mass coverage commit) as a side effect, not through the proper TDD workflow. ### Root Cause `UnitOfWork._ensure_database_initialized()` hardcoded `require_confirmation=True` when calling `MigrationRunner.init_or_upgrade()`. Even when `--yes` was passed at the CLI level, the migration runner would enter the `require_user_approval` path and invoke the prompt callback. With the existing workaround, this callback returned `True` (auto-approve), but the prompt path was still exercised unnecessarily. ### Fix Applied 1. **`UnitOfWork.__init__`** (`cleveragents.infrastructure.database.unit_of_work.UnitOfWork.__init__`): Added a `require_confirmation: bool = True` constructor parameter, stored as `self._require_confirmation`. Default is `True` for backward compatibility. 2. **`UnitOfWork._ensure_database_initialized`** (`cleveragents.infrastructure.database.unit_of_work.UnitOfWork._ensure_database_initialized`): Changed from hardcoded `require_confirmation=True` to `require_confirmation=self._require_confirmation`, making it configurable via the constructor. 3. **`init_command`** (`cleveragents.cli.commands.project.init_command`): Updated the `--yes` path to pass `require_confirmation=False` in addition to the existing `prompt_for_migration=lambda _: True` (kept as belt-and-suspenders fallback). When `--yes` is passed, the migration runner now skips the prompt entirely. ### Test Verification - **Behave TDD tests** (`features/tdd_init_yes_no_input.feature`): Both scenarios pass — `@tdd_expected_fail` tags were already removed on master. - **Robot TDD tests** (`robot/tdd_init_yes_no_input.robot`): Both test cases pass. - **Related tests**: `cli_init_yes_flag.feature` (5 scenarios) and `db_migration_lifecycle.feature` (8 scenarios) all pass. ### Quality Gates All nox stages pass: - `nox -e lint` — passed - `nox -e typecheck` — passed (0 errors, 1 pre-existing warning) - `nox -e unit_tests` — 12,230 scenarios passed, 0 failed - `nox -e integration_tests` — all tests passed - `nox -e coverage_report` — 98.38% coverage (threshold: >97%) ### Design Decision Chose to make `require_confirmation` a constructor parameter on `UnitOfWork` rather than modifying `MigrationRunner.init_or_upgrade()` defaults, because the decision of whether to prompt belongs to the caller (CLI layer), not the infrastructure layer. The existing `prompt_for_migration` callback is retained as a fallback safety measure.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#783
No description provided.