1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
//! `tm projects` registry-B project + config command group (DOC-35 §3.1/§10.8, #2115/#2381/#2120).
//!
//! Why: extracted from `cli.rs` (issue #2603) to keep the top-level file
//! under the 500-SLOC production cap. Deliverable/Milestone sub-actions live
//! in the sibling `actions::deliverables` module.
//! What: [`ProjectsAction`] (`list`/`register`/`show`/`status`/`config`/
//! `deliverables`/`milestones`), [`ConfigAction`] (`set`/`unset`/`tags`),
//! and its [`SettableConfigField`] / [`ClearableConfigField`] value enums.
//! Test: `cli_parses_projects_*` in `tests_projects.rs`;
//! `cli_parses_projects_config_*` in `tests_projects_config_tests.rs`.
use Subcommand;
use ;
/// Actions for the `tm projects` subcommand (DOC-35 §3.1/§10.8, #2115/#2381).
///
/// Why: the registry-B project surface plus the Deliverable/Milestone ledger,
/// exposed as a deterministic verb tree of thin HTTP clients.
/// What: the four registry verbs (`list`/`register`/`show`/`status`) and the two
/// nested subtrees (`deliverables`/`milestones`).
/// Test: `cli_parses_projects_*` in `tests_projects.rs`.
pub
/// Actions for `tm projects config <name>` (DOC-35 §3.1/§6, #2120).
///
/// Why: the deterministic sub-verbs of the configurator — `set`/`unset` mirror
/// the field-level PATCH exactly (never free text); `tags` is a DEDICATED verb
/// rather than folded into `set`/`unset` — disclosed deviation from a literal
/// reading of the spec's CLI sketch (which groups tags under the same
/// set/unset comment line): `set <field> <value>` structurally cannot express
/// two independent lists (add AND remove) in one positional value, and §6's
/// own field table sanctions "`--add`/`--remove`" as the mechanism; the issue
/// text explicitly allows either "set/unset or dedicated --add/--remove
/// flags" and this is the dedicated-verb form.
/// What: three subcommands routed by `commands::projects::registry::config`.
/// Test: `cli_parses_projects_config_*` in `tests_projects.rs`.
pub
/// CLI value for a settable config field (§6); maps 1:1 to
/// `trusty_mpm::project_config::ConfigField` via `convert.rs`. Kept local so
/// `cli.rs` carries no domain dependency. Default kebab-case value names
/// (`default-branch`, `stack-hint`, …) match this codebase's other
/// `ValueEnum`s (e.g. `DeliverableStatusArg`).
pub
/// CLI value for a clearable config field (§6) — DELIBERATELY NARROWER than
/// [`SettableConfigField`]: `default_branch` is excluded because it has no
/// wire representation for "clear" at all (`PatchProjectBody::default_branch`
/// is a plain `Option<String>` — absent=unchanged, present+blank=400,
/// present+non-blank=set; there is no double-Option `null`=clear story like
/// `description`/`stack_hint`/`gh_user` have). Rejecting `unset
/// default-branch` at clap parse time (an "invalid value" error) is strictly
/// better than proxying a request the server cannot honor.
pub