Struct FieldEdits 

pub struct FieldEdits {

    pub title: Option<String>,
    pub status: Option<String>,
    pub priority: Option<String>,
    pub labels: Option<Vec<String>>,
    pub files: Option<Vec<String>>,
    pub assignee: Option<Option<String>>,
    pub estimate: Option<Option<String>>,
    pub commit: Option<Option<String>>,
    pub cycles: Option<Option<Vec<String>>>,
    pub milestones: Option<Option<Vec<String>>>,
    pub reviewer: Option<Option<String>>,
    pub start_date: Option<Option<String>>,
    pub due_date: Option<Option<String>>,
    pub parent: Option<Option<u32>>,
}

Fields

title: Option<String>

status: Option<String>

priority: Option<String>

labels: Option<Vec<String>>

files: Option<Vec<String>>

assignee: Option<Option<String>>

estimate: Option<Option<String>>

commit: Option<Option<String>>

cycles: Option<Option<Vec<String>>>

milestones: Option<Option<Vec<String>>>

reviewer: Option<Option<String>>

start_date: Option<Option<String>>

due_date: Option<Option<String>>

parent: Option<Option<u32>>

The decomposition parent, as a resolved issue number.

Some(None) clears it, mirroring assignee and every other optional field: an absent flag leaves it untouched, --parent "" removes it.

A number, never a selector, because a title is not stable and a stored title would silently break every child on a retitle. Resolution happens in crate::commands::edit against the store, which merge_fields has no access to.

Out of map for WP03 (src/editor.rs is in no WP’s owned_files; see tix #1374). The field lives here, rather than as a separate parameter, because that is exactly what assignee does: the value is merged so the merge stays uniform, and the side effect merge_fields cannot perform — here validating through the hierarchy service and appending the History event — happens around it in the caller. The alternative, a second write path in edit that bypasses the merge, is what assignee’s precedent argues against.