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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
//! Goal-tracking data model for the Session Manager (DOC-14 §9.1).
//!
//! Why: the SM tracks operator intent as durable, queryable [`Goal`]s, each
//! fanned out to one-or-many delegated t-mpm sessions (§9.3). Progress and the
//! BLOCKING verification gate (§3.5) are *derived* from the per-session
//! verification state, so the data model must capture that state precisely and
//! serialisably — it is the source-of-truth payload written to the SM palace and
//! mirrored in the `goals.json` hot cache (§9.4). Pulling the pure types into
//! their own file keeps the store (`store.rs`) focused and under the SLOC cap and
//! keeps timestamps injectable so tests stay deterministic.
//! What: defines [`GoalStatus`], [`SessionTaskState`], [`SessionLink`], and
//! [`Goal`] — all `serde`-serialisable — plus the derived [`Goal::progress`]
//! recompute and the [`Goal::all_verified`] verification-gate predicate. No I/O,
//! no clock reads here: every timestamp is passed IN.
//! Test: `goals/model_tests.rs` covers id stability, progress recompute, the
//! all-verified predicate, status transitions, and serde round-trips.
use ;
use ;
/// Lifecycle status of a [`Goal`] (DOC-14 §9.1).
///
/// Why: the operator and the SM need a single, explicit state for each goal that
/// drives surfacing (§9.2) and the close decision. The spec enumerates exactly
/// these five variants — `Done` is reachable ONLY through the verification gate
/// (§3.5), enforced in [`super::store::SmGoalStore`].
/// What: a closed enum, serialised in lowerCamelCase to keep the palace/cache
/// JSON stable and human-readable. `Pending` is the `Default` (a freshly created
/// goal with no linked work yet).
/// Test: `status_default_is_pending`, `goal_status_serde_roundtrip`.
/// Verification state of a single linked session task (DOC-14 §9.1 / §3.5).
///
/// Why: `Goal` progress and the close gate are derived purely from how many
/// linked tasks have reached `Verified` (observed evidence, §3.5). A precise
/// per-task state machine is therefore the foundation of the whole feature: a
/// goal cannot be `Done` unless EVERY link is `Verified`.
/// What: a closed enum mirroring the §3.4 delegation loop — `Launched` (spawned)
/// → `Running` (observed working) → `Verified` (evidence captured) or `Failed`.
/// `Launched` is the `Default` (the state a link is created in when a session is
/// first spawned). Serialised in lowerCamelCase for stable JSON.
/// Test: `session_state_default_is_launched`, `session_state_serde_roundtrip`,
/// and the progress/gate tests.
/// A link from a [`Goal`] to one delegated t-mpm session task (DOC-14 §9.1).
///
/// Why: a goal fans out to one-or-many sessions (§9.3); each launched
/// session-sized task is recorded here with its current verification `state` and
/// any captured `evidence` (the PR URL / test-pass output the gate requires,
/// §3.5). The `session_id` is the join key returned by `POST /sessions`.
/// What: the `session_id`, the `task` description it was launched for, its
/// [`SessionTaskState`], and `evidence` (`None` until observed). Serialisable for
/// the palace/cache payload.
/// Test: `session_link_serde_roundtrip`, and the progress/gate tests.
/// A tracked operator goal with its linked sessions and derived progress (§9.1).
///
/// Why: the central SM artifact — operator intent normalised into a stable,
/// durable record the SM reasons over, surfaces, and closes through the
/// verification gate. It is the exact payload persisted to the palace
/// (source-of-truth) and mirrored in `goals.json` (§9.4), so it must be fully
/// `serde`-serialisable and carry a STABLE `id` that survives restarts.
/// What: an `id` (`g-<short-uuid>`, assigned once at create), the normalised
/// `description`, the [`GoalStatus`], testable `acceptance` criteria, the
/// `sessions` fan-out, a derived `progress` percentage `0..=100`, `created` /
/// `updated` timestamps, and free-form `notes` (decisions / blockers). Timestamps
/// are passed in by the store so tests stay deterministic.
/// Test: `goals/model_tests.rs` (progress recompute, gate predicate, serde) and
/// `goals/store_tests.rs` (id stability, lifecycle).